Research

This is the second post in a new series. If you want to track it through the entire editing process, you can follow along and contribute on GitHub. You can read the first post here Building an Encryption System In a straightforward application we normally break out the components – such as the encryption engine in an application server, the data in a database, and key management in an external service or appliance. Or, for a legacy application, we might instead enable Transparent Database Encryption (TDE) for the database, with the encryption engine and data both on the same server, but key management elsewhere. All data encryption systems are defined by where these pieces are located – which, even assuming everything works perfectly, define the protection level of the data. We will go into the different layers of data encryption in the next section, but at a high level they are: In the application where you collect the data. In the database that holds the data. In the files where the data is stored. On the storage volume (typically a hard drive, tape, or virtual storage) where the files reside. All data flows through that stack (sometimes skipping applications and databases for unstructured data). Encrypt at the top and the data is protected all the way down, but this adds complexity to the system and isn’t always possible. Once we start digging into the specifics of different encryption options you will see that defining your requirements almost always naturally leads you to select a particular layer, which then determines where to place the components. The Three Laws of Data Encryption Years ago we developed the Three Laws of Data Encryption as a tool to help guide the encryption decisions listed above. When push comes to shove, there are only three reasons to encrypt data: If the data moves, physically or virtually. To enforce separation of duties beyond what is possible with access controls. Usually this only means protecting against administrators because access controls can stop everyone else. Because someone says you have to. We call this “mandated encryption”. Here is an example of how to use the rules. Let’s say someone tells you to “encrypt all the credit card numbers” in a particular application. Let’s further say the reason is to prevent loss of data if a database administrator account is compromised, which eliminates our third reason. The data isn’t necessarily moving, but we want separation of duties to protect the database even if someone steals administrator credentials. Encrypting at the storage volume layer wouldn’t help because a compromised administrative account still has access within the database. Encrypting the database files alone wouldn’t help either. Encrypting within the database is an option, depending on where the keys are stored (they must be outside the database) and some other details we will get to later. Encrypting in the application definitely helps, since that’s completely outside the database. But in either cases you still need to know when and where an administrator could potentially access decrypted data. That’s how it all ties together. Know why you are encrypting, then where you can potentially encrypt, then how to position the encryption components to achieve your security objectives. Tokenization and Data Masking Two alternatives to encryption are sometimes offered in commercial encryption tools: tokenization and data masking. We will spend more time on them later, but simply define them for now: Tokenization replaces a sensitive piece of data with a random piece of data that can fit the same format (such as by looking like a credit card number without actually being a valid credit card number). The sensitive data and token are then stored together in a highly secure database for retrieval under limited conditions. Data masking replaces sensitive data with random data, but the two aren’t stored together for later retrieval. Masking can be a one-way operation, such as generating a test database, or a repeatable operation such as dynamically masking a specific field for an application user based on permissions. For more information on tokenization vs. encryption you can read our paper. That covers the basics of encryption systems. Our next section will go into details of the encryption layers above before delving into key management, platform features, use cases, and the decision tree to pick the right option. Share:

