Part 2 — Building an Application Security Programme
An application security programme is your company’s product security game plan, that has a goal of reducing the number of security flaws introduced into the application over the course of its software lifecycle. While, at the same time increasing the difficulty of exploitation (i.e. making it harder for an attacker to find vulnerabilities) and reducing security risks, such as data loss.
It includes high level objectives and activities, that when implemented can provide technical assurance that the application is at a certain level of security maturity.
- For managers, CISO’s and board members it can be used to demonstrate a strategy to reduce cybersecurity risks like interruption of service, reputation damage and loss of customer data.
- For application security professionals, it’s a way to stay focused on the long term strategy, as it can be easy to get buried under the day to day reactive demands of the job.
- For product teams, it’s a guide to how they can introduce security within the different areas of the software development process.
- For wider stakeholders, once summarized, is a way for the security team to publicize a consistent vision and increase the overall security awareness at the company.
Getting Started
When designing an application security programme for a company that develops software, as every company is unique, it’s important to first gather information that will give us more details about the environment and what they are trying to achieve. A few questions to start with could be:
- How many developers are writing code and is there a QA presence already?
- How many security resources are there? If so how many are application security focused?
- What is the security budget? e.g. Will we have enough to pay for external services/tools or hire more people if needed?
- What does the development process currently look like? Are they utilising Agile methodologies, DevOps practices, CD/CI, IaC, languages and tools used, etc?
- What’s the security culture like? Do the tech teams consider security a necessary step in the development process? Or is security seen as a burden or a blocker? And in which case will we need to prioritise security awareness activities?
- Does the company have to comply with any regulatory or compliance standards?
- What is the company’s current application security maturity? Do they have an existing strategy? What is it? And what level of maturity or assurance are they aiming for?
- What is the company trying to achieve? What are the biggest cyber security risks? Or do they just want to satisfy compliance requirements?
Assessing Application Security Maturity
While gathering information about a company, you will likely discover that they already have some security initiatives in place. Or they may already have a security strategy and would like to know if they are on the right track. One way to assess the current strategy or initiatives is to hire a firm to perform a cyber security review. They will likely use standards such as NIST and their own custom built frameworks. At the end of the review you will be handed a report containing a rating of how well the company is doing in each security domain, compared to other similar companies.
This can be quite valuable in itself, however these reviews are often not application security specific and lack the detail needed to truly assess how effective your current strategy is or what you can do to improve it. Instead we can use application security specific frameworks like OWASP OpenSAMM or the Building Security In Maturity Model (BSIMM).
OpenSAMM helps you design a programme using activities and controls recommended by OWASP to assure secure software. It also provides three different levels of maturity that can be compared to the company’s strategy to see where they currently stand.
BSIMM is similar but takes a slightly different approach, by gathering data from other companies in the industry to reveal which activities and controls they are implementing and then giving you a score showing how you compare to others companies. This data also highlights what security initiatives companies are focusing on. A benefit of this approach is that the data (which activities provide the most value to these companies) is likely to be more up to date than frameworks such as OpenSAMM. So if current development practices and processes change rapidly (which then tend to do), then security practices will have to change too. So using real time industry data could be a better way of measuring your security maturity.
Doing an assessment of your current strategy can be valuable for a few reasons:
- If you already have an application security programme or have just designed one then doing an assessment is a good way of proving to yourself and the business that the strategy is justified and built on industry consensus best practices. It can also show progress over time if done regularly and what areas still need improvement.
- If you are at the beginning of your application security journey, it can give you direction, convince management of the current gaps and help prioritise activities that will provide the most value and quickest wins.
Modern Challenges
From the challenges and trends covered in Part 1 — Defensive Application Security in a Modern Organisation, the main difficulty in designing an effective application security programme is that development practices seem to continually and rapidly evolve over time. The way we develop software today is fundamentally different from even just five years ago. We are deploying faster (CD/CI), we have more reliance on PaaS providers like Amazon Web Services (Cloud), tech teams have more autonomy and responsibility (DevOps) and sometimes they even have the ability to choose their own development stacks (complexity).
This continually puts pressure on the security industry, to adapt the way we approach securing software and to continually update security related tools, services and resources to fit into these new frameworks, platforms, languages and practices. Thankfully, fundamental security practices like the need for code review, security testing and secure architecture reviews don’t need updating often. However, the way we implement and execute these practices will need to adapt. As an example let’s take security testing. We know it’s an important part of the overall security of an application, but how do we perform it in a company that deploys to production a few times a day? It’s no longer feasible to perform manual penetration testing for every release, so we will instead have to use a mixture of automated security testing tools and manual testing.
Designing a Programme Using OpenSAMM
Despite the difficulties, the software assurance maturity model (OpenSAMM) mentioned above is a great place to start. The framework can be used to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
The information provided in OpenSAMM will aid in:
- Evaluating an organisation’s existing software security practices.
- Building a balanced software security assurance program in well-defined iterations.
- Demonstrating concrete improvements to a security assurance program.
- Defining and measuring security-related activities throughout an organisation.
The model defines four business functions, which each have three high level security practices. It then describes in more detail what you should be doing under each practice by giving objectives and associated activities to implement. There are quite a few objectives, so to make it easier to digest and improve upon over time, they have split up the objectives into three levels. The first being the simplest to achieve. With the idea of moving to the more mature levels over time as you complete the activities in the first level.
As an example, let’s use the model to add security testing (one of the practices) into the development and quality assurance process of a company that deploys to production a few times a day. Security testing lives in the verification business function so looking at this section of the model and starting with the level one objective and corresponding activities, we learn what is required and what the success criteria will be for that activity.
Although, the model only guides and directs us at a high level as it lacks the implementation and execution details needed to complete the activity. This is by design, as every company will have a different approach due to environmental constraints, hence the importance of the information gathering stage mentioned towards the start of this article.
Starting with the level one activity:
“Conduct penetration testing on software releases”
With the knowledge that the company releases to production multiple times a day, we know that this activity will be hard if not impossible to achieve, as it’s practically infeasible to perform a manual pen test or to review results from a security test for every release.
For companies with these types of constraints it might be necessary to consider completing some or all of level two and three activities as well, to achieve the same assurance around security testing as a company without such constraints. So jumping to the level two activities:
“Utilize automated security testing tools” and “Integrate security testing into development process”
Together they outline a recommendation to run automated security test cases in an automated way which would work better given the constraints of fast release cycles.
So for this company you would end up with a security testing strategy that includes plans to integrate automated security testing tools into the deployment process, to cover off the low hanging fruit. Plus performing manual pen testing for larger, more sensitive releases and even running a bug bounty program to cover off the remaining gaps.
Microsoft’s Secure SDLC
There are other resources available that will help you develop an application security programme. One of which is Microsoft’s Secure SDLC. They define the Security Development Lifecycle (SDL) resource as:
A software development process that helps developers build more secure software and address security compliance requirements while reducing development cost.
It includes very relevant information for web application development but it’s definitely geared more towards companies building desktop applications in .NET. Which makes sense since given it’s developed by Microsoft! It’s definitely not as detailed as OpenSAMM but does have links to resources that are quite useful, like the Microsoft Threat Modeling Tool and training material so is worth checking out.
Putting It All Together
Earlier we briefly went through how to build the “security testing practice” strategy (at a high level) using the OpenSAMM model. That’s a great start, but if you want to build a complete application security programme then you will have to define a strategy, ideally for all security practices in the model, starting with level one and amending the programme with the other levels over time as you start completing the objectives.
However, in the real world most companies don’t have the bandwidth (money and resources) to implement all security practice activities at once. It’s going to take time, normally years depending on the company’s goals. Also some activities are dependent on others, so not all can be completed in parallel.
It’s not something that you can implement effectively overnight, as even with unlimited resources and money you will still hit other roadblocks, like difficulty hiring skilled people to do the work effectively. Also to be truly successful you will have to build security into the development processes, not just as a bolt on function. So you will have to work hard to change the security culture and also heavily involve other stakeholders including the tech teams, as most of the activities will involve the ones producing the software you are trying to secure.
For example they will have to write security related test cases, attend training sessions, use tools to check for vulnerable libraries and fix security issues that are identified.
Depending on the company’s bandwidth and risk appetite, you can adjust how many practices to include in the first stage of the application security programme that you will socialise to other stakeholders. Remember this is a living document that will be added to and adapted over time, so don’t be worried if it does not include every possible activity from the start.
Ideally you want to build a programme with enough activities spread across different business functions that could conservatively be implemented within a few years. Anymore than that and it will likely overwhelm stakeholders, the security team and the business!
Below is an example that shows a high level overview of a programme and the different activities planned for the next few years. This version has been simplified so that it can be used at the start of all business cases and presentations to the tech teams. This is a great way to keep everyone focused, aware of the overall game plan and what’s coming up next.
The Delivery
With the application security programme finished, containing a handful of activities from industry recommended models such as OpenSAMM, taking into account the business constraints, the value add of each activity, the associated costs and the impact to the business. It’s time to socialise the programme and get it approved so the company can start implementing the activities. Although depending on the situation you might have to answer some questions, so it’s important to be ready, a few common ones are below:
Is this the right strategy for us? How does this program compare to other similar companies?
- The BSIMM can be a great way of justifying your program by showing how the company’s application security maturity ranks against other companies.
- There are also firms that can do an IT security threat management maturity review that will give you an independent view of the maturity of your cyber security program compared to other companies in similar verticals.
- Getting in touch with people from other similar companies and asking them what activities and controls they have in their programme.
What are the risks to the business if we don’t implement this program?
- Find examples of other similar companies that have had breaches or attacks.
- Get relevant attack data from places like your web application firewall (WAF) or Security information and event management (SIEM), to demonstrate how often the company is being attacked.
- Gather issue metrics from penetration tests or bug bounty programs to show real risks facing the business. Recent incidents, breaches or even near misses can also help here.
- Focusing on brand reputation damage more so that financial impact can help in some orgs especially if you are an online company where brand reputation matters.
Now that we have our high level application security programme and it has been approved (hopefully!), we have to figure out how to actually implement these activities.
Articles in this series
