CALL US +44 1502 449001
CountryCountry

The ISO 27001 & ISO 22301 Blog

Dejan Kosutic

How to handle access control according to ISO 27001

Access control is usually perceived as a technical activity that has to do with opening accounts, setting passwords, and similar stuff – and it is true: access control does include all these things, but access control doesn’t begin as a technical thing. It begins as a business decision.

Let’s see what ISO 27001 requires: it defines access control in section A.9 of Annex A, a total of 14 controls (placed in 4 subsections) – more than 12% of all controls in this standard – which means this topic is obviously very important. Let’s see what these controls look like.

Business requirements of access control (subsection A.9.1)

blogpost-banner-27001-premium-en

This subsection requires you to set up an Access Control Policy, and to define which users will have access to which networks and services. In effect, this means you have to set the rules first, and only then allow the users to browse your networks and services.

You can set the access rules in several ways, but typically there are two approaches: the first approach is that you define user profiles (where you define the level of access for each user profile), and then based on each job title you assign an appropriate user profile to that job title. For example, you can define that you have user profile A (with access to basic applications and services), and user profile B (with access to all basic + more sensitive systems) – then you can define a rule where everyone in the company uses user profile A, while only some privileged users (e.g., administrators, managers, etc.) use user profile B.

The second approach is that you define that owners of assets (i.e., networks, applications, services, etc.) have to approve the access to certain users each time they need to access those assets – this second approach is, of course, much more time consuming. In reality, the combination of these two approaches is very often used, as I’ll explain later on.

By the way, the Access Control Policy can focus only on information systems, or both on the information systems and the physical access to secure areas – the standard allows both approaches. In reality, approving the access to a physical area doesn’t have too many differences compared to approving the access to an information system. Read also: Physical security in ISO 27001: How to protect the secure areas.

User access management (subsection A.9.2)

This is where things start to get technical – you have to define how you require the users to register in your systems (e.g., handling user IDs), how you assign them the access (provisioning of access or revoking the access), and how you manage the authentication data (e.g., how you provide the initial passwords, smart cards, etc.).

But again, you have to take care of some organizational stuff – for example, if you need to allow access that is outside of the regular rules (privileged access), you need to define exactly who can approve such user access exception. What is usually done is that companies define user profiles, and if any access has to be approved above that, this is treated as privileged access and then the asset owner has to approve such exception.

Since such exceptions will always exist, the asset owners should regularly review all the privileged access and decide whether they are still needed – very often you’ll have a situation where a privileged access was approved a long time ago, only to find out it poses a high security risk and there is no operational need for such access.

Finally, there has to be a process of removal of all access rights when someone is leaving the company or adjusting them when a person changes their position in the company. Too many times it has happened that people have access to some systems a couple of years after they have left a company, only because no one has remembered to close this access.

By the way, you can define all those rules in the same Access Control Policy, or you can develop separate documents for that purpose – for example, you might develop a Password Policy where you define how to perform the authentication.

User responsibilities (subsection A.9.3)

This is a very short subsection (with one control only) that requires you to define how the users will keep their authentication information secret (e.g., protect their passwords). This is usually done through some document like the Acceptable Use Policy, which defines rules like these: do not write the passwords down, do not disclose them to anyone, do not use the same password in different systems, etc.

System and application access control (subsection A.9.4)

This is where things get even more technical – you have to ensure that the access to all systems is really compliant with the Access Control Policy, that the access is protected with secure log-on procedures (e.g., use biometrics if passwords are not enough), that passwords in use are complex enough and secure enough, etc.

Further, if your company is developing programs, you should define how to protect the access to the source code – usually, the access is defined through the same Access Control Policy as for all the other access issues.

Finally, you should define how to protect the access to the information when using special software tools that enable access to the information directly, bypassing the standard application or system controls – these are usually administrator and utility programs, mainly used by system administrators. In any case, the use of such tools must be restricted, allowed to be used only in very specific circumstances, and under supervision.

To conclude, to have no access control means to have no security at all – this is one of the main building blocks of information security which has to be technically performed well, but also designed so that it is both secure enough and acceptable to users. What you don’t want to happen is to have a very ambitious plan to change passwords every month, only to find out your employees have completely rejected such a system because they thought it impractical.

Check out this  ISO 27001 Gap analysis tool that will give you insight into how much your company is compliant with access control requirements of this standard.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.

OUR CLIENTS

OUR PARTNERS

  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.