The easiest tool (that you won’t use) that could save 10% of your budget
Checklists, how to use them to save time and money, and why you won’t bother to
Arrrgh where is Brent? He knows everything about the firewall/routing/machine build process/ICS/other IT thing, if we can’t find him how can we solve the IT emergency? If we don’t get this solved soon nobody is going to get paid and the business will fail!*
Want to avoid decision paralysis, ensure repeatability and consistency? Perhaps something as stupidly simple as a checklist can help. They can free us up from having to worry about the simple tasks, and let us concentrate on the difficult and new problem solving. I read (listened to) The Checklist Manifesto by Atul Gawande on a recent trip to Scotland, and had some thoughts on how we can use it for cyber/information security.
What is the Checklist Manifesto?
By using stories Gawande tells us how aviation, construction, finance, and medicine have used checklists as part of a process to significantly improve outcomes. How can we apply this to info/cyber security to improve our outcomes, making processes repeatable and consistent? The key themes from the book and my thoughts are:
1. Checklists are required for success.
Yes you can rely on your superstars, google searches, stackoverflow, “oooo this looks interesting” gut feel to work out what to do next, but this will not be repeatable or consistent in one area of cyber/infosecurity, let alone across the board. As we are seeing with lots of security tasks automation and playbooks significantly improve security outcomes – checklists are just the same, and are required for us to win either as blue, red or purple teams.
2. We cannot be specialists at everything.
Due to the complexity of the modern world people can only gain a deep understanding in one or two areas. (Read the Second Machine Age by Erik Brynjolfsson and Andrew MacAfee for a long discussion about this). Therefore, communication is key and checklists are part of this communication.
3. You cannot checklist out communication.
In fact communication should be integral to a checklist. The Agile methodology is a great example of this – the APMG Agile team leader is there to facilitate communication, not to tell people how to do their jobs. Therefore checklists should aid and facilitate communication, not hinder and isolate individuals.
4. There are 3 different kinds of problem in the world.
- Simple – easily knowable.
The problem can be summarised simply, and from an infosec perspective probably automated. E.g. build a PC to a standard to meet the policy.
- Complicated – not simple, but still knowable.
The problem cannot be summarised in one checklist / automation task. But probably can with a series of checklists. For example, the task might be to develop a new software feature, with checklists for development, testing and production phases.
- Complex – not fully knowable
The problem cannot be written down with exact steps end to end, as it changes each time. If you think of the problem as a tangled ball of string in this instance it is impossible to untangle it! An example might be “protect the infrastructure from cyber threats”. Here a single checklist, or series of checklists, cannot define all the details of what we must do. But it can provide a repeatable process to help us – see point 6 below.
5. Checklists take two different forms:
Do the action(s), then check afterwards that you got everything, or read the item off the list and do it immediately afterwards. DO-CONFIRM style is probably appropriate for most information security situations.
6. A good checklist is:
- 5-9 items
- 1 page
- Upper and lower case
- Tested in the real world
A key objection to checklists is something like “it takes away my skill as a human” or “it doesn’t allow me to think for myself”, but these objections are a symptom of a bad checklist rather than anything else. A good checklist will allow the human to not have to worry about what order they should do things in, or what steps to include. Rather it will allow the human to apply their ingenuity and skills to solving the complexity of a problem, without having to apply brain power to the simple. This is very similar to how automation is helping us today.
Why you won’t use them
Gawande points out that the biggest problem with checklists is in getting people to adopt them. He cites how surgeons will clamour for funding for a technological innovation that will reduce mortality by 20%, but refuse to implement a checklist that has been proven to have the same outcome. Gawande also cites similar examples from early aviation and finance. This is attributed to the checklist insulting the human intelligence “I don’t need to use a list to do my job, I’m an expert”, where a new tool compliments our abilities. The challenge for us as infosec / cyber professionals is the culture change to get people to use checklists, using our interpersonal skills to get people to see checklists as assets and aids, rather than red tape and bureaucracy.
So where to start with checklists for my organisation?
The good news is that NIST (and others) has already done a lot of work for us, providing checklists in a lot of their publications, such as the incident handling checklist from SP 800-61r2 below:
Yes this list looks like it breaks the rule of only 5-9 items, but it’s actually 3 lists combined, and is a great starting point. Note that it specifically doesn’t tell you how to do a stage, which wouldn’t work for this level of checklist, but merely checks each stage has been completed. The great thing is you can take this list, try it, and then adapt and change it to your organisation.
Finally, how do you know that your checklist is appropriate, tested, ready etc before a problem occurs or you use it for the first time in the wild. This is where a cyber exercise might come in, allowing you to safely test and modify the checklist. To learn how to use cyber exercises please book a free web consultation today: https://clearcutcyber.com/contact/
*This might sound familiar to anyone that has read “The Phoenix Project” https://itrevolution.com/book/the-phoenix-project/