Aporeto Logo
Aporeto Logo

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.

AWS Security Groups

To achieve security objectives, the use of security groups in Amazon Web Services 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.

Fine-grained Security

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.

Recent Posts Key Security Concerns for a Kubernetes Deployment How We Prevented the Kubernetes API-Server Vulnerability Security Groups and their Pitfalls

Subscribe to Our Blog

x