Small and mid-sized businesses are able to manage their information security, including web application security, in a very direct fashion. The numbers of assets, vulnerabilities, and incidents are low enough for the security manager to be able to have a clear view of IT security posture. However, with the growth of your business and the expansion of your security team, your security management methods will need to rely more and more on cybersecurity metrics / KPIs.
As your business goes on to become an enterprise or a corporation, cybersecurity will make it all the way to the board level. Your business leaders will most likely include not only a CIO and/or CSO but also a CISO (Chief Information Security Officer) who will be responsible for the entire cybersecurity program. Their role will be focused on decision-making related to risk assessment and risk management and they won’t be able to go into information technology details, for example, web vulnerability management data. This is where an effective security metrics program becomes key to the organization’s security – it becomes the means of communication between a cybersecurity expert, the entire IT team, and a business expert.
Start thinking about metrics
If you’re responsible for web application security in a small business, it is a good idea for you to start thinking about cybersecurity metrics for web applications early on and not only when you are asked to provide them to those in the boardroom. Some of these metrics, unfortunately, require much more than just printing a management report from a vulnerability scan.
Here are the most typical cybersecurity metrics related to web application security that you may be required to provide to your C-suite. Note that all these metrics should be monitored both as most recent values as well as trends in time.
Total number of vulnerabilities
The most obvious and easiest to obtain metric for web application security is the total number of vulnerabilities found – both using automated vulnerability scanning and further manual penetration testing. However, since the consequences of web vulnerabilities may be very different, it is useful to subdivide them into severity classes.
Acunetix reporting mechanisms are very useful to provide this metric because of automatic vulnerability assessment capabilities. The tool automatically classifies vulnerabilities according to their severity based on potential impact, ease of exploitation, and more.
However, your CISO may want vulnerabilities classified according to the business impact of the web asset – for example, a major vulnerability in a minor marketing site may have much less impact than a minor vulnerability in a major financial system. Acunetix® can help you with monitoring this, too, but you need to enter the baseline data manually. Therefore, you should continuously evaluate the business impact of each web asset and modify it in Acunetix as a parameter of the scan target.
Reoccurring vulnerabilities
The number of reoccurring vulnerabilities is a very important measure of the efficiency of the remediation process as well as the quality of developer education. If the same vulnerability in the same web asset is rediscovered during several consecutive vulnerability scans it means that it’s not getting fixed. The fact that it’s not getting fixed usually means that there are not enough resources to fix it, which may be important for the board.
On the other hand, if a vulnerability is fixed and then keeps reappearing in the same or similar target, it might mean that there is a problem with developer education and the general security performance. This could be resolved by introducing web vulnerability scanning early in the SDLC but, again, this is an important signal for the board because it impacts all security operations.
Average time-to-remediate
Another important metric (again, useful to be subdivided into different severity classes) is the time that is usually required for the vulnerability to be fixed. This response time data can either be acquired directly from the scanner (time between first discovery of the vulnerability and the last occurrence of this vulnerability), or from a vulnerability management / issue tracking tool.
Similar to the number of reoccurring vulnerabilities, this metric is supposed to present the C-suite with the current state and trend of remediation efficiency. For example, if the average time-to-remediate keeps increasing it means that the developer load is excessive and measures should be taken to reduce the number of issues that require more than simple patching.
Cost of remediation
The C-suite strongly focuses on the IT budget and therefore direct financial information is very valuable for them. Unfortunately, getting data on the cost of remediation is not as easy as in the case of previous measurements because it cannot be acquired directly from a vulnerability scanner. A vulnerability scanner may evaluate how long it takes to fix the vulnerability but it cannot evaluate how much of that time the vulnerability is stuck in the queue and how much time and effort it actually takes the developer to fix it.
The simplest way to estimate the cost of remediation would be to evaluate the actual time spend on remediation by developers, which would need to be acquired directly from the issue tracking system. The cost evaluation would then be based on average developer labor costs.
The number of cybersecurity incidents
In addition to potential cyber threats and attack vectors, such as web application vulnerabilities, the C-suite must also know about any cybersecurity incidents associated with these potential cyber attack vectors. This information is necessary to maintain an effective risk management program.
Web vulnerability scanning focuses completely on prevention and therefore incident data must be acquired from other types of systems, for example, web application firewalls or intrusion detection systems.
While previous metrics show the quality of owned assets (from the point of view of cybersecurity), this metric shows the potential for real losses such as those caused by data breaches. This data helps the C-suite make decisions related to cyber risk, for example, helps them decide whether to invest more in incident response or in preventive measures.
Other security controls and metrics
The above metrics are not industry standards – they are just examples of the type of data that your C-suite may require. The actual metrics and KPIs will differ from organization to organization, depending on the size of the company, the types of assets, and even the approach of the C-suite.
Knowing about these measures early and preparing to gather them using, for example, a scanner with extensive reporting capabilities such as Acunetix is a good idea for any management-level security professional in a growing business.
Source: https://www.acunetix.com/blog/web-security-zone/cybersecurity-metrics-for-web-applications/
