Importance Of Structured Incident Response Process

8/14/2019 Importance Of Structured Incident Response Process

1/14

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 Corporationssecurity infrastructure includes firewalls, intrusion detection systems, anti-virussoftware and operating system logs, all technology investments from the boomyears. 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 operators attention is directedelsewhere.

Meanwhile, the worm, which caused the above laptop problems, continues to

spread throughout Examples 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 Examples security monitoring capabilitiesdeployed in a DMZ and on a network perimeter, the remainder of Examplesvulnerable corporate assets are largely unguarded and unwatched. Thus, as theworm wends its way around Examples enterprise, the company security team isnot even aware of a developing disaster.

Page 1

8/14/2019 Importance Of Structured Incident Response Process

2/14

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 chaos

ensues. 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 helpdesk

operator 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 organizations 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 implicitly

follow 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

8/14/2019 Importance Of Structured Incident Response Process

3/14

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 todays 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 the

questions 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 and

non-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

8/14/2019 Importance Of Structured Incident Response Process

4/14

SANS Six Step Incident Response Methodology

Overall, the SANS methodology allows an organization to give structure to theotherwise chaotic incident response workflow. The steps of the SANSmethodology are both clearly defined and easy to follow, and most importantly,

work in the high-stress post-incident environments for which they were designed.

Following the steps is as easy as selecting and appropriately customizing theprocedures for each case at hand. Using the SANS pre-defined proceduresassures that an incident response workflow will become relatively painless andthe crucial steps will not be missed. Additionally, such a system will facilitateboth training and collaboration between various response team members, whocan share the workload for increased efficiency.

Finally, integrating the SANS methodology into an overall incident responseplanning assures todays IT organizations that they have a comprehensive

approach in-place to tackle security incidents. It also demonstrates compliancewith industry best practices, which is sometime associated with regulatorycompliance. Having a repeatable incident management process is highlighted inseveral recent regulations, such as HIPAA.

Lets spend just a moment reviewing a few key features of the SANS Six StepIncident Response methodology:

The Preparation stage covers everything one should do before handling the firstincident. It involves both technology issues, such as preparing response andforensics tools, learning the environment, configuring systems for optimal

response and monitoring, as well as business issues -- such as assigningresponsibility, forming a team and establishing escalation procedures.Additionally, this stage covers the steps necessary to increase a companyssecurity posture and thus decrease the likelihood and damage from futureincidents. Security audits, patch management, employee security awarenessprogram and other security tasks all serve to prepare the organization for incidentaction. Building a culture of security and a secure computing environment alsoserves as incident preparation.

Specifically, establishing a real-time system and network security eventmonitoring program will help to receive early warnings about the hostile activities

as well as collect evidence after the incident. Providing a single view into your security infrastructure goes a long way towards being more prepared andequipped to deal with the incidents as they occur as well as cleaning up in theaftermath. Single evidence storage allows performing sophisticated dataanalysis, leading to better awareness of threats and vulnerabilities.

Identification is what happens first when an incident is suspected or detected.Determining whether the observed event does in fact constitute an incident (as

Page 4

8/14/2019 Importance Of Structured Incident Response Process

5/14

defined above) is of crucial importance. Careful record keeping is very important,since such documentation will be heavily used at later stages of the responseprocess. One should record everything that was observed in relation to theincident, whether online or in the physical environment. During this stage, it isimportant that people responsible for incident handling maintain the proper chain

