Practical Security for Agile and DevOps

Mark S. Merkow

• Editorial: Auerbach Publications
• Año: 2022
• ISBN:
  9781000543421
• Edición: 1
• Categoría: Informatique
• Categoría: Technologies de l'information

This textbook was written from the perspective of someone who began his software security career in 2005, long before the industry began focusing on it. This is an excellent perspective for students who want to learn about securing application development. After having made all the rookie mistakes, the author realized that software security is a human factors issue rather than a technical or process issue alone. Throwing technology into an environment that expects people to deal with it but failing to prepare them technically and psychologically with the knowledge and skills needed is a certain recipe for bad results.

Practical Security for Agile and DevOps is a collection of best practices and effective implementation recommendations that are proven to work. The text leaves the boring details of software security theory out of the discussion as much as possible to concentrate on practical applied software security that is useful to professionals. It is as much a book for students' own benefit as it is for the benefit of their academic careers and organizations. Professionals who are skilled in secure and resilient software development and related tasks are in tremendous demand. This demand will increase exponentially for the foreseeable future. As students integrate the text's best practices into their daily duties, their value increases to their companies, management, community, and industry.

The textbook was written for the following readers:

• Students in higher education programs in business or engineering disciplines

• 
  
  

• AppSec architects and program managers in information security organizations

• 
  
  

• Enterprise architecture teams with a focus on application development

• 
  
  

• Scrum Teams including:

• 
  
  

  • Scrum Masters

  • 
    
    

  • Engineers/developers

  • 
    
    

  • Analysts

  • 
    
    

  • Architects

  • 
    
    

  • Testers

  • 
    
    

• DevOps teams

• 
  
  

• Product owners and their management

• 
  
  

• Project managers

• 
  
  

• Application security auditors

• 
  
  

• Agile coaches and trainers

• 
  
  

• Instructors and trainers in academia and private organizations

• 
  
  

Chapter 1 Today’s Software Development Practices Shatter Old Security Practices

CHAPTER OVERVIEW

Software development techniques and methodologies leapfrog over themselves constantly, making efforts to secure them a moving target that won’t wait. To address this fact, it’s essential that application security controls and their implementation are as agile as the development processes they support. In this chapter, you’ll find some strategies to address these moving targets, while applying tried-and-true security control implementations that remain standing over time.

CHAPTER TAKEAWAYS

• Examine the changes in the software development lifecycle (SDLC) since its inception.
• Explain the Agile/Scrum Framework for modern day software development.
• Describe the Shift Left approach to implementing software development security controls.
• Understand the principles that apply to successful implementation of application security programs.

In the decade since Secure and Resilient Software Development¹ 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 of application security (appsec) professionals—if it happened at all—happened WAY too late, after 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 insecure 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 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 SDLC. Now, however, 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 sometimes onerous) activities, and have 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/continuous deployment (Cl/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.

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.

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

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 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 where we focus 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 have 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 muc...