Introduction

People who live in areas prone to natural disasters such as a hurricanes or wildfires understand planning and preparation prior to the disaster vastly improves the response and outcome to the event. An Incident Response Program is the equivalent planning for potential digital disaster events. As Connor Group continues to grow in visibility and success, malicious attempts to compromise or extort the company are inevitable. Connor Group Information Security’s first priority is to keep these events from occurring; with the second priority being to minimize the impact for when they do occur. When an incident is detected or reported, the ability to effectively respond to security incidents is paramount. Having a documented and practiced response is essential to best minimize impact of adverse events and to protect company assets. The Incident Response Program and associated Standard provide the framework and governance for responding and recovering to security incidents.

 

This standard codifies expectations for proper reporting and response of security incidents for Connor Group. This standard is one in a set of documents that together, form Connor Group's Information Security Management System (ISMS). 

 

Purpose

The Incident Response Program exists to improve the process of identifying and recovering from security incidents. This is accomplished through establishing expectations on how to report and escalate potential events as well as how to respond and recover from such events. The continual refinement of this program streamlines the ideal decision-making and communication processes during an event.

 

Scope

All staff and Third Parties responsible for the management of IT Systems or Identities must understand and follow the requirements herein. 

 

All Connor Group employees are expected to understand the necessity of reporting suspected or actual security incidents to IT or Information Security.  

 

In the event of uncertainty regarding the applicability of this Standard, contact Information Security for clarification and/or guidance at [email protected].  

 

Definitions

References for terminologies or acronyms used within Information Security Standards can be accessed within the Glossary of Definitions (https://helpdesk.connorgp.com/a/solutions/articles/11000112202)

 

Standard

Adherence to requirements in this standard is mandatory.

 

 

1. DETECTION and REPORTING

 

Ref

Requirement

1.1

All Connor Group employees or contractors shall be trained on the expectation of reporting potential or actual security incidents to IT through identified channels.

 

1.2

Connor Group IT shall be trained and required to gather as much initial information on reporting as possible, such as:

  1. Known or suspected assets affected (identities, computers, networks, services, etc.)
  2. Location of asset and reporter
  3. Date and time of reporting
  4. Date and time of first suspected issue
  5. Supplemental information of asset activity before the incident was reported

 

1.3

IT Communication mediums should include email and phone options at a minimum for reporting a security incident.

 

1.4

IT shall establish and maintain a system to receive and alert on potential security incidents. The system to receive information regarding potential security incidents must be available to receive submissions from both employees and non-employees.

 

1.5

Connor Group IT must notify the Director of Information Security for all security incidents, whether suspected or confirmed. If acknowledgement of the notification cannot be obtained from the Director of Information Security, IT must notify the Director of IT or the CIO for confirmation of receipt. 

1.6

Potential and confirmed Security Incidents are classified as Confidential, with incident details restricted to authorized personnel only.

 

2. RESPONSE and MITIGATION

 

Ref

Requirement

2.1

Information Security shall establish an Incident Response playbook containing documented action plans for the following at a minimum:

  1. Business Email Compromise
  2. Account Compromise
  3. Reported Phishing Message
  4. Ransomware

 

2.2

Incident Response plans shall be designed to follow the NIST incident response life cycle, focusing on Containment, Eradication, and Recovery.

2.3

Each confirmed incident requires an Incident Summary and postmortem to capture lessons learned and potential remediation actions.

 

2.4

Incident Response playbooks shall be reviewed for validity and improvement annually or upon execution, whichever is sooner.

 

 

3. COMMUNICATIONS

 

Ref

Requirement

3.1

IT shall establish a communications and escalation process for the sharing of security incidents with appropriate groups such as HR, Legal, and Connor Group Executive Leadership.

3.2

At a minimum, the agent actioning an Incident Response playbook must notify Information Security or the Director of IT regarding the activity.

 

3.3

IT shall create and maintain a communications plan that includes the establishment and operation of a secure Emergency Bridge for the coordination of work and dissemination of information during an event.

 

 

 

Compliance

Information Security team shall verify compliance to this standard through various methods, including but not limited to; process review, monitoring, business tool reports, internal and external audits, and through feedback to the standards owner. 

 

Any exceptions to this Standard require a formally approved exemption documenting justification and approval against compliance to this Standard. Exemption approvals are required prior to the System entering live operation.

 

The following are required to adhere to this Standard, except where a formal exception has been granted as above: 

  • All Connor Group employees, independent contractors, and subcontractors. Any individual found to have violated this Standard may be subject to disciplinary actions including termination and legal recourse. 
  • Any Third-Party System that used to support Connor Group data and/or Services. Any Third Party that violates this Standard will be considered to have breached their contract with the Connor Group.

 


 

Revision History

Revisions require approval by the Director of Information Security and dissemination to applicable business units prior to release.

 

Version 

Detail 

Author 

Date 

1.0

Initial Document

Connor Group Information Security

Sept 2024

1.1

Format Revision

Connor Group Information Security

Oct   2024

 

 

 

 

 

 


 

 

Appendix 1 - Examples of Information Security Incidents

Examples of common Information Security Incidents are listed below. It should be noted that this list is not exhaustive.

Malicious

  1. Giving information to someone who should not have access to it - verbally, in writing or electronically.
  2. Computer infected by a virus or other malware.
  3. Sending a sensitive e-mail to 'all staff' by mistake.
  4. Receiving unsolicited mail of an offensive nature.
  5. Receiving unsolicited mail which requires you to enter personal data.
  6. Finding data that has been changed by an unauthorized person.
  7. Receiving and forwarding chain letters – including virus warnings, scam warnings and other emails which encourage the recipient to forward onto others.
  8. Unknown people asking for information which could gain them access to company data (e.g. a password or details of a third party).

Misuse

  1. Use of unapproved or unlicensed software on Connor Group, Inc. equipment.
  2. Accessing a computer database using someone else's authorization (e.g. someone else's user id and password).
  3. Writing down your password and leaving it on display / somewhere easy to find.
  4. Printing or copying confidential information and not storing it correctly or confidentially.

Theft / Loss

  1. Theft / loss of a hard copy file.
  2. Theft / loss of any Connor Group, Inc. computer equipment.

Other Examples of Possible Security Incident Indicators

  1. Uncontrolled system changes.
  2. Access violations – e.g. password sharing.
  3. Breaches of physical security.
  4. Non-compliance with policies.
  5. Systems being hacked or manipulated.
  6. Inadequate firewall or antivirus protection.
  7. System malfunctions or overloads.
  8. Malfunctions of software applications.
  9. Human errors