How to Conduct a Security Exception Review Using FAIR

Taylor Maze

As the saying goes, there’s an exception to every rule. Security policies are no exception (though they are a rule…).

With that being said, however, how can you determine whether an exception should be made to allow a system to be in non-compliance with a security policy?

One way is by using the Factor Analysis of Information Risk (FAIR) model and RiskLens to evaluate how much risk the non-compliance poses to the organization.

In order to evaluate a policy exception request utilizing FAIR, the loss event must first be defined. To do so, consider an event that is likely to happen as a result of the exception being (or not being) in place. For example, if the policy exception request is related to a legacy system not having the technical requirements to be in compliance with Information Security policy technical requirements, the loss event might be something like this:

“Assess the risk associated with cyber criminals (threat) utilizing malware to cause an outage (effect) in L egacy System X (asset) as a result of non-compliance with Information Security policy technical requirements.”

Read this next: Security Exception vs. Risk Acceptance: What’s the Difference?

Risk Triage

After the loss event has been defined, you can begin the risk triage process. A risk triage is a “quick and dirty” way of prioritizing loss events and determining if a full quantitative analysis is required. The triage can typically be completed by the requestor with the help of the Legacy System owner, in this case. If the results of the triage exceed your organization’s defined threshold, a full quantitative analysis may be required.

Probable Frequency of a Loss Event

If the results of the triage exceed your organization’s threshold, the first step of the quantitative analysis requires understanding how often the loss event is likely to occur in a given year. This can be evaluated at the event level (i.e. historically, how often has this happened) or at the attempt and susceptibility level (i.e. how often is this event attempted? how likely is it to be successful?). In this scenario, you would be estimating how often cyber criminals attempt to cause an outage of Legacy System X and how likely they are to be successful when doing so. In order to do so, you would likely involve the Legacy System owner as well as the Information Security team to determine if and how often events of this type have occurred and how susceptible you are to them.

Probable Magnitude of Loss

After understanding how often the loss event is likely to occur in a given year, you then must answer the “so what?” aka the amount of loss associated with the event. In order to do so you must first identify what types of loss are applicable. In this scenario, it is likely to be incident response and employee productivity impacts– depending on the extent of the outage. Generally, Incident Response and HR teams can provide insight around these data points.

In addition to estimating the amount of loss associated with incident response and employee productivity impacts, you also need to estimate the amount of downtime you can expect from the Legacy System. The Legacy System Owner can likely provide this information.

Based upon the results of the analysis, you can determine if the policy exception can be approved or if the amount of loss exposure associated with the event exceeds what your organization has deemed acceptable and as such, requires mitigation. Using the RiskLens CRQ tool, you can set your risk appetite directly in the platform (see the red line in the example below) and by doing so, create automatic comparisons between the scenario’s annualized loss exposure and your organization’s risk appetite.