[SECURITY-L] CSIRT groups take on new roles

[CSIRT - UNICAMP]

----- Forwarded message from Cristine Hoepers <cristine em nic.br> -----

From: Cristine Hoepers <cristine em nic.br>
Subject: [S] CSIRT groups take on new roles
To: seguranca em pangeia.com.br
Date: Mon, 31 Jan 2005 15:27:10 -0200


[http://www.nwfusion.com/careers/2005/013105man.html?fsrc=rss-security]

CSIRT groups take on new roles

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

By Paul Roberts
Network World, 01/31/05

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.

"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. 


----- End forwarded message -----