There are best-practices you just pick up after a while, but who sets them? Ahm, I don't know. And that is part of the problem. There are area-specific best-practices makers, such as the SANS institute for IT Security issues and Microsoft TechNet for Microsoft, but there isn't anything out there for overall best-practices setting.
Over the years I've been asked to identify best-practices and evaluate how close we are to meeting them. Coming up with that list involves a lot of web-searching, learning where the standard-makers are, and not a little of distilling of best-practice out of mailing-list posts.
Do we need a single repository for sysadmin best-practice?
As I mention in a previous post System Administration has a very broad definition, and varies dramatically from organization to organization. What's more, the industry is fractured on vendor lines, as what works for Cisco may not be entirely valid on Juniper, and the same goes for Linux/Windows, AIX/Solaris, Oracle/Postgresql, Government/Private-Industry, EMC/NetApp, SAP/PeopleSoft, and many, many more.
One best-practice that has broad recognition is the idea that Administrative users like me should have two accounts; one for regular work, and another for admin tasks. I should not be running Outlook and hitting refresh on cnn.com while logged in as Domain Admin, that should be in as a normal user. And yet even this has differences between Linux and Windows.
On Linux, sudo is a great way to do one-time tasks as root and if you need to you can create a specific terminal window that's in as root. On Windows, UAC means you're running as normal-user for most of your tasks but can promote certain tasks to admin rights by opening them the right way or opening certain tools at all. And yet... on Windows, even with UAC a domain-admin logged in to a workstation will still be able to change NTFS rights everywhere, as icacls isn't subject to UAC. Windows does have 'run as' functionality now, which allows sudo-like workflow, but it isn't as easy to work with as sudo is.
Is Microsoft's attempt at account separation good enough, or does an admin need the ability to have two discrete login sessions going at the same time? Pre-UAC, this is exactly what Microsoft was recommending.
In my past best-practices work I know that many managers would prefer their best-practices be accompanied with step-by-step guides for following the best-practice so they can be certain they're doing it right. Best-practice-by-rote. So finding a document that describes privilege separation for admin users in generic terms isn't as useful as the one that comes with a step-by-step guide.
Providing best-practice guides for the breadth of Systems Administration is fantastically hard.
Creating a list of general principles is relatively easy. An engaged sysadmin group such as LOPSA or SAGE could generate such a list given a few months and a lot of word-smithing.
Creating platform-specific best-practices guides to go with the statements of general principle will take an orders of magnitude more effort. It means identifying enough subject-matter experts to create guides for everything, which greatly increases the number of people that need to be involved. Worse, the step-by-step guides become stale far faster than the general statements do, so regular maintenance will need to be done.
Because of this difficulty we have the status-quo. Best-practices guides are found in area-specific domains, even the ones that cover a lot of the system-administration space. LOPSA is heavy in Linux/Unix admins and light in Windows, so may not do as good a job generating guides for the Windows platform as they would be for Linux. The MSRC would be great at putting out guides for Windows, but useless for anything else. SANS is a great source of general guides for security-topics, and even has some step-by-steps, but does not cover things like backup rotations.
By my read of it outside of Security we have very few non-vendor organizations publishing best-practices guides for system administration topics. The few that are tend to be concentrated in one domain, *nix administration. Creating any kind of broadly-applicable best-practices documents will require participation across the entire breadth of the System Administration space, and no organization even approaches that yet. LOPSA has hopes in that direction, but before they can really attack the problem they need to attract a broader membership. That takes time. Until then, things stay fractured.
Over the years I've been asked to identify best-practices and evaluate how close we are to meeting them. Coming up with that list involves a lot of web-searching, learning where the standard-makers are, and not a little of distilling of best-practice out of mailing-list posts.
Do we need a single repository for sysadmin best-practice?
As I mention in a previous post System Administration has a very broad definition, and varies dramatically from organization to organization. What's more, the industry is fractured on vendor lines, as what works for Cisco may not be entirely valid on Juniper, and the same goes for Linux/Windows, AIX/Solaris, Oracle/Postgresql, Government/Private-Industry, EMC/NetApp, SAP/PeopleSoft, and many, many more.
One best-practice that has broad recognition is the idea that Administrative users like me should have two accounts; one for regular work, and another for admin tasks. I should not be running Outlook and hitting refresh on cnn.com while logged in as Domain Admin, that should be in as a normal user. And yet even this has differences between Linux and Windows.
On Linux, sudo is a great way to do one-time tasks as root and if you need to you can create a specific terminal window that's in as root. On Windows, UAC means you're running as normal-user for most of your tasks but can promote certain tasks to admin rights by opening them the right way or opening certain tools at all. And yet... on Windows, even with UAC a domain-admin logged in to a workstation will still be able to change NTFS rights everywhere, as icacls isn't subject to UAC. Windows does have 'run as' functionality now, which allows sudo-like workflow, but it isn't as easy to work with as sudo is.
Is Microsoft's attempt at account separation good enough, or does an admin need the ability to have two discrete login sessions going at the same time? Pre-UAC, this is exactly what Microsoft was recommending.
In my past best-practices work I know that many managers would prefer their best-practices be accompanied with step-by-step guides for following the best-practice so they can be certain they're doing it right. Best-practice-by-rote. So finding a document that describes privilege separation for admin users in generic terms isn't as useful as the one that comes with a step-by-step guide.
Providing best-practice guides for the breadth of Systems Administration is fantastically hard.
Creating a list of general principles is relatively easy. An engaged sysadmin group such as LOPSA or SAGE could generate such a list given a few months and a lot of word-smithing.
Creating platform-specific best-practices guides to go with the statements of general principle will take an orders of magnitude more effort. It means identifying enough subject-matter experts to create guides for everything, which greatly increases the number of people that need to be involved. Worse, the step-by-step guides become stale far faster than the general statements do, so regular maintenance will need to be done.
Because of this difficulty we have the status-quo. Best-practices guides are found in area-specific domains, even the ones that cover a lot of the system-administration space. LOPSA is heavy in Linux/Unix admins and light in Windows, so may not do as good a job generating guides for the Windows platform as they would be for Linux. The MSRC would be great at putting out guides for Windows, but useless for anything else. SANS is a great source of general guides for security-topics, and even has some step-by-steps, but does not cover things like backup rotations.
By my read of it outside of Security we have very few non-vendor organizations publishing best-practices guides for system administration topics. The few that are tend to be concentrated in one domain, *nix administration. Creating any kind of broadly-applicable best-practices documents will require participation across the entire breadth of the System Administration space, and no organization even approaches that yet. LOPSA has hopes in that direction, but before they can really attack the problem they need to attract a broader membership. That takes time. Until then, things stay fractured.
If I read your post right, I think this begs the question, would you want an overarching sysadmin best practices document that covers every OS or environment?
I used to be a UNIX admin then went over to the Windows area. To call what happens with Windows administration different is to cheapen the word. It's worlds apart, but the one thing I believe it does have is an easy adaptability to defining sysadmin best practices because of how intensely graphical and wizard-driven most things are and also because of how inflexible the OS happens to be. There are many ways to manage a UNIX environment, almost as many as there are admins! Which is why, considering this, that there even exists UNIX best practices.
Interesting blog, keep it up!