Preface

Software is eating the world. Developers are the new kingmakers. The internet of things means there will be a computer in every light bulb.

These statements indicate the growing dominance of software development, to the point where most people in the world will never be further than a meter away from a computer, and we will expect much of our life to interact with computer-assisted objects and environments all the time.

But this world comes with some dangers. In the old world of computing, security was often only considered in earnest for banking and government systems. But the rise of ubiquitous computing means a rise in the value that can be realized from the abuse of systems, which increases incentives for misuse, which in turn increases the risks systems face.

Agile software development techniques are becoming rapidly adopted in most organizations. By being responsive to change and dramatically lowering the cost of development, they provide a standard that we expect will continue to grow until the majority of software is built in an Agile manner.

However, security and Agile have not historically been great bedfellows.

Security professionals have had their hands full with the aforementioned government, ecommerce, and banking systems, trying to architect, test, and secure those systems, all in the face of a constantly evolving set of threats. Furthermore, what is often seen as the most fun and exciting work in security, the things that get covered on the tech blogs and the nightly news, is done by teams of professional hackers focusing on vulnerability research, exploit development, and stunt hacks.

You can probably name a few recent branded vulnerabilities like Heartbleed, Logjam, or Shellshock (or heaven forbid even recognize their logos), or recognize the teams of researchers who have achieved a jailbreak on the latest iPhones and Android devices. But when was the last time a new defensive measure or methodology had a cool, media-friendly name, or you picked up the name of a defender and builder?

Security professionals are lagging behind in their understanding and experience of Agile development, and that creates a gap that is scary for our industry.

Equally, Agile teams have rejected and thrown off the shackles of the past. No more detailed requirements specifications, no more system modeling, no more traditional Waterfall handoffs and control gates. The problem with this is that Agile teams have thrown the baby out with the bathwater. Those practices, while sometimes slow and inflexible, have demonstrated value over the years. They were done for a reason, and Agile teams in rejecting them can easily forget and dismiss their value.

This means that Agile teams rarely consider security as much as they should. Some of the Agile practices make a system more secure, but that is often a beneficial side effect rather than the purpose. Very few Agile teams have an understanding of the threats that face their system; they don’t understand the risks they are taking; they don’t track or do anything to control those risks; and they often have a poor understanding of who it even is that is attacking their creations.

Who Should Read This Book

We don’t know if you are an Agile team leader, or a developer who is curious or wants to know more about security. Maybe you are a security practitioner who has just found an entire development team you didn’t know existed and you want to know more.

This book was written with three main audiences in mind.

The Agile Practitioner

You live, breathe, and do Agile. You know your Scrum from your Kaizen, your test-driven-development from your feedback loop. Whether you are a Scrum Master, developer, tester, Agile coach, Product Owner, or customer proxy, you understand the Agile practices and values.

This book should help you understand what security is about, what threats exist, and the language that security practitioners use to describe what is going on. We’ll help you understand how we model threats, measure risks, build software with security in mind, install software securely, and understand the operational security issues that come with running a service.

The Security Practitioner

Whether you are a risk manager, an information assurance specialist, or a security operations analyst, you understand security. You are probably careful how you use online services, you think about threats and risks and mitigations all of the time, and you may have even found new vulnerabilities and exploited them yourself.

This book should help you understand how software is actually developed in Agile teams, and what on earth those teams are talking about when they talk about sprints and stories. You will learn to see the patterns in the chaos, and that should help you interact with and influence the team. This book should show you where you can intervene or contribute that is most valuable to an Agile team and has the best effect.

The Agile Security Practitioner

From risk to sprints, you know it all. Whether you are a tool builder who is trying to help teams do security well, or a consultant who advises teams, this book is also for you. The main thing to get out of this book is to understand what the authors consider to be the growing measure of good practice. This book should help you be aware of others in your field, and of the ideas and thoughts and concepts that we are seeing pop up in organizations dealing with this problem. It should give you a good, broad understanding of the field and an idea for what to research or learn about next.

Navigating This Book

You could read this book from beginning to end, one chapter at a time. In fact, we recommend it; we worked hard on this book, and we hope that every chapter will contain something valuable to all readers, even if it’s just our dry wit and amusing anecdotes!

But actually, we think that some chapters are more useful to some of you than others.

We roughly divided this book into three parts.

Part 1: Fundamentals

Agile and security are very broad fields, and we don’t know what you already know. Especially if you come from one field, you might not have much knowledge or experience of the other.

If you are an Agile expert, we recommend first reading Chapter 1, Getting Started with Security, to be sure that you have a baseline understanding of security.

If you aren’t doing Agile yet, or you are just starting down that road, then before we move on to the introduction to Agile, we recommend that you read Chapter 2, Agile Enablers. This represents what we think the basic practices are and what we intend to build upon.

Chapter 3, Welcome to the Agile Revolution, covers the history of Agile software development and the different ways that it can be done. This is mostly of interest to security experts or people who don’t have that experience yet.

Part 2: Agile and Security

We then recommend that everybody starts with Chapter 4, Working with Your Existing Agile Life Cycle.

This chapter attempts to tie together the security practices that we consider, with the actual Agile development life cycle, and explains how to combine the two together.

Chapters 5 through 7 give an understanding of requirements and vulnerability management and risk management, which are more general practices that underpin the product management and general planning side of development.

Chapters 8 through 13 cover the various parts of a secure software development life cycle, from threat assessment, code review, testing, and operational security.

Part 3: Pulling It All Together

Chapter 14 looks at regulatory compliance and how it relates to security, and how to implement compliance in an Agile or DevOps environment.

Chapter 15 covers the cultural aspects of security. Yes, you could implement every one of the practices in this book, and the previous chapters will show you a variety of tools you can use to make those changes stick. Yet Agile is all about people, and the same is true of effective security programs: security is really cultural change at heart, and this chapter will provide examples that we have found to be effective in the real world.

For a company to change how it does security, it takes mutual support and respect between security professionals and developers for them to work closely together to build secure products. That can’t be ingrained through a set of tools or practices, but requires a change throughout the organization.

Finally, Chapter 16 looks at what Agile security means to different people, and summarizes what each of us has learned about what works and what doesn’t in trying to make teams Agile and secure.

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 elements such as variable or function names, databases, data types, environment variables, statements, and keywords. If you see the ↲ at the end of a code line, this indicates the line continues on the next line.

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 determined by context.

Tip

This element signifies a tip or suggestion.

Note

This element signifies a general note.

Warning

This element indicates a warning or caution.

O’Reilly Safari

Note

Safari (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.

Members have access to thousands of books, training videos, Learning Paths, interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

  • O’Reilly Media, Inc.
  • 1005 Gravenstein Highway North
  • Sebastopol, CA 95472
  • 800-998-9938 (in the United States or Canada)
  • 707-829-0515 (international or local)
  • 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/agile-application-security.

To comment or ask technical questions about this book, send email to .

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

First, thank you to our wonderful editors: Courtney Allen, Virgnia Wilson, and Nan Barber. We couldn’t have got this done without all of you and the rest of the team at O’Reilly.

We also want to thank our technical reviewers for their patience and helpful insights: Ben Allen, Geoff Kratz, Pete McBreen, Kelly Shortridge, and Nenad Stojanovski.

And finally, thank you to our friends and families with putting up with yet another crazy project.

Get Agile Application Security now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.