Manage Learn to apply best practices and optimize your operations.

A step-by-step network incident response plan

We need automated response tools that go beyond fledging IPSes. In this tip you will learn how to create an IT incident response plan, step-by-step.

It's 2 a.m. Saturday, and something nasty is running loose on the network. All indications are it's a fast-replicating worm powered by a zero-day exploit. Within minutes, your network traffic is spiking as the worm ravenously scans for targets.

Without hesitation, a sysadmin hits the "Big Red Button," which shuts down or isolates critical portions of your network, and closes ports used by the affected service on all noncritical network segments.

Seem a little extreme? It's not entirely irrational.

Allowing a worm infection could cause extensive damage and downtime. The activation of some predetermined emergency lockdown sequence could spare vast portions of your network from infection and damage. A little lost accessibility and productivity is a couple of shades better than the cost of restoring numerous systems and recovering lost data.

Security solutions are grudgingly integrating to provide rapid responses to previously unseen threats. Eventually, IDSes and firewalls will talk to each other, tell one another when they suspect malicious activity and automatically respond. Today's systems simply aren't integrated tightly enough, and network and security managers don't know their infrastructures well enough to allow automated responses.

The Big Red Button (BRB) is nothing more than taking knowledge of a network infrastructure and services, overlaying it with emergency plans, and installing tools and scripts that rapidly put those plans into action. If you've centralized your network management and identified important systems, you can quickly decide what you can shut off and what you have to keep online.

Here's how a Big Red Button would work. First, do an inventory of your networked systems: critical services, data stores and network segments, chokepoints and systems that can lose connectivity without causing serious damage. Code that data into your BRB matrix, and map it to various contingency plans. The BRB would rapidly implement contingency plans across your backbone, servers, firewalls, routers and wireless APs.

Most organizations have such inventories, albeit in an ad hoc manner that's distributed among their firewalls, security policies and router ACLs. And there are no off-the-shelf tools that can leverage that information into automated responses. However, centralizing that intelligence and deploying automated management tools will give enterprises tremendous control over their networks.

Imagine that a new worm starts spreading across your network. Don't hesitate. Hit the BRB! It will turn off all routine file shares between systems outside of their immediate workgroups. Or, suppose that you discover your network is infested with an IRC bot. Hit the BRB, and drop all IRC connections across your enterprise until you can clean it up. Sure, a few people will be inconvenienced for a day or two, but the downtime resulting from a major worm outbreak is even more inconvenient.

We need the Big Red Button or something very much like it. Our current mechanisms are too manual, too slow, and aren't sufficiently integrated for the split-second reactions necessary to survive next-generation worms. We need better security information and response management tools that go beyond the fledgling intrusion prevention technology or amalgamation of existing solution sets.

Is the Big Red Button the answer? Recent worm outbreaks -- including last month's Mydoom -- have taught us that most organizations' ability to react leaves them in second place in the survival of the fittest game.

About the author:
Marcus J. Ranum is a senior scientist with TruSecure Corp., and built the first commercial firewall product, DEC SEAL.

Dig Deeper on Network intrusion detection and prevention (IDS-IPS)