One of the keys to consistency when using the FAIR™ model is using the same magnitude across cyber loss data analyses. Particularly when using it for a risk assessment where the goal is to be compliant with regulations and compare the applications to each other, it is reasonable and “fair” to use consistent magnitude amounts. That said, the amounts need to be re-evaluated to keep up with changes in the data. This is a difficult balance to strike, but I recommend reviewing them at least every other year.
Allison H. K. Seidel is Senior Risk Specialist at PNC Bank where she applies FAIR for compliance and management decisions. Catch Allison’s presentation at the upcoming 2020 RSA Conference with Steve Reznik of ADP, "What’s in Your Risk Assessment?."
Here are the steps I recommend to create a cyber loss data “shopping” list:
Start with the Verizon DBIR
If you are not using the RiskLens platform that includes loss tables based on updated feeds from Advisen and proprietary data, and your budget for determining the magnitude side of your FAIR equation is zero, the last published data in the proper format was from the 2015 Verizon data breach report (using data from 2014). According to Google’s inflation calculator, $1 in 2014 is equivalent to $1.09 in 2019. The following table reflects 10% higher than the Verizon published data in 2015 (rounded to the nearest thousand):
Gather Internal Data
The second step to take is to look internally. Reach out to your insurance professional and gain an understanding of the data from the insurance provider for determining the cost of cyber insurance. However, these costs reflect the worst-case scenario and not the most likely. Consider who else may have the type of data you are seeking. Are there any Information Security professionals with specific examples? Anything that has happened to your company from which you can extrapolate?
Tap these Free Reports
I found the following:
Federal Trade Commission Privacy & Data Security Update (see the Data Security and Identity Theft section. Additional research on each case is required)
NOTE: I also looked at the Veris Community Database but the need for a data parser kept me from including this on the list.
Putting all that into perspective should give you some good ideas about what he loss magnitude for a cyber incident would be and the types of costs that would be incurred.
Consider Paying for Data
Also, there are companies specifically trying to sell the data without providing free summary reports. They include:
Another free source for data breach information can be found on Wikipedia. It contains a list of breaches and records compromised with sources for each. Cost information, however, requires additional research.
This is certainly not meant to be an exhaustive list. You can always look for more and better sources on this topic. However, it certainly makes sense to stop reading and put the pencil to paper at some point. Remember Doug Hubbard’s reference to the law of diminishing returns.
Make Your Cyber Loss Data “Shopping” List
Now it is time for the shopping part. What is important to you? Should the dataset include companies close to your company’s size? Or is more important that the companies are all in the same industry? Do you need to have the data in the format required by RiskLens or can you manipulate the type of data to the format you need? If you have already started using data, how drastic can the changes be? Taking all these important criteria along the left side and all the potential providers along the top, create a grid and rank your choices. Here is an example:
If there isn’t a clear “answer”, get more people in your organization involved or weight the questions to the most important things for your organization. Adding more opinions to the mix and subjecting your work to criticism, eventually improves quality and clarity. Also, it gains allies in meetings if people have looked at it ahead of time and their viewpoint has been taken into account.
Your final product might look like this:
How to Avoid Costly Mistakes on Using Ponemon to Report Risk (RiskLens Blog)