22,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A must-read guide to a new and rapidly growing field in cybersecurity In The DevSecOps Playbook: Deliver Continuous Security at Speed, Wiley CISO and CIO Sean D. Mack delivers an expert analysis of how to keep your business secure, relying on the classic triad of people, process, and technology to examine--in depth--every component of DevSecOps. In the book, you'll learn why DevSecOps is as much about people and collaboration as it is about technology and how it impacts every part of our cybersecurity systems. You'll explore the shared responsibility model at the core of DevSecOps, as well as the people, processes, and technology at the heart of the framework. You'll also find: * An insightful overview of DevOps and DevSecOps principles and practices * Strategies for shifting security considerations to the front-end of the development cycle * Ways that the standard security model has evolved over the years and how it has impacted our approach to cybersecurity A need-to-read resource for security leaders, security engineers, and privacy practitioners across all industries, The DevSecOps Playbook will also benefit governance, risk, and compliance specialists who seek to better understand how a transformed approach to cybersecurity can impact their business for the better.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 341
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
COVER
TABLE OF CONTENTS
TITLE PAGE
FOREWORD
INTRODUCTION
WHO SHOULD READ THIS BOOK?
WHO THIS BOOK IS NOT FOR
HOW THIS BOOK IS ORGANIZED
CONVENTIONS USED IN THIS BOOK
CHAPTER 1:
Introducing DevSecOps
WHY DEVSECOPS? WHY NOW?
DevOps OVERVIEW
DevSecOps OVERVIEW
RUGGED DevOps OVERVIEW
DevSecOps BUSINESS RESULTS
CONCLUSION
NOTES
CHAPTER 2:
The Evolution of Cybersecurity (from Perimeter to Zero Trust)
THE EVOLUTION OF THE THREAT LANDSCAPE
THE EVOLUTION OF CYBERSECURITY RESPONSE
CONCLUSION
NOTES
CHAPTER 3:
DevSecOps People
INTRODUCTION
COLLABORATION AT THE CORE
DevSecOps CULTURE
THE SHARED RESPONSIBILITY MODEL
PSYCHOLOGICAL SAFETY
ORGANIZING FOR DevSecOps
BUILDING A DevSecOps CULTURE
THE EVOLUTION OF THE EMPLOYEE (T‐SHAPED PEOPLE)
HIRING FOR DevSecOps
CONCLUSION
NOTES
CHAPTER 4:
DevSecOps Process
INTRODUCTION
UNDERSTANDING PROCESSES AT SCALE
DevSecOps FOR IT SERVICE MANAGEMENT
SECURITY INCIDENT MANAGEMENT
CHANGE MANAGEMENT
PROBLEM MANAGEMENT
RELEASE MANAGEMENT
A DevOps APPROACH TO SECURITY PROCESSES
CHAOS ENGINEERING
CONCLUSION
NOTES
CHAPTER 5:
DevSecOps Technology
INTRODUCTION
DevSecOps CONTINUOUS INTEGRATION AND CONTINUOUS DEPLOYMENT
INFRASTRUCTURE AS CODE
SECRETS MANAGEMENT
PRIVILEGED ACCESS MANAGEMENT
RUNTIME APPLICATION SELF‐PROTECTION
MONITORING AND OBSERVABILITY
EVENT MANAGEMENT WITH SIEM AND SOAR
CONCLUSION
NOTES
CHAPTER 6:
DevSecOps Governance
INTRODUCTION
THE CHALLENGE OF COMPLIANCE
MANAGING RISK
DevSecOps APPROACH TO GOVERNANCE
COMPLIANCE AS CODE
COMPLIANCE FOUNDATIONS
CONCLUSION
NOTES
CHAPTER 7:
Driving Transformation in Enterprise Environments
INTRODUCTION
THE CHALLENGE OF CULTURAL TRANSFORMATION
TRANSFORMATIONAL LEADERSHIP
THE KEYS TO A SUCCESSFUL TRANSFORMATION
TRANSFORMATION CHALLENGES
CONCLUSION
NOTES
CHAPTER 8:
Measuring DevSecOps
INTRODUCTION
KEYS TO A SUCCESSFUL METRICS PROGRAM
OPERATIONAL METRICS
BOARD‐LEVEL METRICS
MEASURING TRANSFORMATION
CAPABILITY MODELS
CONCLUSION
NOTES
CHAPTER 9:
Conclusion
INTRODUCTION
PEOPLE, PROCESS, AND TECHNOLOGY
COLLABORATION IS AT THE CORE
MAKING SECURITY PART OF HOW YOU WORK
WHERE TO START
THE FUTURE OF DEVSECOPS
CONCLUSION
NOTE
ACKNOWLEDGMENTS
ABOUT THE AUTHOR
How to Contact the Author
INDEX
COPYRIGHT
END USER LICENSE AGREEMENT
List of Illustrations
Chapter 1
Figure 1.1 DevOps can be thought of as the intersection of development, oper...
Figure 1.2 DevSecOps can be though of as intersection of development, operat...
Figure 1.3 While Agile focuses on the development process, DevOps adds focus...
Chapter 2
Figure 2.1.1 Early computer systems and data were contained in the company h...
Figure 2.1.2 Interconnected offices expanded the network footprint.
Figure 2.1.3 Data centers were co‐located or hosted outside of the company h...
Figure 2.1.4 Increased adoption of cloud providers such as AWS, GCP, and Azu...
Figure 2.1.5 SaaS providers such as Salesforce and SAP introduced new locati...
Figure 2.1.6 As cloud adoption accelerated multi‐cloud approach further incr...
Figure 2.1.7 The global remote and hybrid work environment accelerated by th...
Figure 2.2 Defense in Depth takes a layered approach to security with protec...
Figure 2.3 In addition to security at every level, Defense in Depth includes...
Figure 2.4 Traditional waterfall development methodology depicted as proceed...
Figure 2.5 Testing during the traditional development cycle is heavily weigh...
Figure 2.6 Testing by development phase using a Shift Left approach introduc...
Figure 2.7 The NIST 2002 study “The Economic Impacts of Inadequate Infrastru...
Chapter 3
Figure 3.1 Security professionals often fall into the later stages of the in...
Figure 3.2 DevSecOps can be considered the intersection between operations, ...
Chapter 4
Figure 4.1 The rate of change shows a significant spike in the number of rel...
Chapter 5
Figure 5.1 The DevSecOps pipeline integrates security tools directly into th...
Figure 5.2 Correlating events across all logs, metrics, and alerts provides ...
Chapter 6
Figure 6.1 The different cybersecurity frameworks have significant areas of ...
Figure 6.2 Standards such as the emerging standards for the protection of pr...
Figure 6.3 The hierarchy of risk management flows from general standards and...
Chapter 7
Figure 7.1 The innovation adoption life cycle can provide a guide for adopti...
Chapter 8
Figure 8.1 Number of incidents by priority can be a great way to ensure inci...
Chapter 9
Figure 9.1 By setting measurable targets, you can align the direction in whi...
Guide
Cover
Table of Contents
Title Page
Copyright
Foreword
Introduction
Begin Reading
Acknowledgments
About the Author
Index
End User License Agreement
Pages
iii
xiii
xiv
xv
xvi
xvii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
iv
221
THE DEVSECOPS PLAYBOOK
Deliver Continuous Security at Speed
SEAN D. MACK
FOREWORD
The friction between traditional security and the rest of the IT organization started increasing as developers needed to deploy more quickly, push out more stable builds, and produce more secure products. Teams created new practices to solve the bottlenecks, and the impossible came into reach. Much like doing multiple deploys a day was once considered insane on the maturity scale, embedding security in the whole organization is now within reach. Security is a first‐world citizen in this new alliance between dev and ops.
So how do you get started with DevSecOps? I like people who come to me with solutions instead of complaining about problems. This is how I recruit people with the right attitude. To propose solutions, you need to know what's out there, learn about them, and put them in your toolbox to apply them wisely. Dealing with security is no exception. If you are embarking on this journey, The DevSecOps Playbook will provide you with what you need: insights, tools, process, and people practices.
One could say collaboration is all you need, and the rest will come from there. This emphasis on collaboration prompts the question, how is DevSecOps different from DevOps? In mindset there is no difference; they both start from the same principles, similar to how DevOps started from Agile principles. And introducing DevSecOps is no different from driving any other change in a company.
What is important is that by giving DevSecOps its own label, we were able to tag all the related stories and good practices that people were exploring under one umbrella term. The stories and information shared in this book give you the context of how the concept was born. Then you'll learn about the tools and techniques that will help you.
What gives The DevSecOps Playbook a unique perspective is that the author has gone through an actual long‐running transformation, not just some theoretical exercise. It translates the DevOps principles to security practices. Therefore, instead of focusing on a few aspects, it covers the right broad spectrum of topics. But don't let this vast coverage scare you! It only means that there is a lot to learn. And learn you shall now that you have this book in your hands.
—Patrick Debois
Founder of DevOpsDays and a creator of theDevOps movement
INTRODUCTION
Welcome to The DevSecOps Playbook: Deliver Continuous Security at Speed. This book is the definitive guide to DevSecOps transformation. With DevSecOps, you can deliver secure products and services to market quicker, helping you to outpace your competition while ensuring security and privacy. This book explores the people, process, and technology of DevSecOps and provides a guide for driving the transformation.
WHO SHOULD READ THIS BOOK?
This book is intended for anyone interested in truly understanding DevSecOps and how to apply it to keep businesses more secure. More specifically, this book is for security leaders who want to learn about how to drive DevSecOps transformation to build and deliver secure products and services without impeding the flow of delivery. This book is also for security engineers who want a better understanding of DevOps and the changing security landscape, as well as privacy practitioners, auditors, and governance, risk, and compliance specialists who want to understand how a fundamentally different approach to security with DevSecOps can impact the way they do business.
This book is focused on DevSecOps in midsize and large enterprise environments. While the principles of DevSecOps apply to companies of any size, the challenges of coordination and collaboration become more acute with the size and age of a company. Details around driving transformation and organizational structures may be more applicable to companies that have established ways of working than to startups taking a greenfield approach.
A basic understanding of information technology and cybersecurity concepts and terminology may be helpful but is not required.
WHO THIS BOOK IS NOT FOR
This book is not an engineering guide. This book does not tell you how to configure DevSecOps tools (although it covers many tools), and it does not go into detail about secure coding practices.
HOW THIS BOOK IS ORGANIZED
DevSecOps is about more than technology; in fact, it is more about people and collaboration than anything else. Gene Kim, author of the Phoenix Project and one of the foremost thought leaders in DevOps, originally described DevOps as a cultural movement. Because of its cultural nature, DevSecOps impacts all elements of how you do cybersecurity. This book uses the classic triad of people, process, and technology to look in depth at all components of DevSecOps.
Chapter 1, “Introducing DevSecOps,” starts by providing an overview of DevOps and what DevSecOps is. Chapter 2, “The Evolution of Cybersecurity (from Perimeter to Zero Trust),” provides a foundation for the rest of the book by looking at the evolution of technology and the resulting impact on the approach to cybersecurity. With this background, Chapters 3, “DevSecOps People”, Chapter 4, “DevSecOps Process”, and Chapter 5, “DevSecOps Technology,” look at people, process, and technology and how DevSecOps impacts each of these categories.
The remaining chapters dig into key DevSecOps topics in depth. Chapter 6, “DevSecOps Governance,” takes an detailed look at how the concepts of DevSecOps provide a fresh approach to governance and compliance with the opportunity to save millions of dollars and reduce engineering overhead. Chapter 7, “Driving Transformation in Enterprise Environments,” provides insight into how to drive the DevSecOps transformation in your business, laying out some of the key elements for successful transformation and some of the pitfalls to avoid. Chapter 8, “Measuring DevSecOps,” looks at some of the key metrics for measuring your DevSecOps progress and the impact it is having on the business. Chapter 9, “Conclusion,” brings these concepts together by providing some insight into what is coming and the next steps you can take to drive your DevSecOps transformation.
CONVENTIONS USED IN THIS BOOK
Throughout this book you will find a few conventions to note key terms, technical notation, and auxiliary information. The following conventions will help as you make your way through this book:
Lines of programming code are noted using this Courier, fixed-width font.
Code that is included within the text looks like these code words within the sentences and paragraphs.
You will also see key terms in italics. These are important terms that are given emphasis the first time they appear to indicate their importance.
REAL‐WORLD EXAMPLES
Throughout the text, you will find additional information and examples to highlight the points being made through the use of specific, real‐world examples.
Key concepts—Important ideas from the chapter are called out from their context in this manner to make them easily identifiable and to reiterate critical information.
Notes—explain background information or clarify a point. They are also used to direct you to information you can find elsewhere to clarify certain topics.
Tips—are used throughout the book to provide practical information or advice related to topics covered in the book. These can be helpful in the implementation of the principles covered.
CHAPTER 1Introducing DevSecOps
WHY DEVSECOPS? WHY NOW?
DevSecOps provides the ability to deliver more secure products and services to the market rapidly. For decades, technology engineers have sought to balance the speed of delivery with security and performance. DevSecOps fundamentally alters this equation, allowing companies to deliver at speed without compromising security, privacy, or system performance.
Technologists have long struggled with the balance of quality and speed, attempting to answer the question, “How do we deliver products to market quickly without sacrificing security?” With DevSecOps, you finally have that answer, and that answer lies in collaboration. DevOps and, by extension, DevSecOps offer the promised holy grail of technology product development and delivery: the ability to build reliable, secure, and maintainable products without sacrificing speed to market.
DevSecOps provides a fundamentally new approach to security. This approach moves away from the gating approach of yesterday by shifting responsibilities earlier in the development pipeline. By working with developers, it is possible to integrate security across technical applications and services more easily. Through automation and education, one engineer can embed security practices in many applications. By ensuring that security practices are embedded earlier in the developments, you can reduce the effort it takes to build secure products. In effect, by taking a DevOps approach to security, you can reduce the friction of security and compliance and become a force multiplier for the security team.
Cybersecurity has never been a more critical issue than today. The number of cyber threats is continuing to grow. Today we face an increasing number of threats, and the breaches we are seeing have an even larger impact.
With the increasing prevalence of remote work and global teams, the attack surface is continuing to expand. It is no longer possible to simply secure the network perimeter; we must provide security at every level as we move toward approaches such as defense in depth and zero trust. Chapter 2, “The Evolution of Cybersecurity (from Perimeter to Zero Trust),” explores the evolution of the security model in detail.
In addition, we are seeing an increasing number of attackers and increasing sophistication of the attackers. The number of attackers continues to grow as the availability of tools to launch attacks has grown. The ready availability of attack tools means that it takes less skill to launch attacks. Today, a novice attacker can rent a fleet of zombie computers on the Dark Web and launch a distributed denial‐of‐service attack in minutes. In addition to the proliferation of attackers, we are seeing increasing sophistication of attackers. Today the primary threat actors include organized crime with cybercrime revenue estimated at $1.5 trillion in 2019, more than the revenue of Tesla, Facebook, Microsoft, Apple, Amazon, and Walmart combined.1 We also see nation‐states leveraging cybercrime as a weapon of war.
To combat this increasing threat landscape, you not only need new tools; you need a fundamentally new approach. DevSecOps gives you what you need to combat these emerging threats. By taking a collaborative approach to security, you will be able to leverage the power of the entire technology organization to drive security rather than relying on a single team within that organization. In addition, technologies such as continuous integration and continuous development (CI/CD) allow you to integrate security directly into the deployment pipeline.
DevOps OVERVIEW
The people, process, and technology of DevOps advance the way that engineers build, deploy, and manage technical systems by bridging the gap between development and operations teams to get products to market quickly, while addressing the nonfunctional requirements such as stability and scalability. DevOps is a set of principles for delivering value to customers based on Lean principles and collaboration. While many people think of DevOps as a technology or set of technologies, these are really a means to an end. That is, these are simply tools used to better apply the principles of DevOps.2 DevOps includes the people, processes, and technologies used to deliver value to customers through technical products and services based on the DevOps principles.
DevOps is a set of principles for delivering value to customers based on Lean principles and collaboration.
Gene Kim, DevOps thought leader and author of The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win\ The DevOps Handbook: How to Create World‐Class Agility, Reliability, & Security in Technology Organizations, and many other DevOps books, describes DevOps in an interview with Dynatrace, saying, “I think that's exactly what DevOps is. Take those Lean principles, apply them to technology value streams, and you end up with emergent patterns that allow organizations to do tens, hundreds, or even hundreds of thousands of deployments per day, while preserving world‐class reliability, security, and stability.”
Understanding DevOps as a culture or set of principles that focus on collaboration, you can then understand it as the interaction or collaboration among development, operations, and QA, as shown in Figure 1.1.
Figure 1.1DevOps can be thought of as the intersection of development, operations, and quality assurance
Although there are many definitions of DevOps, the Three Ways of DevOps, described in Gene Kim's The Phoenix Project, as well as the CALMS model originated by Jez Humble, co‐author of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations and The DevOps Handbook: How to Create World‐Class Agility, Reliability, & Security in Technology Organizations, provide two of the original models for understanding DevOps. These two models go a long way to explaining the principles underlying DevOps.
If you are already a DevSecOps professional, much of the following information may be review. Feel free to skip to Chapter 2. If you are just getting started with DevOps and DevSecOps, keep reading.
Brief History of DevOps
In 2009, John Allspaw, then senior vice president of technical operations at Flickr, and Paul Hammond, director of engineering at Flickr, delivered their talk “10+ Deploys per Day: Dev and Ops Cooperation at Flickr” at the O'Reilly Velocity Conference. They introduced many of the concepts of small batch deployment and collaboration between development and operations. The blog A Short History of DevOps states that “The talk becomes widely credited with showing the world what development‐operations collaboration can achieve.”3 That same year, the term DevOps was introduced when Patrick Debois launched the “Devopsdays” event in Ghen, Belgium. The concept took hold, and the first U.S. Devopsdays was held in 2010. Devopsdays was later shortened to the term DevOps that we are all familiar with today.
In 2013, Gene Kim, Kevin Behr, and George Spafford penned their book, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, which presented many of the underpinning concepts that make up DevOps today. At the same time, the “State of DevOps Report” was developed, which sought to determine DevOps best practices and their outcomes. The “State of DevOps Report” has become a staple of information for DevOps practices. In his blog post “A Summary of All of the State of DevOps Reports,” Tom Geraghty writes, “The first report was in 2013, and showed quite clearly that adopting DevOps practices resulted in technological and business improvements.”
DevOps continued to grow, and in 2014 we saw the increased expansion of DevOps into enterprise environments marked by the launch of the DevOps Enterprise Summit (DOES). DOES sought to explore DevOps at scale for large and complex organizations. That same year the group that would later develp the DevOps Research and Assessment (DORA) metrics teamed up with Puppet labs to find new ways of measuring DevOps and the results.4 These metrics were included in the “State of DevOps Report” from 2014–2017. The research and details about these metrics were published in Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim in 2018.
While site reliability engineering (SRE) had been around for some time, it came into increased usage much later. The term was originally used at Google in 2003. The term grew in prominence in the DevOps world around 2015, and in 2017 LinkedIn named SRE as one of the most promising jobs of the year.5
It is only in recent years that DevOps has really begun to connect with security and DevSecOps has gained momentum. The 2017 and 2018 “State of DevOps Report” showed that DevOps helped improve security outcomes.
Today, DevOps is something almost every company is doing, from nimble startups to the Fortune 500. More and more the scope is expanding to cover security, and companies are seeing how the benefits of DevOps can be unleashed on cybersecurity through DevSecOps.
The Three Ways of DevOps
Gene Kim's The Phoenix Project provides one of the earliest and most widely read explanations of the key principles of DevOps. Based loosely on The Goal: A Process of Ongoing Improvement by Eliyahu M. Golratt, The Phoenix Project follows a set of fictional characters through the trials of a modern technical and bureaucratic landscape. In the book, the protagonist, Bill Palmer, is thrust into a leadership role as the new VP of operations, where he must right the sinking ship and ensure a successful product launch for a struggling auto parts manufacturer. Through the book he discovers that by getting the development and operations teams to work closely together, he not only saves the struggling project but also boosts the company to never before discovered levels of success.
In the book, Palmer meets a mysterious mentor who guides him through the principles referred to as the Three Ways of DevOps. These principles allow Palmer and his team to rise to the challenge.
These “Three Ways” provide some of the core principles of DevOps. On his blog, Kim writes, “We assert that the Three Ways describe the values and philosophies that frame the processes, procedures, practices of DevOps, as well as the prescriptive steps.”
Kim describes the Three Ways as follows.
The First Way focuses on the flow through the entire system, which breaks down silos such as development and operations to enable flow from ideation to ultimate customer value creation. This type of thinking shifts focus away from “what is my job?” to “how do we deliver value to the customer?” When viewing systems in this way, people can begin to look at how to maximize flow and remove bottlenecks.
These are examples of the First Way of DevOps:
Shared goals
—By sharing goals across technology teams, companies build a shared direction for the company. Instead of having a development team focused on delivering new functionality and an operations team focused on delivering stability, all teams can focus on delivering value to the customer with the right mix of functionality and stability.
Value stream mapping
—Value stream analysis is a Lean management technique for analyzing the process of delivering value to the customer. This analysis looks at every step in a process to identify potential bottlenecks and inefficiencies. By mapping out the process of value delivery, it is possible to identify and eliminate bottlenecks that may impact the delivery of value to the customer.
Test automation
—Automated development testing is a key element of the First Way, as it reduces handoffs between development and QA teams and eliminates potential bottlenecks, thus enabling the flow of value to the customer. In traditional software development models, software was developed, and once a feature or product was complete, it was handed off to the quality assurance team for testing. Automated testing allows for incremental testing so that minor code changes can be tested as soon as they are checked in. This helps ensure the product is always in a working state during development and eliminates the need for large‐scale test and retest cycles at the end of every development cycle.
The Second Way is about creating feedback loops. This way focuses on getting and amplifying input from the customers to the people building the product. The Second Way also includes looking for ways to shorten and amplify these feedback loops.
These are key examples of the Second Way:
A/B testing
—A/B testing is the process of comparing and testing hypotheses about a product's performance by testing them in a production environment. As a simple example, if a company wanted to determine if users were more likely to click a green button or a blue button, they could display a green button for 50 percent of users and a blue button for 50 percent of users and measure the results.
Feature flags
—Feature flags are a method of turning features on or off. These enable companies to push features to production without making them available to customers and then turn those features on at a given time without additional changes to the code in production. This process allows companies to push new features to production without affecting timing of marketing launches or other timing‐related elements. More advance feature flags allow for features to be enabled for certain percentages of users or even certain customer segments and, as such, can enable A/B testing.
Continuous customer contact
—One of the best ways to get feedback is by meeting directly with customers. Far too often security engineers work in isolation from the people they are trying to protect. Whether they are internal customers or external customers, it is critical to hear input directly from them at every stage of the product life cycle.
The Third Way focuses on driving experimentation and learning. This includes building a learning culture that is continually reflecting on mistakes, learning from them, and using these learnings to grow and improve. In a learning culture, learning is built into the way a company operates on a daily basis. The Third Way also looks at opportunities to drive mastery through repetition as part of this larger learning culture.
These are key practices of the Third Way:
Chaos engineering
—Chaos engineering is a practice where random errors are intentionally inserted into the system to ensure that the system, processes, and people are resilient and able to react and respond appropriately. These errors can range from software defects to hardware failures to security misconfigurations. By inserting errors into the system, chaos engineering helps ensure system resilience and provides opportunities to learn when it is not.
20% time
—This refers to the practice of reserving 20 percent of resources time to do work focused on innovation and experimentation. Reserving one day a week or one week a month or 20 percent a day can facilitate this. The key is that this time must be isolated and protected to ensure that there is room for experimentation.
Hackathons
—Hackathons are the practice of designating a set period of time where organizations form teams to do focused work on building innovative new ideas. Hackathons often take the form of weeklong efforts focused on demonstration of the work created during that time period.
Blameless culture
and
blameless postmortems
—
Blameless postmortems focus on providing a safe space to review past incidents without trying to find anyone or any one thing to blame. Instead, these postmortems are focused on using incidents as a learning opportunity, which help the organization improve by learning together. Blameless culture extends this concept ensuring that the culture is one that does not point fingers but instead is one of physiological safety where people can learn and grow.
The Five Ideals
In 2019, Gene Kim released a sequel, The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data. The Unicorn Project takes place during the same time period at the same company as the Phoenix Project. However, the Unicorn Project follows a second set of characters, giving a perspective from the team level, as they work through their own set of challenges.
Throughout this book, Kim introduces the Five Ideals, listed here:
The First Ideal: Locality and Simplicity
The Second Ideal: Focus, Flow, and Joy
The Third Ideal: Improvement of Daily Work
The Fourth Ideal: Psychological Safety
The Fifth Ideal: Customer Focus
These ideals introduce ways of working that are crucial to the DevOps culture.
The CALMS Framework
The CALMS framework is another approach to defining the principles of DevOps. CALMS is an acronym that stands for Culture, Automation, Lean, Measurement, and Sharing. The original acronym, CAMS, was coined by John Willis and Damon Edwards. It was later expanded to include L for Lean by Jez Humble,6 co‐author of The DevOps Handbook and Continuous Delivery.
This model focuses on these underlying principles of DevOps:
Culture focuses on how people work together to achieve a goal.
Automation emphasizes the need to automate everything through methods like continuous delivery and infrastructure as code to ensure the continuous flow of value to customers. The focus on automation is critical for DevOps because, without it, we require people to take multiple, time‐wasting steps, which require handoffs between teams and increase opportunity for bottlenecks.
Lean refers to the Lean management principles, such as small batch sizes, which underpin much of DevOps. While these principals were originally developed for manufacturing, they have significant applicability to software engineering. For example, small batch sizes allow for incremental delivery of value to the customer while reducing inventory, backlogs, and work‐in‐progress.
Measurement refers to the extraction of key data that provides everyone with constant opportunities to learn and improve.
Sharing refers to the need for open communication, transparency, and collaboration at all levels and stages of the process.
This model, like the Three Ways, codifies many of the underlying principles of DevOps.
It is important to note that neither the Three Ways nor CALMS excludes security, but neither do they explicitly include security. The focus on removing silos certainly implies that cybersecurity should be part of the value delivery equation.
DevOps as an Anti‐Pattern
In many ways, DevOps can be seen as an anti‐pattern, a rejection of the idea that operations and development should be separate silos. That is, DevOps has emerged as a response to a common problem that arises in the conflict between operations and development teams.
In traditional software development, with waterfall‐based methodology, the development teams and operations teams often function under separate leaders, sometimes even under separate organizations altogether. This organizational structure invites inherent conflict, with development teams focusing on delivering features and operations teams focusing on stability. Not only were these teams focused on separate things, these teams were often aligned around separate and competing goals with compensation tied directly to these goals. Operations teams receive bonuses based on system availability and development teams receive bonuses based on the number of features built. This underlying structure causes conflict between teams and creates delays in getting products to customers, which meet both their functional and nonfunctional requirements.
THE CHANGING RELATIONSHIP BETWEEN DEVELOPMENT AND OPERATIONS
I remember many years ago, applying for my first job leading operations teams. The interviewer asked me how I felt about and handled the conflict between operations and development. Now this was back in the days when the company was still releasing their product on CD, so not only was DevOps not a thing, but many of the enabling technologies hadn't been invented yet.
My answer was something along the lines that it was a healthy tension. This tension was, in fact, useful to have one team that prioritized feature development and another that prioritized stability and, as long as they worked together with open dialogue, a healthy balance would emerge.
My beliefs have changed since then and so has the technology. With the advent of DevOps, we can deliver features to market quickly without sacrificing stability, and these principles apply to security too!
In addition to the inherent conflict based on separation of operations and development teams, this structure coupled with a waterfall‐based approach ensured multiple manual handoffs, which, by their nature, create an opportunity for delay.
Development teams handed off the product to the operations teams, who would then begin running through a rigorous set of tests to ensure the application is “ready for production.” Only after all development was complete would the operations teams begin looking at the product. Extensive performance testing would be performed, and the maintainability of the product would be reviewed. Invariably, defects were discovered, and the product would be sent back to development for correction. This process fostered a blame‐based culture that forced the already burdened development teams to constantly refocus, ensuring further delays.
INHERENT CONFLICT BETWEEN DEVELOPMENT AND OPERATIONS
At another company, I remember sitting cramped in a small conference room with 20 other development and operations engineers fervently arguing with the CTO that the product was not ready to be released. (If you are too young to remember times when this was commonplace, count yourself lucky!) I argued that the product had major known defects and that performance testing was not complete. The CTO was arguing that they had a major market event coming up and the launch of the product was based around this one event. In addition, customers had been promised that this product would be ready, and the date of launch had already been communicated.
I lost that argument. The product was launched with all the known problems. We spent the next two weeks in a struggle to troubleshoot problems while fixing known issues and investigating new complaints. Teams worked day and night just to ensure the product stayed up. The customer experience, and team morale, suffered significantly.
DevOps emerged as a rejection of this approach. With a focus on collaboration, it sought to tear down the barriers between teams, to break through the inherent conflict between development and operations, and, in so doing, to deliver better products to market that addressed both the functional and nonfunctional requirements in a much timelier and more transparent way.
Agile and DevOps
Both the Agile and DevOps methodologies have roots in Lean manufacturing. Dating back to the 1990s, Agile focuses on development and quality assurance working together to deliver incremental value to customers. While more recent, DevOps takes these same concepts and extends them to operations, building on many of the same principles and practices.
If you look at the goals of Agile and DevOps, you find that they are strikingly similar. Look at the value Agile and DevOps deliver. That is, look at the “why” of DevOps, and look at the “why” of Agile. When you look closer, you discover that the goals of both are to get value to the customer quicker and to rapidly react to changing market demands. DevOps takes the principles introduced in Agile and extends them beyond code check‐in to deployment and operations.
DevOps takes the principles introduced in Agile and extends them beyond code check‐in to deployment and operations.
As the goals of Agile and DevOps align, it is not surprising to find significant overlap in the practices that surround them. In many ways, the intersection of DevOps and Agile relates to a culture of collaboration and modern technical practices and processes that emerge from that culture. Processes such as continuous testing and the small batch deployment help ensure the rapid delivery of working products to the customer. DevOps takes Agile concepts and extends them beyond the build so you can amplify Agile by implementing DevOps practices.7
DevOps and ITSM
There is a prevalent myth that DevOps and IT Service Management (ITSM) and the IT Infrastructure Library (ITIL) are incompatible. However, this supposition has very little basis. ITIL is a framework from which you can take or leave portions you like, and, in fact, this framework provides many useful paradigms for DevOps implementations.
Contrary to the myth, there is a considerable amount of synergy between ITIL and DevOps. If you understand ITIL as a process framework and see DevOps as, primarily, a culture of collaboration, there is no reason you cannot have a process framework integrate very well with a culture of collaboration. In fact, the process framework of ITIL can support the culture of collaboration. If you look at the ITIL process for problem management, incident management, or change management and approach these with a focus on DevOps principles such as collaboration, transparency, learning, and automation, you can build DevOps‐aligned processes to support the business.
Many others have noted the synergies between DevOps and ITIL. At CIO.com, Barclay Rae writes, “We need the key elements that are found in both ITSM and DevOps, whether we use these explicitly or not. DevOps is much more than just automated development; it involves collaboration and a blame‐free culture. As well, ITSM/ITIL shouldn't be pigeonholed as an administrative burden, but rather used in an Agile way.”8
The ITIL process framework is just that, a framework. It is not a mandate that “thou must fill out 20 pages of documents to release software” (although some overly bureaucratic implementations certainly make it feel that way). When you understand the IT Infrastructure Library as a framework, it becomes evident that there is no reason you cannot apply DevOps principles within this framework to make your technology operations more streamlined. By taking a DevOps approach to your change process definition and implementation, you can drive safer releases rapidly, you can ensure better communication between your teams, you can drive quicker resolution to incidents, and you can ensure you keep your focus keenly on delivering value to your customers quickly.9 You will delve deeper into how you can take a DevOps approach to ITIL processes in Chapter 4, “DevSecOps Process.”
DevSecOps OVERVIEW
Put simply, DevSecOps is the subset of DevOps focused on cybersecurity. It is critical to fully understand DevOps. In many ways, DevSecOps is the intersection of development, quality assurance, operations, and cybersecurity, as shown in Figure 1.2.
Figure 1.2DevSecOps can be though of as intersection of development, operations, quality assurance, and cybersecurity.
Agile focuses on the overlap of development and quality assurance; DevOps focuses on the interconnectivity between development, quality assurance, and operations; and DevSecOps focuses on the connection between development, quality assurance, operations, and cybersecurity (see Figure 1.3).
Figure 1.3While Agile focuses on the development process, DevOps adds focus on the operational aspects of the product life cycle, and DevSecOps emphasizes security.
This view of Agile, DevOps, and DevSecOps is, perhaps, a bit too simplistic. Agile never excluded operations or security. In fact, it provides a model for prioritizing operations and security work. In addition, the small batch sizes and rapid iteration are ideally suited for reducing the scope of defects that might be introduced and addressing them rapidly when they are introduced.
