The Language of Profit and Loss
Security professionals spend a lot of time honing their area of expertise. Your strength could be in packet analysis, or programming…maybe you are at your best in the realm of security engineering, or pentesting. Or, you may have the best technical skills, but when it comes to obtaining a budget for a project or a new security tool, you need to understand and explain the difference between likelihood, and probability.
Why is this important? This is important because the language of business is based on profits and loss, and that component is key to your progress. How can you describe the need for a new security initiative that makes the point to the people who will fund the venture?
The best way to advance your cause is through quantitative, or qualitative analysis. Specifically, how likely, or how probable an event will occur. As the CISSP Common Body of Knowledge (CBK) describes it, “Likelihood is relevant to qualitative analysis, and probability relates to quantitative.” Some dictionaries don’t make this fine distinction, treating likelihood and probability synonymously, however this is unwise when working in security.
What’s the Difference?
A simple way to remember the difference is that qualitative analysis deals with quality, and quantitative analysis deals with quantities.
Quality = Likelihood measurement
Quantity = Probability measurement
Many treat qualitative analysis as less reliable than quantitative because there are no hard numbers when using qualitative examinations.
When working in risk management, qualitative analysis is usually in order. This is commonly represented by a table showing a risk event against its likelihood and impact. For example, one method that was presented many years ago showed how a qualitative risk analysis was equal for erecting a building against earthquakes was equal for New York and San Francisco.
If we use the classic formula of “Threat x Vulnerability = Risk”, we can build the idea this way:
In San Francisco – Threat level is 7 (because the risk of an earthquake is very high), multiplied by a Vulnerability level of 3 (because their building codes have strict earthquake standards.
This makes the risk a level of 21.
In New York – Threat level is 3 (because there has never been a devastating earthquake in the region), multiplied by a Vulnerability level of 7 (because, if a serious earthquake happens, every building is vulnerable due to no earthquake protections in the building codes). This also creates a risk level of 21.
It is easy to see why an exact, by-the-numbers business executive would treat qualitative analysis as a less serious discipline than a quantitative analysis. The numbers in qualitative analyses are a little too substitutable.
Accuracy in Numbers
Quantitative analysis is much more definite in its numeric components. The simple calculation for a quantitative analysis, seen in the CISSP CBK is:
Annual Loss Expectancy (ALE) = Single Loss Expectancy (SLE) x Annual Rate of Occurrence (ARO)
An easy way to remember this is to think of a lost phone. If we add numbers to that, the totals are clear. Using the modest reference of a $600 phone, and 100 people annually losing or destroying that device: $60,000 (ALE) = $600 (SLE) x 100 (ARO).
If anything, this example should demonstrate why, despite every security analyst’s advice, the “Bring Your Own Device” movement was so successful. Too many corporations were losing too much money on lost phones.
Quantitative analysis goes even deeper, showing how to calculate the Single Loss Expectancy, as well as calculating safeguard values. In the case of lost phones, even the best insurance could not reasonably reconcile the ALE costs. (Paradoxically, in some cases, when a person knows that they have loss insurance for a corporate device, they tend to treat the device less carefully than if it is their own property, raising the ARO even higher.)
The CISSP CBK covers the depth of quantitative analysis, and not only is it worth understanding it clearly from a loss perspective, it is more important to be able to calculate whether a proposed safeguard is a sound value to an organization. There is nothing more prone to failure than proposing a solution that will cost an organization more money than it will save.
More Convincing When Used in Conjunction
From the above breakdown, it is easy to see why Quantitative analysis is a very convincing tool. However, does this make qualitative analysis less valuable? Not at all. In fact, when used in conjunction with a quantitative analysis, it can add fuel to a proposal.
Let’s imagine that you are trying to acquire a budget for a new Mobile Device Management (MDM) platform. If we continue with the phone example, a qualitative analysis can show that the likelihood of a lost device is high, and if that device holds corporate data that is not protected with a quality MDM, the risk to the organization is very high, both in reputational damage and possibly regulatory penalties.
Is the extra work worth the effort? After all, shouldn’t the quantitative analysis be enough? Those are the hard numbers, rich in their detail, to bring a smile to the face of the most hardened Chief Financial Officer. Yes, however, sometimes it is best to add that extra piece, which covers the risk management side of the equation as well.
How the CISSP Credential Can Help You Succeed
The CISSP CBK explores each domain from the perspective of risk management, and more importantly, risk mitigation. In every aspect of business, whether you are an independent consultant, or you work for a company of any size, there will come a time when you will benefit from understanding quantitative and qualitative analysis. The knowledge gained through the study of the CISSP CBK will serve you well in stating a case at any level of the corporate hierarchy.
To discover more about CISSP explore the, 9 Traits You Need to Succeed as a Cybersecurity Leader whitepaper.
The post More Than Likely, Or Less Than Probable: Is a truly quantitative security analysis possible? appeared first on Cybersecurity Insiders.
May 21, 2021 at 09:09PM
0 comments:
Post a Comment