4 Common Mistakes When Calculating Threat Event Frequency For Web Apps

April 15, 2022  Bryan Smith

Threat in CybersecurityWhen it comes to the frequency half of the FAIR model, I consider Threat Event Frequency (TEF) king. Yes, in Factor Analysis of Information Risk (FAIR™), all of the ontology is important. But mistakes with Threat Event Frequency act as a multiplier.

We see this when analysts new to FAIR are working on Threat Event Frequency for web applications. A common use of RiskLens is to prioritize remediation efforts for web applications. Using FAIR provides a consistent and contextual way to identify what matters.


headshot_Bryan-SmithBryan Smith is CTO of RiskLens and leads development of the RiskLens enterprise cyber risk quantification platform and other quantitative risk management products and services.


But if TEF is incorrectly derived, the analysis can run aground. Fortunately, mistakes made with Threat Event Frequency are often simple and easy to avoid.


Discover your industry's greatest cyber risks in this new report. TRY IT FREE.


 

Threat Event Frequency in FAIR Cyber Risk Analytics

But first a quick recap of Threat Event Frequency. "Threat Event Frequency is the probable frequency, within a given time frame, that threat agents will act in a manner that may result in loss." (from the FAIR book, Measuring and Managing Information Risk) That's a mouthful, so let's unpack it:

  1. Probable Frequency - We're dealing with how often something will happen. In this context how often bad guys attack our web application.

  2. Given Time Frame - We have to put a limit on how long we will count events. In RiskLens, we always deal with annualized time. So one year.

  3. Threat Agents - A threat agent (or actor) can be many things. A person, a group (think the hacking group Anonymous), malware, etc. The important part is the agent is acting in a malicious way against your web application. (I'm assuming the risk scenario context is external hackers here.)

  4. May Result in Loss - Just because an attack happened doesn't mean a loss happened. But it's important to remember the intent for loss was there.

Keep this definition in mind as we go over these common mistakes and how to avoid them.


Train in FAIR quantitative risk analysis with the experts: the RiskLens Academy


Mistake #1 - Confusing Contact Frequency with Threat Event Frequency

Threat in Cybersecurity - Hand This is by far the most common mistake analysts new to FAIR make. A great example of this is using security logs from a web application firewall (WAF). A WAF can be a great source of data to derive Threat Event Frequency. But it's important to understand individual log entries are contact events, not threat events.

To avoid this, the analyst needs to use a consistent method to group contact events into threat events. Not doing so will overstate Threat Event Frequency. Using concepts such as Imperva's notion of a Battle Day can help. Just remember web application contact frequency will likely be grouped into threat events. If you're not grouping you're likely making a mistake.

Mistake #2 - Not Defining Where in the Attack Chain You’re Measuring TEF

Threat in Cybersecurity - Hand For example, if you’re analyzing ransomware risk, we recommend measuring TEF once the ransomware is on an endpoint and not earlier, in other words before firewalls and filtering introduce noise. Find the spot where the data is easiest to understand and most available. You need to know where to measure so you can define how to measure and achieve consistent measurement; this will also help you align the data you have or see the estimates you need. And in the above example, it is simpler to measure because it’s always a threat and not confused with Contact Frequency. This leads us to…

 

Mistake #3 - Confusing Intent

Threat in Cybersecurity - Hand Not all attacks look alike. Actually, not all attacks are attacks. Remember in our definition above, the threat actor is malicious and may cause a loss. Is a scan of a system malicious? Some may say it is, but in FAIR’s definition of TEF it is not. A scan also doesn't lead to a loss.

To avoid this, be sure to understand what your data is showing you. Is this a scan (simple contact) or an attack? If it's a scan don't include it in the final Threat Event Frequency. Or include scans as part of an attack, call it the opening move, just one move among many in a single attack.


Learn more about using the attack chain for cyber risk analysis in these blog posts:

Business Email Compromise Risk: The What, Why and How to Quantify

Case Study: Quantify Cybersecurity Risk for Industrial Robots


 

Mistake #4 - Not Doing a Smell Test

Threat in Cybersecurity - Hand You've crunched the numbers and the data says X. You put the results in and blissfully jump to the next question. Stop. You're not done, you've skipped an important step. Not doing a smell test, a critical look at the result in context of the full risk scenario is a mistake. A mistake that allows mistakes #1 and #3 to creep into your analysis.

To avoid this, add a "smell test" task to your workflow. A simple step that adds critical thinking for quality control. Come back to the answer later, after you've got your head out of the data. Ask yourself if it still seems realistic. Does it make sense given the context of the risk scenario? If not, go over it once more. Apply the definition to the data again and see if you fell for a common pitfall and correct it accordingly.


More on Threat Event Frequency from the FAIR Institute

Those who are just learning FAIR occasionally confuse Threat Event Frequency (TEF) with Loss Event Frequency (LEF), and this is one of the most-missed questions on the certification exam. There is a strong similarity between the definitions of TEF and LEF. The only difference is that the definition for TEF doesn’t include whether a threat agent’s actions are successful. TEF captures the number of attempts (by a threat actor) to cause harm to an Asset. A common example of a malicious threat event (where harm or abuse is intended) would be the attacker (Threat Actor) who unsuccessfully attacks a web server. Such an attack would be considered a threat event, but not a loss event.

--FAIR Terminology 101 – Risk, Threat Event Frequency and Vulnerability

 RRevolutionary-Benchmark-1080x1080

 

More on Threat Event Frequency rom thFAIR Institu