Information Security Incident Response Process · Information Security Incident Response Process Page 5 of 32 2 Executive Summary This document provides the processes and instructions

Government of Alberta

Information Security Incident Response Process

[Standard Operating Procedures (SOP)]

June 2019

Corporate Information Security Office

Service Alberta


Page 2 of 32

Table of Contents

1 Version History ....................................................................................................... 4

2 Executive Summary ............................................................................................... 5

3 Background ............................................................................................................. 5

3.1 Policy Context .............................................................................................................. 5

3.2 Scope of this SOP ....................................................................................................... 6

3.3 Purpose of this SOP .................................................................................................... 7

4 Definitions ............................................................................................................... 7

5 Severity Levels ....................................................................................................... 8

5.1 Critical Severity ............................................................................................................ 9

5.2 High Severity ............................................................................................................... 9

5.3 Medium Severity .......................................................................................................... 9

5.4 Low Severity ...............................................................................................................10

6 Incident Management Principles ......................................................................... 10

7 Roles and Responsibilities .................................................................................. 11

8 Process Workflow Chart ...................................................................................... 13

8.1 Process Workflow Details ...........................................................................................14

9 Security Incidents Flowcharts ............................................................................. 18

9.1 GoA Critical / Non-Critical Security Incident Flow Diagram .........................................18

9.1.1 GoA Critical / Non-Critical Security Incident Process Details .............................. 19

9.2 Event Handling Flow Diagram ....................................................................................20

9.2.1 Event Handling Details ............................................................................................. 21

9.3 Lost Assets Flow Diagram ..........................................................................................22

9.3.1 Lost Assets Details ................................................................................................... 23

9.4 Misuse of Account Privileges Flow Diagram ...............................................................25

9.4.1 Misuse of Account Privileges Details ..................................................................... 26

9.5 DNS / Website / Server Compromise Flow Diagram ...................................................27

9.5.1 DNS / Website / Server Compromise Process Details ........................................... 28

10 Security Incident Report ...................................................................................... 31

11 Contact List ........................................................................................................... 31

11.1 Incident Response Team - DutySMO..........................................................................31

11.2 Director of SMO (Security Management & Operations) ...............................................31

11.3 Sector Information Security Officers (Sector ISOs) .....................................................31

11.4 GoA Service Desk ......................................................................................................31


Page 3 of 32

12 References ............................................................................................................ 32


Page 4 of 32

1 Version History

Date Author Version Description of Change

July 19, 2012 Jack Truong 1.0 Initial Draft

July 27, 2012 Security Incident Management Committee

2.0 Minor updates

Nov. 20, 2012 Security Incident Management Committee

3.0 Final

July 29, 2013 Security Incident Management Committee

3.1 Minor update to pg.20

April 15, 2014 Kenneth Lummis 3.2 Change to Service Modernization, Change Archer reference to CISO, Updated on call representation

June 5, 2015 Jack Truong/Chris Agidi 3.3 Change title - in line with best practice, Update new SMO Director, Lost Devices, and added new DNS/Web/Server Compromise process

Mar 28, 2019 Christine Gunarson 4.0 Add components of Information Security Incident Mgmt Policy Advisory Guide and Security Incident Standard into this document. Other minor updates throughout, and replace MISO with Sector ISO

June 25, 2019 Clifton Sandford 4.1 Added Information Security Classification footer – Protected A


Page 5 of 32

2 Executive Summary This document provides the processes and instructions for managing information security Incidents and lessons learned in the Government of Alberta (GoA). It outlines the different types of security incidents that can occur and the detailed workflow processes that the GoA should follow when responding to a security incident. Examples of incidents are included to help determine the severity of a security incident. Information security incidents may be the result of external or internal threats, or discovered in the investigation of break/fix incidents that requires an investigative approach to assessment and resolution. Reporting of all GoA incidents provides visibility and is essential for a comprehensive understanding of enterprise-wide risks. All incidents will be managed consistently by trained personnel. The consistent approach will:

Ensure that incidents are assessed, categorized and handled efficiently.

Ensure all program areas in the GoA have access to services necessary to protect, defend and respond to incidents.

Enhance personnel awareness to recognize and report incidents.

Provides standard process/instruction for evidence collection to maintain a proper chain of custody.

Ensure that lessons learned are applied to improve the incident handling processes, security protective services and security awareness training.

3 Background CISO provides monitoring, incident management and investigative services to ensure risks associated with Information Security Incidents are effectively managed. In the first half of 2012, a Security Incident Management Committee was assembled. The committee consisted of 7 MISO members and 3 CISO members. The objective was to review the security incident management processes used by CISO and MISOs, find improvements in these processes, and develop high level consolidated workflow process. This document is a result of that collaboration. In 2018, the MISO role changed to Sector Information Security Officers and moved from Ministries to CISO, reporting under the Office of the Chief Information Officer.

