How do you handle NIST's separation of duty requirements?

Sysadmins, as you know, wear a lot of different hats--meaning that sysadmins do a lot of different jobs and typically have ultimate power in all of them. The all-powerful root user account and its highly-protected password are good examples of that ultimate power. For those of you who perform work that falls under certain regulations, like those of Department of Defense (DoD) project, you may have to comply with guidelines from the National Institute of Standards and Technology (NIST) 800-171, which includes the separation of duties (Control 3.1.4).

NIST 800-171 Control 3.1.4:

Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of organizational systems and system components when developing policy on separation of duties.

The question is, "How do you handle the separation of duties under this control?" In companies where I had to comply, we set up change management processes such that one person "applied" for a change, another approved the change (usually by quorum), and another person implemented the change. That's great for a larger company where you can have one person per group submit all the changes, which is what we had, but for smaller companies, this requirement can put stress on staff members. It can also put the responsibility on someone as an approver who has no idea what the impact or potential impact of certain changes can be. Sure, there's a checkbox for severity level but some approvers don't have enough "in the trenches" knowledge to ask the right questions or deny a change that hasn't been properly vetted in a test or development environment.

[ Want to test your sysadmin skills? Take a skills assessment today. ] 

How you document and handle the separation of duties can have serious repercussions on your continued involvement with government contracts. How do you handle it for your organization?