Why is it important to apply security best practices when the risk they protect against is very low?

Question

Sometimes, security best practices protect you against attacks that are very improbable. In these scenarios, how do you defend the implementation of such security measures?

For example, password-protecting access to the BIOS of a thinclient. A BIOS without a password is a risk because an attacker with physical access can change BIOS configuration in order to boot from USB and access the data of the system without authentication. In this case, the attacker needs physical access, the thinclient does not store too much important information, etc. The risk is very low.

Other examples may be related to some measures when you harden systems.

In this case, is it better to not enforce this security measure to be reasonable with the rest of the company or you are opening little holes that will punch you in the face in the future?

Answer 1

The potential impact of this is not low, regardless of how much information the thin client stores.

Specifically the risk is that an attacker installs something like a rootkit or software keylogger in the operating system of the thin client, which you are unlikely to be able to discover by inspection. (This is a variant of the Evil Maid attack).

Should any administrator ever use that client in the future, it will be game over for the network. The thin client can also be used as a beachhead to launch further attacks against the network, or to conduct reconnaisance.

Protecting the BIOS prevents this from happening, by protecting the integrity of the thin client OS.

The wider lesson here: Best practice saves you the expense and difficulty of assessing every risk, which as this question demonstrates, is hard to do.

Answer 2

Costs are the basis to evaluate risks and their mitigations. If the costs (monetary costs, operational costs, ease-of-use costs etc.) to implement a defence (best practice, etc.) exceed the damage caused by the risk being realized, then you are justified in choosing the accept the risk.

This is pretty basic concept in risk management.

Answer 3

Best practices are not laws but recommendations. They usually come with an explanation why they are recommended. If you feel that the explanation does not apply in your case your are free to ignore the recommendation. You might even be right with this feeling and thus you can save costs.

But be aware that depending on your working environment you cannot simply ignore the recommendation, but you need to document why you feel that it can be ignored. It might also be that you are responsible in person if something bad happens because the best practices got ignored. Thus it is often easier and less risky to follow the recommendations than to ignore them.

Answer 4

There are a number of factors to be considered here:

1. What's the cost of implementing the measure? Protecting all BIOSes can be a pain, but isn't a significant outlay of money or effort.

2. what's the risk of a bad thing happening? The chances are fairly low, but the impact is moderate (keyloggers are mentioned, there are a number of other issues with someone executing their own code on your system, namely that it is no longer your system). The actual risk is low-to-medium.

3. What's the impact of implementation? Are there any legitimate reasons for the average user to be accessing the BIOS of their thin client? Not really.

So we've got something where mitigation doesn't cost much, doesn't have a major impact, and protects against a low-to-medium risk. I'd say that's a good argument to implement it, personally.

Answer 5

In many cases it boils down to a question about what very low risk means. If you have an exact knowledge of how low the risk is, you can do calculations on the expected cost of not mitigating the risk.

In reality you rarely know the exact risk. Often potential security problems are dismissed as very low risk without any attempt at an actual assessment of the risk.

In many cases it requires less effort to solve the security problem than to evaluate the risk with sufficient accuracy to make an informed decision on whether to address the security vulnerability. For me that is the primary argument for addressing even security vulnerabilities of very low risk, because it means you save most of the cost associated with evaluating the risk.

Who can always tell the difference between a security problem known to be low risk and one assumed to be low risk?

Sometimes it is more productive to evaluate security problems against each other rather than evaluating each individual security problem against a low risk threshold.

In your specific example you could compare the risk of malicious change of BIOS settings to the risk of network connection on the device being bugged with a MITM device.

Answer 6

Sometimes, security best practices protect you against risks that are very unprobable. In that scenarios, how do you defend the implementation of these security measure?

You shouldn't have to defend anything; let the numbers speak for themselves:

1. Probability of attack X occurring = P.
2. Total Cost of X if it occurs = TC. (This needs to include diagnosing and fixing the breach, lost revenue, reputation, lawsuits, crisis management, etc.)
3. Cost to take security measures to prevent X in the first place = C.

The equation is simply:

C < P * TC

When the equation is true, the security measure should be implemented. Of course, the difficult part is calculating P and TC to begin with, but you may find you can be overly conservative on TC and overly optimistic on P and it will still be a worthwhile investment. Plus you also get the added benefit of publicizing the security measures to investors and/or customers.

This is obviously an oversimplification of all the factors to consider, but from a ROI point of view, the logic should hold up.

