PURPOSE
This document details the steps taken to establish and manage an incident process response. It consists of the information detailed in steps 17.1-17.6 of the CIS Controls. Please note that this document primarily focuses on incident responding and handling, and that recovery is addressed separately.
REQUIREMENTS
It is required to own a copy of the incident responder handbook.
CONTROLS
17.1 – Designate Personnel to Manage Incident Handling
Key personnel (both primary and backup) will manage the enterprise’s incident handling process. These personnel are responsible for coordinating and documenting incident response and recovery efforts. The management team can consist of either internal employees, third-party vendors, or a combination of both. If a third-party vendor is used, one or more internal employees should be assigned to oversee all work they complete. The employees who currently address internal issues are Darin Anderson and Andy Albrecht. External issues are addressed by SecqureOne.
This process should be reviewed annually, or when significant enterprise changes occur that could impact this safeguard.
17.2 – Establish and Maintain Contact Information for Reporting Security Incidents
Contact information should be established and maintained for all parties that need to be informed of security incidents. These contacts may include the following:
· Internal employees (namely, department heads who will then assign tasks to the appropriate employee(s))
· Third party vendors (SecqureOne being the primary contact here)
· Law enforcement
o Financial crimes unit for financial crimes (phone number 619-531-2000)
o Regional cyber security forensics lab for cyber crimes (phone number 858-638-7400)
· Cybersecurity insurance providers
· ISAC partners (Co-op that addresses company cybersecurity issues)
· Relevant government agencies
· Legal counsel
· Shareholders
Contact information should be verified on an annual basis in order to ensure information is up-to-date.
17.3 – Establish and Maintain an Enterprise Process for Reporting Incidents
An enterprise process for the workforce should be established and maintained in order to report security incidents. The optimal process for incidents is for all work to be completed in Dreamtsoft. For internal incidents, the process should consist of the following steps:
A. The Service Desk alerts the incident response team.
B. The Service Desk then creates an incident record on the Workspaces page in Dreamtsoft.
C. A problem record is then created on the ITSM page in Dreamtsoft, and the incident record is then linked to it.
The problem record should include the following information:
· The timeframe in which the issue occurred
· Who identified the issue
· How they identified the issue
· All events that’ve occurred and work completed
· Personnel to report to
· Mechanism for reporting
· The minimum information to be reported
External incidents will follow the same procedure once the client has submitted a ticket into Dreamtsoft and a Service Desk technician has discussed the issue with them.
It should also be detailed whether this is a security event (where preventative action was taken that prevented a breach or compromise from occurring) or a security incident (where a breach or compromise did occur).
The process should be publically available to the entire workforce.
This process should be reviewed annually, or when significant enterprise changes occur that could impact this safeguard.
17.4 – Establish and Maintain an Incident Response Process
An incident response process should be established and maintained in order to address roles and responsibilities, compliance requirements, and a communication plan.
In the case of an incident, centrexIT is the incident responder, and coordinates and communicates to all needed resources. In addition to the incident responder, other resources utilized may include the following:
· Client corresponder to lead communication (vITMs and vCIOs)
· IT team lead
· Security team lead
· Forensics team lead (usually an internal resource, but can be an external consultant)
· Bitcoin or other cryptocurrency partner (in cases where data has been encrypted and the client wants to pay the ransom, the partner will set up an account for them)
· Legal partner (evaluates state of network and determines repercussions of getting breached)
· Cybersecurity insurance partner (this contact may also reach out to the legal and forensics contacts to consult)
This process should be reviewed annually, or when significant enterprise changes occur that could impact this safeguard.
17.5 – Assign Key Roles and Responsibilities
Key roles and responsibilities should be assigned for incident response. The staff assigned to work on the incident response may include (as applicable) the following departments:
· Legal
· IT
· Information Security
· Facilities
· Public Relations
· Human Resources
· Incident responders
· Analysts
These roles and responsibilities should be reviewed annually, or when significant enterprise changes occur that could impact this safeguard.
17.6 – Define Mechanisms for Communicating During Incident Response
This safeguard determines which primary and secondary mechanisms will be used to communicate and report during a security incident. These mechanisms can include phone calls, emails, or letters. If possible, both primary and secondary phone numbers and email addresses for all contacts should be retained. When using email for communication, please bear in mind that this mechanism can be affected during a security incident. As such, a Signal account (an encrypted communication system) should be set up for everyone involved, in order to prevent any hackers monitoring emails from discovering which resource is the incident responder.
These mechanisms should be reviewed annually, or when significant enterprise changes occur that could impact this safeguard.