Information Security Toolkit - Guidance

1.1. Internal Organisation

Units should have their own information security policy in place. The security policy could be part of an existing policy framework or a policy in its own right. However it should describe the information security objectives for the unit, and demonstrate the commitment, at a senior level within the unit, towards achieving those objectives. Of course, the unit may simply adopt the University's Information Security policy and sub-policies as their own. However it may be appropriate for the unit to amend, add specifics to, or create their own policy from scratch.

The unit's information security policy should be brought to the attention of, and made available to, all staff, students, third parties and other persons who may interact with the unit's and/or University's information systems. There should be an auditable process in order to demonstrate that all users are made aware of the security policies, and are reminded of them on a regular basis. This could include, for example, including reference to the policies in user registration processes etc. Reminding users of the policies once a year, or when significant changes occur, would likely be considered reasonable.

The information security policy should also describe the structure for managing information security within the unit. Normally the management of security will be included with the management of ICT and such frameworks usually exist already, consisting of a departmental/college IT committee or equivalent, chaired by a senior member of the college/department. For smaller departments this may be subsumed within a structure organised at a divisional or faculty level, though final responsibility rests with the Head of Department or unit.

All users within the unit have responsibilities for information security and the Head of Department, College, Hall or other administrative unit is ultimately responsible for ensuring that users are aware of those responsibilities. Responsibilities will vary and will include responsibilities for configuring and maintaining ICT systems (usually assigned to registered IT support staff) down to the responsibilities of all end users (e.g. not to disclose passwords or allow unauthorised use of systems or accounts etc.). When handling information classified as confidential or sensitive, users should be explicitly made aware of their responsibilities for that particular dataset (e.g. not copying to personal computers, storing unencrypted etc.). All users have a responsibility to report any breaches of information security policies.

The ICT/information security policies should be reviewed at least once a year. There should be means of demonstrating that the policy has been reviewed (e.g. minutes of meeting at which it was discussed). Policies should also be reviewed in the event of significant changes or in the event of security breaches.

1.2. External Parties

Whenever third parties are dealt with, the security requirements of the University/unit, must be brought to the attention of the relevant party and be included in any contract. Security requirements of third parties should also be included in any such agreements and/or contracts from the outset. In particular, such agreements should clearly state the roles and responsibilities for specific aspects of security including, for example, applying security updates, auditing systems, monitoring logs. Responsibilities for incident response should also be included from the beginning and all third parties should be made aware of the requirements of the unit and OxCERT for dealing with incidents (e.g. maintaining appropriate logs to be able to trace any misuse). This should explicitly include notification of any security breaches that the third party becomes aware of.

Back to best practices

2.1. Roles and Responsibilities

Roles and responsibilities should include the requirement to implement and act in accordance with the information security policies and should be defined and clearly communicated during the pre-employment process. Security roles and responsibilities can be included in job definitions and/or contracts. A code of conduct or acceptable use policy may also be used to cover the responsibilities of staff, students, contractors, conference guests or others. Where appropriate, verification checks on applicants for new positions should be carried out before interview including, for example, character references. For positions that will allow access to sensitive or confidential information, further background checks and vetting may be appropriate.

2.2. Agreement to abide by the policies

All parties should sign up to the University's policies before being granted access to services. Sign up can be done as a link to terms and conditions when registering for an account, or could also be done via physical means such as inclusion in contracts of employment. It is important however to be able to demonstrate that users actively agree to abide by the policies. Similarly, means should be in place which can clearly demonstrate that all users are reminded of the policies on a regular basis. On average once a year should suffice or when any significant changes occur. For groups who have short term access to information systems (e.g. contractors) more frequent reminders may be appropriate. Regular reminders could simply be via communications such as email, or may be an interactive process as part, for example, of renewing user accounts and/or changing passwords.

2.3. Awareness, Education and Training

Awareness, education and training should be suitable and relevant to the person's role, responsibilities and skill. They should include information on known threats, who to contact for further security advice and the proper channels for reporting information security incidents. Awareness training should commence with a formal induction process designed to introduce the unit's and University policies and expectations before access to information services is granted. For registered IT support staff, ITS3 at OUCS provide inductions on a regular basis which include briefs on incident handling from OxCERT. However all staff should be made aware of their own responsibilities for the secure handling of information.

