• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Importance Of Structured Incident Response Process
 Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
WRITTEN: 2004
Example..................................................................................................................1Introduction.............................................................................................................2SANS Six Step Incident Response Methodology...................................................4Incident Response Tools........................................................................................6Example Corporation – Worm Incident Revisited...................................................7Common Mistakes of Incident Response.............................................................10Conclusion............................................................................................................12Glossary................................................................................................................13
DISCLAIMER
:
Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with suchever-changing reality, one has to evolve with the space as well. Thus, eventhough I hope that this document will be useful for to my readers, please keep inmind that is was possibly written years ago. Also, keep in mind that some of theURL might have gone 404, please Google around.
Example
Right around lunchtime, a helpdesk operator at Example Corporation -- amedium-sized manufacturing company – receives calls from several users allreporting computer failures and slow network response. Example Corporation’ssecurity infrastructure includes firewalls, intrusion detection systems, anti-virussoftware and operating system logs, all technology investments from the “boom”years. The helpdesk operator opens a new trouble ticket in Remedy, describingthe users’ problems and recording the machines’ hostnames. Other unrelatedsupport issues continue to pile up and the operator’s attention is directedelsewhere.Meanwhile, the worm, which caused the above laptop problems, continues tospread throughout Example’s network. The malicious software made its way intoExample after being brought in by one of the sales people who often plugs hislaptop into untrusted networks, such as hotels and customer environments,outside the company. With most of the Example’s security monitoring capabilitiesdeployed in a DMZ and on a network perimeter, the remainder of Example’svulnerable corporate assets are largely unguarded and unwatched. Thus, as theworm wends its way around Example’s enterprise, the company security team isnot even aware of a developing disaster.
Page 1
 
Soon, network traffic generated by the worm has increased dramatically, as moremachines become infected and start spewing copies of the same worm. Whenthe infection reaches critical levels and starts to affect the performance of monitored servers, the security team is notified by a flood of pager alerts… chaosensues. While some try installing anti-virus updates other apply firewall blocks(preventing not only worm scanning, but also the download of updates) and yetothers try to scan for vulnerable machines that contributes to the network-leveldenial-of-service.After hours of uncoordinated activities, most of the worm-carrying machines arediscovered and the re-infection rate is brought under control. A managementrequested investigation begins and computer forensic consultants are brought in.However, what remained of the initial infection evidence was either destroyed or extremely hard to find due to “mitigation” activities that were implemented. Noone remembered the original Remedy incident recorded by the helpdeskoperator since the helpdesk system was not deemed relevant for securityinformation. The investigation was able to conclude only that the malicioussoftware was brought in from outside the company -- the specific initial infectionvector was never determined.The financial and technological damage is easy to see. And yet, the recurringsecurity incident described above shows what happens when companies lack acentral point from which to manage security incidents.
Introduction
Security professionals learn to constantly chant the mantra “prevention-detection-response.” Each of these three components is known to be of crucial importanceto the organization’s security posture. However, unlike detection and prevention,the response is impossible to avoid. While it is not uncommon for theorganizations to have weak prevention and nearly non-existent detectioncapabilities, response will have to be there since the organization will often beforced into response mode by the attackers (be it the internal abuser,omnipresent “script kiddie” or the elusive “uber-hacker”) or their evil creations(viruses, worms and spyware). The organization will likely be
made
to respond insome way after the incident has taken place. Even in cases where ignoring theincident that happened might be the chosen option, the organization will implicitlyfollow a
response plan
, even if as ineffective as to do nothing.In light of this, being prepared for incident response is likely to be one of the mostcost effective security measures the organization takes. Timely and effectiveincident response is directly related to decreasing the incident-induced loss to theorganization. It can also help to prevent an expensive and hard-to-repair reputation damage, which often occurs following the security incident. Severalindustry surveys have identified that public company's stock price may plunge
Page 2
 
several percent as a result of a publicly disclosed incident(http://www.securityfocus.com/news/11197). Incidents that are known to wreakcatastrophic results upon the organizations may involve malicious hacking, virusoutbreaks, economic espionage, intellectual property theft, network accessabuse, theft of IT resources and other policy violations.Most of us in the security industry are already familiar with the traditionalchallenges we face every day… too much security data to sift through, too manyfalse alarms to deal with, and not enough budget or resource to handle an ever-growing number of security incidents. One additional and often overlookedchallenge involves the security management process itself. Largely ignored inmany of today’s IT enterprises, a clearly defined, documented, and repeatableincident management process defined in an incident response plan isfundamental to ensuring fast and accurate handling of security incidents.Even if an explicit incident response plan is lacking, after the incident occurs thequestions such as these might be asked by the company management:
•
What to do now?
•
How to put it the way it was?
•
How to prevent recurrence?
•
How we should have prepared?
•
Should we try to figure who is responsible?Answering these questions requires knowledge of your computing environment,company culture and internal procedures, implemented technical security andpolicy countermeasures. Effective incident response fuses together technical andnon-technical resources, bound by the incident response policy, procedures andplans. Such policy should be continuously refined and improved, based on theorganization's incident history, just as the main security policy should be.To build an initial incident resolution management framework one can use SANSSix Step incident response methodology. This approach was originally developedfor US Department of Energy, adopted elsewhere in the US government andthen popularized by the SANS Institute(http://www.sans.org/rr/whitepapers/incident/)The methodology includes the following six steps:
1.Preparation2.Identification3.Containment4.Eradication5.Recovery6.Follow-Up
Page 3
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...