Practical Cloud Security A Guide for Secure Design and Deployment, 2nd Edition (Chris Dotson) (z-library.sk, 1lib.sk, z-lib.sk)

D otson Pra ctica l C loud Security Pra ctica l C loud Security Chris Dotson Practical Cloud Security A Guide for Secure Design and Deployment Second Edition

CLOUD COMPUTING “In Practical Cloud Security, Chris Dotson expertly navigates the complex world of shared responsibilities in cloud systems, particularly as they pertain to sensitive sectors like healthcare. Using a straightforward yet thorough approach, this second edition offers essential strategies for protecting data and applications in the cloud. It is a must- read for students and professionals aiming to strengthen their skills in cloud security.” —Amir Bahmani, PhD Stanford lecturer and Director of Stanford Deep Data Research Center Practical Cloud Security Twitter: @oreillymedia linkedin.com/company/oreilly-media youtube.com/oreillymedia With rapidly changing architecture and API-driven automation, cloud platforms come with unique security challenges and opportunities. In this updated second edition, you’ll examine security best practices for multivendor cloud environments, whether your company plans to move legacy on-premises projects to the cloud or build a new infrastructure from the ground up. Developers, IT architects, and security professionals will learn cloud-specific techniques for securing popular cloud platforms such as Amazon Web Services, Microsoft Azure, and IBM Cloud. IBM Distinguished Engineer Chris Dotson shows you how to establish data asset management, identity and access management (IAM), vulnerability management, network security, and incident response in your cloud environment. • Learn the latest threats and challenges in the cloud security space • Manage cloud providers that store or process data or deliver administrative control • Learn how standard principles and concepts—such as least privilege and defense in depth—apply in the cloud • Understand the critical role played by IAM in the cloud • Use best tactics for detecting, responding, and recovering from the most common security incidents • Manage various types of vulnerabilities, especially those common in multicloud or hybrid cloud architectures • Examine privileged access management in cloud environments Chris Dotson is an IBM Distinguished Engineer and an executive security architect in the IBM CIO organization. He has 11 professional certifications, including the Open Group Distinguished IT Architect certification, and over 25 years of experience in the IT industry. US $49.99 CAN $62.99 ISBN: 978-1-098-14817-1

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

978-1-098-14817-1 [LSI] Practical Cloud Security by Chris Dotson Copyright © 2024 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: Megan Laddusaw Development Editor: Rita Fernando Production Editor: Clare Laylock Copyeditor: Liz Wheeler Proofreader: Rachel Head Indexer: WordCo Indexing Services, Inc. Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea March 2019: First Edition October 2023: Second Edition Revision History for the Second Edition 2023-10-06: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098148171 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 2 Defense in Depth 2 Zero Trust 3 Threat Actors, Diagrams, and Trust Boundaries 4 Cloud Service Delivery Models 8 The Cloud Shared Responsibility Model 8 Risk Management 12 Conclusion 13 Exercises 15 2. Data Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Data Identification and Classification 17 Example Data Classification Levels 18 Relevant Industry or Regulatory Requirements 19 Data Asset Management in the Cloud 21 Tagging Cloud Resources 22 Protecting Data in the Cloud 23 Tokenization 23 Encryption 24 Conclusion 31 Exercises 33 3. Cloud Asset Management and Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Differences from Traditional IT 35 Types of Cloud Assets 36 iii

Compute Assets 37 Storage Assets 43 Network Assets 48 Asset Management Pipeline 49 Procurement Leaks 50 Processing Leaks 51 Tooling Leaks 52 Findings Leaks 52 Tagging Cloud Assets 52 Conclusion 54 Exercises 56 4. Identity and Access Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Differences from Traditional IT 59 Life Cycle for Identity and Access 60 Request 62 Approve 62 Create, Delete, Grant, or Revoke 63 Authentication 63 Cloud IAM Identities 63 Business-to-Consumer and Business-to-Employee 64 Multi-Factor Authentication 65 Passwords, Passphrases, and API Keys 68 Shared IDs 70 Federated Identity 71 Single Sign-On 71 Instance Metadata and Identity Documents 73 Secrets Management 75 Authorization 79 Centralized Authorization 80 Roles 81 Revalidate 82 Putting It All Together in the Sample Application 85 Conclusion 87 Exercises 89 5. Vulnerability Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Differences from Traditional IT 92 Vulnerable Areas 94 Data Access 95 Application 95 Middleware 98 iv | Table of Contents

Operating System 99 Network 100 Virtualized Infrastructure 100 Physical Infrastructure 100 Finding and Fixing Vulnerabilities 101 Network Vulnerability Scanners 102 Agentless Scanners and Configuration Management Systems 104 Agent-Based Scanners and Configuration Management Systems 105 Cloud Workload Protection Platforms 107 Container Scanners 107 Dynamic Application Scanners (DAST) 108 Static Application Scanners (SAST) 108 Software Composition Analysis Tools (SCA) 109 Interactive Application Scanners (IAST) 109 Runtime Application Self-Protection Scanners (RASP) 109 Manual Code Reviews 110 Penetration Tests 110 User Reports 112 Example Tools for Vulnerability and Configuration Management 112 Risk Management Processes 115 Vulnerability Management Metrics 115 Tool Coverage 116 Mean Time to Remediate 116 Systems/Applications with Open Vulnerabilities 117 Percentage of False Positives 117 Percentage of False Negatives 117 Vulnerability Recurrence Rate 118 Change Management 118 Putting It All Together in the Sample Application 119 Conclusion 123 Exercises 124 6. Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Differences from Traditional IT 125 Concepts and Definitions 127 Zero Trust Networking 127 Allowlists and Denylists 127 DMZs 129 Proxies 129 Software-Defined Networking 130 Network Functions Virtualization 130 Overlay Networks and Encapsulation 130 Table of Contents | v

Virtual Private Clouds 131 Network Address Translation 132 IPv6 133 Network Defense in Action in the Sample Application 134 Encryption in Motion 135 Firewalls and Network Segmentation 138 Allowing Administrative Access 144 Network Defense Tools 148 Egress Filtering 152 Data Loss Prevention 155 Conclusion 156 Exercises 158 7. Detecting, Responding to, and Recovering from Security Incidents. . . . . . . . . . . . . . . 161 Differences from Traditional IT 162 What to Watch 163 Privileged User Access 165 Logs from Defensive Tooling 167 Cloud Service Logs and Metrics 170 Operating System Logs and Metrics 171 Middleware Logs 172 Secrets Server 172 Your Application 172 How to Watch 173 Aggregation and Retention 174 Parsing Logs 175 Searching and Correlation 176 Alerting and Automated Response 176 Security Information and Event Managers 177 Threat Hunting 179 Preparing for an Incident 179 Team 180 Plans 181 Tools 183 Responding to an Incident 185 Cyber Kill Chains and MITRE ATT&CK 185 The OODA Loop 187 Cloud Forensics 188 Blocking Unauthorized Access 189 Stopping Data Exfiltration and Command and Control 189 Recovery 189 Redeploying IT Systems 189 vi | Table of Contents

Notifications 190 Lessons Learned 190 Example Metrics 190 Example Tools for Detection, Response, and Recovery 191 Detection and Response in a Sample Application 192 Monitoring the Protective Systems 193 Monitoring the Application 194 Monitoring the Administrators 195 Understanding the Auditing Infrastructure 195 Conclusion 196 Exercises 198 Appendix. Exercise Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 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. This is primarily a book about security, not compliance. That said, if you need to meet specific compliance requirements, such as PCI DSS, HIPAA, or FedRAMP, you will find some limited guidance on designing your security controls so that you will be able to do so. Who Should Read This Book This book is designed as an intermediate-level resource and is intended primarily for two types of practitioners: ix

• Those who have some experience with securing on-premises environments, but little or no experience with cloud environments • Those who have experience building cloud environments, but little or no experi‐ ence with securing those cloud environments The goal of this book is to provide a conceptual-level understanding of the “art of the possible” in cloud security. You won’t find a cookbook-style guide on exactly how to implement various controls in specific cloud environments, for a few reasons. One is that such guides tend to become out of date very quickly, because cloud providers are constantly improving their implementations. Another is that the cloud providers gen‐ erally do a better job of providing explicit how-to guides than I can, because the implementations are specific to the way they’ve designed their services. A detailed how-to guide by one cloud provider will be more useful than a generic how-to that tries to cover multiple cloud providers. What I try to provide is the understanding of when you need to find such a guide and use it. Navigating This Book The first three chapters deal with understanding your responsibilities in the cloud and how they differ from those in on-premises environments, as well as understand‐ ing what assets you have, what the most likely threats to those assets are, and some protections for them. Chapters 4 through 6 provide practical guidance, in priority order, of the most important security controls that you should consider first: • Identity and access management • Vulnerability management • 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! What’s New in the Second Edition This new edition has been updated based on developments in the cloud computing and security industries in the years since the release of the first edition. Some exam‐ ples are: • More information on zero trust principles as they apply to protecting cloud environments x | Preface

• Advancements in encryption techniques, such as quantum-resistant encryption algorithms • Advancements in authentication techniques, such as passwordless technologies and passkeys • The use of privileged access management tools to protect cloud environments • Verification of workload identities in addition to human identities • The importance of protecting software supply chains, including build and deployment environments in the cloud, with transparency through a Software Bill of Materials (SBOM) • Updates based on changes to offerings by major cloud providers since the previ‐ ous publication • Updated examples of the different types of defensive tools and technologies avail‐ able today In addition, you can now check your newfound understanding of cloud security con‐ cepts as you read. I have added some questions and exercises to the end of each chap‐ ter, and the answers are in the Appendix. 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. Preface | xi