3.1 Policy Context

This document is a reflection of the GoA Information Technology Security Framework that must be adhered to by all GoA ministries when handling information security incidents.


Page 6 of 32

Users of information and IT systems must take responsibility for and accept the

duty to actively protect GoA information and technology assets, and reporting IT

security events and incidents [Information Security Management Directive #1.3,

Organization of Information Security].

The Deputy Minister of Service Alberta is accountable for monitoring and

reporting security compliance and security incidents across the Government of

Alberta [Information Security Management Directive #1.9, Organization of

Information Security].

Security incidents, breaches or policy violations caused by personnel must be reported to the CISO and reviewed by Management [Information Security Management Directive #3.6, Human Resources].

The criticality of information security incidents must be determined to identify appropriate responses including stakeholders’ communication, and manage remediation activities [Information Security Management Directive #8.1, Incident Management].

Post security incident reviews must be conducted to assess and improve the standard GoA Incident Response Process and to mitigate future information security incidents [Information Security Management Directive #8.2, Incident Management].

All reasonable measures must be taken to ensure personal information is managed to ensure privacy protection and security [The Protecting People’s Personal Information (PPPI)].

Employees are also bound by the government’s Code of Conduct and Ethics that outlines expectations for employees to avoid conflict of interest situations and conduct themselves with impartiality and integrity.

The Government of Alberta’s Internet and Email Use Directive outlines acceptable and unacceptable usage of government information technology systems. The Incident Response Process provides the necessary processes to investigate violations of the Directive.

3.2 Scope of this SOP

Requirements set in this SOP apply to all Ministries. The scope of this SOP includes:

Real or potential information security incidents and privacy breaches.

Information security events.

Potential or physical security breaches as they relate to information and/or system.

Environmental threats, events or incidents as they relate to information security.

http://www.chr.alberta.ca/Practitioners/?file=legreg/code/titlepage&cf=819

http://www.chr.alberta.ca/index.cfm?notoc&file=directives/relations/use-of-information


Page 7 of 32

3.3 Purpose of this SOP

The purpose of this SOP is to:

Ensure that adverse impacts to business processes are reduced by authorizing immediate action to remedy or contain a situation(s), and making certain the correct people receive notification.

Demonstrate commitment to protecting information and respecting rights to privacy and confidentiality.

Ensure prompt reporting of and response to information security incidents.

Follow-up on security incident report recommendations until issue is resolved.

Identify a single point of contact for all security incidents.

Provide instructions for investigating, managing and reporting on information security incidents and privacy breaches.

Communicate information security incidents to the CISO.

Identify the steps personnel are expected to take when reporting security incidents.

Ensure security incidents are categorized and triaged according to Government of Alberta directives and standards.

4 Definitions Event

An Information Security Event is an identified occurrence of a system or service state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant. An Information Security Event, upon analysis, may be determined to be an Information Security Incident, an Information Security Weakness or may not be a security related event of significance.

Examples of o Events include a user connecting to a website or sending an email, a firewall

blocking a connection attempt, a system alert or an individual taking a sensitive file out of the office.

o Adverse events are events with a negative consequence, such as system crashes, network packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malicious code that destroys data. (Based on NIST 800-61)

Security weakness

An Information Security Weakness provides for the potential loss of confidentiality, integrity or availability and is therefore reported and monitored as an information security incident. An untreated Information Security Weakness may evolve into an Information Security Incident.

A weakness in a computer system, network, application or process that may allow an adverse event to take place and may evolve into an information security incident.


Page 8 of 32

Information security incident

Indicated by a single or series of adverse events which have a significant probability of compromising business operations.

When there is a violation of the government’s security policies or when there is a failure or absence of required safeguards providing for the loss or potential loss of confidentiality, integrity or availability.

Within this document, information security incidents will be referred to as incidents. Incident handling/response

The process of identifying, analyzing and mitigating the effects of an incident. Incident response team

The team (also commonly known as a Computer Security Incident Response Team [CSIRT]) is responsible for receiving, reviewing, and responding to computer security incidents and activities. (Based on CERT) Comply with incident handling instructions issued by CISO. The CISO CSIRT is DutySMO.

Incident handler

An Incident Handler is the individual assigned to lead the investigation and make decisions for how to manage an incident. The Incident Handler is responsible for documenting facts about the incident, notifying appropriate parties, collecting and preserving evidence as required, instructing individuals to take specific actions to bring closure to an incident and return operations to normal state. The Incident Handler has authority to direct government personnel and contracted service providers to take actions to manage, resolve and contribute to the investigation of incidents.

The CISO will assign an Incident Handler for all Critical and High severity incidents, all incidents affecting multiple ministries or at the discretion of the CISO.

5 Severity Levels An information security incident is categorized based on its real or potential impact. An incident is assessed and assigned a severity level which determines who is assigned to handle the incident and how quickly to act on the incident. The categorization of an incident can be adjusted as more details of the sensitivity or impact of the incident is acquired. There may be a severity level assigned to a weakness based on the likelihood that the weakness will be exploited and result in a more severe incident. This severity level should drive the response to correcting the weakness. Loss of or damage to data classified at a higher protection level will increase the severity of the incident. Some incidents are related to inappropriate behavior or policy violations by personnel. The severity levels and associated examples are identified below.


Page 9 of 32

5.1 Critical Severity

There has been a violation of the Law using government information technology systems or the level of harm is extreme. There may be imminent or active extreme harm to the security of information, personnel or property and requires an immediate intervention. Examples related to information security incidents:

Property destruction

Bodily harm

Burglary or break-in

Severe financial loss or hardship

Suspected access of child pornography

Copyright violation or illegal software download

Malicious software or other threat agents that have caused: o permanent loss or violation of integrity of government information;

o a prolonged period of unavailability of critical business services; or

o Unauthorized disclosure of protected information.

5.2 High Severity

There has been a policy violation or there has been loss of confidentiality, integrity or availability affecting more than one Ministry in terms of real and perceived affects or the level of harm is high or very high. Examples:

Unauthorized disclosure of information that has potential to cause a high or very high level of harm

Malicious software or other threat agents that have affected a large number of devices/information or caused substantial (but not severe) harm, such as Ransomware data encryption

Loss or compromise of more than one user’s authentication credentials

Violation of visitor sign-in or escort policy with some measurable impact

Evidence of an unsuccessful attempt to break-in to a government facility or information technology system

5.3 Medium Severity

There has been a policy violation or there has been loss of confidentiality, integrity or availability but the level of harm is low or medium and limited to one Ministry in terms of real and perceived affects. Examples:

Loss or compromise of a single user’s authentication credentials

Lost or stolen laptop, phone, mobile device or other computer equipment

Violation of Internet and Email Acceptable Use Policy (but no illegal activity)

Suspected unauthorized sharing of user accounts

Unintentional computer actions (e.g. user reporting strange behavior on PC)


Page 10 of 32

Unauthorized scans or probes of GoA resources, from unknown sources

Device accessible from internet that should be restricted to GoA

A server sending unusual messages (e.g. to IRC servers)

Detection of unknown or rogue devices connected to GoA network

Malicious/targeted attempts to e-mail internal government accounts

Malicious software that has affected a small number of machines, did not cause substantial harm and where the threat has been neutralized but clean-up is required

Violation of visitor sign-in or escort policy with no apparent impact

5.4 Low Severity

There is a real or perceived security warning or weakness that may result in a loss of confidentiality, integrity or availability if acted upon by a threat agent. The weakness does not appear to result in an immediate consequence. Examples:

Low or Medium vulnerability identified through vulnerability scanning on a government web site or infrastructure

Entrance way to a controlled area (e.g. office space) left open but no obvious loss or damage

6 Incident Management Principles Information security incidents must be investigated and managed by trained Security Incident Handlers. Incident investigation and management should be carried out according to the principles set out in this section.

Mitigate Immediate Threats. The Information Controller should take steps to mitigate further damage by active threats through actions such as isolating target systems and devices from the Government information technology infrastructure.

Integrity of Evidence. Where criminal activity or policy violation is suspected, only authorized personnel may participate in the investigation to ensure evidence is preserved and admissible in legal proceedings.

Confidentiality and Need-to-Know. Information about Incident investigations, including those supporting PSC investigations, must be treated with sensitivity and disclosed on a need-to-know basis.

Separation of Duties. Incident Handlers must not investigate or manage incidents if they were involved in the circumstances that led to the Incident.

Security Clearance. Incident Handlers must have a security clearance commensurate with the sensitivity of the Incident they are investigating.

Return to Normal Operating State. Incidents may disrupt normal business operations. Incident Handlers must take steps and give direction to minimize


Page 11 of 32

additional disruption to what is required for adequate investigation and assist a return to normal operating state.

Documentation. The usage of ITSM platform must be used to report, track and monitor Security Incidents and Weaknesses.

7 Roles and Responsibilities

A RACI chart identifies who are Responsible, Accountable, Consulted and/or Informed.

The following RACI chart depicts the high level roles and responsibilities when managing information security incidents. The chart is meant to identify roles at a high level for each of the four main phases. IT System or Service support teams may have their own additional detailed security incident processes. 1 2 3 4

Tasks/Phases

Roles

Detection and

Reporting Phase

Assessment and

Decision Phase

Response Phase

Lessons Learned Phase

Incident Reporter (includes Program or Worksite Employee, Contractor or Agent, etc…)

R I

Managers and Supervisors I I

Incident Handler R R C

Information Custodian C R/C I

Sector Information Security Officer I C C R/C

Ministry Information Privacy Officer (IPO) I C C R/C

Sector Chief Information Officer (CIO) I R* I

Information Controller I R* I

Corporate Information Security Office (CISO) I C C/I C/R*

* As per Directive #1.9 the Deputy Minister of Service Alberta is accountable for monitoring and reporting security compliance and incidents across the Government of Alberta. Step 1: The Incident Reporter who detected the incident is responsible to report it to their immediate supervisor(s) or manager(s). The IPO/CISO is notified accordingly. Step 2: Once the Information Custodian, IPO, and CISO are consulted, an Incident Handler is assigned (can be a Sector ISO or CISO delegate). It is the Incident Handler that is responsible in assessing whether a security incident occurred or not, after interviewing the Incident Reporter. Step 3: The Incident Handler with assistance from the Information Custodian is responsible for notifying and assigning work to the appropriate teams to contain and remediate the security incident, and fill out the Security Incident Report. The Sector ISO, IPO, and CISO should be


Page 12 of 32

consulted in this response phase. The Information Controller is responsible for remediation of the incident. Step 4: The CISO and/or IPO is responsible for consulting with the Incident Handler to determine if any findings during the investigation could be used to apply to “lessons learned”.


Page 13 of 32

8 Process Workflow Chart


Page 14 of 32

8.1 Process Workflow Details

Responsibility Action

Detection and Reporting Phase

Incident Reporter (GOA Program or Worksite Employee, Contractor or Agent, etc.)

1. Identify a real or potential security incident or receive complaint or notification from another source, such as an anonymous submission or complaint from the Office of the Information and Privacy Commissioner. (OIPC)

2. Notify your supervisor or manager with details of the incident and any action already taken.

3. If urgent, take immediate steps to remedy the situation. Do not, under any circumstances, attempt to prove a suspected weakness. Testing weakness could cause damage and may be interpreted as a potential misuse of the system and result in legal liability for the individual performing the tests.

4. Contact the Service Desk, and then notify your security representative (Sector ISO) as soon as possible and without jeopardizing personal safety.

5. Continue to make every effort to recover lost or damaged assets; or contain source of potential breach, while awaiting instructions from the Incident Handler.

Incident Handler (Sector ISO/CISO)

6. Receive notification from internal or external source.

7. If circumstances dictate, provide instructions on containing the security incident.

8. Contact DutySMO to:

Assign an Incident Handler

Determine next steps

Evaluate the level of urgency

DutySMO 9. Determine the Incident Handler. In the event that the incident affects several ministries and no lead area is apparent, the CISO assumes the role of Incident Handler.

Assessment and Decision Phase

Incident Handler 10. Contact Incident Reporter to clarify and assess the nature and scope of the security incident.

11. Provide a high level description of security incident response so the Incident Reporter knows what to expect.

Incident Reporter 12. Promptly provide the information requested.

Incident Handler 13. Assess whether a security incident occurred.

14. If the security incident is a false alarm, notify DutySMO and the Incident Reporter. Follow-up with training, as required, log and close the incident ticket.


Page 15 of 32

15. If the security incident is valid, determine whether the incident has been contained and what, if any, action has been taken to date. Proceed to the “Response Phase” section of this procedure.

Response Phase

Incident Handler 16. Identify the appropriate Information Controller(s).

17. Notify the Information Controller(s), if this has not previously occurred.

Incident Reporter 18. Follow any instructions provided by the Incident Handler.

19. Under the direction of the Incident Handler, take immediate steps to contain the situation:

Do nothing, unless instructed by DutySMO.

Stop an unauthorized practice.

Cease activities intended to contain the situation already underway.

Other actions, determined by the Incident Handler.

Incident Handler 20. Discuss response actions to be taken with the Information Controller and recommend next steps, as required.

DutySMO 21. Identify initial severity and if circumstances dictate, initiate procedures to:

Recover records.

Move records to a secure facility.

Change door locks.

Revoke an individual’s access to the electronic communication system.

Temporarily shut down a server or workstation.

Disable a device.

Remove a file or record from a public website.

Contact local authorities.

Change the password.

Other actions, merited for the incident.

Incident Handler 22. Collaborate with DutySMO and assign tasks to relevant DutySMO members as needed.

23. Track and follow up on assigned tasks.

24. Work with DutySMO to identify measures or precautions to preserve evidence required for internal problem analysis, forensic evidence and/or negotiating for compensation from a vendor, where possible. Examples could include:

Placing holds on records or logs pending destruction.

Disabling user accounts, to prevent tampering or destruction of evidence.

Protecting data obtained from intrusion detection systems against unauthorized disclosure, modification or destruction.

Turning off and securely storing computers involved in hacking or compromising system(s).


Page 16 of 32

Copying and archiving logs, backing-up impacted systems.

Etc.

25. Obtain direction from CISO management if documenting evidence collection is required.

26. Determine who else is already aware of the incident.

27. Assess who has access to live systems, data or records and whether access needs to be limited.

28. Re-evaluate the severity associated with the incident.

29. Evaluate the risks associated with the incident. If necessary, review existing or initiate the Statement of Sensitivity (SoS) or Privacy Impact Assessment (PIA) procedures.

30. If the incident criticality warrants, identify which DutySMO members will notify relevant partner Ministries.

31. Escalate to the DutySMO co-sponsors, as needed.

Information Privacy Officer (IPO)

32. Review any Privacy Impact Assessments (PIA) related to the incident and determine if the current event had been previously identified, as a risk.

33. Determine whether the PIA recommendations were adequate or followed and whether this information could be used as applied to “lessons learned”.

34. Any other actions deemed necessary.

Information Controller

35. Consider the following when determining who else needs to be made aware of the incident:

Injury, harm or loss of life.

The severity of the real or potential incident.

Overall impact on service delivery to citizens.

The type of theft.

Damage to trust relationships.

Financial loss.

Business disruption.

Risk to personal information.

Compliance with policy and legislation.

Incident Handler 36. Contact the Information Controller and collect details for the security incident report.

37. Complete the security incident report.

38. Log the incident.

Information Controller

39. Provide the details of the incident to the Incident Handler.

Incident Handler 40. Continue to follow up with the Incident Reporter and/or Information Controller until issue resolution or closure, and send report to CISO.

Lessons Learned Phase

Sector ISO 41. Update the risk registry as required. 42. If necessary, review any STRA(s) related to information

security systems, sites or programs involved in the incident.


Page 17 of 32

43. Determine if the current event had been previously identified as a risk.

44. Determine whether the STRA recommendations were adequate or followed, and whether this information could be used to apply to “lessons learned” or ongoing process improvement.

Incident Handler 45. Identify and review other assessments or analysis relevant to the security incident.

46. Communicate recommendations to remedy the situation and prevent future occurrences, as required.

47. Follow-up on recommendations and any ongoing risks

48. Update and close the Incident ticket.

DutySMO 49. Discuss trends at the weekly Team meeting. 50. Determine whether this information could be used to apply

to “lessons learned” or ongoing process improvement.


Page 18 of 32

9 Security Incidents Flowcharts

This section provides additional details about the different types of security events that may occur and incident response processes for them. Note this is from the GoA domain perspective, but is at a high level so that Ministries can apply any additional internal security incident steps.

9.1 GoA Critical / Non-Critical Security Incident Flow Diagram


Page 19 of 32

9.1.1 GoA Critical / Non-Critical Security Incident Process Details

1. Security incidents can be reported from multiple sources. It is up to the Sector ISO and/or CISO to assess incidents and act accordingly.

2. If it is deemed a critical security incident or impacting multiple ministries, the CISO will be the Incident Handler. If there is an immediate and extreme risk to GoA, CISO will take action to minimize losses and notify the CISO Executive Director, Directors and Sector ISO; and document all actions taken.

3. If it is a non-critical incident, the Sector ISO will be assigned as the Incident Handler. Note: This is a high level process overview workflow. Refer to the other workflow diagrams later in this document as to the specific type of incidents (i.e. lost fobs), and whether or not it is in the GOA domain or ministry idomain.

4. Once the investigation is completed, the Incident Handler will create a security incident report and send it to DutySMO within 5 business days.

5. CISO will follow up with the Incident Handler every 5 business days to ensure the report is completed and submitted to DutySMO in a timely manner. CISO will review the report for completeness before the report is filed and ticket is closed.

6. After two unsuccessful attempts to obtain the report from the Incident Handler, the DutySMO analyst will send a final request for the report to the Incident Handler and give a 5 day deadline (provide specific date/time) to complete the report. Each request for the report will be recorded in the ticket work log.

7. If the Incident Handler has not provided an incident report by the deadline, the ticket will be marked as “incomplete” and resolved.


Page 20 of 32

9.2 Event Handling Flow Diagram


Page 21 of 32

9.2.1 Event Handling Details

1. This includes computer viruses, worms or high-risk activities (i.e. Bots, Trojans, viruses, DoS, scans, etc.), that have been triggered by the Intrusion Detection and Prevention System (IDPS) alerts, suspicious host report, Shadow Server Report, Canadian Centre for Cyber Security (CCIRC) or elsewhere. In such cases CISO should be informed.

2. CISO will identify the affected device(s) from the source and destination IP addresses, and assess the security event/alert that occurred. If it is deemed a security incident, a ticket will be created.

3. If the device is within the GOA domain, CISO will identify the user logged on during the time of the incident, and notify the Sector ISO for that ministry. CISO will be the Incident Handler.

4. If it is a workstation, CISO will create a ticket for the AVS Team to investigate. If needed, the Worksite Support Team can make a site visit.

5. If it is a server, CISO will create a ticket for the Server Team or the appropriate service support teams (Duty Web, Duty App, or Duty DBA) to investigate and remediate.

6. Once the technical teams complete their investigations, the details will be provided to DutySMO. CISO will complete the security incident report, and forward a copy to the Sector ISO and close the ticket.

7. If it is not within the GOA domain, the Sector ISO will be notified with the details of the security incident and some instruction from CISO as to what is needed to be followed up. The Sector ISO will be the Incident Handler and engage the system/service owner and follow their internal processes to identify and remediate the situation. The CISO can provide guidance as required.

8. Once the investigation is completed, the Sector ISO will create a security incident report and send it to DutySMO for review and close the ticket.


Page 22 of 32

9.3 Lost Assets Flow Diagram


Page 23 of 32

9.3.1 Lost Assets Details

1. User reports a lost or stolen asset to the GoA Service Desk to have the device wiped or disabled (as applicable).

2. After Step 1 is completed, the user can report the lost/stolen asset to the Ministry Contact and inform Telecom Coordinator or SRC to cancel the plan.

3. The Service Desk determines if the lost or stolen asset belongs to GoA or an idomain.

4. If the asset belongs to an iDomain, the Service Desk gathers all the information pertaining to the incident and sends it via email to the appropriate Sector ISO. a) The Sector ISO notifies the Ministry Privacy, FOIP, Seniors Records Officer (SRO), Sector CIO and CISO as required. b) The user of the device provides details to the Sector ISO and reports a stolen device to the Police. Technical support can either remote wipe or disable the device as appropriate. c) The Sector ISO documents the information and files a security incident report.

