TERENA Incident Taxonomy and Description Working Group
Work in progress
Editor: Jimmy Arvidsson, Telia CERT
1. Scope of this document
Taxonomy of terminology used in Incident Object Description and Exchange Format, particularly:
2. Attack vs Attacker
Attack
An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system. Attack can be active or passive, by insider or by outsider, or via attack mediator.
Attacker
Attacker is individual who attempts one or more attacks in order to achieve an objective(s) [Sandia].
For the purpose of IODEF attacker is described by its network ID, organisation
which network/computer attack was originated and physical location information
(optional).
3. Target vs Victim
Target
A computer or network logical entity (account, process or data) or physical entity (component, computer, network or internetwork).
Victim
Victim is individual or organisation which suffered the incident which is described in incident report.
For the purpose of IODEF victim is described by its network ID, organisation
and location information.
4. Vulnerability
A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy.
Most systems have vulnerabilities of some sort, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds.
Success depends on the degree of vulnerability, the strength of attacks,
and the effectiveness of any countermeasures in use. If the attacks needed
to exploit a vulnerability are very difficult to carry out, then the vulnerability
may be tolerable. If the perceived benefit to an attacker is small, then
even an easily exploited vulnerability may be tolerable. However, if the
attacks are well understood and easily made, and if the vulnerable system
is employed by a wide range of users, then it is likely that there will
be enough benefit for someone to make an attack.
4. Damage vs Impact
Damage
An intended or unintended consequence of an attack which affects the normal operation of the targeted system or service.
In IODEF the description of damage may include free text description of actual result of attack, and, where possible, structured information about the particular damaged system, subsystem or service.
Impact
Impact describes result of incident expressed in terms of user community,
for example the cost in terms of financial or other disruption
5. Evidence
Evidence is information relating to an event that proves or supports a conclusion about fact of it has occurred, i.e. evidence could be information relating to a security incident, as a computer intrusions, that proves or supports a conclusion about fact of malicious use or attack.
It may include but is not limited to: data dump created by Intrusion Detection System (IDS), data from syslog file, kernel statistics, cache, memory, temporary file system, or other data that caused the alert or were collected after the incident happened.
Special rules and care must be taken when collecting and archiving evidence, particularly to preserve its integrity. When necessary evidence should be stored encrypted.
According to Guidelines for Evidence Collection and Archiving (Evidence)
evidence must be strictly secured. The chain of evidence custody needs
to be clearly documented.
6. Event vs Incident
Event
An action directed at a target which is intended to result in a change of state (status) of the arget" [(IEEE96:373) Sandia]. This could be any observable occurrence in a system or network.
Incident
The definition of an incident varies between professions, organisations and people. In order to make use of a common and sound vocabulary regarding incident handling within the IT area the following definitions are used.
Incident is a root/key element of the discussed IODEF. Incident object
data model is described by separate document.
7. Detailed Examination Of Incident
The use of the same granularity and preciseness in terms gives us:
8. Incident
An incident is an event that might lead to an accident or an accident which is not to serious.
This matches well both Oxford and Longman dictionaries, which have these definitions
"something unusual, serious, or violent that happens" [Longman] or "an event or occurrence, especially a minor one" [Oxford]. An incident may be escalated (reassessed) if it has a more serious impact, i.e. it may be escalated to a security incident, crisis or a catastrophe.
In the IT area, an incident may be availability problems in a network,
a zone transfer or computer virus on a single workstation. Normally, we
have established units handling incidents daily. These units are a part
of the permanent organisation, i.e. help-desk or support units. They are
trained to handle incidents and this has become a normal issue in their
working day.
9. Security Incident
A security incident is an event that involves a security violation. This may be an event that breaks a security policy, UAP, laws and jurisdictions, etc.
A security incident is worse than an incident as it affects the security of or in the organisation. A security incident may be logical, physical or organisational, for example a computer intrusion, loss of secrecy, information theft, fire or an alarm that doesn't work properly. A security incident may be caused on purpose or not. The latter may be if somebody forgets to lock a door or forgets to activate an access list in a router.
This can be narrowed to cover only the IT sector, i.e. security incidents
that happens in the IT sphere is called IT-security incidents.
10. Security Incident - Other definitions:
A security incident is an event that involves a security violation. This may be an event that violates a security policy, UAP, laws and jurisdictions, etc. A security incident may also be an incident, which has been escalated to a security incident.
A security incident is worse than an incident as it affects the security
of or in the organisation. A security incident may be logical, physical
or
organisational, for example a computer intrusion, loss of secrecy,
information theft, fire or an alarm that doesn't work properly. A security
incident may be caused on purpose or not. The latter may be if somebody
forgets to lock a door or forgets to activate an access list in a router.
Existing definitions:
11. IT Security Incident
The Handbook for Computer Security Incident Response Teams (CSIRTs) defines an IT security incident as "any real or suspected adverse event in relation to the security of computer or computer networks. Examples of such are: intrusion of computer systems via the network, occurrence of computer viruses or probes for vulnerabilities via the network to a range of computer systems" [Howard et al].
Typical security incidents are, within the IT area, a computer intrusion,
a denial-of-service attack, information theft or data manipulation, etc
. This recommendation is proposed by the Internet Security Glossary [RFC
2828] which also recommend not to use the definition proposed in [RFC 2350]
which declares a computer security incident as "any adverse event which
compromises some aspect of computer or network security."
12. Basics definitions from Sandia Report
"A Common Language for Computer Security Incidents" by John D. Howard amd Thomas A. Longstaff [Sandia]
Howard's events
Howard's attacks
Howard's scheme
13. Example: IT Security Incidents
The definition of an incident varies between professions, organisations and people. In order to make use of a common and sound vocabulary regarding incident handling within the IT area the following definitions are used.
Note that the overall and general term incident is used by IODEF, instead of the more precise IT security incident. This choice of terms depends heavily on the fact that far from all organisations have stated an incident handling policy, in which incident taxonomy is described or referred.
By using the broader term INCIDENT, IODEF does not discriminate or disregard organisations that do not make use of the difference in taxonomy discussed below. Although it is most likely that CSIRTs focussing in handling IT security incidents only, e.g. a reported scan may be referred by the victim as a security incident while the CSIRT define it as an incident.
Incident is a root/key element of the discussed IODEF. Incident object
data model is described by separate document. According to this the terms
security incidents, computer security incident and IT security incident
will not be used in this document.
Table 1. Definition of Computer Security Incident related terminology
with references
| TERM | DEFINITION |
| Attack | "a series of steps taken by an attacker to achieve
an unauthorized result" [Sandia]
"to act violently against" - "to act harmfully on" [Oxford] " An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system. (See: penetration, violation, vulnerability.)" [RFC2828] |
| Attacker | "an individual who attemtps one or more attacks in order to achieve an objective" [Sandia] |
| Catastrophe | "a terrible event that causes a lot of destruction
or suffering" [Longman]
"a great and ususally sudden disaster [Oxford] |
| Constituency | "Implicit in the purpose of a Computer Security
Incident Response Team is the existence of a constituency. This is the
group of users, sites, networks or organizations served by the team. The
team must be recognized by its constituency in order to be effective."
[RFC 2350]
"body of voters who elect a representative; an area so represented" [Oxford] |
| Crisis | "a time when a problem or situation is very
bad or dangerous" [Longman]
"a decisive moment; a time of danger or great difficulty" [Oxford] |
| Damage | "something done or suffered that reduces the value or usefulness of the thing affected or spoils its appearance" [Oxford] |
| Evidence | "an indication, a sign, the facts available
as proving or supporting a notion" [Oxford]
"information given personally or drawn from a document etc. and tending to give a fact; testimony; admissible in court" [Oxford] |
| Event | "An action directed at a target which is intended
to result in a change of state (status) of the target" [(IEEE96:373) Sandia]
Any observable occurrence in a system or network [FedCIRC] "a thing that happens or takes place, especially one of importance" [Oxford] |
| History (of incident handling) | |
| Incident | "something unusual, serious, or violent that
happens" [Longman]
"an event or occurrence, especially a minor one" [Oxford] "a group of attacks that can be distinguished from other attacks because of the distinctiveness of the attackers, attacks, objectives, sites and timing" [Sandia] |
| IO data signature | |
| IO data digest /hash | |
| IT security incident | "Any real or suspected adverse
event in relation to the security of computer or computer networks. Examples
of such are:
|
| Security Event | " A occurrence in a system that is relevant to the security of the system. (See: security incident.)" [RFC2828] |
| Security incident | Any adverse event whereby some aspect of computer
security could be threatened: loss of data confidentiality, disruption
of data or system integrity, or disruption or denial of availability [NIST-800-3]
Proposition made by Internet Security Glossary [RFC 2828]: (I) A security event that involves a security violation. (See: CERT, GRIP, security event, security intrusion, security violation.) (C) In other words, a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. (O) "Any adverse event which compromises some aspect of computer or network security." [RFC2350] (D) ISDs SHOULD NOT use this "O" definition because (a) a security incident may occur without actually being harmful (i.e., adverse) and (b) this Glossary defines "compromise" more narrowly in relation to unauthorized access. I = recommended
|
| Target | "a computer or network logical entity (account,
process or data) or physical entity (component, computer, network or internetwork"
[Sandia]
"an objective, a minimum result aimed at .." [Oxford] |
| Victim | "a person who is injured or killed by another or as a result of an event or circumstance" [Oxford] |
| Vulnerability | "a weakness in a system allowing unauthorized
action [(NRC91:301; Amo94:2) Sandia]
A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy." [RC2828] "A 'vulnerability' is a characteristic of a piece of technology which
can be exploited to perpetrate a security incident. For example, if a program
unintentionally allowed ordinary users to execute arbitrary operating system
commands in privileged mode, this "feature" would be a vulnerability."
[RFC2350]
|
References:
| Sandia | "A Common Language for Computer Security Incidents"; John D. Howard amd Thomas A. Longstaff; Sandia National Laboratories [Sandia Report: SAND98-8667] |
| FedCIRC | Federal Incident Response Capability; (URL: http://www.fedcirc.llnl.gov) 2000-05-20 |
| NIST800-3 | Establishing a Computer Security Incident Response Capability (CSIRC); NIST, November 1991 |
| Oxford | "The Oxford Reference Dictionary"; Oxford University Press, 1986 |
| RFC2350 | Best Current Practice; Expectations for Computer Security Incident Response; N. Brownlee, The University of Auckland, E. Guttman, Sun Microsystems, June 1998 |
| CMU/SEI-98-HB-001 | Handbook for Computer Security Incident Response Teams (CSIRTs); Moira J West-Brown, Dan Stikvoort, Klaus-Peter Kossakowski; Carnegie Mellons, Software Engineering Institute, 1998 |
| RFC2828 | Internet Security Glossary by R. Shirey. May 2000. |
| IDMEF-Req | Intrusion Detection Exchange Format Requirements by Wood, M. - December 2000. - http://www.eetf.org/internet-drafts/draft-ietf-i.nl/tech/projects/cert/i-taxonomy/archive/draft-ietf-idwg-requirements-02.txt |
| IDMEF-DTD | Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition by D. Curry - March 2000 - http://www.terena.nl/tech/projects/cert/i-taxonomy/archive/draft-ietf-idwg-idmef-xml-03.txt |
| EVIDENCE | Guidelines for Evidence Collection and Archiving by Dominique Brezinski, Tom Killalea - July 2000. - http://www.terena.nl/tech/projects/cert/i-taxonomy/archive/draft-ietf-grip-prot-evidence-01.txt |