3. Operations
This section of the toolkit adds further detail to the corresponding Operations sub-policy within the University's Information Security Policy.
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
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
Software and services
Change control
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.3.1. Storage
Backups should be stored in a suitable location so as to reflect the security requirements of the information. Usually the backup location should be a remote location or device kept separately from the original data to escape any damage/loss from the primary copy. What is appropriate will depend on the risk you are trying to mitigate. For example, backing up a laptop to a remote USB drive and storing the drive in the same location as the laptop, may mitigate the risk of a hardware failure, but not of theft of the device. It is also important to apply the same level of security controls to any backup copies of data, as it is to the original and, where confidentiality is a primary concern, backups should be protected by means of encryption. When backing up to remote devices consideration should also be given to the expected longevity of the media so as to protect the integrity of the backup for an appropriate period of time.
3.3.2. System Recovery
Restoration processes should be clearly defined, documented and regularly tested to ensure they are effective. Thought should be given to how long it will take to restore data in any given circumstance. For critical systems in particular, backup procedures should cover all systems information, applications and data necessary to recover the entire system in the event of a disaster.
3.3.3. Archiving
Archiving of information and documents must take place with due consideration for legal, regulatory and business issue. The policy for archiving information should be set by the unit that is responsible for that information.
3.3.4. HFS
For staff and postgraduate students, OUCS provide a central backup service for desktops, laptops and servers. For more detail please see http://www.oucs.ox.ac.uk/hfs/
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.4.1. Log File Management and Maintenance
Clearly, log file management is a balance between the amount of data collected and how useful this is. Sufficient logs should be collected to be able to identify the source of the problem without flooding log files with excessive data. Some key things that could be included in log files might include:
- Authorised access
- Privileged operations
- Unauthorised access attempts
- System alerts and failures
- Network traffic
Failure to provide sufficient logs can severely restrict investigations into any kind of problem and/or security incident. Inability to trace the source of problems is therefore one of the main reasons for delayed incident resolution. It is therefore vital to ensure that not only is the correct information being collected from the outset, but that the logs are available to those that need them and can be relied upon. Logs should therefore be periodically tested in order to ensure that the process is working as expected. It is important to bear in mind log retention and roll over periods. Thought should also be given as to how the integrity of the logs can be maintained. If a system is compromised, for example, it is likely that the logs will be tampered with by the attacker. Using a separate system, such as a central syslog server could therefore be considered.
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
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.
3.8.1. Desktops/Laptops
Malware that targets user machines can propagate in a number of ways including automatic network propagation (in the case of worms), email attachments, drive-by-downloads, infected portable devices such as USB sticks, trojaned software, social engineering (e.g. Fake AV malware) etc. The most common current attack vectors are probably code hidden in websites (drive-by downloads), email attachments and USB devices all of which are used to exploit vulnerabilities in a user's operating system and/or other software.
3.8.2. Prevention
Prevention can be difficult as attacks are often sophisticated and well resourced. In addition to that, the perception is often that increased security means decreased usability. However at the very least, the following actions should be taken:
- Running legitimate, up-to-date antivirus software and scanning your machine regularly
- Using automatic updates and installing critical security updates for your operating system as soon as possible
- Keeping third party software (such as Adobe products or web browsers) up to date with the latest version
- Not clicking on links or opening attachments in unsolicited email
- Not installing pirated software
- Making sure your operating system's firewall is on
- Only visiting reputable websites
- Not using untrusted USB devices or using your own USB devices in untrusted machines
3.8.3. Detection
Realistically most users cannot be expected to detect malware other than by running up-to-date AV and relying on alerts. However if other suspicious symptoms are encountered (e.g. a dramatic increase in advertising pop-ups, sudden performance issues, unexpected email replies or deletion) then users should get their machine checked out by local ITSS or the OUCS Help Centre.
3.8.4. Recovery
This may not always be as simple as it first appears - even if your AV detects and removes some malware from your machine, there may be malware still present. It is also difficult to be certain how long ago the machine was compromised. Having your machine compromised decreases the trust you can place upon it and recovery steps will depend on how much risk you are willing to accept. Recovery steps will also depend on whether the machine is owned by the university/unit or an individual. For university owned machines, for example, it may be simpler to re-image the machine. Again, the very minimum steps that need to be taken are to:
- Provide evidence that some malware has been found and removed (e.g. AV logs, files which have been found and deleted etc.)
- Ensure that the machine's operation system and all software is fully patched and up-to-date
- Make sure that the machine is successfully scanned with up-to-date AV software
Of course the only way to be 100% sure that the machine is clean is to re-install the operating system back to its original state. Restore points can be used but there should be some degree of assurance that the machine is not being restored to a compromised state. Similarly, important work and software may need to be restored from backup whilst exercising caution so as to not restore compromised material. Where re-installation is not possible, additional steps could include:
Running additional removal tools such as
Manual inspection of the system (requiring certain levels of technical knowledge and skill). Useful tools include the following from Microsoft Sysinternals:
3.8.5. Technical Vulnerabilities
While sophisticated attacks can, and do, happen, the vast majority of incidents that OxCERT deal with occur because simple controls have not been put in place. Probably the most common cause is out-of-date, vulnerable software (often third party software). It is therefore imperative that servers are kept as up-to-date as possible in terms of the operating system and all third party software. System administrators should pay particular attention to the software being run and maintain a watch for vulnerabilities in any such software and/or the underlying operating system. This is just as important as applying patches when they become available as there may be exploitable vulnerabilities for which a fix is yet to be released.
OxCERT do attempt to provide information on technical vulnerabilities of relevance and details can be found at Security Bulletins. It should be stressed however that OxCERT is not responsible for maintaining any University systems and it is up to system administrators to be aware of vulnerabilities on their own systems. OxCERT are not able to notify ITSS of all existing vulnerabilities and system administrators should consider joining the appropriate vendor mailing lists for vulnerability announcements. Where vulnerabilities do exist, system administrators (or other persons responsible for ICT systems) should evaluate the unit's exposure and take appropriate action. Usually this will involve a plan to apply security updates however where this is not immediately possible other measures MUST be taken in accordance with the identified risk. This could be anything from disabling services, restricting access, following mitigation guides by vendors or even (in extreme cases) temporarily removing access to the server.
3.8.6. Secure Coding Practices
Often code is written purely for functionality and security is not even taken into consideration. Units should therefore ensure that anyone employed (either internally or externally) to write code for servers is appropriately trained and fully aware of security issues when writing code. In particular, any code that allows user input of any kind should be properly sanitised and the input validated. More information, and details on how to prevent SQL injection (and other similar) attacks can be found within Suggested Technical Solutions.
3.8.7. Other Controls
Other controls that should be taken into consideration include the following:
- Good authentication and password policies
- The chosen authentication methods should be appropriate to the system in question. Systems with poor authentication methods face a risk of unauthorised access. Passwords, for example, may be guessed, shared, key-logged or brute-forced. If passwords are the only method of authentication these threats should be addressed. One of the main threats to passwords today is that of key-logging malware. Therefore system administrator passwords should not be used on untrusted machines. OxCERT have witnessed examples of Windows domain administrator passwords, for example, being used to authenticate IT support staff on machines compromised by key-logging malware leading to the compromise of the entire domain.
- Access to services
- Access to services should be restricted as far as possible without
adversely affecting availability. For certain services (e.g. HTTP on
a web server) this may not be possible. Remote access services (SSH,
Remote Desktop, VNS etc.) should, in particular, be restricted where
possible. This might include restricting to specific static IP
addresses or certain IP addresses ranges. Where static addresses are
not possible using a VPN range could be considered. Even using the
University's general VPN range for all users is preferable to access
from the entire world. If access really is required from anywhere,
then other controls MUST be put in place to reduce the considerable
risks that this poses.
For services which are intentionally open to the world (e.g. HTTP, SMTP etc.) the use of a DMZ should be considered in order to prevent any compromise being used to gain further access to internal resources - Unnecessary privileges
- All software should be run with the minimal privilege necessary to do the job at hand and should not, for example, be run as root. Similarly user accounts should have the minimum privileges necessary by default.
- Antivirus software
- Where possible anti-virus software should be run. However for some servers this is not always possible or advisable. Where this is the case other measures MUST be taken (see other controls in this list).
- Configuration errors and testing
- Often security breaches occur as a result of simple configuration
errors combined with a lack of testing. Therefore when configuration
changes are being made they should be tested to ensure that no
unexpected consequences occur. Specific test systems may also be
used though thought should be given to data sets used in test
systems. For example where personal or sensitive personal
information is processed it is advisable for test systems to use
simulated, rather than live data.
Configuration changes that could increase the likelihood of security incidents might include the following (and many more):
3.8.8. Detection
Detection of security breaches is crucial. Often compromised servers are discovered by OxCERT only to find out that initial access was several months earlier and the system has likely been accessed by several unauthorised groups or individuals. OxCERT do, of course, monitor the network for signs of unauthorised access to systems and will alert ITSS to any breaches we are aware of. This should be seen as the last line of defence for system administrators however who are responsible for monitoring their own systems/services. The following list gives just some examples of techniques that can be used to detect security incidents:
3.8.9. Recovery
In order to recover from system compromises, it is important to understand how the machine was compromised so that any identified vulnerabilities can be fixed. Usually log files from the local machine would be used to ascertain the method of entry. These could be supplemented by network flow data which can be used to identify IP addresses and times to look for in the log files.
As well as understanding how the attacker gained entry in the first place it is also important to understand what the attacker did in order to remove any outstanding malware, backdoors and/or minimise the impact of any other actions - such as access to confidential information (e.g. password files). For example, looking for files and folders created around the time of the compromise or checking the bash history of compromised accounts may provide clues as to what the attacker did. Similarly, running services should be checked to make sure they are all authorised. More information on recovery can be found in the suggested technical solutions section.
Up: Contents Previous: 2. Personnel, Recruitment and Training Next: 4. Network Management