GC Information Technology Incident Management Plan

Archived information

Archived information is provided for reference, research or recordkeeping purposes. It is not subject to the Government of Canada Web Standards and has not been altered or updated since it was archived. Please contact us to request a format other than those available.

This document has been updated!

A more recent version of this document has been found.

Publié aussi en français sous le titre Plan de gestion des incidents de technologie de l'information au gouvernement du Canada

Table of Contents

1. Effective Date

This plan takes effect on May 10, 2012. It replaces the 2009 Government of Canada Information Technology Incident Management Plan (GC IT IMP). The GC IT IMP will be reviewed on a yearly basis and modified as appropriate.

2. Application

2.1 This Plan is prepared under the authorities delegated to the Treasury Board of Canada Secretariat under the Financial Administration Act and the associated Policy on Government Security; department mandates; as well as the delegated authorities of the Minister of Public Safety under the Emergency Management Act.

2.2 This Plan applies to all federal institutions subject to the Policy on Government Security and addresses:

  • Threats, vulnerabilities, and incidents within an IT environment that affect or may affect service to Canadians, government operations, security or privacy of information or confidence in government;
  • Incidents within an IT environment requiring an integrated GC response;
  • Networks classified secret and below.

2.3 This plan does not address the coordination of national and international cyber incidents with other forms of crisis and emergency management.

2.4 This version of the plan requires departments to report IT incidents to the Government of Canada Cyber Threat Evaluation Center (GC CTEC) at the Communications Security Establishment Canada (CSEC) until such time as Shared Services Canada (SSC) is ready to assume the role of the Government of Canada Computer Incident Response Team (GC CIRT).

2.5 The following IT incident management departmental operating procedures will be provided to Treasury Board Secretariat (TBS) for inclusion in appendices to this document: Public Safety (PS), Communications Security Establishment Canada (CSEC), Canadian Security Intelligence Service (CSIS), Royal Canadian Mounted Police (RCMP), Treasury Board Secretariat (TBS), Shared Services Canada (SSC) and Department of National Defence (DND).

3. Context

The occurrence of Information Technology (IT) incidents involving Government of Canada (GC) networks and infrastructure can have a significant impact on government operations, services delivered to Canadians and, consequently, confidence in government. The ability to detect and respond to incidents in a coordinated and consistent fashion, across the GC, is essential to maintaining government operations and services and to ensure the confidentiality, integrity and availability of the Government's information and IT assets.

The Government of Canada Information Technology Incident Management Plan (GC IT IMP) provides an operational framework for the management of IT security incidents and events that could have or have had an impact on the GC computer networks.

3.1 Objectives

  • Enhanced situational awareness across the GC;
  • Improved coordination and incident management planning within the GC;
  • Timely resolution of incidents that affect GC services and operations;
  • Informed decision making and associated incident mitigation and response;
  • A shared sense of responsibility and partnership among the GC IT and Information Technology Security (ITS) communities;
  • Improved shared GC knowledge and expertise;
  • Enhanced Canadian public confidence in the GC.

3.2 Assumptions

The following assumptions were made during the development of this Plan:

  • All organizations have incident management processes / plans and business continuity plans (BCP) in place as established under the Policy on Government Security;
  • Current departmental mandates and responsibilities will be respected;
  • IT security incidents related to the disclosure of personal information or private communications will follow established privacy procedures;
  • In addition if the incident is considered a crime, particulars should be reported directly to the Royal Canadian Mounted Police or Military Police as applicable, and if considered of national security importance, details will be reported directly to the Canadian Security Intelligence Service.

4. Governance Model

During a serious incident, the timely engagement of senior government officials is key to a strong and effective response. The governance model of the GC IT IMP identifies the senior management committees and officials who will be engaged when severity and trigger criteria are met.

Guidance provided by the committees and officials of the GC IT IMP governance structure will cover both short- and long-term activities for more serious incidents. Short-term activities are event-driven and are carried out during the mitigation of a threat or vulnerability or the response to or recovery from an incident. These activities require a prompt and coherent response. Longer-term activities involve post incident analysis and lessons learned, which will allow the Assistant Deputy Minister Security Committee (ADM Security) and / or Assistant Deputy Minister National Security (ADM NS) along with the Chief Information Officer Council (CIOC) to provide longer-term strategic leadership, direction, and governance related to security and IT respectively.

