How to Use PICERL to Address Security Incidents in 6 Steps

UPDATE: This post, originally published on February 12, 2021, has been updated to reflect the current state of PICERL, cybersecurity frameworks, and the drastically changing threat landscape.

In the ever-evolving landscape of digital threats, understanding and implementing incident response (IR) plans is crucial for any organization looking to fortify its cybersecurity defenses and respond effectively to incidents. One such methodology is PICERL, a cybersecurity framework that organizations can adopt to increase their capacity to respond to security incidents today and to fortify their defenses against incidents that may occur in the future.

Responding to a cybersecurity incident, whether a data breach, ransomware event, or other cyberattack, can dramatically compromise an organization’s routine business operations.

Without effective incident response, security incidents can shatter public confidence, erode brand value, and take a big chunk out of top-line revenue.

In this blog, we explore all things PICERL, including a brief history of its origin, compare PICERL to other common cybersecurity models, and provide real-world insights around incident management that can help make implementing a process like PICERL or other security frameworks a success at your organization.

• What is PICERL in cybersecurity?
  • Step 1. Prepare
  • Step 2. Identify
  • Step 3. Contain
  • Step 4. Eradicate
  • Step 5. Recover
  • Step 6. Lessons Learned
• Is PICERL different from NIST?
• Is PICERL the best incident response model?
• How to choose an incident response framework

What is PICERL in cybersecurity?

PICERL is a six-step incident response process for Prepare, Identify, Contain, Eradicate, Recover, and Lessons Learned.

Created by SANS, a private organization established in 1989 to provide security research and education, the PICERL model has become an industry standard for incident response. Many consider PICERL an effective framework because it provides a structured and comprehensive approach to handling security incidents.

Following PICERL ensures that organizations are well-prepared for incidents (Preparation), can quickly identify them (Identification), contain the threat to prevent further damage (Containment), eradicate the threat from the system (Eradication), recover from the incident to normal operations (Recovery), and learn from the incident to improve future responses (Lessons Learned).

Let’s review the PICERL steps more in-depth while also highlighting actionable takeaways you can put into practice today to help you minimize the impact of incidents and strengthen your organization’s overall security posture.

Step 1. Prepare

Preparation ensures that the right people from the right teams are involved, understand their roles, and know what to do when an incident occurs.

The preparation phase should generate a plan that incident response team members can practice against, like how organizations practice their backup and data recovery (DR) procedures.

IR plans must be rehearsed regularly to address any weaknesses. Mock IR drills give team members the confidence to execute under the pressure of a real incident.

[Read also: AI vs. humans: Why SecOps may (not) be the next battleground]

IR teams participating in mock drills should be able to answer questions like:

• Who notifies the public relations (PR) team?
• Who notifies legal?
• Who notifies finance?
• When do law enforcement or regulatory agencies need to be notified?

The preparation phase also determines whether you have the right tools. If not, do you have the funding you need to procure them and provide training for team members? It’s important that once an incident response plan has been created, senior leadership reviews and approves it, including a budget to support the plan.

Step 2. Identify

Once you’ve determined you have an incident, the identify phase is where you start trying to triage by answering questions like:

• When did it start, and how did it occur?
• What was the point of entry?
• Was it an unpatched vulnerability?
• Who found it, and how did we find it?
• Do we know the scope? Is it confined to one or two individuals or assets, or is it widespread?
• Can we continue to do business?
• Will whatever steps we take affect one of our lines of business?

Very often, compromised credentials are the point of entry. From there, an incident escalates, and the bad actors take advantage of any opportunities in your environment.

[Read also: What is access control in security? An in-depth guide to types and best practices]

To improve success in identifying threats, organizations have started to gamify preparing and testing their response process. For example, you can offer awards for the team that finds the phishing email or follows through on their checklist plan in the quickest and clearest way. Gamification is particularly helpful for entry-level security professionals.

Step 3. Contain

Once an incident has been declared, containment is about executing your plan to prevent the unwanted behavior from spreading. There are two popular schools of thought on containment methodologies, each providing pros and cons:

1. A short-term containment strategy could be as simple as issuing a quarantine command to keep compromised systems, assets, or applications from communicating with anything except a security tool. It involves quick measures like isolating affected systems, blocking malicious traffic, or disabling compromised accounts to prevent further damage while a more permanent solution is developed.
   
   Having a short-term containment strategy is a critical step in limiting the immediate impact of a security incident. It helps maintain business operations and minimize disruption during the initial stages of incident management.
2. Long-term containment is a fix implemented enterprise-wide but could be considered short of complete remediation of the root cause of the incident. A long-term containment strategy in incident response is designed to provide a sustainable solution to security breaches, ensuring that the threat is not only temporarily controlled but also prevented from recurring. This may involve system upgrades, patch management, network segmentation, or implementing advanced security protocols.
   
   For example, do you have unpatched vulnerabilities related to an incident? If so, accelerating the patch schedule for the software in question — application or operating system — should be included as part of a long-term containment strategy.

Another crucial task to include during the containment process is revisiting which users have administrative access and to what systems, such as:

• What is your attack surface relative to Active Directory?
• Have you enabled multi-factor authentication?

It’s a good idea to have long-term containment strategies connected to your data backup and recovery systems, as this can help increase the likelihood that your data has been properly duplicated and easily recoverable to a state before the incident occurred.

Step 4. Eradicate

Now you’re trying to eliminate the cause of the breach — root and branch, as they say. What does that mean? It means, for instance, in the case of malware that you’ve found, you can securely remove every instance of it you can identify. You’ve hardened and patched systems where applicable. You’ve reimaged systems that you can’t harden. You’ve updated your threat intelligence to make sure you can identify artifacts related to the breach.

Download free: The ultimate guide to ransomware defense

While the incident handling process unfolds, it may change the scope of your efforts. After a ransomware attack, for example, you may have a lot of systems that need to be reimaged and restored from their last known good backup. And if you don’t catch all the artifacts related to the attack or haven’t addressed the vulnerability exploited to get in, you could be attacked again.

The key to eradication is thoroughness. This ultimate question is whether you found it all — whatever “it” is. A partner or third party with specialized expertise can often help with the cleanup.

Step 5. Recover

Moving from eradication to recovery is like coming out of surgery. The damage has been done, and now it’s time to focus on healing.

From an incident response perspective, it’s time to be very honest with yourself by answering:

• When can you return the affected systems to production?
• Have you patched, hardened, and tested them?
• Have you used your internal red team to run a simulated attack against these systems using the same techniques as the attackers?

Recovery is measured by how fast you can restore impacted systems and processes to their pre-breach functionality. Recovery also means defining how you will change the scope of your monitoring after the incident. Determine how long you will monitor for the activity that caused the breach (for example, 30 days, three months, or six months) and precisely what you are looking for.

Again, the red team tests and the artifacts collected during containment will help here. At the end of the recovery phase, you want to be able to say, “We addressed the vulnerabilities, and here’s our proof.”

There’s a strong trend among security professionals to lower the mean time to repair (MTTR) number, or how long it takes to move through the identification, containment, and eradication phases. As IR plans mature and teams become better at practicing their IR plans, the MTTR and mean time to detect (MTTD) should decrease. Tracking these metrics over time can help you understand whether the PICERL framework is an effective incident response model for your organization.

Step 6. Lessons Learned

This step should begin with an after-action meeting that includes everyone on the incident response team and related departments, such as information security, compliance, legal, PR, etc. This is where you can review and document what you learned about the incident, such as:

• What part of your IR plan worked well? What didn’t?
• Were there gaps where additional people were needed? Did we need to contact a third party or an internal team not on our list of resources?
• Based on the incident, do we need to change how we operate?
• Were we using the tools we had effectively? Were they configured properly?
• How was communication among teams? Could it be improved?
• Was there an employee aspect to the breach, such as a social engineering attack or improper data handling? Can this be addressed with training?
• Was the vulnerability exploited unique to a line of business or endemic across the organization?
• Could we address the vulnerability using a different operational structure or process?

