Cloud Native Security Cookbook Recipes for a Secure Cloud (Josh Armitage) (Z-Library)

📄 File Format: PDF

💾 File Size: 6.1 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

Josh Armitage Cloud Native Security Cookbook Recipes for a Secure Cloud

📄 Page 2

CLOUD COMPUTING / SECURIT Y “An essential guide to securing the cloud. Organizations running workloads at the scale their customers demand need cloud security. This book contains essential recipes that will set them up for success and allow them to scale securely.“ —JK Gunnink Google Cloud developer expert “A must-read for anyone working or trying to get into cloud security. Josh does a great job of showing how to implement various components of a secure cloud environment all through the power of Terraform.” —Marcus Maxwell Security Practice Lead, Contino Cloud Native Security Cookbook ISBN: 978-1-098-10630-0 US $59.99 CAN $74.99 Twitter: @oreillymedia linkedin.com/company/oreilly-media youtube.com/oreillymedia With the rise of the cloud, every aspect of IT has been shaken to its core. The fundamentals for building systems are changing, and although many of the principles that underpin security still ring true, their implementation has become unrecognizable. This practical book provides recipes for AWS, Azure, and GCP to help you enhance the security of your own cloud native systems. Based on his hard-earned experience working with some of the world’s biggest enterprises and rapidly iterating startups, consultant Josh Armitage covers the trade-offs that security professionals, developers, and infrastructure gurus need to make when working with different cloud providers. Each recipe discusses the inherent compromises, as well as where clouds have similarities and where they’re fundamentally different. • Learn how the cloud provides superior security to what was achievable in an on-premises world • Understand the principles and mental models that enable you to make optimal trade-offs as part of your solution • Learn how to implement existing solutions that are robust and secure, and devise design solutions to new and interesting problems • Deal with security challenges and solutions both horizontally and vertically within your business Josh Armitage has been plying his trade as a consultant to enterprises and startups for many years. He’s seen security from many angles and has wide and deep technology expertise that includes writing production assembly on mainframes and operating a globally distributed machine learning system. Josh now focuses on cloud native technologies, lean software development, and taking teams through DevSecOps transformations.

📄 Page 3

Josh Armitage Cloud Native Security Cookbook Recipes for a Secure Cloud

📄 Page 4

978-1-098-10630-0 [LSI] Cloud Native Security Cookbook by Josh Armitage Copyright © 2022 Joshua Hagen Armitage. 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: Jennifer Pollock Development Editor: Corbin Collins Production Editor: Jonathon Owen Copyeditor: Sonia Saruba Proofreader: Piper Editorial Consulting, LLC Indexer: Judith McConville Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea April 2022: First Edition Revision History for the First Edition 2022-04-20: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098106300 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Cloud Native Security Cookbook, 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. This work is part of a collaboration between O’Reilly and Palo Alto Networks. See our statement of edito‐ rial independence.

📄 Page 5

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1. Security in the Modern Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Why Security Is Critical 1 1.2 What Is Meant by Cloud Native Security? 3 1.3 Where Security Fits in the Modern Organization 5 1.4 The Purpose of Modern Security 7 1.5 DevSecOps 7 1.6 How to Measure the Impact of Security 12 1.7 The Principles of Security 14 2. Setting Up Accounts and Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1 Scalable Project Structures on GCP 19 2.2 Scalable Account Structures on AWS 27 2.3 Scalable Subscription Structures on Azure 35 2.4 Region Locking on GCP 40 2.5 Region Locking on AWS 43 2.6 Region Locking on Azure 47 2.7 Centralizing Users on GCP 49 2.8 Centralizing Users on AWS 54 2.9 Centralizing Users on Azure 58 3. Getting Security Visibility at Scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.1 Building a Cloud Native Security Operations Center on GCP 64 3.2 Building a Cloud Native Security Operations Center on AWS 71 3.3 Building a Cloud Native Security Operations Center on Azure 75 3.4 Centralizing Logs on GCP 78 3.5 Centralizing Logs on AWS 82 iii

📄 Page 6

3.6 Centralizing Logs on Azure 88 3.7 Log Anomaly Alerting on GCP 94 3.8 Log Anomaly Alerting on AWS 98 3.9 Log Anomaly Alerting on Azure 102 3.10 Building an Infrastructure Registry on GCP 106 3.11 Building an Infrastructure Registry on AWS 110 3.12 Building an Infrastructure Registry on Azure 118 4. Protecting Your Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.1 Encrypting Data at Rest on GCP 124 4.2 Encrypting Data at Rest on AWS 129 4.3 Encrypting Data at Rest on Azure 137 4.4 Encrypting Data on GCP with Your Own Keys 143 4.5 Encrypting Data on AWS with Your Own Keys 147 4.6 Encrypting Data on Azure with Your Own Keys 151 4.7 Enforcing In-Transit Data Encryption on GCP 156 4.8 Enforcing In-Transit Data Encryption on AWS 160 4.9 Enforcing In-Transit Data Encryption on Azure 162 4.10 Preventing Data Loss on GCP 165 4.11 Preventing Data Loss on AWS 170 4.12 Preventing Data Loss on Azure 174 5. Secure Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 5.1 Networking Foundations on GCP 182 5.2 Networking Foundations on AWS 188 5.3 Networking Foundations on Azure 195 5.4 Enabling External Access on GCP 203 5.5 Enabling External Access on AWS 208 5.6 Enabling External Access on Azure 214 5.7 Allowing Access to Internal Resources on GCP 219 5.8 Allowing Access to Internal Resources on AWS 225 5.9 Allowing Access to Internal Resources on Azure 231 5.10 Controlling External Network Connectivity on GCP 236 5.11 Controlling External Network Connectivity on AWS 243 5.12 Controlling External Network Connectivity on Azure 251 5.13 Private Application Access on GCP 257 5.14 Private Application Access on AWS 265 5.15 Private Application Access on Azure 272 6. Infrastructure as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 6.1 Building Secure Infrastructure Defaults on GCP 278 6.2 Building Secure Infrastructure Defaults on AWS 282 iv | Table of Contents

📄 Page 7

6.3 Building Secure Infrastructure Defaults on Azure 288 6.4 Functions as a Service on GCP 294 6.5 Functions as a Service on AWS 299 6.6 Functions as a Service on Azure 303 6.7 Robust Deployment on GCP 309 6.8 Robust Deployment on AWS 314 6.9 Robust Deployment on Azure 322 6.10 Deployment at Scale on GCP 329 6.11 Deployment at Scale on AWS 331 6.12 Deployment at Scale on Azure 336 7. Compliance as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 7.1 Labeling Resources on GCP 342 7.2 Tagging Resources on AWS 347 7.3 Tagging Resources on Azure 352 7.4 Detecting Noncompliant Infrastructure on GCP 357 7.5 Detecting Noncompliant Infrastructure on AWS 364 7.6 Detecting Noncompliant Infrastructure on Azure 369 7.7 Preventing Noncompliant Infrastructure on GCP 375 7.8 Preventing Noncompliant Infrastructure on AWS 379 7.9 Preventing Noncompliant Infrastructure on Azure 383 7.10 Remediating Noncompliant Infrastructure on GCP 388 7.11 Remediating Noncompliant Infrastructure on AWS 396 7.12 Remediating Noncompliant Infrastructure on Azure 400 8. Providing Internal Security Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 8.1 Protecting Security Assets and Controls on GCP 408 8.2 Protecting Security Assets and Controls on AWS 412 8.3 Protecting Security Assets and Controls on Azure 417 8.4 Understanding Machine Status at Scale on GCP 422 8.5 Understanding Machine Status at Scale on AWS 426 8.6 Understanding Machine Status at Scale on Azure 430 8.7 Patching at Scale on GCP 435 8.8 Patching at Scale on AWS 439 8.9 Patching at Scale on Azure 442 8.10 Data Backup on GCP 447 8.11 Data Backup on AWS 451 8.12 Data Backup on Azure 456 9. Enabling Teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 9.1 Enabling Project Sharing on GCP 462 9.2 Enabling Account Sharing on AWS 465 Table of Contents | v

📄 Page 8

9.3 Enabling Resource Group Sharing on Azure 468 9.4 Application Security Scanning on GCP 472 9.5 Application Security Scanning on AWS 475 9.6 Application Security Scanning on Azure 479 10. Security in the Future. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 10.1 The Infinite Game 484 10.2 Building Capability 484 10.3 Building Situational Awareness 486 10.4 Conclusion 488 11. Terraform Primer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 11.1 Authenticating with GCP 490 11.2 Authenticating with AWS 490 11.3 Authenticating with Azure 490 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 vi | Table of Contents

📄 Page 9

Preface 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 general note. This element indicates a warning or caution. vii

📄 Page 10

Using Code Examples Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/Armitagency/cloud-native-security-cookbook-tf. If you have a technical question or a problem using the code examples, please send email to bookquestions@oreilly.com. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require per‐ mission. We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Cloud Native Security Cookbook by Josh Armitage (O’Reilly). Copyright 2022 Joshua Hagen Armitage, 978-1-098-10630-0.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, 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, 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 viii | Preface

📄 Page 11

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 webpage for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/cloudNativeCkbk. Email bookquestions@oreilly.com to comment or ask technical questions about this book. For news and information about our books and courses, visit http://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Acknowledgments This book stands upon the shoulders of other people’s ideas and knowledge. I am indebted to the many people who have readily shared their expertise so that we can explore further and higher rather than continually relearn the same lessons. Above the main coworking space in my home city of Perth is the Greek proverb “A society grows great when old men plant trees whose shade they know they shall never sit in,” an ideal I try to hold close. I truly feel that everyone has valuable stories to share. Wherever you are on your journey, there are people behind you or next to you on their own journey who could benefit from your experience. This book is my attempt to help people develop safer systems, protect their users, and have a more ful‐ filling and happier working life. Having spent a number of years consulting with the world’s biggest enterprises, I have firsthand experience of both the pains and triumphs that come with digital and cloud transformation, especially in the security domain. This book is a distillation of those days in the trenches, with a bias for action that is imperative for real change to happen. Working with computers was almost preordained for me, as it seems the occupation of choice for my family. My father and I both got jobs as mainframe developers straight out of university about 30 years apart, much to his enjoyment when he found out. I started writing this book while in lockdown in the UK, attempting to find a project to help keep me sane. I finished it in Australia just before my daughter was due to arrive. I couldn’t have finished this book without the never-ending support of my Preface | ix

📄 Page 12

wife, Rebecca, who has had to deal with many late nights and weekends of me ham‐ mering the keyboard. In the end, the timing could not have worked out better as I move on from this herculean labor to being a father. Thank you to my triumvirate of tech reviewers who have challenged me and kept me honest through the book, Marcus Maxwell, JK Gunnink, and Pete Yandell. Your hours spent dissecting my writing has taken the book to a higher level and I am for‐ ever grateful. To the amazing staff at O’Reilly, especially Corbin Collins for supporting me through‐ out this endeavor, Jennifer Pollock for giving me the chance to write this book, and the production team, thank you for having the requisite patience and ensuring that this book became a reality. It’s hard to imagine this book existing were it not for the support of each and every one of you. x | Preface

📄 Page 13

CHAPTER 1 Security in the Modern Organization In this chapter, you will learn the following: • Why security is becoming ever more critical in the modern age • What is meant by cloud native security • Where security fits in the modern organization • What the purpose of security is • What DevSecOps really is • How to measure the impact of security • The underlying principles of security This foundation is critical for you to compellingly articulate why investment into security is and will continue to be mandatory and how the advent of the cloud has not invalidated the fundamental principles of security but has transformed how they are applied. 1.1 Why Security Is Critical Seeing as you’re reading this, you probably already believe in the criticality of secu‐ rity; however, it’s important to understand how security continues to be ever more important day to day and year to year. Life in the 21st century is digital first—our lives revolve around the internet and tech‐ nology. Everyone’s personal information is given to and stored by trusted third par‐ ties. We all believe that it will be handled safely and securely. What recent history has shown us, however, is that security breaches are the norm; they are to be expected. 1

📄 Page 14

This information is the gold filling the 21st-century bank vaults of technology titans. Where you have concentrations of wealth, you must scale your security to match. Human instinct makes us believe that to go slowly is to go safely, which often mani‐ fests as lengthy security assessments, full multiweek penetration tests on every release, and security being the slowest moving part on the path to production. This is actively harmful in two ways. First, the systems that businesses operate are inherently complex. Complexity theory and other models of complexity, such as the Cynefin framework, shown in Figure 1-1, teach us that it is impossible to think our way through a complex system. No amount of reading code and looking at architec‐ ture diagrams can allow you to fully understand all the possibilities and potential vul‐ nerabilities within a system. Being able to react and apply fixes quickly when issues are discovered, such as the Log4j vulnerability in December 2021, results in a supe‐ rior security posture when compared to lengthy, time-intensive review cycles. Figure 1-1. Cynefin framework But even if it were possible with sufficient time to root out all security vulnerabilities, for a business, moving slowly in the 21st century is a recipe for disaster. The level of expectation set by the Googles, Microsofts, and Amazons of the world has laid down a gauntlet. Move fast or die. Security teams are caught between two unstoppable forces: the business imperative for agility through speed and the exponential growth in breach impacts. When a breach happens, the business suffers in a number of ways, to name but a few: • Reputational damage • Legal liabilities • Fines and other financial penalties • Operational instability and loss of revenue • Loss of opportunity 2 | Chapter 1: Security in the Modern Organization

📄 Page 15

The vast majority of businesses are either already in the cloud or are exploring how they can migrate their estates. With the near ubiquity of cloud infrastructure, both governments and regulators are investing significantly in their understanding of how companies are using the cloud. Examples such as the General Data Protection Regu‐ lation (GDPR) and the California Consumer Privacy Act are just the tip of a wave of increased security expectations, controls, and scrutiny. Over time, the damage suf‐ fered by a business from a breach will exponentially and catastrophically increase. Our principles of security are not invalidated by this new reality, but how they are applied, embedded, and upheld needs to fundamentally transform. 1.2 What Is Meant by Cloud Native Security? A common trope of the technology industry is that definitions become loose over time. In this book, cloud native is defined as leveraging technology purpose-built to unlock the value of, and accelerate your adoption of, the cloud. Here is a list of common properties of cloud native solutions: • It is automation friendly and should be fully configurable through infrastructure as code (IaC). • It does not place unnecessary, artificial constraints on your architecture. For example, per machine pricing is not considered a cloud native pricing model. • It elastically scales. As your systems and applications grow in size, the solution scales in lockstep. • It natively supports the higher-level compute offerings on the cloud platforms. It should support serverless and containerized workloads, as well as the plethora of managed service offerings. In this book, where possible, the recipes use the managed services provided by the cloud platforms themselves. They have all the previous properties, are purpose-built to support customers in their cloud journey, and are easily integrated into your estate. IT security has existed from the day there was something of value stored on a com‐ puter. As soon as things of value were stored on computers, it was necessary to defend them. As an industry, IT has proven the ability to undergo seismic shifts with frightening regularity; embracing cloud native is simply the most recent. As more value is poured into technology and systems, the potential value to be gained by attacking them increases, therefore our security must increase in kind. The cloud can bring so much good, but with it comes new challenges that will need cloud native people, processes, and tools to overcome. 1.2 What Is Meant by Cloud Native Security? | 3

📄 Page 16

The Beginnings of the Cloud Back in 2006, Amazon first announced Amazon Web Services (AWS), offering pay- as-you-go technology to businesses. Over the intervening 15 years, a tectonic shift fundamentally altered how companies approach technology. Historically, businesses ordered and managed hardware themselves, investing huge sums of capital up front and employing large teams to perform “undifferentiated heavy lifting” to operate this infrastructure. What Amazon started, followed in 2008 by Google and 2010 by Microsoft, allowed businesses to provision new infrastructure on demand in seconds, as opposed to waiting months for the hardware to arrive and be racked, configured, and released for use. Infrastructure became a commodity, like water or electricity. This enabled businesses to rapidly experiment, become more agile, and see technology as a business differen‐ tiator rather than a cost center. Over time, the cornucopia of services offered by the Cloud Service Providers (CSPs) has grown to encompass almost everything a busi‐ ness could need, with more being released every day. Nearly every company on the planet, including the most ancient of enterprises, is cloud first. The cloud is here to stay and will fundamentally define how businesses consume technology in the future. Old Practices in the New Reality When something as transformational as cloud computing occurs, best practices require time to emerge. In the intervening gap, old practices are applied to the new reality. The security tools and processes which served us well in the pre-cloud age were not built to contend with the new normal. The pace of change posed by the cloud presented new security challenges the industry was not equipped to face. Through effort, time, and experimentation, it is now understood how to achieve our security objectives by working with, not against, the cloud. You can now have cloud native security. Cloud native security is built around the following fundamental advantages of cloud computing: Pay for consumption In a cloud native world, expect to only pay for services as you use them, not for idle time. Economies of scale As the CSP is at hyperscale, it can achieve things which cannot be done in isola‐ tion, including lower pricing, operational excellence, and superior security postures. 4 | Chapter 1: Security in the Modern Organization

📄 Page 17

No capacity planning Cloud resources are made to be elastic; they can scale up and down based on demand rather than having to go through the effort-intensive and often inaccu‐ rate process of capacity planning. Unlock speed and agility By allowing companies and teams to rapidly experiment, change their mind, and move quickly, the cloud allows for capturing business value that would be impos‐ sible otherwise. Stop spending money on “undifferentiated heavy lifting” Rather than focus on activities that cannot differentiate you from your competi‐ tion, allow the CSP to focus on those tasks while you focus on core competencies. Span the globe The CSP allows businesses to scale geographically on demand by having loca‐ tions all over the world that operate identically When you look at the processes and tools that constitute cloud native security, you enable the consumption and promised benefits of the cloud, not constrain them. 1.3 Where Security Fits in the Modern Organization Historically, security has operated as a gatekeeper, often as part of change advisory boards (CABs), acting as judge, jury, and executioner for system changes. This siloed approach can only take you so far. The waste incurred by long feedback loops, long lead times, and slow pace of change is incompatible with a digital-first reality. By looking to block rather than enable change, the security and delivery teams are forced into a state of eternal conflict, creating friction that breeds animosity and pre‐ vents the business from achieving its goals. Team Topologies, by Matthew Skelton and Manual Pais (IT Revolution Press), examines the four team archetypes that are fun‐ damental to exceptional technology performance: enabling teams, platform teams, complicated-subsystem teams, and stream-aligned teams, as shown in Figure 1-2. 1.3 Where Security Fits in the Modern Organization | 5

📄 Page 18

Figure 1-2. Team topologies Stream-aligned teams are how the business directly delivers value. They build the sys‐ tems and services that allow the business to function, interact with customers, and compete in the market. Complicated-subsystem teams look after systems that require their own deep domain expertise, such as a risk calculation system in an insurance company. Platform teams produce compelling internal products that accelerate stream-aligned teams, such as an opinionated cloud platform, which is the focus of Chapter 2. Enablement teams are domain specialists who look to impart their understanding of other teams within the business. Simply put, all other teams are there to enable the stream-aligned team. Security needs to operate as an enablement team; i.e., they are domain experts that actively collaborate with other teams. It is unrealistic and infeasible to expect that all engi‐ neers become security experts throughout a company, although it is not unrealistic or infeasible to expect and embed a base level of security competency in all engineers. Even in a highly automated world, developing systems is knowledge work—it is peo‐ ple who determine the success of your security initiatives. It is through this enablement lens that many of the recipes in this cookbook make the most sense. Through working with enterprises around the world, I have seen that the paradigm shift from gatekeeper to enabler can be difficult to undertake; the animosity and lack of trust between security and delivery built over many years are powerful inhibitors of change. However, to take full advantage of cloud native security, this shift must happen, or misaligned incentives will scupper any and all progress. 6 | Chapter 1: Security in the Modern Organization

