Checklists solve the problem of forgetting specific details. They work very well in situations where all possible problems have been enumerated and the only failure mode is forgetting to check for one.

They do not solve the problem of getting people to think things through and recognize novel issues.

There are some jobs you can't do well. You can do them adequately or screw them up. Checklists are helpful in those jobs.

Checklists work well in high stress situations where you cannot forget a step (medicine, aviation).

A checklist in a security incident? Probably helpful.

A security checklist to satisfy auditors and ancient regulations? This is an entirely different kind.

Yea, the problem most often in computer security checklists is misapplication of the checklist.

I do cyber security related stuff for the finance and they have some of the dumbest checklists ever.

A more recent one I got was

"We only allow the HTTP verbs 'GET' and 'POST', your application can only use that and the verbs PUT, PATCH, and DELETE cannot be used.

After not replying 'are you fucking stupid' I said

"You do realize that you are using a RestAPI application and that these verbs can go to the same interface to modify the call in different way? Not only would we have to rewrite our application which would probably take months to years, you would have to rewrite tons of applications on your side to make this actually work."

You get these dipshit auditors from other firms that pick up some 'best practice' from 2003 and put it in a list then get a god complex about it needing to be implemented when they have absolutely zero clue why the original thing was called out in the first place.

For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application.

> For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application.

Thanks. One thing that's more interesting than the revealed stupidity of such rules is the actual (and often sensible) reason they were first created long ago.

"Temporary" hacks outliving both the problem they solved and the system they were built for seems to be a regular occurrence in bureaucracy as much as it is in software and hardware.

Most of this comes about because the talent pool for cyber is so small. Cyber Auditors, should understand what the risk is, and what controls should be in place, and how they operate.

Most don't because they lack the appropriate technical skills. Therefore we fall back on checklists, as less skilled people can do a compliance check to it.

In large organisations this can also happen between cyber and engineering teams, where the teams don't understand security and are just focussed on releasing features, and so cyber enforces checklists or non-negotiables or compliance assessments.

All of this comes down to skills and awareness. Not enough people have the skills/knowledge to cover all the roles out there.

Don't think the talent pool is small. It's the budget. InfoSec is seen as a huge money sink in the eyes of many unfortunately.

Checklists are a good tool for making sure you don't forget something. They're a terrible replacement for actually thinking.