The more flexible the IR plan is, the more you’ll learn from an incident when it occurs. Then, everything you learn should feed back into your preparation phase to be refined and improved.

[Read also: 7 ways Tanium can protect your organization from evolving cyber threats and data breaches]

Is PICERL different from NIST?

PICERL and NIST Cybersecurity Framework are popular methodologies for incident response but differ in structure and focus.

[Read also: How Tanium capabilities map to the NIST cybersecurity framework]

PICERL offers a sequential approach to managing a security incident using six phases. In contrast, NIST is a broader, more flexible set of guidelines structured around five core functions (Identify, Protect, Detect, Respond, and Recover) to help organizations manage cybersecurity risks.

PICERL is a detailed playbook for incident response, while the NIST framework is a more comprehensive guide for overall cybersecurity risk management. However, the NIST framework is generally considered not prescriptive and only offers a taxonomy of high-level cybersecurity outcomes and links to resources for achieving those outcomes.

What does this mean for your incident response plan? Organizations typically use PICERL for incident response within the broader context of the NIST framework to manage cybersecurity risks effectively.

Is PICERL the best incident response model?

PICERL offers a detailed and structured approach to incident response, which can benefit larger organizations or those with more complex IT environments. However, the PICERL framework can also present challenges, such as the need for extensive preparation, the potential for complexity in identifying and containing incidents, and ensuring all staff is adequately trained.

These challenges have paved the way for emerging incident response models designed to provide more flexible approaches compared to frameworks with agile processes like PICERL – and signify a critical turning point in how organizations must rethink the strategies needed to perform effective incident response.

One such model is SOAR, or Security Orchestration, Automation, and Response. SOAR focuses on automating responses and can be particularly useful for organizations with limited resources to address incidents that need immediate responses.

Learn how the Tanium Platform integrates with SOAR

Similarly, DAIR, or Dynamic Approach to Incident Response, is also gaining popularity because it emphasizes approaching incident response using waypoints, or milestones, which do not have to occur in sequential order like PICERL. The DAIR model guides you to focus on the outcomes and the activities that help achieve those outcomes instead of following a phased approach.

With the chaotic nature of cyber threats, the ability to quickly address increasingly sophisticated attacks means modern incident response plans and the tools used to support them must be able to pivot and remediate threats quickly and do so with tighter budgets and cyber talent gaps.

Since today’s security incidents don’t follow a rulebook, why should your incident response plan?

How to choose an incident response framework

In this post, we’ve learned how PICERL has traditionally stood out in the security model landscape by offering a detailed roadmap for incident response. However, each incident response model has its strengths and challenges.

Ultimately, the incident response plans your organization adheres to must be tailored to the specific cybersecurity issues of your industry. For IR plans to be effective, they must also efficiently leverage the resources, tools, and personnel available while proving actionable in real-world scenarios and adaptable to counter new threats as they emerge.

Continuous improvement and evolution of your incident response plan are vital to staying ahead in cybersecurity. Whether it’s PICERL, DAIR, or another model uniquely crafted to address your organization’s needs, the key is to create a plan that addresses current security needs and positions your organization to face future cyber threats confidently.

---

Tanium offers unparalleled cybersecurity support for all frameworks with Tanium Incident Response, which replaces disjointed point-product tools with a unified solution that allows organizations to identify, manage, and remediate vulnerabilities quickly.

Tanium enhances the capabilities of your current SIEM and EDR tools, transforming threat detection and incident response efforts into proactive defense measures that ensure minimal disruption to user productivity and fortify your cyber resilience.

By leveraging real-time visibility and comprehensive endpoint data alongside Tanium Automate, our cutting-edge technology built to automate complex tasks at scale requiring little to no coding expertise, teams of any size and skill level can become more effective, productive, and efficient.

Schedule a custom, live demo to see Tanium in your environment.