Research

This is a short series on where to start with AWS security. We plan to release it as a concise white paper soon. It doesn’t cover everything but is designed to kickstart and prioritize your cloud security program on Amazon. We do plan to write a much deeper paper next year, but we received several requests for something covering the fundamentals, so here you go… Building on a Secure Foundation Amazon Web Services is one of the most secure public cloud platforms available, with deep datacenter security and many user-accessible security features. Building your own secure services on AWS requires properly using what AWS offers, and adding additional controls to fill the gaps. Amazon’s datacenter security is extensive – better than many organizations achieve for their in-house datacenters. Do your homework, but unless you have special requirements you can feel comfortable with their physical, network, server, and services security. AWS datacenters currently hold over a dozen security and compliance certifications, including SOC 1/2/3, PCI-DSS, HIPAA, FedRAMP, ISO 27001, and ISO 9001. Never forget that you are still responsible for everything you deploy on top of AWS, and for properly configuring AWS security features. AWS is fundamentally different than even a classical-style virtual datacenter, and understanding these differences is key for effective cloud security. This paper covers the foundational best practices to get you started and help focus your efforts, but these are just the beginning of comprehensive cloud security. Defend the Management Plane One of the biggest risks in cloud computing is an attacker gaining access to the cloud management plane: the web interface and APIs to configure and control your cloud. Fail to lock down this access and you might as well just hand over your datacenter to the bad guys. Fortunately Amazon provides an extensive suite of capabilities to protect the management plane at multiple levels, including both preventative and monitoring controls. Unfortunately the best way to integrate these into existing security operations isn’t always clear; it can also be difficult to identify any gaps. Here are our start-to-finish recommendations. Control access and compartmentalize The most important step is to enable Multifactor Authentication (MFA) for your root account. For root accounts we recommend using a hardware token which is physically secured in a known location which key administrators can access in case of emergency. Also configure your Security Challenge Questions with random answers which aren’t specific to any individual. Write down the answers and also store them in a secure but accessible location. Then create separate administrator accounts using Amazon’s Identity and Access Management (IAM) for super-admins, and also turn on MFA for each of those accounts. These are the admin accounts you will use from day to day, saving your root account for emergencies. Create separate AWS accounts for development, testing, and production, and other cases where you need separation of duties. Then tie the accounts together using Amazon’s consolidated billing. This is a very common best practice. Locking down your root account means you always keep control of your AWS management, even in case an administrator account is compromised. Using MFA on all administrator accounts means you won’t be compromised even if an attacker manages to steal a password. Using different AWS accounts for different environments and projects compartmentalizes risks while supporting cross-account access when necessary. Amazon’s IAM policies are incredibly granular, down to individual API calls. They also support basic logic, such as tying a policy to resources with a particular tag. It can get complicated quickly, so aside from ‘super-admin’ accounts there are several other IAM best practices: Use the concept of least privilege and assign different credentials based on job role or function. Even if someone needs full administrative access sometimes, that shouldn’t be what they use day to day. Use IAM Roles when connecting instances and other AWS components together. This establishes temporary credentials which AWS rotates automatically. Also use roles for cross account access. This allows a user or service in one AWS account to access resources in another, without having to create another account, and ties access to policies. Apply object-level restrictions using IAM policies with tags. Tag objects and the assigned IAM policies are automatically enforced. For administrative functions use different accounts and credentials for each AWS region and service. If you have a user directory you can integrate it with AWS using SAML 2.0 for single sign-on. But be careful; this is most suitable for accounts that don’t need deep access to AWS resources, because you lose the ability to compartmentalize access using different accounts and credentials. Never embed Access Keys and Secret Keys in application code. Use IAM Roles, the Security Token Service, and other tools to eliminate static credentials. Many attackers are now scanning the Internet for credentials embedded in applications, virtual images, and even posted on code-sharing sites. These are only a starting point, focused on root and key administrator accounts. Tying them to multifactor authentication is your best defense against most management plane attacks. Monitor activity Amazon provides three tools to monitor management activity within AWS. Enable all of them: CloudTrail logs all management (API) activity on AWS services, including Amazon’s own connections to your assets. Where available it provides complete transparency for both your organization’s and Amazon’s access. CloudWatch monitors the performance and utilization of your AWS assets, and ties tightly into billing. Set billing alarms to detect unusually high levels of activity. You can also send system logs to CloudWatch but this isn’t recommended as a security control. Config is a new service that discovers services and configurations, and tracks changes over time. It is a much cleaner way to track configuration activity than CloudTrail. CloudTrail and Config don’t cover all regions and services, so understand where the gaps are. As of this writing Config is still in preview, with minimal coverage, but both services expand capabilities regularly. These features provide important data feeds but most organizations use additional tools for overall collection and analysis, including log management and SIEM. As a

