ISO 27001:2013 A. 9 Access control

by Pretesh Biswas,

Access control is the process of granting authorized users the right to use a service while preventing access to non-authorized users. Access control can also be referred to as Access management, rights management, or identity management. The Access Control clause addresses requirements to control access to information assets and information processing facilities. The controls are focused on the protection against accidental damage or loss, overheating, threats, etc. This requires a documented control policy and procedures, registration, removal, and review of user access rights, including here physical access, network access, and the control over privileged utilities and restriction of access to program source code. It provides the following value:

  • Controlled access to services ensures that the organization is able to maintain more effectively the confidentiality of its information.
  • Employees have the right level of access to execute their jobs effectively.
  • There is less likelihood of errors being made in data entry or in the use of a critical service by an unskilled user.
  • The ability to audit the use of services and to trace the abuse of services.
  • The ability more easily revoke access rights when needed – an important security consideration.
  • Maybe needed for regulatory compliance

The terminology of access control:

  1. Access – refers to the level and the extent of a service’s functionality or data that a user is entitled to use.
  2. Identity – refers to the information about the user that distinguishes them as an individual and which verifies their status within the organization. By definition, the identity of a user is unique to that user.
  3. Rights – (also called privileges) refer to the actual settings whereby a user is provided access to a service or group of services. Typical rights, or level of access, include read, write, execute, change and delete.
  4. Service or service groups – Most users do not use only one service, and users performing a similar set of activities will use a similar set of services. Instead of providing access to each service for each user separately, it is more efficient to be able to grant each user, access to the whole set of services that they are entitled to use at the same time.
  5. Directory services – refers to a specific type of tool that is used to manage access and rights.

Access control provides the right for users to be able to use a service or group of services. It is, therefore, the execution of policies and actions defined in information security management.

  1. It is the process of granting authorized users the right to use a service while restricting access to non-authorized users
    • Grant access to services, service groups, data or functions
    • Only if they are entitled to that access
  2. Protecting Confidentiality, Integrity, and Availability (CIA). Sometimes known as rights management or identity management
    • Remove access when people change roles or jobs
    • Regularly audit access permissions to ensure they are correct
  3. Security incidents and problems related to access management will be discreetly recorded

Activities of access control

  1. Requesting access – Access can be requested using one or any number of mechanisms, e.g.
    • A standard request
    • A request for change
    • A service request (submitted via the request fulfilment system)
    • Executing a pre-authorized script or option
    • Rules for requesting access are normally documented as part of the service catalogue
  2. Verification – It needs to verify every request for access to a service from two perspectives:
    • That the user requesting access is who they say they are
    • That they have a legitimate requirement for that service
  3. Providing rights – It does not decide who has access to which services. It only executes the policies and regulations defined. It enforces decisions to restrict to provide access, rather than making the decision. As soon as a user is verified, it will provide that user with the rights to use the requested service. In most cases, this will result in a request to every team or department involved in supporting that service to take the necessary action. Ideally, these tasks should be automated.
  4. Monitoring identity status – As users work in the organization, their roles change as do their needs to access services, e.g. job changes, promotions/demotions, resignation or death, etc. It should understand and document the typical user lifecycle for each type of user and use it to automate the process. Access controls tools should provide features that enable a user to be moved from one state to another or from one group to another, easily and with an audit trail.
    • Job changes – In this case, the user will possibly need access to different or additional services.
    • Promotions or demotions – The user will probably use the same set of services, but will need access to different levels of functionality or data.
    • Transfers – In this situation, the user may need access to exactly the same set of services, but in a different region with different working practices and different sets of data.
    • Resignation – Access needs to be completely removed.
    • Death – Access needs to be completely removed.
    • Retirement – In many organizations, an employee who retires may still have access to a limited set of services, including benefits systems or systems that allow them to purchase company products at a reduced rate, alumni information, etc.
    • Disciplinary action – In some cases, the organization will require a temporary restriction to prevent the user from accessing some or all of the services that they would normally have access to. There should be a feature in the process and tools to do this, rather than having to delete and reinstate the user’s access rights.
    • Dismissals – Where an employee or contractor is dismissed, or where legal action is taken against a customer (for example, for defaulting on payment for products purchased on the internet), access should be revoked immediately. In addition, access management, working together with information security management, should take active measures to prevent and detect malicious action against the organization from that user.
  5. Logging and tracking access – Access management should not only respond to requests. It is also responsible for ensuring that the rights that they have provided are being properly used. Information security management plays a vital role in detecting unauthorized access and comparing it with the rights that were provided by access management. Access management may also be required to provide a record of access for specific services during forensic investigations. If a user is suspected of breaches of policy, inappropriate use of resources, or fraudulent use of data, access management may be required to provide evidence of dates, times and even content of that user’s access to specific services.
  6. Removing or restricting rights – Just as access management provides rights to use a service, it is also responsible for revoking those rights. Again, this is not a decision that it makes on its own. Access management will execute the decisions and policies made during service strategy and design and also decisions made by managers within the organization. Removing access is usually done in the following circumstances:
    • Death
    • Resignation
    • Dismissal
    • The user has changed roles etc.

A.9.1 Business requirements of access control


To limit access to information and information processing facilities.

A.9.1.1 Access control policy


An access control policy should be established, documented and reviewed based on business and information security requirements.

Implementation guidance

