ETSI GS ISI 004 V1.1.1 (2013-12)

Information Security Indicators (ISI); Guidelines for event detection implementation

DGS/ISI-004

General Information

• Status: Published
• Publication Date: 22-Dec-2013
• Technical Committee: ISI - Information Security Indicators
• Current Stage: 12 - Completion
• Due Date: 16-Jan-2014
• Completion Date: 23-Dec-2013

Standards Content (Sample)

Group Specification
Information Security Indicators (ISI);
Guidelines for event detection implementation
Disclaimer
This document has been produced and approved by the Information Security Indicators (ISI) ETSI Industry Specification Group
(ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS ISI 004 V1.1.1 (2013-12)

Reference
DGS/ISI-004
Keywords
ICT, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS ISI 004 V1.1.1 (2013-12)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 11
4 From basic events and traces to security incidents . 12
5 Positioning the various elements against the MITRE CybOX and STIX reference frameworks . 13
6 List of symptoms/artifacts and methods of detection . 15
6.1 Symptoms/artifacts/hints . 15
6.2 Which relevant categories for each incident field (regarding its characteristics) . 17
6.2.1 Symptoms linked to the incident origin . 17
6.2.2 Symptoms linked to actions . 18
6.2.3 Symptoms linked to techniques used . 18
6.2.4 Symptoms linked to vulnerability exploited . 18
6.2.5 Symptoms linked to the incident status. 18
6.2.6 Symptoms linked to assets and CIA consequences . 18
6.2.7 Symptoms linked to business consequences . 18
6.2.8 Summary . 18
6.3 Which relevant categories for each step of the 5-step attack stream . 19
6.4 Which methods of detection and tools should be used . 20
6.5 The key role of seasoned experts in detection . 21
6.6 The key role of threat intelligence and associated process . 21
7 Examples to illustrate the previous concepts. 22
7.1 Internet-facing Web application intrusion . 22
7.2 Advanced Persistent Threat (APT) . 23
Annex A (informative): Authors & contributors . 27
Annex B (informative): Bibliography . 28
History . 30

ETSI
4 ETSI GS ISI 004 V1.1.1 (2013-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Information Security
Indicators (ISI).
The present document is included in a series of 6 ISI multi-part specifications. These 6 specifications are the following
(see figure 1 summarizing the various concepts involved in event detection and interactions between all specifications):
• GS ISI 001-1 addressing (together with its companion guide GS ISI 001-2) information security indicators,
meant to measure application and effectiveness of preventative measures,
• GS ISI 002 addressing the underlying event classification model and the associated taxonomy,
• GS ISI 003 addressing the key issue of assessing organisation's maturity level regarding overall event
detection (technology/process/people) and to weigh event detection results,
• GS ISI 004 addressing demonstration through examples how to produce indicators and how to detect the
related events with various means and methods (with a classification of the main categories of use
cases/symptoms),
• GS ISI 005 addressing ways to produce security events and to test the effectiveness of existing detection
means within organization (for major types of events), which is a more detailed and a more case by case
approach than ISI 003 one and which can therefore complement it.
GS ISG ISI Series Summary Definition
Event
reaction
measures
Fake events
(Simulation)
Security
Event
Real Detected
prevention
detection
events events
measures measures
Residual risk
(event model-
centric vision)
Figure 1: Positioning the 6 GS ISI multi-parts against the 3 main security measures
ETSI
5 ETSI GS ISI 004 V1.1.1 (2013-12)
Introduction
The purpose of the present document, which is the engineering part of the ISG ISI 5-part series, is to:
• present a comprehensive classification of the main symptoms/use cases (in some cases also referred to as
indicators of compromise) to look for in IT system traces in order to detect stealthy events (as listed in
GS ISI 002 [i.3]);
• position all these elements of information within a consistent framework (MITRE CybOX standard) in order to
ease their exchange between various security stakeholders (such as CSIRTs, SOCs, administrators, etc.);
• give some examples of frequent security events in order to illustrate powerful means and methods of detection.
The present document addresses only events detected through technical means, and only security incidents and
behavioural vulnerabilities, excluding all other kinds of vulnerabilities (software, configuration and general security),
since these latter are far simpler to detect with well-identified and well-established methods and tools. And regarding
security incidents, focus is stressed mainly on attacks of a malicious nature.
ETSI
6 ETSI GS ISI 004 V1.1.1 (2013-12)
1 Scope
The scope of the present document is to define and describe a classification of the main symptoms/use cases, which are
used to detect security events listed in GS ISI 002 [i.3].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
[1] ISO/IEC 27002:2013: "Information technology -- Security techniques -- Code of practice for
information security controls".
[2] NIST SP 800-126 Revision 2 (September 2011): "The Technical Specification for the Security
Content Automation Protocol (SCAP Version 1.2)".
2.2 Informative references
[i.1] ETSI GS ISI 001-1: "Information Security Indicators (ISI); Indicators (INC); Part 1: A full set of
operational indicators for organizations to use to benchmark their security posture".
[i.2] ETSI GS ISI 001-2: "Information Security Indicators (ISI); Indicators (INC); Part 2: Guide to
select operational indicators based on the full set given in part 1".
[i.3] ETSI GS ISI 002: "Information Security Indicators (ISI); Event Model: A security event
classification model and taxonomy".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
NOTE: See also the summary chart at the end of this list.
asset: entity (information or physical component) that has value to the organization and that can be broken down in
primary assets (such as business activities, data, application software, etc. which hold the business value) and
secondary/supporting assets (network or system infrastructure, which host primary assets)
assurance: planned and systematic activities implemented in a management system so that management requirements
for a service will be fulfilled
NOTE: It is the systematic measurement, comparison with a standard, monitoring of processes and an associated
feedback loop that confers error prevention. This can be contrasted with Management "Control", which is
focused on process outputs.
ETSI
7 ETSI GS ISI 004 V1.1.1 (2013-12)
base measure: regarding the "indicator" definition, defined in terms of an attribute and the specified measurement
mean for quantifying it (e.g. number of trained personnel, number of sites, cumulative cost to date)
NOTE: As data is collected, a value is assigned to a base measure.
continuous auditing: periodic verification and collection of a series of controls identified within the Information
System, corresponding to the detection of incidents and of software, configuration, behavioural or global security
framework vulnerabilities and/or non-conformities
NOTE: There are three auditing levels (in principle, hierarchy notably implemented within banking and financial
institutions):
Detailed behavioural, global security framework or technical checking at the security software or
equipment level (network, system, application software).
Level 1 auditing via monitoring of trends and deviations of a series of significant measurement
points.
Level 2 auditing (verification of existence of an appropriate level of assurance and technical
coverage of the chosen control and measurement points, and of implementation of regulatory
requirements).
Continuous auditing can be either manual or automatic (for example, monitoring by means of tools
appropriate for a SIEM approach). Finally, continuous auditing is generally associated with statistical
indicators (levels of application and effectiveness of security controls), that provide information
regarding the coverage and assurance level of the security controls in question.
criticality level (of a security event): level defined according to the criteria which measures its potential impact
(financial or legal) on the company assets and information, and which make it possible to evaluate the appropriate level
of reaction to the event (incident treatment or vulnerability or nonconformity removal)
NOTE: The criticality level of a given event is determined by the combination of its severity level (inherent to the
event itself - see definition below) and of the sensitiveness of the target attacked or concerned (linked to
the asset estimated value for the company - whose value concerns confidentiality, integrity or
availability). This concept of criticality level (usually defined on a scale of four levels) is at the core of
any SIEM approach, for which classifying security events processing according to organization-defined
priorities is vital from both a security and economic point of view.
derived measure: regarding the "indicator" definition, measure that is derived as a function of two or more base
measures
effectiveness (of security policy or of ISMS): As a supplement to the actual application of security policy (or of
ISMS) and of its measures assessment, it is necessary to assess its level of effectiveness, that can be estimated through
identified residual risk (that corresponds with the residual vulnerabilities that are actually exploited and that have led to
security incidents).
NOTE: It should be added that the term "efficiency" is sometimes also used, but generally with a different
meaning of economy in the use of resources (not addressed here for reasons of lesser relevancy).
(security) incident: single unwanted or unexpected security event, or series thereof, that correspond to the exploitation
of an existing vulnerability (or attempt to), and with an actual or potential threat (attempt underway), that have a
significant probability of compromising business operations and threatening information security
NOTE: In case of success, an incident affects nominal operations of all or part of an information system
(according to the Confidentiality, Integrity and Availability criteria - English acronym CIA). An incident
that manifests itself through previously unseen phenomena, or is built as a complex combination of
elementary incidents often cannot be qualified and therefore inventoried or categorized easily; such an
incident will often be referred to as an anomaly.
indicator: measure that provides an estimate or evaluation of specified attributes derived from an analytical model with
respect to a defined information need
NOTE: Indicators are the basis for analysis and decision making.
ETSI
8 ETSI GS ISI 004 V1.1.1 (2013-12)
log: continuous recording of computer usage data, with specific characteristics: detailed and specified structure, time-
stamping, recording as soon as they occurs in files or other media
NOTE: Logs are a kind of trace (more general concept - see definition below).
non-conformity: security event that indicates that organization's required security rules and regulations have not been
properly enforced, and are therefore the consequence of a usage or implementation drift
NOTE: Continuous monitoring of non-conformities (similar to continuous auditing - Cf. this term above) enables
to better ensure that an organization's security policy is being enforced. Non-conformity can be further
refined according to their kind: configuration, behaviour, global security (technical and organizational)
and material. Non-conformities are also vulnerabilities or incidents, depending on the situation (see
definition).
periodic audit (Periodic scanning): using isolated audit means, periodic acquisition and verification of security
controls
NOTE: A periodic audit can also be either manual or automatic (for example, carried out through scanner type
tools). Finally, a periodic audit is generally Boolean (all or nothing compliance level).
risk: product of the probability of occurrence of a security incident involving a specific asset by its impact on this asset
(impact assessed according to the CIA sensitivity level)
NOTE: The level of risk exposure (concept which is used in risk assessment methods) corresponds to the product
of the vulnerability level of the asset in question by the threat level hanging over it.
risk not covered (by existing security measures): Risk sometimes also referred to as "residual", which breaks down
into 3 shares:
• Known and realized suffered risk, corresponding to the impact suffered by the organization under attack when
the security policy is not applied (configuration, behavioural or global security non-conformities), and when
known and critical software vulnerabilities are not appropriately addressed.
• Known and accepted risk that corresponds to a risk taken by choice by an organization, by comparing the risk
associated with attacks with economic, usage and security level considerations.
• Unknown risk associated with unknown and unpatched vulnerabilities, or innovative attack vectors.
security event: information about a change of state in a system that may be security relevant and that indicates the
appearance of a risk for the organization
NOTE: A security event is either an incident or a vulnerability occurrence or detection (see definition of these
terms). 500 security events have been inventoried within the industry, and are grouped into 7 major
categories, with the 3 first corresponding to incidents, and the 4 last to vulnerabilities: external attacks
and intrusions, malfunctions, internal deviant behaviours, behavioural vulnerabilities, software
vulnerabilities, configuration vulnerabilities, general security (technical or organizational) vulnerabilities.
Security Information and Event Management (SIEM) solutions: combination of the formerly separated product
categories of SIM (security information management) and SEM (security event management)
NOTE 1: SEM deals with real-time monitoring, correlation of events, notifications and console views. SIM
provides long-term storage, analysis and reporting of log data.
NOTE 2: The present document extends these two notions under the generic SIEM acronym, which encompasses
all organizational, processes and human aspects necessary to deploy and operate these tools, and which
include vulnerability and nonconformity management; we may refer to Cyber Defence approaches in the
most complex case.
security policy: overall intention and requirements as formally expressed by management
NOTE: Two levels are used: general statements and detailed rules. General statements are consistent with
controls within ISO/IEC 27002 [1] standard. Rules apply to network and systems configuration, user
interaction with systems and applications, and detailed processes and procedures (governance, operational
teams, and audit). Violation of a rule brings about nonconformity, which is either an incident or
vulnerability.
ETSI
9 ETSI GS ISI 004 V1.1.1 (2013-12)
sensitivity level: level which corresponds to the potential impact (financial, legal or brand image) of a security event on
an asset, an impact linked to the estimated value of the asset for the company along four possible viewpoints: its
Confidentiality, Integrity and Availability (CIA) and sometimes its accountability
severity level (of security incident): Level (generally defined on a 4-element scale) inherent to the event itself and that
depends on several criteria that vary according to the types of events (in decreasing order of importance):
• Dangerousness is the result of multiple factors combined together according to circumstances or types of
incidents: propagation speed for a worm, virulence, effectiveness, importance and number of impacted assets,
capability of harm, target reachability, capability of remote action, persistence, weakness or lack of curative
means, and extend of compromise (depth of component which is can be or has been reached, concept of
Defence in Depth or DiD).
• Stealthiness covers the level to which the incident can be hidden to the defender: obvious visibility, visible
through simple and easy to use mechanisms, detection requires advanced technical tools, almost invisibility. It
is a key factor for monitoring and detection. Anonymization and camouflage, or active and passive masking
techniques are stealthiness techniques. Stealthiness takes on an indirect meaning when it applies to similar not
yet detected incidents.
• Feasibility describes the attacker's motivation and skills. It increases proportionally to all the necessary
prerequisites (regarding skills, tools, financial means, collusion, initial access, etc.) combined with the
presence of exploitable vulnerabilities; feasibility can be tied often to the frequency of attacks that can be
detected in the world. Its assessment is not simple, because it is subject to change. For example, it may be
difficult to create a hacking tool for a given vulnerability. However, once the tool is released on the Internet, it
can be used by unskilled attackers. Feasibility takes on an indirect meaning when it applies to a potential threat
(see definition of this term), as the analysis of its factors required to evaluate it provides an interesting
evaluation of the risk.
NOTE: This notion appeared in the mid-1990s within the framework of the ITSEC certification, then towards the
end of this decade with the issue of global and public management of vulnerabilities and "malware"
(security software vendors and CERTs). It is once again being developed at the present time with the
recent release of log analysis and correlation tools that completely integrate this concept along with
criticality.
severity level (of vulnerability or of nonconformity): The severity level definition is about the same as the one for
incidents, with a few small differences:
• Dangerousness: impact of the related attacks, weakness of protective techniques, possible remote exploitation,
scope of the target/victim population (number of machines, of services, etc.), importance to organization of the
security rule that was violated.
• Stealthiness: same definition as for incident.
• Exploitability (by attackers), is the opposite definition of incident feasibility.
NOTE: The proposed definition is aligned with the CVSS (NIST SP 800-126 [2] or SCAP) standard for software
vulnerabilities.
taxonomy: science of identifying and naming species, and arranging them into a classification
NOTE: The field of taxonomy, sometimes referred to as "biological taxonomy", revolves around the description
and use of taxonomic units, known as taxa (singular taxon). A resulting taxonomy is a particular
classification ("the taxonomy of ."), arranged in a hierarchical structure or classification scheme.
threat: potential cause of an unwanted incident, which may result in harm to a system or organization
NOTE: There are 4 categories of threats:
Natural threats:
- Environmental causes: public service outage, fire, and other disasters
- System failure: physical or software computer or network breakdowns
ETSI
10 ETSI GS ISI 004 V1.1.1 (2013-12)
Human threats:
- Unintentional (error, carelessness, irresponsibility, unawareness, etc.): conception and design,
development, operation and usage, due to chance, hasty development and deployment,
tiredness, gullibility, incompetence
- Internal or external malice: theft, economic spying, sabotage, intrusion, fraud, etc.
The frontier between error, carelessness and malice is often fuzzy: it is always possible for an
unscrupulous employee to plead error even though he has been negligent or malicious. However the
difference between unintentional and malicious actions can often be found with the following clues:
An unintentional action is not hidden (so not stealthy), it tends to impact availability rather than
confidentiality and integrity, and it has a low dangerousness and a high feasibility. The resulting
severity is often low to fairly low.
A malicious action is stealthier (notably to enable the attacker to remain anonymous and allow him
to sustain the advantages obtained for a longer period of time), with an impact on confidentiality
and integrity rather than on availability, and with high dangerousness.
trace: computer data that proves the existence of a business operation
NOTE: As an example, logs (see definition above) are traces, but traces are not necessarily logs.
vulnerability: undesirable state of a system whose occurrence or detection is a security event
NOTE: It corresponds to a flaw or weakness of an asset or group of assets (at the level of a technical system,
process or behaviour) that can be exploited by a threat. Occurrence and actual detection of a vulnerability
(often delayed in time) are considered the same in the present document. There are 6 types of
vulnerabilities, but only the first four are in the scope of a SIEM approach and are being dealt with in the
present document:
Behavioural.
Software (that can lead to malicious exploitation by an attacker via an "exploit").
Security equipment or software configuration (same as above).
General security technical or organizational (vulnerabilities defined as having a global and major
effect on Information System's security level, and having a level equivalent to the 133
ISO/IEC 27002 [1] standard control points).
Conception (overall system design at architecture and processes levels).
Material level (corresponding with vulnerabilities which enable physical incidents - of an
accidental, negligent or malicious kind).
A behavioural, configuration, global security (technical and organizational) or material vulnerability
becomes a nonconformity (see definition above) when it violates the organization's security policy and
rules. The present document uses the terms "usage or implementation drift" in this case.
ETSI
11 ETSI GS ISI 004 V1.1.1 (2013-12)
Summary of terms fundamental to
a Cyber Defence or SIEM approach
Events
Security Other
events events
Occurrence or actual
Exploitation or attempts
Vulnera-
detection of potential Security
of exploitation of
sources of security
bilities
incidents vulnerabilities
incidents
Security Security Exploitation of
Known Exploitation of
policy viola- Unknown policy viola- known but
vulnerabilities unknown
tion (noncon- vulnerabilities tion (noncon- accepted
but accepted vulnerabilities
formities) formities) vulnerabilities

Figure 2: Relationships between different kinds of events
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply: ®
AD Active Directory
APT Advanced Persistent Threat
CAG Consensus Audit Guidelines
CAPEC Common Attack Pattern Enumeration and Classification (Mitre)
CCE Common Configuration Enumeration
CEE Common Event Expression
CI Computer Interface
CIA Confidentiality Integrity Availability
CIO Chief Information Officer
CISO Chief Information Security Officer
COA Courses Of Action
CSIRT Computer Security Incident Response Team
CSS Cross-Site Scripting
CVE Common Vulnerabilities and Exposures
CVSS Common Vulnerability Scoring System
CWE Common Weakness Enumeration
CybOX Cyber Observable eXpression
DDoS Distributed Denial of Service
DLP Data Leak Prevention
DNS Domain Name Server
DoS Denial of Service
DPI Deep Packet Inspection
HIDS Host-based Intrusion Detection System
HTTP HyperText Transfer Protocol
IDS Intrusion Detection System
IP Internet Protocol
IPS Intrusion Prevention System
ISM3 Information Security Management Maturity Model
ISMS Information Security Management System
ISO International Organization for Standardization
IT Information Technology
ITIL Information Technology Infrastructure Library
ETSI
12 ETSI GS ISI 004 V1.1.1 (2013-12)
LDAP Lightweight Directory Access Protocol
MAEC Malware Attribute Enumeration and Characterization
NIDS Network Intrusion Detection System
NIST National Institute of Standards and Technology (USA)
NSA National Security Agency (USA)
OS Operating System
PC Personal Computer
SIEM Security Information and Event Management
SOC Security Operation Center
SOC Security Operations Centre
SQL Structured Query Language
STIX Structured Threat Information eXpression
TTP Tactics, Techniques and Procedures
VDS Vulnerability Detection System
VPN Virtual Private Network
WS Workstation
XML Extensible Markup Language
4 From basic events and traces to security incidents
The contribution of a SIEM implementation for detection (notably through implementation of powerful tools) consists
primarily in unearthing previously undiagnosed security events (in particular those which are very stealthy and lead
typically to breach of confidentiality or to a lesser extent to breach of integrity); it also aims at highlighting so-called
"weak signals", events that provide advance notice of security breach attempts (scouting, mapping, connection failures,
etc.), allowing the organization to deal with these events before more serious consequences occur and to demonstrate a
far better reactivity. SIEM implementation for detection is therefore about highlighting potential sequences of events
leading up to a security incident (i.e. with actual impact measured by loss of C, I or A on the targeted or concerned
asset). Note that these events can typically be detected and qualified shortly after they occur (thus meaning that a
potentially new reaction to critical incidents can be quickly triggered by the organization, situation where nothing was
happening previously).
Figure 3 summarizes the evolution over time of an attack or misuse event stream when a security incident occurs
(applicable mostly to malice and carelessness).

vulnerabilities events incidents

vul and flaws system ref. reference symptoms
frameworks
data base frameworks data base
vul detection auditing & IDS, IPS, AV,
detection
users
systems checking SIEM, other
means
attack/misuse
vul and flaws
vulnerability symptom
non-
Meaning: attack attempt security
conformity
impact
or misuse incident
causality
malice or
detection carelessness
scope of
time evolving attack or misuse stream
ISI 004
Figure 3: Positioning of the various elements involved in an attack or misuse
ETSI
13 ETSI GS ISI 004 V1.1.1 (2013-12)
The first priority is of course to spot the most basic vulnerabilities (being exploited in 70 % of all incidents occurring in
real life, as explained in introduction of GS ISI 002 [i.3]), while the remaining security incidents shall be detected by
other means. In the case of these incidents (when they are of a malicious nature), the attack stream in figure 3 can be
refined in the following 5-step process (using or not social engineering):
1) Fingerprinting, exploration, spying and intelligence gathering (lawful and unlawful information collection).
2) Sabotage (to neutralise or weaken security protections).
3) Intrusion (to get illicit access to the target).
4) Installation of malware and other utilities (to maintain a foothold within the target, and possibly exfiltrate
information or launch further actions later).
5) Concealment or camouflage (to conceal attacker's presence, by erasing evidence for example).
Most of the malicious security incidents use only a few steps (typically 1 or 2 steps. Complex ones (such as APTs)
encompass all steps. Annex B/clause 1.3 ("How") of the GS ISI 002 [i.3] Event Classification Model describes for each
kind of incident listed in clause 1.2 ("What") the main methods and means for an attacker or user to achieve the
st
concerned incident. This description is a 1 input to identify a given incident and to figure out ways to detect it. Such a
way for IDS, IPS or Antivirus tools is the definition of a signature of the attacks. But despite huge efforts by tools
vendors, this technology has demonstrated clear limits so far notably because of the exploitation of unknown zero-day
software vulnerabilities and therefore of rapidly-changing and swift attacks or malwares. An alternative up-and-coming
way has been instead to detect the consequences or symptoms (or artifacts) of attacks, as they can be viewed in
networks or systems behaviours modifications. The underlying principle is to establish a baseline in the Information
System behaviour, and track any deviation from it.
Depending on the step reached by the attack, symptoms (or artifacts) are either advanced signs (or indicators) of an
attempt underway or signs (or indicators) of an already successful attack. These symptoms, which can be categorized in
various classes, are described in clause 6, together with the principle methods, means and (security, network or system)
monitoring tools to detect them.
Even though tools have become significantly advanced and powerful, the analysis and diagnosis of suspicious events by
skilled security SOC professionals remains essential since symptoms of attacks are not necessarily caused by actual
security incidents. This key human issue is at the heart of security monitoring and is what makes it sometimes so
challenging to present tangible results to organisation's executives.
All these difficulties show that it is necessary to implement both top-down and bottom-up approaches (see
clause 6.5), which combine threat intelligence provided by security governance and measured by state-of-the-art figures
(associated to GS ISI 001 indicators) with creative means of detection of related security events as they can be provided
by field security experts.
5 Positioning the various elements against the MITRE
CybOX and STIX reference frameworks
TM
International in scope and free for public use, the Cyber Observable eXpression (CybOX ) is a standardized schema
developed by the MITRE corporation and written in XML for the specification, capture, characterization and
communication of events or stateful properties that are observable in the operational domain. A wide variety of cyber
security use cases rely on such information including: event management/logging, malware characterization, intrusion
detection, incident response/management, attack pattern characterization, etc. CybOX provides a common and flexible
mechanism (structure and content) for addressing cyber observables across and among this full range of use cases
improving consistency, efficiency, interoperability and overall situational awareness.
ETSI
14 ETSI GS ISI 004 V1.1.1 (2013-12)
The Structured Threat Information eXpression (STIX™) is a collaborative community-driven effort led by the MITRE
corporation to define and develop a standardized language to represent structured cyber threat information and enable
easier and quicker information sharing among concerned stakeholders. The STIX Language intends to convey the full
range of potential cyber threat information and strives to be fully expressive, flexible, extensible, automatable, and as
human-readable as possible. In addition, STIX provides a unifying architecture tying together a diverse set of cyber
threat information (with relevant MITRE standards indicated) including:
• Cyber Observables (CybOX), which are the "base" element within the STIX structure (for example,
information about a file, a registry key value, a service being started, an HTTP request being sent - see also
CEE).
• Cyber Threat Indicators, which are a construct used to convey specific Observables combined with contextual
information intended to represent artifacts and/or behaviours of interest within a security context (Let us note
that Indicator has here a different meaning as in GS ISI 001).
• Security incidents (see CAPEC and MAEC).
• Adversary Tactics, Techniques, and Procedures (including attack patterns, malware, exploits, kill chains, tools,
infrastructure, targeting, etc. - see CAPEC and MAEC), which are representations of the behaviour or modus
operandi of cyber-adversaries.
• Exploit Targets (e.g. vulnerabilities or weaknesses in software, systems or configurations - see CVE, CWE and
CCE), that are targeted for exploitation by the TTP of a Threat Actor.
• Courses of Action (COA), e.g. incident response or vulnerability/weakness remedies, which are specific
measures to be taken to address threat whether they are corrective or preventative to address Exploit Targets,
or responsive to counter or mitigate the potential impacts of Security incidents.
• Cyber Attack Campaigns, which are instances of Threat Actors pursuing an intent, as observed through sets of
incidents and/or TTP, potentially across organizations.
• Cyber Threat Actors, which are characterizations of malicious actors (or adversaries) representing a cyber
attack threat including presumed intent and historically observed behaviour.
Interest in presenting STIX and CybOX in the present document is motivated by its extended scope, ranging from IT
non-security information to high-level IT security events, making it possible to further position the various elements
introduced in figure 3 of clause 4. Figure 4 describes this mapping with STIX and CybOX elements.
ETSI
15 ETSI GS ISI 004 V1.1.1 (2013-12)
IPC
File
system
Defined
Internet
Object
Object
Measure
State
source
Cyber (Exploit)
Stateful Mea
Module
Observable
sure (Exploit
& Indicators
Target)
Object
Custom
Measure
ISI-004
Attributes
Registry
Security
Action
(Base events
Event/TTP/ ISI-002
ISI-004
(COA)
& input data
Threat Actor
(Impacted
(Symptoms
in detection Network
or targeted
/Artifacts/
tools) ISI-002
assets)
Use cases)
(Attacks,
+
Daemon
incidents,
partly
vulnerabilities &
ISI-001
nonconformities)
(only a few
…
Indicators)
Figure 4: Mapping of STIX and CybOX elements with GS ISI multi-part series concepts
6 List of symptoms/artifacts and methods of detection
6.1 Symptoms/artifacts/hints
The symptoms, artifacts and hints that lead to the detection of security events can be categorized in 3 main categories:
• Suspicious behaviours (exhibited either by targets or attackers) that deviate from usual and specified
operations (also known in the literature as "anomaly detection").
• Exploitation underway of known software or configuration vulnerabilities (also known in the literature as
"misuse detection").
• Other attacks requiring elaborate correlation (especially known structured and complex attack patterns).
st
The 1 category consists in establishing a baseline of usual or acceptable behavior and in detecting deviations. The
principal method for implementing anomaly detection relies on the use of statistical techniques and machine learning to
create a reference model. Examples of monitored information include:
• at the network level, flow size (for example, usual size of flows for each internal host), communication
direction, service request rate (for example DNS), communication patterns (for example internal hosts
connecting to many other internal hosts);
• at the system or application level, list of processes, loads (especially during off-peak or weekend hours),
communication streams direction, access rate to some resources and applications, access rate to some actions,
activity of accounts, rate of rejections to some resources;
• regarding log information, log data string size (suspicious if too bulky), log data timeliness (suspicious if
limited interruption);
ETSI
16 ETSI GS ISI 004 V1.1.1 (2013-12)
• regarding user behaviours on workstations or central systems, identities and credentials (brute force, account
sharing, theft of credentials, failed authentication), user connection profiles (time and frequency), data protocol
usage, mail usage, files download, dump of data bases, file access methods (through some suspicious
resources), suspicious extension of rights or escalation of privileges;
• integrity of files (especially key files and files content changes).
nd
The 2 category consists in detecting well-characterized attack patterns, and also exploits or methods of exploitation
of known conception or software or configuration vulnerabilities. The main method for detecting such attack patterns is
through the definition of signatures (for example regular expressions). Examples of misuse that can be detected through
such methods include:
• malware installation;
• intrusion attempt such as SQL injection (entry of unusual string of characters into a Web application);
• Attempt to use a forbidden set of commands in an application;
• Commands stemming from hosts with origin addresses with a unusual or erroneous structure or without a
standard known structure;
• Attempts to access non-existent resources (through the use of honeypots).
This detection method applies to public software vulnerabilities (CVE tagg
...