Training might include areas such as security requirements for particular dataset and/or units, legal responsibilities as well as training on technical controls that can be put in place. However it is vital (particularly when handling information classed as sensitive or confidential ) that the limitations of technical controls are widely communicated and that social and personnel controls are not overlooked. For example, when data is to be protected by encryption, all staff having authorised access to the data, must be made explicitly aware of the requirements for handling the data (e.g. copies of the data must not be made onto personal devices etc.).

Disciplinary processes can be used as a deterrent but should also ensure fair and correct treatment for users who are suspected of committing a breach of security, taking into account first offences, level of skill, training etc. In serious cases process should allow for instant removal of duties, access rights and privileges.

3.1. Training

It only takes a single lapse in order to place the University's or unit's data and resources at risk. Therefore all staff who are managing ICT systems should be trained and qualified as appropriate to their role. This should include making staff aware of their roles and responsibilities when it comes to information security. Information security training should be included as part of staff inductions and be ongoing as relevant to their role. In particular, security training and awareness should include:

• Awareness of the risks to information
• How to prevent the compromise and/or accidental disclosure of sensitive information
• The need to be aware of the latest threats and vulnerabilities
• Maintenance, monitoring and auditing of log files
• Security testing
• How to report security incidents
• Security incident handling and business continuity
• Legal compliance

Records of staff training should be kept and training needs should be reviewed on a regular basis to demonstrate that staff are trained as appropriate to their role.

OUCS offer inductions for new IT support staff which includes security incident handling within Oxford University and ITS3 continue to offer a range of training courses. For more details, or to request courses in a particular field, please contact ITS3.

JANET also offer a number of courses in the field of information security. For more details please see: JANET training Courses.

Not all system owners/administrators will necessarily be registered IT support staff however, where this is the case, system owners/administrators should be made aware of their responsibilities towards information security and should be made explicitly aware of ICT regulations and policies.

3.2. Documentation

Having documented procedures in place can help ensure sensitive data is processed in a secure and efficient manner. It also provides a means to ensure that best practice is being followed by all staff (not just IT staff), and that the availability and integrity of ICT systems is maintained.

Effective documentation of operating procedures can save duplication of effort and facilitate the most efficient use of ICT systems and staff time. Failure to maintain appropriate documentation can lead to operational shortcuts, increased system downtime, processing errors, problems with auditing and difficulties in training new staff.

All documentation should be reviewed at regular intervals and updated when any changes in operating procedures are made. It is important to ensure that documentation is made available to all users who need it. Thought should therefore be given to how to control access to documentation and under which circumstances access to documentation will be required (e.g. in disaster recovery and/or business continuity situations). For example you may consider keeping multiple copies (including hard copies) of important documentation.

Access to documentation should only be given to those that require it and controls should be implemented to ensure that any changes to documentation happen in a controlled and authorised manner.

The following should be considered when creating and maintaining documentation:

Network connectivity

• Means used to connect to networks
• IP address, netmask and routing information
• Any authorised/unauthorised network access
• Means and methods for remote access
• Network services that should/shouldn't be enabled
• Switchports and patching information
• Cabling requirements and organisation
• Local firewall implementations

Computer operations

• Startup and shutdown procedures
• Operating system details
• Backups
• Inter-system dependencies
• Scheduled tasks
• User and administrator accounts
• Running processes and services

Error/Incident Handling

• System recovery procedures
• Support contact information

Audit trails and system logs

• Required levels of logging
• Required system events, access logs and errors
• Required logging of system usage
• Logging policies including log rotation and deletion

System capacity

• Disk capacity
• File systems
• Processing power
• Networking capabilities

Software and services

• Installation and removing of software
• Software Updates
• Software auditing
• Configuration management

Change control

• Procedures for making and controlling changes in configuration
• Planning, testing and acceptance of changes
• Rolling back changes

3.3. Backups

Backups of data are primarily to maintain availability of information. \ Threats to availability include accidental/deliberate damage, loss and theft. It is therefore the responsibility of information asset owners to ensure that all information is backed up appropriately and that processes for restoring data are thoroughly tested to ensure successful system recovery. Backup policies should reflect the level of information that it is necessary to backup and how frequently backups should be made. This will depend largely on the importance of the information to the unit/University and the frequency with which the information is changed/updated. Such factors will also determine whether it is appropriate to take full backups or differential/incremental backups.

3.4. Monitoring and Logging

Information on the extent to which the University may monitor the use of its ICT systems can be found within the Regulations Relating to the use of Information Technology Facilities. All personnel, and IT staff in particular, must ensure they comply with these regulations.