5. If the asset belongs to GoA, the Service Desk creates two tickets: One for

themselves to wipe or disable the device and the other ticket assigned to CISO. a. If the Service Desk is having issues/difficulty wiping or disabling the

device they will create another ticket and have the technical support team wipe or disable the device. The ticket for the technical support team will be related to CISO's ticket.

b. Once the technical support team has wiped or disabled the device, they will resolve the ticket. Note: If there are any errors or further complications in wiping or disabling the device, then the technical support team will document all this in their ticket.

6. CISO determines if the device is a FOB, Cell Phone, Laptop or a Tablet:

a. Device is a FOB (RSA Token) CISO confirm that the FOB was disabled. CISO sends email notification to Sector ISO including all details for the incident. CISO advise the Sector ISO to follow-up with the user regarding security awareness, training and best practices. If user was out of Canada with their device, provide link to CISO tip sheet: International Travel with GoA Mobile Devices. CISO close ticket with “All details contained in the ticket – no security incident report required”.

b. Device is a Cell Phone CISO confirms that the wipe command has been sent to the cell phone. If the cell phone was not found in the MDM, this could be because user has already reported it to their Telecom rep who has removed it from their system. Or that the cell phone is not on GoA MDM.


Page 24 of 32

CISO sends email notification to the Sector ISO including all details for the incident. CISO advise the Sector ISO to follow-up with the user regarding security awareness, training and best practices. If user was out of Canada with their device, provide link to CISO tip sheet: International Travel with GoA Mobile Devices. CISO close ticket with “All details contained in the ticket – no security incident report required”.

