In this blog, I cover:
A somewhat popular StackOverflow answer to introduce a metaphor about useless security controls
How to tell if a control is probably useless
Why useless controls are bad for the industry, advising where to go from here, and tease a future series of blogs diving into specific common, useless controls in depth
Chimps in a Cage
A resource that I (and many others, us security bloggers are all very original) advise aspiring security minds to do to learn security is to go on the Security StackExchange and read a bunch of the top questions and answers.
If you carry out this sage advice, you'll come across Tom Leek, the highest karma'ed answerer on the InfoSec exchange. He has a great way of explaining things. My favorite answer he ever gave responds to a query as to why so many applications still had character length restrictions (this was some years ago), typically eight characters, on passwords:
Take five chimpanzees. Put them in a big cage. Suspend some bananas from the roof of the cage. Provide the chimpanzees with a stepladder. BUT also add a proximity detector to the bananas, so that when a chimp goes near the banana, water hoses are triggered and the whole cage is thoroughly soaked.
Soon, the chimps learn that the bananas and the stepladder are best ignored.
Now, remove one chimp, and replace it with a fresh one. That chimp knows nothing of the hoses. He sees the banana, notices the stepladder, and because he is a smart primate, he envisions himself stepping on the stepladder to reach the bananas. He then deftly grabs the stepladder... and the four other chimps spring on him and beat him squarely. He soon learns to ignore the stepladder.
Then, remove another chimp and replace it with a fresh one. The scenario occurs again; when he grabs the stepladder, he gets mauled by the _four_ other chimps -- yes, including the previous "fresh" chimp. He has integrated the notion of "thou shallt not touch the stepladder".
Iterate. After some operations, you have five chimps who are ready to punch any chimp who would dare touch the stepladder -- and none of them knows why.
---
Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old [DES-based "crypt"](https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_32.html), actually a password _hashing_ function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.
The Internet is full of chimpanzees.
I love this answer.1 The internet is indeed full of chimpanzees. Worse, this isn't just the lowly, uneducated masses; our security ecosystem is very much full of chimps. Our chimp behaviors are similar to the original DES issue above: we tend to invest in useless2 controls that don’t make sense, usually impacting operational effectiveness.
This is a huge problem for the security industry: I’d argue at least half of our efforts (or at least our budgets) go towards controls of minimal to non-existent value. I'd like to go over the implications of this; the next several posts I make (and probably many more a year until I retire or die) will be to understand the why for common, useless security controls.
How to Tell A Control Is Useless
If the control can only be explained in a nebulous way, such as "to improve security" or "for compliance reasons", that's probably a useless control. If the security-ish person forcing the control on you cannot adequately explain it, it's probably because they have no idea why themselves. If that security-ish person doesn't understand why, it's a good heuristic that there isn't a legitimate why at all.
"But Jon," you say, unhappily trapped in this conversation, "What if the reasoning is very complex and hard to explain to people who are not experienced security masters?". This is a fair question on the surface.
How many controls can you think of that you know are useful, and you genuinely know why they are, but you can't explain it in 2-3 sentences to someone with a modicum of technical understanding? Some examples:
Encryption in transit is valuable because it prevents anyone with access to points on the network between you and your friend from viewing or modifying your messages
Private S3 buckets are valuable so you don't leak your data all over the place and have embarrassing articles written about you
Cross-site scripting (XSS) safe front-end frameworks like React are good because they prevent XSS. XSS is bad because it allows an attacker to take over your active web session and do horrible things
See? Easy. There are many complex things about security, but these are almost all in how we do things. The why is almost always pretty simple.
You won't be able to give wonderful off-the-cuff explanations for every security control you ever implement. It's more that every control you consider, spend resources implementing, and spend other teams' resources in dealing with the implantation should be explainable after you think about it. The reason should never just be "to support our robust security posture." That's a tautology, and tautologies outside of XKCD comics are bad.
The Damage of Useless Security Controls
When I rant about this with my peers, mentors, friends, family, and unfortunate bystanders at the bar, a common reframe is, "Why is this so bad"? It's still people caring about security. So what if some of that isn't as effective as it could be?
We are so resource-constrained as an industry. There's not enough manpower, budget, and political capital. We can't be wasteful while still being effective stewards of the systems and data entrusted to us. We can't waste any of it! And we certainly can't keep asking for more budget when we're blowing 50% of what we already have on useless crap.
People, going about their everyday lives and jobs with their own problems, deadlines, and OKRs, have a finite amount of fucks to give about security. You have to use those fucks very sparingly. We can only get the average person to do a few things to help secure themselves or their company; wasting most of those slots on uselessness is devastating. We can't afford to be chimps.
These also aren't decisions that only affect the implementing company. Many useless controls are in compliance and control frameworks and standard maturity models, forcing waste on whole swaths of companies.
Many, many more are added by well-meaning security teams to security questionnaires, forcing every company that tries to sell to them to at least spend time discussing why they don't do it. Sometimes this leads to much back and forth, wasting time on both sides. I've spent depressing amounts of time implementing useless controls, not for their value (there was none), but because the time cost was lower than explaining to prospects why we don't do them every single week. This is devastating to security teams at medium-sized companies; I know several 3-4-person security teams whose roadmaps are hamstrung due to the cost of customer requests for useless dribble.
Worse, useless controls may be added to contractual security addendums. Worst, these contractual requirements can be recursive: As a signing company, I not only have to implement the useless control myself but require all of my significant sub-processors to implement it as well. These types of contractual requirements can be depressingly hard to unwind, leaving the entire industry in a less secure state, not because we even think the control is useful anymore, but because we're contractually bound to beat up any chimp who tries to effect change and grab a banana.
Where Do We Go From Here
Don't be a chimp.
Don't implement controls without knowing why! You should be able to figure out the threat model related to the control, understand the threat this control is mitigating or the outcome you're looking for, and vaguely, how. You don't need to understand the TLS handshake process, how keys are computed, or how cipher suites are negotiated, but you need to understand what TLS buys you and where that is actually useful.
If you're on a security team, you should demand this from your peers.
If you're a normal employee, engineer, or executive reading this post for some reason, you should demand this from your security team. Make them tell you why. If they can't in a satisfactory way, it's probably not because it's complicated but because they don't really know themselves. Send them this post as a response; I can use the impressions.
I'll be publishing a series of posts diving into useless controls that we still demand everywhere. Many of these are ones we call for all the time in industry everywhere, so I hope it'll be interesting!
Ones I’ve written so far are:
Some of these are controls many of my friendly enterprise clients care deeply about still, and to avoid giving them an aneurysm, I'll confirm I actually carry those out where appropriate. I do carry them out, very well, because I like their money.
I'd Love To Hear From You
Do you agree? Disagree? Intensely? Do you have any other feedback for me? Please leave a comment below; I'd love to hear it!
Other Tom Leek Answers
In case you enjoy that kind of stack overflow answer as much as I do, here are my other favorites:
https://security.stackexchange.com/questions/54120/is-google-overreaching-by-forcing-me-to-use-tls/54129#54129 (I enjoy that there was a time when people were concerned that Google was evil for enforcing HTTPS)
Yes, I know this is a common thought experiment and not a Tom Leek original; see https://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu.
By useless, I mean a range of utilities, from actually useless to not just solving anything in the top 50 or so problems we actually face.
Drawing from my experience and active contributions to the security community, I appreciate how the blog highlights valid concerns about the limitations of static security controls and an over-reliance on compliance-driven measures. However, I believe the narrative could unintentionally downplay the critical role that well-designed controls and guardrails play in mitigating vulnerabilities and preventing exploitation. Below, I’ve outlined some constructive feedback to provide a more balanced perspective:
1. Security Controls as Foundational Best Practices:
While some controls may appear ineffective in isolation, they serve as foundational layers in a defense-in-depth strategy. Without robust guardrails, systems are far more susceptible to bypasses, misconfigurations, and exploitation of overlooked vulnerabilities. Security is not just about stopping every attack but mitigating risk through layered protection.
2.Addressing Common Threat Vectors:
Security controls and policies are essential to mitigate common and preventable threats like phishing, credential theft, and lateral movement within systems. Dismissing these controls without offering a structured alternative risks leaving organizations exposed to basic but damaging attacks.
3.Adaptive and Dynamic Controls:
The blog correctly identifies the need for adaptive security measures. However, static controls can act as baselines to enforce secure practices while adaptive mechanisms respond to evolving threats. The integration of static controls with real-time monitoring, behavioral analytics, and threat intelligence strengthens overall resilience.
4.Guardrails for Human Error:
Security controls also act as compensatory measures for inevitable human errors or oversights. Without automated enforcement, vulnerabilities such as open cloud buckets, insecure APIs, and excessive permissions are far more likely to persist.
5.From Compliance to Security Outcomes:
While compliance is not synonymous with security, controls inspired by regulatory frameworks often address critical risks (e.g., encryption, access control, and auditing). The issue lies not in the controls themselves but in ensuring they are contextually appropriate, monitored, and updated regularly to align with real-world threats.
6.Need for Balanced Critique:
The post could better reflect the nuanced role of controls by discussing how they integrate into broader frameworks like Zero Trust, DevSecOps, or Security by Design. Highlighting their effectiveness in well-implemented scenarios would provide a balanced perspective.
Conclusion:
Rather than viewing security controls as “useless,” the focus should shift to optimising their design, deployment, and evolution. Controls and guardrails are not the entire solution but are indispensable components of a secure system. Combining them with adaptive and threat-aware mechanisms ensures that vulnerabilities are mitigated effectively while addressing the dynamic nature of cyber threats.