Digging it up on Security Costs and Security Budgets - part1

In my previous article, security costs and security budget, I made some assumption to simplify an introductory analysis on how much we should spend on security.

Some of those assumptions have been made to simplify out tasks.

Today I would like to quickly analyse some of those simplifications.

One of the biggest assumption I made on the previous article is that if a problem cost us X then we can find a number n that express the number of incidents I’m allowed to permit so that nX can express the cost I’m allowed to accept. This simplification was based on two ideas, the first is that (as reported in the article)

Just to translate this in terms of Systems engineering this means: would it make any difference if the service stop is due to a broken disk, a server HW failure, a software failure, a network failure or a Dos attack?
I should answer really  I DON’T CARE  since the result would be systems down anyway.

the second is that the incident cost is X and the cost remain the same for each repetition.

The truth is a little different since, again, we have to take into account some human behaviour aspects and other occurrences.

with the simplified model presented in the previous article we were able to assume that

stating C as the cost we could afford we were able to find a relation where

C=nX

would be quite easy so determine the n number of incidents since would have been

n=C/X

now the n number would have been useful when trying to determine the kind of technologies we need to put in place.

In a real environment C is not a constant because the process “P” has not a fixed value. This means that C is a function and not a constant value, and depends on some factors as the sensibility of the management, the risk perception and of course the value of the process itself.

C(P,t ….)

Of course C and the process P can be fixed to make our budget to predetermined values at a certain time “t0” for example we can consider the value of P and C at the start of the year based on the previous year experience.

on the other end it is not truth that all the incidents that make me to stop the process can cause me the same costs.

If I stop the process “P“, for example, for a HW failure I’ll have different internal impact if the stop to “P” is due to an hacking.

Even if the two occurrences make the same damage (for example think of a disk failure because of a HW failure as a broken controller, or software failure due to a virus) the perceived quality of the damage is different (and somehow irrational).

An HW failure is usually well understood and usually some mitigations are improved by design and usually well tolerated from the upper management, on the other end an Hack would be perceived as a more serious matter (and, as a matter of fact it should be).

Here we have the irrational behaviour, although an Hacking, or malware attack would be perceived as more dangerous the risk perception on those kind of aspect is so low that management do not even put some effort by design as for an HW failure.

This means that the X is different for any kind of accident and so we will not have a single “n” to count on but

where the

n_iX_i

are related to the different kind of incidents that can occur to the  process P

Obviously we have to take in account the fact that  n_iX_i    are somehow critical where n_i and X_i  (with n related to X both bound to a specific type of incident)  are the parameters we should use to understand what part of the budget should be allocated on a specific technology.

so here the question:

if both the incidents we talked before (HW failure and Software Hack) have to be considered how I have to deal when balancing the budget?

One way, used by most of the company, is to transfer part of the risk to another department.

This is usually the dept. in charge of storage or servers or…..

So apparently this seems a good thing, you as a security guy have to deal with less stuffs, but the reality is that a portion of the security budget is diverted on other budget voices so that you loose control and contract power when contracting your budget. Basically the problem is how you can ensure that the HW failure worths more or less money than the money related to the hack?

On the other end, an objection I usually receive is: if we put this in the security spending we we’ll see just that that budget would be reduced without further explanations.

in other words Ctot would be not equal to the sum of the two C(HW) + C(Hack)

Ctot<C(Hw)+C(Hack).

Alas security metrics are still considered too much complicated for most of the management, and this is not my statement but the result of several survey and literature, so it is hard to change this behaviour.

To Be Continued ….

Related articles

• Security Costs and Security Budgets (aitechupdate.wordpress.com)
• Understanding How Network Security Professionals Perceive Risk (sei.cmu.edu)
• Social engineering tops list of help desk security threats (net-security.org)
• Avoid These Errors When Making a Budget (cashaccounting.net)
• OVH : Security Incident (status.ovh.net)
• Apple hacked!! Ethical hackers personal information hacked at Apple (parsonsisconsulting.wordpress.com)
• Digging it up on Security Costs and Security Budgets – part1 (aitechupdate.wordpress.com)
• Viber App Hacked By Syrian Electronic Army (iClarified.com)
• Car hackers ‘drive’ car with laptop (bbc.co.uk)
• This Is Costing The U.S. As Many As 500,000 Jobs Per Year (huffingtonpost.com)

[contact-form]