CSIRT groups take on new roles

Creating and sustaining a computer security incident response team calls for ample preparation.

Traditionally, computer security incident response teams are thought of as a way for large organizations to respond to hacking incidents, rogue employees or virus outbreaks. Now they are coming into the mainstream as a critical tool for maintaining business operations and regulatory compliance.

Check out these resources for setting up a CSIRT

“We’re definitely seeing an increase in the number of [CSIRTs] being formed,” says Georgia Killcrece, leader of the CSIRT development team at the CERT Coordination Center at Carnegie Mellon University. In many cases, companies are being driven to create CSIRTs by mandates from Washington, industry groups and the upper reaches of corporate management, she says.

New requirements in laws such as the Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act, and California State Law SB 1386, hold companies accountable for the handling and whereabouts of sensitive data, and respond appropriately to any breaches of customer or employee privacy.

At their best, CSIRTs let companies react in a consistent and coordinated way to events that affect IT systems. “Companies don’t want to have to reinvent the wheel each time an incident occurs. They want to know what to do, gather the right information and pull the right people together,” Killcrece says.

Put together a plan

To create an incident response team, start by getting the proper participants together. Business managers, network and desktop administrators, and IT security experts have to be involved, Killcrece says. Legal staff, human resources representatives and senior executives who make funding decisions also should participate in the planning.

When drafting your CSIRT plan, start with the basics, recommends Adam Hansen, manager of security at Sonnenschein, Nath & Rosenthal, a law firm in Chicago. “Define things like ‘What’s an incident?’ [or] ‘What’s a response?'” he says.

Companies also need to identify the scope of a CSIRT’s responsibilities, says Troy Smith, senior vice president at Marsh Risk Consulting. “You have to look at the core software applications that you need to sustain yourselves. If you have one set of systems that are really critical, the scope [of the CSIRT] could be narrow. If you’re an organization that’s very dependent on technology, it could be very broad,” he says.

Howard Schmidt, former White House cybersecurity adviser and the current chief security officer at online auction site eBay, recommends a holistic approach to creating CSIRTs.

“A lot of time the focus is on looking at one piece of the network — [intrusion-detection systems] or responding to viruses. People get tunnel vision about where the problem is based on what happened last week,” Schmidt says.

Hansen agrees. “If a breach of security is identified by IDS, you’re going to need to work with other groups – the workstation group, the server group,” he says.

At the same time, CSIRT plans shouldn’t be too prescriptive. The team must be able to grasp the big picture and be open ended when necessary, experts say.

“I used to be adamant about having names in slots, and I was one of a couple of people who were on the spot if something went wrong,” Hansen says. “Then I thought ‘I really like hiking. If there was an incident while I’m hiking and I didn’t have a cell phone signal, what would happen?’ Now I’ve shifted to a [decentralized] model where I have a general manager at the top and a bunch of smart people working underneath him.”

On a practical level, the plan should spell out specific roles. In an emergency, it should be clear not just who the technical contacts are to fix or restore broken IT systems, but who is empowered to speak to the media if an incident occurs, who can speak to clients and who to call with legal questions. The CSIRT plan should indicate which executives can be contacted if issues need to be escalated, Hansen says.

Organizations also should spell out who arbitrates disagreements and has the final word. “When you’ve got a whole bunch of people in the room, you need someone to break a tie,” Schmidt says. CSIRTs also will need to have well-defined connections to outside groups, including specific contact information and previously established nondisclosure agreements with local and federal law enforcement, and computer forensics investigators, Hansen points out.

In their focus on solving technical problems, organizations shouldn’t lose track of the fact that humans make up the CSIRT, says Steve Fallin, director of the rapid response team at WatchGuard. “It’s easy to get caught up in the excitement and intensity of what’s happening. The reality is that people might need to take breaks, get up and grab a bite to eat or coffee. They’ll get more quality work done over time than trying to work 12 or 15 hours without a break,” he says.

Finally, organizations have to test their CSIRT plans before incidents occur to make sure that everyone who might be called into action understands their roles. Testing a plan and getting everybody to understand what’s required of them can take 18 months to two years, Killcrece says.

“The biggest mistake is to think that you can [create CSIRTs] in a short time-that you’ll set it up and it will be in operation next month,” she says.

Ultimately, the success of an organization’s incident response team will depend on its commitment to that team: the resources and funding allocated, the time put into planning and rehearsing incident response scenarios.