Incident response is a vital component of every organisations security. It provides the safety net for when the inevitable happens and other controls fail. A good incident response team will also have subject matter experts who can guide your entire organisation’s security strategy.
If you take security even slightly seriously, you will have an incident response team. Often called a “CSIRT,” but you may use other titles like SIRT, IRT or CERT. Ideally, you’ve put your technical expertise here so that they can respond to incident across the board. You’ve manned it properly so the team have resources to deal with the volume of incidents you face and you’ve given them the tools to detect, confirm, investigate and contain incidents in a timely manner.
If you’ve done all this, you’ve done well and your response will be pretty good.
However, even the best CSIRT team needs help. Your handlers may be experts but you want them spending time on incidents, not constantly refreshing their knowledge of the ins and outs of your environment.
You can solve this by making sure they interact with key stakeholders in your business.
5 Key Stakeholders for Incident Response
Every organisation is different. However, your CSIRT must find a way to engage with the equivalents of the following groups:
- IT Services. Your incident response team need to establish solid relationships with all the key parts of your IT Services organisation. Internally, this includes networking, database teams and developers. Externally you need to include hosting providers and service providers. This is the most crucial relationship they can have.
- Security Management. You need more than a CSIRT. The incident responders can be expected to own every aspect of security. You need to ensure they have a route to engage other parts of security and especially security management / leadership teams.
- Legal. Incidents open the door for lots of legal considerations. You need to make decisions about what to report and how significant an event may be. Your incident responders should be technical experts, not legal experts. This means your handers must have a way of seeking guidance from real lawyers. Ignore legal at your peril.
- Human Resources. Users are a frequent cause of security incidents. Your incident response team need to be able to handle these in the correct way. To enable this, the CSIRT need to engage with HR. Ideally, there will be regular links to ensure compliance and an ad-hoc link when an incident happens. As with legal, ignore HR at your peril.
- Public Relations. Incidents can go public with very little warning. No one wants to make the Talk Talk mistake with a CEO talking faster than your incident response team can work. It is vital that your incident response guys engage with PR before and during incidents. Your PR team are experts in making sure the incident response message is the right one. If you need to go public and there is no link between incident response and PR, you will feel pain. Lots of pain.
Incident Response Communications
So, you know it makes sense to engage, but how can you do it?
Step 1: Identify the right people. Find or nominate key individuals within the stakeholder groups. These do not need to be security experts, but they need to be aware of the incident response team’s existence. Make them aware of their duties – normally act as a support point for any incident activity.
Step 2: Set up regular security cadence meetings. People forget things. You can minimise this with a regular meeting between all the stakeholders. You can use this to drive improvements, review previous incidents or just remind everyone.
Step 3: Incident Response Escalations. Your team is in-flight with an incident, have them set up pro-active alerting. Don’t call everyone, every time, but your handlers need to be planning ahead. Your incident response team need to be warming up key contacts so when they have to press the button, it doesn’t shock anyone.
Incident Response Really Matters!
No matter how good your security is, there will be a time when it fails. An attacker will get through.
This doesn’t mean you should ignore other controls. It doesn’t mean you should give up hope.
However, it does mean you need to have a plan B. A good incident response team gives you this plan B.
Your incident response team need your security controls. They need your logs. They need tools to contain incidents. They need skills and knowledge.
When they have all this, the need engagement with others!
With all this, you make it less likely the attackers will “get lucky.”