Most companies that we work with are building software. That’s not a surprise because that’s our niche. Yet a surprising number of those companies don’t know about application security programs. Even companies with sophisticated security teams often struggle with application security and don’t take a programmatic approach to it. Why? Because it is really hard and requires knowledge of how application development and SDLC’s work. In this post, I’ll talk about some of the high level parts of successful AppSec Programs we’ve seen.

Inventory

One of the first things we need to effectively run an AppSec program, is an inventory of what applications we have. At its simplest, this could be a spreadsheet. Ideally, it is automated or dynamically updated. Once we have an inventory, we can map activities and costs to that. Without an inventory, we can’t do anything concrete with the program.

Tiers

Many companies we work with have hundreds, thousands or even tens of thousands of applications, services, repositories, etc. Even for those with just 10, in order to help us focus, we need to decide which applications we really care about.

We usually introduce the concept of Tiers here, Tier 1, Tier 2 and Tier 3. Then we work with a client to decide what criteria make an application a Tier 1 application.

Activities

There are dozens of things we can do to improve the security of our applications. We can use tools like SAST, DAST, IAST, WAF, and on and on and on. Those may be important, but in many cases, we can be pretty sure that the inventory will dictate what is realistic. If we have 10,000 applications, we can’t just point a SAST tool at it and expect to to work in any kind of time frame.

It can be dangerous to confuse a specific activity with a program. As a specific example, some tools (eg. SAST or IAST) believe that they are your dashboard for application security. That negates all the other parts of the program that you need (eg. training, security requirements, etc.).

A key part of building an AppSec program is working with stakeholders to know what activities are going to be fundable. Another key part is to work on cost effective activities while building to more expensive ones. A final key point about program activities is that the best fit activities are different at every company we work with. At the end of the post, we’ll talk about things that we do as part of AppSec programs, but it is not the same and needs to fit the development culture and SLDC.

Budget

Building a program without thinking about budget won’t work. Once we know about activities, and which will be applied to which applications we can start to know how much work we have. That means we can estimate budgets.

We need to get beyond the idea of 10% incremental increases in AppSec budget. Having an inventory and a proactive idea about what we need to do for which application gives us a constructive way to build a budget. We all know that if we just say we want security but we don’t fund it, we won’t get it.

Complexity

Something that is fundamentally tricky about AppSec is that it is complex. As we’ve written in the past, there are some things that tools just won’t find.

By embracing a customized program that values training and security requirements we invest in our people and their unique ability to understand potential security needs. If our program doesn’t emphasize that human factor, we may be strong in some ways but we won’t be in others.

Why A Program?

A program is like a plan of plans. Maybe each software project has a mini plan for application security. The program is the assembled set of all project plans for doing software security.

The program can develop to include dates, costs, and metrics. The whole idea is that we want to know if we are succeeding or failing – then we want to be able to improve in targeted ways.

References

Example AppSec Modules

  • Baseline security requirements
  • Automating inventory
  • Automating dependency checks
  • Automating static analysis (SAST)
  • Automating dynamic scanning (DAST)
  • Automating configuration checks (AWS)
  • Security requirements
  • Security unit tests
  • Encryption
  • Single Sign On
  • Security Logging (Signal)
  • Security Audit Logs (Audit)
  • WIKI Presence
  • Threat Model
  • Sprint Security Requirements
  • Sprint Security Checklists
  • Sprint Security Unit Testing
  • Training
  • Code Review
  • App Pen Test
  • OWASP ASVS
  • OWASP OpenSAMM
  • Cloud Auditing
  • Log Review
  • Tool Selection or Review
  • Security Intelligence
  • Data Classification
  • Deep Dive on Credit Card Flow
  • Deep Dive on EncryptionPassword Flow and Handling Review
  • Honeypots
  • Honey Emails
  • Maturity Model Integration
Matt Konda

Matt is a software engineer. He's our CEO and former Chair & OWASP Board Member.

Want to stay up to date with the lastest from Jemurai?

Sign up for our monthly newsletter!