Attacks/Breaches

2/27/2018
10:30 AM
John Moran
John Moran
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Incident 'Management': What IT Security Can Learn from Public Safety

How a framework developed for fighting California wildfires back in the '70s can fortify first responders to a modern cyberattack.

The increasingly dynamic nature of attacks and high cost of data breaches have forced many organizations to supplement protection measures with internal or outsourced incident response capabilities. When designing an incident response program, it is vital to consider not only incident response, but also incident management. Although the two terms are often used interchangeably, there is an important distinction between response and management.

Response consists of actions taken to investigate, contain, and eradicate an incident, and then recover from it. Management consists of actions taken to plan for, oversee, coordinate, and manage an incident response process, and then conduct post-incident activities.

Failing to have proper management practices in place can lead to an inefficient and ineffective response, which can result in millions of dollars in lost revenue or fines as well as disruptions to business and organizational damages. Even seasoned IT teams require structure and leadership to successfully respond to an incident.

The Incident Command System (ICS) was developed in the 1970s by authorities in California to establish a reliable and repeatable process for responding effectively to dangerous and life-threatening incidents after a series of large, fatal wildfires. Due to its success, it was quickly adopted by agencies across the country and the world. ICS gives first responders a formal, scalable, standardized approach to managing critical incidents. Many of the philosophies and best practices of ICS are also present in corporate America, although often in a less formal manner.

For the purposes of this article, we will refer to ICS as IMS (Incident Management System), since incident management is a more familiar term in the security industry. Let's examine IMS and how it can streamline the overall incident response process.

What Is IMS?
IMS is a framework developed and refined through decades of use to effectively manage incidents of any size and complexity. One of the core tenants of IMS is that it is both flexible and scalable. Each incident requires a distinct set of resources and tactics. IMS is precisely designed to do this.

IMS includes many familiar concepts, such as using common terminology, incident action planning (tabletop exercises and runbooks) and comprehensive resource management (asset inventory). However, there are several other core IMS concepts that, while they may seem like common sense, are often overlooked in most incident response programs. For example, here are four core concepts that should be part of any incident management system:

Concept 1: Appoint a Coordinator, Follow a Top-Down Structure … and Stay Flexible
To maximize the efficiency of IMS, you must first appoint an incident response coordinator (IRC), who will oversee all aspects of the response process. This role works with a top-down command structure, meaning that as the scope of an incident expands, tiers of stakeholders are added, with each tier reporting upward toward the IRC.

The tiered structure enables two other key tenants of IMS: each person should report to only a single supervisor, and each supervisor should oversee no more than six to seven people.

Concept 2: Optimize Information Management
To ensure the efficiency of an IMS, information must flow smoothly up and down the chain of command. When information does not flow properly, managers are forced to make decisions based on incorrect or incomplete information, while responders cannot fully address management's questions or meet their objectives. The uninhibited flow of information is critical in effectively responding to an incident, and its absence is one of the most common reasons for a response process to fail.

Concept 3: Engage All Stakeholders
For IMS to succeed, an organization must involve all stakeholders in the process, both in training and implementation. All possible stakeholders should be aware of how IMS is implemented in the organization and their respective roles in the process. This is especially true for ancillary team members, such as human resources, legal, or finance, who may be unfamiliar with the incident response process.

Concept 4: Practice Makes Perfect
As is the case with most processes, the more an IMS is used, the more comfortable all stakeholders will be with it, and the easier the process will be to implement under stressful conditions. While tabletop exercises and training sessions are invaluable, there is no substitute for experience under real-world conditions. Implementing IMS for all incidents will ensure that when the time comes to implement it during a large-scale incident, all stakeholders will be comfortable with the process. 

A good training approach is to do an annual tabletop or walk-though response exercise simulating an incident that grows large enough to involve a large portion of the IMS. The first year's exercise should focus on the core group of stakeholders, typically the information security and information technology groups.

Subsequent exercises should be extended to include ancillary stakeholders such as legal, human resources, executive management, and communications. This second exercise will ensure that ancillary stakeholders have a cursory familiarity with the IMS system and their respective potential roles.

Planning, preparation, and simulation are the surest way to be ready to respond to a security incident in a controlled and efficient fashion. 

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

John Moran is a security operations and incident response expert. He has served as a senior incident response analyst for NTT Security, computer forensic analyst for the Maine State Police Computer Crimes Unit and computer forensics task force officer for the US Department of ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8023
PUBLISHED: 2018-09-21
Apache Mesos can be configured to require authentication to call the Executor HTTP API using JSON Web Token (JWT). In Apache Mesos versions pre-1.4.2, 1.5.0, 1.5.1, 1.6.0 the comparison of the generated HMAC value against the provided signature in the JWT implementation used is vulnerable to a timin...
CVE-2018-14643
PUBLISHED: 2018-09-21
An authentication bypass flaw was found in the smart_proxy_dynflow component used by Foreman. A malicious attacker can use this flaw to remotely execute arbitrary commands on machines managed by vulnerable Foreman instances, in a highly privileged context.
CVE-2018-14645
PUBLISHED: 2018-09-21
A flaw was discovered in the HPACK decoder of HAProxy, before 1.8.14, that is used for HTTP/2. An out-of-bounds read access in hpack_valid_idx() resulted in a remote crash and denial of service.
CVE-2018-1685
PUBLISHED: 2018-09-21
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, and 11.1 contains a vulnerability in db2cacpy that could allow a local user to read any file on the system. IBM X-Force ID: 145502.
CVE-2018-1710
PUBLISHED: 2018-09-21
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 10.1, 10.5, and 11.1 tool db2licm is affected by buffer overflow vulnerability that can potentially result in arbitrary code execution. IBM X-Force ID: 146364.