Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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 product management, security operations, and incident response expert and currently holds the position of Senior Product Manager at DFLabs, where he is responsible for shaping the product road map, strategic planning, technology partnerships, and customer ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19037
PUBLISHED: 2019-11-21
ext4_empty_dir in fs/ext4/namei.c in the Linux kernel through 5.3.12 allows a NULL pointer dereference because ext4_read_dirblock(inode,0,DIRENT_HTREE) can be zero.
CVE-2019-19036
PUBLISHED: 2019-11-21
btrfs_root_node in fs/btrfs/ctree.c in the Linux kernel through 5.3.12 allows a NULL pointer dereference because rcu_dereference(root->node) can be zero.
CVE-2019-19039
PUBLISHED: 2019-11-21
__btrfs_free_extent in fs/btrfs/extent-tree.c in the Linux kernel through 5.3.12 calls btrfs_print_leaf in a certain ENOENT case, which allows local users to obtain potentially sensitive information about register values via the dmesg program.
CVE-2019-6852
PUBLISHED: 2019-11-20
A CWE-200: Information Exposure vulnerability exists in Modicon Controllers (M340 CPUs, M340 communication modules, Premium CPUs, Premium communication modules, Quantum CPUs, Quantum communication modules - see security notification for specific versions), which could cause the disclosure of FTP har...
CVE-2019-6853
PUBLISHED: 2019-11-20
A CWE-79: Failure to Preserve Web Page Structure vulnerability exists in Andover Continuum (models 9680, 5740 and 5720, bCX4040, bCX9640, 9900, 9940, 9924 and 9702) , which could enable a successful Cross-site Scripting (XSS attack) when using the products web server.