Information Security Toolkit - Guidance

5.1. Access Control Policies

Local access control policies will define who is allowed access to which physical locations and logical resources. This could refer to individuals but more likely will refer to specific roles and/or user groups. There needn't be one single, over-arching access control policy and it is, perhaps, more likely that access control policies will refer to specific locations/resources. For example you may have a data centre/machine room policy which only authorises access to system administrators or a policy that only allows members of a particular committee, access to the minutes of their meetings.

However you should ensure that there is some form of policy for all resources (even if it just means that access is allowed to anyone). For computing systems, information systems and peripherals the default policy should be that access is not allowed and any policies should explicitly allow access to particular users/groups/roles.

How often access controls should be reviewed will depend on the specific resource. Access to confidential information, for example should be reviewed on a more regular basis (perhaps once a month) than access to public areas (which may be reviewed annually). Any access control policies should be reviewed whenever there are significant changes such as changing roles or staff/students leaving/arriving.

5.2. Identification and Authentication

Robust identification and authentication means that the methods of identification and authentication should be sufficient to be able to trace any misuse/abuse of systems to an individual user. Identification of users requires sufficient steps to be taken to ensure a claimed identity is genuine. Many identification and authentication systems will therefore be based on the users University card, including a user's Single Sign On (SSO) username. Users must not share access to their SSO account and where group access is required, project accounts can be considered. Similarly, where access is required to another user's mailbox, access should be delegated via Nexus. SSO/Nexus passwords must not be shared.

A number of authentication methods could be used, the most common being a username and password. Secure logon controls should include not sending passwords in clear text and may include controls such as limiting the number of logon attempts (bearing in mind the potential for denial of service) and/or sending warnings to system administrators when thresholds are reached. When implementing authentication solutions provisions should be made for keyloggers and, for critical systems, further authentication methods should be considered e.g. two factor authentication. The University can provide two-factor authentication using one-time-passwords via SMS for particular services where necessary.

5.3. Remote Access

For remote access the level of authentication should be appropriate with the identified risk. In many cases, Webauth or the University's central VPN service will be acceptable. However, for access to information of a sensitive or confidential nature more specific access control systems may be appropriate. In such circumstances specific access control policies should be in place to define who is allowed access, from where, and how copies of the data will be controlled. The Classification of Information Guidelines should be followed for further advice. University remote access accounts must not be shared. Users are responsible for any misuse of their remote access account including accidental misuse (e.g. leaving yourself logged in). Common occurrences of such misuse include copyright infringement, malware and access to libraries and resources. All of the above will lead to remote access accounts being disabled and users will be held accountable for the use of their own account.

Appropriately secure network connections will usually mean that any data transfer is encrypted. Typically this will be done via SSL or IPSEC. Further advice may be sought from OxCERT.

5.4. Length of sessions

The length of sessions needs to be a balance between usability and security. For devices that are publicly available, or when allowing access to sensitive or confidential resources, sessions should be timed out sooner than devices in private office areas. SSO sessions typically last 10 hours, so this should be taken into consideration when deciding if this is an appropriate means of authentication. Of course other means can be taken to mitigate the risk which can include human factors such as putting up reminder signs in public areas or having (for example) help centre staff routinely patrol for inactive but open sessions.

5.5. Multi-user systems

For some systems it may not be appropriate and/or trivial to individually authenticate every single user. Typical examples include public kiosk machines in a help centre environment. The risk here is that such systems could be misused in such a way as to damage the reputation of the unit/University, break the law, or be compromised by (for example) key-loggers which may harvest user information. Therefore where it is not possible/appropriate to authenticate every user, a specific risk assessment must be carried out and other steps taken to mitigate the risk. Often this will include reducing the chance of abuse by locking down the system and only allowing access to specific resources. However other means of monitoring or authentication could be implemented such as CCTV or logging of user access to public areas.

5.6. Authentication of network devices and other equipment

Individual devices should be authenticated on the network so as to prevent unauthorised use and ensure all equipment is permitted to connect to the network. Examples would include 802.1X or MAC address registration.

5.7. Access for system administrators

Access to diagnostic, remote management ports and other similar services should be restricted to only authorised users, and the level of restriction should reflect the importance of the service. Scanning of remote access ports such as SSH is extremely common so access should be restricted as far as possible without adverse affects on availability.

5.8. Password Management

Password management systems should be designed so as to maintain accountability. Good practice advice might include allowing users to choose passwords, enforcing quality, preventing password re-use and protecting passwords in transit and in storage. Users should be advised to use passwords on personal machines that will be connecting to the University network as the responsibility for misuse of their machine lies with them.