Incident Handling

1. Incident handling

Most security incidents are initiated by OxCERT, through our monitoring alerting us to a potential problem and subsequent investigation.

Should ITSS themselves discover a security breach or be alerted to one by their users, please let OxCERT know as soon as possible. We will endeavour to assist in the investigation, liaise with external organisations where appropriate, and may find that the incident involves other systems within the University network.

2. Expectations

Please see our document on logging of network usage for details of what we expect units to log. Users of NAT should pay particular attention as to the need for detailed logs to be kept.

3. Notifications and correspondence

OxCERT will generally use a single email address for each college or department for correspondence regarding security incidents. Ideally this should be a generic address such as which is monitored on a regular and frequent basis by multiple members of staff. We are happy to use a particular contact address specifically for use regarding security incidents; just let us know. If we do not have a record of a preferred address from past correspondence, we will look to contact either a generic IT support contact address (if one exists) or the registered IT manager.

OxCERT notifications are generally sent from our own ticketting system, bearing a ticket number in the Subject line. Please try to keep this in the subject line of all further correspondence regarding a particular incident for ease of reference. If you have your own ticketting system then please avoid sending an autoresponse to every correspondence from us on a ticket; we will tolerate one in response to our initial notification.

Please keep all correspondence in plain text (unless sending specific attachments). HTML-only email in particular can interact badly with our systems.

When requesting removal of network blocks, as well as including the ticket number, it can help to explicitly state the MAC and/or IP address of the host in question, so that we can process the request more quickly.

4. Security blocks

Network-level blocks will generally be applied at the backbone routers, by MAC address or IP address as appropriate, in order to isolate the system from anything but its local network, and for the protection of the remainder of the University network and the global Internet. Please bear in mind that this does not necessarily protect systems on the same network from attack by the compromised system.

MAC address blocks are generally preferred as many networks are using dynamic IP address assignments. This avoids collateral damage to other systems later assigned the same IP address, and the block remains effective should the compromised host later be assigned a different IP address. However, MAC address blocks are incompatible with firewalls which do routing or proxy-ARP, or in certain circumstances may be inappropriate for other reasons; in such cases blocks will be by IP address. Note that a MAC block is specific to a particular network connection; a block against that MAC on one unit's connection will have no effect elsewhere on the University network.

Upon receipt of a notification, please promptly isolate the system from the local network pending further examination, for instance by using a port block if you have managed switches.

OxCERT will endeavour to notify local ITSS as soon as possible, but at particularly busy times the notifications may be delayed or overlooked. If you suspect that a host has been blocked but have not received a notification, please check against the blocks list from any system within the University network, and contact us if necessary. A brief summary of the reason for each block will be given.

5. Keylogging malware

Where systems have been infected with keylogging malware such as Zeus (also known as Zbot or wsnpoem), additional safeguards are necessary in order to reduce the potential for attackers to abuse any credentials that they may have gathered. We have seen many examples of University accounts being abused, sometimes over a period of many months, and must take reasonable measures to prevent this occuring.

As of January 2010, OxCERT now expect ITSS to take the following measures in dealing with instances of keylogging malware:

  • All Oxford University passwords that have been entered on a system that has suffered a keylogger attack must be changed.
  • OxCERT will request the usernames of people who have or are likely to have used the attacked machine within 30 days so that those details can be used to trace other incidents.
  • Remote Access accounts will have their password randomized so that once an account is unblocked the user can set a new password using online self-registration.
  • As with any such attack it is extremely likely that other passwords, including including those for other services within the University, online banking etc., will have been disclosed. Please make sure affected users are aware of and understand the guidance at

In cases of infections on managed systems, logs should be available to determine recent users of a system. For personally-owned systems then the only way to determine who else may have used it will likely be to ask the machine's owner. In general it will not be possible to determine how long ago a system was compromised. A compromise may have occurred considerable time before OxCERT detected it; this is particularly likely with systems which are used on multiple networks. Alternatively OxCERT may have only detected one of several several malware items on the system. In the absence of other information, we consider thirty days a reasonable period, for which logs (or the user's memory!) may reasonably be expected to be available.

Ultimately users have to be responsible for the security of their own passwords and other private data. Nevertheless it is important to ensure that they understand the reasons for taking action and the possible implications of not doing so, and we encourage ITSS to assist with this.

While we shouldn't ignore users' security on external systems such as online banking or Google Mail, our chief concern is with that of the University network and hence it is important to ensure that passwords for any system on the University network are changed. Users may have passwords for their own computer, central OUCS systems, systems both in college and within their department, and potentially other parts of the University such as Libraries or BSP.

6. Excessive traffic notifications

OxCERT may notify units in the event of a system being seen to generate unusually large amounts of network traffic. Such notifications are purely warnings and OxCERT will not impose a block; it is up to individual units to decide whether they feel a local block is appropriate.

IT officers should check out the affected machines promptly; OxCERT have had cases where a warning has apparently gone ignored and a copyright violation notice for the system has subsequently been received.

OxCERT has no objection to large amounts of data being transferred for genuine academic purposes, or to reasonable recreational usage, provided it does not contravene other network rules.


Written by IT Services. Latest revision 5 September 2014