This is the first post in a new series. If you want to track it through the entire editing process, you can follow it and contribute on GitHub. The New Age of Encryption Data encryption has long been part of the information security arsenal. From passwords, to files, to databases, we rely on encryption to protect our data in storage and on the move. It’s a foundational element in any security professional’s education. But despite its long history and deep value, adoption inside data centers and applications has been relatively – even surprisingly – low. Today we see encryption growing in the data center at an accelerating rate, due to a confluence of reasons. A trite way to describe it is “compliance, cloud, and covert affairs”. Organizations need to keep auditors off their backs; keep control over data in the cloud; and stop the flood of data breaches, state-sponsored espionage, and government snooping (even their own). And thanks to increasing demand, there is a growing range of options, as vendors and even free and Open Source tools address the opportunity. We have never had more choice, but with choices comes complexity; and outside of your friendly local sales representative, guidance can be hard to come by. For example, given a single application collecting an account number from each customer, you could encrypt it in any of several different places: the application, the database, or storage – or use tokenization instead. The data is encrypted (or substituted), but each place you might encrypt raises different concerns. What threats are you protecting against? What is the performance overhead? How are keys managed? Does it meet compliance requirements? This paper cuts through the confusion to help you pick the best encryption options for your projects. In case you couldn’t guess from the title, our focus is on encrypting in the data center – applications, servers, databases, and storage. Heck, we will even cover cloud computing (IaaS: Infrastructure as a Service), although we covered that in depth in another paper. We will also cover tokenization and its relationship with encryption. We won’t cover encryption algorithms, cipher modes, or product comparisons. We will cover different high-level options and technologies, such as when to encrypt in the database vs. in the application, and what kinds of data are best suited for tokenization. We will also cover key management, some essential platform features, and how to tie it all together. Understanding Encryption Systems When most security professionals first learn about encryption the focus is on keys, algorithms, and modes. We learn the difference between symmetric and asymmetric and spend a lot of time talking about Bob and Alice. Once you start working in the real world your focus needs to change. The fundamentals are still important but now you need to put them into practice as you implement encryption systems – the combination of technologies that actually protects data. Even the strongest crypto algorithm is worthless if the system around it is full of flaws. Before we go into specific scenarios let’s review the basic concepts behind building encryption systems because this becomes the basis for decisions on which encryption options to go use. The Three Components of a Data Encryption System When encrypting data, especially in applications and data centers, knowing how and where to place these pieces is incredibly important, and mistakes here are one of the most common causes of failure. We use all our data at some point, and understanding where the exposure points are, where the encryption components reside, and how they tie together, all determine how much actual security you end up with. Three major components define the overall structure of an encryption system. The data: The object or objects to encrypt. It might seem silly to break this out, but the security and complexity of the system depend on the nature of the payload, as well as where it is located or collected. The encryption engine: This component handles actual encryption (and decryption) operations. The key manager: This handles keys and passes them to the encryption engine. In a basic encryption system all three components are likely located on the same system. As an example take personal full disk encryption (the built-in tools you might use on your home Windows PC or Mac): the encryption key, data, and engine are all stored and used on the same hardware. Lose that hardware and you lose the key and data – and the engine, but that isn’t normally relevant. (Neither is the key, usually, because it is protected with another key, or passphrase, that is not stored on the system – but if the system is lost while running, with the key in memory, that becomes a problem). For data centers these major components are likely to reside on different systems, increasing complexity and security concerns over how the pieces work together. Share:

Rich, Mike, and Adrian each pick a trend they expect to hammer us in 2015. Then they talk about it, probably too much. From threat intel to tokenization to SaaS security. And oh, we did have to start with a dig at the Pats. Cheating? Super Bowl? Really? Come on now. Watch or listen: Share:

Over the years the RSA Conference has racked up some (legitimate) criticism that its session selection process was too opaque, started too early for up-to-date content, and didn’t always reflect the community at large. I am a bit biased because I have been involved with RSAC for a while now, and talk to the organizers year round, but I know they make a concerted effort to deal with these issues. (No, I’m not on any of the selection committees). For example they can’t really release the names of the track leads since there is a swarm (or is that murder?) of PR and marketing pros who are paid to get their representatives on stage, no matter what. I guarantee you that if those names get out, those individuals will be hammered directly. The early Call For Papers? This is a large event with a ton of tracks and a selection process. Hold the CFP too close to the event and it opens yet more cans of messes. Community representation? Funny you ask! This year RSAC has dedicated an entire track to crowdsourced submissions. The goal is to directly address all the criticism above: Submissions are open until March 12, only a month before the conference. Anyone can submit, but corporate presentations will most definitely be scrutinized. The community will vote to pick the best sessions. Anyone can vote – not just RSAC attendees! RSAC attendee votes get weighted more, which should help reduce gaming the system. The final selections will be by a public panel, based on the top 25 vote receivers. The panel is comprised of known entities, who are used to dealing with PR and marketing techniques. Yes, I am on the panel. I also feel honored that they approached me early to get ideas and feedback on this concept. They have put a lot of thought into this (especially Britta Glade, who probably hates me for calling her out). It won’t be perfect but it’s version 1.0. If you always wanted to speak at RSA, but couldn’t get through the process, give it a shot. This is a great chance for new speakers, late-breaking research, and creative sessions. Share:

Earlier today in the Friday Summary I vented frustrations at news articles blaming the victims of crimes, and often guessing at the facts. Having been on the inside of major incidents that made the international news (more physical than digital in my case), I know how little often leaks to the outside world. I picked on the Wired article because it seemed obsessed with the lack of encryption on Anthem data, without citing any knowledge or sources. Just as we shouldn’t blindly trust our government, we shouldn’t blindly trust reporters who won’t even say, “an anonymous source claims”. But even a broken clock is right twice a day, and the Wall Street Journal does cite an insider who says the database wasn’t encrypted (link to The Verge because the WSJ article is subscription-only). I won’t even try too address all the issues involved in encrypting a database. If you want to dig in we wrote a (pretty good) paper on it a few years ago. Also, I’m very familiar with the healthcare industry, where encryption is the exception more than the rule. Many of their systems simply can’t handle it due to vendors not supporting it. There are ways around that but they aren’t easy. So let’s look at the two database encryption options most likely for a system like this: Column (field) level encryption. Transparent Database Encryption (TDE). Field-level encryption is complex and hard, especially in large databases, unless your applications were designed for it from the start. In the work I do with SaaS providers I almost always recommend it, but implementation isn’t necessarily easy even on new systems. Retrofitting it usually isn’t possible, which is why people look at things like Format Preserving Encryption or tokenization. Neither of which is a slam dunk to retrofit. TDE is much cleaner, and even if your database doesn’t support it, there are third party options that won’t break your systems. But would either have helped? Probably not in the slightest, based on a memo obtained by Steve Ragan at CSO Online. The attacker had proficient understanding of the data platforms and successfully utilized valid database administrator logon information They discovered a weird query siphoning off data, using valid credentials. Now I can tell you how to defend against that. We have written multiple papers on it, and it uses a combination of controls and techniques, but it certainly isn’t easy. It also breaks many common operational processes, and may not even be possible depending on system requirements. In other words, I can always design a new system to make attacks like this extremely hard, but the cost to retrofit an existing system could be prohibitive. Back to Anthem. Of the most common database encryption implementations, the odds are that neither would have even been much of a speed bump to an attack like this. Once you get the right admin credentials, it’s game over. Now if you combined with multi factor authentication and Database Activity Monitoring, that would have likely helped. But not necessarily against a persistent attacker with time to learn your systems and hijack legitimate credentials. Or perhaps encryption that limited access based on account and process, assuming your DBAs never need to run big direct queries. There are no guarantees in security, and no silver bullets. Maybe encrypting the database would have helped, but probably not the way most people do it. But it sure makes a nice headline. I am starting a new series on datacenter encryption and tokenization Monday, which will cover some of these issues. Not because of the breach – I am actually already 2 weeks late. Share:

