ROYAUME DU MAROC

ADMINISTRATION DE LA DÉFENSE NATIONALE

DIRECTION GÉNÉRALE DE LA SÉCURITÉ DES SYSTÈMES D’INFORMATION

RÉFÉRENTIEL
DE GESTION DES INCIDENTS DE CYBERSÉCURITÉ

Edition 2017
 Référentiel de gestion des incidents de cybersécurité

Sommaire

I. Introduction ....................................................................................................................... 2
1. Contexte ........................................................................................................................... 2
2. Rappel de la chaine d’incident de cybersécurité ................................................................. 3
3. Object du document .......................................................................................................... 3
II. Les phases de gestion d’incident de cybersécurité ......................................................... 4
1. Planification et préparation ............................................................................................... 5
2. Détection .......................................................................................................................... 7
3. Analyse et déclaration ....................................................................................................... 8
4. Réponse à l'incident .......................................................................................................... 9
5. Actions post-incident....................................................................................................... 10
III. Annexes ............................................................................................................................ 11
Annexe A : Catégories des incidents de cybersécurité les plus répandus ................................... 11
Annexe B : Capture du trafic ................................................................................................... 13
Annexe C : Les signes d'un incident et les sources de collecte. .................................................. 14
Annexe D : Vecteurs d’attaques .............................................................................................. 18
Annexe E : Incident relatif à un malware ................................................................................. 19
Annexe F : Incident de déni de service ..................................................................................... 20
Annexe G : Incident de défiguration de site web ...................................................................... 23
Annexe H : Fiche de déclaration d’un incident. ........................................................................ 24
Références ............................................................................................................................. 26

DGSSI 1
 Référentiel de gestion des incidents de cybersécurité

I. Introduction

1. Contexte

Dans un monde ultra-connecté et où les actions de dématérialisation de processus et le

nombre de transactions numériques explosent, les tentations d’utiliser frauduleusement les
multiples points d’interconnexions avec l’extérieur, notamment les accès Internet, augmentent
du jour en jour.

Ainsi, les cyberattaques sont devenues non seulement plus nombreuses et diversifiées,
mais aussi plus nuisibles et perturbatrices.

Il est fondamentale, ainsi, d’identifier et de comprendre les risques susceptibles

d'affecter le système d’information et de développer l'agilité nécessaire pour faire face aux
nouvelles menaces.

De ce fait, la gestion des incidents de cybersécurité est devenue l’un des piliers de la
sécurité des systèmes d’information. Cette activité complexe, requiert de nouvelles expertises
et nécessite l'implication forte des responsables métiers et surtout du top management.

Par ailleurs et pour gérer dans des délais raisonnables tout incident informatique, il est
nécessaire de mettre en place les moyens adéquats pour détecter rapidement ces incidents et
partant réduire la perte et la destruction des données, éliminer les faiblesses exploitées et
restaurer les services assurés par ce système d’information.

C’est à cet effet que l’article 6 du décret n°2-15-712, relatif au dispositif de protection
des systèmes d’information sensibles des infrastructures d’importances vitales, ait invité ces
entités à mettre en place une politique de gestion des incidents et de communiquer au
maCERT tout incident de cybersécurité.

DGSSI 2
 Référentiel de gestion des incidents de cybersécurité

2. Rappel de la chaine d’incident de cybersécurité

Comme illustré dans la norme de gestion des incidents de sécurité de l’information

ISO 27035, la chaine d’incident de cybersécurité se présente comme suit :

 Faille de cybersécurité :
C’est une vulnérabilité dans un système informatique permettant à un attaquant de porter
atteinte à son fonctionnement normal, à la confidentialité et l’intégrité des données qu’il
contient.
 Evénement de cybersécurité :
C’est l’occurrence identifiée de l'état d'un service, d'un système ou d'un réseau indiquant
une faille possible dans la politique de sécurité de l'information ou un échec des mesures
de sécurité ou encore une situation inconnue jusqu'alors et pouvant relever de la sécurité.
 Incident de cybersécurité :
Un ou plusieurs évènements liés à la sécurité de l'information indésirables ou inattendus
présentant une probabilité forte de compromettre les activités de l'organisation et de
menacer la sécurité de l'information. De ce fait, il a des impacts sur l’un des critères de
sécurité: Confidentialité, Intégrité, Disponibilité, Auditabilité.
3. Object du document

DGSSI 3
 Référentiel de gestion des incidents de cybersécurité

Le présent document détaille les exigences à respecter par les entités pour la mise en
place d’un système de gestion des incidents de cybersécurité. Ce système comprend 5 phases
à savoir : planification et préparation, détection, analyse et déclaration, réponse à l’incident et
enfin les actions post-incident.
Les objectifs visés par la mise en place d’un système de gestion des incidents de
cybersécurité sont :
 Neutraliser certains incidents de cybersécurité avant qu’ils ne surviennent ;
 Limiter l’impact des incidents de cybersécurité sur la confidentialité, la
disponibilité ou l’intégrité des services, des actifs informationnels et des activités
de l’entité ;
 Traiter les menaces et les vulnérabilités dès l’occurrence d’un incident de
cybersécurité;
 Améliorer la coordination et la gestion des incidents de cybersécurité entre les
entités et la DGSSI ;
 Réduire les coûts directs et indirects engendrés par les incidents de cybersécurité.
En outre, ce document détaille le traitement des incidents de cybersécurité les plus
répondus, en l’occurrence : ceux relatifs au malware, au déni de service et à la défiguration
d’un site web.

II. Les phases de gestion d’incident de cybersécurité

La gestion d’un incident de sécurité ne s’improvise pas. Il est donc important de
procéder de façon structurée afin de concilier efficacité et rapidité, tout en conservant une
démarche d’amélioration continue. Le schéma ci-après illustre les cinq phases de gestion
d’incident :

DGSSI 4
 Référentiel de gestion des incidents de cybersécurité

1. Planification et préparation
Comme les atteintes à la sécurité sont de plus en plus sophistiquées, le maCERT
estime qu’un nombre important des incidents demeure non décelé. Ceci est dû, d’une part, à
l’absence de déploiement de méthodes de prévention avérées et de moyens de détection et de
contrôle en matière de cybersécurité, et d’autres part, au manque de compétences techniques.
Ainsi, planifier et préparer une politique et un plan de gestion d’incident de
cybersécurité s’avère indispensable pour une détection et une réponse efficaces aux incidents.
La politique de gestion des incidents de cybersécurité doit fournir les principales démarches
formellement documentées pour assurer une mise en œuvre cohérente et appropriée des
processus et procédures. Elle doit faire partie de la stratégie de sécurité de l'information de
chaque entité et doit être conforme à la politique et aux procédures appliquées par l’entité.
L’élaboration et la mise en place d’une politique de gestion des incidents de
cybersécurité exigent l’élaboration au préalable d’une politique de sécurité des systèmes
l’information. Celle-ci doit respecter les lignes directrices suivantes :
 Obtenir l’appui du top management à l’égard de la politique de gestion des incidents
de cybersécurité ;
 Vérifier l’adéquation de la politique de sécurité de l’entité avec la Directive Nationale
de la Sécurité des Systèmes d’Information (DNSSI) ;
 Mettre à jour la politique de sécurité du système d’information de l’entité ainsi que la
politique de gestion des incidents dès qu’un changement majeur, ayant un impact sur
la cartographie des risques, est opéré sur le système d’information;
 Mettre sur pied une équipe de réponse aux incidents et lui assurer un programme de
formation approprié ;
 Déployer des méthodes et des équipements de détection des incidents et de contrôle
(équipements de sécurité, gestion des correctifs, évaluation des vulnérabilités,…) ;
 Définir le but, les objectifs et la portée de la politique de gestion des incidents ;
 Décrire les catégories et les types des incidents de cybersécurité (Voir Annexe A) ;
 Définir et décrire la criticité de ces incidents ;
 Elaborer des plans d’actions par type d’incident et aviser en conséquence les parties
concernées ;
 Définir les rôles et les responsabilités pour chaque phase du processus de gestion des
incidents de cybersécurité ;
 Identifier les entités externes pouvant assister dans la réponse aux différents
incidents ;
 Définir les canaux de communication avec les entités externes et formaliser, si
nécessaire, des contrats de supports et de maintenances;
 Mettre en place des mécanismes pour permettre aux parties externes de signaler des
incidents et surveiller attentivement ces mécanismes. Il s’agit de mettre à disposition
du public une adresse mail, un numéro de téléphone au niveau du site web, page jaune
et la base Whois ;
 Planifier des tests réguliers de vérification des processus et procédures de la gestion
des incidents de cybersécurité.

DGSSI 5
 Référentiel de gestion des incidents de cybersécurité

Pendant la phase de préparation, chaque entité vise également à limiter le nombre

