ETSI GS ISI 001-1 V1.1.1 (2013-04)
Information Security Indicators (ISI); Indicators (INC); Part 1: A full set of operational indicators for organizations to use to benchmark their security posture
Information Security Indicators (ISI); Indicators (INC); Part 1: A full set of operational indicators for organizations to use to benchmark their security posture
DGS/ISI-001-1
General Information
Standards Content (Sample)
Group Specification
Information Security Indicators (ISI);
Indicators (INC);
Part 1: A full set of operational indicators for organizations
to use to benchmark their security posture
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 001-1 V1.1.1 (2013-04)
Reference
DGS/ISI-001-1
Keywords
ICT, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 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 001-1 V1.1.1 (2013-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions, symbols and abbreviations . 8
3.1 Definitions . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Fill the existing gap in continuous assurance standards . 8
4.1 Overview of existing continuous assurance standards . 8
4.2 Position and target 6-part GS ISI . 9
5 Description of the proposed security indicators . 9
5.1 Building a full flexible architecture of indicators . 10
5.2 The key issue of organization's maturity level . 11
5.3 Indicators detailed definition . 11
5.4 Indicators with security incidents . 12
5.5 Indicators with vulnerabilities . 30
5.6 Indicators as regards impact measurement . 50
5.7 Recap of available state-of-the-art figures . 51
Annex A (normative): Description of the proposed indicators with reference to the template
recommended in ISO/IEC 27004 standard. 56
Annex B (informative): Spreadsheet presentation of the indicators . 58
Annex C (informative): Authors & contributors . 59
Annex D (informative): Bibliography . 60
History . 62
ETSI
4 ETSI GS ISI 001-1 V1.1.1 (2013-04)
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 part 1 of a multi-part deliverable covering the Information Security Indicators (ISI); Indicators
(INC), as identified below:
Part 1: "A full set of operational indicators for organizations to use to benchmark their security posture";
Part 2: "Guide to select operational indicators based on the full set given in part 1".
The present document is included in a series of 6 ISI 00x specifications. These 6 specifications are the following (see
figure 1 summarizing the various concepts involved in event detection and interactions between all specifications):
• The present document addressing (together with its associated guide GS ISI 001-2 [3]) information security
indicators, meant to measure application and effectiveness of preventative measures.
• GS ISI 002 [4] addressing the underlying event classification model and the associated taxonomy.
• GS ISI 003 [i.5] addressing the key issue of assessing organization'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 [i.2] 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.
ETSI
5 ETSI GS ISI 001-1 V1.1.1 (2013-04)
GS ISG ISI Series Summary Definition
Event
reaction
measures
Fake events
(Simulation)
Security Event
Detected
Real
prevention
detection
events events
measures
measures
Residual risk
(event model-
centric vision)
Figure 1: Positioning the 6 GS ISI 00x against the 3 main security measures
Introduction
Over the course of recent years, a general consensus has progressively taken shape within the industry, recognizing that
the security benchmarking of IT systems was worthwhile, on an equal footing with what is done in some other areas or
disciplines such as quality or management. In other words, it seems possible to perform an objective assessment of the
application and effectiveness of a security policy or, more generally, of an Information Security Management System
(ISMS) and of the residual risk (see chart in introduction of GS ISI 002 [4], which highlights the 2 associated types of
events - incidents and vulnerabilities - and the joint area covered by IT security policy through the concept of usage or
implementation drift). Initial confirmation of this shared belief began to be seen worldwide in various sources of highly
converging figures, notably the figures from some advanced Cyber Defense and SIEM (Security Information and Event
Management) projects in the USA and Europe, through reliable and very refined operational indicators dealing with
both incidents and vulnerabilities. This emergence of security state-of-the-art figures (proving a trend towards
practical outcomes as much as sheer compliance) also made it possible:
• To bring to light the types of indicators that can under no circumstances serve as reference points (in
particular, ones that are too risk-oriented and consequently specific to a given industry sector), and to
determine the ones that are common to all industry sectors and situated on the right level (see the associated
event classification model in GS ISI 002 [4]),
• To map these indicators to the 11 domains of the ISO/IEC 27001/2 standards [6], [2] to assess continuously
the application and effectiveness of an existing ISMS (Continuous Checking), to the ISO/IEC 27006 standard
on ISMS audit, and to ISO/IEC 27004 [1] that primarily relates to security indicators.
Furthermore, to meet the requirements of governance (need for executive summary) and accuracy (need for clear
description), the idea is to tag and organize them according to the underlying event classification model and the
associated taxonomy, making it therefore possible to group them based on various criteria (origin, type of action, type
of asset impacted, type of impact, etc.) and to build a pyramidal structure with different level of more and less
aggregated indicators (with high flexibility). Each incident and each vulnerability will be described following a
structured language.
ETSI
6 ETSI GS ISI 001-1 V1.1.1 (2013-04)
The typical list of some 90 indicators and their 10 to 15 possible derived and consolidated indicators (as provided in
the present GS), generally shared by most advanced Cyber Defense and SIEM projects, is meant as a priority to CISOs,
in order to help them assessing and enforcing their company's or organization's IT security governance. Some of them
or some aggregates of them may also be used by Operational Risk Managers, CIOs and senior executives by providing
them with an overview of trends, drifts or progress as regards organization's whole security posture. However, the
proposed list of indicators is more or less in wide-spread use, leading to group them into 4 distinct categories, each with
different maturity levels:
• Well-known with accidental security incidents (i.e. breakdowns and natural disasters).
• Better and better defined with security incidents of the malicious and unawareness type (external intrusions
and attacks, internal deviant behaviours).
• Little developed with impact measurements.
• Very little developed with behavioural, software, configuration and general security vulnerabilities.
A question remaining is how to use this GS and select the relevant indicators, which depend on organization's existing
ISMS. In this regard, the proposed range of indicators should be considered as a simple but representative ground work,
from which a selection can be made by completely relying on the existing ISMS. Proceeding in this manner will lead to
a series of unique indicators that are specific to each organization, amongst which a first part will typically consist of
specific indicators, with a second part consisting of a sub-set of the list given in the present document. The main
characteristic of the former will be "effective ISMS implementation", while that of the latter will be more "operational".
As such, the structuring side of the ISMS will clarify and validate the choice of a given indicator from the proposed
ground work.
A second aspect to consider in the use of the present GS is the dispersal or not of the proposed state-of-the-art figures, a
state that can be directly associated with their greater or lesser "universal" reference quality (which in some extreme
cases can go so far as production impossibility). As such, the summary table proposed in clause 5.7 brings to light the
indicators with high convergence, which it is therefore possible to rely on with full trust in order to carry out
benchmarking within one's organization or one's company.
These considerations together with mapping with various reference frameworks and contexts are addressed in a separate
Guide called GS ISI 001-2 [3]. Another completely different use of indicators, which is worth mentioning here, is also
being dealt with in this Guide; it consists of applying them to the field of security product certification (with
ISO 15408).
It should be finally mentioned that the present GS rests partly on a work carried out by Club R2GS (see annex D), a
French association created during 2008, specializing in Cyber Defence and Security Information and Event
Management (SIEM). This association brings together a large number of representatives from many of the bigger
French institutions (mainly users) concentrating on those that are the most advanced in the Cyber Defence and SIEM
field. The present document (and associated GS ISI 001-2 [3]), as well as all other GS ISI 00x, is therefore based on
sound experience, this community of users having adopted and used the set of indicators and the related event
classification model sometimes for more than 3 years and sometimes on a world-wide scale. Moreover, it should be
added that a survey amongst the members proved the existence of a large core of indicators shared by most of them
(30 %). This core mainly overlaps the set of indicators mentioned as Priority 1 in clause 5.7 (Recap of state-of-the-art
figures), thus strengthening their level of dependability.
ETSI
7 ETSI GS ISI 001-1 V1.1.1 (2013-04)
1 Scope
The present document provides a full set of information security indicators (based on already existing results and hands-
on user experience), covering both security incidents and vulnerabilities. These one become nonconformities when they
violate organization's security policy. The present document is meant to aid CISOs and IT security managers in their
effort to evaluate and benchmark accurately their organization's security posture. GS ISI 001-2 [3] gives precise
instructions on how to use the present document and select indicators.
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
The following referenced documents are necessary for the application of the present document.
[1] ISO/IEC 27004:2009: "Information technology -- Security techniques -- Information security
management - Measurement".
[2] ISO/IEC 27002:2005: "Information technology -- Security techniques -- Code of practice for
information security management".
[3] 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".
[4] ETSI GS ISI 002: "Information Security Indicators (ISI); Event Model; Part 2: A security event
classification model and taxonomy".
[5] SANS Consensus Audit Guidelines V4.0: "20 Critical Security Controls for Effective Cyber
Defense".
NOTE: See http://www.sans.org/critical-security-controls/ for an up-to-date version.
[6] ISO/IEC 27001:2005: "Information technology -- Security techniques -- Information security
management systems -- Requirements".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
organization with regard to a particular subject area.
[i.1] NIST SP 800-55 Rev. 1 (July 2009): "Performance Measurement Guide for Information Security".
[i.2] ETSI GS ISI 005: "Information Security Indicators (ISI); Event Testing; Part 5: Event Testing".
[i.3] NIST SP 800-126 Rev. 2 (Sept. 2011): "The Technical Specification for the Security Content
Automation Protocol (SCAP): SCAP Version 1.2".
[i.4] NIST SP 800-53 Rev. 3 (August 2009): "Recommended Security Controls for Federal Information
Systems and Organizations".
ETSI
8 ETSI GS ISI 001-1 V1.1.1 (2013-04)
[i.5] ETSI GS ISI 003: "Information security Indicators (ISI); Indicators; Part 3: A set of Key
Performance Security Indicators (KPSI) for security event detection maturity evaluation".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in GS ISI 001-2 [3] apply.
3.2 Symbols
For the purposes of the present document, the symbols given in GS ISI 001-2 [3] apply.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in GS ISI 001-2 [3] apply.
4 Fill the existing gap in continuous assurance
standards
Despite rather numerous initiatives and some resulting useful standards in the continuous assurance field within the
information security community all around the world, standardization regarding indicators and tied up security event
classification model is missing (see figure 2). Standardization on this matter is becoming essential because such a set of
measurements has to be widely published in order to stimulate sharing of state-of-the-art figures within the security
community. Such a trend could eventually lead to the emergence of widely recognized and reliable state-of-the-art
statistics through large centralized data bases (possibly European-wide), and organizations could benefit greatly from
them to assess and benchmark themselves on a fully reliable basis. It is about overcoming often dramatic
inconsistencies and therefore total lack of dependability as regards the numerous figures that are published by various
sources today.
4.1 Overview of existing continuous assurance standards
The chart below is a summary of main existing standards in the continuous assurance field, which are all aimed at
providing guides to practically implement and use the notions of security assurance, trust and dependability, and to help
executives take the appropriate decisions and steps regarding security investments. Their scope ranges from basic (and
often purely technical) specifications to whole organizational standards.
ETSI
9 ETSI GS ISI 001-1 V1.1.1 (2013-04)
Which positioning for new « standards »?
Whole specifications Continuous assurance specifications
Global ISO 27002 or NIST 800-53 ISO 20000
ISO 27004 or NIST 800-55
frameworks
Cobit V4.1 … ISO 15408
ISO 27035 or NIST 800-61
ISO 27003 or NIST 800-37
Implementation
IETF RFC 2350
frameworks IETF RFC 3227 US CAG
…
NIST 800-137
NIST 800-92
s
Security Table Security policy Act Action Plans Indicators
k
e
r
c
c
i
o
f n
i
e w
c
Protect. Prof. Risk Analysis BCP Reaction Plans Event Model MITRE CAPEC
r
e e
e
p f MITRE CEE
NIST 800-86
m
S e
a
r
r
Projects Contracts Phys. Sec. Forensics Glossary
f
IETF RFC 4765/ NIST 800-126 MITRE CEE
Base (or technical)
…
5070/6045/5424 (SCAP) (CLS/CLR)
frameworks
Figure 2: Positioning the 6 GS ISI 00x against other main continuous assurance standards
4.2 Position and target 6-part GS ISI
Filling the gap requires the correct positioning with a clear correspondence with other widespread and widely used
lower or higher level specifications or standards. The goal of the 6-part GS ISI is also to build a future that can reconcile
and bridge the gap between initiatives or standards such as ISO/IEC 27002 [2] or NIST SP 800-53 [i.4] or the US
Consensus Audit Guidelines (CAG) [5] and GS ISI; or in other words to bring together top-down (security governance)
and bottom-up (IT field operational staff) approaches, and make these 2 populations exchange information better (see
chart above). As regards indicators, they should be compatible with the defined structure and the examples given in
ISO/IEC 27004 [1] or NIST SP 800-55 [i.1] (which both make up gateways to the continuous assurance and
operational world). And these should be closely tied up in their definition with a structured security event classification
model resting on a clear taxonomy for security events.
Positioning of 6-part GS ISI against CAPEC (Common Attack Pattern Enumeration and Classification) reference
framework is also useful, although it concerns mainly the event classification model. This correspondence is interesting
since the present document deals with the same kinds of security events (though only security incidents of the malicious
kind). CAPEC has been worked out by The MITRE Corporation, and it complements the NIST SP 800-126 [i.3]
(SCAP) standard, part of it deals in particular with categorizing vulnerabilities and nonconformities. Relationships
between 6-part GS ISI and CAPEC are addressed in GS ISI 002 [4] (Security Event Classification Model and
Taxonomy).
5 Description of the proposed security indicators
This clause describes the full set of the proposed security indicators, with a breakdown in line with the associated Event
Classification Model (Representation and associated Taxonomy) developed in GS ISI 002 [4] (in order to have a clear
and accurate description of them). Main categories are the following (3 relating to security incidents and 4 relating to
vulnerabilities):
Security incidents
• Intrusions and external attacks (Category IEX)
• Malfunctions (Category IMF)
• Internal deviant behaviours (Category IDB)
NOTE: This list also includes another category that concerns all categories of incidents (Category IWH).
ETSI
10 ETSI GS ISI 001-1 V1.1.1 (2013-04)
Vulnerabilities
• Behavioural vulnerabilities (Category VBH)
• Software vulnerabilities (Category WSW)
• Configuration vulnerabilities (Category VCF)
• General security (technical or organizational) vulnerabilities (Category VTC or Category VOR)
For each indicator, correspondence with ISI 002 Event Classification Model categories (categories, sub-categories and
families) and with the ISO/IEC 27002 [2] controls are mentioned. Indicators definition is compliant with the
recommended template provided for that purpose in ISO/IEC 27004 [1]. Moreover, stakeholders of indicators are
summarized in clause 5.7 table (Recap), by assigning indicators to 2 different populations: first CISOs, and then
Operational Risk Managers, CIOs and Senior Executive Management. Last, a spreadsheet presentation of the indicators
is given in annex C (Excel document).
5.1 Building a full flexible architecture of indicators
To meet requirements of both completeness (need for a full set of more than 90 indicators for precise benchmarking
purposes of most ISMS controls) and governance (need for a summary of 10 to 15 derived and consolidated
indicators), they are mapped and organized according to the underlying event classification model (representation and
associated taxonomy), making it therefore possible to group them based on various criteria (origin, type of action, type
of asset impacted, type of CIA consequence, type of impact, etc.) and to build a pyramidal structure with different level
of more or less aggregated indicators (with high flexibility).
The model structure and taxonomy used to describe incidents (see GS ISI 002 [4]) are as follows (8 areas required to
fully describe a change in a system): who and/or why (subject), what (verb 1), how (verb 2), status of incident (attempt
underway or success), which vulnerability is being exploited, on what kind of asset (complement), with what CIA
consequence, with what kind of impact.
The model structure and taxonomy used to describe vulnerabilities (see GS ISI 002 [4]) are as follows (5 areas
required to fully describe a state): what, on what kind of assets, who (only for behavioural vulnerabilities), for what
purpose (only for behavioural vulnerabilities), to what kind of possible exploitation.
The following aggregated top level key indicators for incidents are recommended:
• External malicious incidents.
• Internal malicious incidents (that can be split depending on various origins - employees, contractors, service
providers and business partners).
• Internal incidents involving carelessness or lack of awareness (that can be split depending on various origins -
employees, contractors, service providers and business partners).
• Accidental or unwitting incidents.
• Incidents with A consequences (loss of availability, possibly refined with the various types of assets
impacted - i.e. workstations, servers, mainframes, network).
• Incidents with C consequence (loss of confidentiality - the usually less known consequence, possibly refined
with privacy, IPR, Defence secret, etc.).
• Incidents with fraud-related I consequence (loss of integrity, refined with the most interesting types).
• Incidents with a specific impact (financial, legal, reputation, etc.).
• Incidents impacting workstations (possibly refined with organization-owned or employee-owned - Cf.
BYOD).
• Incidents impacting Web servers.
• Incidents depending on the kind of vulnerabilities exploited or on their status (regarding lack of patching for
example).
ETSI
11 ETSI GS ISI 001-1 V1.1.1 (2013-04)
It is however necessary to be aware that most of the time no benchmarking is possible with these top level indicators,
since they are too dependent on each industry sector.
5.2 The key issue of organization's maturity level
No events detected within an organization does not mean that no events occurred within it, so it is strongly advised to
assess the level of event detection effectiveness. It is about building a dedicated, practical, simple and easy-to-use
N-level maturity scale focused on security event detection and based on hands-on experience, in order to weigh the
figures worked out by organizations depending on their security maturity level (tools, processes, organization, people)
and therefore to correct these figures (see GS ISI 003 [i.5]). This concept is close to the "Implementation evidence"
concept used in NIST SP 800-55 [i.1] in the description of examples of indicators (Appendix A - Candidate Measures).
GS ISI 003 [i.5] addresses this issue by defining a simple way to achieve that, by relying in particular on the US CAG
reference framework and its control points. Based on a list of questions and on these control points and associated
special metrics, it is proposed to define a set of KPSI (Key Performance Security Indicators) that will apply to the
present indicators to weigh the results. Another (more accurate) way to assess this maturity level is to test the
effectiveness of the detection tools through a comprehensive set of testing scenarios (stimulation through fake security
events); this is the objective of GS ISI 005 [i.2].
For each indicator described below, a whole detection level of associated events corresponding to the state-of-the-art
(practices by the best organizations) is given in item 6 (3 levels - from 1 very difficult to 3 relatively easy - with the
detection level by the best methodology and current tools in the profession, if known). Since we are far from reaching a
100 % event detection rate for many security events, it is mandatory to apply a correction to figures gathered from the
SIEM projects and achievements within the profession (depending on the level of monitoring equipment and the
seriousness of sampled organizations), if we want to reckon real state-of-the-art figures (representing the true reality).
This sort of detection level figure should therefore be reckoned specifically for the organization depending on its
maturity level (through KPSI as defined in GS ISI 003 [i.5]) to get the most likely figure applying to the organization.
Another more obvious concept that is necessary to have in mind and to communicate when working out an indicator is
of course its level of coverage, i.e. the IT perimeter or scope on which the indicator is being worked out; a small scope
of monitoring may therefore lead to a more partial and less reliable figure than a larger and possibly organization-wide
scope.
5.3 Indicators detailed definition
The following is provided for each proposed indicator (except Impact indicators, which are of a different kind and have
no correspondence with the GS ISI 002 [4] event classification model):
0) Its category (according to the 7 categories of the event classification model described in GS ISI 002 [4]).
1) Its family and identifier (XXX_YYY.number) and name (according to the GS ISI 002 [4] event classification
model).
2) The precise definition of base events comprising the indicator with possible general comments (to be as precise
as possible about the events that are counted).
3) The estimated frequency level of base events (main rationale for selecting the indicator). Let's note that this
frequency is being quantitatively and more precisely collected and reckoned by Club R2GS in the state-of-the-
art value (see point 8).
4) The severity level of base events (1 being the lowest and 4 the highest).
5) The state-of-the-art detection means of most base events (manual vs. automatic, methods and technical tools
for detecting events).
6) The whole detection level of most base events (3 levels - from 1 very difficult to 3 relatively easy - with the
detection level by best methodology and current tools in the industry, as defined in the related maturity KSPI -
see item 10 and GS ISI 003 [i.5]).
7) The indicator production as regards ISO/IEC 27004 [1] ("base measure", "derived measure 1", "derived
measure 2", "indicator value").
ETSI
12 ETSI GS ISI 001-1 V1.1.1 (2013-04)
8) The state-of-the-art value (after necessary correction - see explanations in clause 5.2 - in order to reckon the
true average value due to the detection rate by best organizations - see previous field 6):
- Indicated with the scattering of the figures at the basis of the supplied average value.
- Expressed as monthly frequency of events occurrence or as a % (organization with 100 000 workstations
accessing the Information System, with possible supplementary clarifications, if necessary).
- Possibly not applicable or not uniform (definitions which are too variable depending on organizations).
9) Its possible correspondence to ISO/IEC 27002 [2], via the corresponding control area from amongst the 11
available ones ("control objective").
10) The type of maturity KPSI relevant to the indicator (see GS ISI 003 [i.5]).
Annex A presents the positioning of these various items relative to the "template" recommended in ISO/IEC 27004 [1]
for working out an indicator within an organization. As such, the proposed indicators are positioned, depending on the
cases, as "base measure", "derived measure" or "indicator". The term "indicator" means that the measurement is
appropriate to serve as a reference point for assessing progress made with the existing ISMS, while for their part, the
terms "base measure" and "derived measure" can, in some cases, mean that we have no way of acting on the relevant
controls (for example applied external pressure). It should also be noted that many subjects tackled in the
ISO/IEC 27004 [1] "template", which are totally specific to the organization and not applicable here, are consequently
not included in the present document.
The indicators described below (also available in an Excel spreadsheet referenced in annex B) are split into
3 categories:
• The ones relevant to security incidents (ISMS effectiveness level), which are complemented by forewarning
indicators that measure the external malicious "pressure" (malicious attempts detected and that can herald
security incidents of the "real intrusion" type).
• The ones relevant to behavioural, software, configuration and general security (technical and organizational)
vulnerabilities (partly ISMS actual application level).
• The ones relevant to impact measurements (Practical consequences).
5.4 Indicators with security incidents
The following are the recommended operational indicators with security incidents (41 in all):
Category IEX (Intrusions and external attacks)
Indicators of this category give information on the occurrence of incidents caused by external malicious threat sources.
Family IEX_FGY: Website forgery
IEX_FGY.1: Forged domain or brand names impersonating or imitating legitimate and genuine names
Forged domains are addresses very close to the domain names legitimately filed with registration companies or
organizations (forged domains are harmful only when actively used to entice customers to the website for
fraudulent purposes). It also includes domain names that imitate another domain name or a brand.
Base events
Detection of a new forged domain address (primarily .com and .nn, with the latter also possibly including .gov.nn)
that is close to the domain or brand names of the company or organization (including typing errors), and that is
st
registered within a database corresponding with these 1 level domains
Frequency: Frequency often high (companies with the general public as customers)
Severity: 2 (if addresses actually used)
Detection means: Semi-automatic production (search directly within databases administered by the registrars in
charge of 1st level domains, or with intermediaries that offer parking pages)
Detection level: 3 (detection rate can be up to 70 %)
Indicator production
Base measure: Date of the event
Derived measure 1: Number of events detected during the last 30 days
Derived measure 2: Ratio of Number of events detected during the last 30 days to Number of existing legitimate
addresses
ETSI
13 ETSI GS ISI 001-1 V1.1.1 (2013-04)
Indicator value: Ratio of Derived Measure 2 to Average per month for the last 90 days
State-of-the-art value: Not applicable (too dependent on companies or organizations, on their reputation or on
the general public nature or not of their activities)
Link with ISO/IEC 27002 [2]
No (but implicit and derived link with A13)
Maturity KPSI
Will be available in the next version of the present document.
IEX_FGY.2: Wholly or partly forged websites (excluding parking pages) spoiling company's image or
business
Forged websites correspond with 2 main usages (forgery of sites in order to steal personal data such as account
identifiers and passwords, forgery of services in order to capitalize on a brand and to generate turnover that
st
creates unfair competition). In this case, reference is often made to phishing (1 usage) or pharming.
Base events
Detection of a website or service with at least 25 % forged pages
Frequency: Frequency often high (companies with the general public as customers)
Severity: 2
Detection means: Semi-automatic production is possible (detection using recognition tools that search the Web
for content that is identical with that of the company or organization, by means of an Internet crawler used
together with an image analysis engine)
Detection level: 1 (detection rate could be up to 40 % for business forgery and 60 % for phishing)
Indicator production
Base measure: Date of the event
Derived measure 1: Number of events detected during the last 30 days
Derived measure 2: Ratio of Number of events detected during the last 30 days to Number of company's or
organization's exposed Websites
Indicator value: Ratio of Derived Measure 2 to Average per month for the last 90 days
State-of-the-art value: Not applicable (too dependent on companies or organizations, on their reputation or on
the general public nature or not of their activities). However, one quarter of IEX_FGY.1 seems to lead to
IEX_FGY.2
Link with ISO/IEC 27002 [2]
No (but implicit and derived link with A13)
Maturity KPSI
Will be available in the next version of the present document.
Family IEX_SPM: Spam
IEX_SPM.1: Not requested received bulk messages (spam) targeting organization's registered users
Spam are messages received in company's or organization's messaging systems in the framework of mass and
not individualized campaigns, luring into clicking dangerous URLs (possibly Trojan laden) or enticing to carry out
harmful to concerned individual actions.
Base events
Reception of a spam message, not detected and not blocked by messaging system entry filtering
Frequency: Very high frequency (situation that leads to loss of effectiveness in exchanges for all companies' or
organizations' users)
Severity: 3
Detection means: Manual production (figures from messaging system to collect - Cf. messages filtered by
antispam tools at organization's messaging system entry -, and messages declared « undesirable » by users
themselves - Cf. monthly manual survey based on a sample of users)
Detection level: 3 (detection rate can reach 100 %)
Indicator production
Base measure: Date of the event
Derived measure 1: Number of events detected during the last 30 days
Derived measure 2: Ratio of Number of events detected during the last 30 days to Number of messages
received in messaging system during the last 30 days
Indicator value: Ratio of Derived Measure 2 to Average per month for the last 90 days
State-of-the-art value: (Derived measure 2) 0,2 % for internal business messaging systems (rather low
scattering between companies and organizations, but very different situation for public messaging systems)
Link with ISO/IEC 27002 [2]
No
Maturity KPSI
Will be available in the next version of the present document.
ETSI
14 ETSI GS ISI 001-1 V1.1.1 (2013-04)
Family IEX_PHI: Phishing
IEX_PHI.1: Phishing targeting company's customers' workstations spoiling company's image or business
Phishing involves a growing number of business sectors (financial organizations, e-commerce sites, online
games, social sites etc.). It includes attacks via e-mail with messages that contain either malicious URL links (to
forged websites) or malicious URL links (to malware laden genuine websites).
Base events
Customer reporting of a phishing attempt.
Frequency: High frequency and strong impact on the image
Severity: 2
Detection means: Manual production (via periodic tests of customers or users)
Detection level: 2 (detection rate can be up to 80 %)
Indicator production
Base measure: Date of the event
Derived measure 1: Number of events detected during the last 30 days
Derived measure 2: Number of unique campaigns detected during the last 30 days. A unique campaign consists
of a series of coordinated phishing attacks coming from a single origin within a given time slot, with an average of
6 attacks per campaign.
Indicator value: Ratio of Derived Measure 2 to the media exposure (communication measurement specific to
each professional sector)
State-of-the-art value: (Derived measure 2) 20 campaigns per month in English language (relatively high
scattering between companies in a given business sector, primarily depending on the media exposure)
Link with ISO/IEC 27002 [2]
No
Maturity KPSI
Will be available in the next version of the present document.
IEX_PHI.2: Spear phishing or whaling carried out using social engineering and targeting organization's
specific registered users
Spear phising are "spoofed" and customized messages looking like a usual professional relationship or an
authority, and asking to click on or open dangerous URL links or dangerous attachments (malware laden)
Base events
Reception of a "spoofed" and customized messages looking like a usual professional relationship or an authority,
and asking to click on or open dangerous URL links or dangerous attachments (malware laden), or asking to send
confidential information by e-mail return
Frequency: High frequency in some business sectors and organizations, and possible early indicator of
subsequent successful intrusions
Severity: 3
Detection means: Automatic production possible (usage of CERTs to detect more or less repetitive attack
scenarios targeting different organizations and personalities, internal detection via the users themselves if
moderately executed scenario)
Detection level: 1 (detection rate can be up to 30 %)
Indicator production
Base measure: Date of the event
Derived measure 1: Number of events detected during the last 30 days
Derived measure 2: idem Derived Measure 1
Indicator value: Ratio of Number of events detected during the last 30 days to Number of messages recieved in
messaging system during the last 30 days
State-of-the-art value: Not applicable (too dependent on companies or organizations, on their reputation or on
the sensitive kind of their business)
Link with ISO/IEC 27002 [2]
A13 control area
Maturity KPSI
Will be available in the next version of the present document.
Family IEX_INT: Intrusion
IEX_INT.1: Intrusion attempts on externally accessible servers
Attempts are here systematic scans (excluding network reconnaissance) and abnormal and suspicious requests
on externally accessible servers, detected by an IDS/IPS or not.
Base events
Detection of intrusion attempts (systematic scans (excluding network reconnaissance) and abnormal and
suspicious requests on externally accessible servers.
Frequency: High frequency and information of possible successful intrusions
Severity: 2 or 3 (according to the type - flaw discovery scan vs. attack in
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...