The engagement of the following committees and officials will be based on the circumstances and gravity of each situation.

Figure 1: Governance Structure
Governance Structure. Text version below:
Figure 1 - Text version

This flow chart describes the governance model of the GC IT IMP of which identifies the senior management committees and officials who will be engaged when severity and trigger criteria are met.

From the bottom, the GC CIRT receives incident / threat information from various organizations (an affected department, PS, partners). The GC CIRT then provides the incident information to TBS and to CTEC if cyber in nature). The CTU will receive information from GC CIRT and/or GC CTEC. The GC CIRT will asses the information, if cyber in nature, the Cyber Response Unit (CRU) (consisting of CSIC, TBS, GC CTEC, PS CCIRC, DND/CF, RCMP and SSC) chaired by directors of CTEC, TBS CIOB SPCS and SSC.

If non cyber in nature, the information will be passed to the Management Team directly, bypassing the CRU. The management team consists of TBS- CIOB, CSEC – DG Cyber defence, DG investigative Agency(s), Others as required, DND/CF DGIMO, DoJ (PS Rep), PS DG NCSD, PS DG Comms and SSC DG,  and chaired by PS DG Ops and TBS CIOB ED Security. From the Management team, there is a communications channel to the DG Comms WG consisting of PS DG Comms (Chair), TBS, PCO, Affected Department, Supporting Departments, SSC DG Comms). From the Management team, the reporting continues to the Federal Coordinating officer, the ADM level committees (ADM EMC + GC CIO, CIOC and ADM NS Ops + GC CIO), followed by the DM committee and the Cabinet Committee.

5. Incident Management Process

The incident management process will consist of the following five defined stages (see Figure 2): the stages "preparation" and "identification" are integral components to an effective incident management plan that must be in place and kept up to date to be properly prepared for managing an incident. The other three stages, "response", "recovery" and "post incident analysis" will be the focus of the governing structure.

Figure 2: Stages of Incident Management Process
Stages of Incident Management Process. Text version below:
Figure 2 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The responsibilities of departments related to incident management process are documented for each of the stages in the following sections. A summary of departmental responsibilities for all stages of the incident management process is summarized in appendix B.

5.1 Preparation

Figure 3: Stages of Incident Management Process (Departmental Preparation)
Stages of Incident Management Process (Departmental Preparation). Text version below:
Figure 3 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The "Departmental preparation" box is highlighted.

The preparation stage involves incident handling planning and training activities designed to provide adequate capabilities to prevent and detect incidents.

As a minimum, Departments will:

  1. Develop and practice incident handling planning and training activities and exercises to enable identification and effective response
  2. Ensure the response plan and communications procedures are well known and easily accessible to all IT personnel, and reviewed and updated (as required) both periodically and following an incident.
  3. Identify their critical systems (Business and Operations) to better identify injury and impact levels when reporting an event or incident.
  4. Integrate the processes of the GC IT IMP into their departmental Security, Business Continuity, IT contingency plans and Departmental Security Plan (DSP).
  5. Ensure awareness and response training is available to all employees commensurate with, the current and emergent threat landscape.
  6. Ensure provision of appropriate training and awareness of incident identification, incident management policy, and procedures to IT staff, so that all individuals involved understand their role and responsibilities related to incidents.
  7. Ensure that standard measures are defined in advance for rapid implementation as required.
  8. Monitor and manage software, hardware and firmware configurations including versions numbers and patch level in a departmental database to ensure that departments are able to identify vulnerabilities and act accordingly.
  9. Take reasonable measures to ensure the preservation and protection of evidence (see Appendix C).

5.2 Identification

Figure 4: Stages of Incident Management Process (Departmental Identification)
Stages of Incident Management Process (Departmental Identification). Text version below:
Figure 4 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The "Departmental idnetification" box is highlighted

The identification stage consists of the detection of an event suspected of being a cyber security incident, advising Information Technology representatives for the affected systems (who will perform the initial assessment to determine if it is an actual incident), and determining the impact, severity, and probable cause of the suspected incident.

As a minimum, Departments will:

  1. Carry out monitoring and intrusion detection activities (e.g. track and analyze threats, vulnerabilities, events via logs from various sources such as firewalls or Intrusion Detection Systems (IDS), which may affect departmental IT systems) as per the Standard on the Management of Information Technology Security (MITS). This should also include a proactive vulnerability management process using standard frameworks such as The National Institute of Standards and Technology's (NIST) Common Vulnerability Scoring System (CVSS);
  2. Monitor information coming from GC CIRT or Government of Canada Cyber Threat Evaluation Centre (GC CTEC) (e.g. GC status reports, requests for information —(RFI), GC incident reports, GC incident situation reports, warnings, threat assessments and GC situational awareness reports) and take appropriate actions;
  3. Contact the Government of Canada Computer Incident Response Team (GC CIRT) for assistance in characterizing potentially suspicious events;
  4. Once it is determined that an event has the potential or has been confirmed to be an incident, send an initial departmental incident report to the GC CIRT (Appendix "E") and when further information becomes available, submit an updated departmental incident report;
  5. Departments will preserve evidence as outlined in Appendix C.

The incident information must be reported to the GC CIRT no later than one (1) hour after the detection of an incident. The Incident Report Template located in Appendix D should be used as a guideline to categorize the level.

If relevant, affected departments should attempt to correlate multiple incident reports to identify those that are related to a single incident.

If the GC CIRT or GC CTEC notifies the department of a significant event, departments will be requested to confirm if the event is in fact an incident. Departments then must respond by reporting the incident using the Incident Report Template in Appendix E.

The GC CIRT may trigger the Incident Management process if they detect an incident involving one or more departments.

Categorization

The affected department shall assign a category to the confirmed or suspected incident within the Incident Report Template using the chart provided in Appendix D

Prioritization

Affected departments shall prioritize based on the incidents' potential impact.  Impact is the effect of the incident on the organization's objectives and mission based on the following factors:

  • Technical impact (current and future): The current negative effects of the incident and likely future effects. For example, malware spreading within one regional office has an immediate local impact, but if the malware spread across the Wide Area Network (WAN), it could affect operations throughout the department; and
  • Criticality of affected resources: The criticality of the Information system (IS) resources that are or could be affected by the incident. Critical systems have been identified through the Business Impact Assessments (BIA) and other business continuity activities.

5.3 Response

Figure 5: Stages of Incident Management Process (Departmental Response)
Stages of Incident Management Process (Departmental Response). Text version below:
Figure 5 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The "Departmental response" box is highlighted

Figure 6: Incident Flow (Departmental View)
Incident Flow (Departmental View). Text version below:
Figure 6 - Text version

There are three distinct identifiable sections; Under departments / Area of responsibility, Incident discovery/reporting and situational awareness/response. Under the heading of departments / Area of responsibility, Affected federal departments, public safety or partners report into GC CIRT. Other departments and TBS are identified for situational awareness. The GC CIRT then shares information with GC CTEC, RCMP/CSIS and DND/CF.

Within the Incident discovery/reporting heading, GC CIRT will log & receive action plan followed by trending /situational awareness. The GC CTEC will proactively detect for incidents and requires confirmation of incident at the affected federal department. If confirmed an incident, the information is then reported to the GC CIRT by the affected department. The information RCMP/CSIS and DND/CF received from the GC CIRT and/or GC CTEC will go thru and assessment phase and further by an investigation if required. From the log & receive action plan followed by trending /situational awareness the information may go to the CRU located in the situational awareness/response section of the diagram. From the CRU, the flow of information continues to the Containment mitigation, recovery and lessons learned. The trending / situational awareness is provided to other departments and TBS for situational awareness.

Once an event is received from an affected department, partner, Public Safety or GC CTEC, the GC CIRT will send an acknowledgment of receipt. If it is determined to be an incident the GC CIRT will assess the information received to determine whether the incident is of an IT or cyber nature, and provide appropriate mitigation advice and guidance to the affected department(s) and will alert other departments of the threat and how to protect against it. If the incident is of a cyber security nature, the GC CIRT will also provide this information to GC CTEC for analysis. The GC CIRT will also provide a summary of incidents on a regular basis to TBS CIOB for situational awareness.

Based on the incident categorization (Appendix D), the incident will be handled accordingly as indicated below.

If deemed low risk:

  • The information will be logged and the circumstances monitored as an integral part of situational awareness. It will also be reviewed against previous events (even those deemed low risk).

If deemed medium to high risk:

  • If the incident is deemed to be non cyber in nature, the information will be provided to the management team for review and action if warranted.
  • The information will be provided to TBS as to ensure the management of security incidents is effectively coordinated within departments and across government.
  • The information will be passed to the CTU (CTU) for an assessment. If an investigation is deemed necessary by the RCMP or CSIS then GC CTEC and the GC CIRT will be informed immediately.
  • If an incident has implications for defence, the information will be passed to the Department of National Defence / Canadian Forces (DND/CF). If an investigation is deemed necessary by DND/CF, then GC CTEC and the GC CIRT will be informed immediately.
  • While an investigation is ongoing, the investigating party may provide information to GC CTEC, GC CIRT and/or the Cyber Response Unit (CRU) for mitigation purposes.

The CRU will proceed according to standard operating procedures.

The CRU's main goal is to provide mitigation advice to the affected department(s) and to alert other departments of the threat and how to protect against it.

If containment cannot be achieved at the department level, the GC CIRT will lead the containment effort as per established procedures.

At any time departments may update their incident report to provide additional information to the GC CIRT or to request further mitigation advice.

Threat and vulnerability events will be escalated by the GC CIRT or TBS to the CRU when there is a high risk to the GC.

Figure 7: Incident Escalation Flow
Incident Escalation Flow. Text version below:
Figure 7 - Text version

