Australia’s cloud security paradox shows visibility is lagging

At a glance

What this is: The article argues that Australian cloud security teams are investing heavily but still lack the context needed to explain traffic, prioritise alerts, and stop lateral movement effectively.

Why it matters: For IAM and security practitioners, the cloud visibility gap matters because identity, access, and movement controls only work when teams can trace who or what is communicating and why.

By the numbers:

• 92% of organizations plan to increase their cloud security spending this year, signaling a nationwide push to strengthen resilience in the face of growing cloud complexity.
• 40% of network traffic lacks sufficient context.
• 2, 061 alerts per day
• 83% say they get more alerts than they can effectively investigate.

👉 Read Illumio's analysis of Australia's cloud security paradox and visibility gaps

Context

Australia’s cloud security paradox is not a tooling shortage. It is a governance and context problem, where organisations can generate alerts and spend more on controls but still struggle to explain what network activity means in operational terms. The primary keyword here is cloud security visibility, and the article’s core claim is that visibility without context leaves defenders unable to prioritise risk.

That matters to IAM practitioners because cloud traffic often reflects identity-driven access, workload-to-workload communication, and lateral movement between services and environments. When teams cannot trace the who, what, and why behind activity, they lose the ability to connect access decisions to runtime behaviour. For teams managing NHI and workload identity, that gap is especially relevant; it shows why observability must be tied to identity governance, not treated as a separate SOC problem.

Key questions

Q: How can organisations reduce alert fatigue from cloud security tools?

A: Reduce alert fatigue by filtering findings through runtime evidence, business context, and actual execution paths. When teams know which functions run in production, they can suppress low-value noise and focus on issues that affect live services. That improves response speed and makes remediation queues more credible to engineering teams.

Q: Why does east-west visibility matter for cloud security?

A: East-west visibility matters because attackers often move laterally after initial access using legitimate credentials and approved protocols. If defenders cannot see internal service-to-service traffic clearly, they cannot tell whether a connection is expected, excessive, or malicious. That makes containment slower and increases the chance that a breach expands before it is understood.

Q: What breaks when cloud traffic lacks context?

A: When cloud traffic lacks context, teams lose the ability to distinguish normal behaviour from malicious movement. Detection becomes noisy, prioritisation becomes inconsistent, and response decisions rely on guesswork instead of evidence. The practical failure is not just missed alerts, but the inability to connect access, communication, and impact in time.

Q: How do organisations know whether IAM observability is actually working?

A: They should look for measurable reductions in dormant accounts, excessive privileges, unresolved exposure, and time needed to close high-risk findings. If observability only produces more alerts or more reports, it is not improving governance. The right signal is a shrinking identity attack surface and faster, more accurate remediation.

Technical breakdown

Why cloud detection tools still fail without context

Detection tools can generate high-fidelity events, but without context they cannot tell defenders whether an action is normal, risky, or part of an attack path. Context means the surrounding data needed to interpret an event, such as workload identity, source and destination, timing, policy state, and known relationships between systems. In cloud environments, east-west traffic is often the hardest to interpret because it looks routine until you map it against expected behaviour. The result is not a lack of alerts, but a lack of meaning. Practical implication: prioritise telemetry that ties activity to identity and communication intent, not just raw network events.

Practical implication: prioritise telemetry that ties activity to identity and communication intent, not just raw network events.

How alert fatigue obscures lateral movement

Alert fatigue emerges when analysts receive more signals than they can validate, forcing them to ignore or delay review of potential attack indicators. Lateral movement is especially hard to spot in cloud environments because it often uses legitimate credentials and approved protocols after initial access. If east-west traffic is not baselined against expected service relationships, analysts end up chasing anomalies without understanding the attack chain. That is why the article’s emphasis on context is operational, not cosmetic. Practical implication: build correlation around service identity, trust relationships, and movement patterns so investigators can separate attacker behaviour from normal workload chatter.

Practical implication: build correlation around service identity, trust relationships, and movement patterns so investigators can separate attacker behaviour from normal workload chatter.

Why blast radius control depends on observability

Blast radius control limits how far an attacker can move after gaining a foothold. In cloud environments, that requires knowing not only where a workload can connect, but also whether those connections are justified, monitored, and constrained by policy. If teams cannot see traffic flows clearly, they cannot prove that segmentation, access rules, or detection logic are actually reducing exposure. This is where identity and network governance intersect: workload identities, permissions, and communication paths all shape the containment boundary. Practical implication: treat observability as a control verification layer for segmentation and access policies, not only as a detection feature.

Practical implication: treat observability as a control verification layer for segmentation and access policies, not only as a detection feature.

Threat narrative

Attacker objective: The attacker aims to move laterally inside the cloud environment long enough to expand access, evade detection, and increase the breach impact.

1. Entry occurs through a cloud workload or account compromise that gives the attacker a valid foothold inside the environment.
2. Escalation and lateral movement follow as the attacker uses legitimate access paths to move between services while blending into normal east-west traffic.
3. Impact appears when defenders cannot distinguish malicious movement from ordinary traffic quickly enough to contain the breach.

NHI Mgmt Group analysis

