Effective cybersecurity architecture is as much about safeguarding against the damage of cyberattacks as it is about ensuring they’re prevented in the first place. To that effect, companies employ a litany of threat or vulnerability monitoring programs to nip risks in the bud. But in most cases, these proactive programs aren’t enough. Companies should also optimize a security incident handling process to account for any risks or threats that do materialize into full-blown security incidents.
Security Incident Handling Processes for Enterprise Organizations
Even the most secure companies are bound to experience cybersecurity incidents. Therefore, it’s critical for all businesses to prepare for worst-case scenarios with plans in place for when attacks occur. But incident handling also looks different depending on a company’s needs and means. This blog breaks down all you need to know about two prevalent incident handling processes:
- A four-phase program recommended by the US government for nearly two decades
- A six-step program recommended by one of the most trusted cyberdefense experts
We’ll also introduce you to our adapted model for incident handling and response processes. Our goal is to prepare you for informed decisions on your processes.
NIST Incident Handling and Response Processes
One of the most fundamental and widely used protocols for incident handling is the one that the National Institute of Standards and Technology (NIST) has been recommending since the turn of the 21st century. Its Special Publication 800-61, Computer Security Incident Handling Guide, is currently in Revision 2, published in 2012. This nine-year-old version is nearly identical to the first version of SP 800-61, published in 2004, itself an update to a 1991 security guide.
What this continuity speaks to is the fact that NIST’s proposed model is highly effective because of its simplicity and flexibility. Rather than prescribing specific controls companies need to follow, it suggests a range of best practices that fit into its four phases, each of which also feeds into the others. The following subsections break down each phase, step by step.
Request a Free Consultation
NIST Phase 1: Preparation and Incident Prevention
The first phase within the NIST framework involves two primary concerns: preparation for response and prevention of incidents. The first of these comprises the following setup:
- Handler facilities, such as robust platforms and devices for seamless communication
- Analysis hardware and software, such as programs to collect and dissect incident data
- Miscellaneous analysis resources, like internal and external references for comparison
- Miscellaneous mitigation software, such as backup data for all resources detailed above
For the prevention step, NIST recommends implementing practices including but not limited to:
- Host/endpoint security installed on hardware and around perimeters surrounding them
- Network security enveloping all networks used in your facilities and cloud infrastructure
- Regular risk assessments, documenting any potential vulnerabilities and threat actors
- IT and security awareness training to educate staff on the roles they play in prevention
Phase one feeds directly into phase two.
NIST Phase 2: Detection and Analysis of Incidents
The second phase also breaks down into discrete steps: detection, analysis, and then documentation and prioritization. During detection and determination of the incident vector, there are two primary signs of a cyberattack or incident, each of which is useful in its own way:
- Precursors, or tell-tale signs of an attack that appear prior to it, facilitating prevention
- Indicators, or clear signs that an attack is in progress or imminent, requiring handling
The NIST SP 800-61 does not prescribe a single process or approach to use for analysis. However, it does suggest best practices to inform analytical methods, including but not limited to:
- Understanding and comparing conditions of the incident to normal, baseline conditions
- Synchronizing all host clocks for seamless, real-time visibility of the incident’s evolution
- Correlating given events or activities with others in similar incidents to form predictions
- Creating a profile for the incident and all impacted systems to facilitate future analysis
Finally, this analysis leads to thorough documentation of the incident and notification to stakeholders such as law enforcement or media connections. Simultaneously, the response team will prioritize which elements of the incident to address first, moving into the next phase.
Also Read: The Benefits of Hiring a Managed Security Services Provider
NIST Phase 3: Containment, Eradication, Recovery
Phase three also breaks down into three distinct steps, suggested by its title: containment of the incident, its eradication, and recovery of as many resources as possible for business continuity.
First, it’s essential to draft a containment strategy, weighing these factors (among others):
- Incurred compromises to resource integrity (damage, deletion, or theft thereof)
- Required evidence preservation, including for analysis and resolution
- Present functional availability or continuity of networks and client-facing services
- Resources required for a strategy weighed against desired outcomes’ likelihood
In deploying the strategy decided upon, your company must also carefully consider evidence collection and retention, both for mitigation and for any foreseeable legal battles with attackers.
Additionally, companies may need or choose to identify the attackers, using strategies like:
- Validating attackers’ IP addresses to determine the location attacks are coming from
- Researching the attacking hosts in search engines and threat intelligence databases
- Monitoring communication channels to detect any connections with internal personnel
Once the incident has been contained, companies should move swiftly into complete eradication of it and all its trace elements and recovery of all resources it damaged, deleted, or misplaced.
NIST Phase 4: Post-Incident Reporting Activities
Finally, the fourth phase also breaks down into three distinct steps: compilation of lessons learned, usage of relevant data, and retention of the necessary information. First, your company should carefully collect all evidence and other information pertinent to the attack and determine what weaknesses it should address (and why).
The next step involves a targeted approach, turning lessons learned into transferable analytics:
- The number of incidents handled and baseline statistics for each, such as time elapsed
- An objective assessment of the overall efficacy of teams’ and systems’ responses to it
- A subjective assessment of individual team members’ or teams’ incident responses
One purpose of the previous two steps is to optimize data gathered for multiple purposes. Companies should also share their findings as case study examples and generalizable insights other companies and law enforcement agencies can use for prevention.
Phase four isn’t necessarily the end; it feeds back into phase one for a comprehensive, cyclical process.
SANS Institute Security Incident Handling Processes
The other incident handling and response process that many companies across industries have adopted, adapted, or based their process on is promoted by the SANS Institute. SANS is one of the industry’s oldest and most trusted cybersecurity resources; its experts have written numerous guidebooks on incident management and all other IT security matters.
The SANS approach to incident response is a more staccato, six-step process that breaks up NIST’s third phase into three distinct stages or steps of their own. The framework has been developed across countless SANS whitepapers, such as the theoretical Incident Handling Process for Small and Medium Businesses (SMB Guide) and the utility-focused Incident Handler’s Handbook (Handbook). Sections below break the process down, step by step.
SANS Step 1: Preparation for Incident Response
Similar to NIST, this step in the SANS framework requires the establishment of critical resources and responsibilities. The recommendations from the Handbook include but are not limited to:
- Developing and disseminating overall incident management policies, company-wide
- Creating specific response strategies for containment, eradication, and recovery
- Delegating a team of experts from all sections of the organization for response
- Opening up lines of communication between all team members and stakeholders
- Establishing the infrastructure for instantaneous documentation and analysis of incidents
These are among the considerations that the SMB Guide marks as mandatory. It also specifies several optional considerations, like opening up channels of communication with local media or law enforcement, which will facilitate the reporting and notification procedures in the final step.
SANS Step 2: Identification of Current Incidents
What NIST calls “detection and analysis” SANS truncates to “identification.” However, the simplified title belies the complex nature of this stage. The SMB Guide details two mandatory considerations that will guide this stage and all that comes after it: decisions about what defines an incident and about what constitutes an incident taking place.
Beyond these most critical decisions, optional considerations include the specific philosophy of detection and chains of command and communication that should take place between detection of a possible incident and identification of one that meets the determined criteria. For example, companies should decide between taking a more risk-averse approach and declaring an event an incident before it can 100% be determined as such, or else scaling back the priority to wait for full certainty prior to identification and escalation. Either approach can be equally effective.
SANS Step 3: Containment of Active Incidents
The next step in SANS’ model is the first major departure from the NIST framework. Rather than bundle containment with eradication and recovery, it separates them into discrete stages. First, containment consists of three critical steps or sub-steps, outlined in the Handbook as:
-
- Short-term containment, including practices such as isolating or cutting off individual networks or segments within them or seizing traffic to and from a server indefinitely
- System back-up, or generating a forensic image of systems under safe, non-attack conditions that will facilitate returning to a similarly secure (or more secure) state
- Long-term containment, including removing any initial entry points attackers used to infiltrate your systems and backdoors that would invalidate later eradication efforts
Critically, companies should avoid moving into eradication until containment is ensured. Unlike in the NIST framework, the separation of these steps highlights the sequence needed for safety.
SANS Step 4: Complete Eradication of Incidents
The next step after stopping the spread of an incident, per SANS, is cleaning up every trace of it on your systems — excluding any evidence in your best interest to keep legally. The SMB Guide notes that the actual process of eradication can happen using any individual process or program, or even a combination of them. Mandatory considerations like ensuring every system has been checked are accomplished through antivirus or other scanners.
On the other hand, companies looking to optimize this process can consider the extra, optional approach of generating additional forensic images or backups of the system as it exists under attack. Beyond utility as evidence, these backups can facilitate further analysis and preparation for future attacks from the same attacker or any other incidents featuring similar characteristics.
SANS Step 5: Recovery from Eradicated Incidents
The penultimate step involves getting systems back up and running once all traces of the attack are fully gone. To that effect, the Handbook details the following decisions for a return to normal:
-
- The specific time, date, and conditions to return to, augmented with new IT controls
- Which methods are most apt to test full functionality and continuity of a backup state
- What tools or systems to use for continuous monitoring of and for attacks or incidents
- How long to continue monitoring for specific indicators of other security incidents
These considerations correspond to what the SMB Guide marks as mandatory for this stage. It doesn’t add optional considerations, instead suggesting flexibility to build on these as needed.
SANS Step 6: Lessons Learned and Future Plans
Finally, the last step of the SANS process for incident handling is also the simplest and most accommodating. The Handbook designates space to catch up on any requisite or other documentation that was neglected in previous steps. Similar to the NIST framework, both the Handbook and SMB Guide recommend generating and analyzing data in such a way that emphasizes generalizability of insights for accessibility and easy sharing or reporting.
In particular, the Handbook suggests developing PowerPoint presentations to distribute to all internal staff and to a network of peer organizations and other stakeholders. These should make complex analytical insights readily attainable with simplified questions and answers, such as “when did the incident happen” or “how was it finally eradicated?” — this helps all parties understand nuances of the attack so that they can prevent similar incidents in the future.
Incident Handling Processes with RSI Security
One last consideration for handling security incidents is that no one framework is necessarily the best for every company. That’s why RSI Security offers a flexible process for incident management:
- Identifying all incidents currently impacting your company or likely to happen soon
- Logging incidents as they occur and immediately priming them for a deep analysis
- Diagnosing incidents after a lengthy investigation, leading to thorough strategizing
- Assigning roles and allocating resources for mitigation, then escalating if necessary
- Resolving the incident entirely, including full eradication and recovery
- Satisfying your long-term continuity needs and those of your customers and clients
All of these steps or services can be modified to the specific needs of your company, with a greater emphasis placed on any facet you prefer. To get started with a robust, comprehensive security incident handling process sure to keep your company safe, contact RSI Security today!