Deploying Apps in AWS? Keeps These Security Risks in Mind
By Haseeb Budhani, CEO, Soha Systems, Inc
Deploying applications in a public cloud environment can be an extremely liberating experience for applications teams. Amazon Web Services (AWS) and other public cloud providers are a panacea to the mind-numbing procedures and policies that information security (InfoSec) teams enforce in traditional data center environments.
"AWS has done a tremendous job delivering integrated services that significantly reduce the time for applications to be developed, tested and deployed in production"
Clearly, AWS has done a tremendous job delivering integrated services that significantly reduce the time for applications to be developed, tested and deployed in production. Anyone who has experience submitting requests for new ports on the edge firewall, or a new Virtual IP (VIP) for a staging server, can appreciate why AWS has so quickly disrupted the data center status quo.
Being able to run fast is great, but let’s not forget that data center InfoSec rules exist to defend the enterprise against threats and data loss. The InfoSec team needs to also manage the risk when the application infrastructure is exposed to the following types of users:
1. Privileged users(e.g. IT administrators)
2. Badged employees
4. 3rdparty users (e.g. vendors and contractors)
Application Risk: Data Center vs. AWS
Many people would argue that an application deployed in a data center or in AWS have the same risk exposure. In my opinion the risks in the public cloud are potentially greater, as I will detail below.
Traditional data centers are designed with WAN ingress points that are piped through a DMZ, where security appliances can analyze/monitor bi-directional traffic. Once traffic is scrubbed in the DMZ, it is sent back to application servers. This hierarchical model has developed over time to allow IT organizations to build fat layers of security at the edge of the network.
AWS, on the other hand, is designed to be more flat, with each instance potentially able to talk directly to the Internet. In my opinion, this architecture actually raises risk concerns. There are two features that make it really easy for developers deploying applications in AWS to shoot themselves in the foot:
1. Ability to change security group policies on a per-instance basis
2. Ability to assign an Elastic IP (EIP) to any instance
Consider the following scenario: It’s 1am. You’ve been working for 19 hours and you want to go to sleep. But the build’s broken and you can’t figure out what’s going on. You really need direct SSH access to the Linux instance in the private subnet, but Joe never got around to setting up the bastion host he was supposed to install 2 weeks ago. So what do you do? You associate an EIP to this instance and you reconfigure the associate security group to allow all inbound traffic (ANY from 0.0.0.0/0). You SSH into the instance and fix the problem. And you fall asleep without putting things back the way they were.
Many would argue there’s nothing wrong with leaving a Linux instance on the Internet since there’s a username/password or username/ssh_key pair protecting access. But are you sure you’re not running a vulnerable Tomcat version on this instance? How about a REDIS server? Are you sure all the software installed on this Linux instance is free of vulnerabilities? Clearly there’s no way to be absolutely sure, and if you’ve ever done this, you have more than likely been hacked.
Evaluating Your AWS Security Strategy
With respect to AWS or any other public cloud environment, the following are key questions your InfoSec team needs to ask when evaluating your security strategy:
• Are there reliable controls in place to ensure that only sanctioned users can access a given application?
• The enforcement mechanism must be mature enough to handle the access risk presented by the user type. No badged employee or 3rd party user needs direct network access, and must not be given VPN access to the AWS environment.
• Are there mechanisms in place to control which instances can interface with each other, and over what ports, etc.?
• Controlling the horizontal movement of malware is a critical to your security strategy. If your webserver instances start trying to connect to other instances in the subnet on random ports, you may already be infected.
• Have you implemented the right Identity and Access Management (IAM) policies for your AWS administrators such that no single user’s silly mistake brings the whole house down?
• There is never a good reason to open full access to an instance from the Internet, and it’s best to have policies in place to protect against this.
• Does the security solution you are selecting work seamlessly across public cloud environments through a single pane of glass?
• Most enterprises expect to leverage more than one public cloud provider, and shouldn’t need to deploy different solutions in different environments.
• Is your security solution easy to use?
• Every vendor claims their solution is easy to use, but clearly that’s not the case. Trial the solution, and insist vendors prove their claims via Proof of Concept (PoC) engagements.
The public cloud can indeed be liberating for the application team. By selecting the right security and access solutions to protect applications in the public cloud, security and application teams can work in tandem—a nearly impossible task in a data center. If you can securely enable access to a new application within a few minutes of it being deployed, everybody wins.