If you’re here because you’re looking at how to set up a SecOps Incident Response Plan, then you have come to the right place. We’ll look at planning and implementing the process needed to form a SecOps team.
To fail to plan is to plan to fail
Can you honestly say, hand on heart, that your business has a plan for when you suffer a security breach? Do you? Excellent! However, if you don’t, read on as we dive into and build an incident response plan for a SecOps team.
Planning your SecOps Incident Response Plan
First, you should consider which security framework best fits your organisation. There are many to choose from, such as the NCSC, NIST, ISO, ISACA, SANS, CISA and more. If you research each of these, you will see that they are organisations, some set up by countries for national use, and some are companies which aim to set international standards. I’d recommend researching each of these and adopting an incident response framework that best fits your business.
Once you have decided which framework best fits your business, you need to implement the planning phase:
- Develop a response plan.
- Develop a high-level incident response process.
- Define how communications, response tracking and documentation will be handled.
- Define how incident severity should be decided.
- Consider adding or amending categories in your ITSM Software/ticketing system.
- Consider what criteria are required to escalate a security case.
You should decide this and amend or create processes to ensure your SecOps team knows what to do in all eventualities.
After the planning phase, you will need to define the core incident response cycle. During the core stages, cases should be tracked and correlated and can be escalated, de-escalated, and re-prioritised. This part is critical as it is the ruleset that will govern how your team handle cases operationally. The stages can be defined as follows:
- Analyse
- Contain / Mitigate
- Remediate / Eradicate
- Recover
Playbooks
Once you have documented everything in each phase, you will need to instruct your teams to follow the processes you have set out, which can be tricky as there is a lot of information to absorb. An effective way to visualise the processes and simplify is to create a playbook for common scenarios such as:
- Phishing emails
- Ransomware infections
- Web Server breaches
- Social Engineering attempts
- Insider Attacks
Playbooks remove stress and allow engineers to focus on the task at hand. They ensure that actions are performed in the correct order, that the collection of evidence is actioned correctly, and that business processes are adhered to without having to stop and re-read detailed documentation.
Tabletop exercises
One of the most effective ways, not just to communicate but to teach and practice the processes in place, is to role-play them with the people carrying out the procedures. Tabletop exercises should be conducted regularly to ensure everyone knows their role, what they need to do and when with their colleagues. I’d recommend doing these as often as once a month if you can, as there is always value in discussing how the team could have improved their response to a given scenario.
Post Incident Reviews
The critical attitude to take is not one of blame when something goes wrong. Fundamentally, everyone is working toward a common goal, and when something goes wrong, there is usually a plausible explanation for almost everything. You should take away the ‘Lessons Learned from the incident and move forward by looking at how to prevent or reduce the risk of it occurring again. This could be achieved either by the use of technical controls (a technical solution or configuration), an administrative control (like user training or an improved managerial process) or a Physical control (like a lock and key, or security doors).
