Boston- "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.
Assess the Incident's Scope
In this step it is crucial to understand how data flows through the system, said Zeltser.
What IT infrastructure components (Web sites, networks, servers, etc.) are directly affected by the incident? Also, what applications and data processes make use of the affected IT infrastructure components?
At this stage you will also want to consider compliance implications. If your company has a compliance officer, he or she should be contacted now.
Consider not just what you want to do but also "what we have to do under law," said Zeltser.
At this point it is prudent to also consider how this incident happened.
"How did they get in?" said Zeltser. "What are the possible ingress and egress points for the affected environment? "
Theories about how the incident occurred should also be explored now. And, in keeping with good corporate citizenry, consider if the incident would pose any risk to outside organizations.
Review the Initial Incident Survey's Results
Now you will want to consider what data from the initial analysis you can use going forward. During this step you will also want to determine what forensic details may have been lost.
"Every time you touch a system, you modify its state," said Zeltser.
What commands or tools were executed on the affected systems? What measures were taken to contain the scope of the incident? These can all impact potential forensic evidence.
Also take time now to review logs and see if there are any suspicious entries.
Prepare for Next Incident Response Steps
Does the your group or organization have specific incident response instructions or guidelines? If you are an outside responder helping out, don't assume that people know what to do. You may be dealing with outdated procedures and untrained staff, said Zeltser.
Now is the time to decide whether or proceed with live analysis or start formal forensic examination? Some companies could care less about forensics and simply want to do live analysis to deal with the problem and get back to business as soon as possible, noted Zeltser.
Other key things to ask now: What tools are available to us for monitoring network or host-based activities in the affected environment? What mechanisms exist to transfer files to and from the affected IT infrastructure components during the analysis? (e.g., network, USB, CD-ROM, etc.) Where are the affected IT infrastructure components physically located? What backup-restore capabilities are in place to assist in recovering from the incident?
Lastly, decide what the next steps will be. Who will do what and when? Now you've got a comprehensive mass of information to use to help you decide.