Answer 7

The posture you adopt is based on the environment you are operating in. At the very least, the security policies you create are proportional to the budget you have and the threat models you have in mind. Without an assessment of the dollar value you are protecting, you will be spending an exorbitant amount of time figuring out where the holes are. On the other hand, criminal elements use low/no protected elements to search for higher value targets.

Also bear in mind that vendors purporting to help mitigate risk do not come with the silver bullet to solve every single problem. Ultimately you and the business are the only ones responsible for the security. From a business angle, you could pass on the costs of security errors/flaws, but it might not help in the long run. It's a pretty hoary world out there at the moment.

Answer 8

So this is kind of an extension of schroeder's answer.

I think there's a slight mix-up here in what we mean by 'risk'. You're looking at risk from the perspective of the computer system (password the BIOS, install AV, use a firewall, etc). The perspective that Schroeder is talking about is from the business' perspective: once the machine has been compromised, what is the associated cost?

When a business has a 'risk', there are a few things it can do:

• Accept the risk - assume nothing bad will happen, and if it does it won't be a huge problem to deal with.

• Risk avoidance - Avoid exposure to the risk at all.

• Risk limitation(mitigation) - Reduce the likelihood of the risk happening.

• Risk transference (CYA) - Make sure someone else is responsible for the risk.

To be clear, the two types of risk that are being discussed in the thread:

1. The risk a business has should a particular system be compromised. This can include customer financial information (credit card numbers, etc.), as well as proprietary information, trade secrets, classified information, etc.

2. The risk OP is proposing: the risk of a computer being compromised in a specific way.

Here's the nuance I'm getting at: #1 is the business' risk. The strategy to dealing with this risk is typically through risk limitation (mitigation). That's where #2 comes in. #2 mitigates the likelihood that #1 will occur. We consider many different methods in which a computer can be compromised in #2, and implement preventive measures in order to mitigate #1 as much as possible. Since a lot of 'best practices' are cheap or no-brainers (i.e. their cost is easily justified), it makes sense to follow them even if on an individual basis their attack vector is highly improbable.

Answer 9

In regards to your example:

All access to a system/network/forest/thing that contains secure data, must be kept secure from end to end, no matter how small the end is.

In regards to security in general:

All access to a system/network/forest/thing that contains secure data, must be kept secure.

Why?

There's a reason for this. A single access point to a network that contains secure data, is itself in need of security. Information of what has happened on the system as a WHOLE must be secure to keep the secure data all the way in the smallest part secure. If a single link in the chain breaks, the chain is broken.

But how do I break that chain if there is no security information on the client? Simple, by observing the network. If I can see what goes on in the network, I can learn what keys will get me through what locks, how, and in what ways. Then I have an easy way to get into your network, and get your data. That is why, from end to end, ALL activity must be kept secure.

---

Let's go to the example of punching you in the face:

1. You think your home is secure.
2. You have bio metric finger print scanners(LIKE ON TV) that mean only your fingers get you inside
3. You touch a door knob on a store front 70 million miles away, six years ago
4. I lift that print
5. I identify your print(through some long drawn out process)
6. I use that print to open your home while you sleep
7. I punch you in the face

Even though it was miles away, and that print had many other prints, and so forth and on wards, I could still eventually find your print in there, and use it to open your home. This is very improbable, but if I REALLY want to, I can still punch you in the face with time, effort, and some patience.

---

Still though this doesn't do more than present an example. Let's instead state the truth of security:

The most secure system in the world in buried underground, in an unknown location, burnt to a crisp, and destroyed.

Sure that's a little tongue in cheek, but it gets the idea across. So yes this security best practice should still be used. After all your system isn't the most secure system in the world, so you should try and get close.

Answer 10

As it has already been said, security is mainly a risk vs cost approach.

But IMHO, there is another point to considere: as in building security, a reinforced door is little use if the window is left open. To correctly evaluate a risk you must know what to want to protect against. So protecting BIOS with a password because it could be a vector for an attacker that could have a physical access. IMHO, if an attacker can gain physical access to a computer, this computer is compromised because anything could happer: a physical key logger in the keyboard itself, an network analyser between the internal connector and the external plug, a malicious USB device inside the box, etc.

But BIOS password is still good practice because it can prevent further infection if an attack reaches the post, and mainly because it prevents a careless or clumsy user to break or compromise himself its own terminal.