Migrating legacy workloads to the cloud and embracing containers for new cloud-native applications provides agility and compelling cost benefits. However, securing these workloads from external and internal attacks is problematic at best, resulting in painful security breaches that threaten enterprises on an all-too-frequent basis. We need a solution that increases both security and the visibility of the security posture of applications while simplifying operations for hybrid cloud workloads. Let us break down why we need better security for Amazon Web Services or AWS.
AWS Security Groups
To achieve security objectives, the use of security groups in AWS is ubiquitous. This method is analogous to using an inbound network firewall that enables specific protocols, ports, source IP ranges, and other security groups to reach your EC2 instances. Typically, you create multiple security groups, assign different rules to each, and then place EC2 instances into them.
Problems with the Perimeter Security Model
While the traditional perimeter security model is familiar, it remains suboptimal for a number of reasons. A simple firewall between the Web servers and the rest of the application may be adequate, but relying on static firewall rules that operate at the level of IP addresses and ports for internal East-West traffic is awkward at best for DevSecOps personnel.
Example of AWS Security Group ACLs
IP Address Security Can’t Keep Up
It’s impossible to keep up with the changes required to track the IP addresses of application components. Today, IP address range rules get established by the hundreds. As application components spin up, shut down and move within the dynamic runtime environment across sites and clouds, vulnerabilities are created due to obsolete security rules and the inability to deploy new rules when needed. DevSecOps want to stop struggling to manage hundreds of isolated network segments and move to a model where security is associated with application components, instead. It is a much better model.
Another major factor in play is that AWS security groups do not provide sufficient security granularity. If any of the services in any EC2 instances in one given security group are compromised, then all of the services across all EC2 instances in that group are at risk. This is why the classic land and expand strategy used by most hackers works so well.
Disparate Security Models
Over half of security breaches rely on internal vulnerabilities based on inadvertent human errors such as the use of default passwords, confusion over security settings, or the use of images that contain vulnerabilities. Add to this the complexity of specifying security rules one way for AWS, another way for Azure or on-premises firewalls and, well… you see the point. It’s a mess.
There is an Answer: If security is tied to individual application components instead of being tied to IP address ranges, all of the problems associated with IP address range security go away. There is no longer the need to constantly change and maintain security rules because security moves with the application components across their lifetimes, sites and clouds, regardless of orchestrators being used – and security can be automated to reduce operational complexity with no changes to code being required, providing clear visibility of the security posture of applications.
For more information on AWS, read our AWS integration guide here.
To see Aporeto in action, view our on-demand webinar here. In this On-Demand demonstration learn about key features and use cases of the Aporeto solution, including: