How’s your web application security program measuring up today? If you’re like many people, you’re simply going through the motions of periodic vulnerability scans and problem resolution. It’s a vicious cycle that may or may not be delivering the results you’re looking for. Given all the time, effort, and money you put into web security testing, you can’t afford to guess how things are working and assume that all is well merely because you’ve gone through the motions.
In the same spirit of how you can’t secure what you don’t acknowledge and how you can’t change what you tolerate in security, you can’t manage the things associated with application security that you don’t measure. As management consultant Peter Drucker said: what’s measured improves. If your true goal is to minimize your web-related business risks, you have to establish a set of metrics you can measure your web application security against.
Key areas you need to measure
Results are not the same as intentions. If you’re going to get results you need to ensure you’re focusing on the right areas and doing what’s necessary. Here are seven key areas you need to be measuring – at a minimum – to ensure you’re getting all you can out of your web security program:
- Total initial vulnerabilities (a baseline of issues found by scanners and ones found through manual analysis)
- Repeat vulnerabilities (the flaws that keep reoccurring along with why they’re not being resolved)
- Remediation latency (the window of time it takes to deploy a fix along with any other details such as severity rating and specific type of problem such as coding or server configuration)
- Vulnerabilities that are exploitable placing sensitive information at risk or otherwise impacting the business in a negative way (this might include SQL injection, XSS, weak passwords, and the like)
- Vulnerabilities that go against industry practice but are not currently placing information or systems in immediate danger (this might include ASP.NET debugging being enabled, unhandled exceptions, IP addresses being revealed, etc.)
- Vulnerabilities that are not present but are being sought out on your systems based on what you see in your server and application logs and network traffic analysis (this might include password cracking, denial of service attacks such as the slow HTTP attack, etc.)
- Web security attacks successfully blocked at the network perimeter, application, database, or server level (again, this might include password cracking, denial of service or even something more severe such as SQL injection)
Measure any other activity that adds value in terms of web security based on your own specific situation. You can do this using the information provided by your web vulnerability scanner as well as any other automated or manual tool or process that’s part of your web security program.
Measuring the important security-related issues across all of your websites and web applications will help you determine what’s getting better, what’s getting worse, and what’s remaining constant. If nothing appears to be broken, odds are you haven’t looked hard enough.
Peter Drucker is also quoted as saying “There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” Don’t focus on the wrong target with web application security. Develop some meaningful security metrics around your program that involves all aspects of web applications beyond vulnerability testing, software development, and QA. Branch out to other areas that impact web security such as the network, servers, clients, databases, cloud computing, and even mobile. If it’s important, measure it. If it’s not important then don’t waste your time on it.
You can’t expect perfection early on. However, if you establish the metrics and continue to fine-tune your measurements and the ongoing feedback you receive, your efforts will become intentional. You’re virtually guaranteed to improve your web security program in ways you never conceived.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