Rich here. I don’t remember actually seeing Star Wars in the movie theater. I was six years old in 1977, and while I cannot remember the feelings of walking along the sticky theater floor, finding a seat I probably had to kneel on to see the screen from, and watching as the lights dimmed and John Williams assaulted my ears, I do remember standing with my father outside. In a line that stretched around the building. My lone image of this transformative day is of waiting near the back doors, my father beside me, wondering just what the big deal was. Memories of the film itself come from the television in the living room of my childhood home. Not from years later, when VCRs invaded suburbia and VHS vs. Beta made the evening news, but that year. 1977. When I watched my very own copy of Star Wars on a three-quarter-inch professional video deck connected to our TV. My father was recently shut out of a business he co-founded when his partner, who owned the majority share, decided to take everything. The company was contracting to place video decks on long-haul merchant ships and provide first-run movies to entertain the crews. The business fell apart after my dad left, and all he walked away with (so far as I know – he died when I was in high school) was that video player and three sets of tapes (each tape only held an hour). A documentary on the US Bicentennial celebration we attended as a family in NYC, the Wizard of Oz, and Star Wars. Imagine being the only kid in your neighborhood – heck, possibly the entire state – with a copy of Star Wars at home in 1977 or 1978 (it’s possible I got the tape in 78, but I’m pretty sure it was 77). Tapes of higher quality than VHS or Beta; not that it mattered with our TV. I watched Star Wars hundreds of times over the next few years. I watched it so many times that, to this day, I still start to get up to swap tapes every time the Millennium Falcon is pulled into the Death Star by the tractor beam. And, as has happened to so many others over the past 37 years, the film, and its sequels, didn’t merely influence my life, it defined it in many ways. It is hard to know how anything truly affects you in the long term. But I have to assume the philosophies of the fictional jedi [Ed: Not entirely fictional. Wish fullfillment FTW!] pointed me in certain directions. To martial arts, public service, the study of Japanese history, an obsession with space and science, an attraction to women who kick ass, and a moral framework that prizes self-sacrifice and the protection of others. To bombing recklessly down a Pikes Peak hiking trail on my mountain bike, laughing hysterically as I dodged the trees like I was on a speeder bike. (I was working rescue – it was totally legit!). So the day after Thanksgiving I fired up my Apple TV, went to the Trailers app, and shed a few tears over the next 88 seconds. More tears than I expected. I never thought I would live to see a new Star Wars. A new story – not merely backstory with an inevitable ending. With the actors of my youth, playing the same characters. Written by the writer of Empire, and directed by the guy who saved Star Trek?!? And I certainly never thought I would be standing in line in a theater next December, holding the hand of my daughter, who will be the same age I was when it all started in 1977. (And her younger sister, but probably not the boy – he won’t even be 3 yet). I realize I have been geeking out a lot lately here in the Summary, but for good reason. These are the tools I used to define myself as I built my identity. Perhaps not the same tools you used, and not the only tools, but certainly some of the most influential. I no longer need to look back on them nostalgically. I don’t need to relive my youth. I can once again make them part of my future, and perhaps drag my own children along with me. It’s gonna be a hell of a year. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Nada. No one loves us anymore. Favorite Securosis Posts Mike Rothman: Monitoring the Hybrid Cloud: Solution Architectures. These concepts will become a lot more important in 2015 as the lack of visibility in cloud-land becomes a higher profile issue. Rich: Winding Down. Like Mike, I’m cramming, but also blocking some time to relax and refocus for the coming year. I can’t really say much, but it’s going to be a wild one. Other Securosis Posts Security Best Practices for Amazon Web Services. Monitoring the Hybrid Cloud: Technical Considerations. Firestarter: Numbness. Securing Enterprise Applications [New White Paper]. Favorite Outside Posts Adrian Lane: Dog Follows Athletes. Not security but a great story. Mike Rothman: Fixed vs. Growth: The Two Basic Mindsets that Shape Our Lives. A very interesting article about how you view the world. There is no single right answer, but understanding your mindset enables you to make decisions that work better for you. Rich: The Sony Hack Is A Watershed Moment – Especially If North Korea Is Involved. Not really. Saudi Aramco was the watershed moment. The one that sent shock waves through government and the energy industry. But nothing grabs the headlines like Hollywood. Just imagine if they posted naked pictures of Seth Rogen and James Franco! Research Reports and Presentations Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis