Overview: This document offers a recommended, cyclic approach to managing both cybersecurity and information security related events in a systematic manner. The phased incident response approach outlined in this document aligns with the approach recommended by the US National Institute of Standards and Technology (NIST).
Table of Contents
1.1 Cyber security or information security incident?. 4
1.2 Defining a cyber security incident 5
2.2 Incident response framework. 5
2.4 Detection and analysis. 10
2.4.1 Estimating the scope of the incident 12
2.4.2 Incident prioritization. 12
2.4.3 Incident notification. 14
2.5 Containment, eradication and recovery. 14
2.5.1 Evidence gathering and handling. 15
2.5.2 Eradication and recovery. 16
2.5 Post-incident activity. 16
3.0 Detailed incident response processes. 17
3.2 Incident levels and impacts. 18
3.3 Initial incident detection and reporting. 18
3.4 Types of incident response. 19
3.5 Response decision tree. 19
3.5.1 Responding to end user malware. 20
3.5.2 Responding to server malware. 21
3.5.4 Lost or stolen mobile device. 23
3.5.5 Outsourced or hosted systems incidents. 24
3.5.6 Infrastructure infiltration. 25
3.5.7 Emergency or catastrophic events. 27
3.5.8 National systems incidents. 28
3.5.9 Managed security service provider (MSSP) daily incidents reports. 29
3.5.10 Other security incidents 30
Appendix A – Terms and definitions. 32
Appendix B – Contact
Information. 33
A security incident can be defined as an act or event that has violated information security policies, standards, acceptable use policies or local laws and regulations. Security incidents can be triggered by a single event such as a virus outbreak or a network breach. Often, security incidents are a combination of several seemingly innocuous events which if not identified, contained and eradicated in a timely manner, can manifest into larger events that pose a significant risk to the IT Professional Security (ITPROSEC). When related to information technology, they can result in a loss of confidentiality, integrity or availability of ITPROSEC information, systems or network services.
This document offers a recommended, cyclic approach to managing both cybersecurity and information security related events in a systematic manner. The phased incident response approach outlined in this document aligns with the approach recommended by the US National Institute of Standards and Technology (NIST).
1.1 Cyber security or information security incident?
There are many types of information security incidents that could be classified as a cyber security incident, ranging from serious cyber security attacks on critical infrastructure and major organized cybercrime, through to basic malware attacks or through hacktivism, to internal misuse of systems and general software malfunction.
The term cyber (which actually means robotic) can be interpreted and defined in many different ways. Merriam-Webster defines cyber as “relating to or characteristic of the culture of computers, information technology, and virtual reality.” A research project conducted by a UK-based cyber security organization found the term cyber is often associated with the concept of cyberspace. However; this project revealed that there is no common definition of a cyber security incident and also no authoritative taxonomy to help organizations decide what is (or isn’t) a cyber security incident, breach or attack.
Cyberspace – The space in which computer transactions occur, particularly transactions between different computers. We say that images and text on the Internet exist in cyberspace, for example. The term is also often used in conjunction with virtual reality, designating the imaginary place where virtual objects exist.
As computer based technology continues to evolve and present new opportunities, the desire of business to quickly adopt new technologies provides enormous opportunity, but also brings unforeseen risks and unintended consequences that can have a negative impact.
Many computing devices, including desktops, laptops, tablets, and smartphones, are connected to the Internet on continuous basis. Technical exploits target vulnerabilities web applications as well as in infrastructure. Security incidents that impact cyberspace can be referred to as “Cyber Security Incidents”. As we continue to become more dependent on technology to conduct all facets of business the ability to detect and respond to information security and cybersecurity incidents is paramount. The framework outlined in this guide is designed to handle both information security and cyber security incidents.
1.2 Defining a cyber security incident
Many different types of information security incidents could be classified as cyber security incidents. Often cyber security incidents are associated with malicious attacks or Advanced Persistent Threats (APTs), but there is generally little agreement across organizations.
All types of attacks, whether basic or advanced, use similar attack vectors (e.g. hacking, malware, social engineering, etc) to carry out attacks. The difference between basic and advanced techniques is the level of sophistication, scale and resourcing.
When it comes to identifying and responding to suspected information, IT or cyber security incidents, most organizations treat them using a single incident response process.
This section provides general guidance on the phases and typical activities associated with the overall process for managing security incidents. These additional details outline the complete management of an incident from detection to resolution along with lessons learned activities. The framework outlined in this document is based on framework described in the US National Institute of Standards and Technology’s “Computer Security Incident Handling Guide”.
2.2 Incident response framework
As depicted in Figure 1 below, the incident response framework adopted by the IT Professional Security consists of 4 phases: Preparation, Detection & Analysis, Containment Eradication & Recovery and Post-Incident Activity. The process model outlined provides general information and guidance about each phase along with activities that should take place during each phase.
Figure 1 – Incident Response Framework
This process model is applied to a number of potential security incident scenarios which would require an ITPROSEC response. Section 3 of this document, “Detailed incident response processes”, contains process flows for handling various scenarios.
The preparation stage covers everything that needs to be put in place before a cyber or information security incident occurs. Preparation involves forming a team to handle incidents, assigning roles and responsibilities, and developing escalation procedures. It also involves technology issues such as acquiring the required tools to adequately handle an incident as well as learning the environment and ensuring appropriate monitoring capabilities are implemented.
Security awareness materials should be in place to inform staff how to recognize and report security incidents. It is important to identify other key stakeholders within the ITPROSEC that need to participate in the incident response program. Table 1 represents the recommended set of responsibilities for key participants:
| Role | Responsibilities |
| Incident Response Leader | Overall incident coordinator Decision maker Contact with external security and other relevant agencies |
| Technical Services Lead | Network and infrastructure knowledge base Coordinate access to network components and sources of logs and other network data |
| Application Services Lead | Application access controls Application owner knowledge base Application configuration control Application logs and locations |
| Service Provider Contact(s) | Initial incident detection Assist with network monitoring devices and incident detection Security appliance logs and access to network components Technical expertise |
| Help Desk Lead | Respond to internal user issues Coordinate communications to specific user groups via email distribution lists Coordinates with Crisis Communication Team |
| Information Management Lead | Identify types of information and sources that may be involved Assess impacts to business operations |
| Finance | Funding assistance for external support Acquisition of tools and equipment Invoice management |
| Human Resources | Administrative support Employee conduct issues Securing additional resources as necessary |
| Legal (General Counsel’s Office) | Evidence collection and preservation guidance Chain of custody for evidence Legal and regulatory guidance Investigation advice and assistance |
| Crisis Communications (Communications) | Manage media communication Coordinate internal communication Coordinate external communication Coordinate national systems communications |
| Scribe | Note taking and event activities Event log recording |
Table 1 – Incident Response Team Roles and Responsibilities
It should be noted that not all the roles are necessarily involved in every security incident. Minor incidents, such as limited malware infections, may require only minimal resources and technical assistance. Other more significant incidents, such as major attacks or infiltrations, will require a coordinated ITPROSEC-wide response including input from those responsible for the roles listed above and other individuals.
Preparing to handle an incident is as important as the actions taken during the event itself.
Keeping the number of incidents reasonably low is paramount in protecting the business processes of the ITPROSEC. If the ITPROSEC’s security controls aren’t adequate, higher volumes of incident may occur or incidents may not be detected until well after the incident actually occurred.
It is not the intent of this document to provide specific advice on security systems, networks and applications. However, a brief overview of some recommended practices for securing networks, systems and applications has been included:
- Risk Assessments. Periodic risk assessments of systems and applications should determine what risks are posed by combinations of threats and vulnerabilities. This should include understanding the applicable threats, including organization-specific threats. Each risk should be prioritized, and the risks can be mitigated, transferred, or accepted until a reasonable overall level of risk is reached. Another benefit of conducting risk assessments regularly is that critical resources are identified, allowing staff to prioritize monitoring and response activities for those resources.
- Host Security. All hosts should be built with security in mind and configurations should be standardized. In addition to keeping hosts patched, they should be configured using the principle of least privilege – users should only be granted the rights they need for performing their authorized tasks. Auditing should be enabled and should log significant security-related events. The security of hosts and their configurations should be continually monitored.
- Network Security. The network perimeter should be configured to deny all traffic that is not expressly permitted. This includes securing all connection points such as virtual private networks and wireless traffic with appropriate security controls.
- Malware Prevention. Software to detect and stop malware should be deployed throughout the ITPROSEC. Malware protection should be deployed at the host level (e.g., server and end user operating systems), the application server level (e.g., email server, web proxies), and the application client level (e.g., email clients)
- Training and Awareness. A training and awareness program helps all users to establish good security practices to help prevent intrusions or information loss. As well, awareness training should inform all users about the threat environment, attack vectors and reporting procedures. Training is also intended to assure the organization that the response team is equipped with the necessary skills and tools to effectively respond to an incident. Training delivery may be formal, informal or a combination both. The formal training approach will be effective and efficient when those involved have familiarity with the ITPROSEC’s IT systems, infrastructure and understand ITPROSEC user behaviours.
When a legitimate information security incident is confirmed, there may be a need for certain people to be informed both internally and externally; including the public. Communication may need to occur at a number of stages including:
- When an information security incident is confirmed as legitimate;
- When it is confirmed as under control;
- When it is designated for crisis activities; and/or
- When it is closed and a post incident review has been completed and conclusions reached.
When communication is needed, ensure that it covers who needs to know what and when. Affected stakeholders should be identified and may be divided into groups such as:
- Direct internal stakeholders (crises management, management staff, etc.),
- Direct external stakeholders (market participants, government, peer agencies, vendors, suppliers, etc.) and
- Other external contacts such as press and/or other media
Communication requirements will be coordinated with the crisis communication coordinator for larger incidents (typically significant or critical).
Each stakeholder group may need special information to be provided by the appropriate channels at the ITPROSEC. One of the key communications priorities after an information security incident is to ensure that direct internal and external stakeholders have the necessary information regarding the incident before other external contacts, such as the media.
In order to facilitate more efficient communications, it is necessary to prepare certain information in advance. This prepared information can then be easily adjusted to the circumstances of a particular information security incident and can be forwarded to each relevant group including the press and/or the media. If any information pertaining to information security incidents is to be released to the press it must be done in accordance with the ITPROSEC’s information dissemination protocols. Information to be released should be reviewed by relevant senior management, including communications’ staff and the information security team.
Figure 2 – Detection and Analysis Phase
Detection and Analysis are critical components of incident response as incidents need to be detected and reported as incidents need to be detected and reported as early as possible to limit the impact to the ITPROSEC and apply effective countermeasures. Upon initial detection and/or reporting and subsequent analysis, it may be necessary to access supporting information to determine if the incident actually occurred and/or the extent of the incident. The following table provides guidance on sources of essential information to include in these phases:
| Source | Description |
| Third Party Monitoring Services | These services can quickly identify either precursors or actual incidents. The information obtained can be provided to the ITPROSEC to allow it to mount an effective response. Additionally, the third party monitoring provider may also be capable of assisting with handling the entire incident or any phase activities. |
| Intrusion Detection Systems (IDS) | Intrusion Detection System logs or alerts may identify suspicious behavior coming from IP addresses. Past IDS logs may provide reconnaissance activity from the offender. |
| Security Information and Event Management (SIEM) | Security Information and Event Management (SIEM) generate alerts based on analysis of log data and are initial indicators of a potential incident. |
| Windows Systems Logs | Provides logs for System, Application, and Security logs. |
| Unix Systems Logs | May include log commands to obtain valuable information: Su Command – to show when a user switches to another user ID which is sometimes used to access the root account. Logged-on User (with utmp and wtmp) – to provide log information about who is currently logged in. Often can be found by executing the w, who, command.Logon Attempts – for successful and unsuccessful logon attempts.Cron Logs – to identify scheduled programs for future execution.Lastlog – to show login name, port and last log-in. |
| Web Logs | Provides access to IIS and Apache log information which may include source IP address of the attacker, successful attack requests (HTTP status codes, mostly 200 range codes though HTTP 500 responses can also indicate successful attacks). |
| Network Logs | Firewalls, network monitoring, and routers may provide source/destination IP addresses, protocols and/or dates and times. |
| Network Vulnerability Scans | Tools such as NMAP or Nessus provide information about hosts/services, OS versions etc. |
| Antivirus/Antispam | May provide indicators of increased activity, blocked malware and/or successful detection of malware used in an attack. |
Table 2 – Sources of incident information
In addition to technology indicators, there may also be a significant amount of information available from end-users who suspect or detect events or incidents. This may include end-user observations about:
- Unusual email activity;
- Changes in access privileges;
- Missing, corrupt or changed data;
- Malware events; and
- Unusually slow application/service response times or no response.
These type of indicators are expected to be reported; the initial analysis should then provide additional indicators if an incident is either underway or has already taken place.
2.4.1 Estimating the scope of the incident
There are a number of factors that need to be considered when assessing and prioritizing an incident:
- When and where did the incident occur?
- What was the cause of the incident?
- Which systems, applications and data are affected by the incident?
- Are there any additional systems, applications or data that could be impacted?
- Could there be any legal or regulatory implications of the incident?
- How many users are affected by the incident?
- Are there any third parties involved in the incident?
- Has any information regarding the incident been communicated to external third parties?
Incidents should be prioritized in terms of their actual or potential impact to the ITPROSEC, including any legal or regulatory considerations. The following table should be used to classify the criticality of an incident:
Functional Impact of the Incident. Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. Incident response leads should consider how the incident will impact the existing functionality of the affected systems. Incident response leads should consider not only the current functional impact of the incident, but also the likely future functional impact of the incident if it is not immediately contained.
Functional Impact Categories
| Category | Description | Example |
| Critical | These incidents will usually cause the degradation of critical service(s) for a large number of users, involve a serious breach of network security, affect mission-critical equipment or services or damage public confidence in the ITPROSEC. | Targeted cyber security attacks or loss of publicly available online service. |
| Significant | Less serious events are likely to impact a smaller group of users, disrupt non-essential services and breaches of network security policy. | Website defacement or damaging unauthorized changes to a system. |
| Minor | Many minor types of incident can be capably handled by internal IT support and security. All events should be reported back to the information security manager who will track occurrences of similar events. This will improve understanding of the IT security challenges and may raise awareness of new attacks. | Unsuccessful denial-of-service attack or the majority of network monitoring alerts. |
| Negligible | It is not necessary to report on incidents with little or no impact or those affecting only a few users, such as isolated spam or anti-virus alerts; minor computer hardware failure; and loss of network connectivity to a peripheral device, such as a printer. | Isolated anti-virus alert or spam email. |
Table 3 – Functional Impact Categories
Information Impact of the Incident. Incidents may affect the confidentiality, integrity, and availability of the ITPROSEC’s information. For example, a threat actor could exfiltrated sensitive information. Incident response leads should consider how this information exfiltration will impact the ITPROSEC’s overall mission. An incident that results in the exfiltration of sensitive information may also affect other organizations if any of the data pertained to a partner/affiliated organization.
Information Impact Categories
| Category | Description |
| Integrity Loss | Sensitive or proprietary information was changed or deleted. |
| Proprietary Breach | Proprietary information was, such as enforcement related case information, was accessed or exfiltrated. |
| Privacy Breach | Sensitive personally identifiable information (PII) of employees was accessed or exfiltrated. |
| None | No information was exfiltrated, changed, deleted or otherwise compromised. |
Table 4 – Informational Impact Categories
Recoverability from the Incident. The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident. Incident response leads should consider the effort necessary to actually recover from an incident and carefully weigh that against the value the recovery effort will create and any requirements related to incident handling.
| Category | Description |
| Regular | Time to recovery is predictable with existing resources |
| Supplemented | Time to recovery is predictable with additional resources |
| Extended | Time to recovery is unpredictable; additional resources and outside help are needed |
| Not Recoverable | Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly); launch investigation |
Table 5 – Recoverability Categories
Combining the function impact to the ITPROSEC and the impact to the organization’s information determines the business impact of the incident. For example, a denial of service attack against a public web server may temporarily reduce the functionality for users attempting to access the server, where as an attacker that gained root access to the web server could result in the exfiltration of personally identifiable information (PII) which could have a serious impact on the ITPROSEC’s reputation.
The recoverability from the incident determines the possible response that the team may take when handling the incident. For example, an incident with a high functional impact and low effort to recover from is an ideal candidate for immediate action from the Incident Response team. Other incidents may not have smooth or easy recovery paths and may need a more strategic response. For example, an incident that results in an attacker exfiltrating and publicly posting sensitive data has no easy recovery path as the data is already exposed.
When handling an incident it is usually necessary to make a number of decisions in a relatively short period of time. It is important to ensure that communications channels are in place to notify the appropriate parties. This is especially important in situations where the risk exposure exceeds the levels of responsibility, authority or capability of the incident manager.
When an incident is analyzed and prioritized, the incident response team needs to notify the appropriate individuals so that all who should be engaged get involved.
The exact reporting requirements vary among organizations, but parties that are typically notified include:
- Chief Information Officer (CIO)
- Information Security Manager
- External incident response teams (if appropriate)
- System owner
- Human resources (for cases involving employees, such as harassment through email)
- Communications (for incidents that may generate publicity)
- General Counsel’s Office (for incidents with potential legal ramifications)
- Law enforcement (if appropriate)
2.5 Containment, eradication and recovery
Figure 3 – Containment, Eradication and Recovery
An incident needs to be contained to keep it from spreading and to prevent further damage or loss from occurring. Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions). Decisions such as these are much easier to make if there are predetermined strategies and procedures for containing the incident.
Different containments strategies will be required to address different incidents. As an example, the strategy for containing an email-borne malware infection is quite different from that of a network-based DDoS attack. The ITPROSEC should maintain separate containment strategies for each major type of incident.
2.5.1 Evidence gathering and handling
The primary reason for gathering evidence during an incident is to remediate or resolve the incident; however, evidence may also be required from a legal perspective. If evidence is required for legal purposes, it is important to document how all evidence, including compromised systems has been preserved. Procedures should be maintained to ensure evidence is collected in a manner that maintains chain of custody and is admissible in court. A detailed log should be kept for all evidence, including the following:
- Identifying information (e.g., the location, serial number, model number, IP address, and media access control (MAC) address of a computer)
- Name, title, phone number of each individual who collected or handled the evidence during the investigation
- Time and date (including time zone) of each occurrence of evidence handling
- Locations where the evidence was stored
2.5.2 Eradication and recovery
After an incident has been contained, eradication may be required to remove components of the incident, such as deleting malware and disabling breached user accounts, in addition to remediating vulnerabilities that were exploited. Depending on the nature of the incident, eradication, may not be required or may be performed during recovery.
During the recovery phase, administrators restore systems to normal operation and if required remediate any vulnerabilities to prevent similar incidents. Recovery could entail restoring systems from a known good backup, rebuilding systems from scratch, changing passwords, installing patches, replacing compromised files with clean versions, and tightening perimeter security (e.g., firewall rulesets, router access control lists or intrusion prevention system signatures). Higher levels of system or network monitoring and logging are often required as part of the recovery process.
Figure 4 – Post-Incident Activity
Follow up is one of the most important parts of the incident response process and is frequently omitted. Reviewing the cause of the incident and the incident and the effectiveness of the incident handling procedures enabled the process to be further improved. Additionally follow up is important to prevent the recurrence of similar incidents. A number of questions should be answered in the follow up meeting, including:
- What happened and at what times?
- How well did staff and management deal with the incident? Were documented procedures followed? Were they adequate?
- What information was needed sooner?
- What would be done differently next time a similar incident occurs?
- How could information sharing with other organizations have been improved?
- What corrective actions can prevent similar incidents in the future?
- What additional tools or resources are needed to detect, analyze and mitigate future incidents?
The effort required for the post-incident analysis is generally related to the magnitude of the incident. After serious attacks have occurred, it is usually worthwhile to hold post-mortem meetings with appropriate personnel from various areas of the ITPROSEC.
An additional post-incident activity is creating a follow-up report for each incident. These reports provide a reference that can be used to assist in handling similar incidents. Creating a formal chronology of events is important for legal purposes, as is creating a monetary estimate of the amount of damage the incident caused.
This section of the document contains a comprehensive set of processes that should be followed to address various information and/or cyber security incidents faced by the ITPROSEC.
The following schema is utilized throughout the various flowcharts within this section:
| Item | Symbol | Colour Code | Description |
| Start Point | Yellow | Initial flowchart start point. Source could be system detection, end user reports or other information received leading to a suspected event or actual incident. | |
| Report | Green | Identifies reports or other documents being used or created, may include emails or other electronic documents. | |
| Action | Blue | Analysis or other actions to be taken, including communication information. | |
| Decision | Yellow | Decision making on completion of current action or prior to new action. | |
| Pre-defined Action or Response | Blue | An established process or set of actions outside of incident handling. | |
| Go to Next Step | Black | Proceed to next response step. | |
| Alternate Step | Black | Possible informative response required. | |
| Actions Completed | Grey | Response or current actions completed. |
Table 6 – Response Flowchart Schema
3.2 Incident levels and impacts
Any incidents that are detected in the ITPROSEC should be assessed for priority following the approach outlined in section 2.4.2 – Incident Prioritization.
Within the ITPROSEC, there are several likely sources for incident detection and reporting such as:
- Daily or monthly information from Telus;
- A ticket generated by the Help Desk based on poor quality concerns or other related issues from users;
- An email to the Help Desk from any application/system user or group of users; or
- A report from a hosted service provider to a business owner contact.
After initial incident detection and reporting (depending on the type of incident as determined by the initial analysis and/or by any other reasons to believe that the event is a security incident), a number of potential responses may be invoked.
The more likely incidents to occur include:
- End user malware
- Server malware
- Lost or stolen devices
- Data exfiltration
- Infrastructure infiltration
- Third party service provider incidents
- National systems incidents
- Emergency or catastrophic events
- Daily incident reports
- Other security incidents, including phishing and/or social engineering.
Each of these types of incidents will receive a response according to a specific set of ITPROSEC procedures. For some of the more serious incidents, it may be necessary to engage outside expertise or additional security resources to assist with investigations.
Given the limited resources, skills and time constraints, each response has been tailored to the current activities and processes. The ITPROSEC is not currently equipped with specialized tools or resources to conduct detailed investigations or gather forensic evidence; rather the ITPROSEC team’s focus is on restoring services and resolving any vulnerability that may have contributed to an incident.
The following flowchart may be used to aid in decision making and to determine the most appropriate steps to take in responding to the more common incidents.
3.5.1 Responding to end user malware
This flowchart is utilized when a minor impact incident has been detected on an end user device. The flow chart below outlines the recommended response process.
A Help Desk (HD) staff member makes a determination as to whether or not it is an actual event by contacting the end-user and/or reviewing the device. If it has been determined that the incident is an actual event, the Help Desk staff member may attempt to clean the contamination with various tools or failing that the device can be re-imaged. During off-hours, the Help Desk may instruct the end user to disconnect the device from the network until the next working day when further assistance will be provided.
3.5.2 Responding to server malware
This flowchart should be used when malware has been detected on one or more servers. The recommended response procedures are as follows:
The process for data exfiltration response should be used for incidents that have an impact rating of negligible to minor. In cases where the data is sensitive in nature the ITPROSEC Information Security Team should be contacted immediately. Recommended response procedures are as follows:
During the initial analysis, it may also be determined that data exfiltration has occurred via malware and therefore responders should go to the end user and/or server(s) response flowcharts as indicated.
3.5.4 Lost or stolen mobile device
This process should be used when a mobile device (e.g. laptop or mobile phone) is lost or stolen. Typically these type of incidents should be rated as minor from an impact perspective unless they are unencrypted or involve large amounts of sensitive or confidential data.
Once the report is received from an end user, the CIO, the end user’s Manager and General Counsel may confer to determine is sensitive information is involved. Any additional actions taken will follow ITPROSEC procedure. If the user notifies the Help Desk of the loss without advising the three assessment and decision makers (CIO, GCO, and Manager), the end user is advised to report the loss to the three decision makers before any further action will be taken.
3.5.5 Outsourced or hosted systems incidents
The following process is utilized for a security event which involves third party services for outsourced or hosted systems. Examples of outsourced or hosted systems include:
- Telus – Network management, managed security services;
- Chase Paymentech – Online payment systems;
- Ceridian Canada Limited – Payroll and HR systems;
- Concur Technologies – Travel and expense;
- SWN Communications Inc. – SendWordNow;
- Diligent – Boardbooks; and
- Microsoft – Office365
Recommended response procedures are as follows:
3.5.6 Infrastructure infiltration
The recommended response process for incidents related to infrastructure infiltration is as follows:
3.5.7 Emergency or catastrophic events
The best options for dealing with incidents that are critical from a functional impact perspective, affect sensitive and/or personal information or integrity from an informational perspective and have an impact on recoverability have generally been identified in the ITPROSEC’s BCP and/or crisis management plans. These options are directly related to the ITPROSEC’s business priorities and related timescales for recovery and the maximum acceptable outage for time periods for IT, voice, people and accommodation.
It is not anticipated that security incidents would be exclusively related to a level 4 service management (Help Desk) incident. Such a significant event could involve widespread outages and serious damage possibly affecting human life or causing serious injuries. Should this be the case then it becomes a Crisis Management response, with/involving Emergency Response and other team interventions beyond the security incident response team.
The following process should be for security incidents that appear they may extend beyond security:
3.5.8 National systems incidents
While the ITPROSEC is not responsible for the Canadian Securities Administrators (CSA) National Systems, there may still be a need to be aware of a National Systems event or incident with internal precautionary measures invoked as necessary. National Systems incidents may involve any of the following systems:
- System for Electronic Document Analysis and Retrieval (SEDAR)
- System for Electronic Disclosure by Insiders (SEDI)
- National Registration Database (NRD)
The process may be utilized for a National Systems hacking event involving multiple organizations in addition to the ITPROSEC with typically significant impacts. The recommended procedures are as follows:
The Help Desk Manager may be enlisted by the CIO to assist with end-user notifications. The CIO may be in contact with the General Counsel’s Office either to provide information or to seek guidance on support activities.
3.5.9 Managed security service provider (MSSP) daily incidents reports
Telus provides daily reports to the ITPROSEC Information Security Manager and the Technical Services Team for review. The following process should be followed for incidents that require a response:
Any unresolved issues may be incorporated into the monthly activities and ongoing initiatives with Telus and should be documented in the monthly reports until resolved.
3.5.10 Other security incidents
Other security incidents may include phishing attacks/attempts and or other social engineering events. The following process should be followed when none of the other previously described incident procedures apply:
Appendix A – Terms and definitions
| Term | Definition |
| Access | Entry to an electronic network provided by the ITPROSEC to employees and other authorized individuals on our outside of the ITPROSEC premises. |
| Access controls | Procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or stored data (logical access control) |
| Authentication | To establish the validity of a claimed identity of a user prior to gaining access (e.g. passwords, access cards). |
| Authorization | To grant permission to access resources according to a predefined approval scheme. |
| De-militarized zone | A segregated zone on part of a network to provide additional protection to sensitive information or to control public access from the Internet. |
| Two-factor authentication | Requires the user to physically possess something (i.e. smartcard or token) in addition to something the user knows (i.e. a password or a PIN). The physical component (i.e. smartcard, token) is independently separate from the desktop or laptop used to conduct the authentication process. |
