Security in depth vs security theatre

Question

If some security measure serves only to add an extremely small barrier to an attack, are there generally accepted principles for deciding whether that measure should be retained?

Does defence in depth advocate that any hurdle (no matter how small) should be left in the path of potential adversaries, or does it only require redundant substantive hurdles (that might have been expected to suffice individually)? Conversely, does security theatre advocate for removing the low hurdles (to avoid overestimation of the actual security), or does it only require that some substantive hurdles must also exist (tolerating for low hurdles to be placed too)? In other words, concerning weak additional security measures, is there a general consensus or diverging views?

An example might be something like limiting general developers and wider staff from having visibility of security discussions and analysis. This avoids leaking security analysis in convenient form to an attacker if a staff account becomes compromised, but it also reduces opportunities for alignment and collaboration on security and security culture. Alternatively, a small potential security benefit may come at the cost of complexity (potentially raising maintenance expense or risking misconfigurations and security holes), for example a policy of censoring AWS EC2 instance ids in support requests adds friction/inconvenience but the supposed benefit is unlikely to be critical.

Answer 1

I'll try to cover your question on a high level, which means my response does omit details and should only give you some guidance not be your security policy ;)

If some security measure serves only to add an extremely small barrier to an attack, are there generally accepted principles for deciding whether that measure should be retained?

Security controls (measures) are a way to adress risks observed, so you are deciding the risk response (mitigate, reduce, accept, transfer). Security controls are ways of mitigating or reducing the risk. Having to decide which of the risk responses to apply tend to depend on 2 factors: resource cost and risk appetite.

resource cost rule of thumb: if implementing the security controls costs more then the potential impact. You should reconsider.

risk appetite rule of thumb: does the risk feel like one you are willing to take or not? (likelihood * impact).

Does defence in depth advocate that any hurdle (no matter how small) should be left in the path of potential adversaries, or does it only require redundant substantive hurdles (that might have been expected to suffice individually)?

The definition of defence in depth is a whole other discussion. My working theory on defence in depth; It is no so much as redundant controls but more layered in my mind. If you have two controls, ways to circumvent the first should not apply to the second. For example, to reach data in an application you (could) have 3 layers providing "depth" to the security:

1. network segmentation (only specific vlans can access the environment)
2. WAF (web traffic rules)
3. Authentication (user authentication on the application)

Conversely, does security theatre advocate for removing the low hurdles (to avoid overestimation of the actual security), or does it only require that some substantive hurdles must also exist (tolerating for low hurdles to be placed too)? In other words, concerning weak additional security measures, is there a general consensus or diverging views?

i.m.h.o security theatre is about addressing the "great big steel doors with the key hidden below the flowerpot next to it"; Yes you should always consider if a control is adding value or if the costs is more then the benefit.

An example might be something like limiting general developers and wider staff from having visibility of security discussions and analysis. This avoids leaking security analysis in convenient form to an attacker if a staff account becomes compromised, but it also reduces opportunities for alignment and collaboration on security and security culture. Alternatively, a small potential security benefit may come at the cost of complexity (potentially raising maintenance expense or risking misconfigurations and security holes), for example a policy of censoring AWS EC2 instance ids in support requests adds friction/inconvenience but the supposed benefit is unlikely to be critical.

Yes and no (i think), I try to work on a couple principles for security measures:

• Never depend on a single control; Think "what is the risk of this control failing" and if that means houstan we have a problem you need additional measures.
• Stack (layer) complementary controls. E.g multiple authentications do jack sh*t as users tend to re-use passwords vs a single authentication with MFA.
• Cost vs risk. Every security controls has costs, financially, reputation, time, etc. Is the 'battle' to have the control worth it or can i spend my cost somewhere else.

Specifically a note on cost: If it costs me a lot of good will to have MFA on some backwater application and I can do the same with getting network segmation. I am going for network segmentation, even though that means that one "gap" will remain.

Answer 2

are there generally accepted principles for deciding whether that measure should be retained?

It's called risk management. Evaluate the actual threats, evaluate what risks a specific security measure can reduce and decide if the costs of the security measure (which include reduced usability, but maybe also not being able to do specific things) are worth the added security.

Does defence in depth advocate that any hurdle (no matter how small) should be left in the path of potential adversaries

Defense in depth advocates that one should not assume that a single measure is always sufficient to mitigate a specific risk, but that one should better use layered security with a variety of complementary security measures to reduce the risk. It does not say anything about doing everything possible, instead one still needs to evaluate costs and benefits of a measure to decide if it should be implemented.

Conversely, does security theatre advocate for removing the low hurdles (to avoid overestimation of the actual security) ...

Security theater has nothing to do with what you describe. It is instead about measures which make you feel more secure without actually adding substantial security.

Answer 3

Design a work around for your collaboration problem and then implement your added security. I use zero trust as my mindset and work my way backwards until I have full functionality.

I will always advocate added security since your biggest threats are inside, not outside. The only time I abandon added security is when I can not gain proper functionality after implementation.