How to Build a Mature Application Security Program
Fully integrating application security into the software development process is a major challenge that requires not only the right tools but also a mature development culture. This article shows the vital stages of building a mature AppSec program, as discussed by Invicti founder Ferruh Mavituna on Enterprise Security Weekly.
Your Information will be kept private.
Your Information will be kept private.
Baking application security into the software development process is a major challenge that requires not only the right tools but also a mature development culture. This article shows the stages of building a mature AppSec program, as discussed by Invicti founder Ferruh Mavituna on Enterprise Security Weekly.
Ferruh Mavituna on Building an AppSec Program
In episode #209 of the Enterprise Security Weekly cybersecurity podcast, Ferruh Mavituna talked to Paul Asadoorian, Matt Alderman, and Adrian Sanabria about the challenges that enterprises face when trying to incorporate security into their software development lifecycle. Watch the full video below and read on for a step-by-step guide to building a mature application security program.
The Link Between SDLC Maturity and AppSec Maturity
For all the talk about building DevSecOps and shifting security left in the software development lifecycle (SDLC), there is one fundamental assumption that many discussions miss. Quite simply, to fully incorporate security into your SDLC, you need to have a mature SDLC process in the first place. In other words, your application security program can only be as advanced as the SDLC pipeline itself.
To work at scale, application security must match the level of integration and automation found in modern software development. Traditional security testing methods and processes focused on manual testing, verification, and issue management are slow, resource-intensive, and cannot hope to match the scale of software development efforts. For any large organization, there are at least 5 major steps on the road to a fully mature, hands-off application security program.
Step 0: Take Care of the Basics
Before we start talking about discovering assets, scanning for vulnerabilities, writing more secure code, and all the other exciting things in web application security, every organization needs to start from the basics. Having a cutting-edge application security solution won’t help when you have unpatched servers, weak passwords, misconfigured firewalls, unsecured devices – the mundane but vital side of IT security.
The application layer resides on top of a huge technology stack, so web application security also needs to start there. Doing the groundwork for the mission-critical applications you already know about lets you quickly bag the easy wins and helps to ensure that your application security efforts are not wasted – eliminating an SQL injection in a login form won’t do much good if you can get hacked due to weak passwords.
Step 1: Know What You Have
The first step on the road to secure your web assets is knowing what they are. Every organization knows and secures its crown jewels, but in a large enterprise, hundreds of other websites and applications could be slipping under the radar. Until you have a full picture of your web attack surface, you have no way of deciding what to do to measurably improve security.
Invicti has its own discovery module that provides quick results with very little initial setup and is continually being refined, so actually running discovery and getting results is very easy. The challenge at this stage is deciding what to do about all the assets that are discovered. Invicti is now moving from just providing the tool to actively helping customers address this with best practices.
One step that is crucial for efficient issue assignment later is to determine asset owners. While this is time-consuming, it is a one-time operation that will pay dividends downstream.
Step 2: Find Your Weaknesses
Once you know what you want to scan, it’s time to run vulnerability scanning. This step is highly dependent on the quality of your tools. The better the tool, the less initial configuration you will need and the more accurate your results will be. If you have a high-quality modern DAST solution, you just need to configure authentication as required and click a button – and within hours, you have your scan results.
As an industry leader, Invicti provides broad test coverage across modern web applications and features Proof-Based Scanning to automate the process of confirming many high-severity vulnerabilities. This becomes extremely important in the next step: actually addressing the issues that are found.
Step 3: Address Issues
So far on the road to security, the focus has been on tools – anybody can grab a scanner and throw it at their websites and applications, it’s only the quality and quantity of results that will vary. But now that you have your scan results, what do you do with them? It’s common for large organizations to have hundreds of web assets, so if you get, say, 10 issues per asset on average, you could be looking at several thousand issues. Where do you even start?
This is where most organizations get stuck. At that kind of scale, there is simply no way for security engineers to manually sift through all the results, weed out false positives, assign issues, and get the fixes implemented in any sensible time. It is also where most DAST vendors stop, in effect saying “our job is to test your websites, here are the results, now you’re on your own”.
The big challenge is deciding what is actionable – and that requires identifying real, high-severity issues. This is where Invicti with its Proof-Based Scanning technology completely changes the dynamics of web application security testing by indicating exploitable issues, providing proof that they are real, and prioritizing them by potential impact. Now you know what is actionable, you can start fixing.
Step 4: Integrate and Automate Security
The next challenge is actually getting the issues to developers. Again, this is not something that can (or should) be done manually when dealing with thousands of vulnerabilities – security teams simply don’t have the resources. Large organizations can employ several thousand developers but only a handful of web security engineers, so the only feasible approach is to automatically and efficiently shift as much work as possible to that large developer community.
Developers live and work by their issue trackers, so if you want vulnerabilities fixed, you need to get them into the issue tracker – simply sending developers a bunch of PDFs with vulnerability reports is definitely not the way to get things done. To get results, you need to integrate with the issue tracker already used by the development team and automatically assign actionable issues, complete with all the information needed to isolate and fix a bug. To achieve this, Invicti provides a rich set of integrations so you can automatically assign proven vulnerabilities directly to developers along with remediation guidance and (in most cases) proof that the issue is real.
Step 5: Absorb Security into Your Culture
Once you are at that level of efficiency and security testing is a routine part of everyday workflows, you are finally in control of your web application security – still a rare achievement among global enterprises. Even so, security and development are still separate, though tightly integrated. The final step on the road to a secure SDLC is to fully incorporate regular security testing into the development organization, which requires organizational and cultural changes far more than new tools.
At this stage, we get to the true meaning of shifting left: actually moving application security testing into the development teams. One way to do this is to have the core security team set up a company-wide application testing platform and workflow for all the development teams to use, complete with all the necessary internal documentation and training resources. When plugged into the existing SDLC pipelines, this process will feed only proven and actionable security issues into the ticketing systems, providing a kind of self-service platform.
In this scenario, application security specialists are distributed among the development teams. Their job is to adopt a development mindset to help developers understand security issues and decide on the best way to implement fixes in their specific codebase. The core security team now focuses on high-level vulnerability management, optimizing the AppSec framework, providing training, defining policy, and other tasks that are a more effective use of their time and expertise than manually going through scan results.
You Are Here
Each of these steps roughly corresponds to a level of organizational and technological maturity. Many large organizations are still struggling with step 1 and don’t really know all the web assets they have. Most have gone through step 2 and have some sort of vulnerability detection process in place. The majority are currently stuck in step 3, still struggling to address issues faster than new ones come in. Some mature organizations have progressed to the integration and automation stage but only a select few have made the cultural leap to fully incorporating security into their SDLC.
Cutting-edge solutions like Invicti are already available to help enterprises on the technological level, but deploying and integrating a new tool is the (relatively) easy part, especially for DAST. The real challenge is changing workflows, internal structure, and company culture – and changing people is much harder than changing code.