ISO/IEC 27041:2015
(Main)Information technology - Security techniques - Guidance on assuring suitability and adequacy of incident investigative method
Information technology - Security techniques - Guidance on assuring suitability and adequacy of incident investigative method
ISO/IEC 27041:2015 provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are "fit for purpose". It encapsulates best practice on defining requirements, describing methods, and providing evidence that implementations of methods can be shown to satisfy requirements. It includes consideration of how vendor and third-party testing can be used to assist this assurance process. This document aims to ? provide guidance on the capture and analysis of functional and non-functional requirements relating to an Information Security (IS) incident investigation, ? give guidance on the use of validation as a means of assuring suitability of processes involved in the investigation, ? provide guidance on assessing the levels of validation required and the evidence required from a validation exercise, ? give guidance on how external testing and documentation can be incorporated in the validation process.
Technologies de l'information — Techniques de sécurité — Préconisations concernant la garantie d'aptitude à l'emploi et d'adéquation des méthodes d'investigation sur incident
L'ISO/IEC 27041:2015 fournit des préconisations concernant les mécanismes visant à garantir que les méthodes et processus utilisés dans l'investigation des incidents de sécurité de l'information sont «en adéquation avec l'application visée». Elle englobe les pratiques d'excellence sur la définition des exigences, la description des méthodes et l'attestation que les mises en ?uvre des méthodes satisfont aux exigences. Elle prend en compte les modalités d'utilisation des essais menés par le fournisseur et les tierces parties pour contribuer à ce processus de garantie d'adéquation. L'ISO/IEC 27041:2015 vise à: - fournir des préconisations concernant la collecte et l'analyse des exigences fonctionnelles et non fonctionnelles liées à une investigation sur un incident de sécurité de l'information (IS); - fournir des préconisations concernant l'usage de la validation comme une garantie d'aptitude à l'emploi des processus sollicités par l'investigation; - fournir des préconisations concernant l'évaluation des niveaux de validation requis et les preuves exigées sur un exercice de validation; - fournir des préconisations concernant l'intégration des essais et documentations externes au processus de validation.
General Information
- Status
- Published
- Publication Date
- 18-Jun-2015
- Drafting Committee
- ISO/IEC JTC 1/SC 27/WG 4 - Security controls and services
- Current Stage
- 9093 - International Standard confirmed
- Start Date
- 19-Apr-2021
- Completion Date
- 30-Oct-2025
Overview
ISO/IEC 27041:2015 - Guidance on assuring suitability and adequacy of incident investigative method provides internationally recognized guidance for ensuring that the methods, tools and processes used during information security incident investigations are fit for purpose. The standard describes how to capture functional and non‑functional requirements for an investigation, how to verify and validate investigative processes and tools, and how to produce evidence that method implementations satisfy those requirements. It also covers the role of vendor and third‑party testing in the assurance lifecycle.
Keywords: ISO/IEC 27041, incident investigative method, validation, verification, assurance, digital forensics, information security incident investigation.
Key Topics and Requirements
- Requirements capture and analysis: guidance for defining clear functional and non‑functional requirements for investigations and digital evidence handling.
- Process design and implementation: principles for decomposing complex investigative workflows into atomic parts, tool selection guidance, and risk/uncertainty evaluation.
- Verification: methods to verify processes and tools against specified requirements prior to deployment.
- Validation: approaches to validate that processes produce results suitable for the investigation’s objectives; includes criteria for comprehensive, sufficient, or failed validation.
- Assurance stages and models: staged assurance lifecycle (development, verification, validation, confirmation, deployment, review) and options for in‑house, external, or mixed assurance.
- Evidence production: documenting and maintaining validation evidence; incorporating external testing and vendor documentation into the assurance package.
- Maintenance: review cycles, revalidation and evidence preservation to sustain ongoing fitness for purpose.
Practical Applications and Who Will Use It
ISO/IEC 27041 is designed for organizations and professionals responsible for planning, authorising, managing or conducting information security incident investigations, including:
- Digital forensics teams and incident response practitioners
- Security managers and compliance officers
- IT risk and assurance personnel evaluating investigative methods
- Legal and evidentiary decision‑makers assessing reliability of digital evidence
- Vendors and third parties providing forensic tools or testing services
Practical uses include selecting and validating forensic tools, preparing defensible investigation processes for litigation or regulatory review, integrating third‑party test reports into assurance evidence, and establishing repeatable, auditable incident investigation practices.
Related Standards
- ISO/IEC 27037 - Guidance on identification, collection and preservation of digital evidence (complements 27041).
- ISO/IEC 27042 - Guidance on analysis and interpretation of digital evidence.
- ISO/IEC 27043 - Principles and processes for incident investigation.
- ISO/IEC 27035 (parts) - Incident management and response lifecycle.
Use ISO/IEC 27041 together with these standards to build a comprehensive, auditable framework for information security incident investigations and digital forensic assurance.
ISO/IEC 27041:2015 - Information technology -- Security techniques -- Guidance on assuring suitability and adequacy of incident investigative method
ISO/IEC 27041:2015 - Technologies de l'information -- Techniques de sécurité -- Préconisations concernant la garantie d'aptitude a l'emploi et d'adéquation des méthodes d'investigation sur incident
Frequently Asked Questions
ISO/IEC 27041:2015 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Security techniques - Guidance on assuring suitability and adequacy of incident investigative method". This standard covers: ISO/IEC 27041:2015 provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are "fit for purpose". It encapsulates best practice on defining requirements, describing methods, and providing evidence that implementations of methods can be shown to satisfy requirements. It includes consideration of how vendor and third-party testing can be used to assist this assurance process. This document aims to ? provide guidance on the capture and analysis of functional and non-functional requirements relating to an Information Security (IS) incident investigation, ? give guidance on the use of validation as a means of assuring suitability of processes involved in the investigation, ? provide guidance on assessing the levels of validation required and the evidence required from a validation exercise, ? give guidance on how external testing and documentation can be incorporated in the validation process.
ISO/IEC 27041:2015 provides guidance on mechanisms for ensuring that methods and processes used in the investigation of information security incidents are "fit for purpose". It encapsulates best practice on defining requirements, describing methods, and providing evidence that implementations of methods can be shown to satisfy requirements. It includes consideration of how vendor and third-party testing can be used to assist this assurance process. This document aims to ? provide guidance on the capture and analysis of functional and non-functional requirements relating to an Information Security (IS) incident investigation, ? give guidance on the use of validation as a means of assuring suitability of processes involved in the investigation, ? provide guidance on assessing the levels of validation required and the evidence required from a validation exercise, ? give guidance on how external testing and documentation can be incorporated in the validation process.
ISO/IEC 27041:2015 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security; 35.040 - Information coding. The ICS classification helps identify the subject area and facilitates finding related standards.
You can purchase ISO/IEC 27041:2015 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 27041
First edition
2015-06-15
Information technology — Security
techniques — Guidance on assuring
suitability and adequacy of incident
investigative method
Technologies de l’information — Techniques de sécurité — Directives
sur la façon d’assurer l’aptitude à l’emploi et l’adéquation d’une
méthode d’investigation d’incident
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2015 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 Method development and assurance . 4
5.1 Overview . 4
5.2 General principles . 4
5.3 General development and deployment model . 4
5.4 Assurance stages . 5
5.5 Requirements capture and analysis . 6
5.5.1 General principles of requirements . 6
5.5.2 Functional Requirements . 7
5.5.3 Verification of requirements . 7
5.6 Process Design . 7
5.6.1 Overview . 7
5.6.2 Tool Selection . 7
5.6.3 Uncertainty and risk evaluation . 7
5.7 Process Implementation . 8
5.7.1 Overview . 8
5.7.2 Tool choice — guidance for deployment . 8
5.8 Process Verification . 8
5.8.1 General principles of verification . 8
5.8.2 Verification of processes . 9
5.8.3 Verification of tools . 9
5.9 Process Validation . 9
5.9.1 General principles of validation . 9
5.9.2 Comprehensive validation . 9
5.9.3 Sufficient validation . 9
5.9.4 Fully validated processes .10
5.9.5 Failed validation .10
5.10 Confirmation .10
5.11 Deployment .10
5.11.1 Tool choice .10
5.12 Review and Maintenance .10
6 Assurance Models .11
6.1 Overview .11
6.2 In-house assurance .11
6.3 External assurance .11
6.4 Mixed assurance .11
7 Production of evidence for assurance .11
7.1 Overview .11
7.2 Pre-validation preparation .12
7.3 Producing Evidence of Validation .12
7.4 Maintenance of Validation .12
7.5 Validation of Examinations .12
7.6 Validation of Investigations .13
Annex A (informative) Examples .14
Bibliography .18
© ISO/IEC 2015 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Details of any patent rights identified during the development of the document will be in the Introduction
and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 27, IT Security
techniques.
iv © ISO/IEC 2015 – All rights reserved
Introduction
About this International Standard
This International Standard is concerned with providing assurance that the investigative process used
is appropriate for the incident under investigation and the results which are required. It also describes,
at an abstract level, the concept of breaking seemingly complex processes into a series of smaller atomic
parts, which should aid in the development of simple, yet robust, investigation methods. It should be
considered by any person authorising, giving instruction for, managing, or conducting an investigation.
It should be applied prior to any investigation, in the context of principles and processes (defined in
1)
ISO/IEC 27043:2015) and sound preparation and planning (defined in ISO/IEC 27035-2 ) to ensure the
suitability of methods to be applied in the investigative processes described in ISO/IEC 27037:2012 and
ISO/IEC 27042:2015.
Relationship to other standards
This International Standard is intended to complement other standards and documents which give
guidance on the investigation of, and preparation to investigate, information security incidents. It is not
a comprehensive guide, but lays down certain fundamental principles which are intended to ensure that
tools, techniques, and methods can be selected appropriately and shown to be fit for purpose should the
need arise.
This International Standard also intends to inform decision-makers that need to determine the
reliability of digital evidence presented to them. It is applicable to organizations needing to protect,
analyse, and present potential digital evidence. It is relevant to policy-making bodies that create and
evaluate procedures relating to digital evidence, often as part of a larger body of evidence.
This International Standard describes part of a comprehensive investigative process which includes, but
is not limited to, the following topic areas:
— incident management, including preparation and planning for investigations;
— handling of digital evidence;
— use of, and issues caused by, redaction;
— intrusion prevention and detection systems, including information which can be obtained from
these systems;
— security of storage, including sanitization of storage;
— ensuring that investigative methods are fit for purpose;
— carrying out analysis and interpretation of digital evidence;
— understanding principles and processes of digital evidence investigations;
— security incident event management, including derivation of evidence from systems involved in
security incident event management;
— relationship between electronic discovery and other investigative methods, as well as the use of
electronic discovery techniques in other investigations;
— governance of investigations, including forensic investigations.
These topic areas are addressed, in part, by the following ISO/IEC standards:
— ISO/IEC 27037:2012
1) To be published.
© ISO/IEC 2015 – All rights reserved v
This International Standard describes the means by which those involved in the early stages of an
investigation, including initial response, can ensure that sufficient potential digital evidence is captured
to allow the investigation to proceed appropriately.
— ISO/IEC 27038:2014
Some documents can contain information that must not be disclosed to some communities. Modified
documents can be released to these communities after an appropriate processing of the original
document. The process of removing information that is not to be disclosed is called “redaction”.
The digital redaction of documents is a relatively new area of document management practice, raising
unique issues and potential risks. Where digital documents are redacted, removed information must
not be recoverable. Hence, care needs to be taken so that redacted information is permanently removed
from the digital document (e.g. it must not be simply hidden within non-displayable portions of the
document).
ISO/IEC 27038:2014 specifies methods for digital redaction of digital documents. It also specifies
requirements for software that can be used for redaction.
— ISO/IEC 27040:2015
This International Standard provides detailed technical guidance on how organizations can define
an appropriate level of risk mitigation by employing a well-proven and consistent approach to the
planning, design, documentation, and implementation of data storage security. Storage security applies
to the protection (security) of information where it is stored and to the security of the information
being transferred across the communication links associated with storage. Storage security includes
the security of devices and media, the security of management activities related to the devices and
media, the security of applications and services, and security relevant to end-users during the lifetime
of devices and media and after end of use.
Security mechanisms like encryption and sanitization can affect one’s ability to investigate by
introducing obfuscation mechanisms. They have to be considered prior to and during the conduct of
an investigation. They can also be important in ensuring that storage of evidential material during and
after an investigation is adequately prepared and secured.
— ISO/IEC 27042:2015
This International Standard describes how methods and processes to be used during an investigation
can be designed and implemented in order to allow correct evaluation of potential digital evidence,
interpretation of digital evidence, and effective reporting of findings.
— ISO/IEC 27043:2015
This International Standard defines the key common principles and processes underlying the
investigation of incidents and provides a framework model for all stages of investigations.
The following ISO/IEC projects also address, in part, the topic areas identified above and can lead to the
publication of relevant standards at some time after the publications of this International Standard.
2)
— ISO/IEC 27035 (all parts)
This is a three-part standard that provides organizations with a structured and planned approach to
the management of security incident management. It is composed of
3)
— ISO/IEC 27035-1
2) To be published.
3) To be published.
vi © ISO/IEC 2015 – All rights reserved
This part presents basic concepts and phases of information security incident management. It combines
these concepts with principles in a structured approach to detecting, reporting, assessing, responding,
and applying lessons learned.
4)
— ISO/IEC 27035-2
This part presents the concepts to plan and prepare for incident response. The concepts, including
incident management policy and plan, incident response team establishment, and awareness briefing
5)
and training, are based on the plan and prepare phase of the model presented in ISO/IEC 27035-1 . This
part also covers the “Lessons Learned” phase of the model.
6)
— ISO/IEC 27035-3
This part includes staff responsibilities and practical incident response activities across the organization.
Particular focus is given to the incident response team activities such including monitoring, detection,
analysis, and response activities for the collected data or security events.
7)
— ISO/IEC 27050 (all parts)
This addresses activities in electronic discovery, including, but not limited to identification, preservation,
collection, processing, review, analysis, and production of electronically stored information (ESI).
In addition, it provides guidance on measures, spanning from initial creation of ESI through its final
disposition, which an organization can undertake to mitigate risk and expense should electronic
discovery become an issue. It is relevant to both non-technical and technical personnel involved in some
or all of the electronic discovery activities. It is important to note that this guidance is not intended to
contradict or supersede local jurisdictional laws and regulations.
Electronic discovery often serves as a driver for investigations, as well as evidence acquisition and
handling activities. In addition, the sensitivity and criticality of the data sometimes necessitate
protections like storage security to guard against data breaches.
— ISO/IEC 30121:2015
This International Standard provides a framework for governing bodies of organizations (including
owners, board members, directors, partners, senior executives, or similar) on the best way to prepare
an organization for digital investigations before they occur. This International Standard applies to the
development of strategic processes (and decisions) relating to the retention, availability, access, and
cost effectiveness of digital evidence disclosure. This International Standard is applicable to all types
and sizes of organizations. The International Standard is about the prudent strategic preparation for
digital investigation of an organization. Forensic readiness ensures that an organization has made the
appropriate and relevant strategic preparation for accepting potential events of an evidential nature.
Actions may occur as the result of inevitable security breaches, fraud, and reputation assertion. In every
situation, information technology (IT) has to be strategically deployed to maximize the effectiveness of
evidential availability, accessibility, and cost efficiency
Figure 1 shows typical activities surrounding an incident and its investigation. The numbers shown in
this diagram (e.g. 27037) indicate the International Standards listed above and the shaded bars show
where each is most likely to be directly applicable or has some influence over the investigative process
(e.g. by setting policy or creating constraints). It is recommended, however, that all should be consulted
prior to, and during, the planning and preparation phases. The process classes shown are defined fully
in this International Standard and the activities identified match those discussed in more detail in
ISO/IEC 27035-2, ISO/IEC 27037:2012, and ISO/IEC 27042:2015.
4) To be published.
5) To be published.
6) To be published.
7) New project.
© ISO/IEC 2015 – All rights reserved vii
Figure 1 — Applicability of standards to investigation process classes and activities
viii © ISO/IEC 2015 – All rights reserved
INTERNATIONAL STANDARD ISO/IEC 27041:2015(E)
Information technology — Security techniques —
Guidance on assuring suitability and adequacy of incident
investigative method
1 Scope
This International Standard provides guidance on mechanisms for ensuring that methods and processes
used in the investigation of information security incidents are “fit for purpose”. It encapsulates best
practice on defining requirements, describing methods, and providing evidence that implementations of
methods can be shown to satisfy requirements. It includes consideration of how vendor and third-party
testing can be used to assist this assurance process.
This document aims to
— provide guidance on the capture and analysis of functional and non-functional requirements
relating to an Information Security (IS) incident investigation,
— give guidance on the use of validation as a means of assuring suitability of processes involved in the
investigation,
— provide guidance on assessing the levels of validation required and the evidence required from a
validation exercise,
— give guidance on how external testing and documentation can be incorporated in the validation
process.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27000:2013, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions in ISO/IEC 27000:2013 and the following
apply.
3.1
atomic
performing a single function only
Note 1 to entry: A method (3.11) for recovery of all live files from a device can be atomic if it relies solely on the
use of filesystem meta-data. A method for recovery of all deleted files is unlikely to be atomic as it will require
sub-methods which identify and extract particular file structures from the data on the storage device based on
knowledge of file contents (e.g. .jpg, .png, .odt, XML, etc.).
3.2
black box testing
examining a process by using it to process known inputs and comparing the results against predicted
outputs which reflect the requirements for the process
© ISO/IEC 2015 – All rights reserved 1
3.3
client
person or organisation on whose behalf the investigation is to be undertaken
[SOURCE: ISO/IEC 27042:2015, 3.2]
3.4
confirmation
formal assessment of existing objective evidence that a process is fit (or remains fit) for a specified
purpose
3.5
contemporaneous notes
contemporaneous record
written record of actions taken and decisions made, produced at the same time or as soon afterwards as
is practically possible, as the actions and decisions it records
Note 1 to entry: In many jurisdictions, it is necessary for contemporaneous notes to be handwritten in non-
erasable ink in a tamper-evident notebook to assist with issues of authenticity and admissibility.
[SOURCE: ISO/IEC 27042:2015, 3.4]
3.6
examination
set of processes applied to identify and retrieve relevant potential digital evidence from one or more
sources
[SOURCE: ISO/IEC 27042:2015, 3.7]
3.7
investigation
application of examinations (3.6), analyses, and interpretation to aid understanding of an incident
[SOURCE: ISO/IEC 27042:2015, 3.10]
3.8
investigative lead
person leading the investigation at a strategic level
[SOURCE: ISO/IEC 27042:2015, 3.11]
3.9
investigative team
all persons involved directly in the conduct of the investigation
[SOURCE: ISO/IEC 27042:2015, 3.12]
3.10
investigator
member of the investigative team (3.9), including the investigative lead (3.8)
[SOURCE: ISO/IEC 27042:2015, 3.13]
3.11
method
definition of an operation which can be used to produce data or derive information as an output from
specified inputs
Note 1 to entry: Ideally, a method (3.11) should be atomic (3.1) (i.e. it should not perform more than one function)
in order to enable re-use of methods and the processes (3.12) derived from them and to reduce the amount of work
required to validate processes.
2 © ISO/IEC 2015 – All rights reserved
3.12
process
operational implementation of a method (3.11)
3.13
producer
creator or provider of a tool (3.17), including anyone who modifies or customises a tool
Note 1 to entry: The person(s) or organization(s) responsible for the creation or maintenance of a tool or
customisation of a tool is the producer.
Note 2 to entry: Providing scripts to automate common functions modifies or customises a tool.
3.14
requirements
statement which translates or expresses a need and its associated constraints and conditions
Note 1 to entry: Requirements exist at different tiers and express the need in high-level form (e.g. software
component requirement).
[SOURCE: ISO/IEC IEEE 29148:2011, 4.1.17]
3.15
requirements analysis
process (3.12) through which understanding and prioritisation of the requirements (3.14) is achieved
3.16
requirements capture
process (3.12) through which the requirements (3.14) for a process are discovered, reviewed, articulated,
and documented
3.17
tool
software, hardware, or firmware used in a process (3.12)
3.18
validation
confirmation (3.4), through the provision of objective evidence, that the requirements (3.14) for a specific
intended use or application have been fulfilled
Note 1 to entry: Validation is carried out on a process (3.12) to ensure that it is fit for purpose, i.e. to ensure that
the process, as implemented, produces expected results in a consistent, repeatable, and reproducible manner.
[SOURCE: ISO/IEC 27004:2009, 3.17, Modified – Note 1 to entry has been added]
3.19
validation set
series of objective tests with clearly defined goals, inputs, and outputs, directly related to the agreed
requirements (3.14) for the process (3.12) under validation (3.18)
3.20
verification
confirmation (3.4), through the provision of objective evidence, that specified requirements have been
fulfilled
Note 1 to entry: Verification only provides assurance that a product conforms to its specification.
[SOURCE: ISO/IEC 27004:2009, 3.18, Modified – Original note was removed, Note 1 to entry has been
added]
© ISO/IEC 2015 – All rights reserved 3
3.21
verification function
function which is used to verify that two sets of data are identical
[SOURCE: ISO/IEC 27037:2012, 3.25, Modified – Notes were removed]
3.22
white box testing
testing which includes inspection of the implementation detail
3.23
work instruction
detailed description of how to perform and record a process (3.12)
[SOURCE: ISO/TR 10013:2001, 3.1, Modified - changed from plural to singular, task changed to process]
4 Symbols and abbreviated terms
ATA AT Attachment
SATA Serial ATA
USB Universal Serial Bus
5 Method development and assurance
5.1 Overview
Assurance of suitability and adequacy of incident investigation methods can be required in order
to demonstrate clearly that the investigator used methods which were fit for the purpose(s) of the
investigation and used methods which were not subject to unacceptable errors or uncertainty. Digital
evidence resulting from the application of unassured methods can be considered inherently flawed and
subject to challenge which can result in it being rendered useless for the purposes of the investigation.
This standard presents an assurance model which includes all stages of development of the activities
which make up an investigation, as described in ISO/IEC 27042:2015, from initial specification through
to deployment and maintenance.
5.2 General principles
Assuring suitability and adequacy of incident investigation methods should follow a suitable model,
such as the Plan-Do-Check-Act model used in ISO/IEC 9001:2000, in order to ensure that all processes
are subject to review at least as often as they are used.
5.3 General development and deployment model
Prior to a process being deployed for use in investigations, it should undergo a proper development
process in order to ensure that it is fit for purpose. Figure 2 shows typical stages in this process, which
are:
— Requirements capture and analysis
— Process design
— Process implementation
— Process verification (optional and non-essential)
— Process validation
4 © ISO/IEC 2015 – All rights reserved
— Confirmation
— Deployment
— Review and maintenance
Each of these stages is discussed in more detail below.
5.5
5.12
5.11
5.6
5.10
5.7
5.9
5.8
Figure 2 — Development and deployment process, including assurance stages
5.4 Assurance stages
Assurance should be included in the development model, above, in the following key assurance stages:
— Requirements capture and analysis
— Process validation
— Confirmation
— Review and maintenance
NOTE Further guidance on the conduct of these stages is given in the description of assurance models in
Clause 5.
© ISO/IEC 2015 – All rights reserved 5
5.5 Requirements capture and analysis
5.5.1 General principles of requirements
Prior to designing a process for use in an examination, a proper set of requirements should be produced,
accepted by the client and recorded in accordance with good practice. This set of requirements should be
derived from the requirements identified for the complete investigation and may include both functional
and non-functional requirements.
Each requirement defines an essential capability, characteristic or quality factor. Each individual
requirement statement should be necessary, implementation-free (i.e. it states only what is required,
not how the requirement should be met), unambiguous, complete, singular and consistent with the
remainder of the requirements in the set.
Requirements vary in intent and in the kinds of properties they represent. They can be grouped together
into similar types to aid in analysis and verification. Examples of types of requirements include:
— Functional – describe the functions or tasks to be performed and will include such considerations
as expected inputs and outputs;
— Performance – defines the extent, how well, and under what conditions a function or task is to be
performed;
— Interface – defines how the solution interacts with external systems, or how elements within the
solution (including human elements) interact with each other;
— Process – include compliance with local laws and processes or administrative requirements;
— Non-functional – define how a solution is supposed to be, including quality requirements such as
portability, reliability, maintainability and security, or human factors requirements such as safety,
efficiency or health and wellbeing.
In addition to all essential requirements, the lists of requirements produced should also include clear
definitions of the boundaries of operation associated with the anticipated potential digital evidence
and related investigative processes (e.g. maximum file sizes, maximum and minimum number of input
values).
A new list of requirements may need to be formulated for each investigation undertaken to ensure the
examination correctly fulfils the specific case requirements. Using a monolithic approach to the design
would require a significant validation overhead and so the user should where practically possible select
predefined atomic stages which are compatible with dynamic user definable input parameters.
In that way the unique changes to the requirements will typically be limited to the specific case
input parameters, and so the case specific validation would predominantly be limited to the specific
parameters supplied to the case under investigation, and not the underlying function or process which
should have been designed at the readiness phase.
EXAMPLE While specific keyword searches will be directly dependent on the case being investigated the
keyword filter process should, if designed correctly, be an atomic process which is independent of the keywords
used. The area which requires unique case specific validation be the definition of the correctness of the keyword[s]
applied (i.e. the undefined uncertainty error will be in the user’s design of the specific search terms used, for
instance only searching for “Joe Blogs” would miss references to “Joe Bloggs”, “Mr Blogs”, “J. Blogs”, “Joe”, “Joey”,
etc.).
The incident under investigation should be clearly identified and defined, including limitations to the
scope of the investigation. Sources of potential digital evidence and questions to be answered should be
identified. Sources of risk and their potential effects on the investigation, personnel and systems should
also be identified.
6 © ISO/IEC 2015 – All rights reserved
Once the requirements for the investigation have been identified, the investigative team should then
develop requirements for the examinations, analyses and processes which will make up the investigation
(see ISO/IEC 27042:2015).
5.5.2 Functional Requirements
Functional requirements are those stemming directly from investigative needs and which are expected
by the users of the process. They do not define how the process should operate but will include such
considerations as expected inputs and outputs. All functional requirements should be satisfied by the
investigation.
EXAMPLE The need to process a particular type of filesystem is a functional requirement as it is derived
directly from a source of potential digital evidence.
5.5.3 Verification of requirements
Undertaking an exercise to verify the requirements will ensure that the specified requirements are well
formed and that the needs of the investigative method have been adequately expressed. It involves an
analysis of the recorded requirements to identify problems such as conflicting, missing, incomplete,
ambiguous, inconsistent or incongruous requirements. Any identified problems should be resolved
before moving on to subsequent assurance stages.
5.6 Process Design
5.6.1 Overview
The design of a process should take account of all requirements identified as a result of the requirement
capture and analysis stages. It should give detail of how the method will be implemented, taking account
of accepted non-functional requirements and is the point at which tool selection should be carried out.
Design need not specify the exact detail of each element of the process, but should clearly identify the
flow of activity and evidential material from one step to the next.
5.6.2 Tool Selection
During the design phase, any tools which may participate in the process should be identified and their
role(s) in the resulting process identified. Where several tools can perform the same function in the
process, it may be useful to identify some or all of these tools in order to cope with variation in operating
environments (e.g. write blockers may offer different interfaces such as ATA, SATA, USB etc.) Care should
be taken, however, to ensure that allowing for variable requirements in this way does not adversely
affect the atomic nature of the process.
The documented process should define the group of tools which should be considered for use, along with
the identified and, where possible, quantified risk to specific atomic functions of each of the tools listed.
5.6.3 Uncertainty and risk evaluation
All tools, be they hardware or software based, will be prone to a level of error. This is an unavoidable
8)
reality which is caused by the fact that they are physically manufactured components, designed and
implemented to within a predefined tolerance of an ideal which can never be guaranteed to be 100 %
perfect. The error may range from relatively high to insignificantly minute, but either way it will exist
and can never be completely eliminated, only controlled and accounted for.
The investigator’s familiarity with the proposed tool or process should also be taken into account, as the
less familiar a user is with a tool or process, the greater the chance that additional uncontrolled errors
will occur. Effective training and routine proficiency testing are widely accepted techniques for helping
to minimize this specific type of error.
8) Software resides on a physical computer and so is affected by both hardware and software based errors.
© ISO/IEC 2015 – All rights reserved 7
These errors are collectively known as the uncertainty characteristics of each element or component
of a process, and can be, in simple terms, characterized as the strengths or weaknesses of the process.
The uncertainty characteristics will typically be additive in nature in a linear system, such as the model
described, and so will normally increase proportionally in line with the number of processes used.
To compensate, robust proportional overlapping processes should be designed to ensure they strengthen
the provenance of all the digital evidence found.
Before using a preferred tool or method to conduct an investigation the investigators should consider the
likely effects of all the weaknesses of the complete process sequence selected. A formal understanding of
the weaknesses of a process enables these errors to be effectively controlled through the use of correct
process selection and robust documented risk analysis or assessments.
The use of validated atomic elements within a process sequence can also be a significant aid in helping
to simplify the understanding and controlling these uncertainties, and is the primary reason why it is
central to assurance methods detailed in this document.
Finally, it should also be understood that even though a specific process may exhibit unknown or high
weakness it does not necessarily exclude it from consideration as appropriate. Indeed in some cases,
where it is the only process available to complete a required task it will likely be considered invaluable.
5.7 Process Implementation
5.7.1 Overview
Once the design has been completed, it should be implemented in the form of a documented detailed work
instruction which gives step by step instructions for the correct operation of each step of the process.
During this stage, final decisions about tool selection (e.g. choosing between alternative versions of the
same tool type) may be taken in order to improve the process.
5.7.2 Tool choice — guidance for deployment
Where the design of the process includes a list of tools which may be used to perform the same, or
similar, functions, the work instruction should provide guidance (see also 5.6.2) on how the investigator
should choose the appropriate tool for the conditions encountered during the examination. Care should
be taken, however, to ensure that allowing for variation, in this way, does not adversely affect the atomic
nature of the process.
Maintenance of a risk register, which includes assessments of risk and uncertainty for available tools, can
assist with tool choice. A tool can start with a blank entry in this register, but this should be considered
as a risk as it is likely to indicate that the tool is new and has not yet been evaluated in any detail.
A tool which is not the most suitable for the particular circumstance might still be chosen for use as long
as its evaluation and defined process usage is clearly defined along with its associated risks.
NOTE A tool may be chosen because it is the best available from a set of generally poor solutions, or because
it is the only tool available which can produce any form of usable result.
5.8 Process Verification
5.8.1 General principles of verification
Verification provides a level of assurance that a process or tool conforms to its specification. This does
not guarantee that it will operate in the desired way in the context of a complete investigation or process.
Evidence of verification against requirements which are similar to those for the intended use should be
treated as an initial indicator that the tool or process may be suitable for deployment in the context of
an investigation, but not a complete assurance that it will satisfy the requirements for the intended use.
Verification should be considered an optional, but potentially useful, part of assurance.
8 © ISO/IEC 2015 – All rights reserved
5.8.2 Verification of processes
Following development of the work instruction it should be compared with the design and evidence
produced, to show how the work instruction complies with the design. The design may be amended
to reflect implementational changes made during production of the work instruction (e.g. a result of
unexpected or new tool behaviours). Verification will usually be carried out using “whi
...
NORME ISO/IEC
INTERNATIONALE 27041
Première édition
2015-06-15
Technologies de l’information —
Techniques de sécurité —
Préconisations concernant la garantie
d’aptitude à l’emploi et d’adéquation
des méthodes d’investigation sur
incident
Information technology — Security techniques — Guidance on
assuring suitability and adequacy of incident investigative method
Numéro de référence
©
ISO/IEC 2015
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO/IEC 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Symboles et abréviations . 4
5 Développement de méthode et garantie d’adéquation . 4
5.1 Vue d’ensemble . 4
5.2 Principes généraux . 4
5.3 Développement général et modèle de déploiement . 5
5.4 Phases de garantie d’adéquation . 5
5.5 Collecte et analyse des exigences . 6
5.5.1 Principes généraux des exigences . 6
5.5.2 Exigences fonctionnelles . 7
5.5.3 Vérification des exigences . 7
5.6 Conception du processus . 7
5.6.1 Vue d’ensemble . 7
5.6.2 Sélection des outils . 7
5.6.3 Incertitude et évaluation du risque . 8
5.7 Mise en œuvre du processus . 8
5.7.1 Vue d’ensemble . 8
5.7.2 Choix final de l’outil — Préconisations concernant le déploiement . 9
5.8 Vérification du processus . 9
5.8.1 Principes généraux de la vérification . 9
5.8.2 Vérification des processus . 9
5.8.3 Vérification des outils . 9
5.9 Validation du processus .10
5.9.1 Principes généraux de la validation .10
5.9.2 Validation complète . .10
5.9.3 Validation standard .10
5.9.4 Processus entièrement validés .10
5.9.5 Validation non conforme .11
5.10 Confirmation .11
5.11 Déploiement .11
5.11.1 Choix final de l’outil .11
5.12 Étude et maintenance .11
6 Modèles de garantie d’adéquation.12
6.1 Vue d’ensemble .12
6.2 Garantie d’adéquation assurée en interne .12
6.3 Garantie d’adéquation assurée en externe .12
6.4 Garantie d’adéquation mixte .12
7 Production de preuve pour la garantie d’adéquation .12
7.1 Vue d’ensemble .12
7.2 Préparation antérieure à la validation.13
7.3 Production de la preuve de validation .13
7.4 Maintenance de la validation .13
7.5 Validation des examens .14
7.6 Validation des investigations .14
Annexe A (informative) Exemples .15
Bibliographie .19
© ISO/IEC 2015 – Tous droits réservés iii
Avant-propos
L’ISO (Organisation internationale de normalisation) et l’IEC (Commission électrotechnique
internationale) forment le système spécialisé de la normalisation mondiale. Les organismes
nationaux membres de l’ISO ou de l’IEC participent au développement de Normes internationales
par l’intermédiaire des comités techniques créés par l’organisation concernée afin de s’occuper des
domaines particuliers de l’activité technique. Les comités techniques de l’ISO et de l’IEC collaborent
dans des domaines d’intérêt commun. D’autres organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l’ISO et l’IEC, participent également aux travaux. Dans le domaine
des technologies de l’information, l’ISO et l’IEC ont créé un comité technique mixte, l’ISO/IEC JTC 1.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes de l’Organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC), voir le lien
suivant: www.iso.org/iso/fr/foreword.html.
Le comité responsable de ce document est l’ISO/IEC JTC 1, Technologies de l’information, sous-comité
SC 27, Techniques de sécurité.
iv © ISO/IEC 2015 – Tous droits réservés
Introduction
À propos de la présente Norme internationale
La présente Norme internationale vise à garantir que le processus d’investigation utilisé est approprié
à l’incident soumis à investigation et aux résultats exigés. Elle décrit également de manière abstraite
le concept de scission de processus en apparence complexes en une série d’éléments atomiques plus
petits, dont il convient qu’ils contribuent au développement de méthodes d’investigation simples mais
efficaces. Il convient qu’elle soit prise en compte par toute personne autorisant, gérant ou menant une
investigation, ou bien donnant des instructions concernant une investigation. Il convient de l’appliquer
avant toute investigation, dans le contexte des principes et processus (tels qu’ils sont définis dans
l’ISO/IEC 27043:2015) et d’une préparation et d’une planification appropriées (telles qu’elles sont
1)
définies dans l’ISO/IEC 27035-2 , afin de garantir l’aptitude à l’emploi des méthodes à appliquer dans
les processus d’investigation décrits dans l’ISO/IEC 27037:2012 et l’ISO/IEC 27042:2015.
Relation avec d’autres normes
La présente Norme internationale est destinée à compléter d’autres normes et documents donnant
des préconisations concernant l’investigation, et la préparation à l’investigation, sur des incidents
de sécurité de l’information. Elle ne constitue pas un guide exhaustif, mais édicte certains principes
fondamentaux visant à garantir que les outils, les techniques et les méthodes soient choisis de manière
appropriée et que leur adéquation avec l’application visée puisse être démontrée, le cas échéant.
La présente Norme internationale vise également à informer les décideurs devant déterminer la fiabilité
des preuves numériques qui leur sont soumises. Elle s’applique aux organismes devant protéger,
analyser et présenter des preuves numériques éventuelles. Elle est pertinente dans le contexte des
organismes en charge de l’établissement de politiques, qui créent et évaluent des modes opératoires en
rapport avec les preuves numériques, souvent dans le cadre d’un ensemble plus vaste de preuves.
La présente Norme internationale décrit une partie d’un processus d’investigation complet, portant
sans s’y limiter sur les thématiques suivantes:
— gestion des incidents, comprenant la préparation et la planification des investigations;
— traitement des preuves numériques;
— utilisation de l’expurgation et problèmes en découlant;
— systèmes de prévention et de détection des intrusions, comprenant les informations pouvant être
obtenues à partir de ces systèmes;
— sécurité du stockage, comprenant le nettoyage du stockage;
— vérification de l’adéquation avec l’application visée des méthodes d’investigation;
— analyse et interprétation des preuves numériques;
— connaissance des principes et processus liés à l’investigation des preuves numériques;
— gestion des événements d’incident de sécurité, comprenant l’établissement de preuve à partir de
systèmes impliqués dans la gestion des événements d’incident de sécurité;
— relation entre la découverte électronique et les autres méthodes d’investigation, et utilisation des
techniques de découverte électronique dans d’autres investigations;
— gouvernance des investigations, comprenant les investigations forensiques.
Ces thématiques sont couvertes partiellement dans les normes ISO/IEC suivantes:
— ISO/IEC 27037:2012;
1) Publication en attente.
© ISO/IEC 2015 – Tous droits réservés v
La présente Norme internationale décrit les moyens par lesquels les personnes impliquées dans les
premières phases d’une investigation, comprenant la réponse initiale, peuvent s’assurer que des preuves
numériques potentielles suffisantes sont recueillies pour permettre de poursuivre l’investigation de
manière appropriée.
— ISO/IEC 27038:2014;
Certains documents peuvent contenir des informations dont il ne faut pas qu’elles soient divulguées
auprès de certaines communautés. Des documents modifiés peuvent être diffusés auprès de ces
communautés, après un traitement approprié du document d’origine. Le processus consistant à
supprimer les informations à ne pas divulguer est intitulé l’«expurgation».
L’expurgation numérique des documents est un domaine relativement récent des pratiques de
gestion documentaire, qui soulève des problèmes spécifiques et pose des risques potentiels. Lors
de l’expurgation de documents numériques, il faut que les informations supprimées ne soient pas
récupérables. Dès lors, il est nécessaire de prendre des précautions pour que les informations expurgées
soient supprimées définitivement du document numérique (par exemple il ne faut pas qu’elles soient
simplement masquées dans des parties non affichables du document).
L’ISO/IEC 27038:2014 spécifie les méthodes d’expurgation numérique de documents numériques. Elle
spécifie également les exigences concernant les logiciels utilisables pour l’expurgation.
— ISO/IEC 27040:2015;
La présente Norme internationale donne des préconisations techniques détaillées concernant la manière
dont les organismes peuvent définir un niveau approprié d’atténuation du risque grâce à l’emploi d’une
approche reconnue et cohérente de la planification, la conception, la documentation et la mise en œuvre
de la sécurité de stockage des données. La sécurité du stockage s’applique à la protection (la sécurité)
des informations là où elles sont stockées et à la sécurité des informations transférées au moyen des
liaisons de communication associées au stockage. La sécurité du stockage comprend la sécurité des
dispositifs et des supports, la sécurité des activités de management associées aux dispositifs et aux
supports, la sécurité des applications et des services et la sécurité relative aux utilisateurs finaux
pendant la durée de vie de leurs dispositifs et supports et après la fin de leur utilisation.
Les mécanismes de sécurité tels que le chiffrement et le nettoyage peuvent affecter la capacité
d’investigation d’une personne en mettant en place des mécanismes d’obfuscation. Ils doivent être
pris en compte en amont et au cours d’une investigation. Ils peuvent également être importants pour
s’assurer que le stockage des matériaux probatoires, au cours et en aval d’une investigation, soit préparé
et sécurisé de manière adéquate.
— ISO/IEC 27042:2015;
La présente Norme internationale décrit les modes de conception et de mise en œuvre des méthodes et
processus à utiliser au cours d’une investigation, afin de permettre une évaluation correcte des preuves
numériques éventuelles, l’interprétation des preuves numériques et la consignation pertinente des
découvertes.
— ISO/IEC 27043:2015;
La présente Norme internationale définit les grands principes et processus communs sous-jacents à
une investigation sur incident, et fournit un modèle cadre pour toutes les phases des investigations.
Les projets ISO/IEC suivants couvrent également en partie les thématiques identifiées ci-dessus et
peuvent conduire à la publication de normes pertinentes, suite à la publication de la présente Norme
internationale.
2)
— ISO/IEC 27035 (toutes les parties) ;
2) Publication en attente.
vi © ISO/IEC 2015 – Tous droits réservés
Cette norme en trois parties fournit aux organismes une approche structurée et planifiée de la gestion
des incidents de sécurité. Elle se compose des parties suivantes.
3)
— ISO/IEC 27035-1 ;
Cette partie présente les concepts de base et les phases de la gestion des incidents de sécurité de
l’information. Elle combine ces concepts à des principes selon une approche structurée de détection,
consignation, évaluation, réponse et application des enseignements tirés.
4)
— ISO/IEC 27035-2 ;
Cette partie présente les concepts à planifier et à préparer dans le cadre de la réponse aux incidents.
Ces concepts, comprenant la politique et le plan de gestion des incidents, la constitution de l’équipe de
réponse aux incidents, et les réunions d’information et la formation de sensibilisation, sont basés sur
5)
la phase de planification et de préparation du modèle présenté dans l’ISO/IEC 27035-1 . Cette partie
couvre également la phase du modèle intitulée «Enseignements tirés».
6)
— ISO/IEC 27035-3 ;
Cette partie couvre les responsabilités du personnel et les activités pratiques de réponse aux incidents
pour l’ensemble de l’organisme. Une attention particulière est accordée aux activités de l’équipe de
réponse aux incidents, comprenant les activités de surveillance, de détection, d’analyse et de réponse
menées sur les données recueillies ou les événements de sécurité.
7)
— ISO/IEC 27050 (toutes les parties) ;
Ce projet couvre les activités liées à la découverte électronique, comprenant sans s’y limiter
l’identification, la préservation, la collecte, le traitement, la revue, l’analyse et la production de stockage
électronique d’informations (ESI). Il fournit en outre des préconisations concernant les mesures, allant
de la création initiale d’ESI à leur élimination finale, qu’un organisme peut prendre pour atténuer les
risques et réduire les dépenses, s’il s’avère que la découverte électronique devient problématique. Il
concerne à la fois les membres du personnel associés à des fonctions techniques et non techniques,
impliqués dans tout ou partie des activités de découverte électronique. Il est important de noter que
ces préconisations ne se destinent pas à contredire ou se substituer aux législations et réglementations
locales.
La découverte électronique constitue souvent un vecteur pour les investigations, ainsi que les activités
d’acquisition et de traitement de preuves. En outre, la sensibilité et la criticité des données nécessitent
parfois des protections telles que la sécurité du stockage, pour se prémunir contre les violations de
données.
— ISO/IEC 30121:2015;
La présente Norme internationale fournit un cadre pour les organes de gouvernance des organismes
(comprenant les propriétaires, les membres du conseil d’administration, les directeurs, les partenaires,
les cadres dirigeants ou des fonctions similaires), sur la meilleure façon de préparer un organisme
aux investigations numériques avant leur occurrence. La présente Norme internationale s’applique au
développement de processus (et de décisions) stratégiques concernant la conservation, la disponibilité,
l’accès et l’efficience économique de la divulgation de preuves numériques. Elle s’applique aux organismes
de tous types et de toutes tailles. Elle concerne la préparation stratégique avisée d’un organisme à
l’investigation numérique. La préparation à l’approche forensique garantit qu’un organisme a engagé
une préparation stratégique appropriée et pertinente pour supporter des événements potentiels de
nature probatoire. Des actions peuvent se produire suite à d’inévitables violations de sécurité, fraudes
3) Publication en attente.
4) Publication en attente.
5) Publication en attente.
6) Publication en attente.
7) Nouveau projet.
© ISO/IEC 2015 – Tous droits réservés vii
et déclarations de réputation. Dans chaque situation, les technologies de l’information (TI) doivent être
déployées de manière stratégique afin d’optimiser la disponibilité des preuves, leur accessibilité et leur
efficience économique.
La Figure 1 représente les activités types liées à un incident et à l’investigation s’y rapportant. Les
références représentées dans la figure (par exemple 27037) désignent les Normes internationales
répertoriées ci-dessus; les barres grisées représentent les classes/activités auxquelles chacune
d’elles est la plus susceptible d’être directement applicable ou sur lesquelles chacune d’elles exerce
une certaine influence sur le processus d’investigation (par exemple en stipulant une politique ou en
instaurant des contraintes). Il convient cependant qu’elles soient toutes consultées en amont et au cours
des phases de planification et de préparation. Les classes du processus qui sont représentées font l’objet
d’une définition complète dans cette Norme internationale et les activités identifiées correspondent à
celles évoquées plus en détail dans l’ISO/IEC 27035-2, l’ISO/IEC 27037:2012 et l’ISO/IEC 27042:2015.
viii © ISO/IEC 2015 – Tous droits réservés
Figure 1 — Applicabilité des normes aux activités et classes des processus d’investigation
© ISO/IEC 2015 – Tous droits réservés ix
NORME INTERNATIONALE ISO/IEC 27041:2015(F)
Technologies de l’information — Techniques de sécurité —
Préconisations concernant la garantie d’aptitude à l’emploi
et d’adéquation des méthodes d’investigation sur incident
1 Domaine d’application
La présente Norme internationale fournit des préconisations concernant les mécanismes visant
à garantir que les méthodes et processus utilisés dans l’investigation des incidents de sécurité de
l’information sont «en adéquation avec l’application visée». Elle englobe les pratiques d’excellence sur
la définition des exigences, la description des méthodes et l’attestation que les mises en œuvre des
méthodes satisfont aux exigences. Elle prend en compte les modalités d’utilisation des essais menés par
le fournisseur et les tierces parties pour contribuer à ce processus de garantie d’adéquation.
Le présent document vise à:
— fournir des préconisations concernant la collecte et l’analyse des exigences fonctionnelles et non
fonctionnelles liées à une investigation sur un incident de sécurité de l’information (IS);
— fournir des préconisations concernant l’usage de la validation comme une garantie d’aptitude à
l’emploi des processus sollicités par l’investigation;
— fournir des préconisations concernant l’évaluation des niveaux de validation requis et les preuves
exigées sur un exercice de validation;
— fournir des préconisations concernant l’intégration des essais et documentations externes au
processus de validation.
2 Références normatives
Les documents ci-après, dans leur intégralité ou non, sont des références normatives indispensables à
l’application du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO/IEC 27000:2013, Technologies de l’information — Techniques de sécurité — Systèmes de management
de la sécurité de l’information — Vue d’ensemble et vocabulaire
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l’ISO/IEC 27000:2013 ainsi
que les suivants s’appliquent.
3.1
atomique
qui assure une seule fonction uniquement
Note 1 à l’article: Une méthode (3.11) de récupération de tous les fichiers actifs à partir d’un périphérique peut être
atomique si elle s’appuie uniquement sur les métadonnées du système de fichiers. Une méthode de récupération
de tous les fichiers supprimés a peu de chances d’être atomique, car elle nécessite des sous-méthodes pour
identifier et extraire des structures de fichier spécifiques à partir des données figurant sur le périphérique de
stockage, en se basant sur l’identification du contenu des fichiers (par exemple .jpg, .png, .odt, XML, etc.).
3.2
essai à la boîte noire
étude d’un processus consistant à l’utiliser pour traiter des intrants connus, et à comparer les résultats
aux extrants attendus, qui reflètent les exigences du processus
3.3
client
personne ou organisme pour le compte duquel l’investigation doit être menée
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.2]
3.4
confirmation
évaluation formelle selon des preuves objectives existantes qu’un processus est adapté (ou reste
adapté) à une application spécifique
3.5
notes simultanées
consignation simultanée
consignation par écrit des actions et décisions prises, intervenant en même temps que ces actions et
décisions ou suivant leur occurrence, dès lors que cela est possible dans la pratique
Note 1 à l’article: De nombreuses juridictions exigent que les notes simultanées soient écrites à la main, à
l’encre non effaçable et dans un carnet doté d’un système de scellé, afin de mieux lutter contre les problèmes
d’authenticité et d’admissibilité.
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.4]
3.6
examen
application d’un ensemble de processus visant à identifier et à extraire des preuves numériques
éventuelles pertinentes à partir d’une ou de plusieurs sources
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.7]
3.7
investigation
application d’examens (3.6), suivis d’analyses et d’interprétations visant à mieux comprendre un
incident
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.10]
3.8
chargé d’investigation
personne dirigeant l’investigation au niveau stratégique
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.11]
3.9
équipe d’investigation
toutes les personnes directement impliquées dans l’organisation de l’investigation
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.12]
3.10
investigateur
membre de l’équipe d’investigation (3.9), comprenant le chargé d’investigation (3.8)
[SOURCE: ISO/IEC 27042:2015, paragraphe 3.13]
2 © ISO/IEC 2015 – Tous droits réservés
3.11
méthode
définition d’une opération pouvant être utilisée pour générer des données ou pour dégager des
informations, partant d’intrants spécifiés pour obtenir des extrants
Note 1 à l’article: Il convient dans l’idéal qu’une méthode (3.11) soit atomique (3.1) (c’est-à-dire qu’il convient
qu’elle n’assure pas plus d’une fonction) afin de permettre la réutilisation des méthodes et des processus (3.12) en
découlant, et de réduire le travail requis pour la validation des processus.
3.12
processus
mise en œuvre d’une méthode (3.11) au niveau opérationnel
3.13
fabricant
créateur ou fournisseur d’un outil (3.17), comprenant toute personne qui modifie ou personnalise un outil
Note 1 à l’article: Le fabricant englobe la ou les personnes ou le ou les organismes chargés de la création, de la
maintenance ou de la personnalisation d’un outil.
Note 2 à l’article: La mise à disposition de scripts visant à automatiser des fonctions communes correspond à une
modification ou une personnalisation d’outil.
3.14
exigences
déclaration traduisant ou exprimant un besoin et ses contraintes et conditions associées
Note 1 à l’article: Les exigences correspondent à différents niveaux mais expriment le besoin au niveau le plus
élevé (par exemple exigence relative aux composants logiciels).
[SOURCE: ISO/IEC IEEE 29148:2011, paragraphe 4.1.17]
3.15
analyse des exigences
processus (3.12) permettant la compréhension et la priorisation des exigences (3.14)
3.16
collecte des exigences
processus (3.12) permettant la découverte, l’étude, la mise en corrélation et la documentation des
exigences (3.14) liées à un processus
3.17
outil
logiciel, matériel ou microprogramme utilisé dans un processus (3.12)
3.18
validation
confirmation (3.4), par la fourniture de preuves objectives, que les exigences (3.14) relatives à une
utilisation prévue ou une application prévue ont été satisfaites
Note 1 à l’article: La validation est effectuée sur un processus (3.12) afin de garantir l’adéquation de celui-ci à
l’application visée, c’est-à-dire pour s’assurer que le processus, tel qu’il est mis en œuvre, produit les résultats
attendus de manière cohérente, répétable et reproductible.
[SOURCE: ISO/IEC 27004:2009, paragraphe 3.17, modifié — La note 1 à l’article a été ajoutée]
3.19
ensemble de validation
série d’essais objectifs comportant des objectifs, intrants et extrants clairement définis, directement
associés aux exigences (3.14) convenues pour le processus (3.12) soumis à validation (3.18)
© ISO/IEC 2015 – Tous droits réservés 3
3.20
vérification
confirmation (3.4), par des preuves tangibles, que les exigences spécifiées ont été satisfaites
Note 1 à l’article: La vérification garantit uniquement la conformité d’un produit à sa spécification.
[SOURCE: ISO/IEC 27004:2009, paragraphe 3.18, modifié – La note d’origine a été supprimée, la note 1 à
l’article a été ajoutée]
3.21
fonction de vérification
fonction utilisée pour vérifier que deux ensembles de données sont identiques
[SOURCE: ISO/IEC 27037:2012, paragraphe 3.25, modifié – Les notes ont été supprimées]
3.22
essai à la boîte blanche
essai comprenant l’inspection du détail de la mise en œuvre
3.23
instruction de travail
description détaillée sur la manière de réaliser et d’enregistrer un processus (3.12)
[SOURCE: ISO/TR 10013:2001, paragraphe 3.1, modifié - adoption du singulier au lieu du pluriel, «tâche»
remplacé par «processus»]
4 Symboles et abréviations
ATA Connexion AT (Advanced Technology Attachment)
SATA Connexion ATA série (Serial ATA)
USB Bus série universel (Universal Serial Bus)
5 Développement de méthode et garantie d’adéquation
5.1 Vue d’ensemble
La garantie d’aptitude à l’emploi et d’adéquation des méthodes d’investigation sur incident peut
être exigée afin de démontrer clairement que l’investigateur a utilisé des méthodes qui étaient en
adéquation avec la ou les applications visées par l’investigation, et qu’il a utilisé des méthodes qui
n’étaient pas soumises à des erreurs ou incertitudes inacceptables. Les preuves numériques résultant
de l’application de méthodes non garanties peuvent être considérées comme étant intrinsèquement
défectueuses et pouvant être contestées, ce qui peut conduire à ce qu’elles deviennent inutiles dans le
cadre de l’investigation.
La présente norme présente un modèle de garantie d’adéquation qui inclut toutes les phases
de développement des activités constituant une investigation, telles qu’elles sont décrites dans
l’ISO/IEC 27042:2015, depuis la spécification initiale jusqu’au déploiement et la maintenance.
5.2 Principes généraux
Il convient que la garantie d’aptitude à l’emploi et d’adéquation des méthodes d’investigation sur
incident suive un modèle adapté, tel que le modèle PDCA (Plan-Do-Check-Act, Planifier-Réaliser-Vérifier-
Agir) utilisé dans l’ISO/IEC 9001:2000, afin de garantir que tous les processus soient soumis à l’étude au
moins à chacun de leur déploiement.
4 © ISO/IEC 2015 – Tous droits réservés
5.3 Développement général et modèle de déploiement
Avant qu’un processus ne soit déployé pour être utilisé dans des investigations, il convient qu’il passe
par un processus de développement adapté afin de garantir son adéquation avec l’application visée.
La Figure 2 représente les phases types de ce processus, à savoir:
— collecte et analyse des exigences;
— conception du processus;
— mise en œuvre du processus;
— vérification du processus (facultative et non essentielle);
— validation du processus;
— confirmation;
— déploiement;
— étude et maintenance.
Chacune de ces phases est présentée plus en détail ci-après.
Figure 2 — Processus de développement et de déploiement, comprenant les phases de garantie
d’adéquation
5.4 Phases de garantie d’adéquation
Il convient d’inclure la garantie d’adéquation dans le modèle de développement ci-dessus en y faisant
figurer les phases clés de garantie d’adéquation ci-après:
— collecte et analyse des exigences;
© ISO/IEC 2015 – Tous droits réservés 5
— validation du processus;
— confirmation;
— étude et maintenance.
NOTE La description des modèles de garantie d’adéquation dans l’Article 5 donne d’autres préconisations
concernant la réalisation de ces phases.
5.5 Collecte et analyse des exigences
5.5.1 Principes généraux des exigences
Avant de concevoir un processus à utiliser pour un examen, il convient de définir un ensemble approprié
d’exigences, qui aura été accepté par le client et consigné conformément aux bonnes pratiques. Il convient
que cet ensemble d’exigences provienne des exigences identifiées pour la totalité de l’investigation, et il
peut inclure tant des exigences fonctionnelles que non fonctionnelles.
Chaque exigence définit une capacité, une caractéristique ou un facteur de qualité essentiel. Il convient
que chaque déclaration d’exigence spécifique soit nécessaire, sans ambiguïté, complète, singulière,
cohérente avec le reste des exigences composant l’ensemble, et qu’elle n’aborde pas les questions de
mise en œuvre (c’est-à-dire qu’elle spécifie uniquement ce qui est exigé, et non la façon dont il convient
que l’exigence soit satisfaite).
Les exigences varient en termes d’intention et des types de propriétés qu’elles représentent. Elles
peuvent être regroupées par types afin de faciliter les phases d’analyse et de vérification. Exemples de
types d’exigences:
— exigence fonctionnelle – décrit les tâches ou fonctions à effectuer et inclut des considérations telles
que les intrants et extrants attendus;
— exigence de performance – définit l’étendue d’une tâche ou fonction, les conditions dans lesquelles
elle doit être effectuée et le degré de qualité selon lequel elle doit être effectuée;
— exigence d’interfaçage – définit le mode d’interaction de la solution avec des systèmes externes, ou
le mode d’interaction des éléments l’un avec l’autre au sein de la solution (comprenant des éléments
humains);
— exigence de processus – inclut la conformité aux législations et processus locaux, ou aux exigences
administratives;
— exigence non fonctionnelle – définit ce en quoi une solution est censée consister, comprenant des
exigences de qualité telles que la portabilité, la fiabilité, la maintenabilité et la sécurité, ou bien des
exigences liées aux facteurs humains telles que la sûreté, l’efficacité ou la santé et le bien-être.
Outre toutes les exigences essentielles, il convient que la liste des exigences établie stipule également
des définitions claires des limites de fonctionnement associées aux preuves numériques potentielles
attendues et les processus d’investigation associés (par exemple tailles de fichier maximales, nombre
minimal et nombre maximal de valeurs d’intrant).
Une nouvelle liste d’exigences peut devoir être établie pour chaque investigation menée, afin de s’assurer
que l’examen satisfait correctement aux exigences spécifiques du dossier. Comme l’application d’une
approche monolithique de la conception exigerait une tâche conséquente de validation, il convient,
lorsque cela est possible dans la pratique, que l’utilisateur sélectionne des phases atomiques prédéfinies,
qui soient compatibles avec les paramètres d’intrant dynamiques définissables par l’utilisateur.
Ainsi, les modifications spécifiques apportées aux exigences seront typiquement limitées aux
paramètres d’intrant propres à un dossier donné, et donc la validation spécifique dossier par dossier
serait principalement limitée aux paramètres spécifiques du dossier en cours d’investigation, et non
6 © ISO/IEC 2015 – Tous droits réservés
aux fonctions ou processus sous-jacents dont il convient qu’ils aient été conçus lors de la phase de
préparation.
EXEMPLE Si les recherches par mots-clés spécifiques dépendent directement du dossier en cours
d’investigation, il convient que le processus de filtrage des mots-clés, s’il a été correctement conçu, soit un
processus atomique, indépendant des mots-clés utilisés. Le domaine qui exige une validation spécifique dossier
par dossier serait la définition de la justesse du ou des mots-clés appliqués (c’est-à-dire que l’erreur d’incertitude
indéfinie réside dans le choix par l’utilisateur de termes de recherche spécifiques, qui va par exemple rechercher
uniquement la chaîne «Joe Blogs», et ainsi passer à côté de références à «Joe Bloggs», «Mr Blogs», «J. Blogs», «Joe»,
«Joey», etc.).
Il convient que l’incident en cours d’investigation soit clairement identifié et défini, ce qui comprend
des limitations sur le domaine d’application de l’investigation. Il convient d’identifier les sources des
preuves numériques potentielles et les questions auxquelles une réponse doit être apportée. Il convient
également d’identifier les sources de risque et leurs effets potentiels sur l’investigation, le personnel et
les systèmes.
Une fois que les exigences relatives à l’investigation ont été identifiées, il convient ensuite que l’équipe
d’investigation développe les exigences relatives aux examens, analyses et processus qui vont constituer
l’investigation (voir l’ISO/IEC 27042:2015).
5.5.2 Exigences fonctionnelles
Les exigences fonctionnelles sont celles qui découlent directement des besoins liés à l’investigation et
qui sont attendues par les utilisateurs du processus. Elles ne définissent pas la façon dont il convient
que le processus fonctionne, mais comprennent des considérations telles que les intrants et extrants
attendus. Il convient que l’investigation satisfasse à toutes les exigences fonctionnelles.
EXEMPLE Le besoin de traiter un type spécifique de système de fichiers constitue une exigence fonctionnelle,
car il découle directement d’une source de preuve numérique potentielle.
5.5.3 Vérification des exigences
Procéder à un exercice afin de vérifier les exigences permet de s’assurer que les exigences spécifiées
sont bien formulées et que les besoins liés à la méthode d’investigation ont été exprimés de manière
adéquate. Cela implique d’analyser les exigences consignées afin d’identifier des problèmes tels que des
exigences en conflit, manquantes, incomplètes, ambiguës, incohérentes ou incongrues. Il convient de
résoudre tous les problèmes identifiés avant de passer aux phases suivantes de garantie d’adéquation.
5.6 Conception du processus
5.6.1 Vue d’ensemble
Il convient que la conception d’un processus tienne compte de toutes les exigences identifiées lors des
phases de collecte et d’analyse des exigences. Il convient qu’elle détaille le mode de mise en œuvre de
la méthode, en tenant compte des exigences non fonctionnelles acceptées, et elle constitue le point à
partir duquel il convient de procéder à la sélection des outils. La conception peut ne pas spécifier le
détail précis de chaque élément du processus, mais il convient qu’elle identifie de manière claire le flux
d’activités et les matériaux probatoires entre les différentes étapes.
5.6.2 Sélection des outils
Lors de la phase de conception, il convient d’identifier tous les outils pouvant participer au processus, et
d’identifier leur(s) rôle(s) dans le processus en résultant. Lorsque plusieurs outils peuvent assurer une
même fonction au sein du processus, il peut s’avérer utile d’identifier tout ou partie de ces outils afin de
pouvoir gérer les variations au niveau de l’environnement d’exploitation (par exemple, les bloqueurs
d’écriture peuvent proposer différentes interfaces, telles qu’ATA, SATA, USB, etc.). Il convient cependant
de prendre des précautions pour s’assurer que dans ce contexte, l’autorisation d’exigences variables
n’influe pas de manière négative sur la nature atomique du processus.
© ISO/IEC 2015 – Tous droits réservés 7
Il convient que le processus documenté définisse le groupe d’o
...
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...