Developing an Effective Application Security Program

In this blog, we will discuss the approach to building an application security program that aligns with the development needs of the organization. Building a roadmap begins with three key activities:

1. Determining organization’s current application security posture
2. Identifying gaps and immediate needs of the organization
3. Developing the roadmap that addresses the short and long-term goals of the organization

Understanding current security posture

Before you get started into the role of an application security leader, following key things should be noted

• Understanding the organization structure
• What tools are currently implemented ?
• What vulnerabilities exist ?
• What policies exist ?
• What is the development roadmap (both for the product and the application security )?
• What boards, committees, or community groups exist that application security should be a part of?

Understanding the security tool landscape

Create a matrix of tools that exists in the organization. Following are some of the common tools used for application security

• Static application security testing (SAST)
• Dynamic application security testing (DAST)
• Interactive application security testing (IAST)
• Software composition analysis (SCA)
• Web application firewall (WAF)
• Run-time application security protection (RASP)
• Threat modelling tools

Key factor here is to understand what is the coverage for these tools are. Many times, the coverage of these tools will not be sufficient due to various factors like license constraints , lack of proper inventory , incomplete configuration , tools that are turned off due to reasons like higher false positive rate. To address these issues , security teams should have a matrix that lists the products in the organization against the software security tools. Having a list helps us to address the important question “What is the impact of an ongoing attack?”.

To understand the importance of having the list, we will look at how this would have immensely helped in responding to an attack like Log4j. The remediation for Log4j came in different forms like configuration changes in the running component that removed the ability to make calls to a remote server where the malicious code would reside , upgrade to the latest version of Log4j.

Security teams struggled to understand the impact of the vulnerability and how it affected their organizations. Having complete security coverage would have helped answer some of the following questions:

• Where is Log4j used in the organization?
• Who is responsible for making the updates to Log4j?
• What are the compensating controls in place?
• How long until the fix can be applied across the known locations?
• What is the residual risk of the vulnerability once the compensating controls are in place?

For Log4j , some of the compensating controls were blocking external access to malicious servers, configuring WAF & load balancer to drop the malicious requests, having detection tools to check whether the system was compromised , using SCA tools to identify whether the build contained any vulnerable libraries.

What vulnerabilities do you have?

Begin on the Right — Analyze all types of testing conducted to date, review historically reported vulnerabilities, identify major security issues, and determine how they were discovered — whether through bug bounty programs, penetration testing reports, or other security tool reports. This will assist us in refining our focus areas. If historical reports indicate that vulnerabilities are primarily due to outdated software, we can infer that we should concentrate more on securing the code base. Conversely, if the vulnerabilities stem from bot attacks, the team can adjust configurations on the WAF and load balancers.

One of the first steps in any vulnerability management program is to make sure your data is accurate and that there is a clear path to resolution for the engineering team. Following are some of the key tasks required to manage known vulnerabilities

• Categorize and associate timelines to the open issues
• Ensure that the issues have assigned owners
• Validate older issues — Ensure older vulnerabilities that require large design/architecture change are resolved in a timely manner from an upgrade or decommissioning
• Ensure that the issues have clear instructions to developers on resolution
• Have a single location for all your open vulnerabilities

Above tasks should address the question

“What vulnerabilities are most important to the organization and pose the biggest risk?

The application security team should provide a simple set of charts that show the overall organization exposure to the known vulnerabilities.

Sample vulnerability tracker

Understanding the organization’s security goals

The goals set by the CISO typically focus on defending the organization and enabling business operations by implementing the right controls to keep the organization safe. Most software organizations aim to achieve three fundamental goals:

• Meet client requirement
• Deliver on time
• Maintain high quality and satisfaction

When application security imposes new requirements or provides guidance, it can cause delays if the development team was not expecting these changes.Aligning business and security goals is essential. While businesses prioritize gaining competitive advantages and speed to market, the security organization focuses on interpreting various frameworks and standards like ISO, NIST, SANS, and OWASP to ensure protection. Both sides should work towards a common ground to achieve these objectives.

Identifying the gaps

Gap analysis — A gap analysis is the process of looking at the actual performance or state to compare it to a potential performance or state. The intention is to discover opportunities for improvement or identify gaps in the state.

The organization needs to first identify its goal and the purpose of the gap analysis. Different organizations will have different reasons for addressing gaps, such as contracts, compliance, or customer needs.

Purpose of addressing open security gaps in the organization:

1. Compliance and Regulation: Ensuring adherence to regulations like HIPAA/HITECH for healthcare data security and PCI DSS/SOX for financial data protection.
2. Internal Standards: Adapting security standards to new technologies, such as moving to the cloud.
3. External Standards: Using guidelines like NIST, CIS, or ISO to shape internal security practices, aligning with trusted and well-vetted standards.

Inputs for the gap analysis

Gap analysis will be based on the current state of all functions under the application security team.

Some examples of current state goals for a given function.

As an example , teams can focus on one area like security scanning capabilities. One can start with the simple gap analysis like which development product has what type of scan available [ SAST or DAST or SCA ] for each of their pipeline.

Teams can further deepen the analysis by considering:

1. What is the configuration setup of these tools?

2. What is the alert process?

Once the gap analysis for the security scanning tools is complete, the team can create an implementation roadmap for integrating the missing tools or benchmarking the configuration for each pipeline. A similar exercise can be carried out for each of the other functions.

In my next article, I will discuss a sample application security roadmap and the key metrics for measuring its effectiveness.