Secure, Resilient, and Agile Software Development

Mark Merkow

• Publisher: Auerbach Publications
• Year: 2019
• ISBN:
  9781000041750
• Edition: 1
• Topic: Informatik
• Subtopic: Cybersicherheit

A collection of best practices and effective implementation recommendations that are proven to work, Secure, Resilient, and Agile Software Development leaves the boring details of software security theory out of the discussion as much as possible to concentrate on practical applied software security for practical people. Written to aid your career as well as your organization, the book shows how to gain skills in secure and resilient software development and related tasks. The book explains how to integrate these development skills into your daily duties, thereby increasing your professional value to your company, your management, your community, and your industry. Secure, Resilient, and Agile Software Development was written for the following professionals:

• AppSec architects and program managers in information security organizations
• Enterprise architecture teams with application development focus
• Scrum teams
• DevOps teams
• Product owners and their managers
• Project managers
• Application security auditors

• 
  
  

With a detailed look at Agile and Scrum software development methodologies, this book explains how security controls need to change in light of an entirely new paradigm on how software is developed. It focuses on ways to educate everyone who has a hand in any software development project with appropriate and practical skills to Build Security In. After covering foundational and fundamental principles for secure application design, this book dives into concepts, techniques, and design goals to meet well-understood acceptance criteria on features an application must implement. It also explains how the design sprint is adapted for proper consideration of security as well as defensive programming techniques. The book concludes with a look at white box application analysis and sprint-based activities to improve the security and quality of software under development.

Chapter 1

Today’s Software Development Practices Shatter Old Security Practices

In the decade since Secure and Resilient Software: Requirements, Test Cases, and Testing Methods¹ was published, the world of software development has flipped on its head, shed practices from the past, brought about countless changes, and revolutionized how software is designed, developed, maintained, operated, and managed.

These changes crept in slowly at first, then gained momentum and have since overtaken most of what we “know” about software development and the security tried-and-true methods that we’ve relied on and implemented over the years. Involvement from application security (appsec) professionals—if they happened at all—happened WAY too late, before executive decisions were already made to supplant old practices and the ink was already dried on contracts with companies hired to make the change.

This late (or nonexistent) involvement in planning how to address security hobbles appsec practitioners who are forced to bargain, barter, or somehow convince development teams that they simply cannot ignore security. Compound this problem with the nonstop pace of change, and appsec professionals must abandon old “ways” and try to adapt controls to a moving target. Furthermore, the risks with all-new attack surfaces (such as autonomous vehicles), reliance on the Internet of Things (IoT), and software that comes to life with kinetic activity can place actual human lives in real danger of injury or death.

Although we may have less work on our hands to convince people that in secure software is a clear and present danger, appsec professionals have to work much harder to get everyone on board to apply best practices that we are confident will work.

A decade ago, we were striving to help appsec professionals to convince development organizations to—minimally—address software security in every phase of development, and for the most part over the decade, we saw that far more attention is being paid to appsec within the software development lifecycle (SDLC), but now we’re forced to adapt how we do things to new processes that may be resistant to any changes that slow things down, while the risks and impacts of defective software increase exponentially.

Here’s the definition of software resilience that we’ll use throughout the book. This definition is an adaptation of the National Infrastructure Advisory Council (NIAC) definition of infrastructure resilience:

Software resilience is the ability to reduce the magnitude and/or duration of disruptive events. The effectiveness of a resilient application or infrastructure software depends upon its ability to anticipate, absorb, adapt to, and/or rapidly recover from a potentially disruptive event. ²

In this chapter, we’re going to survey this new landscape for these changes to update our own models on how to adapt to the Brave New World and maintain software security, resilience, and agility.

1.1 Over the Waterfall

New paradigms have rapidly replaced the Waterfall model of software development that we’ve used since the beginning of the software age. Agile and Scrum SDLCs have all but displaced the rigorous (and sometime onerous) activities, and most certainly displaced the notion of “phase containment,” which appsec professionals have counted on as a reliable means to prevent defects from creeping into subsequent phases.

This new landscape includes Agile/Scrum, DevOps, continuous integration/ deployment (CI/CD), and the newest revolution working its way in, site reliability engineering (SRE). To adapt to these changes, we need to understand how the rigor we’ve put into Waterfall-based projects and processes has been swept away by the tsunami of change that demands more software, faster and cheaper.

Changes in the software development paradigm forces change in the software security paradigm, which MUST work hand-in-hand with what development teams are expected to do. While we typically had a shot at inspecting software for security issues at the end of the development cycle (because of phase containment), this control point no longer exists. The new paradigm we had to adopt is called “shift left,” preserving the notion that there are still phases in the SDLC, while recognizing the fact that there aren’t.