Asset owners should determine appropriate access control rules, access rights and restrictions for specific user roles towards their assets, with the amount of detail and the strictness of the controls reflecting the associated information security risks. Access controls are both logical and physical and these should be considered together. Users and service providers should be given a clear statement of the business requirements to be met by access controls. The policy should take account of the following:

  1. security requirements of business applications.
  2. policies for information dissemination and authorization, e.g. the need-to-know principle and information security levels and classification of information.
  3. consistency between the access rights and information classification policies of systems and networks.
  4. relevant legislation and any contractual obligations regarding the limitation of access to data or services.
  5. management of access rights in a distributed and networked environment that recognizes all types of connections available.
  6. segregation of access control roles, e.g. access request, access authorization, access administration.
  7. requirements for formal authorization of access requests.
  8. requirements for periodic review of access rights.
  9. removal of access rights.
  10. archiving of records of all significant events concerning the use and management of user identities and secret authentication information
  11. roles with privileged access

Care should be taken when specifying access control rules to consider:

  1. establishing rules based on the premise “Everything is generally forbidden unless expressly permitted” rather than the weaker rule “Everything is generally permitted unless expressly forbidden”.
  2. changes in information labels that are initiated automatically by information processing facilities and those initiated at the discretion of a user.
  3. changes in user permissions that are initiated automatically by the information system and those initiated by an administrator.
  4. rules which require specific approval before enactment and those which do not. Access control rules should be supported by formal procedures and defined responsibilities.

Role-based access control is an approach used successfully by many organizations to link access rights with business roles. Two of the frequent principles directing the access control policy are:

  1. Need-to-know: you are only granted access to the information you need to perform your tasks (different tasks/roles mean different need-to-know and hence different access profiles).
  2. Need-to-use: you are only granted access to the information processing facilities (IT equipment, applications, procedures, rooms) you need to perform your task/job/role.

9.1.2 Access to networks and network services


Users should only be provided with access to the network and network services that they have been specifically authorized to use.

Implementation guidance

A policy should be formulated concerning the use of networks and network services. This policy should cover:

  1. the networks and network services that are allowed to be accessed.
  2. authorization procedures for determining who is allowed to access which networks and networked services.
  3. management controls and procedures to protect access to network connections and network services.
  4. the means used to access networks and network services (e.g. use of VPN or wireless network).
  5. user authentication requirements for accessing various network services.
  6. monitoring of the use of network services.

The policy on the use of network services should be consistent with the organization’s access control policy.
Unauthorized and insecure connections to network services can affect the whole organization. This control is particularly important for network connections to sensitive or critical business applications or to users in high-risk locations, e.g. public or external areas that are outside the organization’s information security management and control

Organization create, collect, maintain, and makes available large amounts of information in support of their missions. This information is an organizational asset that must be administered and protected in accordance with their value and in conformance with federal, state, and organizational rules and regulations.

The staff, the workers, management, vendors retirees, customers, prospective customers, and members of the community access and utilize different types of information stored on and accessible via organizational systems to perform the numerous tasks required by their respective roles or seek information about products and services provided by the organization. Examples include:

  • Top management
    •  Management resources (Management Information systems, library, etc.)
    • Online ERP systems
  • Staff
    • Employee directory
    • Online human resources systems (timesheets, payroll, benefits, etc.)
  • Purchase
    • Inventory management
    • ERP System
  • All
    • Employee directory
    • Emergency notification systems

Data owners shall determine, approve and assign the level of access to organizational systems and data based on the responsibilities, job functions, reporting or outreach requirements based on the confidentiality of the data and to the restrictions imposed by federal, state and organizational rules and regulations.

Type of Access Control

  1. Centralized Access Control: Rather than maintaining separate accounts on each system, some organizations use a central account database that all systems can authenticate against. In some environments, a Novell server or Windows domain controller functions as the central authentication system. These systems can also be used to enforce policies, limiting users to specifically authorized actions and data. With the increasing number of Web-based services, many organizations are implementing mechanisms to integrate their central authentication systems with their Web-based applications. The JA-SIG Central Authentication Service (CAS) can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate. Other organizations use Kerberos because it supports a broader range of applications and operating systems. However, because Windows systems work best in a Windows domain, even organizations that use Kerberos generally maintain a Windows domain controller that is synchronized with the accounts in their Kerberos domain. Lastly, the Lightweight Directory Access Protocol (LDAP) is another approach to centralized authentication and authorization that is increasingly used in many of the organization.
  2. Decentralized Access Control: It is also not uncommon to find many organizations opting for a decentralized or distributed user account databases where the verification of authorization is performed by various entities located throughout the organization. Common disadvantages of decentralized access control systems are that many times are duplicative, require the coordinated work of several teams, and the administrative overhead is high since changes may need to be implemented throughout numerous locations. Often times each location develops into a silo that is maintained by local administrators without the input/coordination of the other teams. Decentralized access control implementations do have benefits. A well-implemented and coordinated distributed system do not have a single point of failure. If one access control point fails, others can balance the load until the problem is resolved

Access Control Policy

Access Control policies should clearly communicate the organization’s business requirements regarding the identification of users, access to organizational information resources, user access rights, and special access privileges and restrictions.  The following could comprise the core of an organizational access control policy framework.

  • Roles and responsibilities
    • Need-to-Know:  Access only to information needed to perform assigned tasks.
    • Need-to-Use:  Access only to information resources needed to perform assigned tasks
    • Access levels and privileges by role
    • Periodic review and removal of access levels and privileges
    • Segregation of duties for requesting, authorizing, and reviewing access levels and privileges
  • What is required to identify users?
    • The requirement for vetting users in person
    • A requirement to archive records concerning user identification and credentialing
  • What criteria are used to determine the types of credentials used?
  • What criteria are used to determine the level of access to applications and services?
    • Identification of roles with privileged access
    • Contractual obligations for limiting access granted to vendors and partners
  • What is required from identity providers and from service providers?
    • The requirement to identify the security requirements of applications – both, purchased and developed internally
    • The requirement to determine the Level of Authentication (LOA) required to access a service based on risk