c. Device is a Laptop or Tablet CISO sends email notification to the Sector ISO including all details for the incident. If there was no data on the laptop, then no security incident report is required. If there was Protected data on the laptop, then a security incident report is required. Advise the Sector ISO to confirm that laptop is encrypted. Sector ISO will notify their Privacy or FOIP representative as required. CISO advise Sector ISO to follow-up with the user regarding security awareness, training and best practices. If user was out of Canada with their device, provide link to CISO tip sheet: International Travel with GoA Mobile Devices. CISO will review the security incident report and provide any feedback to the Sector ISO for update. Once completed, CISO will file the report and close the ticket.


Page 25 of 32

9.4 Misuse of Account Privileges Flow Diagram


Page 26 of 32

9.4.1 Misuse of Account Privileges Details

1. When the Incident Reporter discovers an ID account misuse, CISO must be notified if the account is part of the GOA domain. CISO will create an ITSM security incident ticket for tracking.

2. If it is within the GOA Domain, CISO confirms if misuse has occurred and becomes the Incident Handler. CISO will engage the appropriate technical support teams as required. a) CISO collects incident details, and gets direction from the Sector ISO to determine a solution (correct, accept or delete the misuse). CISO notifies the appropriate parties and creates a ticket assigned to Domain Admin of the work that is required. b) The Domain Admin performs the work and updates their ticket. CISO prepares the security incident report and notifies the Sector ISO.

