We live in a world of complex systems and unintended consequences. In 2011, Marc Andreessen told us that “software is eating the world.”[1] Today, that seems like an understatement. Some of my friends have remarked that software isn’t merely eating the world, it’s gobbling it down.
Marc’s famous quote is a revealing commentary about the speed of digital transformation. We can argue about when technology began shifting from analog to digital, but I use 1937 as a handy reference point on the historical timeline. That was the year that Claude Shannon, then a 21-year-old student at the Massachusetts Institute of Technology, wrote his master’s thesis on digital circuit design theory. Eleven years later, he published A Mathematical Theory of Communication, a seminal work that jumpstarted the digital age and earned Shannon his unofficial title as “the father of information theory.”
Fast forward to the 2020s. Software is no longer an adjunct or an incidental component; software has become the central core of our economy. Our markets, our exchanges, and our supply chains run on software. And to a greater extent with the passing of every day, our lives run on software. The companies we work for, the schools our children attend, the products we use, the services we consume – none of those would exist in their current states without software.
What seemed like an idea from science fiction has already happened – we have become so reliant on software that it would be impossible to imagine its absence. If software disappeared tomorrow, the world as we know it today would collapse. Period.
Existential Questions
Successful societies have mastered the use of software; it is not difficult to see a direct correlation between software and economic strength. That observation may not be to everyone’s taste, but it’s hard to deny.
If we, as a society, agree that software has become absolutely essential to our lives and to the wellbeing of our families and friends, then we must ask ourselves how we can do a better job of securing our software and our data. Twenty years ago, this would not have been considered an existential question. Today, it is.
Data breaches, denials of service and other disruptions drain billions of dollars from our economies, injure the reputation of corporate brands, endanger the health and safety of people everywhere, and slow the pace of progress. Cybercriminals and their overlords have targeted hospitals, schools, transit systems and water treatment plants.
Worms and viruses such as Melissa, Stuxnet, Code Red, My doom, ILOVEYOU and WannaCry[2] are symptoms of deeper problems. The U.S. Office of Personnel Management hack, the Equifax breach, the Colonial Pipeline hack, the Epik data breach, and of course, the SolarWinds hack – which affected private companies such as Microsoft, Intel, Cisco, Deloitte and FireEye, and public agencies such as the U.S. Departments of State, Treasury, Commerce and Homeland Security – all point to the emergence of a new normal in which any entity, any system or any person can become a target.[3]
The SolarWinds and Kaseya attacks are especially worrisome because of their impact on managed service providers. In a very real sense, they represent a new level of danger and risk.[4]
From ‘Why’ to ‘How’
The “why” questions are easier to answer than the “how” questions. For example, people who aren’t in the tech industry often wonder why the internet is frequently described as a security nightmare. The answer is relatively easy: way back in the 1960s, when engineers such as Kenneth Thompson and Dennis Ritchie were developing UNIX and laying the foundations for the internet, most computers were owned by large corporations, government agencies or universities.
It seems unlikely that those early pioneers could have foreseen how the subsequent rise of personal computers, the World Wide Web, Google, Facebook, Reddit and TikTok would transform the internet from an obscure tool used mainly by a handful of academics into a global platform continuously serving billions of people.
The short answer to the “why” questions is that when the platform we all share was invented, security was not a pressing issue. The “how” questions are more difficult to answer, and they are the beating heart of this book.
Digital Transformation Has Become a Force of Nature
Here are three observations to keep in mind while reading The Purple Book:
- Software has already eaten the world.
- The pace of digital transformation is accelerating and shows no sign of slowing down.
- Open source software has become ubiquitous.[5] Some reports estimate that 98 percent of codebases contain open source code.[6]
Why are these observations especially relevant? Because they frame and inform the discussions you will encounter as you read this book. Like it or not, we live in a world that is very different from the world of our parents and grandparents.
Our predecessors were accustomed to a world of concrete goods and tangible substances. Our generation navigates through a universe of symbols, abstractions and derivatives. Modern life has been shaped, influenced and altered profoundly by decades of digital transformation.
Pining for the good old days isn’t going to help us. Our present and our future hang in the balance as we struggle to control the technologies we have invented. In a world dominated by software, security isn’t a luxury – it’s indispensable to our survival.
Reimagining Application and Product Security
For decades, software development was defined by a set of fairly rigid formalities and expectations. It took years to plan, write and implement new programs. Many of those older programs were quite robust, and some are still running today; however, as we all know, change is the only constant in life. Every decade or two, there are landmark innovations that fundamentally transform the way things are done. In the world of software development, the arrival of public cloud infrastructure was one of those transformational innovations.
With everything moving to the cloud, business agility went to the next level. As a result, the speed of business has accelerated greatly over the past several years, and the standard Waterfall model for developing new programs was simply too slow and cumbersome for many organizations. Agile methodology, developed in 2001, offered a more flexible and iterative approach, which appealed to fast-moving companies in highly competitive markets. Agile’s emphasis on design, testing, iteration and continuous improvement made it a good fit for markets that were becoming increasingly digital and more dynamic.
Even as development cycles shortened, application architecture remained relatively simple, adhering mostly to a three-tier structure:[7]
- Presentation tier
- Application tier
- Data tier
Securing a three-tier monolithic application written in a standard programming language such as C is a fairly straightforward affair. But as the pace of business and digital transformation continues to quicken, monolithic architecture is giving way to microservices.
The advent and extremely rapid adoption of microservices forces us to reimagine application security. Microservices are essentially small applications or snippets of code that communicate with other microservices through APIs (Application Programming Interfaces). They function as loosely coupled services, acting independently and when necessary, across multiple platforms. They can be written in virtually any programming language, which makes it easier for coders to write them on the fly.
Unquestionably, microservices can add value to a business organization. Yet they also add complexity. For example, it’s not difficult to isolate the tiers of a three-tier application and keep an eye on each tier. Testing the security of a three-tier application written in C requires a comparatively small kit of familiar tools.
Nowadays, however, the typical application can be made up of 40 or more microservices. A few years ago, you might have been managing 2,000 applications. Today, you would be managing 80,000 microservices. That represents a huge difference, and quite frankly, many organizations aren’t up to the task.
Viewed from a purely technological perspective, microservices seem like gifts from heaven. Compared to older kinds of applications, they are easy to write, easy to use and easy to deploy. They can help you scale your business quickly and stay ahead of the competition.
But their advantages also pose serious security risks. New applications can improve your top line revenue and make your customers happier; they also can open doors for attackers who want to penetrate your systems, steal your data and disrupt your operations.
Make no mistake: we’re not opposed to microservices. Thanks to microservices, organizations can release new software in days or weeks, as opposed to months or years. Microservices enable innovation and invention at speeds that would have been unthinkable 10 years ago.
We are, however, in favor of taking precautions against the unintended consequences of using microservices. From a business standpoint, microservices are great; from a security perspective, however, they create opportunities for bad guys to enter your systems and rummage through your data.
Open source is another trend that requires closer attention from the security perspective. Open source has been around since the late 1970s; the most famous open source project is Linux, invented by Linus Torvalds in 1991. It would be a gross oversimplification to describe open source code as merely an alternative to proprietary code; but that’s clearly one of its selling points. Anyone with a keyboard and computer can write open source code, which means that some of it is fabulous and some of it is not so good. It also means that when a problem arises in the middle of the night, it's not always immediately clear who is responsible for fixing it.
From a security perspective, the continually changing and evolving nature of open source code makes it problematic. That said, open source code is not going away anytime soon. Open source software is widely used, even by companies that sell proprietary software.[8] Open source code continues to drive innovation, invention, disruption and business growth across practically every sector of the modern economy, so we’ll just have to learn how to leverage its strengths and manage its weaknesses.
Playing With Fire?
You know the old saying, “Play with fire and you will get burned.” At this moment, it feels as though too many organizations are experimenting with new technologies without fully understanding the risks. Perhaps the relatively easy task of securing monolithic applications with only a handful of tools bred a sense of complacency and overconfidence.
Here’s the harsh truth: billions of lines of new code are written every year. Each line represents a potential risk. When you add artificial intelligence and machine learning into the mix, the complexity of the security challenge expands to dangerous levels.
We are experiencing a paradigm shift. Software has become ubiquitous. It’s hard to find a device or machine – or even a toy – that doesn’t have software in it. That means software security can no longer be an afterthought. It must be baked into every decision and every process.
Moreover, we have to accept that many of the testing and analytic processes that we used to perform manually must now be automated. Today’s world moves too quickly for human minds to comprehend; we must adapt and adjust our security solutions to include AI and ML capabilities. We will not succeed in our mission if we continue using security tools and techniques that were developed 10 or 15 years ago.
Many of the older tools were built for Waterfall methodologies. Some need to run for hours or days before yielding results. In a DevOps environment, where new code is written and operationalized at lighting speed, that kind of leisurely pace is unacceptable. We cannot reasonably expect the business to handicap itself in today’s rapidly shifting markets. Instead, we need to provide a new generation of security tools that are better, faster and smarter than the old ones.
As security experts, we need to work more closely with the DevOps teams. Again, security must not become an afterthought. It must be written into the software from the get-go.
A couple of years ago, it was common to visualize security in three buckets:
- Product Security
- Application Security
- DevOps Security (or DevSecOps)
More recently, it’s become apparent that product security and application security have converged (because software is everywhere), and that DevSecOps may be the best place to focus our collaborative energy, since that’s where secure code is born. At the risk of being repetitive, DevOps and security teams must workhand-in-hand; companies must encourage and support the highest possible levels of collaboration in software development processes. Closer collaboration, perhaps more than anything else, will enable us to achieve our business goals without sacrificing our safety and security.
Shift Security Left
The trend today is “shifting security left,” which essentially means including security early in the development process. Some also call this trend “security by design.” In addition to the obvious benefit of building security into the product from the beginning, “shifting left” can also save money, since the cost of fixing defects can be six times cheaper if you find and fix them in the early parts of the SDLC (Software Development Life Cycle).[9]
From our vantage point, we see three capabilities emerging as essential to successful software security strategies:
1. Visibility and Actionable Insights
The extremely rapid proliferation of new applications and microservices makes it exceedingly difficult for organizations to keep track of their software inventories and security status. The problem is exacerbated when companies acquire other companies or merge with them.
Securing even one application can require many tools – e.g., SCA (Software Component Analysis), SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), IAST (Integrated Application Security Testing) and RASP (Runtime Application Self-Protection) – adding complexity to the challenge.
It goes without saying that you cannot secure an application if you don’t know it exists and you’re not certain which tools are required to secure it. Getting a firm grasp of your application portfolio and understanding precisely how your security tools work are essential capabilities in the modern enterprise.
2. Zero Trust DevSecOps
Zero trust has become one of the most powerful concepts in the modern security world. The term was coined by Stephen Paul Marsh in 1994 and later popularized by John Kingervag.[10] Its fundamental premise is do not trust anyone, whether they are inside or outside of the organization. In other words, the default posture is to deny access.
In today’s highly fluid and dynamic software environments, zero trust DevSecOps is imperative. Developers must have the freedom to work rapidly and must integrate security into their products. Again, the idea here is embedding security into products at the point of inception, rather than attempting to bolt it on afterwards.
This requires a fresh mindset in which development and security keep pace with each other. It also requires tools for automating and orchestrating the work of developers and security teams.
3. Continuous Compliance
Back in the days of Waterfall methodology, software was released annually and, as a result, compliance was typically an annual affair involving assessments and an audit. Moreover, compliance was not a standardized process; compliance typically varied by industry and by company size.
As discussed earlier, software development has undergone a tectonic shift. Software is now released once a month, once a week or even several times a day. However, compliance has not caught up with the fast pace of the software development life cycle. For many companies, compliance remains an annual event, with some having quarterly audits of certain controls.
Clearly, we need to hit the “refresh” button. In the modern DevSecOps environment, annual compliance will not suffice. When software is being released several times a day, compliance has to be nearly continuous. Every release that goes out in production should be continuously evaluated with the key standards such as SOC2, GDPR, FedRAMP, HIPAA and OWASP Top 10 (as applicable), and there should be continuous evaluation of the application security posture against control standards to identify exceptions in real-time.
Long Journey Ahead
The capabilities listed above can also serve as a practical framework for developing powerful and effective software security strategies at large, small and medium-sized companies. It’s fair to say that we’re all at the beginning of a long journey, and that our intentions and our integrity will help us determine where we end up. We can shape our destinies and determine our collective future, yet we need to be mindful of the obstacles and difficulties that we will certainly encounter. The journey will require patience, inner strength and the willingness to adapt.
Throughout The Purple Book, our contributing co-authors will offer advice, practices, techniques and suggestions for improving the art and science of software security. Ultimately, our goal is democratizing the practice of software security through the sharing of specialized information and expert knowledge.
Too many executives and decision makers still look at software security as an expense. As professionals who have dedicated our careers to understanding and mastering the various processes involved with providing software security, we view the challenge through a different lens. For us, software security is a mission. It’s our calling and our passion. As stated earlier, we tend to see software security in existential terms. We are fully aware of the risks, and we take our responsibilities seriously. Too much is at stake to do otherwise.
In this unique book, we freely share our skill, expertise and experience. We hope that you and your teams will benefit from reading about our successes, and that you will learn from reading about our mistakes. And of course, we hope that you will join our community and contribute your own stories to our growing compendium of first-hand knowledge. That’s our vision, and we wish you the very best as you navigate the challenges of this fascinating world of software security.
Food for Thought
You cannot secure what you cannot see. 99% of organizations cannot tell how many applications, APIs, and microservices are in their environment, let alone their security posture.
Tremendous business value is trapped because antiquated processes and workflows wear down AppSec engineers and developers.
Once or twice a year compliance is no longer sufficient as releases are done on a weekly or even daily cadence.
Beyond Tools and Techniques
This book is more than a mere collection of stories and anecdotes about software security, and more than a carefully curated list of tools and techniques.
The goal of this book is getting you engaged and actively thinking about the future of software security. When we talk about software security, we’re not just talking about technology issues – we’re talking about human safety issues.
As security practitioners, we have a responsibility and a duty to protect the systems and the data that our world depends upon. That is a mighty task. To be perfectly candid, security is the hardest job in the technology industry. We must rise to the challenge, and we cannot fail. The crushing burden we feel on our shoulders isn’t imaginary – it’s real.
We cannot shrug off our responsibilities. We need to embrace them. They are what makes us different. We’ve all been in meetings where people have talked about “minimum viable products.” We’ve all heard people acknowledge bugs and flaws in software code and then say, “We’ll fix them in the next release.”
In our line of work, those kinds of attitudes don’t fly. We cannot rationalize bad code or deficient processes that make it easier for hackers and criminals to penetrate our systems and steal or manipulate our data.
What’s missing from most conversations about software security are concepts such as discipline and accountability. Everyone involved in the development, testing and rollout of new software must accept that they– not someone else – are responsible and accountable for the consequences of releasing bad code that may compromise the security of systems and data. We need to be proud of more than just meeting our production deadlines and not going over budget. We need to be proud that our systems are secure, and proud that our customers and partners trust us to keep their data safe.
Again, we’ve all been in meetings where someone says that we need to do this or do that within some ridiculously tight timeframe that makes thorough testing difficult or impossible. When these moments occur, our ethos and our shared culture as security professionals require us to push back. We need to be prepared and ready to make a strong business case for safety and security. We need to be ready to show the real costs, both short-term and long-term, of security breaches, data thefts and service disruptions.
Ten years ago, management gurus were advising Chief Information Officers (CIOs) and Chief Technology Officers (CTOs) to “learn the language of business.” Today, those management gurus are advising Chief Information Security Officers (CISOs) to explain the risks of software security in financial terms that senior executives and board members will understand and appreciate. If people don’t remember the Melissa virus, remind them, and tell them what it cost Microsoft. If people don’t fully understand the impact of the SolarWinds hack, take the time to explain it.
We also need to invent a way for incentivizing and rewarding the behaviors that result in great outcomes. Candidly, that will mean rethinking and expanding security budgets. Again, we need to be prepared and ready to make the business arguments in favor of investing more in software security.
As mentioned earlier, we’re experiencing a paradigm shift. Together, we are crossing a membrane between two worlds, one that’s old and familiar, and one that’s new and strange. Nobody ever said that being a security professional would be easy. Let’s pool our knowledge and our resources to make a difference. The Purple Book is designed to make it easier for us to share our collective wisdom and experience and the vision is for it to be the “handbook” which every security practitioner or developer picks up when they have any questions on this area.
This book is also designed to challenge and inspire you. Hopefully, this book will be the first of many editions. We urge you to read it, think about what you’ve read, and then join our community of co-authors. We have a long journey ahead of us, and we look forward to collaborating with you.
Matters of Style
The Purple Book is a truly exceptional collaboration among recognized leaders and experts from top firms in the security field. Each of our contributing authors has a unique voice and style of expression. Their perspectives have been shaped and informed by decades of experience. As a result, each author has a different way of looking at the world, and each represents a different point of view.
We have made a conscious decision to preserve the individual styles of our authors. We believe this decision is in the best interests of our community. We present each chapter in its original and undiluted form, which we believe offers the most value and the greatest power.
Even brilliant minds can disagree, as the brief anecdote about Hawking and Penrose so perfectly illustrates. It’s counter productive and cowardly to minimize differences or smooth over arguments when involved in a search for higher truth.
Our sincere wish is that you will enjoy this book thoroughly and that you will acquire valuable knowledge that will help you on your personal and professional journey in the years and decades ahead.
.svg)
.svg)
