Security 101: Access Approval Documentation

Are all required approvals documented for each access request or modification to a user's or account's access privileges?

Summary

Essentially what this requirement is asking for is a record of every addition or modification to an individual (or group's) access to a system or data needs to be approved and that approval needs to be maintained for future review. Whenever an individual or group is granted access to a company's resource there should be a record of that action.

A couple of examples:

• A new employee starts and needs to be provided the access necessary to perform their jobs.
• A new project member needs to be added to a project specific system or data store.
• An existing employee changes job roles and needs a different set of access.
• A contractor is hired temporarily to work on a project and needs access to the project data.

In most cases this is simply a function of the individual's role.  A member of the accounting department, by virtue of being in the accounting department, is granted permission to the data/systems that the accounting department requires.  However this becomes more complicated in environments where there's a need to isolate individuals based upon the projects they are actually working on.  

This requirement makes the assumption that such an approval is required and this assumption is where some push back exists. What drives this requirement is the principle of "least privilige". Individuals should only have exactly the access they need to perform their jobs. Individuals should only have access to the tools their role requires and only to those projects that they're working on. Clients who request compliance at this level are concerned that data and systems relating to their business may fall into the wrong hands so they want to ensure that only people who are authorized to access their data can. The business will want to ensure that access to sensitive info cannot be accessed or modified (or destroyed) by a malicious employee. This requirement helps to achieve this by requiring that any access is approved by an authorized individual.

Where this starts to get tricky, especially with a smaller organization, is when there's a culture of everybody helps. The business may chafe at a PM not being able to step in and help out the developers because that PM doesn't have access to the source code (he's a PM - not a developer). And if he does want to step in he'll have to have management engage IT to provide that access. Why not simply give everyone access to everything and if not, why not just let folks determine the access they need at any given time? It's faster.  It's more efficient. It keeps the business moving.

But it also introduces risk if you can't be sure who has access to what.  If you don't know who has access to a thing and that they're supposed to then there's no recourse if the system is accessed inappropriately and it's harder to detect when a breach occurs.  Security requirements are absolutely about day to day operations but they're only there for that one panicky moment when something bad happens.

Policy

If you're crafting a security policy for your company and it requires compliance with a statement like we're talking about you might want to include the following:

Default Facilities​

By default, all users must be granted basic information systems services such as electronic mail and word processing facilities. These basic facilities will vary by job title and be determined jointly by <company> management and the Information Technology department. All other system capabilities must be provided through job profiles or by special request directed to the Owner of the involved information. The existence of certain access privileges does not, in and of itself, mean that an individual is authorized to use these privileges.

Access Approval Process​

A worker’s manager must initiate the access control approval process, and the privileges granted remain in effect until the worker’s job changes or the worker leaves <company>. If either of these two events occur, the manager must notify the Information Technology department immediately. All non-employees, contractors, consultants, temporaries, and outsourcing organizations must also go through a similar access control request and authorization process initiated by the project manager. The privileges of these non-employees must be immediately revoked by the Information Technology department when the project is complete, or when the non-employees stop working with <company>. The relevant project manager must review the need for the continuing privileges of non-employees every <however many> months.

Feel free to adjust the above to fit your needs.  Depending upon the size of your organization it may not even be necessary to segregate project work from the departmental roles unless a customer requests it.  The more sensitive the information you work with the more draconian this policy needs to be.

Note: I don't like the last sentence of the Default Facilities section. I think it's important to review access control and ensure that folks do not have access to things they shouldn't by default.

Controls

There's three parts to this:

1. The default permissions defined by being an employee along with the specific job role
2. Access to project type data
3. Exceptions

In a perfect world the first two should be easy.  If access to system resources is allotted using group permissions, as soon as the notification comes that an employee (new or existing) is transitioned to a new role or a project they are added to the appropriate group.  They'll be granted the defined permissions for as long as they are part of the group.

Changes to an individual's groups are handled by a single team, IT who receive a request (from management) to modify that individual's access.  Whether it's a new employee, a change in role, or a change in projects the notification to IT is captured and recorded and associated with both the group that's been modified as well as who has made the request. Once the request has been processed there will be a record of the request, from management, as well as the individual being given access to the necessary resources.  This control works perfectly well for default, role, and project based resources. The request comes in, it's associated with the appropriate groups and individuals.  It gets processed and all is well.

This control is most effective when the following pre-requisites are in place:

• Only a single team can make permission changes. In most cases this will be part of the IT team.
• The default resources for all employees are defined and can be allocated cleanly when a new employee is onboarded.  This includes things like email, access to shared folders, etc.
• The role based resource access is based upon discrete groups that an individual can be assigned to and receive the resources appropriate to the role.
• Project based resource access is based upon discrete groups that also take roles into account to apply access (i.e. a PM working on a project would have different access than a developer).
• Individuals are not assigned permissions to a resource.  They are assigned through group policies.

Exceptions

I'm not a huge fan of exceptions.  If, to use a previous example, a PM requires access to a project's source code to help out then it stands to reason that the PM will also likely require the tools and assets that a developer would have.  There's nothing wrong with an individual being assigned two roles.  But it means that they'll have access to everything a PM and a developer would have for the duration of their stint as a developer.  If they're crossing over to another project team then they'll likely require the PM access to that project as well.  If that's not the case then there's a need to talk about the base access control lists and why they can't support the necessary permissions.

An additional concern is this, and we'll talk about this in future posts: Segregation of duties. It's a security concept that boils down to every role having specific things they do and an individual in that role can do those things and no other. If you have a PM who can assist developers that's amazing. But even if that PM has the skills, should they? Segregation of duties is intended to prevent loss of revenue and data through malfeasance and error. If everyone in your organization knows what they're role is than you won't run into situations where a malicious actor asks them to do something that's not in their role and they actually do it. Example? "Hey! This is the boss. I'm trying to buy a gift for the employees. Do me a favor and grab $2000 in gift cards and send the numbers to me.  Don't tell anyone it is a secret". Yeah. Your developer will know that they don't purchase stuff for the company.  That's done by the supply chain folks. Then they delete the email and all is well.

The TL:DR version of exceptions is that there shouldn't be any. Multiple roles and or projects are totally okay and a person can be assigned to more than one as the needs of the business dictate.  There should still be a record of that fact and the individual should be given the full rights of the role/project when they're wearing multiple hats rather than piece parting the permissions.

Audit

When you get an audit request associated with this requirement, access approval documentation, it will probably be in addition to other requirements relating to access control. To fulfill the audit request you'll need to provide a list of all the access control changes and the approvals associated with them.

This is pretty straight forward if you're logging access changes in some sort of help desk software, which you should. It's also a breeze if you have access control packages based on role and project assignment.  Which you should.

To fulfill an audit request you'll just need to provide the following:

1. A document describing the various access control packages and the resources they provide access to
2. A list of individuals assigned to each documented access control package
3. A list of help desk tickets with the requestor (the authorized party) and the individual the change applied to when they were onboarded, changed roles, changed projects or a project was initiated, etc
4. A list of help desk tickets that reflect exceptions (which you won't need, right?)

Reference

• An awful lot of the base verbiage for the security policy examples I use come from the templates provided by SANS Technology Institute.  Not only are their templates available freely, they're a great place to start if you need to craft IT security policies.
• One of the things you're going to discover, as I did as I started writing these posts, is that the various requirements start to dovetail and build upon one another.  As more of these posts are generated, I'll come back to this section and link to other posts that relate to the topics at hand.  In this particular case it'll be those posts that deal with access control.

This post is part of a series where I dive into a security compliance requirement and detail what it means, how to meet the requirement and how to provide documentation in the case of an audit. You can read more about the series or read the rest of the series. I really hope this post is helpful to you.  Feel free to post in the comments if you have questions or additions.