Other than that, the level of monitoring for individual systems should be appropriate as determined by an assessment of the risk. It is, however, imperative that the source of any abusive or malicious network traffic can easily be traced and isolated. This may be a requirement to trace the end user and/or computer responsible. All units should therefore follow OxCERT's guidance on logging, especially where NAT, routed networks and/or multi-users systems are used. All logs must be associated with an accurate time source. If units do not want to run their own NTP service then OUCS offer a central NTP service.

3.5. Administrator Privileges

Administrator privileges should be restricted as far as possible as inappropriate system privileges can be a major contributory factor in system failure and security breaches.

This should be appropriate to the use of the system and, for ICT systems managed by the unit, should include authorised personnel only (usually ICT staff). Best practice advice only allows access with the minimum privileges necessary for the task in hand. It is advisable that all unit/University owned computers (desktops and laptops) should have a designated administrator who is responsible for that machine. The designated administrator could be a group or individual and would be responsible for that machine. They will, for example, have the ability to create user accounts, assign privileges, configure the machine, install and remove software and apply security related updates etc. Where other users need access to that machine, the administrator would be responsible for assigning the appropriate privileges to them.

For personally owned machines, it is likely that the owner will also be the system administrator. In these circumstances, users should be made fully aware of the ICT Regulations, the Information Security Policies and any local acceptable use policy. All system administrators should be made aware of their security responsibilities, particularly in relation to security incidents. For example, where personally owned machines are concerned, failing to allow local IT support staff to inspect machines, or unwillingness to re-install the operating system, can severely hamper, or even prevent entirely, incident resolution.

3.6. Malicious Code

Malicious code includes malicious software such as viruses, worms, trojans etc. Commonly the term malware is used to describe all malicious software. Malicious code, however, can also be taken to include remote and/or mobile code that could be executed to exploit some vulnerability in a local system. This includes the likes of cross-site-scripting (XSS) attacks, SQL (or other code) injection attacks and buffer overflow attacks. In fact, any attack which includes the unauthorised running of code on a computer can be counted as malicious code for the purposes of this policy and toolkit.

Protection against malicious code should be appropriate and based on an assessment of the risks to individual systems and to the University as a whole. Thought should be given to the emphasis which should be placed on prevention, detection and recovery. What is appropriate for one system may be different for others but the decision should be justifiable and based on the risk assessment. For example, where information systems process personal, sensitive or confidential information, priority may be given to prevention. On the other hand, it may be deemed an acceptable risk to have a machine compromised if detection and recovery processes are robust and the risk of disclosure of information is considered low. Similarly, desktop machines will be treated differently to servers as the impact of certain actions will be different. It is, however, important to fully understand the risks.

3.7. Malicious Code: Risk

Nowadays, malicious code is typically used to gain unauthorised access to systems and/or resources. For example, this could be installing a key-logger to record passwords which will be used in further attacks or the remote execution of code in order to gain full control over systems. Most commonly, those behind propagation of malware are motivated by money. Therefore it is in their interest for the malware to be stealthy and go undetected. Recently, much has been made in the news about advanced persistent threats and malware being used for espionage at a national level. Given the sensitivity of certain research, for example, it is not beyond the realms of possibility that the University of Oxford and/or certain high profile/senior members could be a victim of targeted attacks.

The risks associated with malicious code are therefore numerous. Whilst the obvious risks may be those surrounding the unauthorised disclosure of sensitive data, the following lists just some of the risks associated with malicious code:

Unauthorised disclosure of sensitive information leading to:

• Risk to the safety and well being of individuals
• Reputational damage
• Loss of important research bids/contracts
• Direct financial loss (for example fines from the Information Commissioner)
• Legal action undertaken against the University or a college
• Further abuse of resources (e.g. compromised accounts being used for spam runs)
• Denial of service to legitimate users
• Deletion, modification or corruption of data
• Disciplinary action

Loss of availability via deliberate denial of service or, for example, network blocks placed by OxCERT:

• Reputational damage for the University and/or local unit
• Dissatisfied users
• Loss of productivity and potential income
• Unhappy management

Unauthorised access to further resources and loss of integrity

• Even if no sensitive information is processed directly, systems could be defaced or used as a "stepping-stone" to access further resources that may have a greater impact (e.g. resources behind a firewall)

3.8. Malicious Code: Controls

