Practical Cloud Security A Guide for Secure Design and Deployment (Chris Dotson) (Z-Library)

Chris Dotson Practical Cloud Security A Guide for Secure Design and Deployment

Chris Dotson Practical Cloud Security A Guide for Secure Design and Deployment Boston Farnham Sebastopol TokyoBeijing

978-1-492-03751-4 [LSI] Practical Cloud Security by Chris Dotson Copyright © 2019 Chris Dotson. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Rachel Roumeliotis Developmental Editors: Andy Oram and Nikki McDonald Production Editor: Nan Barber Copyeditor: Rachel Head Proofreader: Amanda Kersey Indexer: Judith McConville Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Rebecca Demarest March 2019: First Edition Revision History for the First Edition 2019-03-01: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781492037514 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Practical Cloud Security, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author, and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix 1. Principles and Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Least Privilege 1 Defense in Depth 2 Threat Actors, Diagrams, and Trust Boundaries 2 Cloud Delivery Models 6 The Cloud Shared Responsibility Model 6 Risk Management 10 2. Data Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data Identification and Classification 13 Example Data Classification Levels 14 Relevant Industry or Regulatory Requirements 15 Data Asset Management in the Cloud 17 Tagging Cloud Resources 18 Protecting Data in the Cloud 19 Tokenization 19 Encryption 20 Summary 26 3. Cloud Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Differences from Traditional IT 29 Types of Cloud Assets 30 Compute Assets 31 Storage Assets 37 Network Assets 41 Asset Management Pipeline 42 iii

Procurement Leaks 43 Processing Leaks 44 Tooling Leaks 45 Findings Leaks 45 Tagging Cloud Assets 46 Summary 48 4. Identity and Access Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Differences from Traditional IT 51 Life Cycle for Identity and Access 52 Request 53 Approve 54 Create, Delete, Grant, or Revoke 54 Authentication 55 Cloud IAM Identities 55 Business-to-Consumer and Business-to-Employee 56 Multi-Factor Authentication 57 Passwords and API Keys 59 Shared IDs 61 Federated Identity 61 Single Sign-On 61 Instance Metadata and Identity Documents 63 Secrets Management 64 Authorization 68 Centralized Authorization 69 Roles 70 Revalidate 71 Putting It All Together in the Sample Application 72 Summary 75 5. Vulnerability Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Differences from Traditional IT 78 Vulnerable Areas 80 Data Access 80 Application 81 Middleware 82 Operating System 84 Network 84 Virtualized Infrastructure 85 Physical Infrastructure 85 Finding and Fixing Vulnerabilities 85 Network Vulnerability Scanners 87 iv | Table of Contents

Agentless Scanners and Configuration Management 88 Agent-Based Scanners and Configuration Management 89 Cloud Provider Security Management Tools 91 Container Scanners 91 Dynamic Application Scanners (DAST) 92 Static Application Scanners (SAST) 92 Software Composition Analysis Scanners (SCA) 93 Interactive Application Scanners (IAST) 93 Runtime Application Self-Protection Scanners (RASP) 93 Manual Code Reviews 94 Penetration Tests 94 User Reports 95 Example Tools for Vulnerability and Configuration Management 95 Risk Management Processes 98 Vulnerability Management Metrics 98 Tool Coverage 99 Mean Time to Remediate 99 Systems/Applications with Open Vulnerabilities 99 Percentage of False Positives 100 Percentage of False Negatives 100 Vulnerability Recurrence Rate 100 Change Management 101 Putting It All Together in the Sample Application 102 Summary 106 6. Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Differences from Traditional IT 109 Concepts and Definitions 111 Whitelists and Blacklists 111 DMZs 112 Proxies 112 Software-Defined Networking 113 Network Features Virtualization 113 Overlay Networks and Encapsulation 113 Virtual Private Clouds 114 Network Address Translation 115 IPv6 116 Putting It All Together in the Sample Application 116 Encryption in Motion 118 Firewalls and Network Segmentation 121 Allowing Administrative Access 126 Web Application Firewalls and RASP 130 Table of Contents | v

Anti-DDoS 132 Intrusion Detection and Prevention Systems 133 Egress Filtering 134 Data Loss Prevention 136 Summary 137 7. Detecting, Responding to, and Recovering from Security Incidents. . . . . . . . . . . . . . . 139 Differences from Traditional IT 140 What to Watch 141 Privileged User Access 142 Logs from Defensive Tooling 144 Cloud Service Logs and Metrics 147 Operating System Logs and Metrics 148 Middleware Logs 148 Secrets Server 149 Your Application 149 How to Watch 149 Aggregation and Retention 150 Parsing Logs 151 Searching and Correlation 152 Alerting and Automated Response 152 Security Information and Event Managers 153 Threat Hunting 155 Preparing for an Incident 155 Team 156 Plans 157 Tools 159 Responding to an Incident 160 Cyber Kill Chains 161 The OODA Loop 162 Cloud Forensics 163 Blocking Unauthorized Access 164 Stopping Data Exfiltration and Command and Control 164 Recovery 164 Redeploying IT Systems 164 Notifications 165 Lessons Learned 165 Example Metrics 165 Example Tools for Detection, Response, and Recovery 166 Putting It All Together in the Sample Application 166 Monitoring the Protective Systems 168 Monitoring the Application 169 vi | Table of Contents

Monitoring the Administrators 169 Understanding the Auditing Infrastructure 170 Summary 171 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Table of Contents | vii

Preface As the title states, this book is a practical guide to securing your cloud environments. In almost all organizations, security has to fight for time and funding, and it often takes a back seat to implementing features and functions. Focusing on the “best bang for the buck,” security-wise, is important. This book is intended to help you get the most important security controls for your most important assets in place quickly and correctly, whether you’re a security profes‐ sional who is somewhat new to the cloud, or an architect or developer with security responsibilities. From that solid base, you can continue to build and mature your controls. While many of the security controls and principles are similar in cloud and on- premises environments, there are some important practical differences. For that rea‐ son, a few of the recommendations for practical cloud security may be surprising to those with an on-premises security background. While there are certainly legitimate differences of opinion among security professionals in almost any area of informa‐ tion security, the recommendations in this book stem from years of experience in securing cloud environments, and they are informed by some of the latest develop‐ ments in cloud computing offerings. The first few chapters deal with understanding your responsibilities in the cloud and how they differ from in on-premises environments, as well as understanding what assets you have, what the most likely threats are to those assets, and some protections for them. The next chapters of the book provide practical guidance, in priority order, of the most important security controls that you should consider first: • Identity and access management • Vulnerability management ix

• Network controls The final chapter deals with how to detect when something’s wrong and deal with it. It’s a good idea to read this chapter before something actually goes wrong! Do you need to get any certifications or attestations for your environment, like PCI certification or a SOC 2 report? If so, you’ll need to watch out for a few specific pit‐ falls, which will be noted. You’ll also need to make sure you’re aware of any applicable regulations—for example, if you’re handling PHI (protected health information) in the United States, or if you’re handling personal information for EU citizens, regard‐ less of where your application is hosted. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program ele‐ ments such as variable or function names, databases, data types, environment variables, statements, and keywords. Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values or by values deter‐ mined by context. This element signifies a tip or suggestion. This element signifies a general note. x | Preface

This element indicates a warning or caution. O’Reilly Online Learning Platform For almost 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help compa‐ nies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, conferences, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in- depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/practical-cloud-security. To comment or ask technical questions about this book, send email to bookques‐ tions@oreilly.com. For more information about our books, courses, conferences, and news, see our web‐ site at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Preface | xi

Acknowledgments This book would not have happened without the encouragement and support of my wonderful wife, Tabitha Dotson, who told me that I couldn’t pass up this opportunity and juggled schedules and obligations for over a year to make it happen. I’d also like to thank my children, Samantha (for her extensive knowledge of Greek mythology) and Molly (for constantly challenging assumptions and thinking outside the box). It takes many people besides the author to bring a book to publication, and I didn’t fully appreciate this before writing one. I’d like to thank my editors, Andy Oram and Courtney Allen; my reviewers, Hans Donker, Darren Day, and Edgar Ter Danielyan; and the rest of the wonderful team at O’Reilly who have guided and supported me through this. Finally, I’d like to thank all of my friends, family, colleagues, and mentors over the years who have answered questions, bounced around ideas, listened to bad puns, laughed at my mistakes, and actually taught me most of the content in this book. xii | Preface

CHAPTER 1 Principles and Concepts Yes, this is a practical guide, but we do need to cover a few cloud-relevant security principles at a high level before we dive into the practical bits. If you’re a seasoned security professional new to the cloud, you may want to skim down to “The Cloud Shared Responsibility Model” on page 6. Least Privilege The principle of least privilege simply states that people or automated tools should be able to access only what they need to do their jobs, and no more. It’s easy to forget the automation part of this; for example, a component accessing a database should not use credentials that allow write access to the database if write access isn’t needed. A practical application of least privilege often means that your access policies are deny by default. That is, users are granted no (or very few) privileges by default, and they need to go through the request and approval process for any privileges they require. For cloud environments, some of your administrators will need to have access to the cloud console—a web page that allows you to create, modify, and destroy cloud assets such as virtual machines. With many providers, anyone with access to your cloud console will have godlike privileges by default for everything managed by that cloud provider. This might include the ability to read, modify, or destroy data from any part of the cloud environment, regardless of what controls are in place on the operating systems of the provisioned systems. For this reason, you need to tightly control access to and privileges on the cloud console, much as you tightly control physical data cen‐ ter access in on-premises environments, and record what these users are doing. 1

1 The Verizon Data Breach Investigations Report is an excellent free resource for understanding different types of successful attacks, organized by industry and methods, and the executive summary is very readable. Defense in Depth Many of the controls in this book, if implemented perfectly, would negate the need for other controls. Defense in depth is an acknowledgment that almost any security control can fail, either because an attacker is sufficiently determined or because of a problem with the way that security control is implemented. With defense in depth, you create multiple layers of overlapping security controls so that if one fails, the one behind it can still catch the attackers. You can certainly go to silly extremes with defense in depth, which is why it’s impor‐ tant to understand the threats you’re likely to face, which are described later. How‐ ever, as a general rule, you should be able to point to any single security control you have and say, “What if this fails?” If the answer is complete failure, you probably have insufficient defense in depth. Threat Actors, Diagrams, and Trust Boundaries There are different ways to think about your risks, but I typically favor an asset- oriented approach. This means that you concentrate first on what you need to pro‐ tect, which is why I dig into data assets first in Chapter 2. It’s also a good idea to keep in mind who is most likely to cause you problems. In cybersecurity parlance, these are your potential “threat actors.” For example, you may not need to guard against a well-funded state actor, but you might be in a business where a criminal can make money by stealing your data, or where a “hacktivist” might want to deface your website. Keep these people in mind when designing all of your defenses. While there is plenty of information and discussion available on the subject of threat actors, motivations, and methods,1 in this book we’ll consider four main types of threat actors that you may need to worry about: • Organized crime or independent criminals, interested primarily in making money • Hacktivists, interested primarily in discrediting you by releasing stolen data, committing acts of vandalism, or disrupting your business • Inside attackers, usually interested in discrediting you or making money • State actors, who may be interested in stealing secrets or disrupting your business 2 | Chapter 1: Principles and Concepts

2 I recommend Threat Modeling: Designing for Security, by Adam Shostack (Wiley). To borrow a technique from the world of user experience design, you may want to imagine a member of each applicable group, give them a name, jot down a little about that “persona” on a card, and keep the cards visible when designing your defenses. The second thing you have to do is figure out what needs to talk to what in your application, and the easiest way to do that is to draw a picture and figure out where your weak spots are likely to be. There are entire books on how to do this,2 but you don’t need to be an expert to draw something useful enough to help you make deci‐ sions. However, if you are in a high-risk environment, you should probably create formal diagrams with a suitable tool rather than draw stick figures. Although there are many different application architectures, for the sample applica‐ tion used for illustration here, I will show a simple three-tier design. Here is what I recommend: 1. Draw a stick figure and label it “user.” Draw another stick figure and label it “administrator” (Figure 1-1). You may find later that you have multiple types of users and administrators, or other roles, but this is a good start. Figure 1-1. User and administrator roles 2. Draw a box for the first component the user talks to (for example, the web servers), draw a line from the user to that first component, and label the line with how the user talks to that component (Figure 1-2). Note that at this point, the component may be a serverless function, a container, a virtual machine, or some‐ thing else. This will let anyone talk to it, so it will probably be the first thing to go. We really don’t want the other components trusting this one more than neces‐ sary. Threat Actors, Diagrams, and Trust Boundaries | 3

Figure 1-2. First component 3. Draw other boxes behind the first for all of the other components that first sys‐ tem has to talk to, and draw lines going to those (Figure 1-3). Whenever you get to a system that actually stores data, draw a little symbol (I use a cylinder) next to it and jot down what data is there. Keep going until you can’t think of any more boxes to draw for your application. Figure 1-3. Additional components 4. Now draw how the administrator (and any other roles you’ve defined) accesses the application. Note that the administrator may have several different ways of talking to this application; for example, via the cloud provider’s portal or APIs, or through the operating system access, or by talking to the application similarly to how a user accesses it (Figure 1-4). Figure 1-4. Administrator access 4 | Chapter 1: Principles and Concepts

5. Draw some trust boundaries as dotted lines around the boxes (Figure 1-5). A trust boundary means that anything inside that boundary can be at least some‐ what confident of the motives of anything else inside that boundary, but requires verification before trusting anything outside of the boundary. The idea is that if an attacker gets into one part of the trust boundary, it’s reasonable to assume they’ll eventually have complete control over everything in it, so getting through each trust boundary should take some effort. Note that I drew multiple web servers inside the same trust boundary; that means it’s okay for these web servers to trust each other completely, and if someone has access to one, they effectively have access to all. Or, to put it another way, if someone compromises one of these web servers, no further damage will be done by having them all compromised. Figure 1-5. Component trust boundaries 6. To some extent, we trust our entire system more than the rest of the world, so draw a dotted line around all of the boxes, including the admin, but not the user (Figure 1-6). Note that if you have multiple admins, like a web server admin and a database admin, they might be in different trust boundaries. The fact that there are trust boundaries inside of trust boundaries shows the different levels of trust. For example, the servers here may be willing to accept network connections from servers in other trust boundaries inside the application, but still verify their iden‐ tities. They may not even be willing to accept connections from systems outside of the whole application trust boundary. Threat Actors, Diagrams, and Trust Boundaries | 5

Figure 1-6. Whole application trust boundary We’ll use this diagram of an example application throughout the book when discus‐ sing the shared responsibility model, asset inventory, controls, and monitoring. Right now, there are no cloud-specific controls shown in the diagram, but that will change as we progress through the chapters. Look at any place a line crosses a trust boundary. These are the places we need to focus on securing first! Cloud Delivery Models There is an unwritten law that no book on cloud computing is complete without an overview of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Soft‐ ware as a Service (SaaS). Rather than the standard overview, I’d like to point out that these service models are useful only for a general understanding of concepts; in par‐ ticular, the line between IaaS and PaaS is becoming increasingly blurred. Is a content delivery network (CDN) service that caches information for you around the internet to keep it close to users a PaaS or IaaS? It doesn’t really matter. What’s important is that you understand what is (and isn’t!) provided by the service, not whether it fits neatly into any particular category. The Cloud Shared Responsibility Model The most basic security question you must answer is, “What aspects of security am I responsible for?” This is often answered implicitly in an on-premises environment. The development organization is responsible for code errors, and the operations organization (IT) is responsible for everything else. Many organizations now run a DevOps model where those responsibilities are shared, and team boundaries between development and operations are blurred or nonexistent. Regardless of how it’s organ‐ ized, almost all security responsibility is inside the company. 6 | Chapter 1: Principles and Concepts

3 Original concept from an article by Albert Barron. Perhaps one of the most jarring changes when moving from an on-premises environ‐ ment to a cloud environment is a more complicated shared responsibility model for security. In an on-premises environment, you may have had some sort of internal document of understanding or contract with IT or some other department that ran servers for you. However, in many cases business users of IT were used to handing the requirements or code to an internal provider and having everything else done for them, particularly in the realm of security. Even if you’ve been operating in a cloud environment for a while, you may not have stopped to think about where the cloud provider’s responsibility ends and where yours begins. This line of demarcation is different depending on the types of cloud service you’re purchasing. Almost all cloud providers address this in some way in their documentation and education, but the best way to explain it is to use the anal‐ ogy of eating pizza. With Pizza-as-a-Service,3 you’re hungry for pizza. There are a lot of choices! You could just make a pizza at home, although you’d need to have quite a few ingredients and it would take a while. You could run up to the grocery store and grab a take-and- bake; that only requires you to have an oven and a place to eat it. You could call your favorite pizza delivery place. Or, you could just go sit down at a restaurant and order a pizza. If we draw a diagram of the various components and who’s responsible for them, we get something like Figure 1-7. The traditional on-premises world is like making a pizza at home. You have to buy a lot of different components and put them together yourself, but you get complete flexibility. Anchovies and cinnamon on wheat crust? If you can stomach it, you can make it. When you use Infrastructure as a Service, though, the base layer is already done for you. You can bake it to taste and add a salad and drinks, and you’re responsible for those things. When you move up to Platform as a Service, even more decisions are already made for you, and you just use that service as part of developing your overall solution. (As mentioned in the previous section, sometimes it can be difficult to cate‐ gorize a service as IaaS or PaaS, and they’re growing together in many cases. The exact classification isn’t important; what’s important is that you understand what the service provides and what your responsibilities are.) When you get to Software as a Service (compared to dining out in Figure 1-7), it seems like everything is done for you. It’s not, though. You still have a responsibility to eat safely, and the restaurant is not responsible if you choke on your food. In the SaaS world, this largely comes down to managing access control properly. The Cloud Shared Responsibility Model | 7