CSIRTs: Computer Security Incident Response Teams

If you are a fan of superhero movies like me, the assembling of the Avengers or Justice League at a pivotal moment to take on the villains is one exhilarating experience. That the collective strength, rather than individual brilliance, saves the day is a common them in most films of this genre.

And the same can be applied to any organization that comes face to face with a major cybersecurity incident such as an enterprise-wide ransomware attack or a massive DDOS attack: the teams save the day.

Today’s digital villains are not causing only digital damage. In fact, the individuals, entities and nation states that perpetrate cybercrime and instigate cyber insecurity are currently ranked among the top global risks — over the next two years and the next decade, according to the World Economic Forum. Dealing with such occurrences requires multi-skilled experienced teams that offer the best bet for:

• Minimizing the impact.
• Restoring normality quickly and decisively.

Such a capability that operates at a high level within an enterprise or a government is the Computer Security Incident Response Team (CSIRT). Let’s take a look.

What are CSIRTs or CERTs?

NIST Special Publication 800-61 Revision 2 defines the CSIRT as a capability set up for the purpose of assisting in responding to computer security-related incidents.

Sometimes referred to as CERT (Computer Emergency Response Team), the CSIRT is a service organization responsible for receiving, reviewing and responding to computer security incident reports and activity raised by any user, company, government agency or organization. They provide a reliable and trusted single point of contact for reporting computer security incidents and disseminating important incident-related information.

CSIRTs with national responsibility, or national CSIRTs, are designated by a country to protect its cybersecurity. A list of national CSIRTs can be found at csirt.org.

(Understand the relationship between vulnerabilities, threats and risk.)

How the CSIRT works: 4 phases of incident response lifecycle

The CSIRT is primarily involved in the four phases of the incident response lifecycle, and we’ll take a look at each phase:

The Incident Response Lifecycle per NIST (Image source)

1. Preparing for the incident

The CSIRT would be governed through an appropriate cyber security policy framework which includes topic specific policies covering the rest of the incident management process. A mission statement for the CSIRT would provide direction in terms of:

• The constituency (body of people) the team serves.
• The authority or directive under which the team operates.

Appropriate tools and resources for handling incidents need to be prepared which includes (but not limited to):

• Communication facilities, such as phones, email, chat, social media, etc.
• Physical facilities, such as a dedicated war room
• Hardware and software including digital forensics workstations and software, secure storage devices, packet sniffers, protocol analyzers, clean OS images and software.

2. Detecting & analyzing the incident

Detection of incidents would take place through many sources. Primarily, the CSIRT would have access to IDS/IPS, anti-malware and log analysis tools that can identify sources of cyberattacks. Detection would also be aided by information received by users, other CERT teams and providers or vendors of technology systems.

Analysis of the incident involves different techniques depending on the type of attack. The CSIRT analyzes the incident to determine three things:

• The scope: which users, systems and services are being impacted)
• The origin: who or what caused the incident
• The occurrence: which attack methods are being used or vulnerabilities exploited

Next, the CSIT team documents and communications the output of the analysis to key stakeholders. This facilitates prioritization and planning for the next course of action.

3. Containing, eradicating & recovering from the incident

Containment approaches vary depending on the type of security incident. The right decision needs to be taken to limit the impact, which might include:

• Isolating or shutting down affected systems
• Diverting traffic away from them

This decision also impacts the collection of evidence, which would be required for legal, regulatory or research reasons. Evidence must be properly documented, securely stored and traced using a formal chain-of-custody approach.

Following containment, the incident source is eradicated from the IT systems through various techniques including:

• Deleting malicious files
• Disabling breached accounts
• Scrubbing impacted devices
• Patching to mitigate the exploited vulnerabilities

Recovery actions can take place after containment and in parallel with eradication. They would include reviving affected systems, restoring data from backups or failing over to disaster recovery sites. Automation of containment, eradication and recovery can reduce the time of incident impact, but care has to be taken in evidence handling.

4. Recovering post-incident recovery

Once things are back to normal, it is crucial that the CSIRT members review the incident event and handling, together with stakeholders. CSIRT team members should document and shared lessons learned in order to:

• Quicken future responses.
• Enhance existing security controls.

In addition, metrics related to response time and impact containment should be reported to support improvement initiatives. In fact, the CSIRT might be required to collaborate with law enforcement agencies in tracing sources of attacks, analyzing evidence, as well as providing testimony during legal proceedings.

Deciding how to build a CSIRT: 5 models

When determining the operating model of the CSIRT, you’ll need consider certain factors including the sourcing approach (internal vs external) and the location (centralized vs distributed). The Carnegie Mellon University Software Engineering Institute (CMU SEI) lists five generic organizational models for a CSIRT:

1. Security team
2. Internal Distributed CSIRT
3. Internal Centralized CSIRT
4. Internal Combined Distributed & Centralized CSIRT
5. Coordinating CSIRT

Let’s look at each model.

Security team

Here, no group or section of the organization has been given the formal responsibility for all incident handling activities. Instead, you’re likely to follow an ad hoc approach to constituting a team of IT personnel to tackle a security incident. The team reports to internal stakeholders within the organization.

(Compare a SOC to a network operations center.)

Internal Distributed CSIRT

This model is composed of a “virtual” distributed CSIRT, which is formally chartered to deal with incident response activities. The organization utilizes existing staff to constitute this team, who may carry out CSIRT activities, in addition to their other regular job roles. This CSIRT coordinates with both internal and external stakeholders.

Internal Centralized CSIRT

This model is composed of a team who is 100% dedicated to the CSIRT activities — the team is centrally located within the organization. They are the single point of contact for incident handling, coordinating with all stakeholders.

Internal Combined Distributed and Centralized CSIRT

This model combines the previous two models and maximizes the utilization of distributed staff to provide context for the centralized unit when tackling incidents across a widely distributed organization.

Coordinating CSIRT

This model involves a CSIRT that coordinates and facilitates incident handling across a variety of organizations, including other CSIRTs. Coordinating CSIRTs usually have a much broader scope with a more diverse constituency, but with little or no authority. Hence, their focus is more on coordinating communication and providing guidance.

Advanced skills for CSIRT teams

CSIRTs will differ in how they operate depending on the available staff, expertise, budget resources and unique circumstances of each organization. Whatever the model, CSIRT members require advanced skills that may not be available to the usual information security teams within an organization. These include:

• Service management skills for event, incident and problem management
• In-depth technical knowledge on applications, platforms and infrastructure across multiple vendors and environments
• Log analysis, forensic data preservation and ethical hacking
• Communication and coordination with multiple internal and external stakeholders
• Analytical skills and ability to evaluate alternative courses of actions in different scenarios