The chosen controls should be based on the identified risks. The controls should be proportionate, and the cost of implementation should not outweigh the cost of 'doing nothing'. Appropriate controls will also depend on the nature of the system e.g. whether it is a personal laptop/desktop, university/unit owned or server.

4.1. Firewalls and Routing

The unit is responsible for all connections on the unit's side of the FRODO box. The University does not operate an organisational level firewall at the JANET link. Whilst a small number of ports are blocked inbound by router access control lists, this should NOT be seen as sufficient protection for individual units. Instead the backbone network should be treated like the Internet and each unit should have their own means of controlling traffic to and from their network. Usually this would mean operating a unit level firewall and/or a series of firewalls at strategic locations in order to prevent unauthorised network traffic. Where units do not operate a firewall there should be documented justification for this decision and, where appropriate, alternative controls should be put in place. This could include, for example, switch or router access control lists. Firewalls or other devices for restricting information flows should be based on source and destination address checking mechanisms.

Any firewall rulesets (or other means of access control) should be in line with an agreed access control policy. A good starting point would be to opt for a default deny inbound policy and a default allow outbound, however there may be good reasons for choosing other policies. Whatever the setup, only authorised traffic should be allowed to traverse the network and so it is advised that access is restricted to being only from necessary locations and only to necessary services. For example, where remote access is required (e.g. SSH or Remote Desktop), this could be restricted to a known set of IP addresses such as a static or VPN range. Only access to the necessary ports should be allowed and it may be worth considering the use of non-standard ports, if appropriate.

Firewall rules and other access control lists should be checked at regular intervals to ensure they are behaving as expected. This could be done on a monthly basis and should always be done when significant changes are made to the configuration. Units should have some procedures in place to ensure that changes to firewall configurations are controlled and rulesets should always be checked after config changes or troubleshooting. A full record of any changes should be maintained.

4.2. Network Administration

Network management and control should ensure the security of information in networks and the protection of connected services from unauthorised access. Responsibilities for network management should therefore be clearly assigned and all networks should be managed by suitably qualified and experienced staff. This is in order to avoid costly errors, inappropriate access to network devices (e.g. from non IT support staff) and/or slow responses to fixing problems which may have an impact on the unit and/or University as a whole. ITS3 at OUCS can help to organise appropriate training courses.

A list of services available to Network Administrators can be found within the OxCERT webpages. This includes any chargeable services. NSMS do also offer a chargeable network management service details of which can be found at: NSMS network management service.

4.3. Network Services

Any network services and their security requirements should be clearly identified. Such services might include the provision of connections, private network services and managed security solutions such as firewalls and intrusion detection systems. Security features of services could be technology such as authentication, encryption etc. or procedures to restrict access to services or applications.

4.4. Segregation

Where possible network traffic should be appropriately segregated with routing and access controls between the domains. This could include, for example, separating traffic on untrusted, "public" networks, from that of staff and students. Thought may also be given to segregating critical assets where the loss or compromise of that asset would have a big impact on the operation of the unit. DMZs could be used, for example, to protect access to major services such as mail servers, web servers or domain controllers. Consideration should also be given to the segregation of wireless networks from internal and private networks.

4.5. Physical Security and Integrity

Appropriate physical security for network cabling will depend on the physical environment and the sensitivity of any data being transferred. Particular attention should be paid to cabling which is exposed in public areas or exposed to the physical elements. For example, cabling and other network equipment may be at risk of flooding in parts of Oxford and appropriate controls should be implemented to mitigate the risk. Where particular network links carry sensitive data, or where availability is a key priority, protection should be implemented to protect from interception or accidental damage.

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.

6.1. Authentication and Authorisation

There should be authentication and authorisation procedures in place to ensure users are only allowed to access services which are intended for them. Specifically for systems using techniques such as Single Sign On, controls should be in place to ensure that creating an account does not allow users access to services for which they are not authorised to use. It is also particularly important to ensure that the same password (or similar) should not be used to login to systems that are supposed to be kept secure. This applies especially to those systems that may contain sensitive personal information.

The following ruling from the Information Commissioner demonstrates that this could be considered a breach of the Data Protection Act 1998: Hampshire school breached data protection rules.

6.2. Registration and De-registration

Registration and de-registration procedures should ensure that users are assigned unique IDs so accountability can be maintained and records should be kept of all registered users. All users should sign up to a conditions of use/access when they are assigned an account. There should also be means to remind users of such terms on a regular basis and ensure they are aware of any changes. Systems should be audited for unwanted/redundant accounts on a regular basis. When users leave access should be revoked and the user de-registered.

