> I'm sorry to be sounding so harsh, but I sincerely detest the security-by-checklist approach.
Checklists are essential (or becoming so) in all professions that require a level of safety or assurance in their operations. They don't replace careful though and action, but they do supplement it be making sure there's a minimum level of items that were checked and not omitted because someone thought they didn't apply when then did, or someone just plain forgot. A checklist is a good way to start some rational thinking about what's required for your specific case (especially if it's so restrictive that you have to (and are expected to) selectively alter portions of the checklist just so your current use case functions.
Checklists are well known and save lives in some professions (such as aviation), and are being applied to others even when there's push-back (Surgeons and emergency room operations[1]) because the benefits are just so large.
I think it's fair to dislike how people and organizations adopt a checklist in lieu of careful thought about security, and to dislike poorly defined and reasoned checklists themselves, but I for one would be much happier, and feel much safer, if security checklists were much more common overall.
Checklists are fine if you have a fixed problem space. Just to go by your example - aviation safety is a mostly fixed problem space you can make mitigations in. Any item on the checklist would be there to mitigate safety issues almost any aircraft would encounter (and I'd imagine there are specific checklists for e.g. passenger vs. cargo aviation).
"Linux security" is not a fixed problem space. Not at all. And that's precisely my problem with this - this checklist pretends that it's a fixed problem space, and therefore grossly misrepresents the problem.
My point is that most problem spaces can be split into fixed and non fixed portions. Aviation safety has plenty of problems that require a real person to make a call and react intelligently, which is why we still have pilots. Checklists are used to cut down on the entirely avoidable problems that might be missed some percentage of the time otherwise.
There are plenty of things in Linux security that are static solutions that can be employed almost all the time, such as not allowing direct access to root accounts, always running a local firewall, making sure remote services aren't run as root without dropping privileges, etc.
Checklists are essential (or becoming so) in all professions that require a level of safety or assurance in their operations. They don't replace careful though and action, but they do supplement it be making sure there's a minimum level of items that were checked and not omitted because someone thought they didn't apply when then did, or someone just plain forgot. A checklist is a good way to start some rational thinking about what's required for your specific case (especially if it's so restrictive that you have to (and are expected to) selectively alter portions of the checklist just so your current use case functions.
Checklists are well known and save lives in some professions (such as aviation), and are being applied to others even when there's push-back (Surgeons and emergency room operations[1]) because the benefits are just so large.
I think it's fair to dislike how people and organizations adopt a checklist in lieu of careful thought about security, and to dislike poorly defined and reasoned checklists themselves, but I for one would be much happier, and feel much safer, if security checklists were much more common overall.
1: https://www.who.int/bulletin/volumes/86/7/08-010708/en/