Identity Access Management for ISO27001

If you have been following along with our blog posts on building up our security framework then by now you will have thoroughly vetted your staff prior to them joining and have HR controls in place we now move on to consider their user account and access management. Having a good User Access Management is vital, not just for ISO 27001 but also other security standards such as PCI-DSS and GDPR.

There are 6 controls in all, from the initial account creation right down to preventing privilege creep by auditing user privileges.

Security category – 9.2. User access management

9.2.1. User registration and de-registration.

This control details how our organization onboards new employees and disables the accounts of former employees. The process should be formally documented and procedures in place for the registration and deregistration of accounts. This includes provisioning unique user ID’s for the employee. The registration process should be carried out for any information service that the user needs access to and should include regular audits to ensure user accounts are disabled when a staff member leaves their role. This control is primarily about authentication.

9.2.2. User access provisioning.

While the previous control described the authentication process staff should go through to log into an account to access a server, the level of access the user requires is described here. During the user provisioning process, specific rights and permissions will need to be granted to the employee and these rights should be recorded in a central repository which makes auditing and reviewing them easier. It can reasonably be expected that an employee may change roles one or more times during their time with your organization. During these role changes the level of access and rights the user requires can fluctuate and regular reviews can counter privilege creep; where long serving staff retain access to systems they no longer have a business need to access. With correct access management we can reduce risks and if we specify sanctions for any unauthorized access attempts a staff member might make we will improve our security posture.

9.2.3. Management of privileged access rights.

Privileged access should be strictly controlled as it allows the employee to circumvent security controls. A good example of this is not allowing staff to use root or admin accounts to perform their daily duties, and only using those privileged accounts when there is a specific need. The privileged access usage should be clearly documented including which users can access privileged rights and for which services. Requiring users to authenticate with their unique ID allows us the ability to audit the use of these accounts and to check and protect against abuse of privileged access. The access such be reserved and only used if there is an absolute need. There should also be a documented procedure outlining the authorization process required to gain access to this privilege level.

9.2.4. Management of secret authentication information of users.

One of the biggest risks that is often ignored at companies is how a user’s credentials are provided to them, and managed. An example of poor practice is if a company’s IT department simply emails passwords to users in clear text and with no requirement in place for the user to change their password or keep it secret. Proper password management should ensure credentials are sent to users over a secure medium in a co-ordinated and documented way, with steps taken to ensure that the user changes their password once received and acknowledges receiving it. The user should have to agree to a password policy that describes not only password requirements such as complexity but password management best practises such as not sharing it, or keeping it written on a post-it under your desk.

9.2.5. Review of user’s access rights.

Users roles change over time. What access a user requires now, may not be what they require in 6 months’ time. In many companies long serving employees can move between roles throughout their time with the organization. Having regular audits or reviews of user access rights can ensure that rights a user has retained from a previous role can be removed when no longer needed.

9.2.6. Removal of users of access rights.

When an employee leaves the organization or their contract changes often the level of access the require for different services changes. In this case un-needed access should be removed then and there to prevent permission creep. This also extends to informing relevant staff of the role change to avoid un-intentional disclosure of information.

Defining your Access Control in line with business requirements

Ensuring access to your business assets are controls improves their protection and this can be tailored in accordance to your business needs. Segmenting your network and having different controls for different segments that are guided by organization wide policies can have a great impact in reducing threat vectors and protecting your company.

9.1.1. Access control policy.

Access to assets is a key concern for any organization. Access should always be based on the businesses needs and tailored to the specific employee and asset type. Employees need just the right amount of access to perform at their job. Too little access and key functions in an organization may be left unfulfilled. Too much access and the organization may suffer a data breach, tampering of services and outages, either by accident or by malicious intent. The best way to approach access controls, and is the way recommended by ISO, is documentation! This is a reoccurring theme but we need documented process to ensure repeatability, uniformity, and fairness. In this case we should consult with asset owners on what access levels different users, or user roles, require and document them. It is important to ensure we protect both physical and logical access. Restricted SSH access is only so helpful if the server hardware is physically protected.

Keep in mind when granting rights to users that the user must have both the correct security clearance to access that data and a legitimate business need to require it. By keeping these in mind we can avoid granting excessive access to individuals. Periodic reviews can also help us prevent privilege creep as roles and requirements change.

9.1.2. Access to networks and network services.

This is similar to the above control but where 9.1.1 focuses on access to assets, 9.1.2’s scope is focused on network access. Best practice for access control should expand to the entire network, not just the assets. This policy should specify which networks and services should be accessible with authorization and authentication procedures for access, consideration for workers accessing the network from public areas using VPN or Wi-Fi and monitoring requirements should all be detailed. Consider segmenting your network into separate areas with VLAN’s, DMZ’s or similar to control network access between different areas of your organizations.

Different kinds of information needs different classification levels!

Information is vitally important that we protect for various reasons. From ensuring compliance with legislation like the GDPR in the EU to reducing costs for e-discovery. Knowing what information is stored in our network and where it is stored is vital these days.

Classifying this information with tags and even labels for physical media and ensuring there are procedures in place to instruct the handling of that information helps us understand our environment more to help us protect it.

8.2.1. Classification of information.

Not all data is made equal. Given the high costs in both resource and complexity of more stringent security controls and the unequal value of data it is recommended to take a tiered approach to data management. This simply means dividing data based on some requirement into tiers, with each tier having different security requirements and levels of access. One of the most famous example of this is the United States of America’s federal government’s data classification levels of Top Secret – Secret – Confidential – Unclassified with the criteria for each listed below from Wikipedia (Classified information in the United States, n.d.);