Inappropriate system privileges can be a major contributory factor in system failure and security breaches so, where possible, privileges should be kept to the minimum necessary and suitable permissions should be defined. In signing up to a conditions of use, users should be made aware of their own responsibilities.

6.3. Passwords and Unauthorised Access

Passwords should not be shared between users and it should be noted that sharing of University passwords such as SSO credentials is explicitly forbidden by the University ICT regulations. This includes giving out your password to IT support staff, OUCS or any other University department. OUCS will NEVER ask users for their passwords and so ANY correspondence (email, phone calls etc.) asking for such details should be treated with caution. Unfortunately, phishing scams are rife these days and users do fall for them. For more details on recognising fake emails please see How To Recognise Fake Emails.

In order to make life simpler when users leave or are temporarily away, role based accounts and access could be considered. Where shared access to accounts is needed other means should be implemented. Project accounts, for example can be set up for clubs and societies (see Registration for more details on different types of accounts) and, within Nexus, access to email accounts can be delegated so there is no need to share passwords (see Delegating access to email, calendar and other Nexus features using Outlook 2007). If passwords need to be written down, this should be done so in as secure a manner as possible. Password management tools can be useful in order to help keep multiple passwords stored in a secure manner. This can be particularly useful for users who have many passwords to remember. It is important to be aware of the fact that where password exposures are known about, user accounts will be temporarily disabled. This can cause significant disruption to users who need access to critical services. It is therefore imperative that all users are made aware of their responsibilities towards password security, and of the consequences of breaching these policies. More information on University passwords and guides to password security can be found at Registration.

