Controls are logical mechanisms applied in an effort to reduce risk.
This may feel vague because the term is primarily an abstract, logical entity that has specific implementations and humans like more concrete, implementable things.
Architecturally these entities sit at the logical layer but have concrete instances that are implemented by contextualizing the qualities of the control into the system you target.
Using the United States list of controls1, Appendix D, Table 2 – Security Controls Baselines, we find that if the system or data we are trying to secure has a rating of low risk for Separation of Duties (listed as AC-5), we don’t need to apply any controls. If, however, the system or the data has a risk of Moderate (Medium) or High then we must apply the same logical control, AC-5 but no others.
When we look this up in Appendix F-AC we find Supplemental Guidance that tells us what the intent of this control is:
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 … ensuring security personnel administering access control functions do not also administer audit functions.
This information is still logical and doesn’t tell us how to implement. That’s one of the qualities of a framework; it will tell you a lot of what you should be trying to accomplish but not how.
The gap between the logical and the physical should be filled by people who can traverse these mental gaps, typically architects or senior engineers or both.
In the system that we’re implementing we must first check the context to see if we’re dealing with a system that has low risk or moderate (medium) to high risk. If our system is only a low risk system (meaning the impact to our business from that system is negligible) then we don’t need to apply any control around this. If, however, the potential impact to our business that would result from a loss of Confidentiality, Integrity or Availability of the system we’re designing would have at least a Moderate impact then we need to apply this control somehow.
In our implementation recipe we might need the following ingredients (format is Name – Role):
- Directory Group 1 – Administer access controls rights
- Directory Group 2 – Audit the functions within the system we’re developing
- A Compulsory Process – This states that Directory Accounts (humans or programs) cannot simultaneously be members of Directory Groups 1 & 2
- Directory Group 3 – Audit the policy that states Directory Accounts (humans or programs) may not be members of Directory Groups 1 and 2, simultaneously
- Directory Group 4 – Directory accounts that are empowered to enforce the Compulsory Process
In our world, we’ll use Role Based Access Control (RBAC) and assign humans to a specific role within our directory of people. In a Microsoft Active Directory (AD) world we would create a group and assign rights to that group so that members of that group could give people access to our system that we’re building. We would then create another group and members of that group would have the authority within our system to audit what’s been done within the system. We wouldn’t be finished yet, though. To continue the implementation of this AC-5 control we would have to publish a compulsory process that stated that humans could not simultaneously be members of both groups. If we want to make a reasonable implementation of AC-5 within our system we would choose another existing group or make a new one and the responsibility of that group would be to audit our groups and ensure that the compulsory process was being followed. The authority to enforce the compulsory adherence to our process may or may not sit with that final group. Perhaps part of their auditing work on the groups would be to report any infractions to management who is already empowered to deal with humans not following company policies, standards, guidelines or position statements.
We separate Directory Group 3 and Directory Group 4 because typically in business humans with the tolerance for enforcement also have specialized roles such as management so this design allows for specialization within Group 3 and Group 4 so that neither group has too large a skillset requirement.
Now we’ve seen the logical definition for control AC-5, Separation of Duties, and followed it into an implementation so that we can see that the implementation may take a lot more to accomplish or, from another viewpoint, each control potentially contains within it a bunch of things (roles, processes and/or technologies).
Within your business, the directory groups may be big or small; they may have broader skillsets. Directory Group 4 may be mid-level managers at your business or they could be one or two VPs in a smaller business. If you have a large enough infrastructure and enough automation the enforcement of the process may even be automated. This is an example of how security must be contextualized and applied to something in the real world before we can truly know the impacts of risk management to our businesses.
Apologies – I’ve not yet posted What Is Governance? but as that post leans on Controls and implementations I wanted to get this out first.
1 – National Institute of Standards and Technology (NIST) Special Publication 800-53 Rev 4 (SP 800-53r4)
Security and Privacy Controls for Federal Information Systems and Organizations
The current version as of the time of this post