SOC 2 Readiness Series – Incident Management

Undertaking a first-year SOC audit can be a daunting feat for an organization. Are you wondering where to start?  As part of our SOC2 readiness series, we’ll be highlighting five of the largest topical areas within a SOC2 audit.

Incident management is a fundamental component to consider during SOC2 readiness. Below we’ve outlined guidance to help organizations comply with the American Institute of Certified Public Accountants’ (AICPA) SOC2 trust services criteria, specifically those that relate to incident management.

[sch_pullbox]SC&H’S Key Takeaways

1. 1. The best way to limit security events that could result in incidents is to make sure there are mechanisms in place to reduce exposure to exploits and vulnerabilities.
   2. The goal of the incident response process is to limit damage and reduce recovery time and cost. Incident response policies and procedures should be defined and communicated to all parties involved.
   3. After a critical or high-risk incident occurs, a postmortem analysis should be completed outlining the details such as the cause and cost of the incident, as well as the steps an organization should take to prevent future incidents (i.e. deeper vulnerability assessment, additional training, etc.).
   4. The steps taken to contain and recover from an incident should be documented in order to evidence to stakeholders adequate and timely response occurred, in accordance with defined policies and procedures.

[/sch_pullbox]

Prevent and Detect

The first line of defense to incident management is prevention. Implementation of strong firewall configurations, anti-virus software, and re-occurring vulnerability scanning, monitoring tools over the security of your organization’s systems, are the most common means of prevention; as is the deployment of additional monitoring tools over servers or applications that maintain confidential information. The best way to limit security events that could result in incidents is to make sure there are mechanisms in place to reduce exposure to exploits and vulnerabilities.

The monitoring tool used in prevention can also assist in detection. Alert settings can be configured and when defined thresholds are met, the appropriate individuals are informed.

To minimize response time and impact, an organization should maintain a formalized incident response policy. The policy should include steps to quickly contain, eradicate, and recover from the threat; as well as communication plans to all stakeholders, both internally and externally. To properly enforce the policy and to hold employees accountable, a disciplinary action section as well as specifics on roles and responsibilities should be included. The policy should be made available to all individuals who may play a part in the incident management process.

Our organization identified a security event, now what?

Security events must be analyzed to determine the ultimate impact on an organization. Consider asking yourself, has the event resulted in a failure of the organization to meet objectives? If so, an incident has occurred.

An incident is typically defined as an occurrence that jeopardizes the security, availability, confidentiality, processing integrity, or privacy system, or data, an implicit or explicit violation of an organization’s security policies and procedures.

Incidents include but are not limited to:

• attempts (either failed or successful) to gain unauthorized access to a system or its data,
• unwanted disruption or denial of service,
• the unauthorized use of a system for the processing or storage of data, or
• changes to a system without the organization’s knowledge, instruction, or consent.

If after the analysis is completed, a determination is made that the event was an incident, the organization has an obligation to react. The goal of the incident response process is to limit damage and reduce recovery time and cost.

Contain

Containment is important before an incident overwhelms resources or increases damage. An essential part of containing an incident is making major decisions (e.g., shutting down a system, disabling functions, etc.). The incident response policy should outline predetermined strategies and procedures for containment. Organizations should define acceptable risks in handling incidents and develop strategies accordingly.

Recover

Now that the issue has been contained, the focus should be on recovery. In recovery, administrators restore systems to normal operation, confirm that the systems are functioning normally, and (if applicable) remediate vulnerabilities to prevent similar incidents. Recovery may involve such actions as restoring systems from clean backups, rebuilding systems, replacing compromised files with clean versions, installing patches, changing passwords, and tightening network perimeter security (e.g., firewall rules).

The steps taken to contain and recover from an incident should be documented in order to evidence to stakeholders adequate and timely response occurred, in accordance with defined policies and procedures. Additionally, documentation of the steps taken to contain and recover from the incident support operating effectiveness of the incident response policy throughout the period under audit. From a SOC auditor’s perspective, “if it isn’t documented, we can’t confirm it happened.”

Now what?

One of the most important parts of incident response is also the most often omitted: learning and improving. After a critical or high-risk incident occurs, a postmortem analysis should be completed outlining the details such as the cause and cost of the incident, as well as the steps an organization should take to prevent future incidents (i.e. deeper vulnerability assessment, additional training, etc.). This documentation may be helpful in determining the organization’s response to the threat/vulnerabilities identified. For additional information, see SOC readiness series – Risk Management.

Download our eBook, “A Comprehensive Guide to SOC Reports” to learn additional pertinent and valuable information around SOC examinations, report types, finding the right auditor, and much more. If you’d like to discuss how our team can help with your SOC audit needs, please contact us.