Building in Security at Agile Speed

James Ransome, Brook Schoenfield

• Publisher: Auerbach Publications
• Year: 2021
• ISBN:
  9781000392784
• Edition: 1
• Topic: Informatik
• Subtopic: Softwareentwicklung

Today's high-speed and rapidly changing development environments demand equally high-speed security practices. Still, achieving security remains a human endeavor, a core part of designing, generating and verifying software. Dr. James Ransome and Brook S.E. Schoenfield have built upon their previous works to explain that security starts with people; ultimately, humans generate software security. People collectively act through a particular and distinct set of methodologies, processes, and technologies that the authors have brought together into a newly designed, holistic, generic software development lifecycle facilitating software security at Agile, DevOps speed.

—Eric. S. Yuan, Founder and CEO, Zoom Video Communications, Inc.

It is essential that we embrace a mantra that ensures security is baked in throughout any development process. Ransome and Schoenfield leverage their abundance of experience and knowledge to clearly define why and how we need to build this new model around an understanding that the human element is the ultimate key to success.

—Jennifer Sunshine Steffens, CEO of IOActive

Both practical and strategic, Building in Security at Agile Speed is an invaluable resource for change leaders committed to building secure software solutions in a world characterized by increasing threats and uncertainty. Ransome and Schoenfield brilliantly demonstrate why creating robust software is a result of not only technical, but deeply human elements of agile ways of working.

— Jorgen Hesselberg, author of Unlocking Agility and Cofounder of Comparative Agility

The proliferation of open source components and distributed software services makes the principles detailed in Building in Security at Agile Speed more relevant than ever. Incorporating the principles and detailed guidance in this book into your SDLC is a must for all software developers and IT organizations. — George K Tsantes, CEO of Cyberphos, former partner at Accenture and Principal at EY

Detailing the people, processes, and technical aspects of software security, Building in Security at Agile Speed emphasizes that the people element remains critical because software is developed, managed, and exploited by humans. This book presents a step-by-step process for software security that uses today's technology, operational, business, and development methods with a focus on best practice, proven activities, processes, tools, and metrics for any size or type of organization and development practice.

Chapter 1

Setting the Stage

1.1 Introduction

What we didn’t realize while we were drafting Core Software Security: Security at the Source* was that we were on the cusp of a confluence of a host of software development shifts. At the time, what we dealt with seemed, perhaps, to be disparate threads. But these were, in fact, highly interdependent and interacting strands that would transform software development. It is in the face of this that we’ve decided to write another software security book.

We understand that there exist a multitude of software security books. In fact, there are many very good ones. Including our own more recent publications, there are books devoted to each and every aspect of secure development—from designing secure software through the testing of it. There are books about the management of software security programs, to be sure. But none of these bring these pieces together into that necessary synthesis that deals with software practices of today and, at the same time, represents a dynamic union of technical, cultural, organizational, and managerial skills.

Trust us, software security requires all of its aspects to be individually successful; however, the aspects aren’t independent, but rather are highly interdependent and interactive. Software security is a collection of intersecting, mutually supportive activities, while it also requires cultural change, process, and organizational muscle to succeed in today’s heterogeneous environments.

Besides, we’ve learned a lot in the intervening years about how to build continuous software security programs based upon and natively integrating with Agile methods. This includes the way that these programs are managed, as well as how to build a security development lifecycle (SDL) that doesn’t interfere with how people are actually creating and then fielding software. Our aim is for security to be foundational to software creation, as well as for security practices (the SDL) to be a part of the warp and weft of software development.

As Brook’s Developer-centric Security Manifesto states:

• Enable development teams to be creative and to innovate

• Ensure that developers have as much specificity as required to “deliver security correctly”

____________

* Ransome, J. and Misra, A. (2014). Core Software Security: Security at the Source. Boca Raton (FL): CRC Press/Taylor & Francis Group.

• Build tools for developers to check for correctness

• Deeply participate such that security earns its “rightful place”

• “Prove the value” of security processes and tools*

The authors are hardly alone among security practitioners focused on working with and empowering development versus imposing security on top of it. At the time of this writing, in talking with our peers, we believe that we still belong to a minority. Enabling development to take charge of security through the support and specialized knowledge of security folks unfortunately remains an emergent practice, rather than the norm.

Many of the tectonic shifts that we’ve seen in the years since writing Core Software Security were already underway. However, none of these shifts had profoundly changed the way that much of software was built. Although some development teams might adopt Agile software practices in order to improve their process, few large organizations were in the process of adopting Agile as an organization-wide standard. It is true that smaller organizations, especially startups, might be fully Agile; however, much of this was seen in the software development world as “boutique.”

Continuous integration and continuous delivery (CI/CD) and DevOps were approaches that some cloud native teams were discovering while other teams, focused on other types of targets, were looking on in amazement and wonder at the boost in productivity these enabled. But it wasn’t obvious then how these technologies and approaches might be applied in other contexts and toward other software targets.