Bottom up, Public Safety, Partners and affected departments report incident information to the GC CIRT. At this level, referred to as level 1 (Standard protective measures, monitoring are generally adequate however enhanced security may be required

  • Incident Categorization: Low injury / Low impact), and Event (On-going routine coordination of activities. Event is under control at the affected department And no further help required.) From the GC CIRT the information may go to GC CTEC and the CRU. This level is refereed to as level 2 (Mitigation needs to be coordinated in a timely fashion as part of normal operations.
  • Incident Categorization: Medium injury / Medium impact) and Initial triage, incident coordination (CRU may be called upon and start planning in preparation for an escalation. CRU to draft / implement an incident action plan and brief the Management Team on situation). From this level the information may flow up to the Management team and the DG Comms WG, referred to as Level 3 (Mitigation is possible with significant resource allocation.
  • Incident Categorization: High injury / Medium impact, Medium injury / High impact) and Authorities to allocate resources, Take action (Management Team to provide guidance and approve incident action plan). If further guidance is needed the information then goes up to the ADM level comities (ADM EMC +GC CIO, CIOC, ADM NS Ops + GC CIO, then DM Committee and finally the Cabinet Committee, also referred to as level 4 (No known  mitigation available or overwhelming response action needed.
  • Incident Categorization: High injury / High impact) and National response (Leadership from Cabinet Operations Committee, DM National Security Committee or ADM EMC / ADM NS Ops and the GC CIO).

The Management Team is the decision-making group that is convened to advise and intervene when attempts to restore services have not produced expected results or when no action taken/conceived can provide for the continuity of operations and rapid recovery of services. The Management Team has the authority to make important decisions necessary in a crisis: activation of a disaster recovery service, approval of special budgets, etc. In addition, if mitigation requires additional resources, the Management Team will be called upon to review the CRU's action plan and act accordingly.

More concise guidance is being developed and will be completed by June 2012. In the interim these incident categories (Appendix D) can be used.

5.4 Recovery

Figure 8: Stages of Incident Management Process (Departmental Recovery)
Stages of Incident Management Process (Departmental Recovery). Text version below:
Figure 8 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The "Departmental recovery" box is highlighted

Most incidents will necessitate recovery actions to restore systems and services to normal operations and preventative actions to avoid recurrence. Recovery actions may include restoration of systems from original media or images, installation of patches and immediate mitigation actions to prevent reoccurrence. System/service recovery should be conducted in a manner that preserves the integrity of the system to assist with an in-depth analysis/investigation of the incident.

The recovery process should align with internal departmental processes such as: Incident Management, Problem Management, Change Management, Configuration Management, and Release Management.

If a department is unable to recover from the incident in a timely fashion, assistance may be available through SSC's IT-SIRT (IT-Security Incident Recovery Team) Footnote 1 and further with the Cyber Protection Supply Arrangement (CPSA).

Prior to reconnecting affected systems or restoring services, incident handlers shall ensure that reinstating the system or service will not result in another incident.

As a minimum, Departments will:

  • Respond to GC CIRT and GC CTEC electronic information products as requested. (Cyber flashes, RFI etc.);
  • Insofar as possible, implement any relevant GC mitigating measures as recommended / mandated by the GC CIRT, GC CTEC or TBS Chief Information Officer Branch (CIOB);
  • Provide situation report updates during the incident phases and provide a final notification to the GC CIRT when normal operations have resumed.

5.5 Post Incident Analysis

Figure 9: Stages of Incident Management Process (Departmental Post Incident Analysis)
Stages of Incident Management Process (Departmental Post Incident Analysis). Text version below:
Figure 9 - Text version

There are five stages (boxes) in the incident management process the stages "Departmental preparation" and "Departmental identification", “Departmental Response”, “Departmental Recovery”, and “Departmental Post Incident Analysis”. Departmental Response has an overlapping process box “GC IT IMP Response” to highlight the overlap of GC processes with the department’s processes. “GC IT IMP Recovery” overlaps the “Departmental Recovery“ and the “GC IT IMP Post Incident Analysis” overlaps the “Departmental Post Incident Analysis” again to highlight the GC IT IMP processes over the departments own processes.

The "Departmental post incident analysis" box is highlighted

Post analysis of incidents is vital for learning and continuously improving GC safeguards and response plans and procedures. Reviewing the incident recording of lessons learned, recommending changes in processes, procedure, and developing long-term capability improvement solutions are crucial for a successful preparation phase.

For every major incident that occurs:

Departments will perform a post incident analysis, which summarizes the impact of the incident and identifies:

  • safeguard deficiencies;
  • measures to prevent similar incidents;
  • measures to reduce the impact of a recurrence;
  • improvements to incident-handling procedures and relating policies;
  • review preparation phase in terms of the response of the incident; and
  • lessons learned.

Affected departments will provide the GC CIRT a post incident summary report. TBS will be the repository of such reports.

TBS CIOB will close the post incident analysis phase of the GC IT IMP based on the implementation of mitigating measures and actions.

For multi departmental incidents, TBS CIOB will lead post incident analysis and will lead implementation of identified changes / improvements.

6. Departmental Roles and Responsibilities

This section identifies roles and responsibilities within departments relevant to the GC IT IMP.

The Departmental Security Officer (DSO) is responsible for:

  • Establishing reporting requirements for IT security incidents that align with the requirements established in the GC IT IMP as part of a coordinated approach to the management of departmental security incidents.

The Departmental IT Security Coordinator (ITSC) is responsible for:

  • Ensuring that effective processes for the management IT security incidents are developed, documented, approved, promulgated and implemented within the department, and that the effectiveness of these processes is monitored; and
  • Reporting on detected IT security incidents in accordance with the requirements established by the DSO.

Security practitioners and Operational IT Staff are responsible for:

  • Responding to IT Security incidents in accordance with the processes and procedures established by the department.

All departmental employees are responsible for:

  • Reporting real or suspected IT security incidents or other suspicious activity to departmental officials, in accordance with the processes and procedures established by the department.

7. Roles and Responsibilities of Other Government Organizations

7.1 Government of Canada Computer Incident Response Team

The Government of Canada Computer Incident Response Team's (GC CIRT) role is to coordinate the identification, mitigation, recovery and post-analysis of IT incidents within the Government of Canada.

7.2 Government of Canada Cyber Threat Evaluation Centre

The Government of Canada Cyber Threat Evaluation Centre (GC CTEC), within Communications Security Establishment Canada (CSEC), supports the identification, risk assessment, mitigation, recovery and post-analysis of cyber security incidents within the Government of Canada that relate to the malicious use or threat of IT that affect the confidentiality, integrity or availability of information systems use of, and information resident therein.

7.3 Public Safety Canada – Canadian Cyber Incident Response Centre

Public Safety – CCIRC's role is to provide advice to the GC CIRT as government is identified as a critical infrastructure within CCIRC.

7.4 CTU

The CTU's role is to determine if an investigation by either Canadian Security Intelligence Service (CSIS) or the Royal Canadian Mounted Police (RCMP) is warranted or ongoing.

7.5 Cyber Response Unit

When activated, the CRU role is to lead and / or assist a response to mitigate the impact of cyber security incidents to the Government of Canada when deemed necessary.

The nature of the incident will determine CRU composition. The team shall consist of members of Shared Services Canada (SSC), Public Safety (PS), CSIS, Department of National Defence / Canadian Forces (DND/CF), CSEC, RCMP, and Treasury Board Secretariat (TBS) as applicable.

7.6 Treasury Board Secretariat – Chief Information Officer Branch

Treasury Board Secretariat's role is of oversight and direction. TBS is responsible for ensuring the management of security incidents is effectively coordinated within departments and government-wide. TBS is also responsible for monitoring the implementation of the policy on government security, its directives and standards.

Figure 10: Area of responsibility for IT incidents
Area of responsibility for IT incidents. Text version below:
Figure 10 - Text version

There are two distinct boxes, on the left, with a heading of “Provinces & Territories, international partners, industry and critical infrastructure”. With a circle identified as CCIRC (PS) and a bullet with National incident response coordination within this box. Between boxes, arrows link the two sides with “integrated IT infrastructure”.

On the right side of the graphic, the heading of “Government of Canada” is at the top. There is a box “TBS, Oversight & Direction” with the bullets, Monitoring, Coordination and Post-Incident analysis. Slightly under the box is a circle within a circle. The main circle is identified as IT Incidents and GC CIRT with a bullet of Central coordination centre for GC incidents. Within this circle is the other circle identified as Cyber incidents and GC CTEC (CSEC) and cyber incident focused.

8. Enquiries

Please direct enquiries about this plan to your department's DSO. For interpretation of this plan, departmental DSO should contact:

Security Division, Chief Information Officer Branch
Treasury Board of Canada Secretariat
2745 Iris Street
Ottawa, ON K1A 0R5

E-mail: Contact Security Division by email: sec@tbs-sct.gc.ca
Telephone: 613-957-2549
Fax: 613-946-4334

Appendix A – Definitions

Cyber Incident
A deliberate IT incident that is state sponsored or is utilizing a non-publicly known exploit
Event
An event is an observable change to the normal behaviour of a system, environment, process, workflow or person. An event can feed into an incident but the opposite is not true.
Incident Handler
The person appointed or responsible to lead all stages of incident handling. The incident handler will be the contact person to GC CIRT throughout the incident life cycle.
IT Incidents
Incidents are understood to be any event or collection of events which may affect the confidentiality, integrity, or availability of an information system including components, or an event or collection of events which may violate information system policies or the law. Incidents can originate internally or externally and can be caused deliberately or accidentally. Incidents include privacy breaches, which are a collection, use, disclosure, access, disposal, or storage of personal information, whether accidental or deliberate, that is not authorized by the Privacy Act.

Appendix B – Summary of Departmental Obligations

Departments will develop and practice incident handling planning and training activities and exercises to enable identification and effective response.

Departments will ensure the response plan and communications procedures are well known and easily accessible to all IT personnel, and reviewed and updated (as required) both periodically and following an incident.

Departments will identify their critical systems (Business and Operations) to better identify injury and impact levels when reporting an event or incident.

Departments will integrate the processes of the GC IT IMP into their departmental Security, Business Continuity, IT contingency plans and Departmental Security Plan (DSP).

Departments will ensure awareness and response training is available to all employees commensurate with, the current and emergent threat landscape.

Departments will ensure provision of appropriate training and awareness of incident identification, incident management policy, and procedures to IT staff, so that all individuals involved understand their role and responsibilities related to incidents.

Departments will ensure that standard measures are defined in advance for rapid implementation as required.

Departments will monitor and manage software, hardware and firmware configurations including versions numbers and patch level in a departmental database to ensure that departments are able to identify vulnerabilities and act accordingly.

Departments will take reasonable measures to ensure the preservation and protection of evidence (see Appendix C).

Departments will carry out monitoring and intrusion detection activities (e.g. track and analyze threats, vulnerabilities, events via logs from various sources such as firewalls or Intrusion Detection Systems (IDS), which may affect departmental IT systems) as per the Standard on the Management of Information Technology Security (MITS). This should also include a proactive vulnerability management process using standard frameworks such as The National Institute of Standards and Technology's (NIST) Common Vulnerability Scoring System (CVSS).

Departments will contact GC CIRT for assistance in characterizing potentially suspicious events.

Departments will monitor information coming from GC CIRT or GC CTEC (e.g. GC status reports, requests for information —RFI, GC incident reports, GC incident situation reports, warnings, threat assessments and GC situational awareness reports) and take appropriate actions.

Departments will, once it is determined that an event has the potential or has been confirmed to be an incident, send an initial departmental incident report to the GC CIRT (Appendix E) and when further information becomes available, submit an updated departmental incident report.

Departments will preserve evidence as outlined in Appendix C.

Departments will respond to GC CIRT and GC CTEC electronic information products as requested. (Cyber flashes, RFI etc…)

Departments will, insofar as possible, implement any relevant GC mitigating measures as recommended / mandates by the GC CIRT, GC CTEC or TBS CIOB.

Departments will provide situation report updates during the incident phases and provide a final notification to the GC CIRT when normal operations have resumed.

Departments will perform a post analysis, which summarizes the impact of the incident and identifies:

  • safeguard deficiencies;
  • measures to prevent similar incidents;
  • measures to reduce the impact of a recurrence;
  • improvements to incident-handling procedures and relating policies;
  • review preparation phase in terms of the response of the incident; and
  • lessons learned.

Affected departments will provide the GC CIRT a post incident summary report.

Appendix C – Evidence Preservation

Overview of basic evidence preservation for IT personnel

Step 1

When an incident has been identified, the incident handlers must:

Ensure that the infected machine(s) is no longer accessible to non authorised personnel (i.e. only accessible to incident handlers - Preservation of the chain of custody).

Ensure that no attempts are made to explore the content of the infected machine(s) or to recover data from it.
The incident handlers must also document:

  • When was the incident discovered?
  • How was the incident discovered?
  • Who discovered the incident?

Step 2

The incident handler needs to preserve the evidence by taking the following actions:

  • Ensure that the infected machine(s) remains in a Live State so that the live memory can be collected.
  • Record of all processes running on the infected machine(s).
  • Record all physical connections from the infected machine(s) to all other devices.
  • Record all IP addresses and wireless connections to and from the infected machine(s) across the network.
  • Preserve all traffic logs (firewall, IDS, IPS, HIDS, etc.) to and from the infected machine(s) across the network.
  • When disconnecting the infected machine(s) from the network carefully monitor processes to ensure that the hard drive is not being erased. If information is being deleted immediately turn off the power.

Step 3

After preserving the network logs and protecting the evidentiary chain of custody, the incident handlers should take the following actions:

  • Record of all actions relating to the collection, preservation, access, storage and/or transfer of digital evidence.
  • Prepare a network diagram with the IP addresses of all the infected machine(s) and all other relevant network nodes.
  • Prepare, date and sign detailed notes on all actions taken during the course of the incident response.
  • Communicate all observations made and actions taken to law enforcement investigators.

Incident handlers must ensure that they have the legal authority to collect and preserve all information gathered during the incident response process. They are also responsible for all actions taken with respect to digital evidence.

Appendix D – Incident Categorization

Step 1:  Incident has occurred, define the Injury level and sector with the guide below.

Sector Injury Level
Low Medium High
Health & Safety No threat to health and safety Limited to moderate threat to health and safety Significant threat to health and safety; may include threat to life.
Public Confidence in the Government of Canada Limited or no loss of public confidence or negative impact on GC reputation Moderate loss of public confidence or negative impact on GC reputation Significant loss of public confidence or negative impact on GC reputation
Critical Infrastructure / Provision of Services Limited or no negative effect on critical infrastructure or provision of services. Moderate negative effect on critical infrastructure or provision of services Significant negative effect on critical infrastructure or provision of services.
Productivity / Financial Limited or no negative effect on productivity or finances. Moderate negative effect on productivity or finances Significant negative effect on productivity or finances.

Step 2:  Define the Impact of the Incident with the guide below.

Impact level Description
Low
  • Impacts a single workstation, mobile /portable device
  • Incident impacts 1-4% of users
  • Protected “A” or unclassified information impacted
Medium
  • Impacts one server or an administrator account is involved
  • Impacts many (10+) workstations, mobile  / portable devices (or one of a high profile official)
  • Incident impacts 5-9% of users
  • Protected “B” or Confidential information impacted
High
  • Impacts infrastructure device such as a router.
  • Impacts two or more servers. (or one E-mail server as indicated in your BIA)
  • Incident impacts 10% or more of users
  • Protected “C”, secret or Top Secret information impacted (to be reported via secure methods only)
  • Privacy breach

Appendix E – Incident Report Template

For assistance filing an Incident Report, please contact the Security and Identity Management Division

1.0 Reporting Entity

  • Name of organization:

2.0 Contact Information

  • First name:
  • Last name:
  • Initials:
  • Position:
  • Phone:
    • Cell:
    • Fax:
  • Pager:
  • Email:
  • Office address:

3.0 Incident Description including Injury and impact level

  • Date and time of incident: (date, time, and time zone)
  • Location of site affected by incident: (if more than one site is affected, please list)
  • Estimated injury level / sector:
  • Estimated impact level:
  • Incident duration: (if incident is over; otherwise, report ‘ongoing')
  • Estimated number of systems affected:
  • Percentage of departmental systems affected:
  • Brief description of the incident:
  • Actions taken: (include date and time if possible)
  • Supporting documents attached: (describe if any)
  • Priority (if multiple incidents reported): (describe if any)

4.0 Status of Mitigation Actions

  • Mitigation details to date: (list any actions that have been taken to mitigate incident and by whom)
  • Results of mitigation:
  • Additional assistance required?
  • YES/NO

5.0 Incident Type

  • Malicious code: Worm, virus, trojan, backdoor, rootkit
  • Known vulnerability exploit: (List the CVE number for known vulnerability)
  • System compromise: Altering logs, altering DNS information
  • Data compromise: Destroying data, altering data, Web defacement
  • Denial of service: DDoS, DoS
  • Access violation: Unauthorized access attempt, successful unauthorized access, password cracking
  • Accident or error: Equipment failure, operator error, user error, natural or accidental causes
  • Other or unknown:

6.0 Systems Affected

  • Network zone affected: Internet, DMZ, administration, internal, enclave
  • Type of system affected: File server, Web server, mail server, database, workstation, other (please specify)
  • Operating system (specify version): Windows, Linux, Unix, MacOS, OS/390, other (please specify)
  • Protocols or services: (List all that apply)
  • Application: (Include specific versions)

7.0 Apparent Origin of Incident or Attack

  • Source IP and port:
    • URL: (if any)
  • Protocol:
    • Malware: (if any)

Appendix F – Transition Plan

Figure 11: Areas of Responsibility for IT Incidents - Currently
Areas of Responsibility for IT Incidents - Currently. Text version below:
Figure 11 - Text version

There are two distinct boxes, on the left, with a heading of “Provinces & Territories, international partners, industry and critical infrastructure”. With a circle identified as CCIRC (PS) and a bullet with National incident response coordination within this box. Between boxes, arrows link the two sides with “integrated IT infrastructure”.

On the right side of the graphic, the heading of “Government of Canada” is at the top. There is a box “TBS, Oversight & Direction” with the bullets, Monitoring, Coordination and Post-Incident analysis. Slightly under the box is a circle within a circle. The main circle is identified as IT Incidents and GC CIRT (CSEC / GC CTEC) with a bullet of Central coordination centre for GC incidents. Within this circle is the other circle identified as Cyber incidents and GC CTEC (CSEC) and cyber incident focused.

The Government of Canada Cyber Threat Evaluation Centre (GC CTEC) within CSEC is the current GC CIRT for Federal Departments and Agencies. All incidents are to be reported to GC CTEC until Shared Services Canada (SSC) assumes the role of GC CIRT (October 2013). In an effort to reduce duplication of effort, services will be provided by various organizations across the GC, TBS is working with stakeholders to establish departmental operational procedures to support the GC IT IMP.

Figure 12: Areas of Responsibility for IT Incidents - End State (October 2013)
Areas of Responsibility for IT Incidents - End State (October 2013). Text version below:
Figure 12 - Text version

There are two distinct boxes, on the left, with a heading of “Provinces & Territories, international partners, industry and critical infrastructure”. With a circle identified as CCIRC (PS) and a bullet with National incident response coordination within this box. Between boxes, arrows link the two sides with “integrated IT infrastructure”.

On the right side of the graphic, the heading of “Government of Canada” is at the top. There is a box “TBS, Oversight & Direction” with the bullets, Monitoring, Coordination and Post-Incident analysis. Slightly under the box is a circle within a circle. The main circle is identified as IT Incidents and GC CIRT (SSC) with a bullet of Central coordination centre for GC incidents. Within this circle is the other circle identified as Cyber incidents and GC CTEC (CSEC) and cyber incident focused.

Date modified: