Introduction to FAIR

Estimate the probable Threat Event Frequency (TEF)

Many people demand reams of hard data before they’re comfortable estimating attack frequency. Unfortunately, because we don’t have much (if any) really useful or credible data for many scenarios, TEF is often ignored altogether. The minute we ignore this component of risk, however, we’re no longer talking about risk. So, in the absence of hard data, what’s left? One answer is to use a qualitative scale, such as Low, Medium, or High. And, while there’s nothing inherently wrong with a qualitative approach in many circumstances, a quantitative approach provides better clarity and is more useful to most decision-makers – even if it’s imprecise. For example, I may not have years of empirical data documenting how frequently cleaning crew employees abuse usernames and passwords on sticky-notes, but I can make a reasonable estimate within a set of ranges.

As discussed in the Factoring section, a TEF estimate would be based upon how frequently contact between this threat community (the cleaning crew) and the credentials occurs AND the probability that they would act against the credentials. If the cleaning crew comes by once per workday, contact reasonably occurs a couple of hundred times per year. The probability that they would act is driven by three primary factors:

• The value of the asset to them (based upon their motives – financial gain, revenge, etc.),
• How vulnerable the asset appears to be
• Versus the risk of being caught and suffering unacceptable consequences

Recognizing that cleaning crews are generally comprised of honest people, that an HR executive’s credentials typically would not be viewed or recognized as especially valuable to them, and that the perceived risk associated with illicit use might be high, then it seems reasonable to estimate a Low TEF using the table below.

Is it possible for a cleaning crew to have an employee with motive, sufficient computing experience to recognize the potential value of these credentials, and with a high enough risk tolerance to try their hand at illicit use? Absolutely! Does it happen? Undoubtedly. Might such a person be on the crew that cleans this office? Sure – it’s possible. Nonetheless, the probable frequency is relatively low.

Estimate the Threat Capability (Tcap)

Tcap refers to the threat agent’s skill (knowledge & experience) and resources (time & materials) that can be brought to bear against the asset. A different scenario might provide a better illustration of this component of the analysis – something like a web application with a SQL injection weakness – but scenarios like that don’t lend themselves to an introductory document. In this case, all we’re talking about is estimating the skill (in this case, reading ability) and resources (time) the average member of this threat community can use against a password written on a sticky note. It’s reasonable to rate the cleaning crew Tcap as Medium, as compared to the overall threat population. Keep in mind that Tcap is always estimated relative to the scenario. If our scenario was different, and we were evaluating the cleaning crew’s capability to execute a SQL injection attack, we’d probably rate them lower.

Estimate the Control Strength (CS)

Control strength has to do with an asset’s ability to resist compromise. In our scenario, because the credentials are in plain sight and in plain text, the CS is Very Low. If they were written down, but encrypted, the CS would be different – probably much higher.

The question sometimes comes up, “Aren’t good hiring practices a control for internal assets?” and “Isn’t the lock on the executive’s door a control?” Absolutely, they are. But these controls factor into the frequency of contact, as opposed to how effective the controls are at the point of attack. We’ll cover defense in depth in subsequent documentation.

Derive Vulnerability (Vuln)

Deriving vulnerability is easy once you’ve established your Tcap and CS. Recall from the Factoring section that vulnerability is the difference between the force that’s likely to be applied, and the asset’s ability to resist that force. Using the matrix below, simply find the Tcap along the left side of the matrix, and the CS along the bottom. Where they intersect determines the vulnerability.

Derive Loss Event Frequency (LEF)

Similar to vulnerability, LEF is derived by intersecting TEF and Vulnerability within a matrix.

In our scenario, given a TEF of Low and a Vuln of VH, the LEF is Low. Keep in mind that vulnerability is a percentage, which means that you can never be more than 100% vulnerable. Consequently, LEF will never be greater than TEF.

About now, you might start to feel uncomfortable with the idea of categorizing this scenario as a “low” anything – even if you agree with the logic behind the analysis. It runs counter to much of what we’ve been taught and have practiced. Questions regarding aggregate risk, and due diligence begin to arise – and for good reason. We’ll touch on this again later on, but rest assured that “low” LEF is not necessarily the same thing as “not a problem”.