Access control control procedure

Contents

• Policy statement
• Audience
• Control statements
• Compliance
• Related documents

Policy statement

This control procedure defines our approach to access control and directly supports the following statement from the Information Security Policy:

“Access to all information will be controlled and will be driven by business requirements. Access will be granted or arrangements made for users according to their role, only to a level that will allow them to carry out their duties.”

“A formal user registration and de-registration procedure will be maintained for access to all information systems and services. This will include mandatory authentication methods based on the sensitivity of the information being accessed, and will include consideration of multiple factors as appropriate.”

“Specific controls will be implements for users with elevated privileges, to reduce the risk of negligent or deliberate system misuse. Segregation of duties will be implemented, where practical.”

Audience

This procedure is intended to be read and understood by all users of university IT systems.‌

Control statements

Access to University resources must be granted on a need-to-know basis. Access control must be implemented to grant the least privileges required to fulfil a role. Access must also be attributable to an individual. This applies to physical access, system and device level access and methods of authentication.

Appropriate access levels are defined and maintained by business owners, in consultation with Information Asset Owners.

• Authentication measures
• Multi factor authentication
• Account security
• User registration and deregistration
• Changes to access rights
• Privileged access
• Database access
• Remote access
• Secure access
• Data centre security

Authentication mechanisms

Any system or service in use at Man Met must utilise the Man Met identity provider service (IDP). 

We facilitate access to the university’s identity provider service via the SAML protocol utilising Azure Active Directory.  

The central university Active Directory (AD) system is the core authentication system and should be used by any service requiring user account authentication, including federating to non-AD or cloud services as appropriate. To maintain lists of who has access to systems, AD Groups (preferably autogroups) should be used to grant privileged access to systems or aspects of systems. 

We use Shibboleth – an industry-standard system based on SAML – to control third party authentication requests for some web-based services, primarily library services. 

Some legacy services use LDAP authentication to AD, however this is deprecated and should not be considered for new services.  

These systems are managed by IT & Digital. 

Where systems cannot use AD credentials, they will follow the same principles of need-to-know and least-privilege, but there must be an access control process ensuring that local ownership is taken for keeping access control lists up to date with staff and business changes. All systems that fall out of standard operating procedures should be discussed with the information security team. 

Multi factor authentication

The University requires the use of a second factor such as a mobile phone app to provide an authentication token (known as multi-factor authentication or MFA). This is designed to prevent stolen credentials being reused to access University systems and data.  

MFA is configured on a conditional policy basis for all accessible systems and services. The parameters of the conditional policy enforcement include but are not limited to; source asset, source location, target services/system, data classification and user type. 

This tiered approach to system access broadly reflects the classification of the information stored in those systems. The University reserves the right to increase the security controls required to access certain systems based on ongoing risk assessments.

Account security 

All Staff, Student and Guest accounts must be protected by Multi-Factor Authentication. This is applied via AD groups in Microsoft Azure AD. MFA is enforced on all systems or services processing university data. Any exceptions to this requirement need to be agreed and documented in line with the Information Security Exceptions control procedure.

The information security function reserves the right to amend the conditions for MFA in response to changes in threat level. 

User registration and deregistration

Human Resources provide an automated data feed to IT and Digital each day which provides details of all new staff joining the institution. Building access and IT access, including an individual email account will be automatically assigned by teams in IT and Digital and Estates based on this feed. The line manager of the new staff member will receive their login details by email from the IT Helpline. 

Human Resources provide an automated data feed to IT and Digital about staff leaving the institution based on contractual information from the HR system. Leaver accounts will be timestamped, which prompts a number of actions to allow the account to be closed down. If there is any confusion over whether a member of staff has left, this should be confirmed with HR before any action is taken. 

For security reasons, it is essential that accounts are not left accessible for longer than is necessary once a member of staff is no longer employed by the university. Accounts of leavers will be disabled on the day the contract expires and deleted 90 days later. IT administrator accounts will be disabled on the user’s last working day, even if this pre-dates the end of the contract. 

Guest accounts must be requested and authorised by a permanent manager. Requests for guest accounts must be requested via the IT Helpline.  All guest accounts will then be processed by IT and Digital with a defined end date which automatically triggers the closure of the account. Guest accounts are only provided for a specified time period and at most a period of 5 years.  