Rich here, Another week, another massive data breach. This morning I woke up to a couple interview requests over this. I am always wary of speaking on incidents based on nothing more than press reports, so I try to make clear that all I can do is provide some analysis. Maybe I shouldn’t even do that, but I find I can often defuse hyperbole and inject context, even without speaking to the details of the incident. That’s a fine line any of us on press lists walk. To be honest, more often than not I see people fall into the fail bucket by making assumptions or projecting their own bias. Take this Anthem situation. I kept my comments along the lines of potential long-term issues for people now suffering exposed personal information (for example a year of credit monitoring is worthless when someone loses your Social Security Number). I was able to talk about who suffers the consequences of these breaches, trends in long-term impacts on breached companies, and the weaknesses in our financial and identity systems that make this data valuable. I did all of that without blaming Anthem, guessing as to attribution, or discussing potential means and motivations. Those are paths you can consider if you have inside information (verified, of course), but even then you need to be cautious. It was disappointing to read some of the articles on this breach. One in particular stood out because it was from a major tech publication, and the reporter seemed more interested in blaming Anthem and looking smarter than anything else. This is the same person who seriously blew it on another story recently due to the same hubris (but no apologies, of course). There is a difference between analyzing and guessing, and it is often hubris. Analysis means admitting what you don’t know, and challenging and doubting your own assumptions. Constantly. I have a huge fracking ego, and I hate being wrong, but I care more about the truth and facts than being right or wrong. To me, it’s like science. Present the facts and the path to your conclusions, making any assumptions clear. Don’t present assumptions as facts, and always assume you don’t know everything and what you do know changes sometime. Most of the time. And for crap’s sake, enough with blaming the victim and thinking you know how the breach occurred when you don’t have a single verified source (if you have one, put it in the article). Go read Dennis Fisher’s piece for how to play it straight and still make a point. Unless you are Ranum. We all need to bow down to Ranum, who totally gets it. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on Tokenization. Paper on dynamic authorization by Gunnar Peterson (Registration required). Securosis Posts We know, slow week. We blame random acts of sleep deprivation. New Paper: Security and Privacy on the Encrypted Network. Incite 2/4/2015: 30×32. Applied Threat Intelligence: Use Case #3, Preventative Controls. Favorite Outside Posts Adrian: Spy Agencies Secretly Rely On Hackers. One of the best aspects of this profession is being able to expand your mind based on really cool research from security people. Spy organizations would be crazy not to do the same! Look at the names on the list – half the people I follow to learn from because they do really interesting research. Mike: Looking for the Teachable Moments. Never stop learning. It’s a simple as that. Rich: Every Frame a Painting. This is a YouTube channel of short segments of film analysis. I’m a big film geek, and I love dissecting a scene or work and learning more about how films are made. The Jackie Chan one is my favorite so far. If you like it you can donate to support it. JJ: Use The ‘Fire Model’ When You Get Criticized At Work. Editor’s note: I am so glad I don’t have to deal with things like this. I’m probably unemployable at this point -rich. Mortman: The Queen Of Code. History FTW. Mortman (2): A Cybersecurity Wake Up Call for Emergency Managers. Rich should appreciate this one. Research Reports and Presentations Security and Privacy on the Encrypted Network. Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. 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. Top News and Posts Cross Site Scripting vulnerability found in IE 11 Yet Another Flash Patch Fixes Zero-Day Flaw The Oracle of Security Flaws via LiquidMatrix Marriott Android App Left Credit Card Data Vulnerable Security Basics for Docker Who’s Hijacking Internet Routes? WiFi blocking… blocked. There could be legitimate enterprise problems with this. A CIO Perspective on Security in the Cloud U.S. Officials Say Chinese Cyberespionage ‘Needs to Stop’ Share:

Rich here. Last week I talked about learning to grind it out. Whether it’s a new race distance, or plowing through a paper or code that isn’t really flowing, sometimes you need to just put your head down, set a pace, and keep moving. And sometimes that’s the absolute worst thing to do. I have always been a natural sprinter; attracted both to sports and other achievements I could rocket through with sheer speed and power. I was horrible at endurance endeavors (physical and mental) as a kid and into my early 20’s. I mean, not “pretending to be humble horrible” but “never got the Presidential Physical Fitness thing because I couldn’t run a mile worth a crap” horrible. And procrastinating? Oh my. I had, I shit you not, a note in my file at the University of Colorado not to “cut him any breaks” because I so thoroughly manipulated the system for so long. (8 years of continuous undergrad… you make a few enemies on the way). It was handwritten on a Post-It, right on my official folder. It was in my mid-20’s that I gained the mental capacity for endurance. Mountain rescue was the biggest motivator because only a small percentage of patients fell near roads. I learned to carry extremely heavy loads over long distances, and then take care of a patient at the end. You can’t rely on endurance – we used to joke that our patients were stable or dead, since it isn’t like we could just scoop them off the road (mostly). Grinding is essential, but can be incredibly unproductive if you don’t pop your head up every now and then. Like the time we were on a physically grueling rescue, at about 11,000’, at night, in freezing rain, over rough terrain. Those of us hauling the patient out were turning into zombies, but someone realized we were hitting the kind of zone where mistakes are made, people get hurt, and it was time to stop. Like I said before: “stable or dead”, and this guy was relatively stable. So we stopped, a couple team members bunkered in with him for the night, and we managed to get a military helicopter for him in the morning. (It may have almost crashed, but we won’t talk about that.) It hadn’t occurred to me to stop; I was too deep in my inner grind, but it was the right decision. Just like the problem I was having with some code last year. It wouldn’t work, no matter what I did, and I kept trying variation after variation. I hit help forums, chat rooms, you name it. Then I realized it wasn’t me, it was a bug (this time) in the SDK I was using. Only when I tried to solve the problem from an entirely new angle, instead of trying to fix the syntax, did I figure it out. The cloud, especially, is funny that way. Function diverges from documentation (if there is any) much more than you’d think. Just ask Adrian about AWS SNS and undocumented, mandatory, account IDs. In security we can be particularly prone to grinding it out. Force those logs into the SIEM, update all the vulnerable servers before the auditor comes back, clear all the IDS alerts. But I think we are at the early edge of a massive transition, where popping our heads up to look for alternatives might be the best approach. ArcSight doesn’t have an AWS CloudTrail connector? Check out a hybrid ELK stack or cloud-native SIEM. Tired of crash patching for the next insert pseudo-cool name here vulnerability? Talk to your developers about autoscaling and continuous deployment. Every year I try to block out a week, or at least a few half-days, to sit back, focus on research, and see which of my current assumptions and work patterns are wrong or no longer productive. Call it “active resting”. I think I have come up with some cool stuff for this year, both in my work habits and security controls. Now I just need time to play with the code and configurations, to see if any of it actually works. But unlike my old patients, my code and writing seem to be both unstable and dead, so I won’t get my hopes too high. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich gave a webcast on the SaaS security lifecycle for SkyHigh Networks. Rich quoted on IoT security. Mostly about the hype. Dave Lewis on DDoS Attacks Continue To Rise in Forbes. Favorite Securosis Posts Rich: There’s a lot of hype on threat intel. Mike is doing a great job showing how to actually use the stuff, as in Applied Threat Intelligence: Use Case #2, Incident Response/Management. Mike: New Paper: Monitoring the Hybrid Cloud. Adrian and I are ahead of the general market, but if you aren’t thinking about how you will monitor cloud stuff you will be behind the curve (and the 8-ball) before long. Other Securosis Posts Incite 1/28/2015: Shedding Your Skin. Applied Threat Intelligence: Use Case #1, Security Monitoring. Firestarter: 2015 Trends. New Paper: Monitoring the Hybrid Cloud. Applied Threat Intelligence: Defining TI. Favorite Outside Posts Mortman: A complete guide to Puppy Bowl XI. Editor’s note: we need to pay more attention to how Mort spends his free time. Rich: Glenn Fleishman on the risk and problems posed by Internet connected devices. Yep, major DDoS attacks now rely on thousands of home routers. It’s an interesting (and real) scenario. Mike: Security Should Be the Top Driver for DevOps – Stormy makes a great point here: if security is going to be relevant moving forward, we had better grok and integrate these DevOps principles. Period. Research Reports and Presentations Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. 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

Rich, Mike, and Adrian each pick a trend they expect to hammer us in 2015. Then we talk about it, probably too much. From threat intel to tokenization to SaaS security. And oh, we did have to start with a dig on the Pats. Cheating? Super Bowl? Really? Come on now. Watch or listen: Share:

Rich here. Last weekend I ran a local half-marathon. It wasn’t my first, but I managed to cut 11 minutes off my time and set PRs (Personal Record for you couch potatoes) for both the half and a 10K. I didn’t really expect either result, especially since I was out of running for nearly a month due to a random foot injury (although I kept biking). My times have been improving so much lately that I no longer have a good sense of my race paces. Especially b cause I have only run one 10K in the past 3 years that didn’t involve pushing about 100 lbs of kids in a jog stroller. This isn’t bragging – I’m still pretty slow compared to ‘real’ runners. I haven’t even run a marathon yet. These improvements are all personal – not to compare myself to others. I have a weird relationship with running (and swimming/biking). I am most definitely not a natural endurance athlete. I even have the 23andMe genetic testing results to prove it! I’ve been a sprinter my entire life. For you football fans, I could pop off a 4.5 40 in high school (but weighed 135, limiting my career). In lifting, martial arts, and other sports I always had a killer power to weight ratio but lacked endurance for the later rounds. While I have never been a good distance runner running has always been a part of my life. Mostly to improve my conditioning for other sports, or because it was required for NROTC or other jobs. I have always had running shoes in the closet, have always gone through a pair a year, and have been in the occasional race pretty much forever. I even would keep the occasional running log or subscription to Runners World, but I always considered a marathon beyond my capabilities, and lived with mediocre times and improvements. (I swear I read Runners World for the articles, not the pictures of sports models in tight clothes). Heck, I have even had a couple triathlon coaches over the years, and made honest attempts to improve. And I’ve raced. Every year, multiple tris, rides, and runs a year. But then work, life, or travel would interfere. I’d stick to a plan for a bit, get a little better, and even got up to completing a half-marathon without being totally embarrassed. Eventually, always, something would break the habit. That’s the difference now. I am not getting faster because I’m getting younger. I’m getting faster because I stick to the plan, or change the plan, and just grind it out no matter what. Injured, tired, distracted, whatever… I still work out. This is the longest continuous (running) training block I have ever managed to sustain. It’s constant, incremental improvement. Sure, I train smart. I mix in the right workouts. Take the right rest days and adjust to move around injuries. But I. Keep. Moving. Forward. And break every PR I’ve ever set, and am now faster than I was in my 20’s for any distance over a mile. Maybe it’s age. Maybe, despite the Legos and superhero figures on my desk I am achieving s modicum of maturity. Because I use the same philosophy in my work. Learning to program again? Make sure I code nearly every day, even if I’m wiped or don’t have the time. Writing a big paper that isn’t exciting? Write every day; grind it out. Keeping up my security knowledge? Research something new every day; even the boring stuff. Now my life isn’t full of pain and things I hate. Quite the contrary – I may be happier than I’ve ever been. But part of that is learning to relish the grind. To know that the work pays off, even those times it isn’t as fun. Be it running, writing, or security, it always pays off. And, for some of those big races, it means pushing through real pain knowing the endorphins at the end are totally worth it. That, and the post-race beers. Hell, even Michelob Ultra isn’t too bad after 13 miles. Runner’s high and all. Now I need to go run a race with Mike. He’s absolutely insane for taking up running at his age (dude is ancient). Maybe we can go do the Beer Mile together. That’s the one even Lance bailed on after one lap. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences I’m giving a webcast on managing SaaS security later this month for SkyHigh Networks. Rich quoted at TechTarget on hardware security. Favorite Securosis Posts Mike: Firestarter: Full Toddler – The disclosure battles heat up (again) and we wonder when someone is going to change Google’s diaper… Other Securosis Posts Incite 1/21/2015: Making the Habit. New Paper: Security Best Practices for Amazon Web Services. Summary: No Surprises. Incite 1/14/2015: Facing the Fear. Your Risk Isn’t My Risk (Apple Thunderbolt Edition). Friday Summary: Favorite Films of 2014 (Redux). Incite 1/7/2014: Savoring the Moment. Favorite Outside Posts Mike Rothman: Question checklist for reviewing your new marketing materials…. There is so much crappy marketing out there, especially in the security industry. Every marketeer should make sure to go through Godin’s list before sending anything out to the market. Pepper: The flood through the crack in the Great Firewall. The Iconfactory effectively DDoSed by China. Rich: Will Sharing Cyberthreat Information Help Defend the United States? Good analysis. We can’t legislate ourselves out of the cybersecurity mess, but if all we do is bitch on Twitter, we sure won’t get anywhere. Richard is one of the few trying to really engage on the issue and help navigate the complexity. Dave Lewis: 3 Problems With UK PM Cameron’s Crypto Proposal. Nope, it isn’t just in the US. Rich #2: A Spy in the Machine. This is one reason consumer privacy and security, without back doors for governments is so important. Research Reports and Presentations Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in

I could probably write a book on AWS security at this point, except I don’t have the time, and most of you don’t have time to read it. So I wrote a concise paper on the key essentials to get you started – including the top four things to do in the first five minutes with a new AWS account. Here is an excerpt: 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. 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 from a virtual datacenter (private cloud), 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 a comprehensive cloud security strategy. The paper has a [permanent home]((https://securosis.com/research/publication/security-best-practices-for-amazon-web-services). Or you can directly download the PDF. I would especially like to thank AlienVault for licensing this paper. Remember companies that license our content don’t get to influence or steer it (outside of submitting comments like anyone else), but their support means we get to release it all for free. Share: