Why so many companies suck at security
It all comes down to two points
It is common in our industry to hear aphorisms such as “security is a failure”. Even pentesters, that enjoy breaking stuff, can’t help feeling disheartened when they inevitably have the sour pleasure of auditing an infrastructure more than once. Companies with fully staffed security teams under the guidance of a prominent CISO have trouble to get things moving: applications don’t get patched, servers don’t get hardened and the business remains hopelessly, irretrievably vulnerable to the same attacks year in year out.
Why is that?
Each company may fail in security for a plethora of different reasons, but I would like to highlight two causes that, in my opinion, are responsible for much of this security inertia within companies. Many seemingly complex symptoms can be traced back to two fundamental points:
Inadequate threat modelling
Misaligned incentives
Inadequate threat modelling
Every meaningful discussion about security should start with two questions:
Who are we fighting against?
What are we protecting?
These two questions are so paramount that it’s ludicrous and unproductive to talk about this attack or that security measure if the company is not absolutely crystal clear about the answer to these two questions. They define the attacker’s profile, their resources, their incentives, their determination to pursue these incentives, the company’s important assets, entry points and so on.
To paraphrase Leonardo da Vinci, Security is never finished, only abandoned. Nothing is truly secure in the absolute sense. It is secure against certain attack hypothesis. If these hypotheses are not clear to everyone in the team, then each member ends up visualizing different attack profiles according to their own sensibilities. They might spend far too much energy securing an asset against phantom threats, or err on the other side, that is, insufficiently barricade an important asset against low-level attacks.
A highly trained expert might spend 1 months hardening that one SELinux instance against the most advanced attacks, while a developer will deploy an unauthenticated app thinking it’s fully protected behind the corporate VPN.
Both cases likely betray a lack of sensible threat modelling tailored to the company’s need. Is spending 1 month on an SELinux project covering one machine the most beneficial use of that person’s time given the current threat landscape of the company? Maybe they’re better off spending 3 days protecting all machines against a regular ransomware, then move on to that Web app that can be exploited by any bot scanner. Perhaps that developer is not aware of the ease with which attackers breach that so-called internal network, or they still think that an app is sufficiently protected because the JSON payload is “quite complex to guess”…
Aligning everyone on the threats a company faces, and agreeing on the attacker’s capabilities and motives, helps adjust the effort and investment needed to secure each asset, before moving on to the next urgent cavity.
Everyone agrees on the common security practices. They are hardly a secret. Yes, you should have a SIEM, network segmentation, patching, a WAF and so on… But the untold secret that makes or breaks a company is the order in which these solutions should be pursued. This order is defined by the threat modelling exercise!
Instead, companies sequentially go through their Christmas list of vendors and tools and completely forget to constantly reassess the cost/benefit ratio…. A WAF can be a powerful tool, but if you mobilize your entire team for 2 years on it to reach 100% coverage, while workstations and systems are sitting ducks on the network… Well, too bad, the first malicious attachment will floor your company, and attackers will pwn the network 7 days until Sunday. Your team is hard-working…they’re just not working on the topics that matter most.
Whenever I used to mention that I was head of a security department, the first question I got in response was “how big is your budget?”. The concern underlying the question is quite telling. Stories abound of security officers that have trouble securing a budget for their projects. The executive team is often blamed for such harsh cuts. “They don’t care about security” is too easy an excuse. No. Odds are, they are not aligned with the threat model of their security team. Maybe they doubt that their business can be targeted by vicious attackers, or don’t understand the impact of a data leak, or they simply don’t agree on the cost/risk ratio presented to them. You’re asking for $200K to protect an asset perceived to be worth much less or to counter a not-very-convincing threat. The same argument holds true for companies who do not even have a security team. The conversation may be bear the dollar sign, but make no mistake, it’s a threat modelling issue. i.e. they have different answers to the two questions: who are fighting against and what are we protecting!
Your job is no longer to negotiate budgets, but to align everyone on the same threat model. It’s the only way to get the support of not only the executive team, but everyone in the company.
In short, by clearly defining the threat model of the company, we get:
Teams that address the most urgent and exploited vulnerabilities
Teams that are constantly focused on the right topics and invest just the correct amount of time and energy
Alignment and support from the company (easier to get budgets, resources, etc.)
Misaligned incentives
Many security teams within companies heavily borrow the operating system of consulting firms, perhaps a vestige of the hacking culture that sprouted the infosec industry. These teams find vulnerabilities, write recommendations, share the report with the audited department before moving on to the next system.
Here is a question. What value did this team truly bring to the business?
A big fat zero.
I know I will bruise many an ego with this take, but bear with me.
Such teams are incentivized to find vulnerabilities, control processes and procedures, and check recommendations… Everything but the most important action of all: Fixing the damn vulnerabilities! Isn’t that the end goal of our industry? Protecting the business and helping it thrive? Pointing to broken stuff yields nothing if we don’t/can’t pick up the wrench to tighten the screw!
Instead, security teams find vulnerabilities, send a 30 line spreadsheet to the dev or infrastructure team and schedule a check in 2 months… But the dev team is busy delivering business critical features. Their incentive is to ship these features. See the problem? Nobody is incentivized to fix vulnerabilities. Not the security team, not the developers…no one.
Even if by some luck a developer decides to pick up that report and start working on the first vulnerability, they’ll notice that the recommendations are awfully short, miss half of the edge cases and carry a huge business risk for little benefit. Again, the security team is incentivized to find vulnerabilities, not to implement fixes… So, any small deviation with standard practices will warrant a recommendation. They don’t have time to dig into the complex business logic, study the side effect of this or that action. They need to go after the next vulnerability on the next system.
The incentive issue is probably the number one problem in cybersecurity and is the most prominent reason behind the slow inertia in many companies. CISO’s are encouraged to perform audits, the ISO 27001 is a list of controls, companies build blue teams that create Jira tickets for developers to fix vulnerabilities in a game of absurd responsibility dodging.
Every time I see a report of a CISO complaining about unpatched machines or the absence of 2FA, I have the same knee-jerk reaction: “well, why don’t you just do it already?”. If the answer is in the realm of: “I cannot”, “It’s not my scope” or “I don’t have that power”… then that’s the real issue that needs to be solved first. Someone must be directly incentivized to fix vulnerabilities.
Consider for a moment a company that restructures its incentive model. Imagine a setting where the security team is not only capable of fixing vulnerabilities, but mandated by the executive team! A sort of task force that can commit code in any repo, change infrastructure components, collaborate with devs to update libraries, understand and study the business impact of every change.
Sure, sometimes they will break stuff or cause an outage, but if they take it as a learning opportunity and build intimate knowledge of the business. Oh, sweet heaven… They will be an unstoppable wave of change that will sweep through the entire company. Combine that with good threat modelling, and you’ll have a powerful team capable of driving change on the most important topics.
Now, that’s how you crack security.