1.2 What Is Agile?

In essence, Agile and Scrum are based on the philosophy that software takes on a life of its own, constantly being improved, extended, and enhanced, and these changes can be delivered in hours, rather than weeks, months, or years.

Let’s take a look at the overall scope of the Agile/Scrum process, as shown in Figure 1.1. This diagram encapsulates all the processes described by Scrum and some suggested time frames showing how it compresses time into digestible bites that continue to produce software. Some new roles are also indicated (e.g., product owner and Scrum master), and teams are composed of ALL the roles you formerly find on separate teams using Waterfall methods. This means that one team is composed of the roles responsible for analysis, design, coding, testing, coordination, and ongoing delivery as new features are added, changes are made, or defects removed. It also means that work is not tossed over the wall to the next person in line to do “something.” The team is responsible for all the effort and results.

A minimally viable product (MVP) is the first release of a new software application that’s considered “bare bones” but has sufficient functionality for release to the market before the competition releases their own version. While the actions are not shown in each sprint, they typically follow the same activities you’d find in the Waterfall model, but with more iterations and fewer phase gates that control when software is tested and released. Software is then changed regularly and is never really considered “complete.” This creates severe challenges for appsec.

We’ll examine the Agile/Scrum process in depth in Chapter 2 and look inside each sprint to see where security controls can work.

1.3 Shift Left!

Shifting left requires that development teams address software security from the very inception of a project (Build Security In) and in every step along the way to its manifestation. This means that everyone who has a hand in the specification and development of this new software “product” clearly understands their security obligations and is prepared and able to meet those obligations. Security teams can no longer “do” security for development teams—the teams must be responsible and able to prove they’re living up to those expectations. We’ll talk about how to make this happen with development team awareness, training, and education in Chapter 3.

Figure 1.1 Agile/Scrum Framework (Source: Neon Rain Interactive, licensed under CC BY-ND 3.0 NZ)

Shifting left also requires new ways in how designers create solutions based on the requirements and how they vet those solutions for potential security problems, since they clearly understand that changes in design once an application is developed will cost potentially hundreds of times more than if the defects were caught while architecture and engineering is underway.

Developers are affected because they’re not given the luxury of time for extensive testing, as they often had with former practices. Now, developers may release new code all day and see it deployed within minutes, so it’s vital that these developers “own” the responsibility for securing it, which means developing it using a defensive programming state of mind. Shifting left in the development activity involves active use—and appropriate response—with security checks built directly into their integrated development environment (IDE)—for example, Visual Studio or Eclipse. Although these checks are on incomplete segments of an overall application, coding provides the first opportunity for security inspection and is needed to continue the cycle of appsec.

Testing presents a major challenge to appsec, because tolerance for long-running tests has all but disappeared. Although it’s true that a comprehensive (finished this time) application is needed for comprehensive testing, product managers won’t wait anymore while security tests are run, and vulnerable applications may be deployed (ship it now—fix it later). Shifting left in this environment forces security testing to happen incrementally, in what we used to call integration testing—the point in development at which all the elements come together to build as a new version of the software. If the implementation of security testing is done correctly and responsively to the needs of the product managers, it can serve as a control to actually “break” a build and force remediation of defects. We’ll discuss this at length in Chapters 10 and 11 on testing.

Taken together, shifting left in the appsec space makes it possible to gain the assurance we need that our applications are appropriately secure, but it changes the role of appsec professionals from “doing” appsec to needing to empower everyone who touches software in the SDLC with practical and appropriate knowledge, skills, and abilities.

Although the names and accelerated pace has significantly changed how we deal with appsec, the activities of software development, as we understood them in Waterfall methodologies, are still present. Requirements are still being gathered, designs are still being built, coders are still coding, testers are still testing, and operators are still deploying and managing applications in production. We can apply what we know works to help secure applications in development, but we have to step back and let those who are intimate with the application do the heavy lifting and prove to us that they’ve done what they needed to do!

At the end of the day, software security is a human factors issue—not a technical issue—and for appsec professionals to succeed in implementing application controls, it’s vital to treat the human factor in ways we know work, rather than throwing more tools at the problem.

1.4 Principles First!

Before we dig into the details on how to create and maintain excellence in application security programs, let’s cover some enduring principles that we need to live by in everything we do to secure application software and the processes used to create it:

• Secure application development is a PEOPLE issue, not a technical one.
• Every intervention into the SDLC affects people.
• Shift Left within the SDLC as much of the appse...