This document is subject to review and update on a yearly basis.
- Response to Security Events
- Response to Security Incidents
- See Also
This procedure applies to information custodians, as defined by Policy 46, of electronic information. This will typically be information technology support staff responsible for the on-going maintenance and administration of University of Waterloo computing systems.
The purpose of this procedure is to augment the Information Security Breach Response Procedure where the breach involves electronic information stored on University of Waterloo computer systems. Like the breach response procedure, the goal is to ensure that all computer security incidents at the University of Waterloo are handled in a consistent manner with the following objectives:
- To ensure UWaterloo complies with applicable legislative and regulatory guidelines.
- To facilitate effective, coordinated, security incident response.
- To identify the root cause of computer security incidents, and implement measures to prevent further incidents of a similar nature.
- To enable continuous improvement of UWaterloo's intrusion detection capability.
For the purposes of this document, a security incident is an incident involving one or more of the following:
- an information security breach, as defined by Policy 46, involving electronic information.
- Activity originating from a university computer system or network that violates Canadian anti-spam legislation. Such activity includes:
- Malware (includes any "attack" designed to exploit a software vulnerability)
- Botnet traffic
- Any other activity on a university computer system or network considered malicious, including a Denial of Service attack.
For the purposes of this document, a security event is defined as one of the following:
- A notification from the IST Security Operations Centre (email@example.com) of a security-related issue.
- A report to firstname.lastname@example.org containing evidence of a security incident.
- Observed user, system or network behaviour that is suggestive of a security incident.
A responder is a technical staff member, designated by a computing support unit, responsible for investigating security event and security incidents involving a particular network, system, and/or service. Ideally, several technical staff, with complementary skills spanning the relevant technology stack, would be involved in a response to a security event or incident. A responder is an information custodian for electronic information.
Staff assigned to the IST Security Operations Centre (SOC) are responsible for ensuring that security events brought to their attention are communicated to the person on record as being responsible for the affected system(s) as soon as possible. Event notifications will be tracked, ensuring that notifications are acknowledged. For events where there is no denial of service condition, notifications that go unacknowledged for longer than 4 business hours will be escalated. Security events unacknowledged after one business day will result in SOC staff taking steps to isolate the affected system or network from the campus network and worldwide Internet.
SOC staff will make efforts to ensure that repeated security events that are not attributed to security incidents, normally caused by intrusion detection system false positives, are prevented so that undue interference with normal operations is minimized.
As soon as possible upon receipt of a security event notification, responders must investigate to determine the cause of the event. Once the cause has been determined, the SOC must be notified with the following information:
- The cause of the event.
- Confirmation that the event does or does not correspond to a security incident.
If a responder has difficulty in obtaining the information listed above, s/he may contact the IST SOC for assistance.
All security incidents must be reported to the Information Security Officer as soon as possible after discovery. This is normally done through the SOC. Actions taken by the responder(s) must be recorded and time stamped.
Containment involves ensuring that unauthorized access resulting from the security incident is prevented while enabling forensics to take place. The measures required for effective containment will vary depending on the technology involved and the infrastructure available. Containment usually involves enabling network access controls or disabling the affected network connection altogether.
In any case where action(s) to contain a security incident results in the interruption of a service, the responder must ensure that all support personnel involved in supporting that service are notified as soon as possible.
The investigation needs to answer the following questions:
- What was the cause of the security incident?
- When did the actual incident first take place?
- Was any information stored on the system classified as Restricted?
- What was the extent of the unauthorized activity resulting from the security incident?
- Were there any unauthorized modifications to software as a result of the security incident?
- Were there any unauthorized modifications to user data as a result of the security incident?
- What information was exposed or potentially exposed as a result of the security incident? For how long?
- Is there evidence of other University of Waterloo systems involved in the security incident?
The appropriate tools and techniques used to investigate security incidents vary widely depending on the circumstances and technology involved. Outlining any further detail is beyond the scope of this document. Indeed, there are entire security training courses dedicated to the topic.
SOC staff are available to assist in the investigation of security incidents on University of Waterloo systems.
Over the course of the investigation, responders must provide daily reports to the SOC and the information steward. Where the incident involves information classified as restricted, or where there exposure of information classified as restricted is imminent, the SOC will involve the FOIP Coordinator as early as possible in the investigation.
In the event of a system-level compromise, the following must take place before the system is to go back into service:
- All software, including the operating system, must be deleted and re-installed. Best practice is to reformat system partitions and re-install the operating system and application software.
- All system and user passwords must be changed.
- All passwords stored on the system used to access other systems, such as remote database servers, must be changed.
- Private keys stored on the system must be discarded, and corresponding public keys must be removed from other systems. Key pairs will need to be regenerated.
- Unless there exists a mechanism to verify the integrity of user data, it is strongly recommended that user data on the system be restored from the last backup before the date of system compromise. This assumes of course that backups are stored on storage that can not be modified by users on the compromised system.
Information Custodians and the Information Security Officer (or a designate) need to review the security measures and systems management practices in place at the time of the security incident. Changes to systems management practices and/or security measures may be required to prevent the incident from re-occurring. Any changes made must be reported to the information steward, and in some cases, the FOIP Coordinator.