LM27032 FR Day4

© Professional Evaluation and Certification Board, 2021. Tous droits réservés.
Version3.0
Numéro de document: LCMD4V3.0
Les documents fournis aux participants sont strictement réservés à des fins de formation. Aucune partie de ces
documents ne peut être publiée, distribuée, affichée sur Internet ou sur un intranet, extraite ou reproduite sous
quelque forme ou par quelque moyen que ce soit, électronique ou mécanique, y compris par photocopie, sans
l’autorisation écrite préalable de PECB.
Licensed to PECB France ()

©Copyrighted material PECB®. Single user license only, copying and networking prohibited. Downloaded: 2021-09-23
1/146
2/146
3/146
Cette section fournit des informations qui aideront les participants à acquérir une connaissance globale en
matière de préparation des TIC pour la continuité d'activité, notamment ses principes, ses éléments et ses
phases.

4/146
5/146
ISO/IEC27031, article 1 Domaine d’application
Cette norme internationale décrit les notions et principes de la préparation des technologies de l’information et de
la communication (TIC) à la continuité d'activité et offre un cadre de méthodes et de processus pour définir et
préciser tous les aspects (critères de performance, conception et mise en œuvre), dans le but d’améliorer l’état de
préparation des TIC à la continuité d'activité. Elle s’applique à tout organisme (privé, gouvernemental et non
gouvernemental, quelle que soit sa taille) qui élabore son programme de préparation des TIC pour la continuité
d'activité (PTCA) et qui exige que ses services et infrastructures de TIC soient prêts à soutenir les activités
d’entreprise en cas de crise, d’événements ou incidents, et d’interruptions connexes, qui pourraient nuire à la
continuité (et à la sécurité) des fonctions d’entreprise critiques. Elle permet également à un organisme de mesurer
les paramètres de performance qui sont corrélés à sa PTCA d’une manière uniforme et reconnue.
Le domaine d’application de cette norme internationale englobe tous les événements et incidents, y compris en
matière de sécurité, qui pourraient avoir un impact sur l’infrastructure et les systèmes de TIC. Il comprend et
s’étend aux pratiques de gestion et de management des incidents de sécurité de l’information ainsi qu’à la
planification et aux services de préparation des TIC.

6/146
ISO 22301, article 3.3 Continuité d’activité
Capacité d’un organisme à poursuivre la livraison de produits et la fourniture de services dans des délais
acceptables à une capacité prédéfinie durant une perturbation
ISO 22301, article3.4Plan de continuité d’activité
Informations documentées servant de guide à un organisme pour répondre à une perturbation et reprendre,
rétablir et restaurer la livraison de produits et la fourniture de services en cohérence avec ses objectifs de
continuité d’activité

7/146
8/146
Les objectifs de continuité d'activité sont l'expression de la volonté de l'organisme d'accroître sa résilience et de
se conformer aux exigences de continuité d'activité. Il convient que l'organisme consulte d'abord les parties
intéressées avant de fixer des objectifs organisationnels.
Il convient que la direction de l'organisme valide et approuve les objectifs de continuité d'activité et les
documente de manière appropriée.

9/146
Lors de la détermination des objectifs de continuité d'activité, il convient que l'organisme prenne en considération
:
Incidents historiques
Risques courants et émergents
Tendances en matière de perturbations des activités
Coûts liés aux perturbations potentielles
Responsabilités (Liabilities)
Responsabilités sociales
Succès ou échec d'autres plans de continuité d'activité

10/146
ISO/IEC 27031, article5.1 Rôle des PTCA dans le management de la continuité d’activité
Le management de la continuité d'activité (MCA) est un processus de gestion holistique qui définit les impacts
potentiels menaçant la continuité des activités d’un organisme et qui offre un cadre pour renforcer la résilience et
la capacité d’intervenir efficacement afin de protéger les intérêts de l’organisme contre les perturbations.
Dans le cadre du processus de MCA, le PTCA fait référence à un système de gestion qui complète et soutient le
programme de MCA et/ou de SMSI d'un organisme, afin d'améliorer la préparation de l'organisme à :
a. Répondre à l'évolution constante de l'environnement des risques ;
b. Assurer la continuation des opérations commerciales critiques soutenues par les services TIC connexes ;
c. Être prêt à réagir avant qu'une interruption des services TIC ne se produise, en cas de détection d'un ou
d'une série d'événements connexes qui deviennent des incidents; et
d. Répondre et se remettre des incidents/catastrophes et des défaillances.

11/146
ISO/IEC 27031, article 5.2 Les principes de l'IRBC (suite)
L'IRBC est basé sur les principes clés suivants :
a. Prévention des incidents – La protection des services des TIC contre les menaces, comme les pannes
d’environnement et matérielles, les erreurs opérationnelles, les attaques malveillantes et les catastrophes
naturelles, est essentielle pour maintenir les degrés d’accessibilité souhaités des systèmes d’un organisme.
b. Détection d'incidents – La détection des incidents le plus tôt possible minimisera l’impact sur les services,
réduira l’effort de rétablissement et préservera la qualité du service.
c. Réponse – La réponse la plus appropriée à un incident permettra une récupération plus efficace et réduira
au minimum les temps d'arrêt. Une mauvaise réaction peut transformer un incident mineur en un incident
plus grave ;
d. Récupération – L'identification et la mise en œuvre de la stratégie de récupération appropriée garantira la
reprise des services dans les meilleurs délais et préservera l'intégrité des données. Comprendre les
priorités de reprise permet de rétablir les services les plus critiques en premier. Les services de nature
moins critique peuvent être rétablis plus tard ou, dans certains cas, pas du tout.
e. Amélioration – Les leçons tirées des incidents de petite et grande envergure devraient être documentées,
analysées et examinées. Comprendre ces leçons permettra à l’organisme de mieux se préparer, de
maîtriser et d’éviter les incidents et les perturbations.

12/146
ISO/IEC 27031, article 5.3 Les éléments de l'IRBC (suite)
Les éléments clés de la PTCA peuvent être résumés comme suit :
a. Personnel : les spécialistes possédant les compétences et les connaissances appropriées, et un personnel
de réserve compétent ;
b. Installations : l'environnement physique dans lequel les ressources TIC sont situées ;
c. Technologie :
1. Matériel (y compris les étagères, les serveurs, les matrices de stockage, les appareils à bande et les
fixations) ;
2. Réseau (y compris la connectivité des données et les services vocaux), les commutateurs et les
routeurs ; et
3. Logiciels, y compris le système d'exploitation et les logiciels d'application, les liens ou interfaces
entre les applications et les routines de traitement par lots ;
d. Données : données d'application, données vocales et autres types de données ;
e. Processus : y compris la documentation d'appui pour décrire la configuration des ressources TIC et
permettre le fonctionnement, la récupération et la maintenance efficaces des services TIC ; et
f. Fournisseurs : autres éléments des services de bout en bout où la fourniture de services TIC dépend d'un
fournisseur de services externe ou d'un autre organisme de la chaîne d'approvisionnement, par exemple un
fournisseur de données sur les marchés financiers, un opérateur de télécommunications ou un fournisseur
de services Internet.

13/146
Il convient que les organismes planifient, mettent en œuvre, maintiennent et améliorent continuellement les
processus nécessaires pour élaborer le plan de préparation des services TIC et assurer la continuité d'activité.
ISO/IEC 27031, Tableau 1 – Cycle Planifier-Faire-Vérifier-Agir dans la PTCA
Planifier : Définir la politique, les objectifs, les cibles, les processus et les procédures de la PTCA en
matière de management des risques et d'amélioration de la capacité des TIC à produire des résultats
conformément aux politiques et aux objectifs globaux de continuité d'activité d'un organisme.
Déployer : Mettre en œuvre et appliquer la politique, les contrôles, les processus et les procédures de la
PTCA.
Contrôler : Évaluer et, le cas échéant, mesurer les performances du processus par rapport à la politique,
aux objectifs et à l'expérience pratique de l'IRBC, et communiquer les résultats à la direction pour révision.
Agir : Prendre des mesures correctives et préventives, sur la base des résultats de la revue de direction,
afin de parvenir à une amélioration continue de la PTCA.

14/146
Exercice 13 : Préparation des technologies de la communication et de l'information dans la continuité
d’activité
Comment la préparation aux technologies de l'information et de la communication (TIC) dans la continuité
d'activité (IRBC) aiderait-elle ITELCO à prévenir, détecter et réagir à une perturbation et à restaurer ses services
TIC ?
Durée de l’exercice : 25 minutes

Commentaires : 20 minutes

15/146
Résumé de la section :
ISO/IEC 27031 fournit des concepts d'IRBC.
La PTCA complète le MCA dans la réalisation de ses objectifs.
La préparation des TIC en matière de continuité d'activité comprend cinq principes de base : la prévention
des incidents, la détection des incidents, la réponse, la récupération et l'amélioration.
Il convient d'établir la PTCA en utilisant le cycle PDCA.

16/146
La présente section fournit des informations qui aideront les participants à acquérir des connaissances sur le
processus de management des incidents de cybersécurité, y compris les phases de planification et de
préparation, de détection et de rapport, d'évaluation et de détection, de réponse et des enseignements tirés.

17/146
18/146
ISO/IEC27035-1, article1 Domaine d’application
Cette partie de la norme ISO/IEC 27035 est le fondement de cette norme internationale en plusieurs parties. Elle
présente les concepts de base et les phases de la gestion des incidents de sécurité de l’information et combine
ces concepts avec les principes dans une approche structurée pour détecter, déclarer, apprécier et répondre aux
incidents et appliquer les leçons apprises.
Les principes énoncés dans cette partie d’ISO/IEC27035 sont génériques et destinés à tous les organismes,
quels que soient leur type, leur taille ou leur nature. Les organismes peuvent ajuster les lignes directrices
d’ISO/IEC27035 en fonction du type, de la taille et de la nature des activités de la sécurité de l’information. Cette
partie d’ISO/IEC27035 s’applique également aux organismes externes qui fournissent des services de gestion
des incidents de sécurité de l’information.
ISO/IEC27035-1, article1 Domaine d’application
Cette seconde partie d’ISO/IEC27035 fournit les lignes directrices pour planifier et préparer la réponse aux
incidents. Les lignes directrices sont basées sur la phase « Planifier et préparer » et la phase « Leçons apprises »
du modèle « Phase de gestion des incidents de sécurité de l’information » présenté dans ISO/IEC27035-1.
Les principaux points de la phase «Planifier et préparer» sont les suivants
politique de gestion des incidents de sécurité de l’information et engagement de la direction;
politiques de sécurité de l’information, y compris celles relatives à la gestion des risques, mises à jour tant
pour l’entreprise que sur le plan du système, du service et du réseau;
plan de gestion des incidents de sécurité de l’information;
établissement d’une équipe de réponse aux incidents de sécurité (ERI);
établissement des relations et des liens avec des organismes internes et externes;
soutien technique et autres formes de soutien (y compris le soutien organisationnel et opérationnel);
activités d’information et de sensibilisation à la gestion des incidents de sécurité de l’information;
test du plan de gestion des incidents de sécurité de l’information.
Les principes énoncés dans cette partie d’ISO/IEC27035 sont génériques et destinés à tous les organismes,
quels que soient leur type, leur taille ou leur nature. Les organismes peuvent ajuster les lignes directrices
d’ISO/IEC27035 en fonction du type, de la taille et de la nature des activités de la sécurité de l’information.
19/146
NIST SP 800-61, Computer Security Incident Handling Guide, clause 1.2 Purpose and Scope
Cette publication vise à aider les organismes à atténuer les risques liés aux incidents de sécurité informatique en
fournissant des lignes directrices pratiques en matière de réponse aux incidents de manière efficace et efficiente.
Elle comprend des lignes directrices sur la mise en place d'un programme efficace de réponse aux incidents, mais
l'objectif principal du document est de détecter, d'analyser, de hiérarchiser et de traiter les incidents. Il est
recommandé aux organismes d'adapter les lignes directrices et les solutions préconisées pour répondre aux
exigences de leur mission et de leur sécurité.

20/146
Parmi les technologies les plus utilisées dans les centres des opérations de sécurité figurent les pare-feu, les
capteurs, les informations de sécurité et les systèmes de management des incidents. L'équipe SOC gère de
manière ininterrompue les menaces connues et existantes en établissant des règles, en identifiant les exceptions
et en déterminant les risques émergents.
Les centres des opérations de sécurité sont les plus populaires auprès des organismes axés sur la stratégie qui
font plus confiance à l'évaluation et à l'atténuation des menaces pour l'homme qu'à un scénario. Ainsi, le SOC
s'appuie fortement sur les connaissances des membres de l'équipe SOC.

21/146
ISO/IEC27035-2, article6.1 Généralités
L'objectif d'un plan de management des incidents de sécurité de l'information est de documenter les activités et
les procédures de traitement des événements, incidents et vulnérabilités de sécurité de l'information, et de leur
communication. Le plan découle et est basé sur la politique de management des incidents de sécurité de
l'information.
De manière générale, il convient que la documentation du plan englobe de nombreux documents, notamment les
formulaires, les procédures, les éléments organisationnels et les outils de soutien pour la détection et le
signalement des incidents de sécurité de l'information, l'évaluation et la prise de décisions afférentes, les
réponses à ces incidents et les leçons à en tirer.
Le plan peut comprendre un aperçu de haut niveau du flux de base des activités de management des incidents
afin de fournir une structure et des pointeurs vers les différents éléments détaillés du plan. Ces composantes
fourniront les instructions étape par étape que les responsables du management des incidents devront suivre en
utilisant des outils spécifiques, en suivant des flux de travail spécifiques ou en traitant des types d'incidents
spécifiques en fonction de la situation.
Le plan de management des incidents de sécurité de l'information entre en vigueur dès qu'un événement de
sécurité de l'information est détecté ou qu'une vulnérabilité de sécurité de l'information est signalée.

22/146
ISO/IEC27035-2, article6.1 Généralités (suite)
Il convient que tout organisme utilise le plan comme guide pour :
a. répondre aux événements liés à la sécurité de l'information ;
b. déterminer si les événements de sécurité de l'information deviennent des incidents de sécurité de
l'information ;
c. gérer les incidents de sécurité de l'information jusqu'à leur conclusion ;
d. répondre aux vulnérabilités de la sécurité de l'information ;
e. les exigences en matière de rapports ;
f. les exigences en matière de stockage des informations (y compris leur format) pendant tout le processus
de management des incidents ;
g. les règles et les circonstances dans lesquelles le partage d'informations avec des groupes ou organismes
internes et externes peut avoir lieu ;
h. l'identification des enseignements tirés et de toute amélioration nécessaire du plan et/ou de la sécurité en
général ;
i. apporter les améliorations identifiées.
Il convient que la planification et la préparation du plan de réponse aux incidents soient entreprises par le
propriétaire du processus, avec un objectif ou un ensemble d'objectifs clairs pour la réponse aux incidents dans
un cadre défini basé sur la politique de management des incidents de sécurité de l'information.

23/146
Un management efficace des incidents de cybersécurité implique tous les aspects de l'organisme et, pour être
efficace, il doit être adapté à l'organisme qui l'utilise. Toutefois, le management d'un incident de cybersécurité
dépend de l'ensemble des connaissances en matière de cybersécurité, de l'équipe de réponse aux incidents, de
l'évaluation des risques de cybersécurité, de la continuité d'activité, des outils forensiques, des approches
techniques, des lois, des règlements et des exigences contractuelles, du plan de communication et des sessions
de sensibilisation et de formation.
Selon le guide de planification de la cybersécurité, il convient d'envisager trois actions principales en cas
d'incident de violation, à savoir
Notification aux autorités répressives si nécessaire : Notification aux autorités répressives et aux autres
autorités gouvernementales dépend du type de violation et du type d'activité de l'organisme qui a subi la
violation.
Collaboration étroite avec les équipes techniques et de direction : Il convient que les équipes techniques et
de direction travaillent en étroite collaboration pour décider du plan d'endiguement. Ce plan doit donner la priorité
à la préservation de la confidentialité et de l'intégrité des données sensibles sans compromis.
Initiation de la récupération : Il est essentiel d'entamer la récupération et l'éradication après la violation. Elle
peut inclure le nettoyage de toute trace du code malveillant, la désactivation des privilèges d'accès, etc.
Source: Federal Communications Commission. Cyber Security Planning Guide. Createspace Independent Pub,
2014.

24/146
Les incidents de cybersécurité ne représentent qu'une petite partie des événements de cybersécurité.
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.1 Events and Incidents
Un événement désigne toute occurrence observable dans un système ou un réseau. Les événements
comprennent un utilisateur se connectant à un partage de fichiers, un serveur recevant une demande de page
Web, un utilisateur envoyant un e-mail, et un pare-feu bloquant une tentative de connexion. Les événements
indésirables sont des événements ayant une conséquence négative, tels que les défaillances du système, les
flots de paquets, l'utilisation non autorisée des privilèges de système, l'accès non autorisé à des données
sensibles et l'exécution de maliciels qui détruisent des données. Le présent guide ne porte que sur les
événements indésirables liés à la sécurité informatique, et non sur ceux causés par des catastrophes naturelles,
des pannes électriques, etc.
Un incident de sécurité informatique est une violation ou une menace imminente de violation des politiques de
sécurité informatique, des politiques d'utilisation acceptable ou des pratiques de sécurité standard. Voici quelques
exemples d'incidents :
Un agresseur ordonne à un botnet d'envoyer un grand nombre de demandes de connexion à un serveur
Web, ce qui provoque son blocage.
Les utilisateurs sont amenés à ouvrir un «rapport trimestriel» envoyé par e-mail qui est en fait un maliciel ;
l'exécution de l'outil a infecté leurs ordinateurs et établi des connexions avec un hôte externe.
Un agresseur obtient des données sensibles et menace de rendre les détails publics si l'organisme ne
verse pas une certaine somme d'argent.
Un utilisateur fournit ou expose des informations sensibles à d'autres personnes par le biais de services de
partage de fichiers peer-to-peer.

25/146
26/146
27/146
Bien que difficile à effectuer, la préparation est considérée comme la partie la plus importante du management
des incidents de cybersécurité. Seuls les organismes qui consacrent suffisamment de temps à la phase de
préparation peuvent réduire les répercussions négatives des incidents, se rétablir plus rapidement et, dans
certaines situations, devenir encore plus forts et mieux organisés après l'incident. Les incidents surviennent
généralement de manière inattendue ; ne pas y répondre efficacement aggrave presque toujours la situation.
C'est pourquoi les plans de réaction aux incidents doivent être testés régulièrement afin de s'assurer que la
mission du plan peut être accomplie en cas d'incident réel. Si, lors des essais, il est constaté que le plan établi
n'est pas aussi efficace et rapide à mener qu'il convient, un temps suffisant doit être alloué pour le modifier.
Il convient que les personnes concernées par la cybersécurité soient capables de détecter et de répondre à
différents types de menaces. Le meilleur moyen d'y parvenir est de documenter les procédures et de garantir la
formation et les essais. Pour disposer d'un processus de préparation efficace, assurez-vous que vos systèmes
fonctionnent comme prévu et que le personnel de votre organisme comprend ses rôles et responsabilités.

28/146
ISO/IEC 27035-1, article 5.2 Planifier et préparer
Un management efficace des incidents de cybersécurité exige une planification et une préparation appropriées.
Pour qu'un plan de gestion des incidents de sécurité de l'information soit mis en œuvre de manière efficace et
effective, un organisme devrait mener à bien un certain nombre d'activités préparatoires, à savoir :
a. formuler et produire une politique de gestion des incidents de sécurité de l'information et obtenir
l'engagement de la direction générale en faveur de cette politique ;
b. mettre à jour les politiques de sécurité de l’information, y compris celles relatives au management du
risque, tant pour l’entreprise que sur le plan du système, du service et du réseau;
c. définir et documenter un plan détaillé de gestion des incidents de sécurité de l'information, y compris les
sujets couvrant les communications et la divulgation d'informations ;
d. mettre en place l'IRT, avec un programme de formation approprié conçu, développé et fourni à son
personnel ;
e. établir et préserver des relations et des liens appropriés avec les organismes internes et externes qui sont
directement impliqués dans la gestion des événements, des incidents et des vulnérabilités en matière de
sécurité de l'information ;
f. établir, mettre en œuvre et faire fonctionner des mécanismes techniques, organisationnels et opérationnels
pour soutenir le plan de gestion des incidents de sécurité de l'information et les tâches de l'IRT. Développer
et déployer les systèmes d'information nécessaires pour soutenir l'IRT, y compris une base de données sur
la sécurité de l'information. Ces mécanismes et systèmes sont destinés à prévenir les incidents de sécurité
de l'information ou à réduire la probabilité qu'ils se produisent ;
g. concevoir et développer un programme de sensibilisation et de formation à la gestion des événements, des
incidents et des vulnérabilités en matière de sécurité de l'information ;
h. tester l'utilisation du plan de gestion des incidents de sécurité de l'information, de ses processus et de ses
procédures.
Une fois cette phase terminée, les organismes devraient être tout à fait prêts à gérer correctement les incidents
de sécurité de l'information. La norme ISO/IEC 27035-2 décrit chacune des activités énumérées ci-dessus, y
compris le contenu des documents de politique et de planification.

29/146
Il convient que la politique de management des incidents de cybersécurité fasse référence aux exigences
juridiques, réglementaires et contractuelles, car la compréhension des lois et règlements applicables est
essentielle pour disposer d'un processus efficace de management des incidents de cybersécurité. Certaines lois
et réglementations exigent que les incidents soient abordés et signalés dans un délai déterminé. D’un point de
vue contractuel, les organismes peuvent avoir l’obligation de signaler ou de traiter les incidents dans certains
délais dictés par les clients.
La politique de management des incidents de cybersécurité peut être rédigée sous forme de document séparé ou
être intégrée dans la politique de cybersécurité.

30/146
Le plan de management des incidents de cybersécurité est la pierre angulaire de la mise en œuvre du
management des incidents de cybersécurité. Il convient de l'élaborer en fonction de la mission, de la taille, de la
structure et des fonctions de l'organisme.
Il convient que tout plan de management des incidents de cybersécurité se fonde sur la politique de management
des incidents de cybersécurité, les lois et règlements en vigueur, les exigences contractuelles et toute autre
source faisant autorité.

31/146
Tout au long du cours, l’acronyme IRT sera utilisé pour désigner l’équipe de réponse aux incidents. Cependant, il
peut y avoir d’autres termes comme indiqué ci-dessous.
Il existe des distinctions entre «équipes de sécurité,» « CSIRT interne » et «CSIRT de coordination»:
Dans une équipe de sécurité, la responsabilité formelle du traitement des activités liées à l’incident a été
attribuée à tout groupe ou section de l’organisme. Aucune équipe de réponse aux incidents de
cybersécurité (CSIRT) n'est mise en place. Au lieu du CSIRT, le personnel disponible (généralement des
administrateurs système, réseau ou de sécurité) ou une filiale locale traite les événements de sécurité de
manière ad hoc et, en cas d’incident isolé, dans le cadre de leurs responsabilités générales ou de leurs
missions.
Dans un CSIRT interne, la responsabilité du traitement des incidents est généralement attribuée à un
groupe de personnes spécifiquement qualifiées.
Dans le modèle CSIRT de coordination, le CSIRT coordonne et facilite le traitement des incidents,
vulnérabilités et information globale dans une variété d’organismes externes et internes, qui peuvent
inclure d’autres CSIRT, des organismes de fournisseurs, des experts en sécurité, voire des organismes
d’application de la loi.
Source: West-Brown, Moira J., Don Stikvoort, Klaus-Peter Kossakowski, et al. Handbook for Computer Security
Incident Response Teams (CSIRTs). Pittsburgh: Carnegie Mellon Software Engineering Institute, 2003.
La taille de l’organisme dans son ensemble par rapport au programme de cybersécurité peut impliquer
que la mise sur pied d’un CSIRT constante n’est pas une proposition réaliste. Dans de tels cas, un
personnel spécifique pourrait être défini comme étant la première ligne de défense des événements de
cybersécurité. Ce noyau d'IRT devrait avoir accès à d'autres personnels et disciplines (informatique,
juridique, RH, opérations, relations publiques, etc.)
L'IRT doit également disposer d'une délégation de pouvoir de la part de l'encadrement supérieur afin de
pouvoir s'acquitter rapidement de ses responsabilités en cas d'incident grave de cybersécurité.

32/146
L'équipe de réponse aux incidents est chargée d'analyser les incidents, de déterminer leur impact et de restaurer
le service normal.
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.4.1 Team Models
Les structures possibles pour une équipe de réponse aux incidents sont les suivantes :
Équipe centrale de réponse aux incidents.
Équipe centrale de réponse aux incidents. Une seule équipe de réponse aux incidents gère les incidents
dans l'ensemble de l'organisme. Ce modèle est efficace pour les petits organismes et pour les organismes
ayant une diversité géographique minimale en termes de ressources informatiques.
Équipes de réponse aux incidents distribuées. L'organisme dispose de plusieurs équipes de réponse
aux incidents, chacune étant responsable d'un segment logique ou physique particulier de l'organisme. Ce
modèle est efficace pour les grands organismes (par exemple, une équipe par département) et pour les
organismes disposant d'importantes ressources informatiques dans des lieux éloignés (par exemple, une
équipe par région géographique, une équipe par grande installation). Cependant, les équipes doivent faire
partie d'une seule entité coordonnée afin que le processus de réponse aux incidents soit cohérent dans
tout l'organisme et que les informations soient partagées entre les équipes. Ceci est particulièrement
important car plusieurs équipes peuvent voir les composantes d'un même incident ou peuvent traiter des
incidents similaires.
Équipe de coordination. Une équipe de réponse aux incidents fournit des conseils à d'autres équipes
sans avoir d'autorité sur ces dernières – par exemple, une équipe à l'échelle d'un département peut aider
les équipes de chaque organisme. Ce modèle peut être considéré comme un CSIRT pour les CSIRT.
Comme le présent document est axé sur les CSIRT centrales et distribuées, le modèle d'équipe de
coordination n'est pas abordé en détail dans ce document.

33/146
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.4.1 Team Models
Les équipes de réponse aux incidents peuvent également utiliser l'un des trois modèles de gestion du personnel :
Employés. L'organisme effectue toutes ses tâches de réponse aux incidents, avec un soutien technique et
administratif limité de la part des contractants.
Partiellement externalisé. L'organisme externalise une partie de ses tâches de réponse aux incidents. La
section 2.4.2 décrit les principaux facteurs à prendre en compte dans le cadre de l'externalisation. Bien que
les tâches de réponse aux incidents puissent être réparties entre l'organisme et un ou plusieurs sous-
traitants de nombreuses manières, quelques arrangements sont devenus courants :
L'arrangement le plus courant consiste pour l'organisme à externaliser la surveillance 24 heures sur
24 et 7 jours sur 7 des capteurs de détection d'intrusion, des pare-feu et autres dispositifs de
sécurité à un fournisseur de services de sécurité gérés hors site (MSSP). Le MSSP identifie et
analyse les activités suspectes et signale chaque incident détecté à l'équipe de réponse aux
incidents de l'organisme.
Certains organismes effectuent des tâches de base de réponse aux incidents en interne et font appel
à des sous-traitants pour les aider à gérer les incidents, en particulier ceux qui sont plus graves ou
plus répandus.
Entièrement externalisé. L'organisme sous-traite entièrement ses tâches de réponse aux incidents,
généralement à un contractant sur place. Ce modèle est plus susceptible d'être utilisé lorsque l'organisme a
besoin d'une équipe de réponse aux incidents sur site à plein temps, mais ne dispose pas d'un nombre
suffisant d'employés qualifiés. Il est supposé que l'organisme aura des employés qui superviseront et
contrôleront les tâches du sous-traitant.

34/146
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.4.2 Team Models Selection
Lors de la sélection de la structure et des modèles de recrutement appropriés pour une équipe de réponse aux
incidents, il convient que les organismes prennent en considération les facteurs suivants :
Nécessité d'une disponibilité 24 heures sur 24 et 7 jours sur 7. La plupart des organismes ont besoin
que le personnel de réponse aux incidents soit disponible 24 heures sur 24 et 7 jours sur 7. Cela signifie
généralement que les équipes de réponse aux incidents peuvent être contactées par téléphone, mais cela
peut également signifier qu'une présence sur place est indispensable. La disponibilité en temps réel est le
meilleur moyen de répondre aux incidents car plus un incident dure longtemps, plus il y a de risques de
dommages et de pertes. La communication en temps réel est souvent nécessaire dans le cadre de tâches
menées en collaboration avec d'autres organismes, par exemple pour remonter à la source d'une attaque.
Membres de l'équipe à temps plein ou à temps partiel. Les organismes dont les besoins en matière de
financement, de personnel ou de réponse aux incidents sont limités peuvent n'avoir que des membres
d'équipe de réponse aux incidents à temps partiel, faisant plutôt office d'équipe virtuelle de réponse aux
incidents. Dans ce cas, l'équipe de réponse aux incidents peut être considérée comme un service de
pompiers volontaires. Lorsqu'une urgence survient, les membres de l'équipe sont immédiatement
contactés, et ceux qui peuvent les aider le font. Un groupe existant, tel que le service d'assistance
informatique, peut faire office de premier point de contact pour le signalement des incidents. Les membres
du service d'assistance peuvent être formés pour effectuer l'enquête initiale et la collecte de données, puis
alerter l'équipe de réponse aux incidents s'il apparaît qu'un incident grave s'est produit.
Moral des employés. La tâche de réponse aux incidents est très stressante, tout comme les
responsabilités incombant à la plupart des membres de l'équipe de veille. En raison de cette combinaison,
les membres de l'équipe de réponse aux incidents peuvent facilement subir un stress excessif. De
nombreux organismes auront également du mal à trouver du personnel volontaire, disponible, expérimenté
et dûment qualifié pour participer, notamment à l'assistance 24 heures sur 24. La séparation des rôles, en
particulier la réduction du volume de tâches administratives que les membres de l'équipe doivent accomplir,
peut être un facteur de motivation important.

35/146
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.4.2 Team Models Selection (suite)
Coût. Le coût constitue un facteur important, surtout si les employés doivent être sur place 24 heures sur
24, 7 jours sur 7. Les organismes peuvent omettre d'inclure dans leurs budgets les coûts spécifiques à la
réponse aux incidents, comme un financement suffisant pour la formation et le maintien des compétences.
La tâche de l'équipe de réponse aux incidents comportant de nombreuses facettes de l'informatique, ses
membres ont besoin de connaissances beaucoup plus approfondies que la plupart des membres du
personnel informatique. Ils doivent également comprendre comment utiliser les outils de réponse aux
incidents, tels que les logiciels de forensique numérique. Les autres coûts qui peuvent être négligés sont la
sécurité physique des zones de travail de l'équipe et les mécanismes de communication.
Expertise du personnel. Le management des incidents exige des connaissances spécialisées et de
l'expérience dans plusieurs domaines techniques ; l'étendue et la profondeur des connaissances requises
varient en fonction de la gravité des risques de l'organisme. Les sous-traitants peuvent posséder des
connaissances plus approfondies en matière de détection des intrusions, de forensique, de vulnérabilités,
d'exploits et d'autres aspects de la sécurité que les employés de l'organisme. De plus, les MSSP peuvent
être en mesure de corréler les événements entre les clients afin de pouvoir identifier les nouvelles menaces
plus rapidement que ne pourrait le faire un client individuel. Cependant, les membres du personnel
technique de l'organisme ont généralement une bien meilleure connaissance de l'environnement de
l'organisme que ne le ferait un sous-traitant, ce qui peut être bénéfique pour identifier les faux positifs
associés au comportement spécifique de l'organisme et à la criticité des cibles.

36/146
Il est important que chaque employé de l'organisme sache comment signaler toute activité inhabituelle sur ses
appareils. Il convient que les employés sachent quelles activités suspectes doivent être signalées à l'équipe de
réponse aux incidents.
Il convient de mettre en place un processus permettant de décider si les incidents potentiels sont des incidents
réels.
Au cours de la phase de détection et de signalement du management des incidents de cybersécurité, il convient
que l'organisme :
Établisse une liste des incidents de cybersécurité les plus courants qui peuvent affecter ses actifs
Regroupe les incidents en catégories afin de faciliter la classification des incidents par ordre de priorité et
la prise de décision
Organise des séances de sensibilisation afin que chaque employé de l'organisme soit conscient des
risques et de son rôle dans leur détection
Crée une politique de réponse aux incidents et définir un format de rapports et de notifications, et attribuer
des rôles techniques et de gestion en matière de rapports

37/146
ISO/IEC 27035-1, article 5.3 Détection et signalement
La deuxième phase de la gestion des incidents de sécurité de l'information implique la détection, la collecte
d'informations associées et le signalement des occurrences d'événements de sécurité de l'information et de
l'existence de vulnérabilités de sécurité de l'information par des moyens manuels ou automatiques. Dans cette
phase, les événements et les vulnérabilités peuvent ne pas encore être classés comme des incidents de sécurité
de l'information.
Le signalement des événements de sécurité conformément aux politiques de signalement de l'organisme permet
une analyse ultérieure si nécessaire.
Pour la phase de détection et de signalement, il convient que tout organisme entreprenne les activités clés
suivantes :
a. Surveiller et enregistrer les activités du système et du réseau des organismes de base ou des organismes
parents, selon le cas ;
b. Détecter et signaler l'apparition d'un événement de sécurité de l'information ou l'existence d'une faille de
sécurité de l'information, que ce soit manuellement par le personnel ou automatiquement ;
c. Recueillir des informations sur un événement de sécurité de l'information ou une vulnérabilité
d. Recueillir des informations sur la connaissance de la situation à partir de sources de données internes et
externes, y compris les journaux de trafic et d'activité des systèmes et réseaux locaux, les flux
d'informations concernant les activités politiques, sociales ou économiques en cours qui pourraient avoir un
impact sur l'activité de l'incident, les flux externes sur les tendances des incidents, les nouveaux vecteurs
d'attaque, les indicateurs d'attaque actuels et les nouvelles stratégies et technologies d'atténuation ;
e. Veiller à ce que toutes les activités, les résultats et les décisions connexes soient correctement consignés
en vue d'une analyse ultérieure ;
f. Veiller à ce que les preuves numériques soient recueillies et stockées en toute sécurité, et à ce que leur
conservation soit contrôlée en permanence, au cas où ces preuves seraient nécessaires pour des
poursuites judiciaires ou des mesures disciplinaires internes. Pour des informations plus détaillées sur
l'identification, la collecte, la récupération et la conservation des preuves numériques, voir les normes
d'enquête à l'annexe A ;
g. Veiller à ce qu'un régime de contrôle des changements soit appliqué pour permettre le suivi des
événements et des vulnérabilités en matière de sécurité de l'information et la mise à jour des rapports, et
pour tenir à jour la base de données sur la sécurité de l'information ;
38/146
h. Remonter les cas, en fonction des besoins, tout au long de la phase, en vue d'une revue ou de décisions
ultérieures.
Il convient de sauvegarder dans la base de données sur la sécurité de l'information gérée par l'IRT toutes les
informations recueillies concernant un événement ou une vulnérabilité en matière de sécurité de l'information. Il
convient que les informations communiquées au cours de chaque activité soient aussi complètes que possible à
ce moment-là. Ces informations serviront à appuyer les évaluations, les décisions et les mesures à prendre.

39/146
NIST, Framework for Improving Critical Infrastructure Cybersecurity, Table 2: Cadre de base
Anomalies et événements (DE.AE): Une activité anormale est détectée en temps opportun et l’impact
potentiel des événements est compris.
Surveillance continue de la sécurité (DE.CM) Le système d'information et les actifs sont surveillés pour
identifier les événements de cybersécurité et vérifier l'efficacité des mesures de protection.
Processus de détection (DE.DP): Les processus et procédures de détection sont maintenus et testés
pour assurer une reconnaissance adéquate et opportune des événements anormaux

40/146
Le management des incidents de cybersécurité est passé de la prévention des cyberattaques à leur détection et
à leur signalement.
La phase de détection et de signalement repose sur l'utilisation d'approches techniques telles que le Darknet,
Traceback et l'opération Sinkhole.

41/146
ISO/IEC 27032, Annexe A.2 Surveillance du Darknet
Le Darknet est un ensemble d'adresses IP qui ne sont pas utilisées dans les organismes. Les types d’adresses IP
du Darknet ne sont attribués à aucun serveur opérationnel ou système PC. En utilisant des paquets surveillés
dans les domaines IP du Darknet, les organismes pourraient observer les nouvelles attaques de réseau, y
compris l'analyse de réseau initiée par les maliciels, le comportement d'infection des maliciels et les
rétrodiffusions DDoS. Comme les adressesIP du Darknet sont publiques et ne sont pas attribuées à des hôtes
légitimes, on peut en déduire que tout le trafic entrant en provenance des domaines IP du Darknet est une
conséquence d’activités malveillantes ou de configurations incorrectes.
Il existe, en général, trois méthodes couramment utilisées dans le Darknet pour observer les trafics liés à des
activités malveillantes sur Internet, à savoir la Black Hole Monitoring et la surveillance à faible et forte interaction.

42/146
ISO/IEC27032-1, annexe A.4 Traçabilité (suite)
Les problèmes opérationnels ci-dessus surviennent lorsqu’un test de retraçage tente de s’étendre au-delà des
limites du réseau. Les techniques de retraçage doivent tenir compte des limites du fonctionnement du réseau et
de la différence entre les politiques opérationnelles des différents domaines du réseau. On croit fermement que
les mécanismes de retraçage interdomaines et les mécanismes d’atténuation des attaques doivent être déployés
de façon omniprésente sur Internet.
Dans le cadre du développement des techniques et systèmes de traçage interdomaines dans la pratique, il
convient d'envisager l'architecture de traçage suivante :
a. Pour maintenir les limites de l'exploitation du réseau, l'architecture de traçabilité doit laisser à chaque AS le
soin de décider d'hériter d'une demande de suivi par la politique opérationnelle de chaque AS ;
b. Il convient également de laisser à chaque SA le soin de décider d'approfondir ou non l'investigation à
l'intérieur de son propre domaine de réseau ;
c. Il convient également que l'architecture laisse à chaque sous-domaine d'un AS la possibilité de décider
d'inspecter ou non le réseau de chaque sous-domaine par sa politique opérationnelle. L'opération de
traçage consommera de nombreuses ressources sur les AS concernés ; par conséquent, l'architecture de
traçage ne devrait pas générer ou inonder des demandes sans signification si possible ; par conséquent, il
convient que l'architecture de traçage ne transmette pas aux AS des messages de demande qui n'ont
aucun rapport avec l'attaque montée ;
d. Afin de réduire les dommages causés par les utilisations abusives, il convient que le message ne contienne
pas d'informations sensibles susceptibles de provoquer la divulgation de secrets ou la perte de confiance
d'un SA ; ainsi, l'architecture de traçage ne devrait pas révéler à d'autres des informations sensibles d'un
SA ;
e. Même lorsqu'un abus ou une action compromise a eu lieu, la traçabilité du message permettra d'identifier
l'auteur de l'infraction ; par conséquent, il convient qu'un message échangé dans l'architecture ait sa propre
traçabilité pour prouver ou confirmer les émetteurs ;
f. Si l'architecture dépend d'une technique de traçage spécifique, les agresseurs développeront des attaques
d'évasion et dissimuleront l'emplacement des nœuds de l'agresseur; Pour surmonter les attaques
d'évasion, il convient que l'architecture du traçage ne dépende pas de techniques de traçage spécifiques ;

43/146
ISO/IEC27032-1, annexe A.4 Traçabilité (suite)
g)De nombreux systèmes d'exploitation prennent en charge la double pile IPv4/IPv6, et plusieurs attaques
passent par un tunnel IPv6 6 à 4. Si l'architecture de traçage ne peut pas suivre les attaques sur le réseau
IPv6 ou les attaques par l'intermédiaire de certains traducteurs, la majorité des attaques passeront à une
attaque aussi complexe. Par conséquent, il convient que l'architecture de traçabilité permette de suivre une
attaque sur un environnement à double pile, même si l'attaque utilise certaines techniques de traduction
d'adresses ;
h)Pour automatiser le processus d'atténuation des attaques, il convient que l'architecture puisse exporter le
résultat d'un essai de traçage comme déclencheur de l'atténuation des attaques. Par conséquent, il convient
que l'architecture de traçage permette à chaque AS de prendre une autre mesure en même temps qu'un
résultat de suivi, comme un filtrage ou un autre suivi ;
i)Il convient que l'architecture puisse coopérer avec des systèmes de détection ou des systèmes de
protection ;
j)Un agresseur peut modifier le schéma de trafic de l'attaque pour éviter l'effet de ces mesures d'atténuation.
En cas de modification d'une attaque complexe, il convient de réduire autant que possible le temps passé à
tracer un chemin d'attaque. En conséquence, il convient que l'architecture exclue autant que possible les
êtres humains.

44/146
ISO/IEC 27032, Annexe A.3 Opération sinkhole (suite)
Les opérations Sinkhole sont souvent utilisées pour se protéger contre les attaques DDoS, comme décrit ci-
dessus. Elles ont également été déployées pour se protéger contre des attaques de botnets, en redirigeant la
commande et le contrôle (C&C) du botnet vers un dispositif sinkhole. Comme chaque botnet doit établir des
connexions avec un serveur de C&C afin de recevoir les instructions d’attaque d’un contrôleur de botnet, il envoie
des requêtes DNS pour résoudre l’URL du serveur de C&C. Ensuite, les serveurs DNS envoient une adresse IP
du dispositif sinkhole aux botnets, au lieu de l’adresse IP réelle du serveur de C&C. Par conséquent, le contrôleur
du botnet est privé de la connexion avec ses botnets, à qui il ne peut plus envoyer d’instructions d’attaque.

45/146
L'exemple de la diapositive est basé sur le Tableau 3-1 du NIST SP 800-61.
Selon NIST SP 800-61, les précurseurs et les indicateurs sont des signes de la survenance d'un incident et sont
identifiés à l'aide de logiciels de sécurité, de journaux, d'informations accessibles au public et du personnel.
Les précurseurs sont des signes qu'un incident peut se produire ultérieurement. Parmi les exemples de
précurseurs, on peut citer les journaux des analyses de vulnérabilité, une déclaration de nouvelles attaques ou
une notification d'un agresseur indiquant que l'organisme sera attaqué.
Les indicateurs sont des signes qu'un incident a pu se produire ou est en train de se produire. Les exemples
d'indicateurs comprennent une alerte du capteur de détection d'intrusion causée par un débordement de la
mémoire tampon, une alerte antivirus qui a détecté un maliciel, etc.

46/146
Dans la phase d'appréciation et de décision, il convient que l'organisme élabore des processus et des actions
directes pour répondre aux incidents identifiés.
Lorsqu'une anomalie a été détectée, il convient que le responsable de la cybersécurité détermine si un
incident s'est produit.
Il convient que le responsable de la cybersécurité recueille des informations directement auprès de la
personne qui a signalé l'incident afin de déterminer si l'anomalie est un incident réel.
Après qu'un événement a été déterminé comme étant un incident, il convient également d'en définir le
type, le domaine d'application, les dommages et l'impact.
Les informations suivantes doivent être incluses dans la description de l'incident :
Brève description de l'incident, y compris son impact, son type et le moment où il s'est produit
Détection de la présence de l'agresseur dans le système
Informations importantes sur le système, telles que le nom, l'adresse IP, le système d'exploitation et la
version, etc.
Tout autre système de support, comme les messages système, la capture d'écran, etc.