📄 Page 19

1.4 The Purpose of Modern Security Security operates in the domain of risk. Perfect security is not a realistic or achievable goal; at any one time, you cannot provide services and be known to be immune to all threats. This reality is even borne out in how fines are handed out following breaches: a substantial percentage of the fine is negated if reasonable attempts have been made to prevent the breach. So, if you cannot achieve complete security, then what is your north star? What is your goal? At the macro level, your goal is to make commercially reasonable efforts to minimize the chance of security incidents. What is deemed commercially reasonable varies wildly among companies. Often, startups have a significantly higher risk tolerance for security than regulated enterprises, as common sense would lead us to predict. What is important to keep in mind is that this much lower risk tolerance does not mean that an enterprise cannot move as fast as a startup due to overbearing security con‐ cerns. Throughout this book you will see how, with the correct principles and recipes in place, you do not handicap your stream-aligned teams. At the micro level, your goal is to ensure that a single change does not present an intolerable amount of risk. Again, what is tolerable is highly context specific, but thankfully, techniques to minimize risk are often universal. Later in this chapter, as I discuss DevSecOps, I will drill into what properties of changes allow you to minimize the risk and how embracing a DevSecOps culture is required for aligning teams around security objectives. 1.5 DevSecOps Before I can dive into what DevSecOps is, you first need to understand its precursor, DevOps. What Is DevOps? At its heart, DevOps is a cultural transformation of software delivery. It is heavily influenced by lean theory and is most simply described as bringing together what his‐ torically were two disparate silos, development and operations, hence DevOps, or the commonly used soundbite, “You build it, you run it.” To put it into numbers, elite teams operating in a DevOps model do the following: • deploy code 208 times more frequently • deploy code 106 times faster • recover from incidents 2,604 times faster • make 1/7 the amount of changes that fail 1.4 The Purpose of Modern Security | 7

📄 Page 20

As you can see from the numbers, DevOps was revolutionary, not evolutionary, and DevSecOps has the same potential. Understanding these numbers is crucial for modern security as it allows for align‐ ment around a common set of constraints—security objectives need to be achieved without preventing teams from becoming elite performers. Being elite for lead time means that changes are in production within an hour, meaning that mandatory secu‐ rity tests that take a day to complete are incompatible with the future direction of the company. A classic example of this in the enterprise is a mandatory penetration test before every release; although the goal of the penetration test is valuable, the activity itself and its place in the process need to change. The increasingly popular approach of bug bounties is a potential replacement for penetration tests. These challenges that security teams are now facing are the same ones that operations teams faced at the birth of DevOps in the early 2000s. It’s crucial to set the context, as it leads to the right conversations, ideas, problems, and solutions to achieve the right outcomes. As you can see, the engineering and cul‐ tural principles needed to allow companies to merely survive today forces wide-scale changes in security, the reality of which is what the industry calls DevSecOps. Two of the seminal texts in DevOps, The Phoenix Project (by Gene Kim et al., IT Rev‐ olution Press) and The Unicorn Project (by Gene Kim, IT Revolution Press), elaborate “the Three Ways” and “the Five Ideals” as underlying principles. I’ll examine them briefly here as they also underpin DevSecOps. The Three Ways These are the Three Ways: Flow and Systems Thinking The first way tells us that you need to optimize for the whole system, not simply for one component. Local optimization can often come at the expense of the sys‐ tem as a whole, which leads us to the realization that the most secure system is not necessarily in the best interests of the business. Delaying a critical feature because of a vulnerability is a trade-off that needs to be made on a case-by-case basis. Amplify Feedback Loops The second way tells us that feedbacks loops are the mechanisms that allow for correction; the shorter they are, the faster you can correct. This leads us to the potential value of the short-term embedding of security specialists in teams, and also adopting tooling that allows for rapid feedback on changes, such as in IDE SAST tooling. 8 | Chapter 1: Security in the Modern Organization