Computer security incident management: Difference between revisions

Revision as of 13:00, 29 March 2017

Latest revision as of 11:53, 17 July 2025

(51 intermediate revisions by 26 users not shown)

Line 1:

{{technicalhow-to|date=MayNovember 20142024}}

In the fields of [[computer security]] and [[information technology]], '''computer security incident management''' involves the monitoring and detection of security events on a [[computer]] or [[computer network]], and the execution of proper responses to those events. Computer security incident management is a specialized form of [[incident management]], the primary purpose of which is the development of a well understood and predictable response to damaging events and computer intrusions.<ref>{{cite web

| title =ISO 17799{{!}}ISO/IEC 17799:2005(E)

Line 9 ⟶ 10:

}}</ref>

Incident management requires a process and a response team which follows this process. In the United States, This definition of computer security incident management follows the standards and definitions described in the [[National Incident Management System]] (NIMS). The [[Computer security incident management#Definitions|'''''incident coordinator''''']] manages the response to an emergency security incident. In a Natural Disaster or other event requiring response from Emergency services, the ''incident coordinator'' would act as a liaison to the emergency services incident manager.<ref>{{cite web

|title=NIMS - The Incident Command System

|work=National Incident Management System

|publisher=Department of Homeland Security

|date=2004-03-01

|url=http://www.nimsonline.com/nims_3_04/incident_command_system.htm

|accessdate=2007-04-08

|archiveurl=https://web.archive.org/web/20070318154341/http://www.nimsonline.com/nims_3_04/incident_command_system.htm

|archivedate=2007-03-18

|url-status=usurped

|deadurl=yes

|df=

}}</ref>

== OverviewIncident response plans ==