47/146
ISO/IEC 27035-1, article5.4Appréciation et décision
La troisième phase du management des incidents de sécurité de l'information implique l'appréciation des
informations associées aux occurrences d'événements de sécurité de l'information et la décision de classer ou
non les événements comme des incidents de sécurité de l'information.
Une fois qu'un événement de sécurité de l'information a été détecté et signalé, il convient d'effectuer les activités
suivantes :
a. Répartir la responsabilité des activités de gestion des incidents de sécurité de l'information par le biais
d'une hiérarchie appropriée du personnel avec évaluation, prise de décision et actions impliquant à la fois
le personnel de sécurité et le personnel non chargé de la sécurité ;
b. Prévoir des procédures formelles que chaque personne avisée doit suivre, y compris la revue et la
modification des rapports, l'appréciation des dommages et la notification au personnel concerné. Les
mesures individuelles dépendront du type et de la gravité de l'incident ;
c. Utiliser des lignes directrices pour la documentation complète d'un événement de sécurité de l'information
et les mesures ultérieures pour un incident de sécurité de l'information si l'événement de sécurité de
l'information est classé comme un incident de sécurité de l'information.
Pour la phase d'appréciation et de prise de décision, il convient que tout organisme entreprenne les activités clés
suivantes :
Recueillir des informations qui peuvent inclure des essais, des mesures et d'autres collectes de données
sur la détection d'un événement lié à la sécurité de l'information. Le type et la quantité d'informations
collectées dépendront de l'événement de sécurité de l'information qui s'est produit ;
Faire effectuer par le responsable une appréciation de l'incident afin de déterminer si l'événement constitue
un incident de sécurité de l'information possible ou confirmé ou une fausse alerte. Une fausse alarme
(c'est-à-dire un faux positif) est une indication d'un événement signalé qui s'avère ne pas être réel ou qui
n'a aucune conséquence. Si souhaité, l'IRT peut effectuer une revue de qualité pour s'assurer que le
responsable de l'incident a correctement déclaré un incident ;
S'assurer que toutes les parties concernées, en particulier l'IRT, enregistrent correctement toutes les
activités, les résultats et les décisions connexes pour une analyse ultérieure ;
Veiller au maintien du régime de contrôle des changements afin de couvrir le suivi des incidents de sécurité
de l'information et la mise à jour des rapports d'incident, et de tenir à jour la base de données sur la
48/146
sécurité de l'information.
informations recueillies concernant un événement, un incident ou une vulnérabilité en matière de sécurité de
l'information. Il convient que les informations communiquées au cours de chaque activité soient aussi complètes
que possible à ce moment-là. Ces informations serviront à appuyer les appréciations, les décisions et les
mesures à prendre.

49/146
50/146
51/146
Dans la phase de réponse, il convient que l'organisme :
Identifie les systèmes et les données auxquels il est possible d'accéder sans autorisation
Détermine les types d'attaques utilisées pour obtenir un accès non autorisé
Vérifie si un incident s'est réellement produit
La mise en place d'un traitement approprié des incidents minimise les résultats négatifs à long terme.
La sensibilisation des employés sur la manière de signaler les incidents constitue un aspect crucial dans ce
domaine. Par exemple, le responsable des fichiers clients peut être le premier à remarquer des changements
importants sur son appareil. Il convient donc qu'il sache comment signaler l'incident. Pour permettre un
signalement efficace des incidents, une procédure de signalement claire doit être mise en place, indiquant s'il
s'agit d'un événement ou d'un incident.
Une fois l'incident identifié, il convient de fixer des objectifs de réponse. Par exemple, dans le cas de
modifications non autorisées, il convient de prendre des mesures pour enquêter sur la nature de ces
modifications et sur les actions entreprises pour corriger éventuellement les données, sur la base d'une
restauration à partir d'une sauvegarde. La recherche se concentrerait sur les dommages potentiels pour la
personne concernée et identifierait les exigences en matière de rapport en fonction de l'impact.
Une fois l'incident maîtrisé, des mesures doivent être prises pour éliminer le préjudice potentiel causé par celui-ci
et veiller à ce qu'il ne se reproduise pas à l'avenir. Ainsi, lors de la réaction à l'incident, il convient de recueillir et
d'apprécier les preuves afin de mieux comprendre ce qui s'est passé et pourquoi l'organisme n'a pas réussi à
prévenir l'incident.
Il convient également d'inclure dans le plan de réponse aux incidents les coordonnées des personnes à contacter
en cas d'incident. Il convient enfin que l'organisme puisse récupérer ses systèmes, ses données, sa connectivité,
etc.

52/146
ISO/IEC 27035-1, article 5.5 Interventions
La quatrième phase du management des incidents de sécurité de l'information consiste à répondre aux incidents
de sécurité de l'information conformément aux mesures déterminées dans la phase d'appréciation et de prise de
décision. En fonction des décisions, les interventions pourraient être faites immédiatement, en temps réel ou en
temps quasi réel, et certaines interventions pourraient impliquer une enquête de sécurité de l'information.
Une fois qu'un incident de sécurité de l'information a été confirmé, il convient d'entreprendre les activités
suivantes :
a. Répartir les responsabilités des activités de management des incidents de sécurité de l'information par le
biais d'une hiérarchie appropriée du personnel avec prise de décision et actions impliquant à la fois le
personnel de sécurité et le personnel non chargé de la sécurité si nécessaire ;
b. Prévoir des procédures formelles que chaque personne concernée doit suivre, y compris la revue et la
modification des rapports, la réappréciation des dommages et la notification au personnel concerné. Les
mesures individuelles dépendront du type et de la gravité de l'incident ;
c. Utiliser des lignes directrices pour une documentation complète d'un incident de sécurité de l'information et
des actions ultérieures.
Pour la phase de réponses, il convient que tout organisme entreprenne les activités clés suivantes :
Procéder à une enquête sur les incidents selon les besoins et en fonction de la cote de l'échelle de
classification des incidents de sécurité de l'information. Il convient de modifier l'échelle si nécessaire. La
recherche peut inclure différents types d'analyses visant à fournir une compréhension plus approfondie des
incidents.
Passer en revue l'incident de sécurité de l'information pour déterminer s'il est maîtrisé et, le cas échéant, y
apporter la réponse requise. Si l'incident n'est pas maîtrisé ou s'il pourrait avoir de graves répercussions
sur les activités de l'organisme, il convient de prendre des mesures de réponse aux crises en passant à la
fonction de gestion des crises.
désigner des ressources internes et externes afin d’intervenir en cas d’incident
Remonter en fonction des besoins, tout au long de la phase, en vue d'une appréciation ou de décisions
ultérieures.
S'assurer que toutes les parties concernées, en particulier l'IRT, enregistrent correctement toutes les
activités, pour une analyse ultérieure ;
53/146
Veiller à ce que les preuves numériques soient recueillies et stockées en toute sécurité, et à ce que leur
conservation soit contrôlée en permanence, au cas où ces preuves seraient nécessaires pour des
poursuites judiciaires ou des mesures disciplinaires internes.
Veiller au maintien du régime de contrôle des changements afin de couvrir le suivi des incidents de sécurité
de l'information et la mise à jour des rapports d'incident, et de tenir à jour la base de données sur la
sécurité de l'information.
Communiquer l'existence de l'incident de sécurité de l'information et partager tout détail pertinent (par
exemple, les informations sur la menace, l'attaque et la vulnérabilité) avec d'autres personnes ou
organismes internes et externes, conformément aux plans de communication de l'organisation et de l'IRT et
aux politiques de divulgation des informations. Il peut être particulièrement important d'informer les
propriétaires des biens (déterminés lors de l'analyse d'impact) et les organismes internes et externes (par
exemple, les autres équipes de réponse aux incidents, les services de police, les fournisseurs de services
Internet et les organismes de partage d'informations) qui pourraient aider à la gestion et à la résolution de
l'incident. Le partage d'informations pourrait également profiter à d'autres organismes, car les mêmes
menaces et attaques touchent souvent plusieurs organismes.

54/146
ISO/IEC 27035-1, article 5.5 Interventions (suite)
Après la récupération d'un incident, il convient de lancer une activité post-incident en fonction de la nature
et de la gravité de l'incident. Cette activité comprend :
Recherche sur les informations relatives à l'incident,
Recherche d'autres sources pertinentes telles que le personnel impliqué, et
Rapport résumé des conclusions des recherches.
Une fois l'incident résolu, il convient de le clore conformément aux exigences de l'IRT ou de l'organisme
d'origine et d'en informer toutes les parties prenantes.
informations recueillies concernant un événement, un incident ou une vulnérabilité en matière de sécurité de
l'information. Il convient que les informations communiquées au cours de chaque activité soient aussi complètes
que possible à ce moment-là. Ces informations serviront à appuyer les appréciations, les décisions et les
mesures à prendre, y compris d'éventuelles analyses ultérieures.

55/146
NIST, Framework for Improving Critical Infrastructure Cybersecurity, Table 2: Cadre de base
Planification de l’intervention (RS.RP): Les processus et procédures d’intervention sont exécutés et
maintenus afin de garantir une intervention rapide aux événements de cybersécurité détectés.
Communications (RS.CO) : Les activités d'intervention sont coordonnées avec les parties prenantes
internes et externes (par exemple, le soutien externe des services répressifs).
Analyse (RS.AN) : L'analyse est effectuée pour assurer une réponse efficace et soutenir les activités de
récupération.
Atténuation (RS.IM) : Les activités sont réalisées pour prévenir l'expansion d'un événement, atténuer ses
effets et résoudre l'incident.
Améliorations (RS.IM) : Les activités d'intervention organisationnelle sont améliorées en intégrant les
enseignements tirés des activités de détection/intervention actuelles et antérieures.

56/146
NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, clause 2.1 The Need
for Forensics
Cependant, les outils et techniques d’analyse judiciaire sont également utiles pour de nombreux autres types de
tâches, notamment:
Dépannage opérationnel. De nombreux outils et techniques de forensique peuvent être appliqués pour
résoudre les problèmes opérationnels, comme par exemple trouver l'emplacement virtuel et physique d'un
hôte ayant une configuration réseau incorrecte, résoudre un problème fonctionnel avec une application, et
enregistrer et examiner les paramètres de configuration actuels du OS et de l'application pour un hôte.
Surveillance du journal. Divers outils et techniques peuvent aider à surveiller les journaux, comme
l’analyse des éléments d’entrée du journal et la corrélation des enregistrements du journal sur plusieurs
systèmes. Ils peuvent faciliter le traitement des incidents, la détection des violations de politiques, l’audit et
d’autres efforts.
Récupération de données. Des dizaines d’outils peuvent récupérer des données perdues à partir de
systèmes, y compris des données supprimées ou modifiées accidentellement ou volontairement. La
quantité de données pouvant être récupérée varie selon le cas.
Acquisition de données. Certains organismes utilisent des outils de police scientifique pour acquérir des
données auprès d'hôtes en cours de redéploiement ou à la retraite. Par exemple, lorsqu'un utilisateur quitte
un organisme, les données de son poste de travail peuvent être récupérées et sauvegardées au cas où
elles seraient nécessaires à l'avenir. Le média du poste de travail peut alors être aseptisé afin de supprimer
toutes les données de l'utilisateur d'origine.
Diligence raisonnable/Conformité réglementaire. Les réglementations existantes et émergentes exigent
de nombreux organismes qu’ils protègent l’information sensible et qu’ils conservent certains
enregistrements à des fins d’audit. En outre, lorsque des informations protégées sont exposées à d'autres
parties, les organismes peuvent être tenus d'en informer d'autres organismes ou les personnes
concernées. La police scientifique peut aider les organismes à faire preuve de diligence raisonnable et à se
conformer à ces exigences.

57/146
58/146
59/146
Dans la phase des leçons tirées, il convient que l'organisme s'assure que tous les incidents sont correctement
contenus et que les leçons tirées de chaque incident ont été recueillies pour référence ultérieure.
Un rapport post-incident est très important car il montre l'impact réel de l'incident. Il aide également l'organisme à
évaluer son plan et son budget de réponse aux incidents de cybersécurité.

60/146
ISO/IEC 27035-1, article 5.6 Leçons tirées
La cinquième phase du management des incidents de sécurité de l'information a lieu lorsque les incidents de
sécurité de l'information ont été résolus. Cette phase consiste à tirer des enseignements de la manière dont les
incidents (et les vulnérabilités) ont été traités.
Pour la phase des leçons apprises, il convient que tout organisme réalise les activités clés suivantes :
a. Identifier les leçons tirées des incidents de sécurité de l'information et des vulnérabilités ;
b. Passer en revue, identifier et apporter des améliorations à la mise en œuvre des mesures de contrôle de la
sécurité de l'information (contrôles nouveaux ou mis à jour), ainsi qu'à la politique de management des
incidents de sécurité de l'information. Les leçons peuvent provenir d'un ou de plusieurs incidents de
sécurité de l'information ou de vulnérabilités de sécurité signalées. Les améliorations sont facilitées par des
mesures intégrées dans la stratégie de l'organisme sur les domaines dans lesquels il convient d'investir
dans les mesures de contrôle de la sécurité de l'information ;
c. Passer en revue, identifier et apporter des améliorations à l'appréciation des risques de sécurité de
l'information et aux revues de management existantes de l'organisme ;
d. Passer en revue l'efficacité des processus, des procédures, des formats de rapport et de la structure
organisationnelle pour les réponses, l'appréciation et la récupération des incidents de sécurité de
l'information et le traitement des vulnérabilités de sécurité de l'information. Sur la base des leçons apprises,
identifier et apporter des améliorations au plan de management des incidents de sécurité de l'information et
à sa documentation ;
e. Communiquer et partager les résultats de la revue au sein d'une communauté de confiance (si l'organisme
le souhaite) ;
f. Déterminer si les informations relatives à l'incident, les vecteurs d'attaque associés et les vulnérabilités
peuvent être partagés avec les organismes partenaires afin d'aider à empêcher que les mêmes incidents
ne se produisent dans leur environnement.
g. Effectuer périodiquement une évaluation complète des performances et de l'efficacité de l'IRT.
Il est souligné que les activités de management des incidents de sécurité de l'information sont itératives, et il
convient donc que tout organisme apporte régulièrement des améliorations à un certain nombre d'éléments de
sécurité de l'information au fil du temps. Il convient de proposer ces améliorations sur la base de revues des
données relatives aux incidents de sécurité de l'information, des réponses apportées et des vulnérabilités de
sécurité de l'information signalées.
61/146
62/146
63/146
Il est important de documenter et d'enregistrer tout incident afin que le personnel chargé de gérer l'incident
puisse disposer de toutes les informations nécessaires pour le résoudre de la manière la plus efficace possible.

64/146
NIST SP 800-61, Computer Security Incident Handling Guide, clause 2.3.4 Sharing Information With
Outside Parties
Les organismes ont souvent besoin de communiquer avec des parties extérieures concernant un incident, et il
convient qu'ils le fassent chaque fois que cela est approprié, par exemple en contactant les services répressifs,
en répondant aux demandes des médias et en recherchant une expertise externe. Un autre exemple consiste à
discuter des incidents avec d'autres parties concernées, telles que les fournisseurs d'accès à Internet (FAI), le
vendeur de logiciels vulnérables ou d'autres équipes de réponse aux incidents. Les organismes peuvent
également partager de manière proactive des informations pertinentes sur les indicateurs d'incidents avec leurs
pairs afin d'améliorer la détection et l'analyse des incidents. Il convient que l'équipe de réponse aux incidents
discute du partage des informations avec le bureau des affaires publiques de l'organisme, le service juridique et la
direction avant qu'un incident ne se produise afin d'établir des politiques et des procédures concernant le partage
des informations. Dans le cas contraire, des informations sensibles concernant les incidents peuvent être fournies
à des parties non autorisées, ce qui peut entraîner des perturbations supplémentaires et des pertes financières. Il
convient que l'équipe documente tous les contacts et communications avec des parties extérieures à des fins de
responsabilité et de preuve.

65/146
NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, clause 4.2.2 Notification
Procedures (cont’d)
Il convient de faire preuve de prudence lors de l'envoi de notifications par courrier électronique, car il n'y a aucun
moyen d'en assurer la réception et l'accusé de réception. Bien que l'e-mail puisse être un moyen efficace de
diffuser des notifications à des comptes professionnels ou personnels, il n'y a aucun moyen de garantir que le
message sera lu. Si le personnel de recouvrement utilise une méthode de notification par e-mail, il convient de
l'informer de la nécessité de vérifier fréquemment et régulièrement ses comptes.
Il convient que les notifications envoyées pendant les heures de travail soient envoyées à l'adresse de travail,
tandis que l'e-mail personnel peut être utile dans le cas où le réseau local (LAN) est en panne.
La stratégie de notification doit définir les procédures à suivre dans le cas où un membre du personnel spécifique
ne peut être contacté. Il convient que les procédures de notification soient clairement documentées dans le plan
d'urgence. Des copies des procédures peuvent être faites et placées en lieu sûr dans d'autres endroits. L'arbre
d'appel représente une méthode de notification manuelle courante. Cette technique consiste à assigner des
tâches de notification à des personnes spécifiques, qui sont à leur tour chargées de prévenir les autres membres
du personnel de reprise. Il convient que l'arbre d'appel tienne compte des méthodes de contact principales et
alternatives et qu'il indique les procédures à suivre si une personne ne peut être contactée.

66/146
Identification des améliorations de sécurité
Durant la revue de clôture d’un incident, de nouvelles mesures de sécurité peuvent être identifiées. Les
recommandations peuvent ne pas être financièrement réalisables pour être mises en œuvre immédiatement. Il
convient donc de les identifier comme des objectifs à long terme de l'organisme.
Identification du plan d’améliorations
Une fois l’incident résolu, le chef d’équipe du IRT ou un candidat doit enquêter sur ce qui s’est passé pour
évaluer et donc «quantifier» l’efficacité de la réponse globale aux incidents de cybersécurité. Cette analyse
détermine les parties du système de management des incidents de cybersécurité qui ont bien fonctionné et
identifie les points à améliorer.
Un aspect important de l'analyse «post-incident» est la réintroduction des informations dans le système de
gestion des incidents de cybersécurité. Si l'incident est d'une grande gravité, il est important de prévoir une
réunion avec toutes les parties concernées, pendant que l'information est encore fraîche en mémoire. Certains
facteurs à considérer dans ce type de rencontre incluent:
Les procédures énoncées dans le plan d'incidents de cybersécurité fonctionnent-elles comme prévu?
Des procédures ou méthodes existantes auraient-elles pu aider à détecter l’incident?
Des procédures et outils qui auraient pu aider au processus de réponse ont-ils été identifiés?
Existe-t-il des procédures qui auraient pu aider à restaurer les systèmes d’information à la suite d’un
incident identifié?
La communication de l’incident à toutes les parties a-t-elle été efficace tout au long des processus de
détection, rapport et réponse?
Les résultats de la réunion devraient être documentés et toute action convenue devrait être mise en œuvre de
manière appropriée.

67/146
68/146
69/146
Exercice 14 : Gestion des incidents de cybersécurité
En vous fondant sur la dernière section de l'étude de cas, intitulée Vulnérabilité du Server Messenger Block
(SMB) v1.0, déterminez quelles phases de la gestion des incidents de cybersécurité l'IRT d'ITELCO a réalisées.
En outre, expliquez ce qu'il convient d'inclure dans la réunion sur les enseignements tirés qu'il convient
qu'ITELCO organise afin d'améliorer sa gestion des incidents de cybersécurité.


70/146
Résumé de la section
Les organismes peuvent utiliser les principes et lignes directrices d'ISO/IEC 27035-1 et ISO/IEC 27035-2
lorsqu'ils cherchent à planifier, mettre en œuvre, gérer et améliorer leurs processus de management des
incidents de cybersécurité.
Pour gérer efficacement les incidents de cybersécurité, il convient que tout organisme crée une politique
de management des incidents et mette en place une équipe de réponse aux incidents chargée de définir
les processus et de rédiger les procédures, de définir les processus de médecine légale, de mettre en
œuvre les mesures de contrôle de la cybersécurité, d'enregistrer les informations liées aux incidents de
cybersécurité, et de mesurer et de passer en revue les processus de management des incidents de
cybersécurité.
Il convient que toute politique de management des incidents comprenne l'engagement de la direction, les
rôles et responsabilités des employés impliqués dans l'identification, la notification et la réponse aux
incidents, la définition d'un incident de sécurité de l'information (de manière claire et explicite), etc.
L'équipe de réponse aux incidents (IRT) est chargée d'assurer la coordination, la gestion, le retour
d'information et la communication en ce qui concerne les incidents de cybersécurité.
Les informations pertinentes relatives aux incidents de cybersécurité peuvent comprendre l'identifiant
unique de l'enregistrement, la date et l'heure de l'enregistrement, le statut de l'incident, les actifs affectés,
les mesures prises pour résoudre l'incident, l'approbation des mesures prises et la clôture de l'incident.
Il convient de mesurer et de réévaluer régulièrement les processus de management des incidents.

71/146
La présente section vise à fournir aux participants des informations sur la manière d'utiliser les techniques
d'essai, de sélectionner les techniques adéquates et les étapes de préparation à un essai de cybersécurité.

72/146
73/146
74/146
Pour disposer d'un programme d'essai efficace pour différents systèmes, il convient d'inclure les éléments
suivants dans le domaine d'application des essais :
Personnes
Processus
Technologique
Source: Stamp, Mark. Sécurité de l’information Principes et pratiques. New Jersey: Wiley, 2011.
ISO/IEC 27032, article 12.5.3.3 Tests
Les employés devraient signer une déclaration indiquant qu’ils acceptent et comprennent le contenu de la
politique de sécurité de l’organisme. Dans le cadre du processus d’amélioration de la sensibilisation et pour veiller
à ce que toute l’attention nécessaire soit accordée à un tel risque, un organisme devrait envisager l’exécution de
tests périodiques pour déterminer le degré de sensibilisation et de conformité aux politiques et pratiques
connexes. Les employés peuvent effectuer un test écrit ou à l’ordinateur pour déterminer s’ils comprennent le
contenu de la politique de sécurité de l’organisme. Ces tests peuvent comprendre la création de sites
d’hameçonnage ciblés, mais contrôlés, de courriers indésirables et de messages frauduleux à l’aide de contenus
d’ingénierie sociale crédibles. Lors de la réalisation de tels tests, il est important de veiller à ce que:
a. les serveurs de test et leur contenu sont tous sous le contrôle et la commande de l'équipe de test ;
b. les professionnels qui ont de l’expérience dans ce genre de tests sont embauchés, dans toute la mesure du
possible;
c. les utilisateurs sont préparés à ces tests grâce aux programmes de sensibilisation et de formation;
d. tous les résultats des tests sont présentés dans un format agrégé afin de protéger la vie privée des
personnes, car le contenu présenté dans ces tests peut gêner certaines personnes et donner lieu à des
problèmes de confidentialité s’il n’est pas bien géré.
NOTE : Il faut tenir compte de l’éthique et de la législation de chaque pays.

75/146
76/146
ISO/IEC 27032, article 13.5.6 Systèmes de test
Bien que chaque système technique et ses méthodes et processus connexes doivent être rigoureusement testés
pour garantir leur fiabilité et leur intégrité, un ou plusieurs systèmes techniques dédiés à l’amélioration de
l’efficience et de l’efficacité des tests, en particulier des tests de scénarios, devraient être envisagés. Un tel
système peut prendre la forme d’un système de simulation, qui simule les environnements d’exploitation tels qu’ils
sont perçus par chaque organisme du cyberespace et la situation évolutive de la cybersécurité, offrant la
possibilité d’introduire une série d’événements de sécurité pour faciliter les tests requis.

77/146
Le processus des essais comprend les étapes suivantes :
Sélectionner ce qui doit être mesuré par les tests
Décider comment les tests doivent être faits
Élaborer les cas de test
Exécuter les cas de test
Comparer les résultats réels aux résultats attendus
Qu’est-ce qui doit être mesuré par les tests?
Envisager chaque mesure de sécurité en fonction d'exigences de sécurité spécifiques qui peuvent être testées et
énumérer plusieurs exigences spécifiques dont chacune nécessite un ou plusieurs tests pour vérifier le bon
fonctionnement et contrôler :
Objectifs du test
Exigences en matière d’exhaustivité
Cohésion de la conception
Fiabilité du code
Comment le tester? Quel type de test est le plus approprié?
Vérifier:
Type de tests
Inspections
Preuve
Tests de la boîte noire et de la boîte blanche
Outils automatisés
Élaborer les cas de test
Élaborer des tests et les effectuer pour en vérifier le bon fonctionnement.
tiliser des données différentes pour les tests (données qui révèlent quelque chose sur l'attribut mesuré)
Déterminer quels sont les résultats escomptés
Déterminer les résultats que vous attendez des essais
78/146
Organiser les tests pour une efficacité maximale et automatiser autant que possible l'exécution et
l'enregistrement des résultats
Exécuter les cas tests
Ce processus peut nécessiter la création d'un logiciel spécial.
Comparer les résultats aux objectifs/résultats escomptés
Cette étape est nécessaire pour tester les erreurs possibles et avec cette méthode, toutes les incohérences
doivent être retracées.

79/146
Chaque organisme peut mettre à l'essai les mesures de sécurité en vérifiant chaque composant individuellement
ou en effectuant un processus d'essai complet. Un processus d'essai peut vérifier les fonctions ou les
performances du système en contrôlant le matériel ou les logiciels, ou des parties de ceux-ci.
Les tests de fonctionnement vérifient si toutes les fonctions spécifiées pour le système dans le cahier
des charges sont opérationnelles. Les essais de fonctionnement sont effectués après la fin de tous les
essais de programmation et d'intégration, et doivent porter sur toutes les parties fonctionnelles du système
afin de détecter toute erreur éventuelle.
Les essais de performance vérifient si le système répond aux exigences non fonctionnelles. Ils
comparent les modules intégrés et les exigences du système non fonctionnel, telles que la vitesse et la
performance. Cela comprend des essais de configuration, de compatibilité, de sécurité, de qualité, etc.
Les essais d'acceptation impliquent l'installation du système sur les sites des utilisateurs et se
concentrent sur la vérification du fonctionnement de toute caractéristique fonctionnelle ou non fonctionnelle
du système.
Les essais d'installation sont un processus qui permet de vérifier l'exactitude de l'installation afin de
garantir la qualité du service.
Les essais de régression sont effectués lorsqu'il y a un changement dans le système et garantissent que
le changement n'a pas affecté une caractéristique existante du système.
Source: Stamp, Mark. Sécurité de l’information Principles and practice. New Jersey: Wiley, 2011.

80/146
Les essais permettent de vérifier la présence de bogues, de défaillances et de problèmes de sécurité. Il existe
différentes méthodes pour effectuer des essais de cybersécurité qui, si elles sont planifiées et utilisées
correctement, peuvent améliorer la sécurité des systèmes d'exploitation, des systèmes techniques, des systèmes
de gestion de bases de données ou, de manière générale, la sécurité du cyberespace. Les essais de
cybersécurité sont essentiels car ils garantissent la fiabilité et la qualité des logiciels, des performances
optimales et l'utilisation des capacités. Ils permettent de vérifier les aspects suivants d'un système :
Authentification
Autorisation
Confidentialité, intégrité et disponibilité
Résilience
Il existe deux types d'essais de cybersécurité basés sur l'origine de l'attaque.
Les essais externes sont effectués depuis l'extérieur de l'organisme et détectent les vulnérabilités qui
pourraient être exploitées par un agresseur externe. Ces essais portent sur des informations accessibles
au public, telles que les noms de systèmes, les adresses de protocoles Internet, etc.
Les essais internes sont réalisés à l'intérieur de l'organisme et détectent les vulnérabilités qui pourraient
être exploitées par un agresseur présumé. Ces essais portent sur la sécurité du système, l'authentification,
les mesures de contrôle d'accès, etc.

81/146
82/146
Les essais de pénétration simulent une attaque réelle sur un système réel afin d'identifier tout type de
vulnérabilité pouvant être exploité et d'identifier ensuite des méthodes pour prévenir tout dommage éventuel
dans le système. Les essais de pénétration déterminent dans quelle mesure le système tolère une attaque
spécifique et fournissent des indications sur les moyens de réduire le risque associé. Il peut être automatisé,
mais il est généralement planifié et mis en place par des consultants en cybersécurité.
Selon NIST SP 800-115, les essais de pénétration se composent de quatre phases :
Lors de la phase de planification, l'organisme définit les objectifs de l'essai et s'assure de l'approbation de
la direction.
Dans la phase de découverte, les essais sont lancés et une analyse de vulnérabilité est effectuée. Afin
d'identifier manuellement les nouvelles vulnérabilités du système, les personnes chargées des essais
peuvent utiliser leur propre base de données ou toute base de données publique telle que la NVB
(National Vulnerability Database).
La phase d'attaque est le processus qui consiste à identifier toute attaque possible en essayant d'exploiter
les vulnérabilités. Il s'agit d'un processus itératif qui peut être subdivisé en quatre autres étapes :
l'obtention de l'accès, la montée des privilèges, la navigation dans le système et l'installation d'outils
supplémentaires.
Dans la phase de rapport, un rapport de conclusion est élaboré qui comprend la liste des vulnérabilités
découvertes et les méthodes pour les atténuer.
Les catégories de vulnérabilités qui sont exploitées lors des essais de pénétration sont les suivantes : les
mauvaises configurations, les failles du noyau, les débordements de mémoire tampon, la validation insuffisante
des entrées, les liens symboliques, les autorisations incorrectes de fichiers et de répertoires, etc.

83/146
L'appréciation de la vulnérabilité est le processus d'identification de l'existence d'une vulnérabilité dans un
environnement technique, qui peut être utilisé pour attribuer les niveaux de sécurité dans un organisme. Cette
technique d'essai de sécurité vise à identifier la vulnérabilité et non à l'exploiter, elle n'est donc pas de nature
exploitante (en comparaison avec les essais de pénétration ou le piratage éthique).
Un processus réussi et efficace d'appréciation de la sécurité comprend trois étapes :
Planification
Exécution
Post-exécution
Il existe différentes activités d'appréciation de la vulnérabilité, présentées ci-dessous :
1. Les analyses basées sur le réseau combinent la découverte de services et d'hôtes avec l'énumération
des vulnérabilités. Les analyses basées sur le réseau utilisent des outils d'analyse pour découvrir le
système d'exploitation et l'application réseau des cibles, et utilisent ces informations pour identifier de
nouvelles vulnérabilités dans le système ou toute mauvaise configuration de ce système d'exploitation.
2. Les analyses basées sur l'hôte sont exécutées à partir de du dispositif cible, ce qui offre une meilleure
visibilité des paramètres d'un système.
3. Les analyses sans fil permettent de vérifier l'infrastructure du réseau sans fil. Il permet de comprendre la
sécurité de tout réseau sans fil. Par exemple, les analyses sans fil d'un cybercafé local peuvent aider à
identifier les points d'accès malveillants, qui se font passer pour des réseaux sans fil légitimes.
4. Les analyses d'applications se concentrent sur des essais d'applications Web pour découvrir les
vulnérabilités des logiciels, comme l'injection SQL, les scripts intersites, etc.
Il convient que l'organisme fournisse des outils et des techniques d'analyse de vulnérabilité dans le cadre du
processus de management de vulnérabilité.

84/146
Sources :
ISACA. “Cybersecurity awareness – Vulnerability assessment.” Consulté le 4 mars 2020.
https://cybersecurity.isaca.org/info/cyber-aware/images/ISACA_WP_Vulnerability_Assessment_1117.pdf
Scarfone, Karen, Souppaya, Murugiah, Cody, Amanda, Orebaugh, Angela. “NIST Special Publication 800-115,
Technical Guide to Information Security Testing and Assessment.” 2008.

85/146
La mise en œuvre d'une stratégie d'essais d'intégration se fait par le biais de différentes approches :
Essais d'intégration progressifs (essais descendants, essais ascendants)
Essais d'intégration non incrémentiels (essais d'intégration au Big Bang)
Essais en sandwich/hybride
Les essais d'intégration sont une technique bénéfique, mais ils présentent certains inconvénients :
Les données peuvent être perdues entre les interfaces
Une fonction peut ne pas fonctionner comme prévu lorsqu’elle est combinée avec une autre
Un module peut avoir un effet négatif sur un autre
Source: Professional QA. «Integration Testing Types.» Consulté le 19 février 2020
https://www.professionalqa.com/types-of-integration-testing

86/146
Les essais assurent la sécurité du fonctionnement du système. Pour gérer les éventuelles complications au cours
du processus, il convient que l'organisme définisse correctement la technique des essais. Chaque cas étant
différent, il convient que l'organisme, au moment de déterminer une technique d'essai spécifique, s'assure que
cette dernière répond aux exigences et aux objectifs de l'essai, et que le risque de perte éventuelle de données
soit pris en compte.
Lors de la sélection de la technique d'essai, il convient de tenir compte de la présence d'informations sensibles et
identifiables, de l'impact sur les systèmes de production et de la similitude de configuration entre les systèmes de
production et de non-production.
À partir des résultats souhaités des essais, les différentes méthodes sont classées en trois catégories :
Techniques d'identification et d'analyse des cibles (découverte de réseaux, analyse des vulnérabilités,
analyse sans fil, etc.)
Techniques de validation de la vulnérabilité des cibles (craquage de mots de passe, essais de
pénétration, ingénierie sociale)
Techniques de revue (revue des journaux, revue de la documentation, revue de la configuration du
système, etc.)
Selon le Manuel de méthodologie des essais de sécurité des logiciels libres (OSSTMM), pour définir un essai de
sécurité, tout organisme peut suivre sept étapes :
Définir les mesures de contrôle à soumettre aux essais
Identifier les mécanismes de protection
Définir le domaine d'application des essais (processus et protocoles permettant de maintenir
l'infrastructure du système opérationnel)
Définir l'interaction du domaine d'application (avec l'environnement intérieur et extérieur)
Identifier les ressources (humaines, physiques, sans fil, télécommunications et réseaux de données)
Définir le type d'essai
S'assurer que les essais de sécurité sont adéquats

87/146
Documentation type nécessaire pour les essais :
Objectifs du test
Raisons de ce test
Scénarios d'essais comprenant des étapes d'essais spécifiques, les participants et leur implication, les
résultats attendus des activités
Durée prévue de l'essai
Type de tests
Calendrier des tests

88/146
89/146
Une fois les essais réalisés, un rapport d'essai doit être rédigé afin de documenter les résultats d'essai. Il s'agit
d'un document détaillé qui présente les résultats du processus d'essai et contient un résumé des activités d'essai.
Les résultats d'essai peuvent être utilisés comme point de référence pour définir les actions qui amélioreront la
sécurité du système. Les recommandations d'atténuation comprennent des recommandations techniques et non
techniques telles que des modifications de politiques, de processus et de procédures, des changements
d'architecture de sécurité, le déploiement de nouvelles technologies de sécurité, etc.

90/146
91/146
92/146
Exercice 15 : Tests de cybersécurité
En vous fondant sur la dernière section de l'étude de cas, intitulée Server Messenger Block (SMB) v1.0
Vulnerability, expliquez comment les essais de pénétration auraient pu aider ITELCO à prévenir l'attaque.


93/146
Il existe quatre types d'essais différents : les essais de modules, les essais de composants, les essais
individuels et les essais d'intégration.
Les essais assurent la sécurité des opérations du système, et pour gérer toute complication au cours du
processus, il convient que l'organisme définisse correctement la technique d'essai de sécurité.
En fonction des résultats souhaités des essais, il existe différents types de méthodes d'essai, telles que
l'appréciation de la vulnérabilité, les essais de pénétration, la revue des journaux, etc.
Afin de traduire les résultats du processus d'essai en mesures qui amélioreront la sécurité, il convient que
l'organisme élabore un rapport d'essai et un document de recommandations d'atténuation.

94/146
La présente section vise à fournir aux participants des informations sur la manière de mesurer les performances
du programme de cybersécurité, de déterminer les objectifs de mesure, de définir les aspects à surveiller et à
mesurer et d'établir des indicateurs de performance. La communication des résultats des mesures constitue un
autre aspect important.

95/146
96/146
La surveillance, la mesure, l'analyse et l'évaluation constituent des facteurs essentiels pour l'appréciation des
performances du programme de cybersécurité. L'objectif est de déterminer dans quelle mesure les processus
atteignent les objectifs. Les résultats de ces activités permettent à l'organisme de comparer les niveaux de
performance réels avec les performances souhaitées.
Certains des avantages de la surveillance, de la mesure, de l’analyse et de l’évaluation sont les suivants:
Déterminer l’efficacité et l’efficience des processus
Identifier les écarts en temps utile et les traiter en conséquence
Mettre en œuvre des mesures pour assurer la réalisation des processus
Identifier les possibilités d’amélioration continue
Il convient d'accorder une grande priorité aux mesures de performance dans le programme des personnes ou
des équipes chargées de la gestion et de la maintenance du programme de cybersécurité.

97/146
Dans une perspective plus large, la surveillance et la mesure impliquent :
Fixation des objectifs pour la mesure et la surveillance
Sélection des caractéristiques à mesurer
Établir des indicateurs de performance
Évaluation de la réalisation des objectifs
Exemple:
1. Objectifs de mesurage: S’assurer que tous les employés sont sensibilisés aux risques majeurs auxquels
l’organisme fait face
2. Attribut: L’employé qui a suivi la session de sensibilisation
3. Indicateur de performance: % des employés qui ont suivi la session de sensibilisation

98/146
99/146
Les mesures de performance choisies seront les vecteurs pour communiquer le succès ou l’échec du
programme de cybersécurité. Tout ensemble de mesures de performance doit être soigneusement sélectionné
pour assurer qu’il détermine de fait la voie à suivre pour réaliser les objectifs de l’organisme.
Les objectifs de mesure dans le contexte d’un programme de cybersécurité comprennent:
Évaluer l’efficacité des processus et des procédures mis en place
Faciliter l’amélioration de la performance
Fournir des éléments d'entrée pour la revue de direction afin de faciliter la prise de décision et de justifier
les améliorations nécessaires du programme de cybersécurité en place

100/146
Il est préférable d'utiliser un nombre minimum de mesures de performance efficaces liées aux objectifs de
l'organisme. Plusieurs organismes utilisent la règle SMART quand ils développent leurs mesures de
performance.
L'acronyme SMART signifie :
Spécifique: clair et ciblé pour éviter toute méprise
Mesurable: peut être quantifié et comparé aux autres données
Atteignable: réalisable, raisonnable et acceptable dans un contexte de performance particulier
Réaliste: s’inscrit dans la culture de l’organisation et est rentable par rapport aux ressources disponibles
Temporellement défini: réalisable dans les délais impartis
Aucun ensemble de mesures génériques ne saurait être efficace pour tous les organismes et peut même ne pas
l’être pour les organismes dans des environnements similaires. L’ensemble final des mesures sera un mélange
de contextes opérationnel, législatif et culturel.
Il existe un certain nombre de niveaux des mesures de performance allant de mesures stratégiques de haut
niveau à des mesures plus spécifiques au niveau opérationnel ou du programme. Il est important pour
l'organisme de ne mesurer que les activités qui sont cruciales pour son fonctionnement, et de ne pas perdre de
temps et de ressources à mesurer les activités simplement parce qu'elles peuvent être mesurées. En termes
d’efficience, un organisme a besoin de mesures significatives qui indiquent ce qui se passe réellement afin qu’il
puisse décider de laisser une activité se poursuivre ou d’intervenir pour prendre des actions correctives. En
termes d’efficacité, un organisme a besoin de mesures pour comprendre si le système de management est
aligné sur les besoins et les objectifs de l’organisme.

101/146
Le type et le nombre de mesures de performance dépendent des objectifs de l’organisme.

102/146
103/146
Il y a de nombreuses façons de rapporter les résultats de la surveillance et des mesures. Le choix de la méthode
dépendra du public ciblé. Les principales méthodes sont:
Les tableaux de bord tactiques et opérationnels sont moins concentrés sur les objectifs stratégiques et
plus liés à l’efficacité des mesures et des processus spécifiques.
Les tableaux de bord ou tableaux stratégiques fournissent des informations stratégiques en intégrant
des indicateurs de haut niveau.
Les rapports (de nature simple et statique, tels qu'une liste de mesures pour une période donnée, à des
rapports croisés plus sophistiqués avec des groupes imbriqués, des résumés déroulants et des liens
dynamiques) sont les plus utiles lorsque l'utilisateur a besoin de consulter des données brutes dans un
format facile à lire.
Les jauges représentent des valeurs dynamiques incluant les alertes, les éléments graphiques
additionnels et l’étiquetage des paramètres.
Note : Un tableau de bord est l’interface utilisateur qui organise et présente l’information d’une façon facile à lire
et à comprendre.
Le tableau de bord n’est que le format de présentation.
Les indicateurs sont le contenu.

104/146
Les tableaux de bord opérationnels sont utilisés pour suivre les opérations en temps réel et pour informer les
utilisateurs des écarts. En outre, ils aident à contrôler les activités opérationnelles et à garantir que les processus
restent dans les limites des objectifs de productivité, de qualité et d'efficacité. Ils peuvent aider à l’analyse
continue de la performance opérationnelle afin d’éviter les problèmes et les pertes de profit, et dans le même
temps de saisir les opportunités, tout en fournissant des données qui permettront d’améliorer le contrôle et
l’efficience des processus.

105/146
La diapositive présente l'évaluation de la conformité des procédures liées au programme de cybersécurité dans
un tableau de bord tactique.

106/146
Les tableaux de bord stratégiques sont des outils qui aident les gestionnaires à tous les niveaux d'un organisme
et fournissent une vue d'ensemble rapide dont les décideurs ont besoin pour surveiller la santé financière de
l'entreprise. Les tableaux de bord de ce type se concentrent sur des mesures de haut niveau des performances
et des prévisions.

107/146
La surveillance, la mesure, l'analyse et l'évaluation sont effectuées dans le but d'améliorer le programme
de cybersécurité.
Il convient que l'organisme définisse des objectifs de mesure, sélectionne les objets à mesurer, détermine
des indicateurs de performance et évalue l'atteinte des objectifs.
Il convient que l'organisme détermine la manière et la fréquence de surveillance ou de mesure du
programme de cybersécurité.

108/146
Cette section fournit des informations qui aideront les participants à acquérir des connaissances en matière
d'amélioration continue du programme de cybersécurité par la surveillance des facteurs de changement, la mise
à jour des informations documentées, la maintenance et l'amélioration du programme de cybersécurité, etc.

109/146
110/146
L'amélioration continue est obtenue en fixant des objectifs de performance organisationnelle, en mesurant et en
passant en revue, et en apportant les modifications nécessaires aux processus, systèmes, ressources, etc.
La publication des performances d'un organisme représente un autre moyen de démontrer qu'il s'efforce
d'améliorer en permanence son programme de cybersécurité. Cela peut se faire de deux manières.
1. En informant les employés de ce qui a été réalisé (par exemple, chaque mois) : Avantages multiples : les
employés prennent conscience de la position de l'organisme sur le marché, ils peuvent voir le résultat de
leur contribution et mieux relier leurs objectifs personnels à la croissance de l'organisme.
2. Publication d'un rapport sur les performances de l'organisation sur une période donnée (par exemple,
chaque année) : Cette pratique permet aux organismes de présenter leurs réalisations à leurs clients et
aux autres parties intéressées.

111/146
112/146
Pour être efficace, il convient que le programme de cybersécurité reflète avec précision les besoins de
l'entreprise, sa structure organisationnelle ainsi que ses politiques et procédures internes.
Dans le cadre du processus d'amélioration continue, les activités et les procédures subissent des changements
en raison de l'évolution des besoins des entreprises, des progrès technologiques ou des nouvelles politiques
internes et externes. Il est donc essentiel que le programme de cybersécurité soit revu et amélioré régulièrement
dans le cadre du processus de gestion du changement de l’organisme afin de s’assurer que les nouvelles
informations sont documentées et que les mesures de sécurité sont révisées si nécessaire.
Règle générale, le plan devrait être révisé pour assurer son exactitude et son exhaustivité, et ce, à une fréquence
définie par l’organisme ou chaque fois que des changements touchent un élément du plan. Certains éléments
peuvent nécessiter des revues plus fréquentes.
Alors que toutes les stratégies devraient être revues de manière continue, la fréquence à laquelle le programme
de cybersécurité de l’organisme doit être revu dépend de la nature, de la taille et de la complexité de l’organisme,
de son profil de risque métier et de l’environnement dans lequel il opère. Les bonnes pratiques indiquent qu’une
revue de la stratégie de l’organisme devrait être faite au moins tous les 12mois, sauf dans les cas suivants:
Il s’agit du développement et de la documentation initiale de la stratégie.
Il y a un changement significatif dans la technologie clé ou dans les télécommunications, y compris les
systèmes et les réseaux.
Le rythme des changements affectant l’activité de l’entreprise est particulièrement agressif.

113/146
114/146
Les informations documentées sont la pierre angulaire du bon fonctionnement du programme de cybersécurité.
En cas de crise, il est important d’avoir une documentation complète et à jour pour permettre aux acteurs
impliqués dans une urgence de suivre une liste d’actions plutôt que d’avoir à décider en improvisant ou par
intuition.
La bonne conservation des informations documentées élimine dans une large mesure la possibilité de prendre
des décisions spontanées. Il prépare simplement les principaux acteurs à agir lorsque la situation l’exige, en
donnant des conseils et en évitant autant d’erreurs que possible.
Le programme de cybersécurité est un système dynamique et un changement continu est impératif. En
conséquence, l’information documentée doit être adaptée à chaque fois que se produit un changement.

115/146
116/146
Il convient que le responsable du programme de cybersécurité enregistre les améliorations ou les modifications
en utilisant un journal des modifications, qui indique le numéro de page, la description de la modification, la date
de la modification et la signature de la personne responsable.

117/146
Exercice 16 : Amélioration continue
Que convient-il qu'un organisme fasse pour assurer l'amélioration continue de son programme de
cybersécurité ? Élaborez votre réponse.


118/146
Grâce à l'amélioration continue, les organismes peuvent réaliser leurs politiques et leurs objectifs.
Il convient que tout organisme améliore en permanence l'efficacité de son programme de cybersécurité en
définissant les facteurs de changement à surveiller, en assurant la mise à jour permanente des
informations documentées et en documentant ces améliorations.
L'amélioration continue aide les organismes à accroître leur efficacité et la satisfaction de leurs clients, à
réduire les erreurs et à renforcer l'efficacité des mesures de contrôle.

119/146
La présente section décrit le protocole de certification et le processus de certification PECB.

120/146
La certification «Foundation» reconnaît que la personne comprend les concepts de base, méthodes et
techniques utilisés dans un programme de cybersécurité.
Les principales certifications des managers:
1. La certification « Certified Provisional Manager »reconnaît que la personne possède les connaissances
de base pour participer à la mise en œuvre d’un programme de cybersécurité.
2. La certification « Certified Manager »reconnaît que la personne possède les connaissances nécessaires
pour participer à la gestion d’un programme de cybersécurité
3. La certification « Certified Lead Implementer »reconnaît que la personne maîtrise les connaissances
nécessaires pour gérer un programme de cybersécurité en et possèdent les compétences nécessaires
pour gérer une équipe de cybersécurité.
4. La certification « Certified Senior Lead Manager » s’adresse aux professionnels qui ont une vaste
expérience en cybersécurité.
La certification « Master » reconnaît que les détenteurs maîtrisent les concepts, les approches, les méthodes et
les techniques de mise en œuvre et de gestion d'un programme de cybersécurité et d'un plan de management
des incidents.

121/146
Passer l’examen n’est pas le seul préalable pour obtenir la certification «PECB Certified ISO/IEC27032
Lead Cybersecurity Manager». Les justificatifs d'expérience professionnelle seront également pris en compte.
Si les candidats ont réussi l'examen mais n'ont pas le niveau d'expérience requis, ils ne pourront pas prétendre à
la certification « PECB Certified ISO/IEC 27032 Lead Cybersecurity Manager ».
Note importante: Les frais d’examen et de certification sont inclus avec la formation: Les candidats n'auront
donc pas à payer de frais supplémentaires lorsqu'ils présenteront une demande de certification à leur niveau
d'expérience correspondant et recevront l'une des certifications professionnelles : PECB Certified ISO/IEC 27032
Provisional Cybersecurity Manager, PECB Certified ISO/IEC 27032 Cybersecurity Manager ou PECB Certified
ISO/IEC 27032 Lead Cybersecurity Manager.

122/146
Après avoir assisté à la formation et soumis le Formulaire d’évaluation de la formation, une attestation
d’achèvement de formation sera générée dans votre Tableau de bord monPECB, sous l’onglet Mes formations.
L’attestation d’achèvement de formation est valable pour 31unités de FPC (formation professionnelle continue).
Note : Il est important de ne pas confondre l'attestation d'achèvement de formation avec le certificat proprement
dit. La première est uniquement une confirmation de la participation à une formation, et non l'obtention d'un
certificat. Pour obtenir un certificat, les candidats devront passer l'examen, faire une demande de certification, et
être certifiés une fois l'évaluation de la demande approuvée.

123/146
Le Comité d’examen de PECB doit s’assurer que l’élaboration et le caractère adéquat des questions d’examen
sont maintenus en fonction des pratiques professionnelles actuelles.
L’examen est disponible en plusieurs langues. Pour passer l’examen dans une langue particulière, veuillez
demander au formateur, ou nous contacter en envoyant un e-mail à examination@pecb.com.
Tous les domaines de compétence sont couverts par l’examen. Pour obtenir une description détaillée de chaque
domaine de compétence, veuillez consulter le site Web de PECB: www.pecb.com.

124/146
Pour les examens à choix multiple et à livre fermé, les candidats ne sont pas autorisés à utiliser de documents
de référence. Les examens Foundation et Transition sont généralement de ce type.
Pour les examens à développement, à livre ouvert et à choix multiple, à livre ouvert, les candidats sont
autorisés à utiliser les documents de référence suivants :
Copie imprimée de la norme principale
Support de formation (accessible via l'application PECB Exams ou imprimé).
Notes personnelles prises pendant la session de formation (accessible via l'application PECB Exams ou
imprimée).
Dictionnaire au format papier
Les examens à choix multiple à livre ouvert comprennent à la fois des questions indépendantes et des questions
basées sur des scénarios, également appelées items. Un item est une unité unique composée d'une question et
de trois options utilisées pour évaluer la compétence d'un candidat dans un examen à choix multiple. Une seule
des options est correcte.
Quelle est la différence entre les questions indépendantes et les questions basées sur un scénario ?
Les items indépendants sont autonomes dans l'examen et ne dépendent pas du contexte, tandis que les items
basés sur un scénario dépendent du contexte, c'est-à-dire qu'ils sont développés sur la base d'un scénario que le
candidat doit lire et auquel il doit répondre par un ou plusieurs items liés à ce scénario.

125/146
Les examens sont corrigés par des correcteurs qualifiés qui sont assignés de façon anonyme.
Afin de garantir l’indépendance, l’impartialité et l’absence de conflits d’intérêts, les formateurs et les surveillants
ne participent pas au processus de correction des examens ni au processus de certification.
Si le candidat échoue à l’examen, une explication lui sera fournie sur les domaines dans lesquels il n’a pas
démontré les compétences requises. Pour ce faire, le candidat doit communiquer avec le responsable de
l’organisme de formation.

126/146
Après avoir réussi l’examen, le candidat dispose d’une période maximale de troisans pour soumettre un dossier
professionnel afin d’obtenir un certificat professionnel relatif au programme de certification ISO/IEC27032. Un
candidat peut postuler pour plus d’une certification liée au programme de certification ISO/IEC27032 (p. ex.
Cybersecurity Manager or Lead Cybersecurity Manager) en même temps s’il répond à toutes les exigences.
Dans votre demande, vous devrez fournir les informations suivantes:
1. Vos cordonnées
Veuillez écrire votre nom tel que vous souhaitez qu’il apparaisse sur votre certificat (en format
ASCII). Avant de soumettre votre demande de certification, veuillez vous assurer de vérifier
l’exactitude des coordonnées que vous avez fournies lors de la création de votre compte PECB. Le
certificat sera délivré avec le nom que vous avez fourni lorsque vous avez créé le compte. Pour
mettre à jour votre nom dans votre compte PECB, veuillez nous contacter à l’adresse
customer@pecb.com.
2. Les preuves de leur expérience professionnelle et en matière de programmes
Vous devez fournir un CV pour présenter votre expérience. L’expérience professionnelle peut être
toute activité démontrant que vous possédez des compétences et des connaissances générales sur
le fonctionnement d’un organisme.
Pour l’expérience du programme, veuillez vous assurer d’indiquer le nombre d’heures effectuées.
Les diplômes d'études ou autres ne remplacent pas l'expérience de travail réelle
3. Au moins deux références
Les références (collègues, partenaires, superviseurs, etc.) fournies par les candidats doivent
confirmer leur expérience. Il est important que les références (ces personnes) connaissent
suffisamment le candidat pour attester de ses compétences.
Votre demande sera évaluée une fois que les références auront été soumises.
Note : Il n'est pas nécessaire de fournir des références pour les certifications Foundation, Transition
et Provisional.

127/146
128/146
Vos références seront contactées pour remplir un court questionnaire visant à attester votre expérience et
évaluer vos qualités personnelles.
Vous pouvez vérifier si vos références ont répondu sur votre compte de membre de PECB sous l’onglet Mes
certifications. Si leurs réponses tardent, vous devriez les relancer pour vous assurer qu’ils aient reçu la
demande de référence.
Dans le cas où PECB serait incapable de communiquer avec une de vos références ou qu’ils n’aient pas
répondu au questionnaire, il vous sera demandé de fournir d’autres références.

129/146
Lorsque le candidat est certifié, il reçoit un avis du système et peut télécharger le certificat à partir de son compte
PECB. Le certificat est valable trois ans. Au-delà de cette période, la certification sera renouvelée si le
demandeur remplit les conditions pour maintenir sa certification.
En plus du certificat, le candidat pourra également réclamer son badge numérique sur Credly et le partager sur
les médias sociaux.

130/146
131/146
132/146
Pour obtenir des informations sur les autres certifications, veuillez consulter notre Politique de maintien de la
certification.

133/146
134/146
Par exemple, si une certification a été délivrée le 2019-01-15 et est valable jusqu'au 2022-01-15, les exigences
suivantes s'appliquent :
Premiers FAM : du 2019-01-15 au 2020-01-15 – Aucun paiement de FAM requis.
Deuxièmes FAM : du 2020-01-15 au 2021-01-15 – Paiement des FAM exigé
Troisièmes FAM : du 2021-01-15 au 2022-01-15 – Paiement des FAM exigé
Si le professionnel certifié ne remplit pas l'une ou l'autre de ces exigences de FPC ou de FAM, la certification
sera déclassée.

135/146
Dans votre Tableau de bord monPECB, sous l'onglet Mes formations, vous trouverez la liste des formation que
vous avez suivies et auxquelles vous êtes actuellement inscrit. Lorsque vous aurez terminé la formation, il vous
sera demandé de remplir le Formulaire d'évaluation de la formation. Vous pouvez soumettre votre évaluation en
cliquant sur le lien Évaluation de la formation. Après avoir soumis le Formulaire d'évaluation de la formation,
une Attestation d'achèvement de formation sera disponible et vous pourrez la télécharger.
L'application Kate est un autre moyen de fournir un retour d'information sur les supports de formation.
Nous nous efforçons d’améliorer constamment la qualité et la pertinence pratique de nos formations. Dans cette
optique, votre opinion quant à la formation que vous venez de suivre a pour nous une grande valeur.
Nous vous serions très reconnaissants de bien vouloir donner votre appréciation de la formation et des
formateurs.
De plus, si vous avez des suggestions pour améliorer le support de formation de PECB, n’hésitez pas à nous en
faire part. Veuillez ouvrir un ticket à l’intention du Service de formation sur le site Web de PECB
(www.pecb.com) dans la section Contactez-nous. Nous lisons et évaluons attentivement les commentaires que
nous recevons de nos membres.
En cas d’insatisfaction à l’égard de la formation (formateur, salle de formation, équipement, etc.), de l’examen ou
des processus de certification, veuillez ouvrir un ticket dans la catégorie Déposer une plainte du site Web de
PECB (www.pecb.com), dans la section Contactez-nous.

136/146
137/146
Pourquoi poursuivre votre parcours universitaire avec l'Université PECB ?
Des spécialisations uniques : Les programmes de l'Université PECB vous donnent l'occasion d'explorer
certains des sujets les plus passionnants d'aujourd'hui en offrant des spécialisations prometteuses qui
vous aident à améliorer vos perspectives de carrière.
Des programmes flexibles : Les programmes de l'Université PECB sont conçus pour répondre aux
besoins spécifiques de l'individu occupé. Nos programmes vous offrent la possibilité de devenir compétitif
tout en conservant vos obligations actuelles.
Une éducation de classe mondiale : Des universitaires compétents qui, outre leurs qualifications
académiques, ont une expérience pratique des sujets qu'ils enseignent, contribueront à votre éducation.
Grâce à leur expérience internationale, vous aurez une vision plus large des questions actuelles et
adopterez un état d'esprit qui vous permettra d'aborder les situations sous divers angles.
Des rencontres internationales : L‘Université ne connaît pas de frontières physiques. Vous aurez donc
des possibilités illimitées de créer des réseaux et d'entrer en contact avec la communauté universitaire,
composée d'étudiants et de membres du personnel venant d'horizons différents.
Expérience numérique : Vous bénéficierez d'un enseignement dispensé sur des systèmes qui vous
permettront de vous connecter et de partager en ligne tout en profitant de votre confort.
Un parcours accéléré vers le diplôme : L‘Université propose une politique généreuse de transfert de
crédits qui vous permet de vous dispenser de certains cours et de progresser plus rapidement vers votre
diplôme.
Les candidats qui détiennent des certificats PECB valides correspondant aux exigences du programme
universitaire qui les intéresse peuvent transférer ces crédits afin de recevoir des crédits complets pour le
programme en question. Pour plus d'informations sur l'Université PECB ou le transfert des crédits de certificats,
veuillez contacter university@pecb.com.

138/146
Le PECB Store est la boutique en ligne de PECB où les clients peuvent acheter diverses normes internationales
ISO et IEC, les Toolkits et eBooks de PECB, ainsi que de nombreux autres produits et services connexes qui
seront ajoutés ultérieurement.
Les normes mentionnées dans cette formation sont toutes disponibles sur la boutique PECB. Nous nous
engageons à soutenir la croissance de nos clients, c'est pourquoi nous vous offrons la possibilité d'acheter sur le
PECB Store des produits de qualité et de faire progresser votre carrière professionnelle en appliquant les
connaissances acquises.
Pour plus d'informations, veuillez visiter https://store.pecb.com ou nous contacter à store@pecb.com.

139/146
PECB Certified ISO/IEC 27001 Lead Auditor
La formation ISO/IEC 27001Lead Auditor permet aux participants de développer l’expertise nécessaire à la
réalisation d’un audit de système de management de la sécurité de l’information (SMSI) en appliquant des
principes, procédures et techniques largement reconnus en audit. Au cours de cette formation, le participant
acquerra les connaissances et les compétences nécessaires pour planifier et réaliser des audits internes et
externes conformément au processus de certification selon ISO19011 et ISO/IEC17021-1. Sur la base
d’exercices pratiques, les participants seront en mesure de maîtriser les techniques d’audit et de devenir
compétents pour gérer un programme d’audit et une équipe d’audit.
PECB Certified ISO/IEC 27005 Risk Manager
La formation ISO/IEC 27005Risk Manager permet de maîtriser les fondamentaux du management du risque de
sécurité de l’informationnotamment : la planification d’un programme de management du risque, l'analyse,
l'appréciation, le traitement des risques, la communication et la surveillance des risques. Par des lectures, des
exercices basés sur des cas réels, des discussions et des démonstrations avec des outils de modélisation des
risques, le participant sera en mesure de réaliser une évaluation optimale des risques. Les participants
acquerront également une compréhension approfondie des méthodes d'appréciation des risques telles que
OCTAVE, EBIOS, MEHARI et la TRA harmonisée. Cette formation correspond au processus de mise en œuvre
du cadre du SMSI présenté dans la norme ISO/IEC 27001.

140/146
141/146
Résumé du jour 4
Les thèmes suivants ont été abordés au cours du quatrième jour de cette formation :
Objectifs de la continuité d'activité
Principes de préparation des TIC dans la continuité d'activité (PTCA)
Éléments et phases de la PTCA
Gestion des incidents de cybersécurité
Systèmes et techniques d'essai
Préparation du test et de la documentation
Activités de post-test
Mesure de la performance
Définir ce qui doit être surveillé et mesuré
Mise en place des indicateurs de performance du programme de cybersécurité
Amélioration continue
Maintien et amélioration du programme de cybersécurité
Mise à jour continue de l’information documentée
Documentation des améliorations
Processus de certification

142/146
143/146
144/146
145/146
146/146

LM27032 FR Day4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LM27032 FR Day4

Transféré par

Droits d'auteur :

Formats disponibles

© Professional Evaluation and Certification Board, 2021. Tous droits réservés.

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Durée de l’exercice : 25 minutes

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Durée de l’exercice : 25 minutes

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()

Licensed to PECB France ()