How I deal with Security Incidents - PICERL
When working on security incidents, I always use an Incident Response framework called PICERL. I got it from SANS450, a brilliant blue…
How I deal with Security Incidents – PICERL
When working on security incidents, I always use an Incident Response framework called PICERL. I got it from SANS450, a brilliant blue team course taught by John Hubbard . I briefly talked about it in a retro today. My team mates were interested to know more so I’ll share this post with them.
When you are dealing with a security incident it’s very easy to get flustered and lost in the thick of it. It’s happened to me before. You have an ongoing incident to deal with, lots of unknowns, lots of new information coming in, stakeholders are chasing you for updates, your notifications are popping off and you’re mind is going at 100mph.
PICERL gives me a mental framework to deal with incidents. It gives me a very high level mental guide of what to do next in the incident response cycle. It gives me clarity and allows me to focus on what needs to be done.
PICERL- Prepare, Identify, Contain, Eradicate, Recovery, Lessons Learned.
During incident response, I will literally lay this out in a table and start documenting what I am doing.
PREPARE — prepare for attacks. This is about our Security controls and having things set up to detect/prevent security incidents. Against Prepare, I often write down what detected the incident e.g. SIEM, Email Gateway, Users, Blocklists, Detection Rules, Firewalls.
IDENTIFY — This stage is about anything that alerts me that an attack is happening e.g. SIEM Alerts with details like alert no or a user reported email. Anything that alerted me to the incident, i’ll note here.
CONTAIN — Containment actions. Stop the bleed, disrupt the attacker. e.g. block links, disable accounts, sever connections etc. These are usually short term actions but can also be actions that are long term.
ERADICATE — Usually more longer term actions that will remove a threat and keep them out. Varies but examples include a full host wipe, remove accounts, new processes.
RECOVERY — Actions that take us back to a pre-incident state. e.g. Restore backups (safely!), bringing systems back online, undoing any temporary measures that are no longer required. It only makes sense to do this part when you are confident you have the situation under control.
LESSONS LEARNED — How to avoid this situation again. Should be done as close as possible to the incident so details are fresh in my mind. What went well? maybe containment actions worked nicely. What can be done better? maybe a playbook wasn’t up to date. Share this with all stakeholders of the incident.
Hope this is useful for my team mates. Thanks for all your help on the thing I was working on recently!
