Cybersecurity and the curse of binary thinking
philvenables.com
philvenables.com
The binary fallacy is endemic in cybersecurity. At INKY we do active blocking of phishing emails, so people automatically assume that we must take the position, as many of our peer companies do, that “simulated phishing awareness training is worthless”. What we’ve actually found is that phishing awareness training is useful in that it trains users to be rightly suspicious of the identities of email senders. It doesn’t really train users to spot phish, no, but that doesn’t make it worthless!
On the subject of end users I agree with the author as well. What we’ve found is that if you give users useful guidance they truly understand, on a minority of emails, they actually follow it and click on far fewer bad links, pay fewer fake invoices etc. On the other hand, if you slap a static banner on every incoming email that says “external: be super careful!” and nothing else, users quickly learn to ignore this useless information and ultimately become completely blind to it. (And no, making the banner really fugly doesn’t help any.) In our experience with email security over the last 6 years, escaping the tyranny of binary thinking is absolutely critical to getting users properly engaged.
Why would type enforcement do any good? When do operating systems enforce types?
My money is on capability based security, Genode and Fuchsia and GNU Hurd when it comes out. Give the users a safe way to run a program without exposing everything to danger, and you'll save everyone a ton of grief.
The present scenario is analogous to building more and more layers of security out of crates of explosives. Any little reaction anywhere becomes a reaction everywhere, because all the code in our systems is trusted.
Full disclosure: I was on the Sidewinder team at Secure Computing way back when.
Thus, you can see why I was mystified.
The product was discontinued in the late 90's and its core features such as RBAC was included in standard Solaris in later versions. However, the more advanced stuff like tagging of connections, etc, was never included and was dropped with the demise of Trusted Solaris. I think it says a lot that I worked at Sun at the time and I actually never used it.
A bunch of research operating systems from the 90s and 00s were based on this kind of design. Microsoft had a largeish engineering team working on one for 9 years (with a notion that it might some day supplant Windows; it was even briefly used in production to run some services, before the project was shut down in 2015). If you're curious about how it worked and why, one of the designers wrote some fascinating posts:
http://joeduffyblog.com/2015/11/03/a-tale-of-three-safeties/ (on how type safety worked)
http://joeduffyblog.com/2015/11/10/objects-as-secure-capabil... (on how the type system was used to model capabilities)
You’d also be surprised how many “please buy gift card” kinds of phish we see. And yes people do fall for them if they get through.
Yet, in the comments, people are explaining Phil’s view of the job to Phil, because Phil is apparently not an “actual technical security expert.” … what?
People like PV build and lead very competent security programs because they see nuance, and focus on biz value. Sec engs, aka “actual technical security experts” who burn out or their companies burn out on them usually don’t.
Edit: I just double checked his resume, forgot to add board if h1, BISO/CISO of a few other banks, former SWE, so on. Security culture is it’s own worst enemy sometimes when evaluating content like this.
Big Nope.
I think one of my actually business oriented colleagues put it best, "I've read through 20,000 pages of NIST security material, and there is no sense of business prioritization, or cogent strategy between all of it."
Truth be told, some of this came out much later. As in, 5 - 7 years later. In the interim a huge amount of abstract security controls that significantly lag actual defensive industry, and the paper A&A / NIST 800-37 process.
Read about two sections that I thought were relevant, the rest was fluff.
LI is not normally a place for security thought leadership.
Given the central points he sits on for his work, that level of access is at a minimum a great way to get some Intel into “govt’s” view on this world. This increasingly matters as they step into the blue team fray vs FEYE leading it. More importantly, security world needs more of that open door policy from senior leaders.
It needs to die a painful death and re-emerge in a different form to be useful.
Rating vendors are incentivized to have a rating for every company regardless of whether or not they have any insight.
Rating vendors cannot act like real attackers, so they must rely on passively collecting some surface level information. This is often no better than you would get by walking through a website with Burp on and checking the list of alerts.
You can pay rating vendors to help you "improve." That is to say, they are incentivized not to fix false assessment data. They can get you to pay for that.
There are two where I disagree with the author (not saying it's unacceptable; the author may be correct and me wrong): the CISSP one, and also the rating vendor one. The author takes a deeper view than the binary thinking, and I want to take it deeper yet to refute the author's view. This arrives at the same conclusion as the binary groupthink in the infosec community, but does so by explaining why the binary idea became de-facto standard.
In case anyone is interested, my beef with CISSP is that the curriculum for CISSP certs promote a highly bureaucratic approach to security. I feel like it is largely a waste of time and money to get that cert. It rubs me the wrong way because once things like CISSP become required for some employment, it is hard to go back to more "lax" standards. Of course, it having a baseline of useful information like the author says is true. I just think CISSP is a net negative for society even so.
1. It's extremely frustrating how much bad security work is done, and how much of it is justified in the name of "defense in depth". So many useless hours spent on mitigation without understanding the threat.
2. Everyone talks in hyperbole. It's shorter and more to the point, and nuance is usually not important in conversation among experts - we already know the nuance. The difficult bit is if you're not an expert, but talk with them, the implicit nuance is lost.
There's also a lot of resentment. I resent compliance. It is a massive waste of both time and money at my company, and is driven purely by sales. We would be safer without compliance because we could have spent that time elsewhere.
> In reality there can be a lot of value in keeping an attacker guessing and creating uncertainty by using deception or a variety of other techniques that could be described as obscurity.
This isn't security through obscurity. I see this all the time, really. If you're keeping an attacker guessing, that's not obscurity, that's a secret. If you're doing it via deception, that's not obscurity, that's a trap. Security through obscurity is "the implementation is less popular, therefor safer", which is nonsense.
I agree with many of the statements though.
> I have become convinced that this “principle of least
> privilege” is fundamentally wrong. Minimizing privilege
> might reduce the damage done by some security holes but
> almost never fixes the holes. Minimizing privilege is not
> the same as minimizing the amount of trusted code, does not
> have the same benefits as minimizing the amount of trusted
> code, and does not move us any closer to a secure computer
> system
Defense in depth, people!
The way I read it, privilege minimisation is almost isomorphic with his actual principle "eliminating trusted code" ... if the code doesn't have access to a resource then it doesn't need to be trusted with that access. So perhaps he is railing against people who want to deploy code into fundamentally insecure contexts and then claim its OK because of protection through limits on privileges .... but he's saying it is always better to improve the fundamental architectural security and not put it in that context in the first place.
There is an inverse relationship with privilege minimization also, that many commodity operating systems require users to maintain a certain amount of privilege to effectively use the system. Reduction of privilege then results in a loss of functionality if there is not a replacing system. With things like high level privileges for admin, but not truly Forest Admin / Enterprise Admin, we only saw native fixes for this recently with the addition of JIT / JEA circa ~2017, or, use of 3rd party administration tools.
Certifications: The typical arguments against security certifications are not that they "don’t represent the full spectrum of skills a professional needs" but instead that many of them teach outdated, useless, or actively negative practices. Then they're used as an advertising tool and organizations with less security expertise are told they must hire based on certifications rather than actual skill.
Compliance: "compliance is counterproductive for security." Most security practitioners don't necessarily like compliance primarily because it's not enjoyable for them. It distracts them from the tasks that they want to be working on. In most cases compliance is orthogonal to security. In some cases it can certainly be counterproductive (e.g. government compliance programs requiring outdated crypto).
Management: The typical refrain "management doesn't spend enough on security / take risks seriously" has been turned into "management doesn’t care about security because they don’t fund every single thing the security team asks for". I mean, it's obvious that the argument wasn't taken seriously by the author just based on how they wrote that.
One other vexing thing in this industry, is that it is very deep. You will often see folks with a deep background in say, reversing, come out with really strong opinions on some other topic such as phishing even though they are little more than observers to that aspect of infosec. Reversing doesn’t qualify you to be a CISO, etc. I just made my own straw man there, but it’s a truism in my opinion.
The core thrust of the article is reasonable though. Often we want an amazing solution or a big win when improving something even a little is a real improvement from a security perspective. A lot of little wins in an organization can really add up to changing its security culture, etc. I would ultimately agree the saying “perfect is the enemy of good” applies in the security world.
I have a B2B micro-ISV in the cyber security space, largely targeting a compliance niche - you get out what you put in.
I have customers that treat compliance as nothing more than a pointless burden; a series of boxes to be ticked, "check-box compliance" - all they want is to prove to their auditors that they are following the letter of the compliance standard. I imagine security consultants see this kind of thing a lot, and it's easy to see why they might view compliance negatively.
However, I also have customers that look past the letter of their compliance standards, and look towards the intent - these customers get a lot more out of it, and are actually increasing their security posture as their compliance standards intended.
Most of the arguments are actually quite common on Twitter’s Infosec communities. It’s common to read smug tweets dunking on certifications or security through obscurity or management similar to these strawman arguments in the article.
Not coincidentally, Twitter isn’t a great place to get good infosec advice. It’s too focused on calling out less-than-perfect solutions from a safe distance rather than actually examining practical security in the real world. This article makes a good point of showing the difference and would be useful for newcomers who might be confused.
Compliance is the bludgeon that says "go make this right". Then security admins bitch about not having the time, and we say we don't have enough people in the industry.
Automate the boring stuff. We do have a shortage - a shortage of people who are creative enough and talented enough to script their toil away.
A great example of this is the debate around fail-open and fail-closed in different scenarios.
Depending on the system, the function, the security objectives underying it, and the way in which success or failure is determined, eventually, a decision can be reached about what is optimal for an organization in a particular case.
It is completely consistant to argue for fail-closed for a low availability requiring system with a big attack surface that is internet facing, while simultaneously proffering fail-open for a mission-critical industrial control system with strong physical protections that is in a locked-down closed off environment, unpivotable, for which work stoppage is a serious threat. Basically, something unlike Colonial Energy..... :)
Not true in my experience. Most end users act in ways that are both less secure and less convenient than they could.
Either because they don't want to make the upfront investment (in setting up a password manager for example) or because they simply don't know any better.
Wore still, surprisingly many more advanced end users believe in security through inconvenience: rotating passwords, timed logouts, etc.
If you already know how to use a password manager, yes, it will easily improve productivity.
But for a non-technical end-user who has never used a password manager before, learning to use one is neither straightforward nor is it convenient.
Not only is it learning a skill which is not critical to their core deliverables — which virtually no one has time for — it also has the worst kind of failure mode: if the user needs technical support, it’s likely that they are locked-out of a service and at a standstill until they receive that support.
The irrational thing to do would be to refuse to learn about a password manager. Your argument works if you focus narrowly, but when you see a fuller picture, your argument falls apart.
Optimizing for time and energy has to do with how one uses their waking/working hours.
At some point in my career I worked at a private Catholic college where many of the professors were 60 to 80 year-old nuns.
They were very smart people but their predisposition to learning computer technology was minimal. Something that might take me hours to learn might take them weeks of frustrating, unintuitive trial and error. Frequently, they couldn’t pick up certain new computer skills at all.
I could not imagine teaching the nuns how to use a password manager. It would be a disaster.
This is an extreme example, but somewhere in every skill there’s an inflection point where it becomes impractical to learn that skill if it’s not part of your core competency as a worker.
Many, if not most, users who would benefit from a password manager simply can’t develop that skill if they are expected to finish the normal duties of their work. They are optimally using their limited time and energy because learning a new skill would impact their functionality in their primary responsibilities too much.
If you can’t imagine users from your work-life that would have this problem... I feel like you just don’t know very many users.
Password managers are a poor substitute. They don't work well and they are not consistent across websites.
Let's say you're part of the marketing team and need to sign up to some ad platform or do a one-off order for branded goods. They will most likely not support SSO, and even if they do you won't have the necessary privileges to actually set it up.
(Which is not even remotely true)
In reality, all systems contain bugs, but the presence of a single bug shouldn't be enough, on its own, to render a system insecure: defense in depth should ensure that a system remains secure even in the presence of minor bugs in any one layer.
On the skills crisis, it just means that security professionals are both expensive and not worth it. As if they (we) were creating value, nobody would say they were expensive, or say that they didn't have the skills to solve the problem. It's not unlike insurance, where you make sacrifices at the altar of compliance and hope the authorities are kind if calamity hits.
While I appreciate the creative cognitive tools for finding alternatives to percieved limits and principles, this dissolving of binary thinking is also a trend to destabilize concreteness and logical thinking and convert issues into an unstable managed consensus, which is effectively a political struggle. It is a cognitive style with a whole bunch of tactics wrapped up in it that are designed for managing groups and not for making things, fixing things, and getting people things they want. We would benefit from some of this in security, and in fact I have used it and seen it work. However, the entire approach resembles how a mother might tell her children to share something, which assumes the thing already exists and what needs resolution is the rights to it as governed by her, which is certainly appropriate in some organizational contexts and situations, but as a single note cognitive style that includes things like non-violent communication, narrative controls and some other tactics, the method sets off a bunch of alarms. The instinct to subvert and subordinate problems as a means to manage them instead of solving them concretely is a powerful tool, but one that we should acknowledge as critically as we do so-called binary thinking.
Another way to look at it is that the author isn't attacking concreteness. Instead, the author is taking generalizations and adding context for why that generalization exists. This helps identify when the generalization applies and when it does not.
What is said: certifications like CISSP don’t represent the full spectrum of skills a professional needs therefore certifications are a waste of time.
Reality: certifications represent a foundational body of knowledge for new entrants to the field - to start the "scaffolding" of their knowledge. It helps employers test a candidate’s commitment to the career and so is useful as long they don’t mandate it above all else.
However, what does the ISC2 marketing material say? Let's take a peek!
Earning the CISSP proves you have what it takes to effectively design, implement and manage a best-in-class cybersecurity program. With a CISSP, you validate your expertise and become an (ISC)² member, unlocking a broad array of exclusive resources, educational tools, and peer-to-peer networking opportunities.
Prove your skills, advance your career, help earn the salary you want and gain the support of a community of cybersecurity leaders here to support you throughout your career
From https://www.isc2.org/Certifications/CISSP
So, basically, a nontechnical certification that is shallow and broad has managed to insinuate itself as the way towards being able to run a security program, and more valuable than any technical security degree, or a CS degree, or a PHD in Cryptography. It claims to be both for security pros with many years experience, but others say it is foundational material. This has then led to a negative cycle of incompotence, bringing in nontechnical types into a field that is uniquely demanding for broad technical skills normally gained through years in the trenches (SRE/development/administration/network engineering)
Is there any wonder why we have a security problem?
Calling it equivalent to a masters was also a marketing coup, there was plenty of discussion and pushback on that characterization when it was announced
The CISSP, with it’s 5 year of experience requirement is not foundational, full stop. What some people attempt to lie about is irrelevant.
> Is there any wonder why we have a security problem?
You're absolutely right, but it hurt to read.
I know the management/technical divide has existed for a while, and yes, I know management sometimes has a point in stopping technicals focusing on irrelevant details. But... jesus. I'm currently tasked with evaluating "what an attacker could do" having compromised <X> on a <Y> system. No, I'm not allowed to evaluate a specific <X>'s likely vulnerability, or even an exact specification of <Y> - because that's losing the bigger picture.
What do I even say?
Opportunity and convenience do matter in terms of security. Maybe more in the physical world, but it's not irrelevant in the digital world either.
Or I could, you know, take the time to inform myself about these things.
Re: The cloud
I used to say that snarky thing proudly, and then I worked on AWS services for a year. Yes, many of them are seemingly overcomplicated. No, you should not go to the cloud to save money.
Yes, you should go to the cloud for a host of potential reasons. One example is IAM. In AWS, every single thing that one can do is controlled by the same policy language and user/role/action framework. Even if the policy is (very woefully) expressed in JSON and not one of a dozen more appropriate languages, it is an incredible feat of IAM to have so many disparate tools controlled with the same language.
Re: Security through Obscurity
I put my SSH ports for lab boxes on port 222. My auth logs drop by orders of magnitude. It doesn't mean I weaken my password or SSH cert, but it means my logs are cleaner, the chance of getting pwned by a 0day are just that much less, and those are benefits.
Re: Open source
I love FOSS. I don't think it is the end-all and be-all of security, though. And when it comes to cybersecurity tooling, I would much rather use certain closed-source NGFWs than opnsense/snort at the perimeter of a large organization. Disclosure: I work for one of the NGFW companies. Point is, seeing the code isn't the last bastion of security.
Re: Compliance
Yes, yes. OP is correct. It is needed, but is not the end-all. A competent audit/compliance regime sets up requirements and recommendations specific to your organization based on government regulation and industry best practice. They will work with you on what is a hard requirement and what can be justified as a mitigated measure, balancing the law, the threat risk, threat likelihood, and compensating controls. At best, they are partners with Infosec, pushing management to do what Infosec knows needs more focus, and slows down management that doesn't want to spend money, or just wants to "move fast and break things".
So yeah, this person knows what they're talking about.
- IT Security is not allowed to say "No" to Business.
It was like the "Yes and.." drama game.
IT Security had to accept that business had a need to do a thing. That people didn't just think up dumb shit to do, despite appearances.
And it was Security's job to help to enable that thing rather than simply saying "No". Of course, they might end up saying no to a particular process, but then they had to work with the Business for a better process that both sides were happy with. A rebalancing of the tradeoffs regarding speed and security, which can often sacrifice very little speed in the IT world.
It meant that any project or even simple day to day stuff could be run past IT Security with no fear. It helped of course that IT Security employed sociable helpful people too.
Sure, that's the intended outcome. But I work with equally as many certified idiots as I do uncertified geniuses, so at this point it means effectively nothing to me.
Compliance: Encryption at rest! Me, designing for AWS: wtf?!?
Let's not forget that by not encrypting internal connection is how google internal traffic was stolen by the NSA (see Snowden revelations), which is why they now (reportedly, I'm not there) encrypt everything in transit.
I'm not sure how I could get a certificate and by that I mean, without the employers money.
So if you don't want people clicking on links in emails then stop sending email with bloody links in them for everything
PS. I always get my annual security training by a link in an email
Many further comments on this thread: https://news.ycombinator.com/item?id=27494450
Plainly stating that they do not provide scaffolding is nonsensical. Newbies have to learn the boundaries of the field IOT target their prep. Certs basically excel at this (and IMO otherwise useless aside from HR speedbumps).
Otherwise, you see a very common situation like this (verbatim example): someone wants to do cloudSec. They decide a good prep area for that is hosting a DVWA in the cloud and pentesting it is good cloudSec home lab work. Very rarely, short of a cert in AWS for instance to start off with, is it easy to ID that cloudSec prep is actually configuring IAM and hardening some servers, and there are a ton of jobs here and the future of SOC work.
Certs provide scaffolding. If you don’t think this, you’re giving your mentees pretty bad advice and should try to open up your view point here.
I’ve helped lead fairly large 0->Sec Job 1 volunteer/non-profit groups, and have seen X000’s of success stories and failures. Failures always share three things, successes always share the inverse
- don’t understand people-networking matters
- don’t understand certs won’t get a job, and they’ll only help re: credentials to get past basic HR boundaries. The field of Sec+/CySa is crowded as hell.
- do projects that veer very basic red team and overall fairly outside the territory of what they’ll actually be hired for. If they’d have taken a cert, a job description, and a cloud or SIEM localhost home lab, they could instead do very simple, almost out-of-the-box projects they’d work on immediately once hired.
With that background paired with “certs are worth nothing” points out two blind spots to me:
- the value-add certs have exists in non-appsec areas, putting aside CISSP and promotion paths. CySA is going to help you be a better soc anaylst, but ya it’s not getting you into NCC Group anytime soon. A CS degree or knowledge in that direction matters a lot more/only. SWE<>Sec exists in a totally different part of the field, in a way.
- early days security folks have a very different view on how to get into the industry. Back then, it was pre-certs, and even really pre-compsec jobs. Things are a bit different now.
You may not realize that where you stand depends on where you sit, but you’re pretty far from new talent pipelines these days it sounds like.
If single sentence platitudes are how you want to engage, then I’m done as well.
There is huge nuance to the cert topic, but it’s silly to hold a binary “they’re worth nothing” view.
There’s not huge nuance here.
If you do a job like electrician or plumber, you have to learn and do tests in pretty much the whole world before you are allowed to work. Since I'm electrician myself, I know how stupid it can be sometimes to follow all the rules. But then if something happens, you are happy everything was installed in the right way.
But for the rest of us, the question more is about balancing between security vs usability+productivity+accessibility. Where you draw the balance is based on individual judgement, leading to endless debate and "binary thinking".
> [...] if something isn’t perfect then it must be terrible, or that if you don’t fully agree with something then you must therefore absolutely disagree with it.
Ask any IT professional who's had to patch zero days on internet-exposed systems whether they think changing the default port is useless, and practically all of them will tell you that it at least cuts down on logs, and means that you almost definitely won't get hit that first day with all the other people by script kiddies scanning the internet. Not posting your internal network diagrams, even though your security is 'open design', means that when someone sends the right email and breaches your perimeter, they still have to scan for what to go after. Additionally, this belief is almost exclusively held dogmatically by the private sector - classified government networks don't get hacked nearly as often as even your air-gapped corporate ones. Obscurity is never a replacement for 'true' security measures, and should only be added on after, but for a system you actually want to protect in the long term some amount of is often very useful.
It's a complacency problem. Changing the port of your SSH server to 900 may, in isolation be a fine thing to do, but when actually done in the real world it tends to be a substitute for keeping your SSH server up-to-date, or more realistically, even remembering you opened up the port to the world in the first place.
The concern isn't and hasn't been the IT professional patching zero-days, it's the IT professional who doesn't know what a zero-day is. Once you've worked with those people, after they've been referred to you by the FBI, you start to understand the harm Security Through Obscurity causes.
> Changing the port of your SSH server to 900 may, in isolation be a fine thing to do, but when actually done in the real world it tends to be a substitute for keeping your SSH server up-to-date, or more realistically, even remembering you opened up the port to the world in the first place.
It's interesting that you frame it this way, because I was thinking of this as the opposite: that the 'theory' being taught is not changing the port because security through obscurity is bad, and that the 'practical' solution is doing all of the things you mention it shouldn't be a substitute for, and only then adding obfuscation methods.
I think we're saying the same thing, that you can't substitute obfuscation for 'legitimate' security measures, but from different perspectives.
However, I read your comment to imply that the author lost credibility with their take on security through obscurity. This seems like the exact kind of harmful binary thinking the article addresses. The author presents a more nuanced take on a mantra, and for daring to do so, you dismiss them.
Obscurity can be useful when overlaid onto stronger security. It's why are military tanks camouflaged and not pink or hi-vis yellow.
Do you post all your internal documentation onto a public repo?
If not you are practicing some security by obscurity.