If you took English literature classes in high school or college, you were probably exposed to John Donne’s famous poem “For Whom the Bell Tolls.” Besides the often-misquoted title (it’s “send not for whom…”, not “ask not…”), this poem also gave us the phrase “no man is an island,” and it was the inspiration for pretty much my favorite Metallica song ever (and if you’re in the mood, try this song too for a chaser). As much as I might wish otherwise, though, I’m not here to write about Metallica or English literature; instead, I want to talk about something that security practitioners sometimes call the “Big Red Truck” attack. As in, what would you do if your most important administrator was hit by a big red truck and wasn’t able to come to work tomorrow morning? If you prefer a happier question, you could instead say “What would happen if my most important administrator won the PowerBall lottery and didn’t come to work tomorrow?” but the effect is the same… and, of course, it is the same question whether that most-important-admin is you or someone else. 

In considering this overarching question, there are (at least) four smaller questions you should be thinking about and documenting the answers. Former Secretary of State, and noted Marine, James “Chaos” Mattis was known for asking his subordinates to answer three questions: 

  1. What do I know? 
  1. Who else needs to know? 
  1. Did I tell them? 

With those as a starting point, let’s dive into some questions you might consider asking in your environment to protect your business. Remember, the intent here is to protect your overall operations against the loss of critical knowledge or skills due to the unavailability of key people. 

What Do You Know? 

Of course, not everyone knows everything about any given environment. Every administrator and developer will have her own little bag of tricks, strengths, and particular knowledge about a system or network. Assessing what people know starts with Chaos’ first question: What do you know? Put in another way, what unique knowledge do you have that no one else on your team does? The most obvious targets for this question are things like passwords: If you have an AWS or Azure instance, who has the root or global admin password for that account besides you? If you’re using a password manager, who has access to it? If there are BIOS or BitLocker passwords on critical servers, who knows those? You get the idea. 

If you’re a team of one, this question still applies, by the way. Unless you run a one-person business and don’t care about what happens to your customer data, tax records, and so on, you need to designate another person to take up the slack in your absence. 

The Microsoft 365 Kill Chain and Attack Path Management

An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!

Who Else Needs to Know It? 

Mattis’ original question “Who else needs to know?” is all about knowledge transfer. In many organizations, the basics of knowledge transfer are handled by simply writing stuff down somewhere. (That of course raises the question “who can get to the stuff that’s written down?” but that’s a topic for another day). I want to encourage you to go beyond this limit and consider who else needs to know how. For any critical member of your admin team, consider what unique skills they have and decide who else needs to have them. In the on-prem world, it was common to have multiple administrators who knew how to do Exchange disaster recovery, for instance. In our cloud world, that’s probably not one of the skills you need to prioritize, but I’m sure you can think of some that are pertinent to your environment. Ironically, the more you use infrastructure-as-code solutions like Bicep or Terraform, the more you’re probably concentrating critical skills into a very small number of brains. Automation that replaces skills seems great… right up until the automation itself stops working properly. 

Did I Tell Them? 

Writing documentation isn’t much fun (says the guy who’s written a bunch of computer books!) Most working admins don’t want to do it. It also requires a particular mindset and skillset. The good news is that written documents aren’t the only way to ensure that important knowledge is preserved. For example, if you wanted to preserve the knowledge of how to configure a particular system, you could easily do a screen capture recording using ClipChamp and then stick it in a Microsoft 365 Stream library. For broader or more abstract topics (“Why did we design our network this way?”) a great alternative is to get a roomful of people and feed them pizza while you explain it to them. There are many other ways to transfer tribal knowledge of this type, and you can undoubtedly find one that fits both your organizational culture and the personality of the people whose knowledge you want to spread. 

Gloomy But Necessary 

BRT attacks are unpleasant to think about. Unfortunately, though, they are a real threat to most organizations; unlike some of the other threats I write about here, though, this particular threat is much easier to mitigate. If you don’t think you have any skills worth preserving or knowledge worth transferring, think about the effect on your own work if that one really smart coworker hit the jackpot and didn’t come into work, and then encourage them to share what they know using Mattis’ framework. You, your coworkers, and your organization will all be better off for it. 

About the Author

Paul Robichaux

Paul Robichaux, an Office Apps and Services MVP since 2002, works as the senior director of product management at Keepit, spending his time helping to make awesome data protection solutions for the multi-cloud world we’re all living in. Paul's unique background includes stints writing Space Shuttle payload software in FORTRAN, developing cryptographic software for the US National Security Agency, helping giant companies deploy Office 365 to their worldwide users, and writing about and presenting on Microsoft’s software and server products. Paul’s an avid (but slow) triathlete, an instrument-rated private pilot, and an occasional blogger (at http://www.paulrobichaux.com) and Tweeter (@paulrobichaux).

Leave a Reply