Users may also be advised to protect against unauthorised access to their own machines, accounts and private information. Obviously this will depend on the specific environment. However some examples could include simply locking office doors, password protected screen locks (e.g. where locking doors isn't possible or offices are shared), logging out of sessions on public machines, and clear desk policies.

6.4. Visitor Accounts

Visitor accounts should be specifically issued and the same University policies and practices (traceability, incident response etc.) are applicable to visitor accounts. The University has two services available for visitors which are Eduroam and OWL-Visitor. For more information on these services please see OUCS and efficient IT. Where individual units wish to provide their own network access for visitors, this should be provided using their own specific IP address space which is segregated from other networks within the unit. It is also important to be able to trace any abuse or misuse coming from such areas. Therefore authentication should be considered. In some circumstances this may be difficult or not desirable. In this case the risks should be assessed and, for example, controls put in place to prevent abuse/misuse in the first place. For example, it may be deemed an acceptable risk to have unauthenticated access to specifically assigned networks if physical access is controlled, physical monitoring is in place, network access is allowed only to specific known good destinations etc.

7.1. University Guidance

7.2. Asset Management

7.3. Risk Assessment

Information security and the management thereof essentially comes down to managing risk. Throughout the University's information security policies and this accompanying toolkit "appropriate" or "suitable" controls are referred to continuously. It is risk assessment that allows us to determine what level of control is appropriate and, perhaps more importantly, allows us to demonstrably justify the decisions we have taken. If there is no risk assessment, then culpability for security incidents is likely to lay firmly at the door of the asset owner. However the process need not be complicated, costly or even formal. The level of risk assessment required will depend on the security requirements of the unit, legal and regulatory requirements and the nature and criticality of the asset needing protection. What is essential, however, is that it is possible show that the decisions made in implementing controls can be justified and considered reasonable.

Risk is the potential for an unwanted event to have a negative impact as a result of exploiting a weakness. It can be seen as a function of the value of the asset, threats and vulnerabilities:

Risk = Asset value * Threat * Vulnerability

Risk management is the reduction of identified risk to an acceptable level. Risk management therefore involves an assessment of the relevant risks followed by the appropriate treatment of the identified risks.

7.4. Backups

See Backup Section

7.5. Media Handling

7.6. Exchange of Information

7.7. Guidelines for the use of Cryptographic Controls

7.8. System Planning and Acceptance

Introducing new ICT systems clearly introduces new risks. The primary concerns are likely to be risks to the existing infrastructure as a result of the change (e.g. a compromised system being used to access further restricted systems) and the risk to the information processed by the new system. For more information see the risk assessment section within the toolkit.

The following lists advice on specific factors to take into consideration with respect to introducing new ICT systems:

8.1. Secure Areas

Secure areas could be anything from a building or collection of buildings down to individual rooms or even particular devices. Defining "security perimeters" therefore means ensuring all personnel are aware of who is authorised to access the area and who is not. This is usually done using signs such as "staff only" and in general communication of policies to all personnel. For example there may be a local policy to ensure that only system administrators as allowed access to machine rooms, whereas other "staff-only" areas may allow visitors to enter if they are signed in and wear appropriate identification.

In both cases however the policy should be clearly communicated to all staff/students and there should be signs and physical security controls (e.g. locked doors) in order to enforce the policy. All personnel should be made aware of who is authorised to access specific areas and should be encouraged to challenge and/or report any persons they come across who are suspected as being unauthorised. This may mean, particularly for large departments, ensuring that authorised personnel wear visible identification at all times. Of course in certain circumstances this may not be possible or deemed appropriate and this should be determined by an assessment of the risk.

Appropriate physical security controls will depend on the nature of the secure area being protected. For example a machine room may be classed as highly secure and require door locks, systems to record entry of individuals, CCTV and intruder detection. Alternatively areas accessible to University members only may simply require identification at the point of entry e.g. via a manned reception or card-swipe entry system. It may also be considered to protect certain individual machines from theft or unauthorised physical access. This could be physically secured boxes or simply disabling external ports such as USB ports.

Appropriate physical security controls for offices will, again, depend on the specific environment and risk. However usually offices should be locked and only specifically authorised personnel given keys. All users should be made aware of who does have access to given office areas (e.g. cleaners, security staff) so that a judgement can be made as to how best to secure access to information within the office. For example, a clear desk policy may be desirable or a policy to keep sensitive information in locked drawers or safes. Using password protected screens or logging out of/switching off computers when leaving an office for a significant period should usually be encouraged as these are fairly cheap controls that will provide some mitigation against casual, opportunist or accidental breaches of data. In certain areas (e.g. open plan offices) screen locking etc. may be particularly relevant.

8.2. Physical and Environmental Security

The risk of natural or man-made disasters such as fires or floods should also be assessed before deciding where to site equipment, particularly if it is critical to the operation of the unit/University. The frequency of flooding in the past, for example, can be used to help with such risks assessments. Where the risk is substantial, appropriate protection should be offered. This could be providing other, failover systems to introduce redundancy, physical protection, or deciding on alternative locations. Systems should also have proper ventilation if in areas that reach high temperatures such as switches in lofts or offices that get especially hot during the summer season. Adequate fans on systems in these situations are essential, including periodic reviews to ensure.

Uninterruptable Power Supply (UPS) should be used for systems that require high availability, such as for core infrastructure including file servers and network equipment to protect them from failures in supporting utilities. Power line surge protection equipment should be used where UPS is not used, as these can help protect systems from damage from power irregularities. Redundant power supplies for critical systems should be considered to reduce the risk of downtime should a power supply fail, and can also provide ease of system power management such as connecting to a different UPS without causing system downtime.

Locations of power and network cables should documented and installed, where possible, along areas less likely to be affected by future construction projects, normal traffic by people or vehicles, heavy runoffs from roads and grit/snow removal equipment. As with systems, cables providing infrastructure support should not be exposed and accessible to passer-by's, especially not in public areas. Installing cabling within walls, ceilings, or within covered trunking and out of easy reach can help reduce tampering and the possibility of intercepted network traffic or loss of service. Power and network port monitoring can be used to alert appropriate personnel if there is a change of state to any connected cables, providing a means of detecting any unauthorized interception or disconnection attempts.

Critical infrastructure equipment should have emergency contact details on it so the appropriate personnel are notified in the event of damage to the equipment or surrounding environment.

8.3. Off-site Equipment and Disposal

It is important that authorisation is received before taking equipment or information off-site. Such authorisation should be gained via the information asset owner and/or a line manager. The specific terms and conditions with which the information/equipment can be used off-site should be explicitly defined. For example, it may be strictly forbidden to make copies of certain data, use software on personal machines or allow others to use specific equipment. It may also be a condition to keep any portable devices such as USB sticks in locked rooms, drawers or cases to prevent accidental loss or theft. The use of encryption should be considered in addition when taking data off-site - see the Cryptographic Controls section of the toolkit.

Procedures should exist to ensure that any sensitive data and licensed software have been removed or securely overwritten when equipment is sold on, transferred or scrapped, as described in Media Handling - Disposal Procedures.

10.1. Incorporating Disaster Recovery Plans

Business continuity plans incorporate, but are not the same thing as, disaster recovery plans. Disaster recovery plans tend to include documentation for the restoration of systems, treating each system equally. Business continuity plans however include risk assessment and the option to mitigate those risks. They also include prioritisation of services and systems based on the criticality to the unit/University. Business continuity can therefore focus on prevention as much as on recovery and is ultimately about keeping critical services running.

10.2. Critical Operational Processes

Key to business continuity is therefore the identification of critical operational processes. These should be the processes which the unit/University relies on more than any others in order to achieve its primary goals. The requirements for continuity should also be identified including for example identification of specific processes, systems, staff, materials, transport etc. required for the successful operation of the service. Requirements for continuity should also include acceptable time periods for which services may be unavailable. Doing this will help to prioritise systems/services and be useful in ascertaining the level of resource that should be provided for mitigating risks.

10.3. Risks

Risks to core services should then be evaluated. These can be varied and should include any event that would have a significant impact on the operation of those services. These could be technical risks such as system failures, physical disasters such as floods, fires, explosions or social/human issues such as pandemics etc. The business continuity management process should then include controls to reduce those risks whether by preventative or reactive means, and limit the consequences of damaging incidents. This may include, for example, suitable insurance or the implementation of additional preventive and mitigating controls (e.g. planning for a pandemic). One area that is often overlooked when considering business continuity is that of security breaches, as well as system failures, and the plans for each may be different. It is therefore imperative to have plans in place for the restoration of services following security breaches. These plans should take into consideration the requirements of the University, as laid out by OxCERT, for incident response (see Incident Handling).

10.4. Business Continuity Plans

Information, and all other assets, required for business processes should be readily available to those who need it in case of such events. However, it is important to consider that business continuity plans should identify high impact vulnerabilities in the unit and or University. Such plans will likely be treated as sensitive or confidential and should therefore be handled accordingly. Business continuity plans should also be accessible in the event of any disaster scenarios so thought should be given to storing plans securely in remote locations.

The overall business continuity framework within a unit/the University should ensure that all roles and responsibilities are clearly defined. Business/service owners should be responsible for business continuity plans and for ensuring that plans are maintained and kept up to date. Business continuity plans should therefore be reviewed and audited on a regular basis and/or when significant changes occur.

Business continuity plans should also be tested on a regular basis as appropriate. This could include numerous techniques including discussion of certain scenarios, simulations, disaster recovery testing or even complete rehearsals of major events.

11.1. Monitoring Compliance

The question is often asked as to how to enforce these policies and monitor compliance. Monitoring compliance is an exercise in information assurance and can be done in a number of ways (both internally and externally). It is difficult to prove compliance so it is therefore important to be able to detect breaches of policy. This may be via technical means such as monitoring logs and other intrusion detection techniques or by human means such as spot checks.

One clear way to monitor compliance is audit and this can be done internally or externally depending on requirements. Audits can be in the form of technical audits (penetration testing, vulnerability scans etc.) or audits of policies and processes. External audit will usually not be necessary as the cost may outweigh the benefit. However it can lead to a greater degree of assurance and certification. This may be required for certain high-risk systems or where it is a contractual requirement. Further advice on audit can be sought from OxCERT. There must be procedures in place so that incidents are reported upwards and senior managers receive appropriate reports.

11.2. Compliance with Data Protection and Privacy Laws

It is imperative, when handling personal or sensitive personal data, that the principles of the Data Protection Act 1998 are followed and, special care must be taken when data is to be transferred or stored outside of the European Economic Area. Full guidance and advice on compliance with data protection and privacy issues can be found on the University's Data Protection web pages.

11.3. Cryptographic Controls

It should be noted that the following is not legal advice. However there should be some awareness that there are certain legal issues that may affect certain policy decisions, and that may need to be dealt with via policies themselves. For example different countries have legal restrictions on the import, export and use of cryptographic technologies. Care should therefore be taken if travelling with cryptographic technology (e.g. laptops using whole disk encryption). One good source of information on this matter can be found on Professor Bert-Jaap Koops' web pages. For further advice please contact OxCERT.

Also relevant are the powers of law enforcement in the UK to require that decryption keys (or the relevant plaintext) should be presented under certain sections of the Regulation of Investigatory Powers Act (RIPA). Thought needs to be given to who would be responsible for providing keys and/or plaintext if such a request was made.