Access Control Program

As data, access, and networks continue to expand, organizations have an ever-increasing need to manage identities and access. The optimum solution for this function may be a well-planned and organization-wide Access Management program. In its simplest form, Access Management ensures that only the right people can access the right services at the right time. However, within a complex organization, establishing an Access Management program is not an easy task. Many stakeholders, technology areas, policies, and processes must work together for a scalable and robust  Program. In addition, governance plays a key role in the success of any Acess Management Program and implementation.

9.2 User access management


To ensure authorized user access and to prevent unauthorized access to systems and services.

9.2.1 User registration and de-registration


A formal user registration and de-registration process should be implemented to enable the assignment of access rights.

Implementation guidance

The process for managing user IDs should include:

  1. Using unique user IDs to enable users to be linked to and held responsible for their actions.  The use of shared IDs should only be permitted where they are necessary for business or operational reasons and should be approved and documented.
  2. Immediately disabling or removing user IDs of users who have left the organization.
  3. Periodically identifying and removing or disabling redundant user IDs;
  4. Ensuring that redundant user IDs are not issued to other users.

Providing or revoking access to information or information processing facilities is usually a two-step  procedure:

  1. Assigning and enabling, or revoking, a user ID;
  2. Providing, or revoking, access rights to such user ID

9.2.2 User access provisioning


A formal user access provisioning process should be implemented to assign or revoke access rights for all user types to all systems and services.

Implementation guidance

The provisioning process for assigning or revoking access rights granted to user IDs should include:

  1. Obtaining authorization from the owner of the information system or service for the use of the information system or service.  Separate approval for access rights from management may also be appropriate.
  2. Verifying that the level of access granted is appropriate to the access policies and is consistent with other requirements such as segregation of duties.
  3. Ensuring that access rights are not activated (e.g. by service providers) before authorization procedures are completed.
  4. Maintaining a central record of access rights granted to a user ID to access information systems and services.
  5. Adapting access rights of users who have changed roles or jobs and immediately removing or
    blocking the access rights of users who have left the organization;
  6. Periodically reviewing access rights with owners of the information systems or services.

Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews are easier managed at the level of such roles than at the level of particular rights. Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel or contractors.

9.2.3 Management of privileged access rights


The allocation and use of privileged access rights should be restricted and controlled.

Implementation guidance

The allocation of privileged access rights should be controlled through a formal authorization process in accordance with the relevant access control policy. The following steps should be considered:

  1. The privileged access rights associated with each system or process, e.g. operating system, database management system and each application and the users to whom they need to be allocated should be identified.
  2. Privileged access rights should be allocated to users on a need-to-use basis and on an event-by-event basis in line with the access control policy, i.e. based on the minimum requirement for their functional roles.
  3. An authorization process and a record of all privileges allocated should be maintained. Privileged access rights should not be granted until the authorization process is complete.
  4. Requirements for the expiry of privileged access rights should be defined.
  5. Privileged access rights should be assigned to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged IDs.
  6. The competences of users with privileged access rights should be reviewed regularly in order to verify if they are in line with their duties.
  7. Specific procedures should be established and maintained in order to avoid the unauthorized use of generic administration user IDs, according to systems’ configuration capabilities.
  8. For generic administration user IDs, the confidentiality of secret authentication information should be maintained when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms).

Inappropriate use of system administration privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems.

9.2.4 Management of secret authentication information of users


The allocation of secret authentication information should be controlled through a formal management process.

Implementation guidance

