Skip to main content

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

Separation of duty can put stress on smaller organizations. How do you handle the requirements?
Image
How do you handle separation of duties?
Image by Free-Photos from Pixabay

How do you handle separation of duty requirements?

26 votes tallied
We have a fully engaged governance team and process
2 votes
We have a written policy that's somewhat followed
7 votes
We have an abbreviated submitter, approver, and implementer process
4 votes
We are working on compliance
9 votes
We don't have any contracts requiring separation of duties
4 votes

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?

Author’s photo

Ken Hess

Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.