Cloud security for the network security engineer, or why it's all just so wrong these days

The talk opens by contrasting traditional on-premises network defense with cloud security. Its central point is that in a cloud account an attacker may hold the same access the defender has, because the control plane replaces the network perimeter as the place where movement happens. The speaker argues that defenders should treat the root account as the closest thing to physical access and should protect it with multiple MFA methods, use a separate everyday user, and keep an inventory of every access key so they can be rotated quickly during an incident. Cloud activity logs are presented as the main record of actions that never cross the network.

The offensive section looks at how resources get exposed. Storage buckets, machine images and queues can be made public by mistake, and granting access to "authenticated users" in AWS covers every AWS account holder worldwide, not just the organisation's own users. Enumeration can start from predictable bucket DNS names. Access keys are described as the most valuable thing an attacker can find, since busy administrators often skip least-privilege configuration. The instance metadata service is shown as a route from an application flaw, such as command injection or a proxy misconfiguration, to credentials already present in the environment.

In the live demonstration, the speaker uses credentials taken from an instance to list buckets that appear secured in the console, then downloads files that include what looks like cardholder and administrative data, along with stored admin keys. The speaker notes that this activity happened outside the internal network, so little telemetry appeared beyond API records. The practical takeaways are to limit what instances can reach, treat long-lived keys as standing risk, and enable data event logging for storage.