The concept of unlimited responsibility
The winning strategy in Security
I stumbled upon the book Conscious Business by Fred Kofman a few months ago, and it shook me to my core. Out of the many principles he explores to make a team succeed, one core tenet resonated with me. It’s the principle of unlimited responsibility, and I believe it’s the fundamental reason why the world of corporate security is such a debacle.
In a beautiful metaphor delivered at LinkedIn, Fred asks the audience1:
“There are 11 players in a soccer team. The offense scores goals. The defense blocks the other team from scoring. But what is the mission of the goalkeeper?”
Now, of course, one can sense a trap lurking in the shadows. What is the mission of the goalkeeper? To block the ball, of course!….
That’s when Fred pulls the rug under the audience:
“Alright, so following this logic, the goalkeeper would rather lose 0 to 1, than win 5 to 4. In the first game he blocked all goals. In the second, he let through 4. How is this team going to achieve excellence if each player is optimizing their own local objectives?”
They won’t…
“The mission of the goalkeeper is the same as that of the rest of the team…to win the game!”.
And that, in a nutshell, is the idea of unlimited responsibility. The objective of every player is subordinate to the ultimate goal of the team, and each of them should and must participate, however, they can to achieve that common goal.
That’s all nice and dandy, but what does it have to do with Security?
Too often in security, teams consider vulnerabilities other people’s problems.
“They set up that obsolete app with the generic admin account. My job is to point out security vulnerabilities and write recommendations. Their job is to fix them!”
I understand the sentiment, but just like we saw above, this creates a twisted incentive for the team. They keep digging out vulnerabilities, sending reports and creating Jira tickets, thinking that they did a wonderful job.
Three months later, of course, nothing gets patched because that other team has a different set of local goals, such as shipping new features. Everybody is busy ticking off their own little checkboxes while the company silently decays and drowns. Sounds familiar?
Now let’s take a different approach, inspired by Fred’s powerful insight.
One could argue, for instance, that the job of the security team is to help secure the business so that it can deliver value to its customers. This unpatched server endangers that goal; therefore, it’s the security team's responsibility to fix this threat. Their task does not stop at sending a 30-page report that no-ones reads. Their task ends when that particular server is not vulnerable anymore.
See how powerful this framing is? The security team is no longer a bystander that everyone ignores. They are committed to the business and the company. They have skin in the game. They must now develop a deeply understand what that server is doing, contact the team responsible for it, develop a working relation with that team, coordinate the effort to perform the upgrade together. If that team does not have the necessary bandwidth, then they must shoulder most of the work, extensively test that upgrade beforehand to not bring down production, schedule a QA session with the product owner and so on.
Who’s willing to bet that the risk presented by this server will be mitigated well before the 3-month mark?—Of course you’ll take that bet.
Such a team cannot afford the “fire and forget” attitude when it comes to the report, no, if they are to succeed in their job, the recommendations must be thorough and well documented. Vulnerabilities should be properly prioritized and triaged because the team is responsible for fixing them. And no one likes to waste their time on unexploitable bugs.
When you frame it like this, suddenly a whole new world of possibilities open to the security industry. An empowering world. A more exciting one.
There is no turf war, no us versus them, no ego boundaries. If I find a vulnerability in the code base, I’ll open a merge request to fix it—respecting the team’s coding and communication standards. If I see an insecure AWS resource, I’ll submit a change proposal to fix it after assessing its potential edge cases. If a feature is broken, yes I will point it out, but I will also consider it my duty to rework it with the product manager or find ways to alleviate its risk.
The principle of unlimited responsibility is such an empowering attitude that might just hold the secret to this broken entrenched industry.
I heavily paraphrased what he said in the video to adapt it to my conversationalist writing style