The process should include the following requirements:

  1. Users should be required to sign a statement to keep personal secret authentication information confidential and to keep group (i.e. shared) secret authentication information solely within the members of the group; this signed statement may be included in the terms and conditions of employment.
  2. When users are required to maintain their own secret authentication information they should be provided initially with secure temporary secret authentication information`, which they are forced to change on first use.
  3. Procedures should be established to verify the identity of a user prior to providing a new, replacement or temporary secret authentication information.
  4. Temporary secret authentication information should be given to users in a secure manner; the use of external parties or unprotected (clear text) electronic mail messages should be avoided.
  5. Temporary secret authentication information should be unique to an individual and should not be guessable.
  6. Users should acknowledge receipt of secret authentication information.
  7. Default vendor secret authentication information should be altered following the installation of systems or software.

Passwords are a commonly used type of secret authentication information and are a common means of verifying a user’s identity. Other types of secret authentication information are cryptographic keys and other data stored on hardware tokens (e.g. smart cards) that produce authentication codes.

9.2.5 Review of user access rights


Asset owners should review users’ access rights at regular intervals.

Implementation guidance

The review of access rights should consider the following:

  1. Users’ access rights should be reviewed at regular intervals and after any changes, such as promotion, demotion or termination of employment.
  2. User access rights should be reviewed and re-allocated when moving from one role to another within the same organization.
  3. Authorizations for privileged access rights should be reviewed at more frequent intervals.
  4. Privilege allocations should be checked at regular intervals to ensure that unauthorized privileges have not been obtained.
  5. Changes to privileged accounts should be logged for periodic review.

This control compensates for possible weaknesses in the execution of controls 9.2.1, 9.2.2 and 9.2.6.

9.2.6 Removal or adjustment of access rights


The access rights of all employees and external party users to information and information processing facilities should be removed upon termination of their employment, contract or agreement, or adjusted upon change.

Implementation guidance

Upon termination, the access rights of an individual to information and assets associated with information processing facilities and services should be removed or suspended. This will determine whether it is necessary to remove access rights. Changes of employment should be reflected in the removal of all access rights that were not approved for the new employment. The access rights that should be removed or adjusted include those of physical and logical access. Removal or adjustment can be done by removal, revocation or replacement of keys, identification cards, information processing facilities or subscriptions. Any documentation that identifies access rights of employees and contractors should reflect the removal or adjustment of access rights. If a departing employee or external party user has known passwords for user IDs remaining active, these should be changed upon termination or change of employment, contract or agreement.
Access rights for information and assets associated with information processing facilities should be reduced or removed before the employment terminates or changes, depending on the evaluation of risk factors such as:

  1. Whether the termination or change is initiated by the employee, the external party user or by management, and the reason for termination;
  2. The current responsibilities of the employee, external party user or any other user;
  3. The value of the assets currently accessible.

In certain circumstances, access rights may be allocated on the basis of being available to more people than the departing employee or external party user, e.g. group IDs. In such circumstances, departing individuals should be removed from any group access lists and arrangements should be made to advise all other employees and external party users involved to no longer share this information with the person departing. In cases of management-initiated termination, disgruntled employees or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they may be tempted to collect information for future use.

  1. User Types and Affiliations

All staff has a broad constituency with varying degrees of affiliation with the organization. One thing in common among all staff is that all require access to some type of organizational information for a determined period of time – they all become Users.

At a high level, organizations can divide Users into two groups based on their type of affiliation with the organization:

  • Formal Affiliation: These are Users whose affiliation to the organization is established by some kind of contract or agreement. Users in this group include staff members, employees, vendors, clients, and Management.
  • Casual Affiliation: These are Users whose affiliation to the organization is transitory, periodic, mostly informational and not established by a contract or agreement. Users in this group include guests, retirees, the relative of employees, visitors for the website, etc.
  1. User Registration

Identification is the mechanism to ensure that a user, program, or device is the entity it claims to be.

User Registration:

The User registration process has, generally, four steps:

  • Identity Vetting: the collection and validation of identity information. This information may include full name as it appears in identity documents, date of birth, current address, existing relationship with the organization (e.g, hired employee, registered contractor, etc.
  • Identity Proofing: aligning collected data and matching an actual person to it. This can be done either:
    • By leveraging a pre-existing relationship with an individual (e.g., individual was a former contractor or a former employee)
    • In-person. The individual is required to go to the HR office charged with User registration and produce a valid current government photo ID that contains the individual’s picture (e.g., driver’s license or passport) and an address. The office compares the picture to the person, verifies the information with its records and, if everything checks, records the sources of proof and approves the issue of a credential.
    • If the individual is unable to fulfill the proofing requirements in-person (e.g., staff in a small remote office ), they can forward to the HR office charged with User registration, via email, mail, fax, a valid current government ID number (e.g., driver’s license or passport) and either a second government ID number or a financial account number (e.g., checking or savings account, credit card) with supporting documentation. The HR contacts the corresponding agencies and verifies the information provided with their records, and if everything checks record the sources of proof and approve the issue of a credential.
  • Creation of a master identity record
  • Issuance of credentials – each credential issued shall include a unique identifier (e.g., UserId) that distinguishes it from all other credentials issued to the individual and shall clearly associate the credential unique identifier to the individual’s master identity record. Credentials are usually issued as an UserId / Password pair but they can also be embedded in other devices such as Id Cards, second-factor tokens, etc
  1. Privilege Management

Privilege management is the set of processes for managing user attributes and policies that determine a user’s access rights to an information resource. In other words, what user attributes, job functions, and organizational affiliations can serve as the basis for access authorization decisions. Users should be granted the least privilege – the most restrictive set of permissions or access rights – needed to perform assigned work tasks.

Two common problems related to privilege management are an excessive privilege and creeping privilege. The former happens when a user has more access or permissions than the assigned work tasks and/or role requires. The latter happens when a user account accumulates privileges over time as roles and assigned work tasks to change. Both problems are addressed by periodic review of user access rights.

Management of Administrative privileges is particularly important since very common cyber-attack techniques take advantage of unmanaged administrative privileges. An attacker can trick a user into downloading an application from a malicious website or opening a malicious email attachment which contains executable code that installs and runs on the user’s device. In cases where users have administrative rights to their devices, the attacker can take over the device and install keystroke loggers, sniffers, etc. to find administrator passwords and other confidential data. Another common attack involves domain administration privileges in Windows environments potentially giving an attacker significant control over numerous devices and access to the data they contain.

  1. Password Management

It is important to realize that people will share their passwords unless you provide them with some other method of allowing specific individuals to access information in their accounts. For instance, individuals in upper management often ask an administrative assistant to check their e-mail. Also, when people go on vacation, they may need to give someone temporary access to data on their computers, in the e-mail, and on other systems. Password sharing policies should be put in place along with solutions that provide needed functionality with accountability for the shared resource.

Good Password Practices:

  • Use strong passwords or long passphrases
  • Do NOT write passwords down
  • Do NOT share passwords
  • Use different passwords for different applications (e.g., work vs personal; shopping, and banking vs casual email and Facebook; applications that contain confidential information vs those that do not, etc.)

What is a Strong Password?

The strength of a password is determined by some restrictions – like minimum length, password age, use of multiple types and special characters, and reuse restrictions – which determines the average number of guesses an attacker must try to guess the password and ease with which the attacker can test the validity of the guessed password. Password entropy is a mathematical way to measure the difficulty of guessing or determining a password. As applied to passwords, guessing entropy is the estimate of the average amount of work needed to guess a password. Min-entropy is the measure of the difficulty of guessing the easiest single password to guess in the population. Password entropy is expressed in bits. If a password of k bits is chosen at random there are 2 to the k exponential possible values and the password is said to have k bits of entropy. If a password of length l characters is chosen at random from an alphabet of b characters (e.g., the 94 printable characters on a typical keyboard) then the entropy of the password is b to the l exponential. See the following InCommon Assurance link for Password Entropy. An example of a reasonably strong password is:

  • An attack targeted against the password should have a probability of success of less than 2 to the -14 exponential (i.e., 1 chance in 16,384) over the life of the password.
  • Has at least 10 bits of min-entropy
  • Has a minimum length of 10 characters
  • Does not contain a username, personal name, or organizational name
  • Avoids repetition or dictionary words
  • Contains a mix of upper and lower case alpha characters
  • Has at least 2 non-alpha characters (i.e., numerals and/or special characters)
  • Has a password life of 90 days
  • Has not been used before (i.e., no password reuse)

To Change or Not to Change? How Often?

Again, there are as many answers to these questions as there are information security professionals. The argument for changing passwords regularly is that the longer a password remains the same and the more often the same password is used, then it is more likely that the password will be discovered or compromised. Also, the benefit of an “expiration date” on a password is that it limits the amount of time a lost or compromised password can be used by an unauthorized party. The more secure or sensitive information resources, the more frequently passwords should be changed. Conversely, the argument against changing passwords regularly is that strong passwords are reasonably secure and they take longer time and more effort to guess thus making them less likely to be discovered or compromised. Also, it may not be as easy to come up with easy to remember a strong password every 30 or 60 days.

Even though there is no “right” or “perfect” answer, the following points are worth considering:

  • Password policy should be based on risk, vulnerabilities, and deployed safeguards
  • The period of time between changes should be determined by the required strength of the passwords being used
  • Password changes make it harder for users to use the same password for multiple services (i.e., forces password “diversity”)
  • Periodic password changes, especially when done as a routine, could limit successful phishing attempts since users would know when it is time to change passwords and when it is not.

Password Management Problems: By no means a comprehensive list

  • Need (and failure) to remember multiple passwords
  • Need (and failure) to remember strong passwords
  • The frequency of password change
  • Coming up with easy to remember but difficult to hack passwords multiple times per year
  • Need to replicate password change to multiple devices or applications
  • The sophistication of social engineering and “phishing” attacks

Alternatives to Manage Password Management Problems:


A passphrase is just a different way of thinking about a “secret” or “something you know”. The main difference is that a passphrase is longer. While a usual password is 8 to 10 characters long, a passphrase can be twice as long. Compared to passwords, a passphrase is generally stronger because it is more memorable than passwords thus reducing the need to write them down, they make some types of brute force attacks impractical since they are much longer than passwords, and they make phrase or quote dictionary attacks almost impossible if the passphrase is well constructed.

  1. Review of Access Rights

Some data, due to its nature or confidentiality requirements, may be restricted from general access by users and may require additional levels of formal approval before being made available. Users are granted access to these data on a need-to-know basis – when there are justified work-related reasons for access or need to know. An important characteristic of need-to-know access is the access is granted for a limited period of time. When the reasons for access are no longer valid, access to the data is (or should be) revoked.

Least privilege and need-to-know access underscore the importance of the periodic review of user accounts and their corresponding access rights. Dormant user accounts – active user accounts that show no activity for very long periods of time – poses an unnecessary risk for unauthorized access to confidential data. The periodic review of user accounts and corresponding access rights with system owners, disabling user accounts after a preset period of inactivity, purging them after a longer period of inactivity are all good practices to ensure that a system does not contain old, unused user accounts and to mitigate risk.

9.3 User responsibilities


To make users accountable for safeguarding their authentication information.

9.3.1 Use of secret authentication information


Users should be required to follow the organization’s practices in the use of secret authentication information.

Implementation guidance

All users should be advised to:

  1. Keep secret authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority;
  2. Avoid keeping a record (e.g. on paper, software file or hand-held device) of secret authentication information, unless this can be stored securely and the method of storing has been approved (e.g. password vault);
  3. Change secret authentication information whenever there is any indication of its possible compromise;
  4. When passwords are used as secret authentication information, select quality passwords with sufficient minimum length which are:
    • easy to remember
    • not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers, and dates of birth, etc.
    • not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);
    • free of consecutive identical, all-numeric or all-alphabetic characters;
    • if temporary, changed at the first log-on;
  5. Not share individual user’s secret authentication information;
  6. Ensure proper protection of passwords when passwords are used as secret authentication information in automated log-on procedures and are stored;
  7. Not use the same secret authentication information for business and non-business purposes.

Provision of Single Sign-On (SSO) or other secret authentication information management tools reduce the amount of secret authentication information that users are required to protect and thus can increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of secret authentication information.

Users should be made aware of their responsibilities towards protecting their issued credentials, choosing strong passwords and keeping them confidential, and preventing the unauthorized disclosure of sensitive information under their care. The following can be included in the institution’s Acceptable Use of Information Security Policy. Systems should be locked when left unattended

Users shall

  • Access data in order to comply with the duties of their role or job duties on a need to know basis.
  • Not attempt to access data or programs contained on systems for which they do not have authorization or consent.
  • Not share their computer/network account, password, personal identification number (PIN), digital certificate, security token (i.e. Smartcard), or any other device used for identification and authorization purposes.
  • Not share digital certificate passwords used for digital signatures.
  • Not circumvent password entry through the use of auto logon, application “remember password” features, embedded scripts or hard-coded passwords in client software.

Password-protect their desktops/laptops when left unattended

9.4 System and application access control


To prevent unauthorized access to systems and applications.

9.4.1 Information access restriction


Access to information and application system functions should be restricted in accordance with the access control policy.

Implementation guidance

Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy. The following should be considered in order to support access restriction requirements:

  1. Providing menus to control access to application system functions.
  2. Controlling which data can be accessed by a particular user.
  3. Controlling the access rights of users, e.g. read, write, delete and execute.
  4. Controlling the access rights of other applications.
  5. Limiting the information contained in outputs.
  6. Providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.

9.4.2 Secure log-on procedures


Where required by the access control policy, access to systems and applications should be controlled by a secure log-on procedure.

Implementation guidance

A suitable authentication technique should be chosen to substantiate the claimed identity of a user. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, should be used. The procedure for logging into a system or application should be designed to minimize the opportunity for unauthorized access. The log-on procedure should, therefore, disclose the minimum of information about the system or application, in order to avoid providing an unauthorized user with any unnecessary assistance. A good log-on procedure should:

  1. not display system or application identifiers until the log-on process has been successfully completed.
  2. display a general notice warning that the computer should only be accessed by authorized users.
  3. not provide help messages during the log-on procedure that would aid an unauthorized user.
  4. validate the log-on information only on the completion of all input data. If an error condition arises, the system should not indicate which part of the data is correct or incorrect.
  5. protect against brute force log-on attempts.
  6. log unsuccessful and successful attempts.
  7. raise a security event if a potential attempted or successful breach of log-on controls is detected
  8. display the following information on completion of a successful log-on:
    •  date and time of the previous successful log-on;
    • details of any unsuccessful log-on attempts since the last successful log-on;
  9. not display a password being entered;
  10. not transmit passwords in clear text over a network;
  11. terminate inactive sessions after a defined period of inactivity, especially in high-risk locations such as public or external areas outside the organization’s security management or on mobile devices;
  12. restrict connection times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access.

Passwords are a common way to provide identification and authentication based on a secret that only the user knows. The same can also be achieved with cryptographic means and authentication protocols. The strength of user authentication should be appropriate for the classification of the information to be accessed. If passwords are transmitted in clear text during the log-on session over a network, they can be captured by a network ”sniffer” program.

9.4.3 Password management system


Password management systems should be interactive and should ensure quality passwords.

Implementation guidance

A password management system should:
a) enforce the use of individual user IDs and passwords to maintain accountability;
b) allow users to select and change their own passwords and include a confirmation procedure to allow for input errors;
c) enforce a choice of quality passwords;
d) force users to change their passwords at the first log-on;
e) enforce regular password changes and as needed;
f) maintain a record of previously used passwords and prevent re-use;
g) not display passwords on the screen when being entered;
h) store password files separately from application system data;
i) store and transmit passwords in protected form.

Some applications require user passwords to be assigned by an independent authority; in such cases, points b), d) and e) of the above guidelines do not apply. In most cases, the passwords are selected and maintained by users.

9.4.4 Use of privileged utility programs


The use of utility programs that might be capable of overriding system and application controls should be restricted and tightly controlled.

Implementation guidance

The following guidelines for the use of utility programs that might be capable of overriding system and application controls should be considered:
a) use of identification, authentication and authorization procedures for utility programs;
b) segregation of utility programs from applications software;
c) limitation of the use of utility programs to the minimum practical number of trusted, authorized users.
d) authorization for the ad-hoc use of utility programs;
e) limitation of the availability of utility programs, e.g. for the duration of an authorized change;
f) logging of all use of utility programs;
g) defining and documenting of authorization levels for utility programs;
h) removal or disabling of all unnecessary utility programs;
i) not making utility programs available to users who have access to applications on systems where segregation of duties is required.

Most computer installations have one or more utility programs that might be capable of overriding system and application controls.

9.4.5 Access control to program source code


Access to program source code should be restricted.

Implementation guidance

Access to program source code and associated items (such as designs, specifications, verification plans, and validation plans) should be strictly controlled, in order to prevent the introduction of unauthorized functionality and to avoid unintentional changes as well as to maintain the confidentiality of valuable intellectual property. For program source code, this can be achieved by controlled central storage of such code, preferably in program source libraries. The following guidelines should then be considered to control access to such program source libraries in order to reduce the potential for corruption of computer programs:
a) where possible, program source libraries should not be held in operational systems;
b) the program source code and the program source libraries should be managed according to established procedures;
c) support personnel should not have unrestricted access to program source libraries;
d) the updating of program source libraries and associated items and the issuing of program sources to programmers should only be performed after appropriate authorization has been received;
e) program listings should be held in a secure environment;
f) an audit log should be maintained of all accesses to program source libraries;
g) maintenance and copying of program source libraries should be subject to strict change control procedures
If the program source code is intended to be published, additional controls to help to get assurance on its integrity (e.g. digital signature) should be considered.

  1. Operating System Access Control

a) Single Sign-On

The Central Authentication Service can be used to securely integrate Web authentication in addition to providing single sign-on capabilities where appropriate. Although having a central authentication system makes account management easier, the exposure of one stolen account is greater when it gives the thief access to multiple systems on the network. Therefore, single sign-on is not necessarily desirable in higher education environments where password theft is a common risk. Less sign-on is ideal – using centralized authentication for most systems but maintaining separate accounts on computer systems that contain particularly sensitive data and require added protection.

b) Authentication

Authentication is the mechanism to confirm the identity of an entity requesting access to an information resource. Authentication is often a prerequisite to allowing access to an information resource. To be properly authenticated, the entity is required to provide credentials – a unique identifier or NetId and a password, passphrase or token. The credentials are compared to the identifying information previously stored on the entity and if the credentials match the stored information, the entity is authenticated.

Most organizations require all members of their communities to have their own unique usernames and password to access certain IT resources. In addition, organizations authenticate these individuals before allowing them to connect to the network or the Internet. This approach not only enables the organization to attribute network activities to individual accounts, but It also gives the opportunity to scan systems for vulnerabilities before they connect to the network.

Are a Username and Password Enough for Authentication?

Information security practitioners are increasingly making the case that passwords and password practices are bad and getting worse. Specifically, that usernames and passwords are no longer sufficient to authenticate to information resources containing confidential information. Two-Factor Authentication is the use of an additional factor to minimize the probability of fraudulent authentication.

What Is Two-Factor Authentication?

It is the use of two independent means of evidence (factors) to assert the identity of a user requesting access to some application or service to the organization that provides the application or service. The objective of two-factor authentication, as a method of electronic computer authentication, is to decrease the probability that the requestor is not who he/she claims to be (i.e., providing false evidence of his/her identity.) Two-factor authentication is achieved by a combination of any two of the three “Somethings” below:

  1. Something you know
  • Personal Identification Number (PIN)
  • Password

2. Something you have

  • Smartphone
  • Token
  • ID Badge / Smartcard

3. Something you are

  • Fingerprint
  • Retinal Scan
  • Voice Pattern
  • Typing Cadence

Note that the use of a password in combination with a PIN, for example, is NOT considered two-factor authentication because both pieces of information involve a single factor – something you know. The use of two-factor authentication has been pervasive and ubiquitous for quite a long time already. Any person who has used an ATM machine to withdraw cash for a bank account has used two-factor authentication – you had to provide something you had (a card) and had to provide something you know (a PIN) in order to complete the transaction.

Difference Between Two-Factor and Multi-Factor Authentication

The subtle difference is that, while two-factor authentication uses exactly two factors to assert the identity of a user, multi-factor authentication uses two or more factors to assert identity. In essence, two-factor authentication is a subset of multi-factor authentication. An example of multi-factor authentication would be the requirement to insert a smart-card (something you have) into a smart-card reader, enter a PIN (something you know), and provide a valid fingerprint (something you are) provided via a biometric fingerprint reader. This example uses three factors to assert the identity of a user.

Business Reasons to Consider Two-Factor Authentication

Privacy and the threat of identity theft is increasingly a concern as more personal information finds its way to online applications.  In addition, passwords alone can frequently be easily guessed or compromised through phishing or hacking, consequently, no longer providing adequate protection for mission-critical information systems and applications containing Personally Identifiable Information (PII), Personal Health Information (PHI), and other confidential information.  Some specific concerns:

  • As passwords become easier to guess or compromise, password complexity requirements are quickly coming to exceed what users can reasonably remember.
  • Password proliferation has increased the time and effort spent on user support because of forgotten passwords and the need to reset them.
  • Many password reset mechanisms are insecure, even if the passwords themselves are not.
  • The increased use of single sign-on increases the value of passwords and the number of ways by which those passwords can be potentially attacked.
  • Passwords are all-too-often cached in applications (e.g., email clients or web browsers), stored off-site (e.g.,  POP consolidation of email from multiple accounts), and reused for multiple services, some highly sensitive.
  1. Application and Information Access Control

a) Information Access Restriction

The organization’s Access Control page can contain publications, presentations, policies, podcasts, and blogs regarding mechanisms by which a system grants or revokes the right to access some data or perform some action.

b) Sensitive System Isolation

Segregation can be defined as the action or state of setting someone or something apart from other people or things or being set apart. Information resources that are critical to the performance of the Organization’s mission, contain confidential information, or is otherwise considered sensitive should be segregated (i.e., have a dedicated environment) based on sensitivity and risk. The segregation of information resources can be accomplished by:

  • Creating network domains (e.g., public vs internal, critical vs non-critical, etc) – the collection of devices and subjects that share a common security policy – and trusts – a security bridge between domains to enable users of one domain to access resources from another – are common practices in decentralized access implementations. Domains are defined based on risk and the specific security requirements of the domain.
  • Implementing virtual local area networks (VLAN) and/or virtual private networks (VPN) for specific user/application groups
  • Controlling network data flows using network equipment routing/switching capabilities (e.g., access control lists (ACLs))
  1. Federation

 A federation is an association of organizations that come together to exchange information, as appropriate, about their users and resources in order to enable collaborations and transactions

  • Increasingly, people must easily and securely exchange information in cyberspace among known individuals and be trusted to access restricted resources without having to struggle with numerous and onerous security processes
  • Ideally, individuals would each like a single digital credential that can be securely used to authenticate his or her identity anytime authentication of identity is required to secure any transaction.
  • Traditional forms of authentication and authorization are no longer sufficient or the level of assurance needed by modern internet-based applications
    • Increase security
    • Compliance with federal and state rules
  • Application security is becoming increasingly onerous (multiple applications, multiple enterprises, and multiple user roles in multiple contexts)
    • Inter-organizational collaboration
    • Operational efficiencies and cost control
  • Examples:
    • The organization wants to offer services to their constituents but doesn’t want to host them.
    • The vendor wants to offer a service to an organization but doesn’t want the burden of managing user credentials and authentication.
    • The user wants seamless access to services. “Single-Sign-On”.
    • The security officer wants to protect organization assets, user identity information, and passwords

Traditional Approach

Federated Approach:

First Steps:

Technically speaking, it involves:

  • new policies
  • new processes
  • new trust relationships
  • new authentication and authorization mechanisms
  • new enterprise directories
  • new applications and much more

The participating organization must agree on:

  • Technical specifications: data attributes to exchange, the software to interoperate with
  • Policy specifications: privacy, establish trust and trustworthy data

Must provide two sets of services:

  • Metadata management: aggregate, distribute, and maintain members’ attribute data, syntax, and semantics
  • Trust management:
    • federation and member operation practices and control
    • privacy and security policies

Things to Think About:

  • Policy work is very slow, but critical – start early
    • Identifiers
    • Privacy
    • Content copyright
  • Do not underestimate the difficulty of application integration with new or legacy infrastructure
  • Authorization can be quite a challenge (e.g., how to identify subsets of people)
  • Consider new support models
  • Communication and coordination are key
  • Keeping all stakeholders motivated and involved can be quite a challenge

Policy Issues:

  • Which services reside where?
  • How is vetting / credentialing performed?
  • How do application owners determine the required Level of Assurance (LOA) for their applications?
  • How do Identity providers comply with applications’ LOA requirements?
  • Who supports the end users and applications?
  • Who audits identity providers’ practices and what standards are used?
  • What is the role of Information Security Governance?

Federation Technology Standards:

  • Security Assertion Markup Language (SAML):
    • Standard developed and ratified by OASIS, an international non-profit standards organization, and managed by the OASIS Security Services Technical Committee
    • Has broad vendor and industry acceptance
  • WS-Federation: a specification developed by IBM, Microsoft, BEA, and others. OASIS now has a technical committee tasked with standardizing WS-Fed.
  • Liberty Identity Federation Framework (ID-FF): now integrated into the SAML 2.0 standard.
  • Open ID: a user-centric distributed web-SSO technology perceived as being lighter-weight and less focused on communities of trust than SAML

Benefits of Federation:

  • Sharing of Resources
  • Collaboration
  • Increase security (fewer usernames and passwords to manage)
  • Lower support costs (no application-based identity management)
  • Improved user experience (fewer usernames and passwords to remember)

Challenges of Federation:

  • Deploying new infrastructure is hard
    • The infrastructure must be there before gains can be realized, which makes it just a challenge.
  • Policy development can take considerable time.
  • Trust can be difficult to achieve.
    • Good policy and governance helps (“trust but verify”)
  • Making it ubiquitous across entities of varying sizes is a challenge.
    • Many times, it is the smaller organizations that can benefit the most.

 Good security and identity practices help ensure that an individual using an electronic credential is the person you think it is. For Service Providers in an identity federation, having Identity Provider Operators support a standard practice set (or profile) can mitigate the risk of a service compromise. For Identity Providers, it is a way to provide single sign-on access to applications requiring an increased level of confidence in a credential.

Cloud Computing and Software as a Service (SaaS)

Cloud [computing] describes the use of a collection of distributed services, applications, information and infrastructure comprised of pools of compute, network, information and storage resources. These components can be rapidly orchestrated, provisioned, implemented and decommissioned using an on-demand utility-like model of allocation and consumption.

Software as a Service (SaaS) is the capability provided to the consumer to use a provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email).


  • The decision to procure cloud computing services or SaaS may be driven mostly by individual departments instead of organizational IT strategy.
  • Integrating separately developed applications into an integrated approach.
    • How to manage access?
    • How to manage to provision?
    • How to integrate these applications into organizational web services?
  • How to reduce the number of credentials

An Alternative Solution:

  • Focus on four activities:
    • Develop an organizational Identity Management System
    • Create a standard set of attributes for each person.
    • Use a federation to enable external access
    • Require organizational developers and in RFPs that service providers support SAML and InCommon
  • InCommon provides an easy to use framework for customers and service providers that will work across higher education.

Mobile Computing and Teleworking

Teleworking (i.e., telecommuting), e-commerce, use of intranets, online education, and the increasing use of portable computing devices (e.g., laptops, tablets, smartphones) are driving the need for access to information resources from any place at any time. Today’s mobile workforce or users are no longer just staff trying to check e-mail from home but part and full-time staff, telecommuters, business partners, vendors. and customers who rely on access to organizational networks to accomplish day-to-day business functions.. Information security controls specifically targeting mobile computing and remote access to information resources are becoming an increasingly critical component of any information security program ensuring the protection of the integrity of the organizational networks while allowing remote access to it.

Challenges of Mobile Computing:

  • User Authentication
  • Protection of Transmitted Data
  • Protection of the Organizational Network

To enable remote access to organizational information resources, organizations are implementing Virtual Private Networks (VPN) technology to provide a secure connection to the institutional network. VPNs send data securely through a shared network. VPNs can be established between remote users and a network or between two or more networks thus using the Internet as the medium for transmitting information securely over and between networks via a process called tunneling.


Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

One thought on “ISO 27001:2013 A. 9 Access control

  1. I think using a central account database instead of separate accounts is a great idea. A ton of people might assume that separate accounts are better because they can be managed indivdually. But having them all connected to a central database means they can be accessed more easily.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s