Existing taxonomies

Published under Community Projects

Generally speaking, existing incident taxonomies belong to either of the following groups:

  • specific taxonomies developed by individual CERTs
  • universal, internationally recognised taxonomies.

As examples of the first group, consider the taxonomies used by two European CERTs.

The first is the taxonomy developed by the LatvianCERT NIC.LV  team. It consists of eleven types of internet security attacks:

  • attacks on the critical infrastructure
  • attacks on the internet infrastructure, eg, root or system-level attacks on any server system, or any part of the backbone network infrastructure, denial of service attacks
  • deliberate persistent attacks on specific resources, ie, any compromise which leads or may lead to unauthorised access to systems
  • widespread automated attacks against internet sites, eg, sniffing attacks, IRC ‘social engineering’ attacks, password cracking attacks
  • threats, harassment, and other criminal offences involving individual user accounts
  • new types of attacks or new vulnerabilities
  • botnets, ie, activities related to the network of compromised systems controlled by a party which is the source of an incident
  • denial of service on individual user accounts, eg, mail bombing
  • forgery and misrepresentation, and other security-related violations of local rules and regulations, eg, e-mail forgery, SPAM, etc
  • compromise of single desktop systems
  • copyright violations.

This kind of taxonomy was probably established according to the team’s experiences. In general, it corresponds to what a team receives as incident reports.

The next taxonomy is different. It is short and is based on completely different factors. This time you see a taxonomy which corresponds to who reported an incident. It is used by CERT-Hungary team and it consists of only four categories:

  • national CIIP
  • CIIP of partners with SLA
  • incidents reported by international partners
  • threats and incidents reported by cooperating organisations.

If you look further into proprietary taxonomies, you will find more variations. Their value is that they maximise the correlation with a team’s needs and expectations, but they are not universal or directly comparable with other taxonomies. This means they can be used for your own internal requirements but comparison with other similar teams will be almost impossible.

To be able to compare, you should at least try to use one of the open models used by more than one team. One in particular is worth considering. Before that is presented, first a glance at one of the oldest schemas, which was developed at the Sandia National Laboratories and is called ‘the Common Language’.

In this taxonomy, there are three main terms:

  • event
  • attack
  • incident.

 Common Language security incident taxonomy

Figure 11 - Common Language security incident taxonomy

An event is when you have available information about a target of the attack and an action undertaken against it. When you have more information about it – a tool which was used in the attack, a vulnerability attacked and a result of the attack – then you can say that you have full information about the attack. According to this taxonomy you have an incident only if you collect all possible information so, besides the information about the attack, you should know who was the source of the incident and what was the objective of this attack.

As you can see this taxonomy is quite extensive. You have to makes decisions about seven different factors to be able to say that you have identified and classified your incident. It is complete. It gives you a chance to classify every incident in a very detailed way, but at the same time it is very time consuming and very often ambiguous. What is more – in most cases you do not have a chance to make use of this fully-detailed description, because you are not able to collect all the information needed. It is worth using, however, for research purposes, theoretical considerations and for creating your own taxonomy.

The second taxonomy that is worth knowing is the taxonomy popularised within the European CSIRT Network project –eCSIRT.net. The taxonomy used in this project is essentially based on the taxonomy of a Swedish CERT team – TS-CERT (TS-CERT was known as Telia CERT/CC in the days when this taxonomy was developed by their team member Jimmy Arvidsson). The table below presents the full classification schema of this taxonomy. It has eight main categories and twenty-five sub-categories.

Incident Class
(mandatory input field)
Incident Type
(optional but desired input field)
Description / Examples
Abusive Content Spam Or ‘unsolicited bulk e-mail’, meaning that the recipient has not granted verifiable permission for the message to be sent and that the message is sent as part of a larger collection of messages, all having identical content
Harmful Speech Discreditation or discrimination of somebody (e.g. cyber stalking, racism and threats against one or more individuals)
Child/sexual/violence/... Child pornography, glorification of violence, ...
Malicious Code Virus Software that is intentionally included or inserted in a system for a harmful purpose. A user interaction is normally necessary to activate the code.
Information Gathering Scanning Attacks that send requests to a system to discover weak points. This also includes some kinds of testing processes to gather information about hosts, services and accounts. Examples: fingerd, DNS querying, ICMP, SMTP (EXPN, RCPT, …).
Sniffing Observing and recording network traffic (wiretapping)
Social engineering Gathering information from a human being in a non-technical way (eg, lies, tricks, bribes, or threats)
Intrusion Attempts Exploiting known vulnerabilities An attempt to compromise a system or to disrupt any service by exploiting vulnerabilities with a standardised identifier such as CVE name (eg, buffer overflow, backdoors, cross side scripting, etc).
Login attempts Multiple login attempts (guessing / cracking of passwords, brute force)
New attack signature An attempt using an unknown exploit
Intrusions Privileged account compromise A successful compromise of a system or application (service). This can have been caused remotely by a known or new vulnerability, but also by an unauthorized local access. Also includes being part of a botnet.
Unprivileged account compromise
Application compromise
Availability DoS

By this kind of an attack a system is bombarded with so many packets that the operations are delayed or the system crashes. DoS examples are ICMP and SYN floods, Teardrop attacks and mail-bombing. DDoS often is based on DoS attacks originating from botnets, but also other scenarios exist like DNS Amplification attacks.

However, the availability also can be affected by local actions (destruction, disruption of power supply,etc.) or by Act of God, spontaneous failures or human error, without malice or gross neglect being involved.

Outage (no malice)
Information Content Security Unauthorised access to information Besides local abuse of data and systems, the security of information can be endangered by successful compromise of an account or application. In addition, attacks that intercept and access information during transmission (wiretapping, spoofing or hijacking) are possible.  Human/configuration/software error can also be the cause.
Unauthorised modification of information
Fraud Unauthorized use of resources Using resources for unauthorized purposes including profit-making ventures (eg, the use of e-mail to participate in illegal profit chain letters or pyramid schemes)
Copyright Selling or installing copies of unlicensed commercial software or other copyright protected materials (Warez)
Masquerade Types of attacks in which one entity illegitimately assumes the identity of another in order to benefit from it
Phishing Masquerading as another entity in order to persuade the user to reveal a private credential.


Open for abuse
Open resolvers, world readable printers, vulnerability apparent from Nessus etc scans, virus, signatures not up to date, etc.


All incidents which do not fit in one of the given categories should be put into this class. If the number of incidents in this category increases, it is an indicator that the classification scheme must be revised.
Test Meant for testing Meant for testing.

Table 12 - eCSIRT.net security incidents taxonomy

This taxonomy is not ideal but it has many factors which make it very useful. In particular the main categories seem to be very practical and universal. Even though the taxonomy was developed many years ago, the main categories are still current and you can easily use them today. The subcategories are not so current and can lead to problems with how to classify an incident. It is not particularly useful any more to make a distinction between DoS attacks and DDoS attacks or to determine what is a ’privileged account compromise’, ’unprivileged account compromise’ or ’application compromise’. In practice, subcategories became a part of the description rather than a concrete schema for classification. Nowadays it is really difficult to determine if a particular malware is a virus, worm, Trojan, spyware or a dialler. The functionality of malware changes and the honest approach is to classify it all as ‘malicious code’.

The eCSIRT.net classification is highly recommended. Despite some defects, it is still quite useful and good. Many European CERTs use it. If you decide to use it, it will give you the opportunity to team up with others later and be able to compare and merge statistics.

We use cookies to ensure we give you the best browsing experience on our website. Find out more on how we use cookies and how you can change your settings.

Ok, I understand No, tell me more