| Document Type | Policy - Mandatory |
|---|---|
| Document ID | |
| Audience | All employees |
| Confidentiality | For internal use |
| Language | English |
| Applies to | |
| Version | |
| Owner | |
| Author | |
| 1st Reviewer / Review Date | |
| 2nd Reviewer / Review Date | |
| Approver (CEO) / Approval Date | |
| Release Date | |
| Next Review |
The Access Control Policy is an overarching document that is intended to establish the principles upon which many of the controls within this section of the standard are based.
The following areas of the ISO/IEC 27001 standard are addressed by this document:
- A.5 Organizational Controls
- A.5.1 Policies for information security
- A.5.15 Access Control
- A.5.17 Authentication information
- A.8 Technological Controls
- A.8.2 Privileged Access Rights
- A.8.3 Information Access Restriction
- A.8.4 Access to Source Code
- A.8.5 Secure Authentication
- A.8.18 Use of privileged utility programs
The control of access to our information assets is a fundamental part of a defense in depth strategy for information security. If we are to effectively protect the confidentiality, integrity and availability of classified data then we must ensure that a comprehensive mix of physical and logical controls are in place.
But our policy regarding access control must ensure that the measures we implement are appropriate to the business requirement for protection and are not unnecessarily strict.
The policy therefore must be based upon a clear understanding of the business requirements as specified by the owners of the assets involved.
These requirements may depend on factors such as:
- The security classification of the information stored and processed by a particular system or service.
- Relevant legislation that may apply in areas such as privacy and corporate compliance.
- The regulatory framework in which the organization and the system operates.
- Contractual obligations to external third parties.
- The threats, vulnerabilities and risks involved.
- The organization’s appetite for risk.
This access control policy is designed to take account of the business and information security requirements of the organization and is subject to regular review to ensure that it remains appropriate.
This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to the information systems.
Business requirements for access control must be established as part of the requirements-gathering stage of new or significantly changed systems and services and should be incorporated in the resulting design.
Information security requirements must be clearly stated within the business requirements specification document and must take account of the organization’s standards established in the document Principles for Engineering Secure Systems.
In addition to the specific requirements, a number of general principles will be used when designing access controls for the information systems.
These are:
- Defense in depth: security must not depend upon any single control but be the sum of a number of complementary controls.
- Least privilege: the default approach taken must be to assume that access is not required, rather than to assume that is.
- Need to know: access is only granted to the information required to perform a role, and no more.
- Need to use: users will only be able to access physical and logical facilities required for their role.
Adherence to these basic principles will help to keep systems secure by reducing vulnerabilities and therefore the number and severity of security incidents that occur.
As part of the selection of cloud service providers specifically, the following access-related considerations must be considered:
- User registration and deregistration functions provided
- Facilities for managing access rights to the cloud service
- To what extent access to cloud services, cloud service functions and cloud service customer data can be controlled on an as required basis
- Availability of multi-factor authentication for administrator accounts
- Procedures for the allocation of secret information such as passwords
Addressing these requirements as part of the selection process will ensure that the provisions of this policy can be met in the cloud as well as within on-premise systems.
Formal user access control procedures must be documented, implemented and kept up to date for each application and information system to ensure authorized user access and to prevent unauthorized access. They must cover all stages of the lifecycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access.
User access rights must be reviewed at regular intervals to ensure that appropriate rights are still allocated. System administration accounts must only be provided to users that are required to perform system administration tasks.
A request for access to the organization’s network and computer systems must first be submitted to the IT Support Team for approval. All requests will be processed according to a formal procedure that ensures that appropriate security checks are carried out and correct authorization is obtained prior to user account creation. The principle of segregation of duties will apply so that the creation of the user account and the assignment of permissions are performed by different people.
Each user account will have a unique username that is not shared with any other user and is associated with a specific individual i.e., not a role or job title. Generic user accounts (single accounts to be used by a group of people) must not be created as they provide insufficient allocation of responsibility.
An initial strong password must be created on account setup and communicated to the user via secure means. The user must be required to change the password on first use of the account.
When an employee leaves the organization under normal circumstances, their access to computer systems and data must be suspended at the close of business on the employee’s last working day. It is the responsibility of the Line Manager to request the suspension of the access rights via the IT Support Team
In exceptional circumstances where there is perceived to be a risk that the employee may take action that may harm the organization prior to or upon termination, a request to remove access may be approved and actioned in advance of notice of termination being given. This precaution will especially apply in the case where the individual concerned has privileged access rights, for example domain admin.
User accounts must be initially suspended or disabled only and not deleted. User account names must not be reused as this may cause confusion in the event of a later investigation.
In line with the Network Security Policy, the use of non-organization owned devices connected to the organization’s network can seriously compromise the security of the network. Specific approval must be obtained from the IT Support Team before connecting any equipment to the organization’s network.
Where remote access to the network is required via VPN, a request must be made via the IT Support Team . A policy of using multifactor authentication for remote access will be used in line with the principle of “something you have and something you know” in order to reduce the risk of unauthorized access from the Internet.
For further information please refer to the Mobile Device Policy and Remote Working Policy.
Partner agencies or 3rd party suppliers must not be given details of how to access the organization’s network without permission from the IT Support Team. Any changes to supplier’s connections (for example on termination of a contract) must be immediately sent to the IT Support Team so that access can be updated or ceased. All permissions and access methods must be controlled by the IT Support Team .
Partners or 3rd party suppliers must contact the IT Support Team on each occasion to request permission to connect to the network and a log of activity must be maintained. Remote access software and user accounts must be disabled when not in use.
On a regular basis (at least annually) asset owners must review who has access to their areas of responsibility and the level of access in place. This will be to identify:
- People who should not have access (e.g., leavers)
- User accounts with more access than required by the role
- User accounts with incorrect role allocations
- User accounts that do not provide adequate identification, e.g. generic or shared accounts
- Any other issues that do not comply with this policy
This review will be performed according to a formal procedure and any corrective actions identified and carried out.
A review of user accounts with privileged access will be carried out by the CISO on a quarterly basis to ensure that this policy is being complied with.
A strong password is an essential barrier against unauthorized access. Unfortunately, this area is often proven to be the weak link in an organization’s security strategy and a variety of ways to improve the security of user authentication are available, including various forms of multifactor authentication and biometric techniques.
Company Name policy is to make use of additional authentication methods based on a risk assessment which considers:
- The value of the assets protected
- The degree of threat believed to exist
- The cost of the additional authentication method(s)
- The ease of use and practicality of the proposed method(s)
- Any other relevant controls in place
Use of multifactor authentication methods must be justified based on the above factors and securely implemented and maintained where appropriate.
Single Sign-On (SSO) will be used within the internal network where supported by relevant systems unless the security requirements are deemed to be such that a further logon is required.
Whether single or multifactor authentication is used, the quality of user passwords must be enforced in all networks and systems using the parameters defined in the password policy.
The use of passphrases rather than dictionary words is encouraged. Any exceptions to these rules must be authorized by the CISO.
The following settings are enforced in the Microsoft Active Directory and therefore applies to all systems based on AD authentication. They shall equally apply to any other system not based on AD authentication, where technically feasible.
The settings apply to standard User Accounts, which every Employee receives.
- Expiration age is set to 180 days
- Minimum age is 1 day (before changing a password again)
- Minimum length is 8 characters
- The password history (# of forbidden old passwords) is set to 10 old passwords
- 5 failed logon attempts are sanctioned by an account lockout of 30 minutes
- The session idle timeout is 5 minutes (not related to password settings)
These settings apply to Administrative Accounts, which selected Employees receive based on business requirements.
- Expiration age is set to 100 days
- Minimum age is 1 day (before changing a password again)
- Minimum length is 12 characters
- The password history (# of forbidden old passwords) is set to 10 old passwords
- 3 failed logon attempts are sanctioned by an account lockout of 30 minutes
- The session idle timeout is 5 minutes (not related to password settings)
A System Account is an account created by an operating system during installation and used for operating system defined purposes (e.g., Administrator, root, etc.). It also includes specifically created system accounts by ICT staff, such as a local emergency account.
A Service Account is a non-interactive account used to authenticate between systems and services. For instance, between a Web server and a Database server.
System Accounts and Service Accounts have in common that they are never supposed to be used by people except to set them or under very specific conditions and are set to never expire. Therefore, the following rules apply:
- Passwords must be randomly generated
- Minimum length is 16 characters
- Expiration age is set to 0 days (never) but they must be changed every 500 days
- They must be stored in the corporate encrypted Password Manager
As part of the evaluation process for new or significantly changed systems, requirements for effective access control must be addressed and appropriate measures implemented.
These must consist of a comprehensive security model that includes support for the following:
- Creation of individual user accounts
- Definition of roles and groups to which user accounts can be assigned
- Allocation of permissions to objects (e.g., files, buckets, programs) of different types (e.g., read, write, delete, execute) to subjects (user accounts and groups)
- Provision of varying views of menu options and data according to the user account and its permission levels
- User account administration, including ability to disable and delete accounts
- User logon controls such as
- Non-display of password as it is entered
- Account lockout once number of incorrect logon attempts exceeds a specified threshold
- Provide information about number of unsuccessful logon attempts and last successful logon once user has successfully logged on
- Date and time-based logon restrictions
- Device and location logon restrictions
- User inactivity timetout
- Password management, including
- Ability for user to change password
- Controls over acceptable passwords
- Password expiry
- Hashed/encrypted password storage and transmission
- Security auditing facilities, including logon/logoffs, unsuccessful logon attempts, object access and account administration activities
Where bespoke software development is undertaken, program source code must be protected from unauthorized access in accordance with the document Secure Development Environment Guidelines.
Access to privileged utility programs that provide a method of bypassing system security (for example data manipulation tools) must be strictly controlled and their use restricted to identified individuals and specific circumstances, for example as part of a named project or change.
Table of Contents
| Target Audience | This Policy is intended to be understood and applied by all employees. |
|---|---|
| Implementation Timing / Impact | Describe when the policy enters into force. |
| Assumptions / Prerequisites | Describe if any. |
| Exception Management | Describe if needed. |
| Version | Date | Description | Revised by |
|---|---|---|---|