of custody (explained here http://en.wikipedia.org/wiki/Chain_of_custody asdocument or paper trail showing the seizure, custody, control, transfer, analysis,and disposition of physical and electronic evidence.). Contrary to popular opinion, this is important even when the case is never destined to end up incourt. Following established and approved procedures will help the investigationthat is internal to the company.

Various security technologies play a role in incident identification. For example,firewall, IDS, server and application logs reveal evidence of potentially hostileactivities, coming from both outside and inside the protected perimeter. Logs areoften tantamount in finding the party responsible for those activities. Security

event correlation is essential for high quality incident identification, due to itsability to uncover patterns in incoming security event flow. Collecting variousaudit logs and correlating them in near real-time goes a long way towards makingthe identification step of the response process less laborious. Additionally,incident identification is greatly helped by qualifying the IDS and other alertsusing other environment context, such as system and application vulnerabilities,running applications as well as business value.

Containment is what keeps the incident from spreading and thus incurringhigher financial or other loss. During this stage, the incident responders willintervene and attempt to limit the damage, such as by tightening network or host

access controls, changing system passwords, disabling accounts, etc. Whilecompleting the above steps, one should make every effort to keep all thepotential evidence intact, balancing the needs of system owners and incidentinvestigators. The backup of affected systems is also essential at this step. Thisis done to preserve the system for further investigation as well as remediation.The important decision on whether to continue operating the affected assetsshould be made by the appropriate authorities during this stage.

Automated containment measures, such as firewall blocking, systemreconfiguration or forced file integrity checks, and the use of intrusion preventionssolution (in the inline mode) can also be used, if driven by event correlation andmore intelligent analytics. However, automated containment will likely becomewidely accepted in the future.

Eradication is the only stage when the factors leading to the incident areeliminated or mitigated. Such factors often include system vulnerabilities, unsafesystem configurations, out-of-date protection software or even imperfect physicalaccess control. Also, the non-technology controls such as building accesspolicies or key card privileges might be adjusted at this stage. In the case of a

Page 5

8/14/2019 Importance Of Structured Incident Response Process

6/14

hacker-related incident, the affected systems are likely to be restored from thelast clean backup or rebuilt from the operating system vendor media with allapplications reinstalled.

Time is most critical during the eradication stage. The first response should

satisfy several often conflicting criteria, such as accommodating the systemowners requests, preserving evidence, stopping the spread of damage whilecomplying to all the appropriate organization's policies.

Recovery is the stage where the organization's operations return to normal.Systems are restored and configured to prevent recurrence and are returned toregular use. To insure that the newly established controls are working, theorganization might want to maintain increased monitoring of the affected assetsfor some period of time.

Return to production is always a critical step. If done too early, there is a

significant risk of recurrence; if done too late, it risks upsetting the businessowners. Thus, it should be clearly documented in the incident procedures duringthe preparation stage.

Follow-Up is an extremely important stage of the incident response process.Just as the preparation stage above, proper incident follow-up helps to ensurethat lessons are learned from the incident and that the overall security postureimproves as a result. Additionally, follow-up is important in order to prevent therecurrence of similar incidents. Additionally, a report on the incident is oftensubmitted to the senior management. It covers the actions taken, summarizesthe lessons learned and also serves as a knowledge repository in case of similar

incidents in the future.Follow-up steps often need to be distributed to a wider audience than the rest of the investigation process. Enterprise-wide security knowledge base helps toaddress this challenge. It will ensure that IT resource owners will be moreprepared to combat future threats. To optimize the distribution of incidentinformation, one can use various forms and templates, prepared in advanced for different types of incidents. Properly sanitized past incident cases should also beadded to an organization-wide security knowledge base, in addition to theindustry security resources and vulnerability knowledge. Such materials can later be used for training new incident responders as well as broader IT audience. Asummary of suggested actions might also be sent to the senior management.

Incident Response Tools

While people and processes are important, tools is what completes the securitytriangle. When the incident is suspected, the response team will need the tools toverify its status, assess damage that was incurred as well as can be occurredand then proceed to contain and recover from the incident. This involves a wide

Page 6

8/14/2019 Importance Of Structured Incident Response Process

7/14

range of tools from intrusion detection to forensics and vulnerabilitymanagement. Backup tools should also not be overlooked. Tools helpful for incident management can be organized as such:

Tools Common uses during incident response

Evidence collectionand storage System and security logs, audit trails, diskimages, email and other communicationData analysis andforensics

Correlation, searching and reporting,forensics discovery activities

Collaboration Incident team communication, workflow,team management

Backup Evidence preservation, known goodconfiguration retention, user data recovery

Documentation Actions logged for audit and improvement,reporting, incident team performancemeasurement, lessons learned, future team

training

Some tools are helpful in more than one of the above category. For example, aSecurity Information Management (SIM) solution often holds most of theevidence from the scene of the information security incident. Incident handling isa natural SIM product functionality aimed at gathering and organizing securityevent data around incidents and also enforcing proper response workflow inorder to facilitate effective and prompt response to security incidents.Specifically, a SIM can

Facilitates the effective handling process Integrates evidence storage and analysis

Enforces proper access control to evidence Enables team collaboration Simplifies resolution monitoring and reporting Makes security measurable

In general, it establishes a single control point of the security responsecapabilities by combining the major potential evidence storage with theinvestigative platform.

Other tools that an incident team needs to be very familiar with include diskimage forensics tools, covering the whole lifecycle from making a forensics copy

of the suspects workstation to final evidence presentation to an internal authorityor law enforcement. Those tools do require significant training, especially if usedfor cases where court trial is likely.

Example Corporation Worm Incident Revisited

Page 7

8/14/2019 Importance Of Structured Incident Response Process

8/14

A network helpdesk operator receives calls from several users all reportingcomputer failures and slow network response. Using a newly establishedprocess, a trained team and right tools, an incident case is opened according tothe plan and user complaints from that department are summarized andpresented to all relevant parties, including the security team contact. The affected

machines together with the information on their owners are also added tocorresponding case fields. The operator then assigns the case to the securityevent monitoring team, as mandated by his instructions, derived from the incidentplan.

Upon receiving the assignment through the case management system, amonitoring team member run several queries searching for suspicious events toand from the affected machines all as part of the incident identificationprocedure defined by the company. He discovers that a network IDS hasdetected an email worm being transmitted from outside the environment. Themonitoring team member shares the incident case with the security analyst team,

running the intrusion detection, so they can verify the impact of the IDS events,based on the affected asset business role and importance. Many eventsreported by the anti-virus systems running on some of the user's desktops werealso reported from the affected IP addresses. As a next step, an analyst selects aContainment procedure from the knowledge base, which involves quarantiningthe infected machines by applying a firewall rule to prevent the spread of theworm. The procedure is added to the incident case and then implemented.

Next, it is necessary to clean the infected PCs. The Mitigation procedureinvolves installing and running full scan using a freshly updated copy of anti-virussoftware. The security engineering team together with security analyst team

verifies compliance of the newly installed anti-virus system with the company'santi-virus policy.

The recommended Follow-up procedure includes a mandated company-widedesktop anti-virus deployment from a dedicated server. The procedure is thensubmitted for management approval and, once approved, the remediation teamassures that the anti-virus software is pushed out to all company desktop PCsand the incident case is closed.

Here is another example of how a company with a well-tuned incident responseprocess handles an attack against the web server.

A security analyst on duty received an email notification when a correlated eventon a successful attack was triggered by SIM solution. An analyst has discoveredthat a real-time correlation rule was matched by a series of events directedagainst the auxiliary web server.

By logging into their SIM and running a report, the analyst has found out that thetriggered rule aims to detect high-severity attacks against the web server, which

Page 8

8/14/2019 Importance Of Structured Incident Response Process

9/14

are preceded by the reconnaissance activity, such as a server version query. Theweb server was first probed for its type and version and later attacked by aknown exploit detected by the network intrusion detection system. The companysecurity monitoring procedure mandated that such be investigated.

Thus, the analyst clicked on the correlated event in the corresponding report andchose to add it to a new incident case. He then added a note saying that hereceived an email notification and started the investigation in accordance with thesecurity procedure.

After the case was registered by the system, the analyst proceeded to investigatethe related events. He opened the report to view the raw security events thattriggered the correlation. Such events included probes against multiple serversfollowed by an attack. He looked at the attack details and found out that the IDSsignature for the exploit matched the server type and the operating system. Headded all the related events to the incident case as well.

Further, he run an query to look for more traces of the same attackers IPaddress (the source) in the event database. Multiple entries indicative of scanning, denied connections on the firewall and TCP port 80 attempts acrossthe enterprise were discovered. The report results were also added to theincident case.

At that stage it was obvious that a consistent attack was in progress. The notewas added to the case Identification section saying that the incident is confirmedand several servers might have been impacted.

The analyst then searched all events involving the attacker web server. Nosuspicious activity has originated from it. However, since the server was not abusiness critical asset, it was possible to take it offline for investigation. Thisdecision was recorded in the Containment section of the incident case and theserver was taken offline.

The detailed server investigation that followed has not revealed any signs of asuccessful compromise. However, the server logs contained evidence of amultiple failed exploit attempts. The server was also found missing several criticalpatches. Their lack was apparently not detected by the attacker. It was decidedto patch the server before the regular maintenance window and to return itonline. It was also decided to increase the logging level on the server. Therespective note was made in the Mitigation section of the incident case and theabove steps were performed.

After the server was returned into operation, the analyst has assigned the case tothe incident manager who had the authority to review the performed steps and toclose the case. The manager added several notes to the follow-up section, which

Page 9

8/14/2019 Importance Of Structured Incident Response Process

10/14

suggested that servers in that subnet be scanned for vulnerabilities more often.The case was then closed.

Common Mistakes of Incident Response

While many organizations are on the path towards organizing their incidentresponse, many pitfalls lay in wait for them on the path to incident managementnirvana. This section summarizes several mistakes that companies make in their security incident response.

# 1 Not having a plan

The first mistake is simply not creating an incident response plan before incidentsstart happening. Having a plan in place (even a plan that is not well-thought)makes a world of difference! Such plan should cover all the stages of incident

response process from preparing the infrastructure to first response all the way tolearning the lessons of a successfully resolved incident.

If you have a plan, then after the initial panic phase, ('Oh, my, we are beinghacked!!!') you can quickly move into a set of planned activities, including achance to contain the damage and curb the incident losses. Having a checklist tofollow and a roster of people to call is of paramount importance in a stressfulpost-incident environment.

To jump-start the planning activity one can use a ready-made methodology, suchas SANS Institute 6-step incident response process, covered above. With a plan

and a methodology your team will soon be battle hardened and ready to respondto the next virus faster and more efficiently. As a result, you might manage tocontain the damage to your organization.

# 2 Failing to increase monitoring and surveillance

The second mistake is not deploying increased monitoring and surveillance after an incident has occurred. This is akin to shooting yourself in the foot during theincident response. Even though some companies cannot afford 24/7 securitymonitoring, there is no excuse for not increasing monitoring after an incident hasoccurred.

At the very least, one of the first things to do after an incident is to crank up allthe logging, auditing and monitoring capabilities in the affected network andsystems. This simple act has the potential to make or break the investigation byproviding crucial evidence for identifying the cause of the incident and resolvingit. It often happens that later in the response process, the investigators discover that some critical piece of log file was rotated away or an existing monitoringfeature was forgotten in an 'off' state. Having plenty of data on what was going

Page 10

8/14/2019 Importance Of Structured Incident Response Process

11/14

on in your IT environment right after the incident will not just make theinvestigation easier, it will likely make it successful.

Another side benefit, is that increased logging and monitoring will allow theinvestigators to confirm that they indeed have followed the established chain of

custody

#3. Being unprepared for a court battle

The third mistake is often talked about, but rarely avoided. Some experts haveproclaimed that every security incident needs to be investigated as if it will endup in court. In other words, maintaining forensic quality and following theestablished chain of custody needs to be assured during the investigation.

Even if the case looks as if it will not go beyond the suspect's manager or the

human resources department (in the case of an internal offense) or even thesecurity team itself (in many external hacking and virus incidents), there isalways a chance that it will end up in court. Cases have gone to court after newevidence was discovered during an investigation, and, what was thought to be asimple issue of inappropriate Web access became a criminal child pornographycase.

Moreover, while you might not be expecting a legal challenge, the suspect mightsue in retaliation for a disciplinary action against him or her. A seasoned incidentinvestigator should always consider this possibility.

In addition, following a high standard of investigative quality always helps sincethe evidence will be that much more reliable and compelling, if it can be backedup by a thorough and well-documented procedure.

#4. Putting it back the way it was

The fourth mistake is reducing your incident response to "putting it back the wayit was". This often happens if the company is under deadline to restore thefunctionality. While this motive is understandable, there is a distinct possibilitythat failing to find out why the incident occurred will lead to repeat incidents, onthe same or different systems.

For example, in the case of a hacking incident, if an unpatched machine thatwas compromised is rebuilt from the original OS media, but the exploitedvulnerability is not removed, the hackers are very likely to come back and take itover again. Moreover, the same fate will likely befall other exposed systems.Thus, while returning to operation might be the primary goal, dont lose sight of the secondary goal: figuring out what happened and how to prevent it fromhappening again. It feels bad to be on the receiving end of the successful attack,

Page 11

8/14/2019 Importance Of Structured Incident Response Process

12/14

but it feels much worse to be hit twice by the same threat and have you defensesfell in both cases.

Incident response should not be viewed as a type of "firefighting" although youdfight plenty of fires in the process. It can clearly help in case of a fire, but it can

also help prevent fires in the future.

#5. Not learning from mistakes

The final mistake sounds simple, but it is all too common. It is simply not learningfrom mistakes! Creating a great plan for incident response and following it willtake the organization a long way toward securing the company, but what isequally important is refining your plan after each incident, since the team and thetools might have changed over time.

Another critical component is documenting the incident as it is occurring, not just

after the fact. This assures that the "good, the bad and the ugly" of the handlingprocess will be captured, studied and lessons will be drawn from it. The results of such evaluations should be communicated to all the involved parties, including ITresource owners and system administrators.

Ideally, the organization should build an incident-related knowledge base, so thatprocedures are consistent and can be repeated in practices. The latter is veryimportant for regulatory compliance as well and will help satisfying some of theSarbanes-Oxley requirements for auditing the controls to information.

Conclusion

While the above cases are simplistic in nature they readily show the need for anysecurity management system to have not only an incident response plan but alsoan integrated incident handling system to ensure complete and effectiveresponse planning deployment. Having a highly efficient plan helps organizationssave money by limiting the impact on core business from security incidents andincreasing the efficiency of existing security infrastructure investments. Overall,the SANS process allows one to give structure to the otherwise chaotic incidentresponse workflow. It defines the steps that will then be followed under incident-induced stress with high precision.

In fact, many of the above steps may be built from the pre-defined procedures.Following the steps will then be as easy as selecting and sometimes customizingthe procedures for each case at hand. Incident handling workflow will becomemore streamlined and the crucial steps will not be missed and documentedproperly. Using pre-defined procedures also helps train the incident responsestaff on proper actions for each process step. The automated system may bebuilt to keep track of the response workflow, to suggest proper procedures for various steps and to securely handle incident evidence. Additionally, such a

Page 12

8/14/2019 Importance Of Structured Incident Response Process

13/14

system will facilitate collaboration between various response team members,who can share the workload for increased operational efficiency.

What is even more important, monitoring incident resolution activities allows theorganization to implement effective security metrics. It is one thing to count

number of alerts or events flowing from various sensors, but to take securityassessment to the next level one needs to measure the performance of thewhole security process, involving both people (such as security team membersworking on the incident cases) and technologies.

ABOUT THE AUTHOR :This is an updated author bio, added to the paper at the time of reposting in2009.

Dr. Anton Chuvakin ( http://www.chuvakin.org ) is a recognized security expert in

the field of log management and PCI DSS compliance. He is an author of books"Security Warrior" and "PCI Compliance" and a contributor to "Know Your EnemyII", "Information Security Management Handbook" and others. Anton haspublished dozens of papers on log management, correlation, data analysis, PCIDSS, security management (see list www.info-secure.org ) . His bloghttp://www.securitywarrior.org is one of the most popular in the industry.

In addition, Anton teaches classes and presents at many security conferencesacross the world; he recently addressed audiences in United States, UK,Singapore, Spain, Russia and other countries. He works on emerging securitystandards and serves on the advisory boards of several security start-ups.

Currently, Anton is developing his security consulting practice, focusing onlogging and PCI DSS compliance for security vendors and Fortune 500organizations. Dr. Anton Chuvakin was formerly a Director of PCI ComplianceSolutions at Qualys. Previously, Anton worked at LogLogic as a Chief LoggingEvangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by asecurity vendor in a strategic product management role. Anton earned his Ph.D.degree from Stony Brook University.

GlossarySecurity event is a single observable occurrence as reported by a security deviceor application or noticed by the appropriate personnel. Thus, both IDS alert andsecurity-related helpdesk call will qualify as security events.

Security incident is an occurrence of one or several security events that have apotential to cause undesired functioning of IT resources or other related

Page 13

8/14/2019 Importance Of Structured Incident Response Process

14/14

problems. Thus, that limits our discussion to information security incidents, whichcover computer and network security, intellectual property theft and many other issues.

Incident response (or IR) is a process of identification, containment, eradication

and recovery from computer incidents performed by a responsible security team.It is worthwhile to note, that the security team might consist of just one person,who might only be a part-time incident responder. However, whoever takes partin dealing with the incident consequences implicitly becomes part of the incidentresponse team, even if such team does not exist as organizations part.

Incident case is a collection of evidence and associated workflow related to asecurity incident. Thus, the case is a history of what happened, what was donewith evidence supporting both items above. It might include various documentssuch as reports, security event data, results of audio interviews, images files andother etc.

Incident report is a document prepared as a result of an incident caseinvestigation. Incident report might be cryptographically signed or have other assurances of its integrity. Most incident investigations will result in the reportsubmitted to appropriate authorities (either internal or outside the company),which might contain some or even all data associated with the case.

It is worthwhile to note that the term evidence is used throughout the chapter indicates any data discovered in the process of incident response.

Page 14