3. If it is not within the GOA Domain, the Sector ISO will be notified and will follow their internal processes to identify and remediate the account and misuse in question. a) The Sector ISO collects the incident details, determines a solution (correct, accept or delete the misuse), notifies the appropriate parties and submits a ticket assigned to Domain Admin of the work that is required. b) The Domain Admin performs work and reports the details to the Sector ISO, who updates the security incident report and forwards it to CISO. c) As GoA and iDomain services are often inter-related, CISO reviews the security incident report and provides comments and recommendation. When the report is complete, CISO files the report and closes the ticket.


Page 27 of 32

9.5 DNS / Website / Server Compromise Flow Diagram


Page 28 of 32

9.5.1 DNS / Website / Server Compromise Process Details

1. The Incident Reporter (i.e. user, IT support) who noticed that an incident has

occurred is to report it to the GoA Service Desk (SD), and optionally .cc DutySMO if they believe it could be a security incident in progress.

2. The GoA SD will collect the details of the compromise.

3. The GoA SD will follow the Right Answers’ article to determine whether or not the incident is a DNS Hijacking, Website Defacement, or Server Compromise security incident, and assign the appropriate priority.

4. The GoA SD will then create 2 incident tickets: 1st ticket will be assigned to CISO; the 2nd ticket will be assigned to the appropriate support teams as per the Right Answers’ article.

