Hello! Welcome to GuardSight; we are a tactical cybersecurity-as-a-service organization dedicated to helping businesses protect their data, their assets, and their endpoints. Today we are going to help those of you that can benefit from audio information versus visual information learn a bit more about cybersecurity by way of this Tomcast (I mean, my name is Tom, so it fits, right?)
Today we are going to address a key model for incident response, known as the PICERL model. Picerl is spelled P. I. C. E. R. L., which is an acronym for Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. Why is this helpful? Well, the model helps define specific steps to take so no important details are missed or omitted during an incident response scenario. Let’s go over each step to gain a bit more familiarity with the overall model:
- Preparation – Preparation is key to many things in many different aspects of business, and incident response is no different. Having the necessary people, skill-sets, access, documentation, and plans of “attack” if/when an incident occurs is very important. This allows an organization to quickly alert the right team for the job knowing the correct resources are already in place to begin the process of incident response.
- Identification – Ok, the incident response (or IR) is in full swing, so what happens now? Monitoring needs to be set up (if it hasn’t been already), events need to be analyzed, the incident needs to be identified, the appropriate people need to be contacted and alerted (leadership, CSIRT, and any others outlined in organizational policy), everything (and I mean EVERYTHING) needs to be documented with as much specificity as possible, and finally threat detection/prevention measures need to be put in place.
- Containment – So, now that the team has identified the cause of the IR the team must determine how to contain the threat. Keep in mind containment means both short-term containment (containing the threat now) and long-term containment (ensuring this will not recur in the future). Also, containment includes making a forensic image/copy of the impacted system(s) (effectively backing up the system(s)).
- Eradication – Alright, the threat has been contained and the organization now has a complete forensic image to analyze. So, next steps would be to re-image/rebuild the impacted system(s) to ensure the removal of any malicious content whatsoever. Also during this time, a root cause analysis is performed to determine what happened and what needs to be done to prevent the same thing from happening again. Another important step in the eradication process is to apply any applicable security best-practices and to perform a malware scan of the re-imaged/rebuilt system(s). This ensures the systems are ready to go back into production.
- Recovery – Whew, we seem to be nearing the end, right? Not quite yet, the recovery step is extremely important since it involves getting production systems back up and running. Organizations need to define times and dates as to when operations will be restored. Everything that was adversely impacted (that has gone through the previous PICERL steps) must be tested and validated for proper functionality. Monitoring needs to be tuned to ensure that alerting is optimal. This is the period where all the previous steps come together to make certain the issue or problem that impacted the organization will not/cannot occur again (to the best of the organizations’ abilities).
- Lessons Learned – Seems simple, right? What did the organization learn from this? Well, there are some more steps involved, but the culmination of those steps should answer that question. First, ensure all documentation is wrapped up/completed with granular detail of every step taken. Make sure an incident report is filed or published that contains detailed information of every step involved in the incident. Determine ways that the IR teams could have improved how they performed, or ways that the response could have been more efficient, faster, better with analysis, etc. Put together a baseline that can be used for comparison purposes in case of future incidents, then schedule and conduct a meeting to go over the incident with the teams involved so that any lessons learned that require changes in operations, behavior, or processes can go through implementation as soon as possible. These are also known as opportunities for improvement (OFI’s); this is a term GuardSight uses to get teams to move in a more positive direction.
So, that is the PICERL model for incident response! We here at GuardSight thank you for taking the time to listen to this audio-cast. Please share this if you believe it would be of assistance to anyone in your contact list, and please provide us some feedback in the comments so we can continue to improve. Thanks!
