Top 5 Tips for Securing Your AWS Management Console


AWS has been pretty clear in its messaging that it’s not solely responsible for its customers’ security with respect to their apps running on AWS.  AWS views security as a shared responsibility between itself and its customers.  In other words, the customer assumes some of the burden in securing the apps and data running on an AWS environment.  Code Spaces learned the hard way last summer what can happen when you rely solely on AWS for your data and app security.

Even Forrester Research’s Ed Ferrara echoed this “shared security” model when he said that “AWS is not going to secure your applications or software infrastructure for you.  AWS’ responsibility stops at the abstraction point between its services and the applications you deploy. . . . AWS provides key security building blocks, but it’s still your responsibility.”

For you CISOs out there that have committed to AWS or are thinking about it, you should be aware of key challenges in monitoring and securing the administration of AWS services, be it through the AWS Management Console or through APIs.  Managing access to AWS is like managing the “keys to the kingdom,” and if not done carefully, may lead to a Code Spaces scenario happening all over again.

Once you’ve got a better handle of the challenges, you can follow these 5 tips to securing admin access to AWS:

1. Find out who’s accessing your AWS console

Do you know who your AWS admins are?  Has anyone left the company recently that still has access to the console?  Are there external folks such as contractors or partners that might have access?  These questions are critical to maintaining the integrity and security of your apps and data that are leveraging AWS services (be it EC2, S3, or something else).  Being able to identify precisely who has access and the extent of their rights will go a long way towards closing any security gaps that might exist.  It’s not always outsiders that do the damage.  Malicious insiders, possibly one of the folks mentioned above, are just as likely to do something malicious or unintentional harm as someone completely unrelated to the organization.

2. Ensure your AWS security settings are up to snuff

As you can imagine, there’s a dizzying array of configuration settings for the AWS Management Console.  Compounding matters is the long list of best practices that Amazon itself publishes.  You’ve also got industry best practice guidelines issued by the Cloud Security Alliance.  And finally, there are regulatory requirements you may have to adhere to, such as those mandated by PCI DSS or ISO.  Tally it all up and it’s a pretty imposing list of requirements you have to account for.  Not meeting minimum standards, whether industry best practice or regulatory, could open yourself up to sanctions or security vulnerabilities that could easily have been avoided.

For instance, here are sample AWS security settings that are subject to compliance requirements:

  • ISO 27002 Section 9.2.3 states that the “allocation and use of privileged access rights should be restricted and controlled”
  • HIPAA Section 164.312 requires multi-factor (strong) authentication to “verify that a person or entity seeking access to electronic protected health information is the one claimed”
  • PCI DSS Section 8.2.4 requires that user passwords be changed at least every 90 days

3. Control access at the device and user levels

It’s no secret that mobile devices are taking over.  Whether it’s a smartphone or a tablet, people are using these devices to do their jobs.  The AWS Management Console has its own iOS and Android mobile apps, where users can easily manage their EC2 instances, load balancers, and other AWS services, right from their phones or tablets.  Thus, from a security standpoint, it’s critical to be able to set and enforce granular policies at the user, department, or device level on specific actions and components (e.g., launching EC2 instances, modifying ElasticCache, creating Virtual Private Clouds, etc.).

4. Stay on top of configuration changes

Since AWS admins wield so much power, it’s essential to have a workflow that can provide real-time notifications on critical admin tasks like security configuration changes.  This means real-time monitoring, alerting, and perhaps blocking all come into play.  And, to ensure you’re covered on the compliance front, you should maintain an audit trail of all security configuration changes done by AWS admins.  Similarly, enforcing separation of duties is a best practice to ensure that AWS admins don’t tamper with audit trails.  Even though AWS provides CloudTrail, it can be turned off by admins at their discretion, which is a compliance “no-no.”

5. Enforce two-factor authentication when in doubt

You can never be too careful these days, what with so many high-profile breaches involving the misuse of stolen user credentials (hello Apple iCloud and Dropbox).  Enforcing two-factor authentication is a widely accepted best practice to prevent account takeovers.  It essentially requires someone to prove who they say they are through a combination of passwords, tokens, keyfobs, etc.  Together with behavioral profiling (whether by user, device, or location) and automatic anomaly detection, two-factor authentication is an incredibly powerful mechanism to tighten up security around the AWS Management Console.  If an admin is going to delete 20 server instances – this might be a good time to invoke 2 factor authentication while also sending alert to IT management.

So, the moral of this blog story is to not fret in a shared security model.  Even though AWS is responsible for only a portion of the complete security picture, solutions like Imperva Skyfence Cloud Gateway make holding up your end of the security pact seamless and (relatively) stress-free.