Implement Incydr: Determine incident response
Overview
This article provides best practices for determining how to respond to incidents identified using Incydr.
Considerations
Code42 Insider Risk Advisors can help you determine responses for incidents brought to light using Incydr. Contact your Customer Success Manager (CSM) to engage Advisory Services.
Best practices for incident response
Assume positive intent
If you identify file movement that is unauthorized, start by assuming that the user did not intend anything malicious. Notify the user of the event and remind them of corporate policy. In most cases, the file misuse was unintentional. Taking an empathetic approach makes your users allies instead of adversaries, and helps them be more compliant in the future. Use Code42 Instructor to educate your users about proper file handling.
Consult with the wider group
Consult with your insider risk working group or cross functional team members to discuss workflow processes for the range of incident severity types. For information on creating an insider risk working group, see our video series 8 Steps to Building an Insider Threat Program and our article in this series on developing an insider risk program.
Determine when exposures are reviewed
Decide when to review exposures, for example:
- When anomalies are observed inside Incydr
- When alerts are received from Incydr
- When events that meet certain criteria are received in your security operation center (SOC) platform
- When alerts from an endpoint detection and response (EDR) system meet certain criteria
Determine which events to escalate
Determine which events to escalate based on their severity and frequency and whether they are intentional:
- Severity Type 1 / Frequency Volume 1-X: Inadvertent/non-malicious data exfiltration, non-strategic asset
- Severity Type 2 / Frequency Volume 1: Inadvertent/non-malicious data exfiltration, strategic asset
- Severity Type 3 / Frequency Volume 2-4: Potentially malicious data exfiltration, strategic asset
Determine additional data sources
Identify the additional data sources within your security operation center platform that you can use to enrich your investigations, such as EDR, URL filtering, and security awareness tools.
Formalize response communications
Formalize the communications to send in response to exposures with business team members, human resources, and legal to ensure consensus. For an example process, see the section on building workflows below.
Define severity levels
The following table is an example of defining severity levels to be used in incident response. Keep in mind this is an example only; you must develop your own set severity levels.
For definitions of data classification (public, internal, confidential, and restricted), see the data classification matrix.
|
|
Data classification |
Example destinations |
Data volume and or value |
Other criteria |
|---|---|---|---|---|
|
Severity 1 |
Public |
USB
Corporate cloud storage public link |
Single document |
|
|
Severity 1 |
Internal |
USB
Corporate cloud storage public link |
Single document |
|
|
Severity 1 |
Internal |
Bitorrent |
Single document |
|
|
Severity 2 |
Confidential |
Personal email |
Multiple documents |
|
|
Severity 2 |
Confidential |
Private storage link |
Multiple documents |
|
|
Severity 2 |
Confidential |
External party via file transfer |
Multiple documents |
|
|
Severity 3 |
Restricted |
Personal email |
Multiple documents |
|
|
Severity 3 |
Restricted |
Private storage link |
Multiple documents |
Legal liability |
|
Severity 3 |
Restricted |
External party via file transfer |
Multiple documents |
Criminal deliability |
Determine incident escalation based on severity and frequency
The following table is an example of using incident severity and frequency of occurrence to determine whom to escalate an incident to.
|
|
Employee |
Employee manager |
Business unit manager |
Human Resources |
C-Suite |
Legal |
|---|---|---|---|---|---|---|
|
Severity 1, Frequency 1 |
X |
|
|
|
|
|
|
Severity 1, Frequency 2+ |
X |
X |
|
|
|
|
|
Severity 2, Frequency 1 |
X |
X |
|
|
|
|
|
Severity 2, Frequency 2+ |
X |
X |
X |
X |
|
|
|
Severity 3, Frequency 1 |
X |
X |
X |
X |
|
|
|
Severity 3, Frequency 2+ |
X |
X |
X |
X |
X |
X |
Build workflows for incident response
Build your own workflows for responding to incidents. Following is an example of a high-level workflow.
Image source: Google Cloud Data Incident Response Process (found on page 7 of the PDF).
Incydr-centric response workflow
Following is a template for using Incydr in your response workflow.
* See the unauthorized data transfer and deletion attestation template.
Reporting
Code42 Insider Risk Advisors can work with you to create the following reports to help you determine your response to incidents:
- Security
The security report summarizes top incidents and their resolutions. Code42 Insider Risk Advisors work with you to identify and prioritize incidents. This report can be generated monthly. - Risk
The risk report identifies risks to specific assets, users, or departments and places the information into a CISO-centric presentation. Code42 Insider Risk Advisors work with you to create the process for reviewing exposures from within the Incydr platform that are used in the report. This report can be generated monthly or quarterly. - Compliance
The compliance report identifies compliance issues exposed by Incydr in the areas of NIST, ISO, CMMC, and HIPAA. This report is generated bi-annually.
Resources
- Code42
- Google Cloud: Data Incident Response Process