The university reserves the right to disable any account with immediate effect, for example where the user is subject to disciplinary action or there is a threat to the university or others. HR, legal and/or the Chief Information Security Officer or Deputy will confirm the need to disable an account. Accounts will be retained for as long as necessary in line with any on-going investigation. 

Student account creation follows the same principles, but information comes from the student record system. Students retain access to core systems for two years after your course end date.  

Changes to access rights

Changing of roles internally may require changes to access control privileges. As a change in role will result in a change in contract, the contract changes will be updated on the HR system, which then feeds directly to IT and Digital. Once a current contract ends, users are automatically removed from previous access groups and their new contract will attract the users new access rights. Any specific changes may need to be made manually on receipt of specific authorisation from a manager. 

Privileged access

The creation of user accounts with higher privileges such as administrators is controlled, and restricted to those users who have a clear business need to manage information systems or networks. 

Each administrator will be given a specific administrator account, which should only be used for system administrative purposes; otherwise, their standard user account should be used. Administrator accounts will not be given access to email, to mitigate the risk of malware spreading via privileged access. More complex passphrase management is required for administrator accounts as outlined in the password management control procedure. Access over the internet to accounts with system level privileges will use the university’s VPN and two factor authentication. No other systems should be used to allow privileged remote access to systems. 

Where structure and existing staffing allows, segregation of duties will be implemented, and administrators will be given the least access possible to allow them to complete administrative tasks. This will also assist with maintaining a clear audit trail of domain management and help to prevent catastrophic accidental changes being made to the domain by a single user. Full domain administrator accounts should only be used when there is no alternative, and their use should be documented and flagged to the information security team. 

Research academics may require local administrator privileges in order to undertake their roles. Access can be granted where the access request is supported by a short written statement explaining the need and is endorsed by the relevant Head of Service or line manager. When access is granted, research academics agree: 

• Not to use their admin rights to disable any protective software installed on their device (antivirus/firewall/automatic updates), or to delete (or prevent the creation of) log files. 
• Not to make any changes to software or the operating system that the university IT and Digital team previously installed. Any required changes should be discussed in advance of any action being taken.  
• Not to install software without carrying out due diligence on its origin, licensing and security. Any questions or concerns should be raised with the IT Helpline. 

Accounts used to run programs or batch jobs should be unique to each service. Each should have the description field appropriately completed and be set to ‘password never expires’. These accounts should be setup in Active Directory and passphrases recorded in an encrypted secure vault with an audit trail of access. These service accounts should only be used for automated logins and never used to login manually. 

Database access

Access to databases should be sufficiently granular to protect the need-to-know principle. Where possible, this should relate to AD groups. Where access control is specified by naming a user on the database access control list, this must be maintained by the service owner, this must also be auditable by information security. 

Remote Access

Remote access to University systems is detailed in a dedicated procedure, and includes the University’s approach to the use of  mobile device management, VPN and MFA. 

Secure areas

Secure areas must be protected by appropriate entry controls to ensure that only authorised personnel are allowed access. The following controls will be implemented to minimise risk: 

• access to areas where sensitive information is processed or stored will be restricted to people with a need to know only; 
• an access control card system will be used to authorise and validate access; line managers will have responsibility for approving access. Access is granted by Business Support; 
• an audit trail of all access will be maintained within Sateon. Logs are maintained in line with the university retention and disposal schedule; 
• visitors will be escorted by authorised personnel and only be allowed access for specific and authorised purposes; 
• all employees and authorised personnel must wear their ID card at all times whilst on campus, or be ready to present their card if challenged; 
• employees must notify security personnel when they encounter unescorted visitors or anyone not wearing visible identification; 
• external support personnel will be escorted whilst on campus by a member of university staff; 
• Information Asset Owners and Managers are responsible for regularly reviewing access rights. 

Data Centre Security

The Operations Team are responsible for the management of access control to the university data centre environments including sensitive data processing areas that may be subject to specific controls. 

The team will run regular reports providing details of access to these areas and will report any attempted or actual unauthorised access under the incident management procedure. 

Compliance

Failure to comply with this procedure could result in action in line with the university’s disciplinary or performance improvement procedure.

Compliance checks will be undertaken by the university’s information governance functions. The results of compliance checks, their risk assessment and their remediation will be managed by the Information Governance Board.

Related documents

This control procedure needs to be understood in the context of the other policies and procedures constituting the university’s Information Security Management System.

Browse Information Security policies and control procedures

Review

A review of this policy will be undertaken by the information security team annually or more frequently as required, and will be approved by the Information Governance Board.