Classification of events for IDEA in the “Category” key is based on abbreviation of slightly extended “mkII” taxonomy (by Don Stikvoort from SURFcert, itself based on eCSIRT.net taxonomy, and formerly Jimmi Arvidsson's taxonomy from Telia CERTCC). For comparison with other taxonomies see Incident classification comparison.ods and for discussion of changes see Incident classification analysis.pdf.
For classification of the security event, list of category names is used. All applicable category names must be used (for example, phishing, detected from spam message, must be marked as both “Abusive.Spam” and “Fraud.Phishing”. If unsure of more precise nature of the incident, only top level category name (omitting dot and subcategory) can be used.
Creator of the IDEA message should do the best to describe security event by existing category names, however completely new category/subcategory name may be used if none existing applicable - this should however happen only in the case completely new security event type or modus operandi turns up in the wild. In case event is generated by machine and no human can assess new category, “Other” category can be used.
In absolute necessity of the new name, camel case must be used, abbreviation should be used only where widely accepted instead of full name (“DDoS”) or where category based on full name would get unfittingly long (“Recon”). Digits, underscore and minus sign are reserved for possibility of new widespread names containing some kind of divider and should not be used.
| Category | Subcategory | Description |
|---|---|---|
| Abusive | Spam | Unsolicited Bulk Email, this means 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 a functionally comparable content. |
| Harassment | Discreditation or discrimination of somebody (e.g. cyberstalking, racism and threats against one or more individuals) | |
| Child | Child pornography | |
| Sexual | ||
| Violence | Glorification of violence | |
| Malware | Virus | Software that is intentionally included or inserted in a system for harmful purpose. A user interaction is normally necessary to activate the code. |
| Worm | ||
| Trojan | ||
| Spyware | ||
| Dialer | ||
| Rootkit | ||
| Recon | Scanning | Attacks that send requests to a system to discover weak points. This includes also some kind of testing processes to gather information about hosts, services and accounts. Examples: fingerd, DNS querying, ICMP, SMTP (EXPN, RCPT, …), port scanning and host sweeping. |
| Sniffing | Observing and recording of network traffic (wiretapping). | |
| SocialEngineering | Gathering information from a human being in a non-technical way (e.g. lieas, tricks, bribes or threats). | |
| Searching | Google hacking or suspicious searches against site. | |
| Attempt | Exploit | An attempt to compromise a system or to disrupt any service by exploiting vulnerabilities with a standardised identifier such as CVE name (e.g. buffer overflow, backdoors, cross site scripting, etc.). |
| Login | Multiple login attempts (guessing/cracking of passwords, brute force). | |
| NewSignature | An attempt using and unknown exploit. | |
| Intrusion | AdminCompromise | A successful compromise of a system or application (service). This can have been caused remote by a known or new vulnerability, but also by an unauthorized local access. Also includes being part of a botnet. |
| UserCompromise | ||
| AppCompromise | ||
| Botnet | ||
| Availability | DoS | System bombarded with so many requests (packets, connections) 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. |
| DDoS | ||
| Sabotage | Outage, caused by local actions (destruction, disruption of power supply, etc.) - willfully or caused by deliberate gross neglect. | |
| Outage | Outage, caused by Act of God, spontaneous failures or human error, without malice or deliberate gross neglect being involved. | |
| Information | UnauthorizedAccess | Besides a local abuse of data and systems the information security can be endangered by a successful account or application compromise. Furthermore attacks are possible that intercept and access information during transmission (wiretapping, spoofing or hijacking). Human configuration/software error can also be the cause. |
| UnauthorizedModification | ||
| Fraud | UnauthorizedUsage | Using resources for unauthorized purposes including profit-making ventures (E.g. the use of e-mail to participate in illegal profit chain letters or pyramid schemes). |
| Copyright | Offering or installing copies of unlicensed commercial software or other copyright protected materials (Warez). | |
| Masquerade | Type 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. | |
| Scam | Fraud on a person by falsely gaining confidence. Prominent example is Nigerian 419 scam. | |
| Vulnerable | Open | Open for abuse, solvable preferably by patch, update, etc. - vulnerabilities apparent from Nessus and similar scans |
| Config | Open for abuse, solvable preferably by configuration hardening/fixing - open resolvers, world readable printers, virus signatures not up-to-date, etc. | |
| Anomaly | Traffic | Anomalies not yet identified as clear security problem. |
| Connection | ||
| Protocol | ||
| System | ||
| Application | ||
| Behaviour | ||
| Other | Yet unknown/unidentified type of attack, or attack unrecognized automatically by machine. | |
| Test | Meant for testing. |
Protocols classification in “Source/Proto” or “Target/Proto” list contains all applicable service names and transport protocol names as defined by IANA Service Name and Transport Protocol Port Number Registry (introduced in RFC6335). If protocols are stacked, they must be ordered from the lowest (the closest to the medium) to the highest (the closest to the application) according to the ISO/OSI model.
“Source/Type” or “Target/Type” contains additional keywords to better describe sense of source/target. Use every keyword that applies, but just those that apply to this particular source/target. Some sources/targets do not qualify for any of keywords, but these should be the ones, whose meaning is obvious from event incident type.
Completely new tag name may be used if none existing applicable and the meaning is not obvious from event incident type - this should however happen only in the case completely new security event type or modus operandi turns up in the wild.
In absolute necessity of the new name, camel case must be used, abbreviation should be used only where widely accepted instead of full name (“CC”) or where category based on full name would get unfittingly long (“MITM”). Digits, underscore and minus sign are reserved for possibility of new widespread names containing some kind of divider and should not be used.
Describes service providing indirect access to other services. May denote HTTP proxies, SOCKS proxies and others. Not necesarilly malicious - but since discovered during or as means of security event, worth inspecting.
Information (usually hostname or URL) was discovered by static analysis of malware binary. Not necesarilly malicious, may have been inserted as a decoy - but worth inspecting.
Information (usually hostname or URL) was discovered by sandbox or live-mode analysis of malware binary. Not necesarilly malicious, may have been inserted as a decoy - but worth inspecting.
Information (usually hostname or URL) was extracted from spam message/data. Not necesarilly malicious, may have been inserted as a decoy - but worth inspecting.
Host of the phishing text. Usually a web page over HTTP, however not necessarily.
Host of the malicious code. Usually a web page, however not necessarily – another example is FTP, or even raw TCP socket.
Host, conducting man-in-the-middle attack.
Origin of the spam (be it common spam, phishing or fraud message). May apply to SMTP MTAs, but also to web sites (for example comment spam), instant messaging gateways and others.
Reflector of the attack/event. May be used for SMTP protocol in case of spam bounce, or for DNS/SNMP/NTP and others in case of reflection or amplification attacks.
Host's service access is unlimited. May apply to SMTP MTAs (“open relays”), web proxies, open resolvers and others.
Host's service provides data, manipulated by attacker. Usually applies to services, which provide name translation or redirection data, namely DNS.
Host's service provides rapidly changing data (to evade investigators). Usually applies to services, which provide name translation or redirection data, namely DNS.
Machine/service is part of the botnet, i. e. runs cooperating and/or remotely controlled malware.
This part of the botnet is the command-and-control server.
NOT:
Various sources and types of security events spring up every now and then, and no human is able to know the types, names and functionality of majority of them. “Node/Type” keywords serve as characterization of detector for the responders of alert, and also means to filter out events by type of source (use only messages generated by honeypots, for example).
Detector administrator should put in all the tags that fit the nature of the probe best, based on detection medium, data source, methodology and possibly some of specific well known types. More tags of one category can be used.
Completely new tag name may be used if none existing applicable or do not explain the function of the node reasonably - this should however happen only in the case completely new class of security event detectors arises.
In absolute necessity of the new name, camel case must be used, abbreviation should be used only where widely accepted instead of full name or where category based on full name would get unfittingly long (“Recon”). Digits, underscore and minus sign are reserved for possibility of new widespread names containing some kind of divider and should not be used.
Describes origin of the data. Use one or more categories, which describe major means of data gathering, or, in case of external, correlation or reported sources, also their means.
analysis of connections to particular host (LaBrea, iptables logs, …)
packet header analysis (iptables, …)
stateful datagram content and/or application protocol based analysis (Snort, Suricata, …)
analysis of local application data (SpamAssassin, antivirus under MTA, …)
file or host filesystem based analysis (Aide, Tripwire, antivirus, antimalware, …)
netflow based analysis (FTAS, FlowMon, …)
system log based (Logcheck, SSHGuard, Prelude with LML, also other analyzers of application protocols…)
analysis of application protocol violation (Dionaea, Hihat, Policyd, Asterisk, greylisting, nolisting…)
watching/analysis of machine state change (Nagios, SNMP watchguards, …)
watching/analysis of general network state change (Nagios, SNMP watchguards, HP OpenView, …)
engines, correlating various data, or data from various sources (Prelude, ACARM-ng, …), additional tags describing the correlated sources should be also used
external source, on which creator of the message has no control, additional tags describing character of the source should be also used
manual incident reporting, human detected events, additional tags describing the source should be also used
hub, transfer node, transit point, queue manager, generally any intermediary node
detection of attempts to authentication violation (Fail2Ban, dictionary attacks)
Describes the technique used to discover security events from the medium.
detectors based on redirection, triggered by known aspect of malicious traffic (for example sinkhole DNS servers, diverting traffic based on knowledge of botnet name generation)
signature based ids' (SpamAssassin, Vipul's Razor, Snort, antivirus, …)
statistical anomaly analysis (SpamAssassin, SSHGuard, usually netflow based detectors)
heuristical, approximative methods or combination of various methods (described by additional tags)
file or system integrity checker (Samhain, Tripwire, Aide, …)
detection of protocol/data policy violations (Ossec, greylisting, nolisting, Postfix SMTP rules itself, …)
detection traps (Kippo, Dionaea, Hihat, Asterisk based honeypots, …)
services or honeypots intentionally holding and delaying incoming connections (LaBrea, greylisting, Stockade, …)
reconnaissance and vulnerability scanning (Nmap, OpenVAS…)
monitoring of production machines/services/applications (Nagios, SNMP monitors, HP OpenView, …)
“Attach/Type” contains more specific desription of the attachment content in addition to the ContentType field.
In necessity of the new name, camel case must be used, abbreviation should be used only where widely accepted instead of full name (“CC”) or where category based on full name would get unfittingly long (“MITM”). Digits, underscore and minus sign are reserved for possibility of new widespread names containing some kind of divider and should not be used.
Windows event log data.
Unix style textual log data.
Binary, script, document or data contain malicious software.
Binary, script, document or data containing exploit payload sample (as a common name, it may also include payloads which try to achieve different aims, such as one shot downloading of another part of exploit/malware).
Script or binary used to exploit vulnerability or drive the attack.