Organizing Your Incident Response Plans and Security Framework

There are a lot of security frameworks to choose from: NIST, ISO, HIPAA, and PCI-DSS. Each framework provides categorized order in which you can organize your focus and activities. Cipher uses a customized information security framework which describes phases of organized information security activities, each pillar with more finely granular areas of interest. This helps the organizations in building a solid incident response plan template overall.

One path forward for managed detection is 24x7 escalation and the notification of security events by choosing a Managed Security Services Provider (MSSP). This enhances ROI for your team over an in-house operation. MSSPs can also provide incident response with red team engagements.

But, what about organizing your own in-house incident response plan template and team? It's an important topic to consider.

Reporting of breach metrics shows us that Cipher is perhaps better equipped in phases of Identify and Protect than in those of Detect and Response: Mean Time to Identify and Mean Time to Contain have ranged between 192-208 days and 52-58 days respectively for the past several years, contributing greatly to overall breach costs. 

Cipher's Respond Heat Map items correspond to other frameworks, such as NIST. Let's examine each more closely so you can begin building a solid Incident Response Plan template.

One of the most critical pieces when organizing an in-house incident response plan template is preparation. Roles and responsibilities need to be well defined and communicated. Expectations need to be conveyed, and skills and capability gaps identified and closed through equipping your incident response (IR) team with the right tools and training. These vary among different businesses, but should scale from SMB to large enterprise applications.

You should identify for each team member the following:

• What is my task?
• When am I to perform it?
• How am I to do it?
• What motivates these first three things?

Reviewing the roles and responsibilities for individuals and the team, including the what, when, how, and why of their role's activities does more than give them operational guidelines. IT tells them about the importance of their part in the larger picture. Testing the team in simulated breaches lets them see the IR machine in action and prepares them for an actual occurrence. It's also important to include notifications for the executive team in your testing.

Within the Cipher framework, the Detect Phase will inform the actions needed in the Respond Phase. The event should be categorized similarly to the following, in order to clarify what actions the IR team needs to take. The list of these is dynamic, modified by discovered activities and actions taken on them. Maintenance and documentation of these are part of your IR Plan Template, by which prioritization is formed based on severity and impact, and which impacts roles and responsibilities post-event. Be sure to standardize these areas for enhanced reporting:

• Reconnaissance
  • Vulnerability probes
  • Broadscan (single port to many IP addresses)
  • Vulnerability Scan (one IP for many ports)
• Malicious Code
  • Trojan
  • C&C Activity
  • Malware family/type if detected
• Denial of Service
  • DNS
  • HTTP/HTTPS
  • FTP
  • SSH
• Authentication, Authorization, and Account (AAA)
  • Account created or deleted
  • Account added to privileged group
  • Login failures
  • Unexpected password changes
• Acceptable Use Violation
  • Installation use/of unauthorized applications
  • Web filter alerts
  • Unauthorized activity
  • Remote access
• Brute Force
  • SSH, telnet, FTP, web, terminal services, etc.
• APP/OS Exploit Attempts
• Phishing
• Data Loss Protection
  • To include email, phone, web, etc.
  • Data exfiltration by APT
• Health
  • A device stops sending logs through collectors to SIEM

The goal in Containment is to limit the scope of the issue at hand and prevent any further or subsequent spread of the issue to minimize loss. Analysis needs to be performed to determine what must be done to:

• Prevent data loss
• Protect and keep critical compute assets and resources operational, if possible
• Determine systems' current ability to do so

Based on those determinations, decisions must be made, to:

• Disconnect the affected resources from the network and allow it to run alone
• Shut down the affected resources immediately to preserve their current state
• Allow the resources to continue as-is and monitor for activity to gain more insight into what exactly is happening

All of these are valid courses of action. In some cases, law enforcement should be notified to participate, in which case it may be wise to consult with them before taking this step. They may have input as to investigation, chain of evidence, or forensics.

The first step in remediation is the investigation. Data needs to be properly acquired so that chain of custody can be preserved. Bit copies of local drives and external storage, dumps of memory contents, associated logs on other devices, system and application logs, and any other possible supporing data that needs to be gathered and audited.

If possible, you will also want to investigate what data was accessed, and by whom. Make sure to document all findings during the investigation.

Ridding the resources of that which is impactful should take place only after the above actions are taken. Activities may consist of running applications either externally or on affected systems to eliminate unwanted applications and their footprints, uninstalling some other software, running offline scans for further discovery, rebuilding the OS from scratch, replacing storage devices with the secure destruction of impaced ones, and in worst-case scenarios, the rebuilding of systems and networks.

Notifications should happen after remediation is underway or is complete to avoid secondary channels of communications by which threat actors could learn that they're being pursued, especially if law enforcement is involved.

Once remediation is complete, the next step in your IR plan is restoration and recovery of normal operations. This can consist of:

• Putting remediated resources back into service
• Restoring data from backups
• Rebuilding systems from scratch
• Testing to ensure vulnerabilities are not still present

Restoration comprises much of how breach cost totals are computed. Was sensitive data lost that compels customer compensation or regulatory fine? Did system and resource downtime contribute to the lost business? Was capital expenditure incurred in restoring the enterprise to a known and healthy state?

A review should be performed for each security incident. Depending on scope and severity of the incident, it can be noted in a help desk ticket for a detected virus that required manual intervention to a full root cause analysis that includes playbook process and procedural review.

You might want to consider the following questions in your After Actions steps of the Incident Response Plan:

• Was preparation sufficient? Is there anything we can add to our playbook from lessons learned?
• Did detection, escalation, and notification happen within our time thresholds? (Yes, you should track this continuously, and by category — it's a metric for contunuous improvement)
• Was executive management happy with how internal communications were conducted?
• For external communications, was marketing successful in their messaging?
• Based on breach cost experience, are additional controls, tools, and/or training needed?

After Actions should be formally reported, potentially in a format suitable for board presentation.

There should be generalized reporting of security metrics on a regular and ongoing basis to your executive management team, similarly to monthly operational reviews that may be conducted for all departments in you business. Security is not just a cost center, it is intended to preserve company value, and so reporting on threat landscape by category, priority based on severity and potential impact, timeline, and response metrics should be of high interest, even up to the board level on at least a quarterly basis. 

Learn how to calculate Return on Security Investment metrics in our two part series: Part 1 and Part 2.

Board-level reports should be brief, to the point, give a good understanding of what happened without a lot of technical detail, and within 3-5 slides inform them of breach cost. If value was preserved, compare that to the costs of security resources that preserved them — hopefully, the value preserved far outweights the mitigating costs. If playbook, process, and procedural improvements have been implemented due to lessons learned, convey that. Make sure they know the same incident could not happen again, and that the experience has improved your incident response.

If you're interested in information security maturity assessments, get started with our complimentary attack surface report here.

 

 

 

 

Disclaimer: This post was originally published in 2023 and republished on June 18, 2025. Some details may have changed since the original publication; please explore our latest resources or contact our Cipher experts for the most current information.