Its not a standard until its written down
Mystery Colleague
Lets preface the phrase “Best Practise”. In IT best practise often depends on the environment and the organisations appetite for best practise rather than actual true best practise. In an ever growing industry the need for security continues to exponentially increase year on year.
Over the years I have tried to create a framework that can grow or shrink with the organisation’s needs and requirements. This helps maintain some semblance of security while balancing usability.
Another challenge I often find is that large scale infrastructure grows organically and rarely has a master road map. As needs and requirements arise adhoc changes are made. Worse still, when people try to implement least privilege it doesn’t work the first time and suddenly accounts that shouldn’t need it become administrators and domain admins.
Lastly when people try to implement a “best practise” project it fails due to the amount of risk it can carry, inertia that needs to be overcome and lack of priority. Everyone knows that security and best practise should be implemented and adhered to, just like we all know we should be checking and topping up the oil in our cars. The reality is we all put it off until the warning light comes on and sometimes that can be too late.
Setting Standards
A colleague once said to me “its not a standard until is written down”. The first thing is setup some standards, naming conventions, and processes. Even if this initially is a very loose framework it allows everyone to work towards the same goal. Make sure the document goes through whatever change process you have to get corporate endorsement and provide the standard some gravitas.
Lets focus initially on organising administrative users and roles within the IT department. This is the easiest starting point as it rarely involves outside engagement and helps build the foundation framework.
Naming Conventions
When it comes to creating administrative groups and administrative roles its good to keep the following principles in mind.
Avoid baking the company name, company location, equipment location into the name unless absolutely critical. Use the description fields to highlight the location. In my experience, company names and locations change more frequently that you would expect. This is particular the case in healthcare or accounting where organizations change names a lot.
I try to use descriptive and human readable names. Its always good to have the first operator in a group name outline the purpose. The means if your groups are all in one location they are ordered alphabetically and naturally grouped into similar purposes.
Avoid including words like Group/GPO/OU/Server in the names of things. I often see so many superfluous words in names that add no benefit. “Local Desktop Administrators Group” We know its a group, why not call the group “Local Desktop Administrators” or servers with the word server in it: “DNS-Server-01″
Whatever you decide why you create your standards documented, make sure to outline what phrases should not be used as well as what phrases should be used.
Administration Groups
These are groups of administrators who perform similar tasks. These groups only contain user accounts. These groups can later be assigned roles. One group might be all service desk staff, the other might be second line staff. Another might be the Infrastructure staff and the last network staff. Generally I create the following groups.
| Group Name | Description |
| Administrators – Service Desk | Administrator accounts for service desk |
| Administrators – ESC Support | Administrator accounts for escalation support |
| Administrators – Infrastructure | Administrator accounts for Infrastructure |
| Administrators – Networking | Administrator accounts for networking |
| Administrators – DBA | Administrator accounts for DBA |
Role Groups
These are roles that a given administrator might carry out on a day to day basis. These can be as granular or general as you require. You can create roles for various applications or work areas within the organization. These roles are granted permissions and then the administration groups are assigned to these roles.
I know that in the ideal world you would set super granular access on a user by user basis but the reality is that unless you have a large security team this just isn’t possible or practical to maintain. I find this process of matching groups of users to groups of roles the most pragmatic and manageable solution. Below are some example groups I might create.
| Group Name | Description |
| Role – Manage Servers | This groups is allowed to manage servers by default |
| Role – Manage Workstations | This group is allowed to manage workstations |
| Role – Manage MFA | This group can manage MFA in Azure |
| Role – Join Domain | This group can join devices to the domain |
| Role – Manage AD L1 | This group can manage AD at level 1 |
| Role – Manage AD L2 | This group can manage AD at level 2 |
| Role – Manage AD L3 | This group can manage AD at level 3 |
| Role – Manage Firewalls | This group can manage firewalls |
| Role – RO Firewall Access | This group has read only access to the FW. |
Pairing Roles to Administration Groups
Now its simply a case of creating a spreadsheet, listing the roles and the groups, then ticking who gets what access. This access list can start to form the basis of your security controls and documentation.
This also helps provide a simple and none technical explanation of who has what access.
Now we have created the roles, Administrators groups, paired them together and added users to each group we need to start implementing.
Follow along for Part 2.