Organizing Your Incident Response Plans and Security Framework
Organizing your information security activities within frameworks lends to order and understanding. There are a lot of 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 we work with in building a solid incident response plan template overall.
Obviously, to CIPHER, the answer for detection, 24×7 escalation, and notification of security events is to choose a Managed Security Services Provider to perform that for you, at a greatly enhanced ROI over an in-house operation. MSS can provide Incident Response, too, in the form of 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 we are perhaps better equipped in phases of Identify and Protect than in those of Detect and Respond: 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.
Our 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.
Incident Response Preparation
Perhaps of the highest importance in 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, skill and capability gaps identified and closed through equipping your 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 these things:
- What is my tasking?
- When am I to perform it?
- How am I to do it?
- What motivates these first three things?
Review of 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. Include notification of the executive team in your testing.
Incident Response Containment
Within the CIPHER framework, the Detect Phase will inform the actions needed in the Respond Phase. The event should be categorized similar to the following, in order to clarify what actions the Incident Response 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 Incident Response Plan Template, by which prioritization is formed based on severity and impact, and which impacts roles and responsibilities post-event. Standardize these areas for enhanced reporting.
- Vulnerability probes
- Broadscan (single port to many IP addresses)
- Vulnerability Scan (one IP for many ports)
- Malicious Code
- C&C Activity
- Malware family/type if detected
- Denial of Service
- 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
- Data Loss Protection
- To include email, phone, web, etc.
- Data exfiltration by APT
- 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.
Incident Response Remediation
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 supporting data needs to be gathered and audited.
If possible, you will also want to investigate what data was accessed, and by whom. Make sure and 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 impacted ones, and in worst-case scenarios rebuilding of systems and network.
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.
Incident Response Restoration
Once remediation is complete, the next step in your incident response plan is restoration and recovery of normal operations and it can consist of the following:
- Put remediated resources back into service
- Restore data from backups
- Rebuild systems from scratch
- Test 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?
Incident Response After Actions
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 Reponse 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 continuous 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.
Incident Response Reporting
There should be generalized reporting of security metrics on a regular and ongoing basis to your executive management, much as monthly operational reviews are conducted for all departments in your 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. In reporting actual breaches to the Board, you’d prefer to have been in the room previously.
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 outweighs 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, contact CIPHER and get started with one of our FREE self-assessments below.