07 Jun, 2018

Have You Adapted Your AppSec?

by David Lindner

For the past 20 years, application security has been built into many organization’s development processes and practices. When the Open Web Application Security Project (OWASP) was established in 2001, it bolstered the importance of application security. Since then, application security practices have been built to include many different processes, but they were all built based on a waterfall approach. Some of these different processes are (in no particular order):

  • Secure Development Standards
  • Application Risk Categorization
  • Secure Design Principles
  • Threat Modeling
  • Testing and Verification
  • Software Integrity
  • Security Tooling
  • Secure Development Training

You will be hard pressed to find an organization that does all of the above, much less does it all well. Performing all or any of these application security practices and processes takes executive-level support and buy-in, and requires a program that promotes collaboration between Development, Security, and Operations; however, for the past 20 years, we have kept these teams and people separate from one another.

Traditional AppSec

Figure 1: Developers and Security talked but neither were heard nor understood.

We designed application security processes in a bubble: ran assessments, ran tools, performed threat models, and committed risks to security issues trackers. We built security debt at alarming rates, and in many cases the time to address security defects took months-if not years-all while continuing to add more and more security issues to the pile. Once developers finally got to the issues they had no way to interface with security personnel. They attempted to fix the issues with limited information, and traditionally failed to implement a strong enough or complete fix.

This disparate application security process needed to change, and quickly, because our development processes moved from Waterfall to Agile to DevOps. We swiftly moved from 9-12 months between production deployments to 9-12 minutes. We can’t stop and wait for security tests anymore. We don’t have time to look at multiple bug trackers and request different permissions. We can’t wait days between asking questions about findings or risks and getting answers on how to implement fixes. The application security process has to adapt! So, how do we do that?

Some have called the “new” approach to application security “DevSecOps.” DevSecOps is an all-encompassing term for Development, Security, and Operations. In reality, it is a fancy way to say, “Hey guys, let’s stop making this hard on ourselves and work together, mmmkay?” Now you may be asking, “How can we make some changes to implement a smoother running DevSecOps team?” Well, I have four specific areas you can improve to better align application security in your fast-paced development cycles:

1. Threat Model and Design Review

Regardless of your development methodology, threat modeling or a secure design/architecture review is critical. This is your chance to evaluate how well you have thought through the defenses your application needs and considered different threat vectors or actors. You need to build an initial threat model, and each subsequent update, story, or feature can cover the delta or changes. Here you can identify how the potential threats affect the application/data and identify what controls are needed and where they should be placed in code or infrastructure. You can then use the results to verify proper placement later in the DevSecOps process. Now you might be saying to yourself, “This is a waterfall process,” and you may be right, but reality tells us we can do proper threat modeling and design by focusing on collaboration and quick iterative reviews. Ultimately resulting in fewer fixes or breaks later in the DevSecOps process.

It’s also important to note how incredibly expensive design flaws are to fix if they make it all the way through to implementation. They will certainly extend time to delivery and in some cases, require rearchitecting. Try as you might, coding yourself out of a flawed design is no fun, hence the importance of Design Review.

2. Collaboration

If you’ve been in the industry for a number of years, you’ve likely seen how Development, Security, and Operations have very little interaction, and in some cases, are prevented from communicating directly. Development writes code and fixes bugs in its defect trackers. Security does penetration tests or runs tools, writes reports and/or submits risks to its security defect trackers. Operations stands up and configures infrastructure, deploys code, and tracks any CVEs or bugs in its supported tools, hardware, etc. The separation of these groups has created long lingering security flaws and issues when infrastructure is changed or updated without Development knowing or testing.

Teams need a platform to be able to openly communicate with each other, whether that be through setting up a dedicated slack channel, having daily scrums, or some other centralized communication. Likewise, Security needs direct access to code, to commit data, to defect trackers, and the ability to perform a manual check of code in process when security relevant code has been changed or added.


Figure 2: Integrate developers and security through collaborative tools.

For audit, compliance and regulatory requirements, there may still be a place for the age-old point-in-time assessments. But the fact is, this process does not support Agile or DevOps development processes in an integrated way and only increases security debt. We have learned over the years you cannot pentest your way secure. Instead, you should focus on having more collaboration and iterative reviews to create a continuous and solid understanding of your application’s security posture. Not just one from testing 9-12 months prior.

3. Tooling and Security Automation

Tooling has always had a place in application security. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools have existed for years. Not unlike a manual assessment, the tools were run, they generated reports, and the reports either sat in someone’s email inbox or the risks were added to a security bug tracker. As time went on, we added Web Application Firewalls (WAF), Interactive Application Security Testing (IAST), Runtime Application Self Protection (RASP), and IDE Tooling. These all played their part in the overall process, but for the most part were disparate systems with their own setups and process.

Fast forward a few years into the Agile and DevOps era. You now need to use the tools you have invested in, but in a more automated fashion. The best way is to build tooling into four distinct places: Integrated Development Environments (IDEs), Code Repositories, Continuous Integration (CI) and Continuous Delivery (CD) pipeline, and Infrastructure (containers, infrastructure as code, orchestration, etc).

Tools and Automation

Figure 3: Build and automate security tooling into your process.

There isn’t a blueprint for which tools will work for your organization, or at which stage the tools will work in your environment. Use the tools you have invested in, but use them in a more automated and collaborative fashion. The key is to make the process as automated and repeatable as possible AND place the output directly in your defect tracker where developers already work.

4. Defect Tracking and Reporting

In years past, defect trackers were abundant and distributed through many teams in a single organization. Development had its own, Security had its own, Operations had its own, etc. This was a very inefficient process where lack of access, lack of tracking, and duplication of issues were common. Why do we manage our application, security, cloud, and infrastructure issues in different places? Roles are being reassigned and duties are changing hands, but our tooling and visibility dashboards haven’t caught up yet.

Here we are in 2018 and we can no longer live with the fact that security defects aren’t addressed for months and that issues are duplicated across multiple systems throughout our organizations. The best way to address this is make sure your defect trackers are all combined into a single tracking system. Roles have changed and some people are developing code, deploying code, and managing infrastructure. It only makes sense to track issues in a single location. Having a single defect tracker provides insight into all open defects or issues for everyone who needs it, allows duplicates to be quickly combined, and provides management with a quick and accurate generate report of current issues and statuses.

Centralized Defect Tracker

Figure 4: Have a single defect tracker used by Development, security, Operations, and Management.

Rather than having Development, Security, and Operations exist autonomously, integrate all the teams/processes and you should have something similar to our new DevSecOps process:

NEW DevSecOps Process

Figure 5: The new “DevSecOps” process.

The keys to a successful DevSecOps process are, defining and designing security early, working more collaboratively, using automation and tooling, and centralizing defect tracking and reporting. Implementing these four things will increase the speed and accuracy of finding and fixing issues. Most important, doing these things successfully will allow developers to stay on track to keep the business happy and to create secure software to protect customers and their data.