What is a CSIRT or CIRT?
A CSIRT (computer security incident response team) or CIRT (computer incident response team) is the group responsible for handling cyber security incidents: working out what happened, containing it and helping the organization recover. The two names are used interchangeably. NIST’s glossary, drawing on the US national security systems glossary (CNSSI 4009), lists a CIRT as also called a CSIRT.
What it means in practice
You will also see CERT (computer emergency response team), “cyber incident response team” or just “incident response team”. The differences are mostly habit and history. The Canadian Centre for Cyber Security uses both: it describes itself as the National CSIRT and as the Government of Canada CIRT, and also uses the name CERT-CA.
The FIRST CSIRT Services Framework defines a CSIRT as an organizational unit, which may be virtual, or a capability that provides services and support to a defined constituency. That last word is the useful one. A constituency is whoever the team serves: one company, a group of member organizations or a whole country.
For a company of 50 to 300 people, “CSIRT” usually means a virtual team and not a department. A typical line-up is the IT lead, a security owner, legal or privacy counsel, someone from communications, a business executive and an outside responder on call. NIST’s older incident handling guide describes three team models: central (one team for the whole organization), distributed (teams for parts of it) and coordinating (a team that advises others without authority over them). It also describes staffing that is in-house, partly outsourced or fully outsourced.
A CSIRT is not the same as a security operations centre. A SOC usually monitors and spots trouble. A CSIRT takes over when something is confirmed. Many organizations combine them.
Where it shows up in an incident
The CSIRT is who gets activated when an event becomes an incident. It works under an incident commander, and its members are named in the incident response plan with contact details that work when email is down.
Common mistakes:
- The team exists on the org chart, but nobody has been told they’re on it.
- No alternates. People go on holiday and change jobs.
- Contact details live only in company systems that the attacker may have taken out.
- Outsourcing without deciding who has authority. NIST notes that organizations are often unwilling to give an outsourcer authority to make operational decisions, so the internal team ends up making them. Agree on that before the incident.
- Leaving out the people who handle customers, staff and the press.
In a tabletop exercise
Inject, Saturday 11:50 p.m. “Your managed service provider’s after-hours line calls the IT manager. It is seeing mass file renaming across several servers.” Discussion: who gets called next, in what order, and how are they reached if email and chat are down?
Discussion question: “Name every person on our response team. For each, who is the backup, and when did we last confirm their phone number?” If the group can’t answer, the team isn’t ready, however good the plan looks. The incident response checklist is a useful cross-check.
Sources
Want to see how your team would handle this for real? Here is how a facilitated tabletop works.