5. For this particular process, if it is NOT a DNS Hijacking, Website Defacement, or Server Compromise type incidents, the GoA SD will follow their normal Incident Creation Process.

6. CISO will analyse the incident and verify if the incident was identified correctly.

7. If the incident is a Domain or DNS Hijacking, the following symptoms may exist: a. The Government of Alberta (GoA) website URL is redirected to a different

URL that is not owned by GoA.

b. Go to https://www.webnames.ca/whois.aspx (use other tools if needed) and enter in the GoA URL; if any of the information shown is not GoA, the domain is most likely hijacked.

c. By doing a Google search with "site:your-page.com" the "hijacking" page will be listed. You will find the "hijacking" page by searching for your domain name.

d. By doing a Google search with "cache:http://www.your-page.com", you will see the hijacking domain name instead of yours in the first line of the cached page.

8. If the incident is a Website Defacement, the following symptoms may exist: a. The webpage’s content may have been changed or partially changed or fully

replaced by another page.

b. The webpage’s content may contain inappropriate content and/or images.

c. The webpage’s hyperlinks may have been changed and could redirect users to a malicious or inappropriate website.

d. The main webpage may not load, but instead redirects users to a malicious or inappropriate website

e. The administration section may have been changed to lockout all valid accounts for that site.

f. Unusual popups while browsing the website that was not there before, or should not be there.