This element signifies a general note. 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-889-8969 (in the United States or Canada) 707-829-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://www.oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/PracticalCloudSecurity2e. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media. xii | Preface

Follow us on Twitter: https://twitter.com/oreillymedia. Watch us on YouTube: https://youtube.com/oreillymedia. 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 first edition editors, Andy Oram and Courtney Allen; my second edition editors, Rita Fernando and Megan Laddusaw; my first edition reviewers, Hans Donker, Darren Day, and Edgar Ter Dan‐ ielyan; my second edition reviewers, Lee Atchison, Karan Dwivedi, and Akhil Behl; 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. Preface | xiii

CHAPTER 1 Principles and Concepts Yes, this is a practical guide, but we do need to cover a few cloud-relevant security principles and concepts at a high level before we dive into the practical bits. If you’re a seasoned security professional, but new to the cloud, you may want to skim down to “The Cloud Shared Responsibility Model” on page 8. The reason for covering these principles and concepts first is because they are used implicitly throughout the rest of the book when I discuss designing and implement‐ ing security controls to stop attackers. Conceptual gaps and misunderstandings in security can cause lots of issues. For example: • If you’re not familiar with least privilege, you may understand authorization for cloud services well, but still grant too much access to people or automation in your cloud account or on a cloud database with sensitive information. • If you’re not familiar with defense in depth, then having multiple layers of authentication, network access control, or encryption may not seem useful. • If you don’t know a little about threat modeling—the likely motivations of attack‐ ers, and the trust boundaries of the system that you’re designing—you may be spending time and effort protecting the wrong things. • If you don’t understand the cloud service delivery models and the shared respon‐ sibility model, you may spend time worrying about risks that are your cloud pro‐ vider’s responsibility and miss risks that are your responsibility to address. • If you don’t know a little about risk management, you may spend too much time and effort on low risks rather than managing your higher risks. I’ll cover this foundational information quickly so that we can get to cloud security controls. 1

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. 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 and skilled 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. However, 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 unacceptable, you probably have insufficient defense in depth. You may also have insufficient defense in depth if a single failure can make several of your security controls ineffective, such as an inventory issue that causes multiple tools to miss a problem. 2 | Chapter 1: Principles and Concepts

1 If you’re expecting tips on how to pick catchy marketing names, you’re probably reading the wrong book! Zero Trust Many products and services today claim to be zero trust, or to support zero trust principles. The name is confusing, because zero trust does not mean a complete lack of trust in anything, and the confusion is worse because it’s used for so many different marketing purposes. There are many different definitions and different ideas about what is meant by zero trust. We are probably stuck with the term at this point, but “zero trust” should really be called something else, such as “zero implicit trust” or “zero assumed trust without a good reason.”1 The core principle is that trust from a user or another system should be earned, rather than given simply because the user is able to reach you on the net‐ work, or has a company-owned device, or some other criterion that’s not well controlled. The implementation of zero trust will differ widely depending on whether you’re talk‐ ing about trusting devices, network connections, or something else. One commonly used implementation of zero trust is requiring encryption and authentication for all connections, even ones that originate and terminate in supposedly trusted networks. This was always a good idea, but it’s even more important in cloud environments where the perimeter is less strictly designed and internet connectivity is easy. Another common implementation of zero trust principles is limiting users’ network access to only the applications that they need, challenging the implicit trust that all users should be able to connect to all applications, even if they cannot log in. If you think this sounds a lot like least privilege and defense in depth, you’re right. There is considerable overlap between zero trust principles and some of the other principles in this chapter. A third example of zero trust is the use of multi-factor authentication of users, with reauthentication required either periodically or when higher-risk transactions are requested. In this case, we’re challenging the implicit trust that whoever has the pass‐ word for an account, or controls a particular session for an application, is the intended user. When following zero trust principles, you should only trust an interaction if you have strong evidence that the trust is warranted, such as by proof of strong authentication, or authorization, or correct configuration. That evidence should either be from some‐ thing you directly control (such as your own authentication system or device man‐ agement system), or from some third party that you have explicitly evaluated as competent to make trust decisions for you. Like other principles in this chapter, it can be disruptive to the user experience if taken to extremes. Zero Trust | 3

2 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. 3 I recommend Threat Modeling: Designing for Security, by Adam Shostack (Wiley, 2014). 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 cyber-criminal can make money by stealing your data, or where a “hackti‐ vist” might want to deface your website for political or social reasons. Keep these peo‐ ple 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,2 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 to advance a foreign government’s political mission or cause 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,3 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. 4 | Chapter 1: Principles and Concepts