How to Respond to an Unexpected IT Security Incident

"So many people walk into an incident and start giving orders," according to Lenny Zeltser, a SANS senior faculty member who also sits on the SANS board of directors.

Zeltser was a speaker at this week's SOURCE Boston conference and gave attendees tips on what to do when an unexpected incident hits an organization. Rather than immediately jumping to make rash decisions, ask questions. Lots and lots of questions. Zeltser detailed four key stages for response that will help you gain control and proceed with confidence.

Understand the Incident's Background

"You have to expect to walk into a situation blindfolded," said Zeltser, who also recommends asserting authority in a calm manner to claim the situation. "Listen more and talk less."

The first thing to ask: What is the nature of the problem as it has been observed so far?

"Maybe the initial diagnosis was incorrect," he said, noting that a problem initially thought to be with a Web server could end up being a firewall issue.

Some other questions to ask: How was the problem initially detected? When was it detected and by whom? What security infrastructure components exist in the affected environment? (e.g., firewall, anti-virus, etc.)

Zeltser also recommend not being afraid to ask about the components of the affected IT infrastructure.

"Don't be afraid to look ignorant. And don't assume they have anti-virus or firewalls."

Also find out what groups were affected by the incident. Again, if it is the Web server, find out who uses it and let them know about the problem.

Define Communication Parameters

You are going to be working remotely with unfamiliar people, noted Zeltser.

"Understand who has what responsibilities and assign roles. If you are an incident handler, people are going to expect this of you. In many cases people will be glad someone is giving them direction."

Other key questions to ask at this stage: Which individuals are aware of the incident? What are their names and group or company affiliations? Write them all down and assign someone responsibility for communicating with them, said Zeltser.

Also, determine exactly who is the primary incident response coordinator.

"Sometimes there are many people who think they are charge," he said. "I think there should be one sole person who is ultimately in charge."

Consider, too, who is authorized to make business decisions regarding the incident. Is it an executive or manager? And decide how the response team should communicate. Will it be phone, email? What encryption capabilities should be used for that communication?

Also determine the schedule for internal and external progress updates and who will deliver them. Regular updates will be necessary because, as Zeltser pointed out: "If people don't hear from you, they will assume the worst."

Lastly, figure out who will conduct "in the field" examinations of the affected IT infrastructure. The incident handler may not be a technical person. Someone else may also have to handle communication with other departments, such as legal officials and members of the public relations team.