CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

What's the Score of the Game - Part 2: Web Security Metrics

In my earlier post entitled "What's the Score of the Game?" I presented the concept that what ultimately matters with web application security is how the application performs during a "Real Game" which means when it is deployed live on the production network. Everything else that happens before that time is preparation. It is important preparation, however no one is given the Lombardi Trophy based on how hard they practiced! No, you actually have to play in and win the Super Bowl in order to obtain that hardware :) So, referencing back to the title of this post, if the production network is "where" the webappsec game is actually played, then the next logical question is "How do we keep score?"

This is where web security metrics come into play.

When I say web security metrics, I am referring to data that is relevant to answering the question - Are we winning or losing the game? By that I mean - in football in order to win the game you have to have more points than your opponent at the end of the game. In webappsec, if you are in charge of defending a web application, you win if an attacker tries to compromise your site and is unable. This seems like a "Duh" statement but it actually isn't when you consider how many web security vendors try and tell you the "Score of the Game". Most vendors will present customers with colorful pie charts stating that a web site has X number of vulnerabilities or that they blocked X number of attacks. This is like asking someone who won the Giants vs. Patriots game and getting a response of - the Patriots completed 35 passes while the Giants intercepted them 3 times. Not really answering the question is it? While some customers may be distracted by eye-catching graphical displays of this information, the savvy ones will ask this key question - Were there any successful attacks? The answer to this question will tell you the score of the game - did the opponent score any touchdowns??? All other data is corollary.

Sidebar - realistically you are dealing with two different types of attacks - the automated kind where an attacker is targeting a specific vuln and searching for sites that have it or the manual type where the attacker is targeting your site specifically and they must then find a vuln to exploit. In the former case, it is like when a football opponent tries one desperate Hail-Mary pass down the field as time expires. If you bat the football down, you win. If you don't, you lose. In the latter case, it is like a methodical 99-yard drive down the field where your opponent is running 2-yard dive plays left and right and slowly marching down the field. If you give them enough time, then they will most likely score. In this case, it is critical that your webappsec defenses are such that you are able to force the attacker to manually try and search for complex logical attacks or develop evasions, you might then be able to implement countermeasures to prevent them access before being successful.

With this concept as a backdrop, let me present the web security metrics that I feel are most important for the production network and gauging how the web application's security mechanisms are performing -

  1. Web Transactions per Day - This should be represented as a number (#) and establishes a baseline of web traffic and provides some perspective for the other metrics. Some WAFs will be able to keep track of this data on their own. If this is not possible then you would need to correlate web server log data.
  2. Attacks Detected/True Positive - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions. This data is a general indicator of malicious web traffic. These numbers are presented in a all WAF reporting functions.
  3. Missed attacks/False Negative - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions. This data is a general indicator of the effectiveness of the web application firewall's detection accuracy. This is the key metric that is missing when people are trying to determine their webappsec success. If the WAF is configured for "alert-centric" logging and therefore only logging blocked attacks then you will not be able to report on this data automatically using the WAFs built-in reporting facilities. If, on the other hand, the WAF audit logging all relevant traffic (requests for non-static resources, etc...) then an Analyst would have raw data to conduct batch analysis and identify missed attacks. The fall-back data source would be whatever incident response processes exist for the organization. There may be other sources of data (web logs, IDS, etc...) where a web attack may be confirmed.
  4. Blocked Traffic/False Positive - This data should be represented as both a number (#) and as a percentage (%) of item 1 - total web transactions. This data is a general indicator of the effectiveness of web application firewall's detection accuracy. This is very important data for many organizations because blocking legitimate customer traffic can mean missed revenue. This can usually be identified by evaluating any Exceptions that needed to be implemented by the WAF in order to allow "legitimate" traffic that was otherwise triggering a negative security rule or signature. Besides Exceptions, this data can be identified in Reports if the WAF has appropriate alert ticketing interfaces where an Analyst can categorize the alert.
  5. Attack Detection Failure Rate - This data should be represented as a percentage (%) and is derived by adding items 3 (False Negatives) and 4 (False Positives) and then dividing by item 2 - True Positives. This percentage will give an overall effectiveness of web application firewall's detection accuracy - meaning the Score of the Game.

Sidebar - I am referencing web application firewalls in the metrics as they are specifically designed to report on this type of data. You could substitute any security filtering code mechanism built directly into the webapp code, however many implementations do not adequately provide logging and reporting for this data. This code may present users with a friendly error message, however they are essentially performing "silent drops" of requests from the back-end logging perspective.

As stated earlier, many webappsec vendors will only provide statistics related to item #2 (blocked attacks). While this data does factor into the equation, it does not provide the best indicator of overall web application security on its own. So, if you really want to know what the score of the game is for you web applications, I suggest you start tracking the metrics provided in this post.

Latest SpiderLabs Blogs

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More

The Secret Cipher: Modern Data Loss Prevention Solutions

This is Part 7 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here. Far too many organizations place Data Loss Prevention (DLP) and Data...

Read More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

UPDATE: Palo Alto Networks confirmed on Tuesday (4/16) that disabling device telemetry is no longer considered an effective mitigation. On Wednesday (4/17), the company released new threat signatures...

Read More