Envestnet

Most application security teams that you will find in an organization will be a small team of multi-skilled individuals that have either come up through software development or through penetration testing. The ex-developers bring a unique perspective on software development and often sympathize with the engineering teams who work to close discovered issues. The penetration testers are often not as interested in how to close an issue but instead more focused on breaking applications. The two marry well in an application security team as the ex-developers, now application security engineers, can take the findings from their teammates and turn them into actionable issues for the engineering teams to resolve. Likewise, the application security engineers can help guide the penetration testers to “hot spots” in the application that need deeper testing beyond the security tools used in the software development life cycle (SDLC).

There are a lot of different security tools that can be integrated into the SDLC to turn overvulnerabilities. Static application security testing (SAST) can find security issues in your non-running code. Dynamic application security testing (DAST) can test your running applications for vulnerabilities through an outside-in view. Interactive application security testing (IAST) can be instrumented into the running application to see vulnerabilities as they occur. Softwarecomposition analysis (SCA) will scan your third-party libraries for known weaknesses and vulnerabilities. Then of course there is container scanning, infrastructure as code scanning, and cloud posture scanning. All of which will rain vulnerabilities down on the application security and engineering teams.

“It’s time to start asking our application security teams to approach securing our applications in a manner that aligns with the methods used in today’s engineering teams. It’s time to modernize application security”

Where this becomes problematic is when the organization lacks a strong vulnerability management program that includes several key factors. One is the ability to know who owns the vulnerability. This sounds simple but is indeed difficult. Consider a vulnerability that is found in a single component in your organization. That component may be packaged by several other components to build a complete application that is delivered to your clients. Who owns the fix? If you said the developer of the lowest level component, you’d be right. However, locating that team or developer is sometimes very difficult especially when the vulnerability that is found is abstract. Another key component of vulnerability management is to know where to send the request to fix. This is often done through a ticketing system like the defect tracking system that is used for normal bug fixes. Lastly, it is important to time bound the fix for the vulnerability. This will be based on the criticality of the vulnerability versus the organization’s (or application’s) risk. The time to remediation should be as short as feasible, based on standards, and consistent across the organization.

One of the largest struggles that application security teams have is the ability to be everywhere all the time. So far, what has been described is how application security has been approached for a very long time. It’s slow, reactive, and is often playing catch-up with the engineering technology. Often the application security team is not fully covering the applications in the organization due to the team size constraints, or visibility into all the applications in scope.

How do we fix this? One tactic is to create anapplication security team that mirrors the way engineering works today and brings a service-oriented approach to their model. Application security with this mindset allows for the team to better scale their capabilities and deliver them to the broader organization by packaging their services into callable APIs. For instance, a service that can run on-demand security tests. Another service can be used to scrub sensitive data. Yet another can provide access to certificate issuance and management functions. Each of these should be easy enough to integrate into any stage of the SDLC whether during development, build time, or in pre-production environments.

Align these services with an overall ecosystem of application security that includes quick hit and always on training, developer environment integration with security tools that provide immediate feedback, security reference architecture built on the organization standards, and a fast feedback loop that delivers vulnerability information to the development team as early as possible is the making of strong ambient application security.

The engineering methodologies have evolved over the years, but application security has largely relied on the tried and true method of discovering vulnerabilities and presenting them to the engineering teams to resolve. It’s time to start asking our application security teams to approach securing our applications in a manner that aligns with the methods used in today’sengineering teams. It’s time to modernize application security.