Top Secret shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security that the original classification authority is able to identify or describe.
Information is classified Secret when its unauthorized disclosure would cause “serious damage” to national security.
Confidential is defined as information that would “damage” national security if publicly disclosed, again, without the proper authorization.
Unclassified is the default and refers to information that can be released to individuals without a clearance.

Having a well-defined and simple to understand data classification scheme can reduce the effort required when deciding how to secure systems housing the data by giving a baseline of security requirements for that tier.

8.2.2. Labelling of information.

Having developed your classification plan you now need to ensure all data in your organization is designated a classification and is easily identifiable as being given that classification to avoid accidental disclosure or mishandling. An example of this would be to label media used for storing the data with coloured labels, such as RED for top secret, anyone handling the media then knows its classification level at a glance. There should be procedures in place to instruct authors how to correctly classify their outputs. All documents should state their classification level in an easy and quickly understandable way. This labelling effort should be part of your organization’s standard process and documented in your handling procedures.

8.2.3. Handling of assets.

This is very important for organizations dealing with sensitive information. There should be clear, documented procedures for how data is handled at the different tiers including how information is stored and transported and who is authorized to handle it. There should also be instructions on how data and media should be destroyed at the end of its life.

Tracking physical assets; an often forgotten step.

We often put the emphasis on our staff being our most valuable assets and while that is true, we should not ignore our physical assets. Physical hardware needs to be kept track of. There are many cases where organizations, who do not keep an inventory of assets, that have had those assets lost, or stolen, and not known about it for a protracted period of time. Organizations need to ensure all assets have an owner, or custodian, for assets purchased and those assets have an acceptable use policy to prevent abuse. After all nobody wants to find out their data centers are used for bitcoin mining as we have seen happen in the past.

Part of this category also connects with our termination of employees blog post; Ensuring there are procedures in place to recover company assets held by employees.

8.1.1. Inventory of assets.

This control is one that is all too often overlooked. How many companies and organizations have a complete list of all their IT assets and those assets owners? Often our inventories grow too large to be managed without additional resources and then become neglected and out of date. This can lead to security risks of lost assets (unowned) sitting on our network waiting to be compromised, new rogue devices getting added to our network and us being unable to distinguish them from our legitimate assets, even from a patch management perspective knowing what you own is essential for security. Any device that is associated with information or information processing should be recorded. We should keep a record of all these assets including documentation for them, license information and contracts/SLAs (for utilities). There are tools that make this task easier and while it is something that can require a dedicated and substantial effort to develop and maintain, it is something that is one of the more essential building blocks to implementing your ISMS.

8.1.2. Ownership of assets.

All assets in your organization need to how owners assigned to them. This gives us a point of contact should any issues arise that require further investigation or remediation. These asset owners can log in and take care of the regular maintenance of a system, such as hardening and patching. This record of owners should be included in our inventory list described in the previous step. Knowing who to contact can be vital in timely remediation and damage mitigation during a breach when every second counts. Knowing the owner also lets us know who is responsible for protecting those systems, adding/removing them from our inventory and abiding by the asset lifecycle policies, including correct disposal of the hardware and data when that asset is end of life.

8.1.3. Acceptable use of assets.

No user should have complete, unfettered use of company assets. Having the acceptable use of assets documented in an Acceptable Use Policy and then distributing that to all your employees can help you ensure assets and resources are used in a responsible way. Part of this policy is to ensure assets have an appropriate level of security for the data and function it is used for, this means you can have multiple Acceptable Use Policies, one for each classification level of data housed in the various assets. By reducing misuse of assets by employees, making them aware of and having them agree to this policy we reduce risks being introduced by assets being used for non-business purposes.

8.1.4. Return of assets.

If we don’t ensure company owned assets are returned to the company during termination we run the risk of losing control of those assets and, more importantly the data contained within. We also run risks that the assets may be misused or damaged. Human resources and your IT team should liaise prior to termination of employment to ensure any company assets in the control of the leaving staff member are promptly returned to the company. There should also be technical controls in place to ensure that data residing on any personally owned devices of the employee is transferred to the organization.

What to do during a staff termination or change of employment?

The final category of Human Resource Security is how our security handles both employee terminations and when an employees role is changed in some way. Thus HR Security should be a consideration at all stages of an employee’s time at the organization.

7.3.1. Termination or change of employment responsibilities.

An organization’s security should take into account staff turnover; Ensuring that when employees leave, either through termination or resignation, there is limited negative impact on the organization’s security posture. This requires additional planning to address security concerns and challenges.

We need to ensure that our IT departments are in sync with our HR departments so that the employee’s access to information systems is revoked at the correct time to protect our systems and data from the former employee. This coordination is also required to ensure company equipment in the possession of the employee is returned. The employee should also be made aware of any obligations he or she has to the organization after his employment ceases, such as NDA’s and non-compete clauses.

These steps should be carried out when-ever an employee leaves their role even if they are simply taking up a new role in the same company, as it limits the risk of data breaches and permission/privilege creep. One of the more neglected issues that impact companies is that when an employee moves teams, is promoted or has a similar role change; they are given the access required to carry out their new role, but the access they had for their previous role is retained. This can lead to long serving employees having access far in excess of what they need to carry out their tasks and presenting a risk. It is better to prevent this by removing access as it is no longer required.