Cloud visibility is now a governance control, not a monitoring feature. The article shows that organisations can spend heavily on cloud security and still lack the context needed to interpret traffic. That means visibility must be treated as an enforcement layer for policy, segmentation, and access review, not just a SOC dashboard. For practitioners, the lesson is that control assurance fails when runtime activity cannot be tied back to identity and intended communication paths.

Context gaps create a false sense of containment readiness. When 97% of organisations say their tools have serious limitations, the problem is not coverage alone. It is that tool output cannot be operationalised without relationships, baselines, and ownership context. This aligns closely with NHI governance, where a service account or workload identity may be legitimate but still dangerous if its behaviour is unobserved or over-broad. Practitioners should assume that unexplained traffic is unresolved access risk, not harmless noise.

Lateral movement prevention depends on understanding trust relationships inside the environment. Cloud controls often focus on perimeter reduction while attackers operate within trusted paths after initial access. That creates a trust gap between policy design and runtime reality. The named concept here is context collapse: the point at which telemetry volume is high but operational meaning is too weak to support containment. Practitioners should close that gap by mapping workload identity, allowed flows, and policy exceptions together.

Australia’s pattern is a preview of a broader cloud maturity problem. High adoption of CNAPP, XDR, SIEM, and SOAR does not automatically produce better decisions if the data remains fragmented. The article reflects a market where teams are well instrumented but still under-informed. For identity leaders, this reinforces that access governance and runtime observability have to converge if cloud resilience is going to improve.

The real control question is not whether alerts exist, but whether they can drive action. Alerting without context creates a reporting burden rather than a defense capability. In practice, that means security programmes should measure time to attribution and containment, not just detection volume. For practitioners, the next step is to prove that each high-risk workload path is visible, attributable, and enforceable under policy.

What this signals

Context collapse: the operational risk is not just too much telemetry, but too little meaning attached to it. Australian teams should expect cloud resilience programmes to shift from alert-volume reduction to evidence quality, entity correlation, and containment verification. Where workload identity is involved, the programme should be able to show which identities can talk to which systems and why.

For identity teams, the next maturity step is to connect cloud observability to access governance and non-human identity control. The cloud control plane and the identity plane are now inseparable in practice, especially where service-to-service trust and lateral movement are part of the threat model. Teams that cannot map these relationships will struggle to prove least privilege at runtime.

The broader signal is that detection and response tooling is becoming a data integration problem. If the programme cannot reconcile network, identity, and policy context, it will continue to generate work without producing clarity. Practitioners should prepare for a stronger emphasis on continuous verification of runtime access paths, not just periodic access review.

For practitioners

• Map east-west traffic to identity and policy Baseline internal service communications against workload identity, approved destinations, and policy exceptions so analysts can tell routine traffic from suspicious movement.
• Reduce alert volume through correlation Correlate signals across cloud, network, and identity sources before they reach analysts, using shared entity context to suppress duplicates and elevate true attack paths.
• Measure containment by attribution speed Track how long it takes to explain a suspicious flow, identify the actor or workload, and decide whether segmentation or account action is required.
• Validate segmentation against real traffic Use observed traffic patterns to test whether segmentation rules actually limit movement between critical workloads, and correct policy drift where connections exceed expected scope.

Key takeaways

• The article’s central problem is context deficiency, not tool shortage, and that is why cloud security investment is not translating into clearer decisions.
• Australian organisations are seeing 40% of network traffic without sufficient context and 2,061 alerts per day, which explains why detection confidence can coexist with poor response quality.
• The practical fix is to tie observability to identity, policy, and communication patterns so teams can prove containment instead of simply generating more alerts.

Key terms

• East-west visibility: East-west visibility is the ability to observe traffic and communication between internal systems, workloads, and services. In cloud environments, it is essential for spotting lateral movement because many malicious actions happen after initial access and look legitimate unless relationships and baselines are known.
• Alert Fatigue: Alert fatigue is the condition where a security team receives so many low-value alerts that important events become harder to notice. In monitoring programs, it usually signals poor rule tuning, weak prioritisation, or a mismatch between detection logic and operational reality.
• Blast radius: Blast radius is the scope of damage an attacker can cause after gaining access. In cloud security, it is shaped by segmentation, identity scope, trust relationships, and the organisation’s ability to detect and contain movement before a foothold becomes a broader compromise.
• Context Collapse: The failure that occurs when separate security tools observe different parts of the same abuse chain but cannot connect them into one narrative. In identity and fraud operations, this means the organisation sees alerts, but not the full campaign behind them.

What's in the full article

Illumio's full blog covers the operational detail this post intentionally leaves for the source:

• The survey methodology behind the Australian cloud detection and response findings, including how the metrics were collected and interpreted.
• Per-metric breakdowns of visibility, alert fatigue, and downtime that support executive reporting and internal benchmarking.
• The article's explanation of how Illumio Insights maps traffic to attack paths and containment decisions in hybrid and multi-cloud environments.
• Implementation context for teams evaluating whether their current detection stack can actually reduce blast radius.

👉 Illumio's full blog expands on the survey findings, the alert-fatigue data, and the containment implications for hybrid cloud teams.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners who need to connect identity control to broader security operations and governance.