9. If the incident is a Server Compromise, the following symptoms may exist: a. GoA logon banner changed.

b. Anti-Virus scans detected malware.

https://www.webnames.ca/whois.aspx


Page 29 of 32

c. Website hosted on the server has changed or defaced; most likely will be the homepage.

d. Large quantities of 404 page not found errors with suspicious file names

e. Non-standard programs installed.

f. Admin accounts/passwords changed.

g. Unknown accounts created.

10. If it is identified that this is not one of the security incidents noted above, CISO will click the Incorrectly Routed Ticket option in the ITSM ticket and update the Work Log to give instructions to reassign the ticket as a break/fix ticket and assign to the appropriate support team for the impacted device/system/service.

11. If it is one of the above security incidents, CISO will need to determine whether or not the domain, site or server is managed by GoA.

12. If it is managed by another ministry, CISO will engage the Sector ISO for that ministry.

13. The Sector ISO will then contact the ministry’s support teams and follow their incident management process. Sector ISO will keep CISO updated with progress and decisions made.

14. Once resolved, the Sector ISO will create a security incident report and send to CISO.

15. If the incident is managed by Service Alberta, DutySMO will notify CISO management and the impacted Sector ISO.

16. DutySMO will then engage Corporate Incident Management (CIM). CIM will manage this incident, with close involvement from CISO and the Subject Matter Experts, including the impacted Sector ISO.