As Agile became more and more prevalent, or was just in the process of organization-wide adoption, software security practitioners began to take notice. Indeed, during the drafting of Core Software Security, two of the authors were engaged in an organizational shift to Agile Scrum. It should be no surprise that Agile and iterative development, in general, deserved some focus in the book. In hindsight, we now believe that the software security program that James and Brook were leading at the time produced one of the industry’s first fully Agile SDLs.

Still, much of the software security industry continued building SDLs aligned with Waterfall development methods. The prevalent published SDLs at the time were all linear, conceived in phases, assuming first idea, then requirements, then coding, and followed by testing and other verification, which, if passed, signaled willingness to release. These “phases” follow each other in an orderly fashion, the next not starting until the first has been completed fully. (As we shall see, this tendency towards linearity that does not match how software is actually built continues to plague software security practice.) But that’s not how software is built today.

All of the software development practices that we now think of as “normal” and “typical” were emerging when Core Software Security was published. At that time, many of these were considered by large organizations as “only for special circumstances or small efforts.” Today, we only find Waterfall development confined to particular contexts to which it is well suited: where coding and compilation are expensive and where design misses can be catastrophic (e.g., firmware). Some form of Agile, whether Scrum or another iterative method, has become widespread in organizations large and small, new and old. CI/CD and DevOps methods are also in wide use, even in organizations or contexts that have little to do with cloud development (where these approaches got started). DevOps is a worldwide movement.

Public cloud use is normal for at least some types of applications and data. Although some organizations do maintain private clouds for particular needs, such as compliance or control, those same organizations also use public clouds. Public cloud use is not at all unusual any longer, but rather expected. Long since, most security practitioners have stopped worrying about whether “data are safe in the cloud,” and, rather, focus on what data are in the cloud and how will they be secured. That’s because just about everybody’s data are in a cloud, probably many clouds. It’s no longer a matter of “if” or “whether” but rather “where” and “how to secure.”

____________

* First published at http://brookschoenfield.com/?page_id=256; republished in Schoenfield, B. (2019). Secrets of a Cyber Security Architect. Boca Raton (FL): Auerbach Publications/Taylor & Francis Group, p. 177.

Software development has been seeking its new “normal” for some time. We believe that security must meet and enable that “normal” if we are to stop the seemingly never-ending release of software issues that plague our digital lives. Each of the authors has field-tested the advice and techniques laid out here—both together and individually. We have seen fairly significant improvements unfold through our efforts. Still, taken as a whole, the software industry continues to stumble through issue after issue, allowing compromise after compromise. We know that we can do better. The transformation won’t be easy; it will take concerted effort, focused on that which developers can and will do, coupled with significant organizational support, including security and a somewhat shifted security mindset.

1.2 Current Events

Over the last 10 years or so,* there has been a profound and revolutionary shift in the way that software is produced, employed, and maintained: This paradigm shift has come to be known as “DevOps”—that is, “development plus (and through) operations” united into as seamless and holistic a practice as can be fostered by those involved.

At the same time, a platform for running code and storing data has matured—that is, “the cloud”: public, private, and hybrid. Code still runs on a person’s device, be that a phone, a tablet, a laptop, or desktop computer (all of which are still sold and used). But, increasingly, many of the functions that used to stand alone on a device are in some way, and typically, many ways, tied to services and functionality that runs within a cloud, quite often, a public, commercial cloud offering. There are many compelling reasons to structure (architect) functionality in this way, among them_

• On-demand server workloads (expansion and contraction of compute resources based upon need)

• Ease of operating, maintaining, and updating cloud software

• Maturity of cloud services (allowing operators to delegate some portion of maintenance duties to the cloud provider, including maintenance for security)

• Availability and stability

• Global distribution

• Continuity requirements

• High resource computation needs (e.g., artificial intelligence and machine learning)

• Larger data sets and their manipulation

• Minimizing compute resources needed from devices (often using battery power)

There are computer tasks that are handled much better in a cloud than on a constrained device. The nearly “always connected” state of most devices fosters an architecture that can take advantage of the characteristics of each environment while, at the same time, enabling sufficient inter-environment communications to make cloud service integration seem nearly seamless.

In short, the paradigms for producing and operating software, as well as the way that functionality is architected, have been through fairly profound sea changes such that if security is going to be built and then run effectively, security techniques, tools, and operations must match, and, in fact, integrate easily, fully, and relatively painlessly with the ways that software is currently built and run (and on into the foreseeable future, if current trends continue).

____________

* Patrick Debois is credited with coining the term “DevOps” in 2009 for a conference, DevOpsDays. Kim, G., Humble, J., Debois, P., and Willis, J. (2016). The DevOps Handbook. Portland (OR): IT Revo...