1 Policy Statement
[Organization Name] will establish specific requirements for protecting information and information systems against unauthorized access. [Organization Name] will effectively communicate the need for information and information system access control.
2 Purpose
Information security is the protection of information against accidental or malicious disclosure, modification, or destruction. Information is an important, valuable asset of [Organization Name] that must be managed with care. All information has value to the Organization. However, not all of this information has equal value or requires the same level of protection. Access controls are put in place to protect information by controlling who has the right to use different information resources and by guarding against unauthorized use. Formal procedures must control how access to information is granted and how such access is changed. This policy also mandates a standard for the creation of strong passwords, their protection, and frequency of change.
3 Scope
This policy applies to all [Organization Name] Organization, Committees, Departments, Partners, Employees of the Organization (including system support staff with access to privileged administrative passwords), contractual third parties and agents of the Organization with any form of access to [Organization Name’s] information and information systems.
4 Definition
Access control rules and procedures are required to regulate who can access [Organization Name] information resources or systems and the associated access privileges. This policy applies at all times and should be adhered to whenever accessing [Organization Name] information in any format, and on any device.
5 Risks
On occasion business information may be disclosed or accessed prematurely, accidentally, or unlawfully. Individuals or companies, without the correct authorization and clearance, may intentionally or accidentally gain unauthorized access to business information which may adversely affect day-to-day business. This policy is intended to mitigate that risk. Non-compliance with this policy could have a significant effect on the efficient operation of the Organization and may result in financial loss and an inability to provide necessary services to our customers.
6 Applying the Policy – Passwords
6.1 Choosing Passwords
Passwords are the first line of defense for our ICT systems and together with the user ID helps to establish that people are who they claim to be. A poorly chosen or misused password is a security risk and may impact the confidentiality, integrity, or availability of our computers and systems.
6.1.1 Weak and strong passwords
A weak password is one that is easily discovered, or detected, by people who are not supposed to know it. Examples of weak passwords include words picked out of a dictionary, names of children and pets, car registration numbers, and simple patterns of letters from a computer keyboard. A strong password is a password that is designed in such a way that it is unlikely to be detected by people who are not supposed to know it, and difficult to work out even with the help of a computer.Everyone must use strong passwords with a minimum standard of:
- At least seven characters.
- Contain a mix of alpha and numeric, with at least one digit
- More complex than a single word (such passwords are easier for hackers to crack).
- [Amend the above as required for your local needs]
The organization advises using Environ passwords with the following format: consonant, vowel, consonant, consonant, vowel, consonant, number, number. An example for illustration purposes is provided below:
6.2 Protecting Passwords
It is of utmost importance that the password remains protected at all times. The following guidelines must be adhered to at all times [amend the list as appropriate]:
- Never reveal your passwords to anyone.
- Never use the ‘remember password’ function.
- Never write your passwords down or store them where they are open to theft.
- Never store your passwords in a computer system without encryption.
- Do not use any part of your username within the password.
- Do not use the same password to access different [Organization Name] systems.
- Do not use the same password for systems inside and outside of work.
6.3 Changing Passwords
All user-level passwords must be changed at a maximum of every 90 days, or whenever a system prompts you to change it. Default passwords must also be changed immediately. If you become aware or suspect, that your password has become known to someone else, you must change it immediately and report your concern to [Name a department – e.g. IT Helpdesk]. Users must not reuse the same password within 20 password changes [amend as appropriate].
6.4 System Administration Standards
The password administration process for individual [Organization Name] systems is well-documented and available to designated individuals. All [Organization Name] IT systems will be configured to enforce the following:
- Authentication of individual users, not groups of users – i.e. no generic accounts.
- Protection with regards to the retrieval of passwords and security details.
- System access monitoring and logging – at a user level.
- Role management so that functions can be performed without sharing passwords.
- Password admin processes must be properly controlled, secure and auditable.
7 Applying the Policy – Employee Access
7.1 User Access Management
7.1.1 User access provisioning
Each user must be allocated access rights and permissions to computer systems and data that are commensurate with the tasks they are expected to perform. In general, this will be role-based, in which a user account will be added to a group that has been created with the access permissions required by that job role. Group roles must be maintained in line with business requirements and any changes to them must be formally authorized and controlled via the change management process. Ad-hoc additional permissions must not be granted to user accounts outside of the group role; if such permissions are required this must be addressed as a change and formally requested. They must cover all stages of the life cycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access. These must be agreed upon by [Organization Name]. Each user must be allocated access rights and permissions to computer systems and data that:
- Are commensurate with the tasks they are expected to perform.
- Have a unique login that is not shared with or disclosed to any other user.
- Have an associated unique password that is requested at each new login.
User access rights must be reviewed at regular intervals to ensure that the appropriate rights are still allocated. System administration accounts must only be provided to users that are required to perform system administration tasks.
7.1.2 Removal or adjustment of access rights
Where an adjustment of access rights or permissions is required, for example due to an individual changing role, this must be carried out as part of the role change. It must be ensured that access rights no longer required as part of the new role are removed from the user account. If a user is taking on a new role in addition to their existing one (rather than instead of) then a new composite role must be requested via change management. Due consideration of any issues of segregation of duties must be given.
Under no circumstances will administrators be permitted to change their own user accounts or permissions.
7.1.3 Management of privileged access rights
Privileged access rights such as those associated with administrator-level accounts must be identified for each system or network and tightly controlled. In general, technical users (such as IT support staff) will not make day to day use of user accounts with privileged access, rather a separate “admin” user account must be created and used only when the additional privileges are required. These accounts must be specific to an individual, for example “Pretesh Biswas Admin”; generic admin accounts must not be used as they provide insufficient identification of the user. Access to admin level permissions must only be allocated to individuals whose roles require them and who have received enough training to understand the implications of their use. The use of user accounts with privileged access in automated routines such as batch or interface jobs must be avoided where possible. Where this is unavoidable the password used must be protected and changed on a regular basis.
7.1.4 User authentication for external connections
In line with the Network Security Policy the use of modems on 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 Service Desk] 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 Service Desk]. 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 unauthorised access from the Internet. For further information please refer to the Mobile Device Policy and Remote Working Policy.
7.1.5 Supplier remote access to the organization network
Partner agencies or 3rd party suppliers must not be given details of how to access the organization’s network without permission from the [IT Service Desk]. Any changes to supplier’s connections (for example on termination of a contract) must be immediately sent to the [IT Service Desk] so that access can be updated or ceased. All permissions and access methods must be controlled by the [IT Service Desk]. Partners or 3rd party suppliers must contact the [IT Service Desk] 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.
7.1.6 Review of user access rights
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 [Information Security Manager] on a quarterly basis to ensure that this policy is being complied with.
7.2 User Registration
A request for access to the Organization’s computer systems must first be submitted to the [Name a department – e.g. Information Services Helpdesk] for approval. Applications for access must only be submitted if approval has been gained from [Name a role – e.g. your line manager].
When an employee leaves the organization, 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 [Name a role – e.g. your line manager] to request the suspension of the access rights via the [Name a department – e.g. Information Services Helpdesk].
7.3 User Responsibilities
It is a user’s responsibility to prevent their userID and password is used to gain unauthorized access to Organization systems by:
- Following the Password Policy Statements outlined above in Section 6.
- Ensuring that any PC they are using that is left unattended is locked or logged out.
- Leaving nothing on display that may contain access information such as login names and passwords.
- Informing [Name a department – e.g. Information Services Helpdesk – and any relevant roles] of any changes to their role and access requirements.
7.4 Network Access Control
The use of modems on non-Organization-owned PCs connected to the Organization’s network can seriously compromise the security of the network. The normal operation of the network must not be interfered with. Specific approval must be obtained from [Name a department – e.g. Information Services] before connecting any equipment to the Organization’s network.
7.5 User Authentication for External Connections
Where remote access to the [Organization Name] network is required, an application must be made via the [Name a department – e.g. IT Helpdesk]. Remote access to the network must be secured by two-factor authentication consisting of a username and one other component, for example, a [Name a relevant authentication token]. For further information please refer to [name a relevant policy -likely to be Remote Working Policy].
7.6 Supplier’s Remote Access to the Organization Network
Partner agencies or 3rd party suppliers must not be given details of how to access the Organization’s network without permission from [Name a department – e.g. IT Helpdesk]. Any changes to supplier’s connections must be immediately sent to the [Name a department – e.g. IT Helpdesk] so that access can be updated or ceased. All permissions and access methods must be controlled by [Name a department – e.g. IT Helpdesk].
Partners or 3rd party suppliers must contact the [Name a department – e.g. IT Helpdesk] before connecting to the [Organization Name] network and a log of activity must be maintained. Remote access software must be disabled when not in use.
7.7 Operating System Access Control
Access to operating systems is controlled by a secure login process. The access control defined in the User Access Management section (section 7.1) and the Password section (section 6) above must be applied. The login procedure must also be protected by:
- Not displaying any previous login information e.g. username.
- Limiting the number of unsuccessful attempts and locking the account, if exceeded.
- The password characters being hidden by symbols.
- Displaying a general warning notice that only authorized users are allowed.
All-access to operating systems is via a unique login id that will be audited and can be traced back to each individual user. The login id must not give any indication of the level of access that it provides to the system (e.g. administration rights). System administrators must have individual administrator accounts that will be logged and audited. The administrator account must not be used by individuals for normal day-to-day activities.
7.8 Application and Information Access
Access within software applications must be restricted using the security features built into the individual product. The [Name a department – e.g. IT Helpdesk or ‘business owner’] of the software application is responsible for granting access to the information within the system. The access must [amend the list as appropriate]:
- Be compliant with the User Access Management section (section 7.1) and the Password section (section 6) above.
- Be separated into clearly defined roles.
- Give the appropriate level of access required for the role of the user.
- Be unable to be overridden (with the admin settings removed or hidden from the user).
- Be free from alteration by rights inherited from the operating system that could allow unauthorized higher levels of access.
- Be logged and auditable.
8 Policy Compliance
If any user is found to have breached this policy, they may be subject to [Organization Name’s] disciplinary procedure. If a criminal offense is considered to have been committed further action may be taken to assist in the prosecution of the offender(s). If you do not understand the implications of this policy or how it may apply to you, seek advice from [name appropriate department].
9 Policy Governance
The following table identifies who within [Organization Name] is Accountable, Responsible, Informed, or Consulted with regards to this policy. The following definitions apply:
- Responsible – the person(s) responsible for developing and implementing the policy.
- Accountable – the person who has ultimate accountability and authority for the policy.
- Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.
- Informed – the person(s) or groups to be informed after policy implementation or amendment.
Responsible [Insert appropriate Job Title – e.g. Head of Information Services, Head of Human Resources, etc.]
Accountable [Insert appropriate Job Title – e.g. Section 151 Officer, Director of Finance, etc. It is important that only one role is held accountable.]
Consulted [Insert appropriate Job Title, Department or Group – e.g. Policy Department, Employee Panels, Unions, etc.]
Informed [Insert appropriate Job Title, Department or Group – e.g. All Organization Employees, All Temporary Staff, All Contractors, etc.]
10 Review and Revision
This policy will be reviewed as it is deemed appropriate, but no less frequently than every 12 months. The policy review will be undertaken by [Name an appropriate role].
11 References
The following XXX policy documents are directly relevant to this policy, and are referenced within this document [amend the list as appropriate]:
The following XXX policy documents are indirectly relevant to this policy [amend the list as appropriate]:
- Email Policy.
- Internet Acceptable Usage Policy.
- Software Policy.
- GCSx Acceptable Usage Policy and Personal Commitment Statement.
- Legal Responsibilities Policy.
- Computer, Telephone, and Desk Use Policy.
- Removable Media Policy.
- Information Protection Policy.
- Human Resources Information Security Standards.
- Information Security Incident Management Policy.
- IT Infrastructure Policy.
- Communications and Operation Management Policy.
12 Key Messages
- All users must use strong passwords.
- Passwords must be protected at all times and must be changed at least every 90 days.
- User access rights must be reviewed at regular intervals.
- It is a user’s responsibility to prevent their userID and password is being used to gain unauthorized access to Organization systems.
- Partner agencies or 3rd party suppliers must not be given details of how to access the Organization’s network without permission from [Name a department – e.g. IT Helpdesk].
- Partners or 3rd party suppliers must contact the [Name a department – e.g. IT Helpdesk] before connecting to the [Organization Name] network.
If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.
