top of page
  • Phil Venables

The Crucial Test of Security Leadership: A-grades vs. Pass/Fail

A major success marker of great security leaders and their teams is one simple prioritization technique: the ability to know what needs to be done really well vs. what needs to be simply ok. In other words knowing when to go for an "A-grade" vs. when to simply "Pass", and making sure that the A-grade goals are dominated by what gives you the most leverage not just the things that are evidently critical. 


It has been over 4 years since I wrote the first version of this post. Since then, these lessons of prioritization seem ever more important. The need for this perspective is intensifying in a progressively more chaotic and demanding world where we face increasing shifts everywhere all at once, from technology to geo-politics. 


First, an aside. When I was an early-teen, in the days before the web and even before the wide proliferation of dial-up bulletin boards, a common way to share computer programs was through various printed magazines like Personal Computer World. These magazines would publish submitted programs and you would literally type in the program (usually Basic or Assembler) on your machine (typically a ZX Spectrum, Commodore VIC-20, Apple II, BBC Micro). The magazines would pay published contributors anything from $5 to $20 - which back then was a lot of money, especially for a school kid. Hence, the competition to get published was significant. Me, and a lot of people I knew, used to write and submit some pretty good programs, in fact some were extremely good. None were accepted. We were puzzled. Then, I figured it out (and it is obvious in hindsight) that because the magazines had to print this stuff and people had to type it in they didn’t want long programs no matter how good they were. They also didn’t want 5 line pieces of nothing. There was a sweet spot, it was about 50 - 250 lines of Basic. Which is enough to produce an ok program but not a great program. Once I’d figured this out I made a pretty good additional income for a few years publishing utilities, small games, and graphics demonstrators. Most people I knew ridiculed me for not submitting my absolute best, they continued to submit theirs and never got published. The rule for success in this "game" was producing something that fit the need, and the need wasn’t the absolute best. It was the optimal input for that particular situation. This lesson stuck with me.


Now, where am I going with this? Well, the same is true in life, but particularly so in security. We live in a world where there is an ever growing amount of things to protect and work to do, all while enabling new business. Even if you have infinite budget you won’t ever have infinite capacity to fill that budget with people, products or services and so you are always going to be resource constrained.


This is not unique to security. It’s in every field or role. You have a choice here:


  1. Try to do everything brilliantly (attempt to get an A-grade at everything) and then end up failing at that, but worse, failing in unpredictable ways. You may barely Pass (or outright Fail) at something you really did need to get an A-grade on.

  2. Realize your limitations and spread everything so you don’t fail at anything but you averagely pass across the board, leaving some things where you really did need an A-grade but not achieving that.

  3. Actually figure out what needs an A-grade vs. just a Pass (I’m assuming nothing is tolerable of failure for this example, but in some organizations there might be such instances).

Assuming option 3 is the goal then how do we differentiate between what needs an A-grade vs. just Pass/Fail? You could do the traditional criticality ordering - the protect the “Crown Jewels” kind of approach - but you can also, as we talked about in this post, focus on the new as well as the critical - and introduce some impetus / velocity to deprecate the old.


You can also find elements in your organization that always need an A-grade irrespective of their notional criticality because they give you massive leverage:


  • Platforms. Embed security in a small number of highly used opinionated platforms and make sure that is done extremely well. Examples include: identity and access management, cloud orchestration, API infrastructure, AI platforms, collaboration technologies, and developer tooling. Migrate as much as you can to those platforms in order of criticality and connectedness.

  • Process. Focus on getting better at a small number of core processes. Examples include: software development lifecycle, site reliability engineering, incident learning, risk transparency/governance and continuous control monitoring.


  • Culture. Amplify a small number of cultural factors that support the healthy treatment of security risk management. Examples include: psychological safety, 5Y's, and treating human error as something to be explained not an explanation in itself.


Bottom line: work hard to figure out what you need to get an A-grade on versus simply Passing - and don't try to get an A at everything. These might not just be your most critical assets, in fact you will likely be best served by getting A-grades on what will give you the most leverage like platforms, process and culture.


1,864 views0 comments

Recent Posts

See All

Going Faster: Isochrones and “Time to Hello World”

When you strip away all the fluff, security succeeds when: You are moving quicker than attackers - mitigating specific attacks ahead of, or just in time, through fast detection, containment and recove

Incentives for Security: Flipping the Script

We’re getting it wrong on the messaging for incentives to do security - and people are pretending it’s landing when it isn’t. There are 5 main categories of security incentives: Loss avoidance. The pr

Where the Wild Things Are: Second Order Risks of AI

Every major technological change is heralded with claims of significant, even apocalyptic, risks. These almost never turn out to be immediately correct. What often turns out to be riskier are the 2nd

Comments


Commenting has been turned off.
bottom of page