In traditional data center environments, security teams usually leverage their standard security tools and agents to capture network-level logs. Capturing these logs gives teams visibility into network architecture and traffic flow. However, when we migrate applications to AWS, these standard practices change. The same toolsets might not be as efficient as they were in the traditional environment. While security fundamentals are the same, the approach changes. Security teams need to explore new options and adopt new tools to ensure adequate security coverage.
Containers and orchestration systems use numerous technical abstractions to support auto-scaling and distributed applications that obfuscate visibility into application communication flows. Security teams lose visibility into application communication flows, rendering traditional tools useless and exposing the application to risk.
At any given moment, attack and defense are in a cat and mouse game where each side gains a momentary advantage. What we’ve recently seen over the past few months is a situation where defense is playing catch-up with what appears to be a serious hardware bug.
Current speculations suggest that a serious CPU bug might allow code running in user space to read kernel space memory. Such capability will make it much easier for attackers to exploit other security bugs that exist in the system or read sensitive system data. Another speculative guess suggests that the bug allows one virtual machine an introspection into another virtual machine memory. This attack vector puts in danger virtual environments such as Amazon EC2 and Azure Hyper-V where multiple tenants can co-exist on a single physical machine.