Encryption Does Not Tell You Who Moved

At a Glance

Encrypted communication protects information in transit, but its presence does not tell an investigator whether a connection was expected, properly authorized, or part of a suspicious sequence. East-west traffic refers here to communications among internal services, workloads, hosts, and cloud resources. An important question is whether an organization can explain which service communicated with which peer, under whose authority, and for what business purpose. MITRE ATT&CK documents misuse of remote services for lateral movement, but the technique describes possible adversary behavior rather than a claim that routine encrypted connections are malicious. [1]

The most useful starting point is not to decrypt every packet. It is to connect network observations with a current picture of application dependencies, workload identities, approved access paths, and the records available after an alert. Cloud flow records can illuminate traffic direction and endpoints; their existence alone does not reveal the complete content or intent of an encrypted conversation. [2]

A Normal Service Connection Can Still Raise a Difficult Question

Consider a hypothetical online service with a front-end workload, a payment service, and a reporting database. A scheduled application update creates a new connection from the front end to the database. The connection is encrypted and technically succeeds. That observation does not prove wrongdoing: The change may be an approved architectural improvement. Yet the security team should be able to trace the request to a service owner, determine whether the direct connection is approved, and understand which controls would prevent an unauthorized route.

A separate example involves an administrator using an approved remote-management protocol during maintenance. The connection may share characteristics with remote access that an adversary could misuse after obtaining credentials. The distinction comes from change records, identity, timing, target, and subsequent actions, not a judgment based on the protocol name. Treat a possible lateral-movement path as a review hypothesis until supporting evidence exists.

Five Questions That Make East-West Traffic Review Useful

1. Which Communications Are Expected?

Ask the Application Owner and Cloud Engineering team to identify essential service-to-service connections for one critical application. Record the sending workload, receiving service, business purpose, normal schedule, and approved environment. A dependency map should identify dynamic service identities rather than relying only on IP addresses that may change after deployment.

2. What Exactly Does the Flow Record Show?

AWS VPC Flow Logs capture selected information about IP traffic to and from VPC network interfaces. [2] Google Cloud VPC Flow Logs uses sampled packets and produces aggregate connection records. [3] Neither description is a promise that an organization automatically records every transaction or application request. Confirm collection scope, sampling, retention, and whether a workload identity can be attached to the record.

3. Which Control Governs the Path?

A security rule or Kubernetes NetworkPolicy helps describe permitted connections, but effective behavior depends on the applicable enforcement system. Kubernetes explicitly requires a compatible network plugin for NetworkPolicy enforcement. [4] Review an approved test of the actual path rather than inferring protection from the policy file. The test should use harmless traffic and document application availability.

4. Can Network and Identity Evidence Be Joined?

A source address, destination address, and connection time may be useful but can be insufficient to determine who initiated an action. Look for workload or host identity, access logs, service ownership, deployment changes, and the analyst case record. If an identity cannot be reliably mapped because of address translation or short-lived workloads, state that limitation instead of inserting a guessed owner.

5. What Decision Would Follow an Unexpected Path?

Define the accountable reviewer, when a service owner should be contacted, and which actions require approval. Security Operations may want to restrict a connection while the Application Owner needs to preserve a payment or authentication dependency. Good evidence supports a proportionate decision and a restoration plan, not simply a larger alert count.

A Simple Evidence Record for One Application

This small record makes uncertainty visible. A connection without a confirmed business purpose is a question to resolve, not a confirmed attack. An alert with missing service identity is a visibility issue until an investigator can establish more context. A successful permitted-traffic test does not validate every other route. Revisit the record after substantial architecture or logging changes.

Why This Matters to Cybersecurity Vendors

For a Chief Information Security Officer, the purchasing question may concern exposure to business-critical systems. Security Operations may want faster reconstruction of an unusual connection. Cloud Architecture may need controls that preserve intended dependencies. A cybersecurity supplier should describe the evidence its solution can provide and the collection prerequisites it does not control. It should not imply that an industry reference proves performance at a prospect.

CyberTech Intelligence can support cybersecurity vendors with buyer intelligence to clarify relevant account roles, managed demand generation to share evidence-led educational content, and pipeline activation once buyers express a specific challenge and agree to engage. CTI’s published service categories provide the commercial context for this approach. [5] An article view or download indicates engagement with content, not a verified security incident or sales opportunity.

Three Mistakes to Avoid

• Treating encryption as proof that a connection is safe or hostile. It establishes neither conclusion on its own.

• Using a flow count as a direct measure of attack prevalence. Retention, sampling, and application context matter.

• Assuming a product deployment proves complete visibility. Verify the configured environment and what was actually observed.

CyberTech Intelligence Perspective

A credible narrative begins with an evidence question the buyer can answer, not an assertion that every encrypted workload conceals a threat. Technical suppliers earn trust by explaining what their controls can observe and how customers can test that claim in a defined environment. CTI can help connect that proof to the distinct decisions made by security, platform, and business stakeholders.

References and Source Boundaries

Numbered citations identify published sources supporting nearby statements. ATT&CK describes possible behavior, standards provide design guidance, and provider documentation defines stated collection features. No cited source establishes a breach in a named prospect, a customer-specific control result, the effectiveness of a commercial product in an untested setting, or revenue attributable to this campaign. Source review date: October 28, 2026.

1. MITRE ATT&CK. Remote Services, T1021. Use in this asset: Adversary use of legitimate remote access for lateral movement. URL: https://attack.mitre.org/techniques/T1021/ 
2. Amazon Web Services. Logging IP Traffic Using VPC Flow Logs. Use in this asset: What cloud network-interface flow records capture. URL: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html 
3. Google Cloud. VPC Flow Logs. Use in this asset: Sampling, connection records, and supported flow observations. URL: https://docs.cloud.google.com/vpc/docs/flow-logs 
4. Kubernetes. Network Policies. Use in this asset: Layer 3/4 rules and the requirement for policy enforcement. URL: https://kubernetes.io/docs/concepts/services-networking/network-policies/ 
5. CyberTech Intelligence. Cybersecurity Intelligence Services. Use in this asset: Published editorial and cybersecurity service scope. URL: https://cybertechintelligence.com/services