An incident response plan (IRP) is a group of policies that dictate an organizations reaction to a cyber attack. Once a security breach has been identified, for example by [[Intrusion detection system|network intrusion detection system]] (NIDS) or [[host-based intrusion detection system]] (HIDS) (if configured to do so), the plan is initiated.<ref>{{Citation|last=Fowler|first=Kevvie|title=Developing a Computer Security Incident Response Plan|date=2016|url=http://dx.doi.org/10.1016/b978-0-12-803451-4.00003-4|work=Data Breach Preparation and Response|pages=49–77|publisher=Elsevier|doi=10.1016/b978-0-12-803451-4.00003-4|isbn=978-0-12-803451-4|access-date=2021-06-05|url-access=subscription}}</ref> It is important to note that there can be legal implications to a data breach. Knowing local and federal laws is critical.<ref>{{cite journal |last1=Bisogni |first1=Fabio |title=Proving Limits of State Data Breach Notification Laws: Is a Federal Law the Most Adequate Solution? |journal=Journal of Information Policy |date=2016 |volume=6 |pages=154–205 |doi=10.5325/jinfopoli.6.2016.0154 |jstor=10.5325/jinfopoli.6.2016.0154 |doi-access=free }}</ref> Every plan is unique to the needs of the organization, and it can involve skill sets that are not part of an IT team.<ref>{{Citation|title=Understanding Plan for Every Part|date=2017-07-27|url=http://dx.doi.org/10.1201/b10336-5|work=Turbo Flow|pages=21–30|publisher=Productivity Press|doi=10.1201/b10336-5|isbn=978-0-429-24603-6|access-date=2021-06-05|url-access=subscription}}</ref> For example, a lawyer may be included in the response plan to help navigate legal implications to a data breach.{{citation needed|date=January 2023}}

Computer security incident management is an administrative function of managing and protecting computer assets, networks and information systems. These systems continue to become more critical to the personal and economic welfare of our society. Organizations (public and private sector groups, associations and enterprises) must understand their responsibilities to the public good and to the welfare of their memberships and stakeholders. This responsibility extends to having a management program for “what to do, when things go wrong.” Incident management is a program which defines and implements a process that an organization may adopt to promote its own welfare and the security of the public.

As mentioned above every plan is unique but most plans will include the following:<ref name=":02">{{cite web |last1=Wills |first1=Leonard |title=A Brief Guide to Handling a Cyber Incident |url=https://www.americanbar.org/groups/litigation/committees/minority-trial-lawyer/practice/2019/a-brief-guide-to-handling-a-cyber-incident/ |work=American Bar Association |date=27 February 2019 }}</ref>

== Components of an incident ==

=== EventsPreparation ===

Good preparation includes the development of an incident response team (IRT).<ref>{{Citation|last=Johnson|first=Leighton R.|title=Part 1. Incident Response Team|date=2014|url=http://dx.doi.org/10.1016/b978-1-59749-996-5.00038-8|work=Computer Incident Response and Forensics Team Management|pages=17–19|publisher=Elsevier|doi=10.1016/b978-1-59749-996-5.00038-8|isbn=978-1-59749-996-5|access-date=2021-06-05|url-access=subscription}}</ref> Skills need to be used by this team would be, penetration testing, computer forensics, network security, etc.<ref>{{Cite journal|date=February 2014|title=Computer Incident Response and Forensics Team Management|url=http://dx.doi.org/10.1016/s1353-4858(14)70018-2|journal=Network Security|volume=2014|issue=2|pages=4|doi=10.1016/s1353-4858(14)70018-2|issn=1353-4858|url-access=subscription}}</ref> This team should also keep track of trends in [[cybersecurity]] and modern attack strategies.<ref>{{Citation|title=Cybersecurity Threat Landscape and Future Trends|date=2015-04-16|url=http://dx.doi.org/10.1201/b18335-12|work=Cybersecurity|pages=304–343|publisher=Routledge|doi=10.1201/b18335-12|isbn=978-0-429-25639-4|access-date=2021-06-05|url-access=subscription}}</ref> A training program for end users is important as well as most modern attack strategies target users on the network.<ref name=":02" />

An event is an observable change to the normal behavior of a system, environment, process, workflow or person (components). There are three basic types of events:

# Normal—a normal event does not affect critical components or require change controls prior to the implementation of a resolution. Normal events do not require the participation of senior personnel or management notification of the event.

# Escalation – an escalated event affects critical production systems or requires that implementation of a resolution that must follow a change control process. Escalated events require the participation of senior personnel and stakeholder notification of the event.

# Emergency – an emergency is an event which may

## impact the health or safety of human beings

## breach primary controls of critical systems

## materially affect component performance or because of impact to component systems prevent activities which protect or may affect the health or safety of individuals

## be deemed an emergency as a matter of policy or by declaration by the available incident coordinator

Computer security and information technology personnel must handle emergency events according to well-defined computer security incident response plan.

As part of the preparation phase in incident response plan should be developed and address the following:

=== Incident ===

An incident is an event attributable to a human root cause. This distinction is particularly important when the event is the product of malicious intent to do harm. An important note: all incidents are events but many events are not incidents. A system or application failure due to age or defect may be an emergency event but a random flaw or failure is not an incident.

* Roles and Responsibilities

=== Incident response team ===

* Lists the incident response team (IRT) members and their duties

The security ''incident coordinator'' manages the response process and is responsible for assembling the team. The coordinator will ensure the team includes all the individuals necessary to properly assess the incident and make decisions regarding the proper course of action. The incident team meets regularly to review status reports and to authorize specific remedies. The team should utilize a pre-allocated physical and virtual meeting place.<ref>{{cite web

* Communication protocols

| title =Creating a Computer Security Incident Response Team

* Training and awareness

| work =Computer Emergency Response Team

* Logging policies and configurations

| publisher =US-CERT

* Event status definitions and thresholds

| date =2003-04-01

* Playbooks and runbooks for common incident types

| url =http://www.cert.org/archive/pdf/csirt-handbook.pdf

* Legal and compliance considerations<ref>{{Cite report |url=https://csrc.nist.gov/pubs/sp/800/61/r2/final |title=Computer Security Incident Handling Guide |last=Cichonski |first=Paul |last2=Millar |first2=Thomas |last3=Grance |first3=Tim |last4=Scarfone |first4=Karen |date=2012-08-06 |publisher=National Institute of Standards and Technology |issue=NIST Special Publication (SP) 800-61 Rev. 2 (Withdrawn) |language=en}}</ref>

| accessdate =2007-04-08 }}</ref>

=== Incident investigationIdentification ===

This part of the incident response plan identifies if there was a security event.<ref>{{Citation|title=Information technology. Security techniques. Information security incident management|url=http://dx.doi.org/10.3403/30268878u|publisher=BSI British Standards|doi=10.3403/30268878u|access-date=2021-06-05|url-access=subscription}}</ref> When an end user reports information or an admin notices irregularities, an investigation is launched. An incident log is a crucial part of this step.{{Citation needed| reason=article has nothing to with incident logs|date=December 2023}} All of the members of the team should be updating this log to ensure that information flows as fast as possible.<ref>{{Citation|last=Turner|first=Tim|title=Our Beginning: Team Members Who Began the Success Story|date=2011-09-07|url=http://dx.doi.org/10.4324/9781466500020-2|work=One Team on All Levels|pages=9–36|publisher=Productivity Press|doi=10.4324/9781466500020-2|isbn=978-0-429-25314-0|access-date=2021-06-05|url-access=subscription}}</ref> If it has been identified that a security breach has occurred the next step should be activated.<ref>{{Cite book|title=Defensive Strategies|last=Erlanger|first=Leon|publisher=PC Magazine|year=2002|pages=70}}</ref>

The investigation seeks to determine the circumstances of the incident. Every incident will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

=== ProcessContainment ===

In this phase, the IRT works to isolate the areas that the breach took place to limit the scope of the security event.<ref>{{Citation|title=of Belgrade's main street. The event took place in absolute|date=2013-11-05|url=http://dx.doi.org/10.4324/9781315005140-28|work=Radical Street Performance|pages=81–83|publisher=Routledge|doi=10.4324/9781315005140-28|isbn=978-1-315-00514-0|access-date=2021-06-05|url-access=subscription}}</ref> During this phase it is important to preserve information forensically so it can be analyzed later in the process.<ref>{{Cite book |title=The Manipulation of Choice|publisher=Palgrave Macmillan|year=2013|isbn=978-1-137-31357-7|chapter=Why Choice Matters So Much and What Can be Done to Preserve It|doi=10.1057/9781137313577_7 |last1=White |first1=Mark D. |pages=127–150 }}</ref> Containment could be as simple as physically containing a server room or as complex as segmenting a network to not allow the spread of a virus.<ref name=":2">{{cite web|url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf|title=Computer Security Incident Handling Guide|date=2012|website=Nist.gov}}</ref>

=== Eradication ===

=== Initial incident management process ===

This is where the threat that was identified is removed from the affected systems.<ref>{{Cite journal|title=Table S3: Results from linear-mixed models where {{sic|non-signf|icant|nolink=y}} parameters have not been removed |journal=PeerJ|date=4 April 2016|volume=4|pages=e1867 |doi=10.7717/peerj.1867/supp-3|last1=Borgström|first1=Pernilla|last2=Strengbom|first2=Joachim|last3=Viketoft|first3=Maria |last4=Bommarco|first4=Riccardo |doi-access=free }}</ref> This could include deleting malicious files, terminating compromised accounts, or deleting other components.<ref>{{Citation|last=Penfold|first=David|title=Selecting, Copying, Moving and Deleting Files and Directories |date=2000 |work=ECDL Module 2: Using the Computer and Managing Files|pages=86–94 |place=London|publisher=Springer London|doi=10.1007/978-1-4471-0491-9_6|doi-broken-date=11 July 2025 |isbn=978-1-85233-443-7}}</ref><ref>{{Cite book|first=Onur|last=Gumus|title=ASP. NET Core 2 Fundamentals : Build Cross-Platform Apps and Dynamic Web Services with This Server-side Web Application Framework|date=2018|publisher=Packt Publishing Ltd|isbn=978-1-78953-355-2|oclc=1051139482}}</ref> Some events do not require this step, however it is important to fully understand the event before moving to this step.<ref>{{Citation|date=2005-02-25|url=http://dx.doi.org/10.4324/9780203416907-8|work=Trouble-shooting Your Teaching|pages=36–40 |publisher=Routledge|doi=10.4324/9780203416907-8|isbn=978-0-203-41690-7|access-date=2021-06-05|title=Do the Students Understand What They Are Learning?|url-access=subscription}}</ref> This will help to ensure that the threat is completely removed.<ref name=":2" />

[[Image:Computer-security-incident-initial-process(high-res).png|thumb|250px|right|Author: Michael Berman (tanjstaffl)]]

# Employee, vendor, customer, partner, device or sensor reports event to ''Help Desk''.

# Prior to creating the ticket, the help desk may filter the event as a false positive. Otherwise, the help desk system creates a ticket that captures the event, event source, initial event severity and event priority.

## The ticket system creates a unique ID for the event. IT Personnel must use the ticket to capture email, IM and other informal communication.

## Subsequent activities like change control, incident management reports and compliance reports must reference the ticket number.

## In instances where event information is “Restricted Access,” the ticket must reference the relevant documents in the secure document management system.

# The ''First Level Responder'' captures additional event data and performs preliminary analysis. The First Responder determines criticality of the event. At this level, it is either a Normal or an Escalation event.

## Normal events do not affect critical production systems or require change controls prior to the implementation of a resolution.

## Events that affect critical production systems or require change controls must be escalated.

## Organization management may request an immediate escalation without first level review – 2nd tier will create ticket.

# The event is ready to resolve. The resource enters the resolution and the problem category into the ticket and submits the ticket for closure.

# The ticket owner (employee, vendor, customer or partner) receives the resolution. They determine that the problem is resolved to their satisfaction or escalate the ticket.

# The escalation report is updated to show this event and the ticket is assigned a second tier resource to investigate and respond to the event.

# The Second Tier resource performs additional analysis and re-evaluates the criticality of the ticket. When necessary, the Second Tier resource is responsible for implementing a change control and notifying IT Management of the event.

# Emergency Response:

## Events may follow the escalation chain until it is determined that an emergency response is necessary.

## Top-level organization management may determine that an emergency response is necessary and invoke this process directly.

=== Emergency response detailRecovery ===

This stage is where the systems are restored back to original operation.<ref>{{Citation|title=Where Are Films Restored, Where Do They Come From and Who Restores Them?|work=Film Restoration|year=2013 |publisher=Palgrave Macmillan|doi=10.1057/9781137328724_3 |isbn=978-1-137-32872-4 |last1=Enticknap |first1=Leo |pages=45–70 }}</ref> This stage could include the recovery of data, changing user access information, or updating firewall rules or policies to prevent a breach in the future.<ref>{{Cite journal|last1=Liao|first1=Qi|last2=Li|first2=Zhen|last3=Striegel|first3=Aaron|date=2011-01-24|title=Could firewall rules be public - a game theoretical perspective|url=http://dx.doi.org/10.1002/sec.307|journal=Security and Communication Networks|volume=5|issue=2|pages=197–210|doi=10.1002/sec.307|issn=1939-0114|url-access=subscription}}</ref><ref>{{Cite book|first1=Philip|last1=Boeckman |first2=David J.|last2=Greenwald|first3=Nilufer|last3=Von Bismarck|title=Twelfth annual institute on securities regulation in Europe : overcoming deal-making challenges in the current markets|date=2013|publisher=Practising Law Institute|isbn=978-1-4024-1932-4|oclc=825824220}}</ref> Without executing this step, the system could still be vulnerable to future security threats.<ref name=":2" />

[[Image:Computer-security-emergency-response-process(high-res).png|thumb|250px|right|Author: Michael Berman (tanjstaffl)]]

# Emergency response is initiated by escalation of a security event or be direct declaration by the CIO or other executive organization staff. The CIO may assign the incident coordinator, but by default, the coordinator will be the most senior security staff member available at the time of the incident.

# The incident coordinator assembles the incident response team. The team meets using a pre-defined conference meeting space. One of the (CIO, CSO or Director IT) must attend each incident team meeting.

# The meeting minutes capture the status, actions and resolution(s) for the incident. The incident coordinator reports on the cost, exposure and continuing business risk of the incident. The incident response team determines the next course of action.

# Lock-down and Repair – Perform the actions necessary to prevent further damage to the organization, repair impacted systems and perform changes to prevent a re-occurrence.

# False Positive – The incident team determines this issue did not warrant an emergency response. The team provides a written report to senior management and the issue is handled as either a normal incident or it is closed.

# Monitor and Capture – Perform a thorough investigation with continued monitoring to detect and capture the perpetrator. This process must include notification to the following senior and professional staff:

## CEO and CFO

## Corporate Attorney and Public Relations

# Review and analyze log data to determine nature and scope of incident. This step should include utilizing virus, spyware, rootkit and other detection tools to determine necessary mitigation and repair.

# Repair systems, eliminate vector(s) of attack, and mitigate exploitable vulnerabilities.

# The ''Test Report'' documents the validation of the repair process.

## Test systems to ensure compliance with policy and risk mitigation.

## Perform additional repairs to resolve all current vulnerabilities.

# Investigate incident to determine source of attack and capture perpetrator. This will require the use of forensics tools, log analysis, clean lab and dirty lab environments and possible communication with Law Enforcement or other outside entities.

# The “Investigation Status Report” as captures all current information regarding the incident. The Incident response team uses this information to determine the next course of action. (See Ref 2 and Ref 3)

=== DefinitionsLessons learned ===

In this step information that has been gathered during this process is used to make future decisions on security.<ref>{{Cite web|title=Figure 1.8. Spending of social security has been growing, while self-financing has been falling|url=http://dx.doi.org/10.1787/888932459242|access-date=2021-06-05|doi=10.1787/888932459242}}</ref> This step is crucial to the ensure that future events are prevented. Using this information to further train admins is critical to the process.<ref>{{Citation|title=Information Governance: The Crucial First Step|date=2015-09-19|url=http://dx.doi.org/10.1002/9781119204909.ch2|work=Safeguarding Critical E-Documents|pages=13–24|place=Hoboken, NJ, US|publisher=John Wiley & Sons, Inc.|doi=10.1002/9781119204909.ch2|isbn=978-1-119-20490-9|access-date=2021-06-05|url-access=subscription}}</ref> This step can also be used to process information that is distributed from other entities who have experienced a security event.<ref>{{Cite journal|last=He|first=Ying|date=December 1, 2017|title=Challenges of Information Security Incident Learning: An Industrial Case Study in a Chinese Healthcare Organization|journal=Informatics for Health and Social Care|volume=42|issue=4|pages=394–395|doi=10.1080/17538157.2016.1255629|pmid=28068150|s2cid=20139345|url=http://eprints.gla.ac.uk/134944/7/134944.pdf}}</ref>

;First Responder/First level review: first person to be on scene or receive notification of an event, organizations should provide training to the first responder to recognize and properly react to emergency circumstances.

;Help Desk Ticket (Control): an electronic document captured in a database and issue tracking/resolution system

;Ticket Owner: person reporting the event, the principal owner of the assets associated with the event or the common law or jurisdictional owner.

;Escalation Report (Control): ''First Responder’s'' documentation for ticket escalation, the Responder writes this information into the ticket or the WIKI log for the event. The ticket references the WIKI log for the event.

;Second Tier: Senior technical resources assigned to resolve an escalated event.

;Incident Coordinator: individual assigned by organization senior management to assemble the incident response team, manage and document response to the incident.

;Investigation Status Report (Control): documentation of the current investigation results, the coordinator may document this material in the ticket, WIKI or an engineer’s journal.

;Meeting Minutes (Control): documentation of the incident team meeting, the minutes document the attendees, current nature of the incident and the recommended actions. The coordinator may document this material in the ticket, WIKI or an engineer’s journal.

;Lock-down Change Control: a process ordered as a resolution to the incident. This process follows the same authorization and response requirements as an Emergency Change Control.

;Test Report (Control): this report validates that IT personal have performed all necessary and available repairs to systems prior to bringing them back online.

;War Room: a secure environment for review of confidential material and the investigation of a security incident.

;Report to Senior Management (Control): the ''incident coordinator'' is responsible for drafting a senior management report. The coordinator may document this material in the ticket, WIKI or an engineer’s journal

==See also==

'''Incident Response Steps'''

* [[Computer emergency response team]]

'''Detection'''- An incident can be detected by a sensor, a network analyst or a user reporting something unusual with his/her PC.

* [[Proactive cyber defence]]

'''Containment'''- In the event of malicious network traffic or a computer virus, the Incident Response Manager should stop the traffic by taking the computer off the network.

*[[Cyber attribution]]

'''Clean'''- Run a virus scan to remove the virus or wipe the computer clean and reimage the machine.

'''Reverse Engineering'''- Use computer forensics tools to understand why the malicious traffic occurred in the first place. Once the incident is completely understood make plans to decrease your future risk.

== References ==

<references />

== Further reading ==

* Handbook for Computer Security Incident Response Teams (CSIRTs) http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

[[Category:Incident management]]

*Handbook for Computer Security Incident Response Teams (CSIRTs) http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

[[Category:Cybersecurity engineering]]

*[[National Incident Management System]]

[[Category:Computer security]]