17. CIM will setup a conference call with appropriate support teams including Sector ISO ASAP.

18. CIM will coordinate the creation of Master ticket, child tickets and required tasks for support teams. CIM will work with CISO on a communication if required.

19. If the security incident is a DNS Hijacking, the ticket should already been assigned to DutyCerts by SD. DutyCerts will notify CISO of incident. DutyCerts will be contacting the registrar for that compromise domain and work towards a resolution. DutyCerts will keep in touch with CIM and CISO with hourly updates.

20. If the security incident is a Website Defacement, the ticket should already been assigned to DutyWeb by SD. DutyWeb will notify CISO of incident. DutyWeb will be following their website security incident handling process and work towards a resolution. DutyWeb will keep in touch with CIM and CISO with hourly updates.

21. If the security incident is a Server Compromise, the ticket should already been assigned to DutyOSS by SD. DutyOSS will notify CISO of incident. DutyOSS will be following their server security incident handling process and work towards


Page 30 of 32

a resolution. DutyOSS will keep in touch with CIM and CISO with hourly updates.

22. Other support teams (i.e. MSS, NetOps, DNS, AV, Forensics) may be engaged by CIM as required.

23. Once a resolution is found, support teams will need to communicate back to CIM and CISO to discuss the options, if any, regarding restoration.

24. Approval will need to be obtained from management or ministry, before the chosen resolution steps can be taken to restore the compromised service.

25. The restoration process can begin after the approval has been provided by the ministry. Support teams will create change tickets and schedule work appropriately.

26. CIM will collect all details and send out an updated communication, as required. The master ticket will only be closed after all work has been completed.

27. CIM will gather the details from support teams and document the lessons learned (what worked and what didn’t).

28. CISO will create a Security Incident Report, resolve the security incident ticket and provide a copy to the Sector ISO.


Page 31 of 32

10 Security Incident Report The Information Security Incident Reporting Form template is located on the CISO website http://www.servicelink.gov.ab.ca/security/Guidelines.cfm. The Sector ISO may use their own forms when collecting information from the users, but when submitting the final details of the investigation to CISO, please ensure the information is transferred on to this template.

11 Contact List

11.1 Incident Response Team - DutySMO

Where noted in this guide, the CISO DutySMO Team is advised of incidents through the GoA Service Desk, who will create an ITSM ticket and automated notification is sent.

Incident Response Team [email protected]

11.2 Director of SMO (Security Management & Operations)

For questions about this Information Security Incident Response Process, operation of the CISO Incident Response Team (DutySMO), or escalations, please contact:

Clifton Sandford (primary) Stuart Lee (backup) [email protected] [email protected]

11.3 Sector Information Security Officers (Sector ISOs)

Contact information for the Sector ISOs can be found on the Government of Alberta CISO website www.servicelink.gov.ab.ca/security.

11.4 GoA Service Desk

Users should contact the GoA Service Desk to report Information Security Incidents. (Exception is users currently working in iDomain ministries – should notify their point of contact assigned by the ministry.)

GoA Service Desk [email protected] 1-888-427-1462

http://www.servicelink.gov.ab.ca/security/Guidelines.cfm

mailto:[email protected]



http://www.servicelink.gov.ab.ca/security



Page 32 of 32

12 References 1. ISO/IEC 27018: 2014 - Information technology – Security techniques – Code of

practice for protection of personally identifiable information (PII) in public clouds acting as PII processors.

2. Province of Alberta Personal Information Protection Act, December 15, 2017. 3. Province of Alberta Freedom of Information and Protection of Privacy Act, March

1, 2018. 4. Cyber Incident Monitoring and Response (CIMR) Service Plan – 2017 to 2020. 5. Protecting People’s Personal Information (PPPI) Policy Final – July 12, 2007.

6. Handbook for Computer Security Incident Response Teams (CSIRTs), Second Edition. Carnegie Mellon University, April 2003.

7. Computer Security Incident Handling Guide, National Institute of Science and Technology Special Publication 800-61 Revision 1. April 2008.

8. Government of Alberta Information Security Incident Report template, Corporate Information Security Office (www.security.gov.ab.ca).

9. Completing an Information Security Incident Report, Corporate Information Security Office (www.security.gov.ab.ca).

http://www.security.gov.ab.ca/

http://www.security.gov.ab.ca/

Documents

Information Security Incident Response Process · Information Security Incident Response Process Page 5 of 32 2 Executive Summary This document provides the processes and instructions