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.
rule of thumb: if implementing the security controls costs more then the potential impact. You should reconsider.
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:
- network segmentation (only specific vlans can access the environment)
- WAF (web traffic rules)
- 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.