Heading to AppSec DC next week? Be sure to catch GuidePoint Security’s Co-Founder and Principal, Justin Morehouse, present Behind Enemy Lines Practical Triage Approaches to Mobile Security Abroad 2012 Edition on Thursday, April 5 at 11 a.m.
If you are unable to make it to the conference, we will post Justin’s slides after the presentation. If you would like more information about the presentation, leave a comment below.
Abstract: Having traveled over 100K miles internationally during the past 9 months, the topic of mobile security while abroad was on my radar. I took some precautions myself and jotted down some ideas to discuss with my peers. Then one of my clients asked me to come up with a solution for their executives while traveling to locations that would benefit greatly from their intellectual property. This presentation covers the lessons learned while securing mobile devices for both the enterprise and consumer while outside the 50 states. Areas of particular interest will be common threats and attacks and the REALISTIC steps you can take to reduce your attack surface and return your IP home safely. We’ll also cover what to do when your primary safeguards fail or end up in a toilet somewhere…
I recently had an in-depth conversation with a client discussing security best practices in Amazon’s Web Services (AWS) Infrastructure-as-a-Service (IaaS). Specifically, the client was interested in applying egress controls to their web, application, and database tiers. Given the sensitivity of the data contained within their AWS application, my client’s largest concern was limiting a potential breach to prevent a successful attacker from exfiltrating their application’s data.
Before diving into my recommendations, it’s important to understand two key security controls provided by AWS. Those who’ve worked with AWS EC2 instances should be familiar with Security Groups. For those of you who aren’t, Security Groups equate to firewall rules that are applied to a specific (or group of) EC2 instances. What some of you may not know is that Security Groups actually perform stateful inspection (this is important to those of you with PCI implications). When your application is architected directly in EC2 (not within a Virtual Private Cloud or VPC), Security Groups can only be applied to inbound traffic. Obviously, this doesn’t help with my client’s objective of implementing egress controls.
The second security control provided by AWS is Network Access Control Lists or Network ACLs. Network ACLs differ from Security Groups in that they are only available within VPCs and are generally intended to be applied to networks rather than individual EC2 instances within a VPC. For example, with Network ACLs it is common that you would say that only 1433/tcp (MS SQL) is allowed from your public subnet to your private network. While utilizing a /32 netmask will allow you to implement Network ACLs for specific hosts, you should note that Network ACLs are NOT stateful (again, remember Security Groups are). This requires you to implement matching inbound and outbound Network ACL rules.
So back to egress controls. Regardless of your application’s architecture within AWS (just EC2 instances or utilizing a VPC), you can apply egress controls directly on your EC2 instances (on the OS itself). However, this often increases the overhead of the EC2 instances to levels unacceptable to development teams. So what other options do we have? A lesser-known feature of VPCs is the ability to apply outbound rules to your Security Groups. For example, you can say that your MS SQL server is not allowed to communicate directly with the Internet, but is only allowed access to 80/tcp and 443/tcp for Windows Updates through a NAT server in your public subnet. Such a setup accomplishes the goal of implementing egress controls on your EC2 instances while not increasing their overhead.
After explaining the enhanced security features of an AWS VPC, my client made a case to his development team in support of re-architecting the application inside of a VPC. Fortunately for my client, the security team was engaged during the design phase of their organization’s AWS application and implementing such a change was a lot less painful than re-designing an existing application. That isn’t to say that such a redesign can’t be successfully performed on an established application, but we all know it’s a lot easier to do earlier in the game.
To recap what we’ve discussed…
- Security Groups are analogous to firewall rules and can be applied to specific EC2 instances (or groups of instances)
- Security Groups provide stateful inspection
- Standard EC2 instances (those not part of a VPC) allow only inbound Security Group rules
- Network ACLs can only be applied to entire networks (subnets)
- Network ACLs do NOT provide stateful inspection
- Network ACLs are only available within VPCs
- VPCs enable outbound rules to be added to Security Groups and can be applied directly to individual or groups of EC2 instances that are part of a VPC
- Inbound and outbound Security Groups do NOT add overhead to the EC2 instances they are applied to
Hopefully you found this information helpful and it results in your further investigation into VPCs when looking at how to apply egress controls to your AWS applications.