What does an efficient web application vulnerability report look like?
According to the Cybersecurity Jobs Report 2018-2021, there will be more than 3.5 million unfulfilled cybersecurity positions by 2021. At the same time, Gartner predicts that the information security spending will exceed $1 trillion from 2017 to 2021.
It’s clear. As hackers find newer ways to penetrate your database, security costs will go up. Unfortunately, the growing gap between security talent and requirement will only worsen the situation for businesses growing exponentially.
That is where cybersecurity KPIs, ROI, and annualized loss expectancy will play a major role. Your talent pool is and will be limited. You need to prioritize what’s more important for the business processes, your data, and your customers. We bring you a reporting blueprint that will help make website vulnerability assessment results more comprehensible and efficient in decision-making.
A vulnerability is a weakness that allows a hacker to breach your application.
For most decision markers (CISO, CIO, CEO, CTO), this is the top figure that they keep an eye on. At any given period, they like to look at the figures and analyse their website threat exposure.
- Number of overall web vulnerabilities
- Increase or decrease in the count for any given period
- Average number of vulnerabilities per application
If you look at the Qualys report, it is the first metric on the reporting dashboard. That is the first fact that CIO/CISOs report to the management and also use to assign KPIs to the security vendor or the inhouse team.
Most web applications vendors simply do not understand the business impact of this metric. It allows managers to prioritize what needs to be fixed or protected first. According to OWASP, the likelihood of a vulnerability and its business impact must be a part of reporting.
Critical issues should be fixed on priority; especially for apps that deal with customer data and money.
However, ensure that the assessment team uses the widely-accepted severity norms rather than picking up their own definitions. You can cross reference the information on the OWASP or SANS website.
If your company has a continuous scanning solution that maintains historic data, look for this number. Age of a particular vulnerability gives an idea of when it was first discovered and if developers have fixed it since. According to the Web Application Security Statistics Report, it can take up to five months to fix a critical issue.
- Time since first reported
- Patching status
- Critical or not
Keep an eye on high and medium vulnerabilities as they can be overlook for months due to critical issues getting all the attention. If possible, use web application firewall to patch all vulnerabilities and stop hackers from exploiting them.
Business Logic Vulnerability
Some vulnerabilities are exclusive to your business only. Automated scanners will miss them 100% of the time. That is where manual assessment by ethical hackers becomes important.
According to OWASP, a business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules.
Hence, if your assessment report does not include this vector, you are likely exposed to some severe issues.
Is detecting a vulnerability enough? Wouldn’t you want security recommendations and remediation suggestions in the assessment report? GammaSec provides an efficient recommendation in all their reports.
It is a key piece of information that will help application developer fix the issues without breaking his head over it. Over the time, as business and vulnerabilities grow, you can train junior developers of fix medium and high vulnerabilities using this cheat sheet.
Good to Have
A perfect website vulnerability assessment report will ideally have some of the following metrics as well:
- Vulnerability Description: A one-liner about the nature of a security loophole and how it affects your business
- Vulnerability Category: Vulnerability grouping according to their nature.
- Graphs: Graphical representations for quick analysis.
- External References: Links to read more about the security loophole.
- CVE ID
- Assessment Time and Date
- Tester’s Notes: A reference on any special comments by the testing team.
Sample Reports for Reference
- GamaSec Web Security Report
- Tenable Web Scan Report
- Infopercep Sample Report
- ISACA Sample Report
- White Hat Security Audit Report
- Beyond Security Report
- Netsparker Report