Cybersecurity Metrics for Web Applications

Small and medium-sized businesses are able to manage their information security, including web application security, in a very direct way. The number of assets, vulnerabilities and incidents is low enough that the security manager can have a clear view of the state of IT security. However, as your business grows and your security team expands, your security management methods will need to increasingly rely on cybersecurity metrics/KPIs.

As your business grows into a business or corporation, cybersecurity will move up 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 management and they will not be able to go into details of information technology, e.g., web vulnerability management The data. This is where an effective security measures program becomes the key to organizational 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’s a good idea that you start thinking about cybersecurity metrics for web applications early on and not just when you’re asked to provide them to members. from the administration board. Unfortunately, some of these measures require much more than just printing out a management report from a vulnerability scan.

Here are the most typical cybersecurity measures related to web application security that you may need to provide to your C-suite. Note that all of these metrics should be monitored both as most recent values ​​and as trends over time.

Total number of vulnerabilities

The most obvious and easily obtained metric for web application security is the total number of vulnerabilities found – both using automated vulnerability scanning and additional manual scanning. penetration testing. However, since the consequences of web vulnerabilities can be very different, it is useful to subdivide them into severity classes.

Acunetix’s reporting mechanisms are very useful in providing this metric due to automatic vulnerability assessment capabilities. The tool automatically ranks vulnerabilities by severity based on potential impact, ease of exploitation, and more.

However, your CISO may want vulnerabilities to be ranked 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 system. major financier. Acunetix® can also help you monitor this, but you must manually enter basic data. Therefore, you should continuously assess the business impact of each web asset and modify it in Acunetix as an analysis target parameter.

Recurring vulnerabilities

The number of recurring vulnerabilities is a very important measure of the effectiveness of the remediation process as well as the quality of developer training. If the same vulnerability in the same web resource is rediscovered during several consecutive vulnerability scans, it means that it is not fixed. Failure to fix it usually means there aren’t enough resources to fix it, which can be important to the council.

On the other hand, if a vulnerability is patched and then reappears in the same or a similar target, it may mean that there is an issue with developer training and general security performance. This could be addressed by introducing web vulnerability scanning early in the SDLC but again this is an important signal to the board as it impacts all security operations.

Average resolution time

Another important metric (again, useful for breaking down into different severity classes) is the time it typically takes for the vulnerability to be patched. This response time data can be acquired either directly from the scanner (time between the 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 recurrent vulnerabilities, this metric is meant to present following C the current status and trend of remediation effectiveness. For example, if the average time to resolution keeps increasing, it means that the load on the developer is excessive and action needs to be taken to reduce the number of issues requiring more than just a fix.

Remediation cost

The C-suite has a strong focus on the IT budget and therefore direct financial information is very valuable to them. Unfortunately, obtaining remediation cost data is not as easy as with previous metrics because it cannot be acquired directly from a vulnerability scanner. A vulnerability scanner can assess how long it takes to fix the vulnerability, but it cannot assess how long the vulnerability is stuck in the queue and how much time and effort it actually takes the developer to fix. to repair it.

The easiest way to estimate the cost of remediation would be to estimate the actual time spent on remediation by developers, which should be acquired directly from the issue tracking system. The cost assessment would then be based on the developers’ average 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 be aware of any cyber security incidents associated with these potential cyber attack vectors. This information is necessary to maintain an effective risk management program.

Web vulnerability scanning focuses entirely on prevention and therefore incident data must be acquired from other types of systems, for example, web application firewalls or detection systems of intrusion.

While the previous metrics show the quality of the assets held (from a cybersecurity perspective), 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 preventative measures.

Other controls and security measures

The above metrics are not industry standards – they are just examples of the type of data your C-suite may need. Actual metrics and KPIs will differ from organization to organization, depending on company size, asset types, and even C-suite approach.

Knowing these metrics early and being prepared to gather them using, for example, a scanner with extensive reporting capabilities such as Acunetix is ​​a good idea for any executive-level security professional in a growing business.


Tomasz Andrzej Nidecki
Technical Content Writer

Tomasz Andrzej Nidecki (also known as tonid) is a technical content writer working for Acunetix. A journalist, translator and tech writer with 25 years of IT experience, Tomasz was editor-in-chief of hakin9 IT Security magazine in its early days and ran a major tech blog dedicated to email security.