Secure SDLC Lessons Learned: #1 Application Catalog

Introduction

As part of Optiv’s application security practice, we spend a lot of time talking with clients about their secure software development lifecycle (SDLC) program (sometimes referred to as the application security program). Common things we hear include:

• We have formal change control processes in place, but we’re unsure how best to incorporate security elements.
• Our development culture is very agile, but we’re struggling to integrate security activities without creating bottlenecks.
• We want to catch security bugs earlier in the software lifecycle. Should we start with static analysis tools, or are dynamic application scanners better to begin with?
• How do we know if our AppSec program is working?

Creating a secure SDLC program can indeed be a daunting task, especially as organizations continue to migrate to market-driven IT approaches like DevOps and cloud-based services. The drive to gain the maximum competitive advantage – or whatever the business goals are – can leave security, risk and compliance teams feeling like they’re chasing horses that broke from the barn. The good news is that there are ways to reign the steeds before they carry everything over the precipice. 

It’s important to point out here that the often-overclocked rapid-release velocity can be a powerful force, one that most business stakeholders will defend to their graves. Security teams would be foolish to mandate a slew of new policies, security gates, and penetration tests and not expect backlash from, well, pretty much everyone else. 

Bottom line, software assurance activities that inhibit or block speed-to-market will be met with much resistance. The modern challenge for many application security professionals is to enable product teams to deploy secure software solutions that meet business objectives, but without impeding the delivery pipeline.

This blog series presents five “lessons learned” from our client conversations relating to secure SDLC in 2016. These include:

1. Application Catalog
2. Assessment Toolchain
3. Knowledge Management
4. Metrics
5. Personnel

These items represent several operational practices that fall outside the boundaries of the leading secure SDLC frameworks and models such as Microsoft SDL, BSIMM and OpenSAMM. We discovered that in each of these areas, organizations were making key implementation-level choices that significantly affected how well their secure SDLC program was being executed.

Secure SDLC Lesson 1: Application Catalog

Building an application catalog is a critical step towards maintaining governance over a secure SDLC program. The primary purposes of the catalog are to provide teams information on which technologies are in place in the enterprise (Java, .Net, third-party libraries, platforms) and criteria for identifying which applications are mission critical and/or high risk. 

Plan

It goes without saying that you can’t truly protect what you don’t know you have. Unsurprisingly, the first step of building the catalog is application discovery. Automated tools are typically used in conjunction with questionnaires, surveys and interviews to collect the base data. 

Inevitably, the question, “What constitutes an application?” will be raised. Very simply, an application is a set of instructions that requires a running computer process to execute. Common application types include “thick” or compiled programs that run on client and server tiers, web applications, mobile applications, RESTful web services and the like. Additionally, an organization may wish to capture details on internal APIs, service-layer applications and custom ETL processes. 

Build

Once some volume of data is collected, applications can start to be categorized and materially described with attribute values. Application catalogs can take many forms, from spreadsheets to purpose-built database applications. The catalog may link to defect tracking systems, source code repositories and security scanners. Regardless of what technology it’s built on, the catalog should be relatively easy to use, update and query. 

Attribute-wise, the application catalog should align with the enterprise's risk assessment framework. Each entry in the application catalog should include at a minimum, the application name, application owner, development team, and other stakeholders such as technical leads that would help with incident response and vulnerability management. Include risk descriptors such as criticality, software composition (e.g. key third-party libraries and platforms), number of users, environments installed, platforms, languages, data sensitivities and compliance touchpoints. Descriptors will vary from one organization to the next, but the intent is to equip users with enough information to make informed risk-based decisions. 

Run

Once an application catalog is in place, it should be leveraged to align enterprise security processes and standards with actual security practices. The catalog, when integrated with the rest of the secure SDLC program, will make evident when and where to perform software assurance activities, how to prioritize security-related bug fixes, and enable security teams to measure progress over time.

For example, an organization may choose to establish a policy that states, “High risk applications will undergo a third-party penetration test annually.” The catalog should clearly identify “high risk applications” while leaving no room for interpretation or argument. 

Not all applications will require all security activities. For example, source code security analysis may only be required of the most critical applications and for code changes touching authentication controls. Secure architecture reviews may only be required of new mission-critical systems.

As you can see, the application catalog hooks into all aspects of the secure SDLC. It truly becomes the system of record for the enterprise's application security program. 

In the next post I will cover secure SDLC lesson #2, assessment toolchain.