d'incidents qui pourraient se produire en sélectionnant et en mettant en œuvre un ensemble de
contrôles et mesures basés sur les résultats des évaluations des risques. Le but est d’être en
mesure de prévenir les incidents tout en gardant les systèmes, les réseaux et les applications
suffisamment sécurisés.
Par ailleurs, garder le nombre d'incidents raisonnablement bas est très important pour
protéger les processus métiers de l’entité. Si les contrôles de sécurité sont insuffisants, un
nombre important et élevé d'incidents peuvent se produire, mettant à mal l'équipe de réponse
aux incidents. Cela peut conduire à des réponses lentes et incomplètes, qui se traduisent par
un impact négatif plus important (par exemple, des dommages plus étendus, les périodes
d'indisponibilité de service et de données plus longues).
Bien que les équipes de réponse aux incidents ne soient généralement pas responsables
de la sécurisation des ressources, elles peuvent émettre et faire valoir les bonnes pratiques de
sécurité suite à l'identification des défaillances et des problèmes que l’entité ignore.
Cependant, la DGSSI recommande aux différentes entités l'application en fonction de
leur environnement des principales pratiques énumérées ci-dessous pour sécuriser leurs
réseaux, systèmes et applications:
 Évaluation des risques

L’évaluation périodique des risques des systèmes et des applications doit déterminer
quels sont les risques posés par des combinaisons de menaces et vulnérabilités. Cela
devrait inclure la compréhension des menaces, y compris ceux spécifiques à l’entité.
Chaque risque doit avoir une priorité, et doit être traités, transféré, ou accepté. Le but
est d’atteindre un niveau global de risque raisonnable. L'équipe de gestion des
incidents doit avoir connaissance de cette évaluation pour la prendre en compte lors de
la priorisation des incidents.
Cette évaluation régulière des risques permet aussi d’identifier les ressources critiques
sur lesquelles les activités de surveillance et d'intervention devraient se focaliser en
priorité.
 Sécurité des postes utilisateurs

Tous les postes utilisateurs doivent être endurcis de manière appropriée en utilisant des
configurations standard. En plus de garder chaque poste à jour en installant les mises à
jour appropriées le mieux via une solution centralisée, les postes doivent être
configurés pour adopter le principe du moindre privilège par l'octroi aux utilisateurs
des privilèges nécessaires à l'accomplissement de leurs tâches autorisées. Ces postes
devraient avoir l' « auditing » activé et devraient générer les événements (log)
importants liés à la sécurité. Considérant les menaces actuelles et les méthodologies
des attaquants, la sécurité des postes utilisateurs et leurs configurations doivent être
surveillées en permanence. Aussi, le système de sécurité doit aussi être capable de
fournir des contrôles robustes pour gérer les utilisateurs à privilèges.
 Sécurité réseau

DGSSI 6
 Référentiel de gestion des incidents de cybersécurité

L'architecture du réseau ainsi que les équipements de sécurité (Firewalls, Proxy, ...)
doivent être configurés pour refuser toute activité qui n'est pas expressément autorisée.
Cela inclut le cloisonnement entre les utilisateurs et aussi entre les applications en
fonction de l'évaluation des risques tout en considérant que les utilisateurs internes et
les applications peuvent être des sources potentielles de menace. Les connexions
établies avec les succursales ou les partenaires qui empruntent des réseaux publics (
LS, ADSL, MPLS, VPN opérateur, …) doivent être chiffrées de bout en bout.
 Prévention contre les malwares
Les solutions pour détecter et arrêter les logiciels malveillants doivent être déployées à
tous les niveaux de l'entité (Postes utilisateurs, serveurs, proxy web et messagerie, …)
et les alertes générées doivent déclencher immédiatement le processus de traitement
des incidents. Ces solutions nécessitent des mises à jour quotidiennes pour qu'elles
soient efficaces.
 Sensibilisation et formation des utilisateurs
Les utilisateurs doivent être informés des politiques et procédures concernant
l'utilisation appropriée des réseaux, des systèmes et des applications. Ils doivent être
sensibilisés sur les nouvelles modes d’attaques, principalement le phishing qui
constitue souvent le vecteur d’attaque initial des cyberattaques. Les enseignements
tirés des incidents précédents devraient également être partagés avec les utilisateurs
afin de réduire la fréquence des incidents. Un utilisateur vigilant capable de déceler
certains évènements anormaux et de les remonter est considéré comme la meilleure
barrière de sécurité.
Un plan de formation annuel, au profit du personnel du département informatique
(administrateurs, développeurs, ..), doit être programmé et exécuté afin qu'ils puissent
maintenir leurs réseaux, systèmes et applications en conformité avec les normes de
sécurité de l'entité et en fonction des nouvelles menaces et tendances.

2. Détection
La phase de détection consiste à déceler un événement susceptible de constituer un
incident de cybersécurité et d’en informer les responsables des systèmes touchés et de
déclencher le processus de réponse à l'incident.

De façon générale, lors de la phase de détection l’entité doit entreprendre les actions
clés suivantes:

 Journaliser l'activité système et réseau de l'entité ;

 Collecter des informations permettant d'assurer une connaissance de la situation à
partir de sources de données internes et externes, y compris :
 le système local, le trafic réseau et les journaux d'activités,
 la capture de trafic des segments critiques (voir Annexe B) ;
 les nouvelles actualités concernant le domaine politique, social ou économique
qui pourraient avoir un impact sur des incidents relatifs à l'entité,

DGSSI 7
 Référentiel de gestion des incidents de cybersécurité

 les flux d'informations externes sur les tendances, les indicateurs et les
nouveaux vecteurs d'attaques et sur les nouvelles stratégies et technologies
d'atténuation;
 Disposer des outils de détection et les configurer selon les risques et menaces qui
pèsent sur l’entité;
 Assurer un suivi et monitoring permanent par l’équipe de sécurité ;
 Détecter et signaler l'occurrence d'un événement de sécurité de l'information ou
l'existence d'une vulnérabilité, que ce soit manuellement ou automatiquement;
 Surveiller les alertes transmises par les systèmes de sécurité internes ;
 Surveiller les rapports d’activités anormales soumis par les utilisateurs ;
 Surveiller l’information communiquée et les alertes diffusées par les organismes
spécialisés dans la détection des incidents de cybersécurité et la réponse aux attaques
informatiques (maCERT, prestataires…) ;
 Rapporter les activités anormales à l’équipe de réponse aux incidents.
 Veiller à ce que les preuves numériques soient collectées et stockées en toute sécurité.
Dans le cas où ces preuves seraient requises pour des poursuites judiciaires ou pour
des mesures disciplinaires internes, celles-ci doivent être conservées et surveillées en
permanence
 Veiller à suivre une procédure de gestion des changements pour assurer la surveillance
et la mise à jour des systèmes de détection mis en place;
 Escalader au niveau supérieur, au besoin, tout au long de cette phase, pour une
évaluation plus approfondi ou pour les prises de décisions.

Pour pouvoir mettre en place les recommandations susvisées et réussir la phase de

détection, il est primordial pour chaque entité de comprendre les signes d'un incident et
pouvoir les collecter à partir des différentes sources disponible au sein de l’entité en fonction
de son secteur d'activité. Pour plus de détails concernant les signes d’incidents ainsi que les
sources de collectes veuillez se référer à l’annexe C.
3. Analyse et déclaration
Cette phase repose sur l’évaluation des événements de cybersécurité décelés pendant
la phase de détection. Cette évaluation vise à déterminer s'il s'agit réellement d'un incident de
cybersécurité, de déterminer son incidence et son envergure, son impact ainsi que la cause
probable de l'incident.
Les tâches à accomplir lors de cette phase se présentent comme suit:
 Evaluer l’événement et confirmer qu’il s’agit d’un incident ;
 Désigner les personnes responsables de l’incident ;
 Déterminer le type de l’incident ;
 Déterminer le vecteur d’attaque susceptible (Cf. Annexe D);
 Déterminer les données, systèmes ou réseaux touchés ;
 Cerner l’impact sur la confidentialité, l’intégrité et la disponibilité ;
 Aviser les personnes compétentes.

DGSSI 8
 Référentiel de gestion des incidents de cybersécurité

Après l’analyse de l’incident, chaque entité doit communiquer au maCERT, le plutôt

possible, les informations relatives à cet incident. Elle doit également fournir les informations
complémentaires demandées par le maCERT. Cette notification doit se faire en remplissant le
formulaire en « annexe H », téléchargeable sur le site web de la DGSSI :
http://www.dgssi.gov.ma/fr/macert/declaration-dincidents.html.
Le formulaire renseigné doit être envoyé à l’adresse suivante : [email protected]
4. Réponse à l'incident
Conformément aux actions menées durant la phase analyse et déclaration, cette étape
consiste à apporter les réponses adéquates aux incidents de cybersécurité détectés..
Une fois qu'un incident de cybersécurité est confirmé, les activités suivantes doivent
être exécutées:
 Attribuer les responsabilités et les rôles aux différents membres de l'équipe
d’intervention interne ou externe ou mixte ;
 Elaborer des procédures formelles à suivre pour chaque personne impliquée dans
l'incident ;
La première phase d’une réponse à incident est l’acquisition des preuves de
compromission. Les analystes doivent reconstituer le scénario complet d’attaque (Exploitation
d’une vulnérabilité, élévation de privilèges, exfiltration de données…). Les évidences
collectées doivent être stockées en toute sécurité. L'acquisition des données peut se faire :
 à chaud, sur un système en marche (on parle de « live forensics ») : La réponse à
chaud permet de mener des investigations en collectant des « artefacts » sur des
systèmes en marche. A ce stade, les détails de la menace sont toujours inconnus, il
faut donc commencer par identifier et quantifier la menace à travers la collecte des
informations nécessaires à l’investigation, à savoir :
 la mémoire volatile ;
 les « prefetch files » ;
 les clés de registre ;
 les connexions réseau ouvertes ;
 les comptes système ;
 etc
Cette action est très efficace dans le cas où on est confronté à une infection ou une
intrusion qui touche un parc informatique étendu. A titre indicatif, l'outil
« FastIR » permet de collecter ces informations.
 à froid, sur un système éteint : Cette manière d'acquisition des évidences est très
couteuse en termes de temps. Elle repose sur la création d'une image du disque
authentique à celle utilisé par le système compromis. Cette action est primordiale
dans le cas où on est sûr que la machine cible est compromise.
Après analyse des informations relatives à l’incident, il faut lancer la procédure de
restauration et d’éradication qui consiste à :

DGSSI 9
 Référentiel de gestion des incidents de cybersécurité

 Supprimer tous les éléments et évidences associés à l’incident ;

 Corriger toutes les vulnérabilités exploitées par l’attaquant;
 Restaurer à partir d’une sauvegarde saine ou réinstaller le système en entier ;
 Déterminer la source du problème pour sécuriser d’avantage le système.
Après le traitement d'un incident, un rapport de synthèse des résultats de l'investigation
doit être rédigé et doit être communiqué à toutes les parties concernées.
En cas d’incident majeur, chaque entité doit transmettre au maCERT, dans le mois qui
suit, une synthèse des informations recueillies et des actions entreprises. Le maCERT peut
apporter son assistance pour aider à identifier le scénario d’attaque.
Pour plus de détails concernant la réponse aux incidents, les annexes E, F et G traitent
respectivement les incidents relatifs aux malwares, au déni de service et à la défiguration des
sites web.
5. Actions post-incident
Après le traitement d’un incident, l'entité doit passer en revue l’ensemble des décisions
prises et les étapes suivies tout au long du cycle de traitement de l’incident afin de déterminer
les points à l’égard desquels des améliorations devraient être apportées.
En outre, des réunions périodiques doivent être programmées pour identifier et
corriger les faiblesses systémiques et les lacunes identifiées dans les politiques et les
procédures adoptées.
Enfin, les rapports de suivi pour chaque incident résolu doivent être exploités pour
mieux traiter les futurs incidents et utilisés comme cas d’études dans la formation des
nouvelles recrues.

DGSSI 10
 Référentiel de gestion des incidents de cybersécurité

III. Annexes

Annexe A : Catégories des incidents de cybersécurité les plus

répandus
Catégorie d’incident Type d’incident Description
Atteinte à la disponibilité DOS Attaque informatique ayant
DDOS pour but de rendre
Sabotage indisponible un service,
d'empêcher les utilisateurs
légitimes d'un service de
l'utiliser. La disponibilité
peut également être affectée
par des actions locales
(destruction, perturbation de
l'alimentation électrique,
etc.).
Infection Virus, Ver, Trojan, Un code malicieux qui est
Ransomware, Backdoor… intentionnellement inclus ou
inséré dans un système à des
fins nocives. L’interaction de
l’utilisateur est normalement
nécessaire pour activer le
code.
Tentatives d'intrusion Exploitation des Une tentative de
vulnérabilités compromettre un système ou
de perturber un service en
exploitant des vulnérabilités
(ex. Buffer overflow, XSS,
Sql injection, file upload
etc.).
Tentatives de connexion Plusieurs tentatives de
connexion (deviner / craquer
des mots de passe, force
brute).
Phishing le but est de dérober des
informations personnelles
des utilisateurs ou de les
piéger à installer un malware
Nouvelle signature d'attaque Une tentative d'exploit
inconnu.

DGSSI 11
 Référentiel de gestion des incidents de cybersécurité

Catégorie d’incident Type d’incident Description

Intrusion Compromission d’un compte Contrôle réussi d’un compte
Ajout d’un compte
Changement des droits
d’accès ou de mot de passe
Défiguration d’un site web Insertion, modification ou
suppression d’un contenu
web
Collecte d’informations Scan Attaques qui envoient des
requêtes à un système pour
découvrir des points faibles.
Ce type d’attaque inclut
certains types de processus
de test pour collecter des
informations sur les hôtes,
les services et les comptes.
Exemples: fingerd, requête
DNS, ICMP, SMTP (EXPN,
RCPT, ...).
Sniffing Capture et enregistrement du
trafic réseau.
Ingénierie sociale Collecte des informations
d'un être humain dans un
environnement non technique
(P. Ex. Mensonges, astuces,
pots de vin ou menaces)
Atteinte à la sécurité des Accès ou modification non
données autorisée des informations
Exfiltration des données Récupération des données et
leur transfert vers une
destination externe non
légitime.
Autres Tous les incidents qui ne
correspondent pas à l'une des
catégories données ci-dessus
doivent être classés dans
cette classe.

DGSSI 12
 Référentiel de gestion des incidents de cybersécurité

Annexe B : Capture du trafic

La capture du trafic permet l’enregistrement complet et permanent du trafic, elle peut

être assimilée à une caméra de sécurité qui surveille l'entrée et la sortie d'un immeuble.

La plupart des outils de sécurité réseau reposent sur un modèle de sécurité passif qui
se base sur des signatures spécifiques pour détecter le trafic malveillant. Le problème majeur
de ce modèle est son inefficacité face aux exploits Zero-Day, qui sont tout simplement de
nouveaux programmes malveillants ou attaques informatiques qui ne sont pas encore connu
publiquement et partant les signatures permettant leurs détections ne sont pas encore
disponibles.

D’où l’importance de la capture du trafic qui permet à un analyste de sécurité

d'examiner toutes les communications du système pour détecter d’éventuelles actions
malveillantes non détectées par les autres moyens de sécurité mis en place. Cette capture
permet aussi la rétrospection du trafic pour déterminer éventuellement si une exploitation a eu
lieu avant la publication des signatures ou avant l'application d'un patch. Les données
recueillies peuvent également être utilisées afin d’enrichir les signatures de détection et
parfois pour extraire les exploits ou les malwares utilisés lors de l’attaque.

Le déploiement d'un système complet de capture de paquets dépend de l'architecture

du réseau et l’objectif visé. La mise en œuvre réussie de ce système repose sur trois facteurs:

 les exigences propres à l'entité notamment le temps minimal de conservation de traces

et les emplacements des points de capture ;
 l'envoi du trafic non altéré au système de capture de paquets en respectant les
exigences de sécurité ;
 le dimensionnement du système de capture pour pouvoir traiter et stocker l’ensemble
du trafic souhaité.

Il existe une variété de solutions « open source » et commerciales pour implémenter

cette capture. Certaines solutions sont des logiciels à installer sur du hardware préparé par
l’entité. D’autres solutions sont entièrement intégrées dans Appliances (hardware et software).
Le choix de la solution de capture à mettre en place dépendra de l’architecture de
déploiement, des compétences de l’équipe, du budget disponible et des exigences pour la
préservation des données.

DGSSI 13
 Référentiel de gestion des incidents de cybersécurité

Annexe C : Les signes d'un incident et les sources de collecte.

Les signes d'un incident

La partie la plus difficile du processus de réponse aux incidents est la précision lors de
la détection et la validation des incidents probables en déterminant si un incident a eu lieu et,
le cas échéant, le type, l'étendue et l'ampleur du problème. Cette difficulté est due à la
combinaison de trois facteurs:

 Les incidents peuvent être détectés par de nombreux moyens, avec des niveaux
différents de détail et de précision. Les incidents peuvent être détectés par des moyens
automatisés (IDPS, les logiciels antivirus, SIEM, …) comme ils peuvent être signalés
par les utilisateurs. Certains incidents ont des signes manifestes qui peuvent être
facilement détectés, alors que d'autres sont difficilement détectables.

 Le nombre de signes potentiels d'incident est généralement élevé. Il est fréquent pour
une entité de recevoir quotidiennement des centaines d'alertes, générées par les
systèmes de détection. Un nombre important d’entre eux sont des faux positifs.

 Une analyse efficiente des données liées à l'incident nécessite des compétences
techniques spécifiques avancées ainsi qu’une large expérience dans ce domaine.

Les signes d'un incident peuvent soit:

 Annoncer la probabilité ou les prémices d’occurrence d'un incident. L'entité peut

éviter l'incident en modifiant sa posture de sécurité afin de protéger la cible objet de
l’attaque. Sinon l’entité peut au moins surveiller l'activité liée étroitement à la cible. Ces
signes sont relativement rares on citera comme exemples :

 Les logs de serveur Web qui indique l'utilisation d'un scanneur de vulnérabilités ;
 L’annonce d'un nouvel exploit qui cible une vulnérabilité au niveau d’un
composant utilisé par l'entité ;
 Une menace émanant d'un groupe indiquant une attaque ciblant l'entité.
 Indiquer qu'un incident a eu lieu ou il est en train de se produire en ce moment. Ce
type de signes est le plus courant. La liste ci-après n’est pas exhaustive:

 Alerte générée par un IPS réseau lorsqu'une tentative de débordement de tampon

se produit sur un serveur ;
 Alerte générée par la solution antivirale ;
 Découverte d’un nom de fichier avec des caractères inhabituels ;
 Changement illégitime de configuration au niveau d’un composant du SI ;
 Des événements d'une application indiquant de multiple échec de tentative de
connexion à partir d'un système distant inconnu ;

DGSSI 14
 Référentiel de gestion des incidents de cybersécurité

 Un administrateur de messagerie voit un grand nombre d'e-mails avec un contenu

suspect ;
 Un administrateur réseau constate un écart inhabituel par rapport au trafic réseau
normal ;
 Les comptes ou les mots de passe ne fonctionnent plus ;
 Le site Internet de l’entité renferme des modifications non autorisées ;
 Il n’y a plus d’espace disque ou de mémoire disponible ;
 Le système gèle à répétition ou se réinitialise de façon imprévue ;
 Les contrôles de sécurité des terminaux, comme les antivirus, ne fonctionnent plus.

Les sources de collecte pour la détection des incidents

Les signes d'incidents sont identifiés à l'aide de nombreuses sources différentes. Les
plus connues sont les solutions de sécurité, les événements de sécurité (log), les informations
publiques, et les personnes. Le tableau ci-dessous répertorie les sources les plus utilisées pour
la détection des incidents.

Source Description

Alertes
IDS/IPS Les IDS/IPS identifient les événements suspects et enregistrent les données
pertinentes à leur égard, entre autres la date et l'heure de la détection de
l'attaque, le type d'attaque et les adresses IP source et destination. La
plupart des produits IDS/IPS se basent sur des signatures pour identifier les
activités malveillantes; la base de données des signatures doit être tenue à
jour pour pouvoir détecter les plus récentes attaques. Les IDS/IPS
produisent de fausses alertes (des faux positifs). Pour minimiser les faux
positifs, un effort important doit être fourni lors de la configuration de
l'IDS/IPS. Les analystes doivent, à cet effet, valider manuellement ces
alertes soit en examinant de près les données justificatives enregistrées ou
en obtenant d'autres données à partir d'autres sources. Pour tirer profit de
ces outils, il est recommandé d’ajouter des signatures spécifiques aux
menaces et risques que l’entité a déjà identifié dans les phases préparation
ou post-incident.

SIEM Le SIEM (Security Information and Event Management) est un point de

concentration des événements de sécurité doté de fonctions d'analyse
intelligente. Il génère des alertes basées sur l'analyse et la corrélation de
plusieurs sources d'événements de sécurité. La collecte de ces événements
doit être très large tout en privilégiant l'équilibre entre les bruits réseau et
les signaux faibles (la qualité d'un SIEM dépend de la qualité de ses
sources). De plus, l'équipe sécurité doit définir les cas d'usages possibles à
savoir les scénarios, les règles de corrélation et de dépassement de seuils.

DGSSI 15
 Référentiel de gestion des incidents de cybersécurité

Par conséquent, la configuration et la personnalisation de ces systèmes est

une tâche complexe et primordiale qui nécessite des compétences
techniques et une bonne connaissance du système d'information à
superviser et qui doit être inscrite dans le temps.

Les Antivirus et Le logiciel antivirus détecte diverses formes de logiciels malveillants,

Antispam génère des alertes, et empêche les logiciels malveillants d'infecter les
machines. Les produits antivirus actuels sont efficaces pour arrêter de
nombreux exemples de logiciels malveillants si leurs signatures sont
tenues à jour. Le logiciel Antispam est utilisé pour détecter les spams
ciblant les boîtes de messagerie des utilisateurs. Le Spam peut contenir
des logiciels malveillants, des attaques de phishing, et autres contenus
malveillants. Une alerte générée par un anti-spam indique des tentatives
d'attaque via E-mail.

Logiciel de Le Logiciel de vérification de l'intégrité des fichiers peut détecter les

vérification modifications apportées aux fichiers importants pendant les incidents. Il
d'intégrité des utilise un algorithme de hachage pour obtenir une somme de contrôle
fichiers cryptographique pour chaque fichier désigné. En recalculant régulièrement
ces sommes de contrôle et en les comparant avec les valeurs précédentes,
les modifications de fichiers peuvent être détectées.

Les services Ils offrent une variété de services d'abonnement et de services de veille et
externes de veille d’alerte. Un exemple, le service de détection externe peut notifier une
et d’alerte entité en cas où ses adresses IP, des noms de domaine, etc, sont associés à
une activité malveillante (source de malware ou de spam, appartient à un
réseau de botnet,…). Certains sites publient en temps réel des listes noires
avec des informations similaires.

Événements (Logs)
Événements Les événements (Logs) des systèmes d'exploitation, des services et des
générés par les applications (en particulier les événements liées à la sécurité) sont souvent
systèmes d'une grande valeur pour la détection et le traitement d'un incident, telles
d'exploitation, les
que l'enregistrement des événements relatifs à l'accès aux comptes et les
services et les
applications actions qui ont été réalisées. Les entités doivent mettre en place des
références exigeant l'activation des logs sur tous les systèmes et surtout
sur les systèmes critiques sans oublier les postes utilisateurs. Ces logs
peuvent être analysés en utilisant des règles de corrélation. Une alerte peut
être générée suite à cette analyse pour indiquer un incident.

Événements des Les événements (Logs) générés par ces équipements identifient les
équipements connexions bloquées et aussi autorisées, même s'ils fournissent peu
d'informations sur la nature de l'activité. Ils peuvent être utiles pour

DGSSI 16
 Référentiel de gestion des incidents de cybersécurité

réseaux et FW identifier les tendances du réseau et faire des analyses comportementales

comme ils peuvent être corrélés avec d'autres événements détectés par
d'autres sources.

NetFlow Les routeurs, les switchs et autres périphériques réseau peuvent fournir ces
métadonnées relatives au protocole TCP/IP. Ces informations sur le flux
réseau, peuvent être utilisées pour identifier des activités anormales
provoquées par des logiciels malveillants, exfiltration de données, et
d'autres actes de malveillance.

Information publique
Informations sur La veille concernant les nouvelles vulnérabilités et nouveaux exploits peut
les nouvelles empêcher certains incidents de se produire et aider à détecter et analyser de
vulnérabilités et nouvelles attaques. Ces informations sont disponibles publiquement au
les nouveaux niveau de différents sites. Elles peuvent être reçues des éditeurs de logiciel
exploits et équipements que l'entité utilise dans le cadre du contrat de maintenance
et de support. Elles peuvent être aussi reçu du maCERT ou à travers un
prestataire de service spécialisé dans ce domaine.

Personnes
Personnel de Les utilisateurs, les administrateurs système, les administrateurs réseau,
l'entité l'équipe sécurité, et d'autres membres de l'entité peuvent signaler des
signes d'incidents. Il est important de valider toutes les notifications et de
recueillir des informations supplémentaires sur l'incident pour aider
l'équipe qui se charge de l'analyse de l'incident.

Personnel externe Les rapports d'incidents qui proviennent de l'extérieur doivent être pris au
à l'entité sérieux. Par exemple, l'entité peut être contacté par une entité qui notifie
qu'un de ces systèmes est en train de l’attaquer. Les utilisateurs externes
peuvent également signaler d'autres indicateurs, comme une page Web
illisible ou un service indisponible. D'autres équipes de réponse aux
incidents peuvent également signaler les incidents. Il est important de
mettre en place des mécanismes pour permettre aux parties externes de
signaler des incidents et surveiller attentivement ces mécanismes. Cela
peut être aussi simple que la mise en place d'un numéro de téléphone et
une adresse e-mail pour transmettre des messages de ce genre.

DGSSI 17
 Référentiel de gestion des incidents de cybersécurité

Annexe D : Vecteurs d’attaques

Les vecteurs ci-dessous ne sont pas destinés à fournir le classement définitif des incidents,
mais plutôt pour être utilisés lors de la définition de procédures spécifiques de
traitement d’incident. Ces procédures sont à définir selon le type vecteur d’attaque utilisé:

 Support externe / amovible: Une attaque exécutée à partir de supports amovibles ou

d’un périphérique.

 Attrition: Une attaque qui emploie des méthodes de brute force pour compromettre,
dégrader ou détruire les systèmes, réseaux ou services.

 Email: Une attaque exécutée par l'intermédiaire d'un message électronique ou une
pièce jointe.

 Utilisation inappropriée: Tout incident résultant de la violation par un utilisateur

autorisé de la politique de sécurité des systèmes d’information de l’entité, excepté les
catégories ci-dessus.

 Attaque composée: Une attaque qui est composée de plusieurs attaques ci-dessus.

 Perte ou vol d'équipement ou sabotage: La perte ou le vol d'un dispositif informatique

ou des médias utilisés par l'entité.

DGSSI 18
 Référentiel de gestion des incidents de cybersécurité

Annexe E : Incident relatif à un malware

L'objectif visé par les attaquants en utilisant des malwares est généralement d'infecter
l'ordinateur d'un ou plusieurs utilisateurs soit pour exfiltrer des données ou accéder au
système d’information de l’entité.

Dans le cas d’un incident relatif à un malware, il faut limiter les dégâts en isolant les
systèmes infectés, généralement en les débranchant du réseau tout en évitant de les atteindre.
Cette décision doit être prise en prenant en compte les risques induits par cette machine sur le
reste du S.I ainsi que l’importance des évidences à collecter.

Il est à noter que souvent les malwares sont délivrés à plus de 98% via un mail de
phishing, ou bien à travers la technique « watering hole attaque». Si on suspecte un mail de
phishing, il faut alors alerter immédiatement les autres utilisateurs voire même le supprimer
de leurs boites au niveau du serveur de messagerie par l’administrateur sans oublier de garder
une copie pour une analyse ultérieure. Dans le cas de « watering hole attaque », il est
important de savoir que les logs du proxy web sont essentiels pour l’investigation technique.
Une fois le site origine de l’infection a été identifié, il faut immédiatement le bloquer et
analyser l’ensemble des machines qui ont consulté ce site web.
En outre, la collecte des évidences doit se faire dans un ordre bien précis à cause de la
volatilité des données que l'on souhaite collecter :
 Capture complète du trafic en utilisant une machine différente de la machine
infectée ;
 Capture de la RAM de machine infectée ;
 Capture du Disque de machine infectée ;
 Collecte des informations Système de machine infectée ;
 Collecte des logs des différents composants du système d’information nécessaires
pour l’investigation de l’attaque.
L'investigation d’un incident révèle l'ensemble des indicateurs de compromission qui
seront les éléments clés de la phase POST-Incident. Ces indicateurs permettraient d’élaborer
des signatures au niveau des systèmes IDS/IPS ou des règles de corrélation au niveau du
SIEM. La communication de ces indicateurs au maCERT/DGSSI lui permettra d’éviter
l’occurrence de cet incident dans d’autres parties prenantes.

DGSSI 19
 Référentiel de gestion des incidents de cybersécurité

Annexe F : Incident de déni de service

Les attaques de déni de service (Denial of Service -DOS) ont pour but de perturber
ou dégrader les services en ligne d'une entité. Pour atteindre cet objectif les attaquants
peuvent :

 Exploiter des failles de sécurité au niveau des composants du SI (réseau,

système, applications, …) en exécutant des requêtes à distance de leurs propres
machines.

 Contrôler plusieurs hôtes sur un ou plusieurs réseaux (botnets), sans que les
victimes en soient informées, pour lancer des requêtes automatisées ciblant les
services en ligne tels que les DNS (Domain Name Services), les sites Web et
les courriels. Il s’agit dans ce cas d’un déni de service distribué (DDOS).

Bien que ces attaques soient très difficiles à empêcher, il existe des stratégies qui
peuvent aider à minimiser leur impact sur l’infrastructure ciblée. Ces stratégies doivent être
prises en compte par les entités dans leurs processus d'évaluation des risques.
Planification et préparation
La planification et la réponse efficaces sont les meilleures mesures préventives contre
les attaques de déni de service. Le temps consacré à la planification et à la préparation va
permettre de réagir en temps opportun et d'annuler les effets voulus de l'attaque pour
maintenir à un niveau opérationnel acceptable les services critiques.
Lors de la planification et la préparation, il est recommandé de prendre en
considération les mesures suivantes :

 Il faut augmenter la résilience du réseau de l’entité contre les activités DDoS en

mettant en œuvre au moins deux liens Internet appartenant à deux FAI
(Fournisseur d’Accès Internet) différents. Cela assure au réseau la redondance des
connexions pour atténuer l’impact de l’attaque.

 Envisager le déploiement des serveurs DNS et des serveurs Web supplémentaires

sur le réseau pour équilibrer la charge résultante des requêtes entrantes, ou préparer
des serveurs de secours en ligne de réserve pour les services critiques. Cela peut
inclure plusieurs serveurs DNS et Web ou des serveurs virtuels qui peuvent être
mis en ligne rapidement lors d’une attaque.

 Dimensionner les ressources système de la plateforme de l’application web pour

qu’elle puisse fonctionner, en temps normal, à 60% de ses capacités.

 S’assurer que le fournisseur d’accès à internet (FAI) dispose d'une connexion

réseau à Internet avec une bande passante suffisante au-dessus des exigences de
l’entité.

 Assurer que le contrat avec l’opérateur:

DGSSI 20
 Référentiel de gestion des incidents de cybersécurité

 Inclut la flexibilité d'augmenter temporairement la bande passante de la

connexion de l’entité à Internet;
 Contient un accord de niveau de service acceptable qui répond aux besoins
du bon fonctionnement des services en ligne ;
 Indique clairement quels sont les processus et les changements réseaux que
l’opérateur doit mettre en place pour surmonter une attaque DDoS.

 Concevoir un processus pour hiérarchiser les services fournis aux clients de

l’entité et identifier les clients primaires légitimes (par exemple, prioriser les
requêtes des adresses nationales par rapport aux demandes internationales).

 Segmenter le réseau afin que les services en ligne sortent par des connexions
réseaux différentes. Par exemple, les transactions commerciales emprunteront une
connexion réseau distincte du réseau de serveurs Web publique. L’utilisation d’une
seule connexion réseau pour transporter tout le trafic des services critiques (accès
à distance, le courrier électronique, l'hébergement Web…) augmentera la
probabilité d’un arrêt total des communications au cours d'une attaque DoS.

 Etablir des contrats avec des fournisseurs spécialisés de proxy en ligne qui
disposent de grandes bande-passantes et qui offrent une protection contre ces
attaques en filtrant le trafic avant de le rediriger vers l’entité. Cela fournit un
niveau de résilience et une flexibilité pour bloquer le trafic avec un contenu
spécifique que les fournisseurs d’accès à Internet peuvent ne pas détecter tout en
gardant les applications et les données de l’entité en interne.

 Planifier des tests réguliers de la capacité de l’infrastructure réseau à gérer les

requêtes avant qu’elle soit au-dessous des niveaux acceptables (teste de monter en
charge).

 Elaborer un plan d’intervention contenant des actions précises à suivre en cas

d’une attaque DOS en respectant les recommandations ci-dessus.
Réaction aux attaques DOS
 Déterminez si l'attaque DOS vise à surcharger la bande-passante du réseau ou les
ressources des serveurs. Les exemples présentés ci-dessous ne sont pas exhaustifs
mais décrivent le principe d'une attaque DoS et l'importance de déterminer la
ressource réseau ciblée :

 la bande-passante:
 L’envoie d’une grande quantité de requêtes est une méthode simple
mais efficace qui consomme la bande passante disponible et ralentit le
traitement des demandes légitimes.

 L'envoi de grands volumes de trafic réseau nécessitant une réponse vers

un serveur consomme également la bande passante disponible.

DGSSI 21
 Référentiel de gestion des incidents de cybersécurité

 Les ressources serveur:

 L’initiation de multiple tentatives d’ouverture de sessions cryptées SSL

ciblent les processeurs du serveur (CPUs) pour ralentir de nombreuses
tâches critiques, dans le but de bloquer ou de crasher le serveur.

 Les requêtes qui établissent et conservent des sessions Web ouvertes

sur un serveur sont conçues pour consommer le nombre maximal de
connexions simultanées que le serveur peut maintenir ce qui empêche
les autres utilisateurs d'accéder au site.

 L’envoi de plusieurs emails ciblant le serveur de messagerie avec des

pièces jointes malicieuses entraîne l’utilisation intensive du processeur
et la saturation de l’espace disque du serveur de messagerie.

 La saturation du serveur de noms de domaine par les requêtes DNS

empêchera les utilisateurs légitimes de résoudre les adresses IP requises
pour accéder aux services en ligne de l’entité.

 Lorsque la ressource ciblée est identifiée, il est indispensable de comprendre la

technique de l'attaque afin d’envisager les plans de remédiation appropriés pour cet
incident :

 Dans le cas des attaques ciblant les serveurs DNS, l’augmentation de la

valeur TTL (Time To Live) des enregistrements DNS et le contrôle de la
quantité de bande passante réseau allouée au trafic DNS pourrait permettre
aux visiteurs légitimes de continuer à accéder au site Web.

 Si une attaque cible une adresse IP de l’entité, la diminution de la valeur

TTL des enregistrements DNS permettra de déplacer le serveur web vers
une autre adresse IP afin de permettre aux visiteurs légitimes d’accéder
pendant que l’attaquant continue de cibler l’adresse IP qui n'est plus
utilisée.

 Analyser le trafic réseau afin de définir les signatures qui permettent d’identifier le
trafic indésirable. L’utilisation de cette technique en combinaison avec une liste
préétablie de clients légitimes, rend l’indentification du trafic indésirable plus
efficace. Par exemple, si le trafic d'attaque tente de saturer les ressources des
serveurs Web, il devient nécessaire de bloquer les requêtes répétitives sur le même
contenu à partir d’une seule adresse IP.

 Demander aux opérateurs de bloquer toute adresse IP responsable d’un trafic

suspect. Le fournisseur d’accès à Internet peut empêcher le trafic source de
l’attaque DOS d'atteindre le réseau de l’entité et ainsi de réduire le risque de
consommation des ressources disponibles.

DGSSI 22
 Référentiel de gestion des incidents de cybersécurité

Annexe G : Incident de défiguration de site web

En cas de défiguration de site web, il faut isoler le serveur en attendant de rétablir le

site web à partir de la dernière version intègre du site. Cette version doit être préparée à
l'avance. La surpression du fichier intrus n’est pas toujours suffisante pour rétablir le site. Il se
peut que des fichiers de configuration soient altérés ou infectés.

Il est recommandé de mettre en place une solution de vérification d’intégrité pour tous
les fichiers et dossiers du site web. Cette solution permettrait de détecter toute injection de
code malicieux ou altération d'un fichier de configuration.

Pour répondre efficacement à ce type d’incident, Il est nécessaire de disposer des logs
ci-après pour une période de 3 mois au moins:

 Logs du serveur web

 Logs des proxys et Firewall applicatifs (WAF)
 Logs des IPS, IDS et Firewall
 Logs des serveurs de bases de données

Il est aussi recommandé de centraliser les logs dans un serveur à part pour garantir que
l'attaquant ayant le contrôle du serveur web ne puisse pas effacer ses traces et fausser
l'investigation.

La défiguration peut être parfois le début d'une attaque plus approfondie pour contrôler
le serveur web et par la suite rebondir vers d'autres systèmes internes pour y persister ou pour
l’intégrer à des plateformes Internet de distribution du malwares. Dans ce cas, d'autres
évidences seront nécessaire pour approfondir l'investigation telles que :

 La capture du trafic ;
 La capture de la RAM ;
 La capture du Disque ;
 Les Logs systèmes et évènements Windows ;
 Les logs de l’annuaire.

DGSSI 23
 Référentiel de gestion des incidents de cybersécurité

Annexe H : Fiche de déclaration d’un incident.

ROYAUME DU MAROC ‫المملكة المغربية‬

ADMINISTRATION
DE LA DEFENSE NATIONALE ‫إدارة الدفاع الوطني‬
DIRECTION GENERALE DE LA
SECURITE DES SYSTEMES ‫المديرية العامة ألمن نظم المعلومات‬
D’INFORMATION
maCERT

Fiche de déclaration d’incident de cybersécurité

Contact
- Nom de l’organisation : ------------------------------

- Nom du responsable (s) à contacter : ------------------------------

- Fonction : ------------------------------

- Email : ------------------------------

- Téléphone : ------------------------------

Détails sur l’incident

- Type de l’incident : ------------------------------

- Impact de l’incident : ------------------------------

- Date et heure d’occurrence : ------------------------------

- Date et heure
de détection de l’incident : ------------------------------

- Vecteur d’attaque susceptible : ------------------------------

DGSSI 24
 Référentiel de gestion des incidents de cybersécurité

Complément d’Informations
------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

Actions prises par l’équipe IT:

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

------------------------------ ------------------------------ ------------------------------

DGSSI 25
 Référentiel de gestion des incidents de cybersécurité

Références

 ISO/IEC 27035: Information technology – Security techniques – Information Security

incident management.

 ISO/IEC 27035- 1: Principales of Incident Management.

 ISO/IEC 27035- 2: Guidelines to plan and prepare for incident response.

 ISO/IEC 27035- 3: Guidelines for incident response operations.

 Publication spéciale de NIST 800-61r2: Incident handling guide.

 Publication spéciale de l’ENISA: Good Practice Guide for Incident Management.

DGSSI 26