Risk-Driven Incident Response

Psst! Do you wanna protect your company from security incidents?

But what you have is hundreds of apps, your infrastructure looks like a bowl of spaghetti, and the company is short on resources? Don’t worry, it’s still doable with careful planning!

This risk-driven incident response framework lets you target the most critical things at your organisation. Keep on reading and your IR team will operate as a powerful sniper rifle, rather than a clunky shotgun.

Information Security activities typically revolve around the protection of intellectual property (IP), critical infrastructure, customer data and brand reputation. Time and money should be spent on security controls protecting the most valuable assets. In a nutshell, this is a mature, risk-based approach.

What if we apply the same principle to incident management? As Microsoft’s whitepaper suggests, incident response (IR) activities should be focused on threats representing high-risk to the company.

Not know what to defend; and he is anxious for the result will be weak.

— Sun Tzu Lulz (@FakeArtofWar) August 19, 2015

In the following sections, we are going implement a risk-based incident response strategy into practice.

Incident Response Policy

The first thing what we need is an IR Policy, which provides a firm foundation for the incident response function itself.

The policy should encapsulate the management’s intention of managing security incidents in an organised manner. Secondly, it should express that the risk-driven approach is desirable when it comes to incident management.

Furthermore, it should also clarify what a cybersecurity incident is. An explicit definition establishes a clear distinction between IT and security incidents.

Last, but not least, the policy is usually not longer than two pages and should avoid techspeak altogether.

Incident Response Plan

The next level below is the IR Plan. It spells out the vision and mission of the future CSIRT still in non-technical terms. The primary purpose is to set the objectives and boundaries of the team.

Vision Statement

The vision – which should be clear and concise – summarises the main purpose of the forming CSIRT.

The statement should:

• Originate from the IR Policy
• Be linked to the business objectives of the organisation
• Consider the biggest risks to the business objectives
• Consider external industry regulations

Example: “Our vision is to protect information systems supporting the core business activities of Omni Consumer Products (OCP) from cyber-crime.”

Mission Statement

The purpose of the mission is to elaborate the vision further by breaking it into smaller pieces. The mission shall:

• Be maximum 3-4 sentences long
• Take industry regulations into account
• Consider quality management practices

In our example, one of the critical systems of OCP is the employees’ PCs. One of the greatest risks to the business here is ransomware infections, as they hamper the productivity of OCP’s employees for a prolonged period of time.

Example: “Our CSIRT aims to protect employees’ work computers from disruptions caused by software with malicious intents. We intend to report security incidents affecting PIIs to the appropriate authorities if necessary. We aspire to measure and maintain the quality of services our CSIRT offers.”

List of Constituents

The constituents (clients) also derive from the vision as well as the mission.

The constituent, in our case with OCP, is the end-user. The CSIRTs goal is to protect the integrity and availability of their PCs to prevent unnecessary business disruptions by ransomware.

Services

Getting near, huh? We know the who, we know the what, but not the how. Luckily the Handbook for Computer Security Incident Response Teams from CERT provides an excellent list of the available options.

Different incident scenarios require a different selection of services. As the main delivery methods of ransomware are phishing, drive-by downloads and browser exploit kits, the CSIRTs attention will be revolving around these particular attack vectors.

The CSIRT of Omni Consumer Products, therefore, selects the following services to tackle ransomware:

• Alerts and Warnings (to warn our employees)
• Everything under Incident Handling except for on-site services (for detecting and blocking the threats)
• Vulnerability and Artifact Response Coordination (for generating IoCs)
• Announcements
• Technology Watch (for being up-to-date on the latest solutions)
• Security-Related Information Dissemination (for being up-to-date on the latest threats)
• Intrusion Detection Services (IDS)

Refer to CERT’s Organizational Models for Computer Security Incident Response Teams paper for more on the selection process.

Procedures

The design process ends with the production of the step-by-step instructions named Standard Operating Procedures (aka. SOPs, playbooks, incident runbooks or “use cases”).

This level is where our hands get dirty as SOPs are the first documents on the chain that involve technology.

Example 1: An end-user reports a ransomware-encrypted PC? Send out Alerts and Warnings to remind your users not clicking on specific emails. Add new email filtering rules to block the phishing campaign, have IT remove emails already delivered from the users’ mailboxes.

Example 2: Outgoing C2 traffic is detected on the proxy? Engage IT to wipe the infected PC and rotate the user’s domain password. Parse proxy logs for identifying other affected computers before the users’ files get encrypted. Generate IOCs and deploy them on the HIDS/NIDS.

1. We started from the top with the IR Policy
2. We drafted a Vision and Mission afterwards. Both statements originated from the greatest risks to the business objectives of the company.
3. Then we defined the Constituents and what we wanted to achieve with them
4. On the next level below, we collected the Services that would support our goals with the Constituents
5. Finally, we had the SOPs, which outlined the step-by-step instructions for handling specific events

Because the business activities, as well as the threat landscape continually evolve, the documentation should be reviewed on a regular basis.

First of all, the vision should adapt as the company’s business objectives change.

As for the mission, it should be extended as the CSIRT becomes capable of taking on more and more tasks. Besides ransomware, there could be other business-disruptive threats to cover, such as attacks against customer-facing web applications.

The IR team should also cover threats already inside the company. For instance, hunting for IoCs, log analysis, traffic pattern analysis are typical activities of a proactive CSIRT. When it comes to business applications, the team can monitor application logs, manage application users (in emergency situations) or mitigate denial of service attacks.

The risk-driven framework is heavily based on the following publications:

• CERT Incident Management Publications
• Computer Security Incident Handling Guide (NIST 800-61r2)

Pictures and diagrams (except the last one): Handbook for Computer Security Incident Response Teams, RoboCop (1987) movie, RoboCop wiki, Emuparadise

Cover photo courtesy of Management Research and Development