Security Best Practices for Amazon Web Services

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

Read Post

Summary: 88 Seconds

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

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.