Technical Insight-Vulnerabilities-Web Application Security

Security and the SDLC: Integrating application security in developer environments

As we wind down the end of the year, I thought it would be good to talk about some big thinking in regard to vuln classification and prioritization. There are two common overlooked issues when enterprises attempt to secure themselves:

1. Once a company finds out about a vulnerability, how do they track it? A company can end up with tens of thousands of vulnerabilities or more if their environment is large and complex enough. And we’re not talking about false positives – I mean real, remotely exploitable vulns.

2. How do you ensure the vulnerabilities actually get fixed? Just because you find a vulnerability doesn’t mean your developers know about it, or know to prioritize it, etc. And what if they just claim that it’s fixed…?

The problem is scale. Any off the shelf scanner will work fine when you’re talking about one app, or a few apps. But where they fall down is when they have to scan hundreds or thousands of apps. Not only do companies not have the manpower to manage all of those scans, and the associated credentials, but even if they did, they’re left with a huge homework assignment – transcribing thousands of vulns into some system that the developers know to look at.

Integration with some sort of case management system, therefore, is a critical component of SDLC (software/security development life cycle) integration. It’s not just a nice-to-have checklist item – if you aren’t doing it, vulns are getting lost, and that’s just a fact. Worse yet, if you don’t have bi-directional communication, vulns can get closed and then you’ll end up opening a new ticket every time you scan. Knowing which vuln corresponds to scanner findings allows you to see when a developer just wants to close a few tickets before 5PM on Friday. When the vulns all re-open on the next scan-run you’ll know who is just trying to game the system and therefore which developer/QA engineers are leaving you unnecessarily vulnerable.

Then you have the whole issue of vuln priority. Without knowing something about the systems in question you could inadvertently prioritize a vuln on an internal device ahead of something that is in production. Scanners are ultimately dumb (yes, it’s true, no matter how much we like to pretend they’re not) and they need to be told how to think about the environment. If your scanner can’t take in information from systems like Archer or similar GRC (Governance Risk Compliance) tools, to know how important a site is, it’s entirely possible that you’re fixing the wrong issues in the wrong order. It’s putting your company unnecessarily at risk and wasting resources in the process.

There is a real art to making sure you are looking at the correct vulns. The more you think about it, the more you’ll probably agree this is the right path forward – adding in all sorts of additional/useful criteria. For instance, knowing how much a site is getting attacked is useful. Knowing which sites take and store PII (personally identifiable information) is useful. Knowing which sites live in the DMZ (de-militarized zone) together is useful. All of those things can help you prioritize and stop wasting time on vulns that either don’t matter because they’re nearly impossible to exploit or are less critical because they are protected by other controls.

There’s obviously a lot more to it, but this should be a good primer on how to start thinking about vulns. If you want more information, we have several webinars that go into this in more gory detail. Either way, if you aren’t spending time identifying your assets and prioritizing them, you’re wasting time and money – and who’s got that?

Tags: Vulnerabilities