ITIL and the DoD RMF - Part 3 of 3 – Practical Example
Part 1 of this series was an overview of the Department of Defense (DoD) Risk Management Framework (RMF). In Part 2, we looked at how process consultants may find within the RMF opportunities to positively influence the security practices of their clients. In this final entry in the series, I provide an example from my work of a client that was falling short of the requirements for a specific control, and how I approached the matter.
The control in question was AC-6, least privilege. The basic premise behind this control is that accounts, especially privileged accounts, are assigned permissions/rights on systems sufficient to accomplish their duties and no more. Frequently accounts receive these permissions/rights through membership in groups which in turn have been assigned the appropriate level of access to systems.
When I met with the client initially, they described to me a situation with privileged groups (and thus accounts) that was unmanageable. Hundreds and hundreds of privileged groups existed, and the organization had no way of knowing which ones were actively being used nor what levels of permissions had been assigned to the groups on which systems. Admins that had moved within the organization often retained the membership in groups from their previous role as well as receiving new privileges from their new role, resulting in cumulative privileged access of an undetermined nature. The result was great uncertainty among risk managers – a feeling of unease – and, likely, a state of system security that was somewhat less than desirable.
The initial ask of this client was to find out which of the groups were needed and which were not. But even this would not address the issue of control AC-6, for there was no documentation to confirm that the groups in question possessed only the rights they needed and no more. A cursory examination of database instances showed excessive system privileges for database admins, and it was easy to believe that this sort of thing may be found elsewhere.
If the task were only to take measure of which groups were needed, it would be a relatively simple (though time consuming) task to interview every technical team in the organization to determine what groups they used to grant access to the systems they managed, then compare the list of groups generated to the list in directory services, delete the delta, and see who screamed.
I pitched and received permission to do something ambitious – to provide a more permanent solution. The task was great, and involved an enormous number of interviews and information gathering, review of findings, the definition of privileged roles for every team in the IT structure, implementation of new privileged groups to be assigned to those roles, a new privileged group management process (along with the corresponding forms and approval flows), and a tool to enforce policy and process discipline. This represented a significant effort but would result in a complete reversal of the situation – total faith that there existed only the privileged groups that should exist, that those groups were assigned only the access they needed and no more, and that admins would no longer accumulate permissions over time.
I began the project armed with only one thing – an org chart. Email addresses and phone numbers for the folks listed on the org chart were tracked down and I began making appointments to interview team leads and their lead technicians. The goal of the initial interviews was to talk about what should be as opposed to what is. I asked first about the mission/responsibilities of the team. Then we turned to what systems the team members needed access to fulfill their responsibilities. Next the question of what tasks were performed on those systems was answered, and finally what rights/permissions were needed to accomplish those tasks. To wrap things up, we talked about whether there existed within the team different roles – different levels of access. Do new employees receive the same level of access as more senior team members? This line of questioning helped clarify the existence of different roles within the team. We named those roles, then took the data regarding systems and levels of access and identified which roles had what.
The result of these interviews was a document that defined the team name and mission, the roles that existed within that team, the systems the team required access to, what tasks they needed to perform on the system, and what level of access was required to perform those tasks, organized by role. This document was reviewed by the team lead in question (and their technical representative) as well as more senior security managers. Once accepted, it was given to the directory services team to be used for the creation of privileged groups with rights/permissions tailored to the need.
Privileged accounts were added to these groups and removed from all legacy groups. Functionality was tested. Once everything was settled, the legacy groups became obsolete. Upon completion of the project in total, all legacy privileged groups could be deleted.
This left only the ongoing management of these groups – the need to ensure that admins who moved from team to team did not accumulate permissions. This effort seamlessly merged with another project for just-in-time-administration. A technical solution would enforce the policies and ensure process discipline.
A solution founded on Microsoft Identity Manager (MIM) was engineered. Admins who needed to perform privileged actions would access a portal and check out a privileged role. The act of checking out the role added their account to the appropriate privileged group for a certain amount of time, at the end of which their privileges would be removed. Rules were put in place to ensure that the privileged users could not check out roles for which they were not approved. A mandatory field in the act of checking out a role was ticket number. This created traceability and helped ensure that privileged access was being used for a valid business reason.
There were a few workflows needed – request/review/approve a privileged account, review/edit privileged group, request/review/approve permission to check out a privileged role, so forth.
In the end it was a great success, and the client’s faith in the management of privileged access was dramatically improved. The requirements of the control were met, and so much more! The project required planning, communication, diplomacy, a bit of technical knowledge, and faith that the organization could achieve the way things “should be” – all required skills of a process consultant. Back to Part 2