- Step 1—Create a spreadsheet of every vulnerability in the project. This spreadsheet will also serve as the basis for the risk register, if the project requires it (see Chapter 10). For the purposes of illustration, we will look at 2. Each vulnerability will reside on its own row, separated by asset class or area of facility.
- Step 2—Add columns for risk number, probability score, vulnerability score, consequences score, and risk score R = (P + V + C)/3. Add a column for recommended countermeasure and estimated cost.
-
Step 3—Create columns for each type of countermeasure, grouped by functions.
Function classes include:
—Entry control
—Detection
—Assessment
—Delay
—Response
—Evidence
To the left of each function, include a column marked Countermeasure Effectiveness Estimate (or CEE). To the right of all columns, add an additional column titled Total Mitigation Estimate (or TME) (Figure 18.2). - Step 4—For each vulnerability place an "X" under each countermeasure that applies. Then, for each function, place an estimate from 0 to 1 where 1 is total mitigation for that function and 0 is no mitigation for that function.
For example, for detection, countermeasures might include door position switch, glass break detector, guard dog, and patrol. For each of these that are applicable for this vulnerability, place an X under the countermeasure. Then estimate the total mitigation for that vulnerability for the detection function. If detection is assured, place a 1 in the Estimate column. If detection is not likely to occur, place a 0 in the column. If detection is nearly always likely, place a number lower than 1 and more than 0.5 in the column. Do this for each vulnerability and for each functional group. This provides the mitigation score for each function for each vulnerability.
Then place a weighting on the functional estimates. Since we have 6 functions, a balanced weighting would be 16.6% for each function.
The formula for total mitigation is simple and straightforward. Total Mitigation = (Entry Control * Weighted Score {WS} Entry Control) + (Detection * WS Detection) + (Assessment * WS Assessment) + (Delay * WS Delay) + (Response * WS Response) + (Evidence * WS Evidence).
Security Event Logs
Security event logs are also a very good way to determine overall security program effectiveness. Across a year's time, security logs will display trends and identify unresolved vulnerabilities. We are interested in both, but especially the unresolved vulnerabilities.
It is unlikely that every last vulnerability will be identified in any risk assessment, but you can be certain that offenders will notice any unresolved vulnerabilities and try to exploit them. These will often be found by minor offenders or the guard staff. These minor exploits will show up as security events in the logs and are a valuable source for tightening up those unresolved vulnerabilities that would otherwise go unnoticed.
I recommend that whatever logging method you use to keep track of security events should have a column to track whether each security event was related to an unresolved vulnerability. An additional column could identify the unresolved vulnerability. This allows the security director to relate security events either to misbehavior that was handled in accordance with policy or was an event that should spark reconsideration of security countermeasures.
Over the course of a year, any unresolved vulnerabilities that develop into security events will draw management's attention to the needs for those vulnerabilities to be mitigated with appropriate countermeasures. Adding the column to identify the security event as related to an unresolved vulnerability and describing that vulnerability allows the security director to quickly identify any unresolved vulnerabilities and also note which vulnerabilities are related to recurring security events.
The goal of ongoing risk assessments is to continuously uncover unresolved vulnerabilities and emerging threats and to make accommodations for them. Security event logs are one of the very best tools an analyst can use to achieve this goal.
In the event that there is no column to identify if each security event is related to an unresolved vulnerability, all is not lost. An analyst can import the logs to a spreadsheet program and add the columns. If the analyst is familiar with the facility, he or she will likely think of the vulnerabilities that could relate to the security event. If not, he or she can assemble the related security events and then discuss these events with staff to uncover any unresolved vulnerabilities.
The spreadsheet acts as a metric, listing both incidents related to vulnerabilities and those that are not. The percentage of incidents related to vulnerabilities is a useful metric to determine that the security program is minimizing risk.
Patrol Logs (Vulnerabilities Spotting/Violations Spotting)
In the same manner that security incident reports can uncover unresolved vulnerabilities, so too can patrol logs. Quality security program directors train their patrol officers to understand vulnerabilities and to spot them when they see them. I always find it interesting when performing risk analysis surveys that interviews with both post and patrol officers always and without exception uncover unresolved vulnerabilities.
There is a wealth of information among the officers "on the ground" about the weaknesses in security countermeasures. It is very common after a major security incident to hear one or many officers say "Yeah, I knew that was going to happen someday." So why did they not report it? Usually it is because management does not emphasize focusing on vulnerabilities and reporting them to management.
By training security officers to observe, and not just to see, management can find those vulnerabilities that are missed by risk analysts and management due to their lack of intimate familiarity with the facility and its operations. Security officers, who spend hours every day interacting with the business operations and every corner of the facility, know every vulnerability well. But in most cases, they are not trained to see them as vulnerabilities that should be addressed and reported to management.
The patrol logs spreadsheet acts as a metric, listing both patrol notes that are related to vulnerabilities and those that are not. The percentage of patrol notes related to vulnerabilities is a useful metric to determine that the security program is minimizing risk.
Annual Risk Analysis
Finally, the risk analysis should be updated annually. This presents an opportunity once each year to compare overall risk progression year over year. The delta between this year and previous years serves as a useful metric to determine risk progression.