IT Services

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:

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.

7. Copyright violations

OxCERT, in conjunction with ITS3, are responsible for dealing with notices of copyright infringements, received from agents acting on behalf of the copyright holder.

Upon receipt of the infringement notification, we will take measures to ensure that the infringing content is no longer served from the University network. Generally such measures take the form of a network block, or in the case of an infringement affecting a user of the OUCS VPN service, the appropriate remote access account will be disabled.

ITS3 will then promptly notify the the IT staff of the network on which the abuse was detected. In the case of VPN users, the user's college (in the case of students) or department (in the case of staff) will be notified. The unit should not make any contact with, or reply to, the complainant directly.

OUCS expect the unit to take appropriate disciplinary action, as it is important to make it very clear that this will not be tolerated. Following ICTC's recommendation and agreement from the Conference of Colleges, such infringements will incur an administrative charge from OUCS of £50 (plus VAT where appropriate).

Blocks will not be removed until ITS3 are satisfied that: To avoid any confusion, please state explicitly that such action has been undertaken when requesting that a block be removed. Please correspond with ITS3 as a reply to the initial notification. Do not contact OxCERT directly as we are not in a position to help, other than to pass your request back to ITS3.

Users should also be made aware that if they use the VPN from networks external to the University (for instance residential broadband), they are regarded just the same as any other user of the University network.