Services
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.
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.
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.
There are dozens of things we can do to improve the security of our applications. We can use tools like SAST, DAST, IAST, WAFA Web Application Firewall (WAF) is a type of cybersecurity technology designed to protect web applications from a variety of attacks, such as SQL injection, cross-site scripting (XSS), and other common web-based threats. A WAF sits between the web application and the internet, monitoring and analyzing incoming traffic in real-time. It can detect and block malicious traffic before it reaches the web application, providing an additional layer of defense against cyber attacks. WAFs can be implemented on-premises or through a cloud-based service and can be configured to suit the specific security needs of the web application they protect. WAF is often required by security standards such as PCI-DSS., 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.
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.
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.
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.
