CLUSIF 2011 Gestion Des Incidents

LES DOSSIERS TECHNIQUES
Gestion des incidents de scurit

du systme dinformation (SSI)

Mai 2011

Groupe de travail Gestion des incidents

CLUB DE LA SECURITE DE LINFORMATION FRANAIS
11 rue de Mogador - 75009 Paris
Tl. : +33 1 53 25 08 80 Fax : +33 1 53 25 08 88
clusif@clusif.asso.fr www.clusif.asso.fr
La loi du 11 mars 1957 n'autorisant, aux termes des alinas 2 et 3 de l'article 41, d'une part, que les copies ou reproductions
strictement rserves l'usage priv du copiste et non destines une utilisation collective et, d'autre part, que les analyses
et les courtes citations dans un but d'exemple et d'illustration, toute reprsentation ou reproduction intgrale, ou partielle,
faite sans le consentement de l'auteur ou de ayants droit ou ayants cause est illicite (alina 1er de l'article 40)
Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait donc une contrefaon sanctionne par les
articles 425 et suivants du Code Pnal

Gestion des incidents I CLUSIF 2011

Table des matires

Remerciements ......................................................................................................................... IV
1 - Introduction........................................................................................................................... 9
2 - Primtre du document ....................................................................................................... 10
2.1. Objectifs du document ............................................................................................. 10
2.2. Dfinition dun incident SSI dans le cadre de ce document..................................... 11
3 - Organisation de la gestion des incidents SSI ...................................................................... 12
3.1. Introduction .............................................................................................................. 12
3.2. Politique de gestion des incidents de scurit .......................................................... 12
3.3. Les Mesures mettre en place.................................................................................. 12
3.4. Organisation ............................................................................................................. 15
3.4.1 Prambule......................................................................................................... 15
3.4.2 quipe de rponse aux incidents SSI ............................................................... 16
3.4.2.1 Fonctionnement ............................................................................................ 17
3.4.2.2 Services et primtre .................................................................................... 19
3.5. Processus de traitement des incidents ...................................................................... 22
4 - Gestion des incidents de SSI............................................................................................... 24
4.1. Dtection et signalement .......................................................................................... 24
4.2. Prise en compte ........................................................................................................ 24
4.2.1 Enregistrement de lincident ............................................................................ 24
4.2.2 Catgorisation par une quipe support ............................................................. 25
4.2.3 Qualification par lquipe de rponse aux incidents de scurit ...................... 25
4.3. Rponse lincident SSI .......................................................................................... 26
4.3.1 Mesures de rponses immdiates ..................................................................... 26
4.3.2 Investigations.................................................................................................... 26
4.3.2.1 Prservation des traces ................................................................................. 26
4.3.2.2 Environnements potentiellement concerns................................................. 27
4.3.2.3 Aide lanalyse ............................................................................................ 27
4.3.2.4 Identification du fait gnrateur et analyse de limpact................................ 27
4.3.3 Traitement ........................................................................................................ 28
4.3.3.1 Mesures pour viter laggravation des consquences................................... 28
4.3.3.2 Dclarations aux assurances......................................................................... 28
4.3.3.3 Rsolution de lincident ............................................................................... 29
4.3.3.4 Mthodes et outils ........................................................................................ 30
4.3.3.5 Exemples de traitements............................................................................... 30
4.4. Revues post-incident ................................................................................................ 31
4.4.1 Investigation post-incident ............................................................................... 31
4.4.2 Rapport de synthse.......................................................................................... 31
4.4.3 Analyse post-incident ....................................................................................... 32
4.5. Actions post-incident................................................................................................ 32
4.5.1 Bilan de lincident ............................................................................................ 32
4.5.2 Le Recours........................................................................................................ 32
4.5.3 Rvision des contrats........................................................................................ 33
4.5.4 Communication interne spcifique (sensibilisation, etc.) ................................ 33
4.6. Amlioration de la gestion des incidents SSI........................................................... 33
5 - Exemples de typologie des incidents .................................................................................. 35
5.1. Prsentation du format des fiches par type dincident.............................................. 35

Gestion des incidents II CLUSIF 2011
5.1.1 Description du type dincident de scurit ....................................................... 35
5.1.2 Mesures prventives possibles ......................................................................... 35
5.1.3 Moyens de dtection......................................................................................... 35
5.1.4 Qualification..................................................................................................... 36
5.1.5 Analyse............................................................................................................. 36
5.1.6 Traitement ........................................................................................................ 36
5.1.7 Actions post-incident........................................................................................ 36
5.2. Fiches par type dincident ........................................................................................ 37
5.2.1 Vol de PC portable ........................................................................................... 37
5.2.1.1 Description du type dincident de scurit ................................................... 37
5.2.1.2 Mesures prventives possibles ..................................................................... 37
5.2.1.3 Moyens de dtection..................................................................................... 37
5.2.1.4 Qualification................................................................................................. 38
5.2.1.5 Analyse......................................................................................................... 38
5.2.1.6 Traitement .................................................................................................... 38
5.2.1.7 Actions post-incident.................................................................................... 38
5.2.2 Installation dun logiciel non autoris.............................................................. 39
5.2.2.1 Dfinition de lincident ................................................................................ 39
5.2.2.4 Analyse......................................................................................................... 39
5.2.2.5 Traitement .................................................................................................... 40
5.2.3 Dysfonctionnement pouvant provenir dun logiciel malveillant...................... 41
5.2.3.1 Dfinition de lincident ................................................................................ 41
5.2.3.4 Qualification................................................................................................. 43
5.2.3.5 Analyse......................................................................................................... 43
5.2.3.6 Traitement .................................................................................................... 43
5.2.4 Intrusions logiques ........................................................................................... 44
5.2.4.4 Analyse......................................................................................................... 45
5.2.4.5 Traitement .................................................................................................... 46
5.2.5 Usage inappropri des ressources informatiques ............................................. 47
5.2.5.3 Dtection ...................................................................................................... 48
5.2.5.4 Analyse......................................................................................................... 48
5.2.5.5 Traitement .................................................................................................... 49
5.2.6 Incidents concernant les habilitations............................................................... 50
5.2.6.3 Dtection ...................................................................................................... 51

Gestion des incidents III CLUSIF 2011
5.2.6.4 Analyse......................................................................................................... 51
5.2.6.5 Traitement .................................................................................................... 52
5.2.7 Dni de service Messagerie par saturation du relais public de messagerie...... 53
5.2.7.3 Dtection ...................................................................................................... 54
5.2.7.4 Analyse......................................................................................................... 55
5.2.7.5 Traitement .................................................................................................... 55
5.2.8 Cas des incidents lis........................................................................................ 56
5.2.8.3 Dtection ...................................................................................................... 56
5.2.8.4 Analyse......................................................................................................... 57
5.2.8.5 Traitement .................................................................................................... 57
6 - Glossaire (source principale : Wikipedia)............................................................... 58

Table des figures

Figure 1 - Acteurs / partenaires de lquipe de rponse aux incidents de scurit................... 17
Figure 2 Grands domaines dactivit des services lis la gestion d'incidents de scurit .. 19

Gestion des incidents IV CLUSIF 2011
REMERCIEMENTS
Le CLUSIF tient mettre ici l'honneur les personnes qui ont rendu possible la ralisation de
ce document, tout particulirement :

Les responsables successifs du groupe de travail :
Robert BERGERON CAPGEMINI
Witold POLOCZANSKI CAPGEMINI

Les contributeurs :
Michel BERTIN
David BIZEUL SOCIETE GENERALE
Annie BUTEL BNP PARIBAS
Philippe LARUE CBP
Sbastien MAUPTIT SYSTALIANS
Lionel MOURER ESR CONSULTING
Grard PETITIT GRAS SAVOYE
Dominique POURCELLIE CNAMTS
Manuel PRIEUR
HP ENTERPRISE SERVICES

Nous remercions aussi les nombreux adhrents du CLUSIF ayant particip la relecture.

Gestion des incidents 9 / 60 CLUSIF 2011
1 - Introduction

La notion dincident est trs large et couvre des domaines varis : incident technique, incident
fonctionnel, incident social, incident de scurit, incident de communication, incident de
paiement, incident financier, etc. Dune manire gnrale, un incident peut tre dfini comme
un vnement causant des dommages ou susceptible de le faire des personnes ou des
organisations.

Concernant les Systmes dInformation, il existe diffrentes dfinitions de la notion
dincident :
pour le COBIT :
Incident informatique : tout vnement qui ne fait pas partie du fonctionnement normal
dun service et qui cause, ou peut causer, une interruption ou une rduction de la
qualit de ce service (IT Incident, dfinition conforme lIT Infrastructure Library,
ITIL),
Problme : en informatique, cause la base dun ou de plusieurs incidents.

pour ITIL :
Incident : tout vnement qui ne fait pas partie du fonctionnement standard dun
service et qui cause, ou peut causer, une interruption ou une diminution de la qualit
de ce service.
Problme : la cause inconnue dun incident significatif ou la collection de plusieurs
incidents prsentant les mmes symptmes. La gestion des problmes consiste en une
analyse visant anticiper les incidents venir.

pour lISO 27000 (scurit de linformation) :
Incident : un ou plusieurs vnements intressant la scurit de linformation
indsirable(s) ou inattendu(s) prsentant une probabilit forte de compromettre les
oprations lies lactivit de lorganisme et de menacer la scurit de linformation
[ISO/CEI TR 18044:2004
1
].

Quelle que soit lapproche, la gestion des incidents a pour objectif la dtection et le traitement
des incidents ( priori et posteriori). Le processus de gestion des incidents inclut en gnral
la dtection de lincident, les analyses et diagnostics, la rsolution de lincident et/ou le
rtablissement du service affect. Un aspect important de la gestion des incidents est le suivi
(reporting) de ce processus et la capitalisation (bilan).

La qualit de service et la performance des organisations exigent la mise en place dune
gestion efficace des incidents et des problmes. La gestion des incidents est galement un
dispositif amont essentiel du Plan de Reprise dActivit car elle dfinit les procdures
descalade qui permettent dtre plus ractif pour le dclenchement des plans de secours.

11
La norme ISO/CEI TR 27035 en prparation va remplacer cette norme prochainement.

2 - Primtre du document

2.1. Objectifs du document

Ce document na pas pour ambition de couvrir tous les types dincident. Son objet est de
constituer un guide de mise en place dun systme de gestion des incidents de Scurit du
Systme dInformation et dapporter une aide la classification et lanalyse de ces incidents.
Il fournit galement en annexe des fiches de recommandations pour les incidents de scurit
les plus courants.

Le document concerne donc principalement dans une organisation, les personnes en
charge de :
la Scurit du Systme dInformation (RSSI, administrateurs de la scurit,
correspondants scurit, etc.),
la gestion des risques (suivi et valuation des risques avrs),
le contrle interne, laudit, linspection, le contrle priodique,
la qualit (taux de disponibilit, frquence des vnements, etc.),
la production.

Les raisons qui conduisent la mise en place dun systme de gestion des incidents peuvent
tre diverses, par exemple :
la dcision de mise en place dun processus damlioration continue,
la ncessit de se conformer aux exigences rglementaires du secteur dactivit,
la mise en uvre dun plan scurit avec un objectif de rduction du nombre et de
limpact des incidents,
la dcision damliorer la gestion dincidents existante (meilleure ractivit, meilleure
efficacit du traitement des incidents, etc.),
la mise en place de procdures descalade dans le cadre dun projet dlaboration
dun Plan de Continuit dActivit (PCA), dun Plan de Gestion de Crise, etc.,
la volont de mettre en place un SMSI, voire dobtenir une certification (ISO 27001
par exemple).


2.2. Dfinition dun incident SSI dans le cadre de ce document

La suite du document concerne les incidents de Scurit du Systme dInformation (SSI).
Mais quest-ce quun incident SSI exactement?

Reprenant les dfinitions cites dans lintroduction, nous dsignerons par incident SSI un
vnement, potentiel (au sens signes prcurseurs ) ou avr, indsirable et/ou inattendu,
impactant ou prsentant une probabilit forte dimpacter la scurit de linformation dans ses
critres de Disponibilit, d'Intgrit, de Confidentialit et/ou de Preuve.

Un incident SSI correspond une action malveillante dlibre, au non-respect dune rgle de
la Politique de Scurit du Systme dInformation (PSSI) ou, dune manire gnrale, toute
atteinte aux informations, toute augmentation des menaces sur la scurit des informations ou
toute augmentation de la probabilit de compromission des oprations lies lactivit.

Concernant la disponibilit, on fera la diffrence entre les sinistres majeurs (incendie,
inondation, etc.) ncessitant lactivation dune cellule de crise et les autres incidents (panne
dun serveur). Une atteinte la disponibilit pourra tre considre comme tant un incident
de scurit (dni de service suite intrusion) ou non (panne de serveur suite dfaillance dun
composant), aprs analyse des causes.

3 - Organisation de la gestion des incidents SSI

3.1. Introduction

La mise en uvre dun processus de gestion des incidents de scurit ncessite la dfinition :
du primtre,
des objectifs (politique de gestion des incidents),
des mesures (processus, bonnes pratiques, etc.),
des moyens associs (organisation des ressources matrielles / humaines /
budgtaires).

3.2. Politique de gestion des incidents de scurit

Une politique de gestion des incidents de scurit passe par la dfinition de deux objectifs
majeurs :
garantir que le mode de notification des vnements et des failles lis la scurit de
linformation permet la mise en uvre dune action complmentaire ou corrective
dans les meilleurs dlais,
garantir la mise en place dune approche cohrente et efficace pour le traitement des
incidents lis la scurit de linformation.

3.3. Les Mesures mettre en place

Les mesures suivantes sont essentielles latteinte de ces deux objectifs.

1. Les vnements lis la scurit de linformation doivent tre signals, dans les meilleurs
dlais, par les circuits appropris

Bonnes pratiques :
des procdures formelles de signalement, de remonte dinformations et de rponses
en cas de dtection dun incident li la scurit de linformation doivent dfinir les
mesures prendre la rception dun appel signalant un tel vnement,
le Service Desk, lquipe de rponse aux incidents et le RSSI peuvent tre les points
dentre pour le signalement des vnements lis la scurit de linformation,
tous les utilisateurs doivent tre informs des points dentre, des procdures de
signalement et de leur obligation de signaler tout vnement li la scurit de
linformation dans les meilleurs dlais (charte, sensibilisation).


2. Il doit tre demand tous les salaris, contractants et utilisateurs tiers des systmes et
services dinformation de noter et de signaler toute faille de scurit observe ou
souponne dans les systmes ou services

Bonnes pratiques :
tous les salaris, contractants et utilisateurs tiers sont tenus de signaler ce type de
problme au Service Desk, dans les meilleurs dlais, afin dviter tout incident li la
scurit de linformation,
le mcanisme de signalement doit tre le plus simple, le plus accessible et le plus
disponible possible. Il est recommand ces personnes de ne jamais tenter dapporter
la preuve de failles de scurit souponnes.

3. Des responsabilits et des procdures doivent tre tablies, permettant de garantir une
rponse rapide, efficace et pertinente en cas dincident li la scurit de linformation

Bonnes pratiques :
outre le signalement des vnements et failles lis la scurit de linformation, il est
recommand de mettre en place une surveillance des systmes, des alertes et des
vulnrabilits afin de dtecter les incidents lis la scurit de linformation,
des priorits de traitement des incidents de scurit doivent tre dfinies,
une description des incidents de scurit et les modes opratoires de rsolution
spcifiques permettent de grer les diffrents types dincidents lis la scurit de
linformation,
de manire optimale, la clture dun incident de scurit est confirme par le dclarant.
Le RSSI donne une apprciation qualitative sur la rsolution de lincident (dlais,
solution propose, amlioration potentielle, etc.).

4. Des mcanismes (organisation, procdures, outils, etc.) doivent tre mis en place,
permettant de quantifier et surveiller les diffrents types dincidents lis la scurit de
linformation ainsi que leur volume et les cots associs

Bonnes pratiques :
les informations recueillies lors de la rsolution dincidents lis la scurit de
linformation pour identifier les incidents rcurrents ou ayant un fort impact sont
rvalues la fin de lincident,
lvaluation dincidents lis la scurit de linformation peut faire apparatre la
ncessit damliorer les mesures existantes ou den crer de nouvelles, afin de limiter
la frquence des futurs incidents ainsi que les dommages et les cots associs, ou afin
dintgrer ces mesures dans le processus de rexamen de la politique de scurit. En ce
sens, une analyse froid des incidents ayant donn lieu une cellule de crise est
ralise lors des comits excutifs (afin didentifier les ventuelles actions prventives
engager),
une revue des incidents ralise rgulirement permet notamment de quantifier et
surveiller les diffrents types dincidents lis la scurit de linformation ainsi que
leur volume, les cots associs et leurs impacts sur les processus mtier.

5. Un programme d'assurances adapt doit tre mis en uvre pour protger les personnes,
les investissements, les informations et lensemble des actifs de lentreprise ou de
lorganisme. La dfinition du primtre assurer fait en rgle gnrale l'objet d'une
analyse de risques mene avec l'assureur. Il faut valuer le plus prcisment possible, la
nature des risques encourus, les consquences financires qu'ils peuvent engendrer, puis
arbitrer entre l'auto-assurance (provision, franchise) et le transfert de risques
l'assureur.
Ces contrats dassurances doivent couvrir galement les risques informatiques (pannes,
destruction, vol de matriel, fraude, etc.) et tout particulirement le poste surcot
dexploitation en cas de sinistre . Des assurances de type pertes d'exploitation
permettent de surmonter les difficults financires engendres par un sinistre.

Bonne pratiques :
actualiser rgulirement le primtre assurer et rviser les contrats en consquence,
dmontrer lefficacit de lorganisation en place pour la gestion des incidents. Cest
une aide pour ngocier des tarifs dassurance prfrentiels.

6. Lorsquune action en justice civile ou pnale peut tre engage contre une personne
physique ou un organisme, la suite dun incident li la scurit de linformation, les
lments de preuve doivent tre recueillis, conservs et prsents conformment aux
dispositions lgales relatives la prsentation de preuves rgissant la ou les juridiction(s)
comptente(s)

Bonnes pratiques :
si elles existent, raliser les dclarations CNIL (ou quivalent) pour les logiciels
danalyse des vnements de scurit,
avoir une procdure interne qui dfinit les exigences de scurit en matire de collecte
des traces techniques de scurit, de leur conservation, de leur protection et de leur
accs,
seules les autorits judiciaires sont autorises collecter les preuves lgales.


3.4. Organisation

3.4.1 Prambule
Une fois lincident qualifi en tant quincident de scurit il doit tre confi une quipe
spcialement constitue pour lanalyse, lvaluation dimpact, les actions correctives et la
remise en fonction du service affect. Cette quipe porte trs souvent le nom de CSIRT
(Computer Security Incident Response Team) ou ISIRT (Information Security Incident
Response Team).

En fonction de la taille de lentreprise ou de lorganisme cette quipe peut avoir une
organisation trs diffrente :
modle centralis (CCSIRT) une quipe unique et centralise prenant en charge tous
les incidents de lorganisation/entreprise. Ce modle est efficace pour les organisations
de taille limite ou les grandes organisations avec les moyens informatiques trs
centraliss,
modle distribu (DCSIRT) plusieurs quipes disperses gographiquement en
fonction de la localisation de centres dhbergement de ressources informatiques. Il est
important, pour une meilleure efficacit et communication, que ces quipes soient
malgr tout administres par une autorit centrale pour garantir lapplication des
procdures homognes et un change efficace dinformations entre les quipes,
entit de coordination dans le cas du modle distribu fortement dispers ou dune
communaut dorganisations indpendantes lquipe de coordination remplit les rles
suivants :
o coordinateur des actions des diffrents DCSIRT quand lincident a un impact
sur plusieurs entits,
o centre dexpertise et dassistance,
o metteur de recommandations et des bonnes pratiques,
o gestionnaire de base de connaissances partage par tous les membres
dorganisation ou communaut.
Un exemple de centre de coordination pour la communaut dutilisateurs
dInternet est le CERT/CC (Central Emergency Response Team / Coordination
Center situ luniversit de Carnegie Mellon aux tats-Unis) ou le CERTA
(Centre d'Expertise Gouvernemental de Rponse et de Traitement des Attaques
informatiques) du gouvernement franais (liste non exhaustive).

Indpendamment du modle dorganisation les membres de chaque quipe doivent disposer
des moyens fiables et scuriss de communication interne, mais galement externe pour
collaborer avec les quipes concernes dans le cadre de leur activit.

Un autre aspect de lorganisation de moyens de gestion dincidents de scurit est la dcision
du mode de gestion des ressources humaines et des services.

Dans le cas le plus simple lquipe est constitue demploys de lentreprise ou de
lorganisme et prend en charge lensemble des services. Dans certains cas, elle fait appel au
support offert par les socits externes. Ce modle peut tre difficile faire fonctionner
cause du large ventail de comptences exiges dans plusieurs domaines dune part et de

lobligation doprer le plus souvent 24h/24 et 7j/7, dautre part. Seules les grandes
entreprises / organisations peuvent soffrir ces capacits.

loppos du modle prcdent il est possible dexternaliser entirement la gestion des
incidents de scurit des prestataires de services spcialiss (MSSP Managed Security
Services Provider). Dans ce cas les tches de prise dappel, de monitoring et dtection,
danalyse, dvaluation dimpact et de reporting sont entirement prises en charge par le
prestataire et les actions correctives et de restitution des services sont faites en collaboration
avec les quipes de production (internes ou externes).

Souvent le modle mixte de rpartition des tches entre le personnel interne et prestataires
peut tre le mieux adapt.

Dans de nombreux cas, il est trs important de dfinir prcisment, de publier et de
communiquer les missions et les services fournir par chacune des entits concernes.

Enfin, les quipes oprationnelles, dans de nombreux cas, seront obliges de communiquer
avec les dcideurs, ladministration et le support technique. Elles doivent donc disposer tout
moment dune liste jour des contacts nominatifs reprsentant diffrentes entits comme :
la Direction Gnrale,
le RSSI,
les tlcoms et rseaux,
le support IT,
les services juridiques,
la communication (relations presse et mdia),
les RH,
les acteurs du PCA,
la scurit physique,
les services gnraux.

3.4.2 quipe de rponse aux incidents SSI
Pour que les incidents de scurit puissent tre correctement traits, il est ncessaire qu'une
structure existe et qu'elle soit ddie la gestion d'incidents. Les sigles CERT (Computer
Emergency Response Team) ou CSIRT (Computer Security Incident Response Team)
dcrivent les activits de telles quipes.

Cette structure est amene tre sollicite par sa hirarchie ou par des contacts techniques
pour qualifier des vnements et intervenir sur un incident de scurit. Pour cela, cette quipe
doit tre clairement identifie comme un point de passage oblig dans tout circuit de
notification d'incident.

Cette quipe doit galement disposer de la lgitimit ncessaire pour pouvoir agir rapidement.
Pour cela, le management doit tre persuad de l'intrt des actions de l'quipe, il doit donc
tre impliqu dans la dfinition des objectifs de l'quipe et tre bnficiaire de services offerts
par l'quipe.


3.4.2.1 Fonctionnement

Une quipe de rponse aux incidents de scurit doit rpondre diffrents objectifs imposs
par son environnement. Parmi ses objectifs on peut lister :
la rationalisation de la veille dans l'entreprise ou lorganisme,
la ncessit de traiter rapidement tout type d'incident de scurit par du personnel
qualifi habilit et avec des modes opratoires prouvs,
la ncessit d'avoir une vue du risque d'exposition du SI de l'entreprise ou de
lorganisme.

Ces objectifs rpondent des stratgies d'entreprise ou dorganisme (conformit
rglementaire, protection de l'image, efficacit oprationnelle, etc.).

L'environnement d'une quipe de rponse aux incidents de scurit est constitu de cercles
d'acteurs / partenaires avec lesquels elle travaille (cf. Figure 1) :
cercle de premier niveau : les commanditaires du service (responsables hirarchiques
ou fonctionnels),
cercle de second niveau : les acteurs internes pour lesquels elle intervient
(responsables scurit, responsables informatiques),
cercle de troisime niveau : les acteurs internes avec lesquels elle travaille au quotidien
(quipes de production, support informatique, quipes projet),
cercle de quatrime niveau : les acteurs internes avec lesquels elle a besoin de
travailler ponctuellement (juristes, ressources humaines, charg de communication,
cellule de crise),
cercle de cinquime niveau : les acteurs externes avec lesquels elle travaille
(fournisseurs de services, prestataires de service),
cercle de sixime niveau : les acteurs externes avec lesquels elle change (CERTs,
forces de police, chercheurs indpendants, etc.).

Acteurs externes
Contacts
Acteurs externes
Fournisseurs
Acteurs internes
Assistance ponctuelle
Acteurs internes
Equipe partenaires
Demandeurs
Clients
Responsables
RSSI
CSIRT 1 2 3 4 5 6 INT EXT

Figure 1 - Acteurs / partenaires de lquipe de rponse aux incidents de scurit


Cet environnement complexe requiert d'tre maintenu jour pour assurer une pleine capacit
de raction l'quipe de rponse aux incidents. Une veille permanente et attentive aux
nouvelles tendances et mthodes d'attaques est galement ncessaire.

Pour tre contacte rapidement, l'quipe de rponse aux incidents doit bnficier d'une bonne
visibilit en interne comme en externe. Latteinte de cet objectif ncessite du temps et la mise
en uvre de diffrentes actions telles que : rencontres, prsentations orales, participations
des confrences.

Il est utile de fournir l'quipe une adresse de messagerie gnrique et un numro de
tlphone.

Les comptences requises au sein de l'quipe de rponse aux incidents sont multiples et
dpendent des services qui sont fournis par l'quipe. Dans la plupart des cas, il sera ncessaire
de disposer :
de comptences techniques pour pouvoir analyser prcisment le contexte oprationnel
dans lequel lincident sest produit et identifier rapidement des contre-mesures
pouvant tre mises en uvre sans mettre en pril le Systme dInformation,
dune connaissance du contexte et des enjeux mtier,
de comptence rdactionnelle pour pouvoir formaliser correctement toutes les actions
entreprises dans les cas de rponse incident,
dune aisance relationnelle pour pouvoir changer facilement avec les acteurs
concerns en adaptant le discours en fonction du profil des interlocuteurs.


3.4.2.2 Services et primtre

L'quipe peut offrir de multiples services lis la gestion d'incidents de scurit. Ces services
peuvent tre regroups en trois grands domaines d'activit (cf. Figure 2) :
services ractifs,
services proactifs,
services qualitatifs.

Alertes
Incident
- Analyse
- Traitement
- Support
- Coordination
Vulnrabilits
- Analyse
- Correction
- Coordination
Outils dattaque
- Analyse
- Traitement
- Coordination
Annonces
Veille technologique
Audits scurit
Administration de
composants scurit
Dveloppement doutils
Dtection dintrusion
Corrlation
Surveillance
Analyse de risques
PCA / PRA
Conseils
Sensibilisation
Formation
Validation de produits
Services Ractifs Services proactifs Services qualitatifs

Figure 2 Grands domaines dactivit des services lis la gestion d'incidents de scurit

Services ractifs

Le domaine ractif regroupe tous les services qui peuvent tre mis en uvre lors du traitement
d'un incident de scurit. Les services suivants sont rattachs ce domaine :
service d'alerte : ce service a pour objectif de notifier les parties prenantes d'un danger
trs court terme. Des contremesures sont listes permettant de remdier au problme,
service de traitement des incidents : ce service assure la prise en charge partielle ou
totale de l'incident par l'quipe de rponse aux incidents de scurit. L'quipe pourra
apporter une simple assistance tlphonique, fournir des modes opratoires ou assister
physiquement les quipes oprationnelles lors de cet incident. L'quipe intervenant sur
l'incident aura sa charge la dtection, l'isolation et la remdiation de la menace
associe l'incident. Un service sous intervention est prfrable mais demande des
comptences multiples, des procdures rodes et de l'outillage,
service de gestion des vulnrabilits : ce service consiste centraliser les vulnrabilits
sur le primtre de l'entreprise ou de lorganisme, les analyser et coordonner leur
correction,
PCA/PRA : un incident analys et jug important pourra engendrer la ncessit de
dclencher un plan de continuit d'activit (PCA) voire un plan de reprise d'activits
(PRA.) Dans ce cas, il est capital que l'quipe en charge du traitement de l'incident soit

intgre aux procdures dalerte et de qualification du PCA. L'quipe de rponse aux
incidents pourra contribuer la gestion de crise selon la nature de lincident.

Services proactifs

Le domaine proactif regroupe des services qui ont pour objectif de prvenir l'apparition d'un
incident ou tout du moins d'anticiper son traitement. Les services suivants sont rattachs au
domaine proactif :
annonces : diffusion d'informations permettant d'anticiper une menace (informations
concernant les vulnrabilits ou ltat de la propagation d'une menace constate en
externe),
veille technologique : mise disposition d'une synthse sur les informations de
scurit essentielles sur une priode donne,
audits de scurit et tests d'intrusion : ces services permettent d'avoir une meilleure
visibilit du niveau du risque et de reprer les points de faiblesse de certains pans du
SI,
administration de composants scurit : ce service permet dassurer ladministration
des briques de linfrastructure scurit de faon garantir la matrise du traitement en
cas dincident,
dveloppement doutils : ce service vise dvelopper quelques outils scurit,
dtection d'intrusions : ce service permet d'avoir une visibilit sur les attaques
destination du SI,
corrlation d'vnements de scurit : ce service permet dassocier les vnements de
scurit pour identifier sils donnent lieu un incident de scurit,
surveillance : ce service trs gnrique peut tre dclin en activits distinctes suivant
le mtier de l'entreprise /organisme ou ses centres d'intrt. Dans tous les cas, des
services de surveillance permettront d'identifier des comportements anormaux
probablement caractristiques d'un incident de scurit.

Services qualitatifs

Le domaine qualitatif regroupe des services qui participent l'lvation du niveau de scurit
par des actions de fond. Ces services ne sont pas propres la gestion d'incident, mais une
quipe de raction aux incidents peut souvent y apporter une forte valeur ajoute. Les services
suivants sont rattachs ce domaine :
analyse de risques : une quipe de rponse aux incidents peut apporter une aide
prcieuse pour identifier rapidement les menaces et leurs impacts sur un actif de
l'entreprise ou de lorganisme. Dans ce cas, une interaction doit tre cre entre les
quipes projets ou d'architecture en charge des analyses de risque et l'quipe de
raction aux incidents,
PCA/PRA : une quipe de rponse aux incidents acquire rapidement de lexprience
sur les typologies dincidents rencontrs dans lentreprise ou lorganisme et sur le
mode de traitement le plus adapt pour leur radication. L'quipe de rponse aux
incidents pourra contribuer la gestion de crise selon la nature de lincident,
qualification des incidents de scurit : lquipe de rponse aux incidents de scurit
contribue llaboration de guides de qualification des incidents, notamment pour
lquipe dassistance de premier niveau,
conseils : la bonne matrise des attaques et des contremesures confre l'quipe de
rponse aux incidents des connaissances qui pourront tre mises contributions pour

des missions de conseil. Tout du moins, il est important que l'quipe soit reconnue par
les quipes projet pour solliciter son conseil sur des points prcis,
sensibilisation : les incidents rencontrs par l'quipe de rponse aux incidents lui
procurent une bonne visibilit des choses faire et viter. Cette connaissance peut
tre mise contribution pour des actions ponctuelles ou rcurrentes de sensibilisation
auprs de publics varis (salaris, managers, dveloppeurs, etc.),
formation : lquipe de rponse aux incidents peut, dans certains cas offrir un service
de formation permettant de dvelopper des comptences particulires en interne dans
lentreprise/organisme,
validation de produits : dans certains cas, il peut tre pertinent de disposer dans
lentreprise/organisme dune quipe mme de tester certains produits tiers pour les
estampiller comme respectueux des engagements de qualit attendus.

La liste des services n'est pas exhaustive et la mise en uvre devra tenir compte du contexte
de l'entreprise/organisme. Tous les services ne sont pas ncessairement offerts par l'quipe de
rponse aux incidents. Si des services ne lui incombent pas, il est par contre du ressort de
lorganisation d'identifier tous les acteurs qui offrent ces services et d'tablir un contact
durable entre eux et lquipe de rponse aux incidents de scurit.

Dans une perspective de rponses aux incidents, le domaine ractif est un lment fondateur et
il est ncessaire qu'au moins un des services rattachs ce domaine soit mis en uvre dans
l'quipe.


3.5. Processus de traitement des incidents

Le processus de gestion des incidents de scurit est reprsent par le schma ci-dessous.
La particularit du traitement des incidents de scurit tient lintervention de lquipe de
rponse aux incidents de scurit. Les autres volets du processus appartiennent soit au
processus gnral de gestion des incidents (prise en compte de lincident, catgorisation,
qualification, traitement), soit au processus de gestion de crise.

Dtection
Signalement
Evnement
Enregistrement
Catgorisation
Qualification
Traitement
Bilan et Clture
Support
Qualification
Rponse
Immdiate
Investigations
Communication
Activation
Crise
Plan de
Gestion de
Crise Traitement
Crise
Situation
Critique
Incident de scurit
potentiel
Qualification
confirme
!
!
Source
(humaine/technique)
Prise en compte
(Help desk)
Equipe de rponse aux
incidents de scurit
Cellule de crise
Autres
incidents
Requalification

Figure 3 Schmatique du processus de gestion des incidents

Le signalement dun vnement susceptible dtre qualifi dincident de scurit est ralis
soit par une personne (utilisateur, administrateur, etc.) ou par des moyens techniques (outils
de surveillance, sites Internet spcialiss, etc.).

La prise en compte est ralise en gnral par un Help Desk. Dautres circuits peuvent exister.
Dans tous les cas, il est ncessaire que lvnement soit enregistr de manire pouvoir en
faire un suivi.

Cest ce stade de la prise en compte que lvnement est catgoris. Il peut tre catgoris
incident de scurit ou tre confi des experts pour qualification.

Les incidents catgoriss incident de scurit sont immdiatement soumis lquipe de
rponse aux incidents de scurit. Les autres types dincident sont transmis aux quipes
comptentes pour leur traitement (support).


Lquipe de gestion des incidents de scurit, aprs analyse, confirme ou infirme la
catgorisation incident de scurit (qualification). Les incidents non confirms incident
de scurit sont retransmis aux quipes support.

Les incidents qualifis de scurit font alors lobjet dun traitement spcifique dont les
particularits sont dveloppes dans le chapitre suivant. Outre les investigations
complmentaires, le traitement des incidents de scurit peut ncessiter des actions
spcifiques telles que la prservation des preuves ou des actions adaptes de communication.

Lorsque lquipe de gestion des incidents de scurit nest plus mme de grer la situation,
ou lorsque les consquences potentielles sont un niveau trop important, la cellule de crise est
alerte et juge de lopportunit de passer en mode gestion de crise .


4 - Gestion des incidents de SSI
Ce chapitre dtaille les tapes du processus de gestion des incidents prsent dune manire
gnrale dans le chapitre 3.5.

4.1. Dtection et signalement

La dtection peut avoir pour origine :
toute personne qui a connaissance dun fait ou dune menace pour lorganisme (par
exemple comportement anormal dun quipement, dune application ou dune
personne),
un administrateur lorsquil est inform par un dispositif de supervision ou lorsquil
constate une anomalie lors de contrles,
un acteur de la scurit lorsquil est inform par un outil de surveillance (dtection
dintrusion ou daction frauduleuse) ou lorsquil constate une anomalie lors de
contrles.

Lanomalie doit pouvoir tre signale une personne comptente dans les plus brefs dlais. Le
contact habituel pour lutilisateur est le help desk. Cependant, il doit galement tre possible
de contacter directement un responsable de la scurit en toute discrtion si la situation
lexige. Les utilisateurs doivent tre sensibiliss et informs sur les diffrents niveaux dalerte.

Dans tous les cas, on doit sassurer que les moyens dalerte sont suffisamment rapides, y
compris en dehors des heures ouvres, pour permettre une rponse adapte (empcher que
lincident se poursuive, prserver les preuves, etc.).

Des mesures immdiates peuvent tre associes la dtection, soit sous forme de consignes
pour la personne qui dtecte, soit par lactivation automatique de mcanismes de protection.

4.2. Prise en compte

4.2.1 Enregistrement de lincident
Comme indiqu prcdemment, un incident suppos de scurit peut tre signal diffrentes
personnes, en gnral le help desk, selon des procdures devant tre connues de tous. Dans
tous les cas, la personne qui rceptionne lappel ou lalerte doit en accuser rception.
Lvnement doit immdiatement tre enregistr dans une base de donnes des incidents.

A ce stade de la procdure, lvnement nest pas encore qualifi dincident de scurit mais il
est catgoris. Lenregistrement de lvnement doit comporter minima la date et lheure de
lalerte, son origine (personne ou dispositif technique), les coordonnes du dclarant, une
description aussi prcise que possible de lvnement et sa catgorisation. Comme pour tout
incident, un numro de dossier est gnr et communiqu si ncessaire au dclarant. La
personne qui enregistre lvnement doit galement mentionner laction immdiate

dclenche (par exemple transmission une quipe support ou directement lquipe de
traitement des incidents de scurit pour qualification).

Lenregistrement de lvnement est essentiel plusieurs titres. Il permet de garder une trace
de chaque vnement et den effectuer un suivi dans toutes les phases ultrieures, danalyse ou
de traitement, jusqu la fermeture du dossier.

La base des vnements constitue galement un outil danalyse a posteriori dans le cadre
danalyses de risques, pour valuer lefficacit des dispositifs en place ou pour identifier des
incidents rcurrents pouvant tre qualifis de problme .

4.2.2 Catgorisation par une quipe support
Une fois lincident identifi comme incident de scurit potentiel, lquipe support peut
tre habilite pour prendre des mesures ou transmettre lincident lquipe de gestion des
incidents de scurit.

Lquipe de rponse aux incidents de scurit tablit des consignes dalerte scurit (fiches
par type dincident) pour les quipes support.

Pour les incidents identifis, ces consignes indiquent le mode opratoire du traitement de ces
incidents pour les quipes de support. Dans les autres cas, cest lquipe de rponse aux
incidents de scurit qui doit tre immdiatement sollicite.

Par exemple : lquipe de rponse aux incidents de scurit peut galement tre sollicite
chaque fois quune quipe support ou quun membre du personnel pense tre face un
vnement susceptible davoir un impact fort sur lorganisation.

Les consignes peuvent ventuellement spcifier que tout incident susceptible dtre dorigine
malveillante ou concernant certains quipements ou logiciels ou encore signal par certains
dispositifs techniques, doit tre transmis lquipe de rponse aux incidents de scurit.

4.2.3 Qualification par lquipe de rponse aux incidents de scurit
Une premire analyse, conduite par lquipe de rponse aux incidents de scurit, confirme ou
infirme la catgorisation incident de scurit .
Les incidents non confirms incident de scurit sont transmis aux quipes support pour
traitement.

Lquipe de rponse aux incidents de scurit procde si ncessaire des investigations
complmentaires pour qualifier lvnement. Les critres dvaluation dimpact prenant en
compte diffrents axes danalyse (impacts financiers, impacts sur limage, impacts sur les
clients ou partenaires, risques de poursuite judiciaire, etc.) doivent tre prtablis et mis la
disposition de lquipe. Typiquement ces critres sont issus de lanalyse de risque.

Il est ncessaire de tenir un journal de bord horodat et prcis des vnements et actions ds
sollicitation de lquipe.


4.3. Rponse lincident SSI

4.3.1 Mesures de rponses immdiates
Suite la qualification, des mesures durgence peuvent tre prises pour limiter les impacts et
prserver les traces. En effet, mme sans connatre prcisment la nature de lincident, son
origine ou son impact rel qui seront lobjet de la phase danalyse, le simple fait didentifier le
type de danger peut dclencher des actions palliatives, comme par exemple :
un confinement (ex : dbranchement du rseau dun poste infect pour le mettre dans
un VLAN de quarantaine),
une isolation (ex : couper tous les flux de messagerie Internet),
une communication cible de recommandations.

Certaines de ces mesures peuvent tre prvues lavance dans des procdures du support et de
lquipe scurit.
Si ces mesures savrent insuffisantes ou/et si la situation nest pas maitrise ou/et si le niveau
dimpact de lincident le justifie, au regard des critres dvaluation, la cellule de crise doit
tre active.

4.3.2 Investigations
Lanalyse de lincident a pour objectif de prciser les lments suivants :
la nature de lincident,
le fait gnrateur,
le primtre concern,
limpact.

Ces lments permettront de dfinir les actions entreprendre. Dans certains cas les
conclusions de linvestigation peuvent conduire lactivation de la cellule de crise.

4.3.2.1 Prservation des traces
Certaines prcautions doivent tre prises. En particulier, en cas de piratage (par exemple), si le
but de lanalyse est de remonter la source de la manipulation frauduleuse et de prendre des
mesures lgales l'encontre des auteurs des faits, il est ncessaire de prserver les
informations dorigines (logs, etc.) afin de conserver le contexte de preuve.

En effet, lanalyse peut, dans certains cas modifier (le travail danalyse gnre lui-mme des
traces qui se confondent ensuite avec les traces laisses par lagresseur), voire effacer, les
traces du passage dun attaquant. De fait, il est ncessaire de sauvegarder (par exemple via
une copie intgrale, de type bit bit) les informations avant d'entreprendre toute action
susceptible de nuire l'intgrit des donnes sur le support d'origine.

Si une copie complte des disques nest pas ralisable ou lest difficilement, il faut au moins
conserver une copie des logs (journaux de connexions au systme). Toutefois, cette
sauvegarde nest pas toujours simple mettre en uvre et peut ncessiter des outils et/ou des
comptences particulires.

Enfin, les donnes ainsi sauvegardes doivent tre protges physiquement et un cadre
opratoire doit tre mis en uvre qui prcisera notamment par qui ces sauvegardes ont t
effectues, quel moment, comment elles ont t protges et qui y a eu accs. En fonction
des enjeux, il peut tre recommand de faire appel un huissier de justice.

Le travail dinvestigation pourra alors commencer, si possible sur les copies de sauvegarde,
les disques durs d'origine tant rangs en lieu sr (une procdure pouvant durer des mois,
voire des annes). Ces derniers ainsi que la sauvegarde des logs, pourront servir de preuves
en cas de poursuites judiciaires.

4.3.2.2 Environnements potentiellement concerns
Durant linvestigation il est important de dterminer le primtre concern :
OS,
rseau et tlphonie,
serveurs,
applications,
locaux,
groupe de personnes,
donnes,
services,
clients, fournisseurs, partenaires,

4.3.2.3 Aide lanalyse
Dans chaque environnement technique il existe des outils qui peuvent aider dterminer
l'tendue de l'attaque mene.

Des procdures peuvent galement tre mises en uvre, intgrant des check-lists qui
permettent de raliser lanalyse dans les meilleures conditions. Par exemple, on peut
positionner les actions suivantes :
vrifier les performances des systmes,
rechercher des processus ou des applications non autorises en cours d'excution,
si des logs existent, y rechercher dventuelles connexions inhabituelles, tentatives
d'ouverture de session infructueuses, tentatives d'ouverture de session avec des
comptes par dfaut, etc.,
dterminer si du matriel non autoris a t connect au rseau,
examiner les groupes cls (administrateurs, etc.) afin de vrifier qu'ils ne contiennent
pas de membres non autoriss,
etc.

4.3.2.4 Identification du fait gnrateur et analyse de limpact
Lobjet principal de lanalyse de lincident proprement dit permet de rpondre plusieurs
questions qui se posent, comme par exemple :
quelle est la vulnrabilit ou la faiblesse qui a rendu possible lincident ? Cest la
question la plus importante ! En effet, si aucune rponse claire nest trouve cette
question, le systme restera vulnrable une fois remis en service ; il pourrait tre
attaqu nouveau,

quel est linventaire des dgts ou quel est limpact de lincident (dni de service,
baisse de la qualit du service, perte de donne, divulgation dinformation
confidentielle, etc.).

4.3.3 Traitement
4.3.3.1 Mesures pour viter laggravation des consquences
En complment des mesures de rponses immdiates dj prises ds la qualification de
lincident, des mesures peuvent tre prises pour viter laggravation des consquences.

Disposant ce stade des informations obtenues lors des investigations, ces mesures seront
plus cibles que les rponses conservatoires durgence :
activation de la Cellule de Crise : selle na pas t active lors de la phase de rponse
immdiate, la gestion de crise du PCA peut tre dclenche ce stade, si la situation
sest dgrade entre temps et limpose,
restrictions temporaires daccs aux rseaux ou/et aux applications : ces restrictions
peuvent tre, suivant les cas, des blocages ou des simples filtrages. (exemple :
interdiction daccs certains sites Web),
communications cibles : pour adapter la communication, il faut valuer trs
rapidement la dure de la perturbation (exemple : valuer la dure de restauration par
rapport au volume de donnes restaurer en cas de pertes de donnes). On identifie
trois types de communication :
o communication vers les utilisateurs. Le communiqu contient en rgle gnrale
minima :
les faits qui doivent tre dulcors dans certains cas,
les activits impactes du fait des restrictions temporaires en place,
des consignes de comportements (exemple : ne pas ouvrir les pices
jointes),
lheure prvisionnelle de retour la normale,
o communication technique entre homologues (dautres sites ou filiales) :
les faits prcis,
les recommandations dactions,
une proposition dactions coordonnes,
o communication vers les externes (clients, assureurs, fournisseurs, etc.). On peut
utiliser si besoin la communication de crise prvue dans le cadre du PCA.

4.3.3.2 Dclarations aux assurances
Procder aux dclarations de sinistres en faisant attention :
la tenue des dlais : gnralement 48 heures pour le vol, 5 jours ouvrs au maximum
dans la plupart des autres cas,
ne rien toucher avant la venue de lexpert en assurances sauf ncessit.

En cas d'urgence, on peut remplacer le matriel et mettre le matriel endommag de ct
(cette mesure ne peut tre prise qu'en cas d'urgence, afin d'viter l'arrt de l'exploitation).

Si le sinistre est important, des photos peuvent ne pas suffire, il faut procder un constat par
huissier et faire mettre toutes les preuves sous scells.


4.3.3.3 Rsolution de lincident
Sans tre exhaustifs, les quelques points ci-dessous ncessitent une attention particulire.

Appels aux supports externes

Lentreprise ou lorganisme peut avoir besoin durgence de comptences externes qui
interviendront distance ou sur site et quil faut rserver en priorit en raison des dlais
dintervention.

radication

Lradication du problme dpend du type dincident rencontr.

On peut noter deux grandes tendances entre lesquelles il faudra choisir :
le mode rparation , souvent manuel mais qui peut tre automatis par un script,
le mode restauration ou rinstallation en repartant dune sauvegarde ou dune
image systme.

Les critres de choix entre ces deux mthodes sont :
le temps total (estimation) pour radiquer lincident,
le niveau de certitude davoir bien identifi tous les impacts prcis lis lincident,
le niveau de perte de donnes acceptable.

Dans les cas complexes, il peut tre important dcrire le plan daction correctif pour bien
ordonnancer les tapes.

Dtermination du point zro de lincident
Les lments permettant de dterminer le point zro sont (entre autres):
le recueil des preuves et journaux,
le tmoignage des utilisateurs,
tous les outils de supervision et reporting.

Cette comprhension de lorigine de lincident permet de vrifier la pertinence des mesures
correctives et de rduire le risque de reproduction.

Dlai de Rapprovisionnement de matriel
Mme si lentreprise/organisme utilise le matriel de secours, il nest pas recommand de
rouler trop longtemps sans roue de secours . Cest pourquoi le rapprovisionnement du
matriel est galement une priorit.

Retour la normale
Le retour la normale doit tre associ une communication spcifique.


4.3.3.4 Mthodes et outils

Du dbut la fin de lincident, les outils indispensables sont :
outil denregistrement des vnements ainsi que les moyens daccs associs
(tlphone, messagerie, etc.),
outil de supervision.

Dautres outils peuvent tre utiles ou ncessaires :
outils de diagnostic,
outils de confinement :
o VLAN de confinement,
o blocage au niveau de lannuaire dentreprise/organisme ou des comptes locaux
des quipements,
o blocage ou filtrage sur tout quipement de scurit (pare-feu, relais filtrant http
ou SMTP, etc.),
o etc.,
outils de rparation :
o antivirus / kit de dcontamination antiviral (exemple : cl USB bootable ou le
CD (pour des matriels plus anciens) contenant des anti-malwares et outils
systmes bases de prfrence sur un OS diffrent de celui qui est install et
pouvant prendre en charge de faon fiable le systme de fichier examiner
(exemple : LINUX pour examiner NTFS).
o outils de dploiement de patchs systmes et/ou dapplications,
o outils de restauration dimages systmes, de donnes ou denvironnement
virtuel,
o etc.

Enfin, laccs aux moyens de communication tlphoniques et informatiques et Internet est
indispensable pour communiquer ou sinformer.

En cas dincident empchant laccs ces outils, les quipes dintervention doivent bnficier
de dispositifs alternatifs.

4.3.3.5 Exemples de traitements
Quelques exemples de traitement (synthtis sous forme de Fiche) sont dcrits dans les fiches
suivantes du chapitre 5 - Exemples de typologie des incidents :
vol de PC portable,
installation dun logiciel non autoris,
prsence dun logiciel non autoris,
dysfonctionnement pouvant provenir dun logiciel malveillant,
intrusions logiques,
usage inappropri,
incidents concernant les habilitations,
dni de service Messagerie par saturation du relais public de messagerie,
cas des incidents lis.


4.4. Revues post-incident

4.4.1 Investigation post-incident
Une fois lincident matris, il est possible quil soit ncessaire de lancer des investigations
complmentaires pour bien comprendre comment cet incident a pu avoir lieu. Si tel est le cas,
il ne faut pas hsiter consacrer le temps ncessaire cette tape qui viendra enrichir le
dossier de synthse.

Si des lments de preuve sont encore prsents et que lincident a vocation tre prsent
devant un tribunal, la collecte des indices devra tre particulirement prcise et se conformer
aux bonnes pratiques techniques en adquation avec les obligations lgales.

4.4.2 Rapport de synthse
Chaque incident de scurit doit tre accompagn dun dossier de suivi et si possible dun
rapport de synthse. Ce rapport doit tre rdig par lquipe en charge de la rsolution de
lincident. Il peut servir de cadre directeur lors dune revue post-incident.

Le rapport de synthse doit pouvoir rpondre aux questions suivantes :
lments techniques :
o quel est lobjet de lincident ?,
o quand a eu lieu lincident ?,
o o a-t-il eu lieu ?,
o comment lincident sest-il produit ?,
o comment lincident a-t-il t matris ?,
bilan processus :
o quest-ce qui na pas fonctionn ?,
o quest-ce qui a bien fonctionn ?,
o quest-ce qui ncessite dvoluer en matire de SMSI ?,
o la communication aux parties concernes a-t-elle t bien faite ?,
bilan financier :
o quel est le cot de lincident en matire de perturbation du SI (impact
mtier) ?,
o quel est le cot induit de lincident en matire dincapacit de travailler pour le
personnel ?,
o quel est le cot de lincident en matire de temps de rsolution pass par les
diffrentes quipes ?,
o quel est le cot de la contre-mesure mise en place ?,
o quelles pertes ont pu tre conomises grce lquipe de rponse incident ?

Le rapport de synthse doit tre rdig au plus prs de la date de rsolution de lincident afin
dviter que le temps nefface dans la mmoire des acteurs des lments ou des dtails
importants pour la comprhension et lanalyse de lincident.
Le rapport doit prioritairement prsenter des conclusions claires comprhensibles par les
responsables.

Ce rapport doit tre conserv dans un espace ddi servant de base de connaissance aux
incidents de scurit. Cette base dinformation pourra par la suite tre mise profit pour une
meilleure anticipation des incidents, pour dfinir les contremesures les plus appropries ou
encore pour vrifier si les dcisions actes ont t suivies deffets.

4.4.3 Analyse post-incident
Lanalyse post-incident sinscrit dans une dmarche damlioration continue et de qualit
PDCA permettant de prendre connaissance des lments qui doivent voluer dans le Systme
dInformation.

Cette analyse post-incident doit impliquer les responsables pour que les engagements soient
pris rapidement en matire dvolution du Systme dInformation. Celle-ci peut prendre la
forme dun comit de pilotage ou tout autre type de runion impliquant les dcideurs
adquats.

Un compte-rendu de lanalyse post-incident doit tre rdig pour acter des volutions du
Systme dInformation.

4.5. Actions post-incident

4.5.1 Bilan de lincident
Les informations et les mesures dtermines lors du traitement de lincident doivent tre
conserves et permettre denrichir la base de connaissances.

Dans le traitement d'un incident majeur, il est important danalyser avec recul, ce qui a bien
fonctionn et ce qui a moins bien fonctionn.
Cela doit se traduire par la rdaction d'un bilan adress aux directions concernes.
La mise en place des mesures du bilan, de prfrence sous forme de plan dactions prcis,
devra tre suivie par le responsable scurit.

4.5.2 Le Recours
Dans le cas dune attaque, la responsabilit de lauteur de celle-ci est dabord dordre pnal.
La loi franaise rprime certains actes commis ou tents, notamment :
laccs illgal un systme,
la modification ou la suppression illicite de donnes,
lentrave au fonctionnement dun systme,
lassociation de malfaiteurs informatiques (en tant qulment aggravant).

La France dispose dune lgislation prcise sur le sujet (Articles 323-1 323-7 du Code pnal
relatifs au piratage informatique) et les pirates sont passibles de sanctions parfois
consquentes. C'est pourquoi, il ne faut pas hsiter lutiliser si vous tes victime dune
tentative de piratage, que lattaquant russisse ou non la mener bien.

Il faudra alors runir les lments suivants :
les faits noncs clairement, de manire chronologique, en incluant tout dtail utile,

une liste, la plus complte possible, de tous les prjudices subis (dommages, prjudice
financier, perte de temps pour vrification de l'intgrit du site ou des donnes, perte
de crdibilit auprs des internautes ou des clients de l'entreprise, etc.),
les lments de preuve constitus lors de lanalyse de lincident (pour que ces lments
aient une valeur juridique leur collecte et leur conservation doivent obir des rgles
trs strictes).

Dans un second temps, il faut identifier auprs de qui porter plainte, en gardant en tte que
c'est gnralement le lieu des faits qui est l'lment dterminant.

Des contacts utiles peuvent tre trouvs sur le site Internet du CLUSIF :
www.clusif.fr/fr/production/cybervictime/.

4.5.3 Rvision des contrats
Il peut tre ncessaire de rviser les contrats dassurance ou dengagement avec des
fournisseurs.

4.5.4 Communication interne spcifique (sensibilisation, etc.)
Les incidents rencontrs par l'quipe de rponse aux incidents lui procurent une bonne
visibilit des choses faire et viter. Cette connaissance peut tre mise contribution pour
des actions ponctuelles ou rcurrentes de sensibilisation auprs de publics varis (salaris,
managers, dveloppeurs, etc.).

4.6. Amlioration de la gestion des incidents SSI

Les enseignements tirs des traitements des incidents de scurit doivent contribuer
lamlioration gnrale des processus et des moyens de gestion de ces incidents.

Lensemble des lments doit tre revu priodiquement suite aux incidents ayant un impact
fort sur le SI, et donner lieu des volutions :
politique de gestion des incidents
organisation (principaux acteurs)
processus :
o prvention,
o dtection :
help desk, numro ddi (circuit spcifique) :
pr-qualification,
cration fiche incident,
escalade,
outils de monitoring
o analyse :
problmatique de prservation des preuves,
classification,
lapprciation des risques,
o actions :
correction (ex : rtablissement dun service),

mise en scurit du primtre concern,
dclaration (autorits),
rapports dintervention (base dincidents),
o suivi :
contrle du processus de gestion de lincident,
tableaux de bord sur les diffrents types dincidents (frquence,
impacts),
analyse post-incident,
alimentation de la gestion des problmes,
o recours :
juridique (recherche de preuve),
assurance,
o communication :
information des utilisateurs,
communication externe,
processus annexes (PCA, gestion des problmes, etc.),
audit.

5 - Exemples de typologie des incidents

5.1. Prsentation du format des fiches par type dincident

Ce chapitre prsente quelques fiches de description de diffrents types dincidents de scurit.
Le formalisme de chaque fiche est dcrit ci-dessous, sur la base des thmes suivants :
description du type dincident de scurit,
mesures prventives possibles,
dtection,
qualification,
analyse,
traitement,
actions post-incident.

5.1.1 Description du type dincident de scurit
Dans ce thme, on retrouve les points suivants :
dfinition de lincident,
illustrations (exemples, diffrentes formes, etc.),
classification :
o impacts potentiels selon les deux axes interne et externe (type dimpact,
niveau),
o situations aggravant la potentialit de lvnement gnrateur,
o domaine concern (locaux, personnel, rseau tendu, rseau local, applications,
dveloppements/maintenance, systmes, domaines mtier, scurit gnrale,
SSI, organisation, fournisseurs, etc.),
o type de propagation (immdiat, progressif, dgressif).

5.1.2 Mesures prventives possibles
mesures organisationnelles,
mesures techniques.

5.1.3 Moyens de dtection
manifestation de lincident,
mesures organisationnelles de dtection spcifiques,
outils de dtection disponibles,
type dalerte (Qui alerte ? Qui alerter ?).


5.1.4 Qualification
recueil des informations et recoupements pour catgoriser le type dincident et en
dduire son niveau de svrit,
premires mesures durgences (rponse immdiate).

5.1.5 Analyse
prcautions ncessaires (prservation de preuve),
mesures immdiates (information, dclaration, anticipation du traitement, etc.),
environnements potentiellement concerns,
outils daide lanalyse (logiciels, tests, check-lists, centres de support, internet, etc.),
type descalade (notamment vers le RSSI ou le RPCA).

5.1.6 Traitement
mesures pour viter laggravation des consquences (confinement, information,
vacuation, etc.),
dclarations rglementaires,
rsolution de lincident (radication, reprise, dblocage, activation du PCA, filtrage,
etc.),
selon type dincident : mthode, outils, etc.

5.1.7 Actions post-incident
recours juridique,
assurance,
communication spcifique (sensibilisation, etc.),
audit,
recommandations,
rexamen de lapprciation des risques.

5.2. Fiches par type dincident

5.2.1 Vol de PC portable
5.2.1.1 Description du type dincident de scurit
Dclaration de vol de portable par un utilisateur.
Exemples : Vol de portable dans les locaux de lentreprise/organisme, vol de portable dans les
transports en commun, vol de portable par lutilisateur, etc.
Classification :
impact variable selon la nature des informations contenues et leur niveau de protection
(contrle daccs, chiffrement),
potentialit forte si le portable nest ni surveill ni protg physiquement,
origines possibles : dfaut de contrle daccs aux locaux, absence de mesure de
scurit (quipement de scurit, rglement, sensibilisation, etc.), non respect des
consignes,
type de propagation : immdiat pour le matriel, progressif possible pour le contenu.

5.2.1.2 Mesures prventives possibles
Mesures organisationnelles :
politique de protection des informations,
charte utilisateur,
responsabilisation du personnel (sensibilisation, sanctions, etc.),
inventaire du matriel,
accompagnement des visiteurs,
contrles priodiques du respect des rgles de scurit,

Mesures techniques :
marquage de scurit des quipements (marquage socit, dispositif RFID, etc.),
attache de scurit,
contrles daccs aux locaux (fermeture des accs, camras de surveillance, etc.),
protection des issues,
contrles daccs aux donnes sensibles,
chiffrement des donnes.

5.2.1.3 Moyens de dtection
Manifestation de lincident : dclaration de vol.
Mesures organisationnelles de dtection spcifiques : dcouverte lors dun contrle
dinventaire.
Outils de dtection disponibles : vidosurveillance, portique de dtection (RFID).
Type dalerte (qui alerte : lutilisateur concern ; qui alerter : selon organisation).


5.2.1.4 Qualification
Le niveau de gravit dincident dpend de la fonction du dtenteur, de lusage du portable, du
lieu du vol, etc.

Mesures de rponse immdiates. Ex : blocage immdiat de tous les accs au SI de
lentreprise/organisme partir de ce PC, changement/ rinitialisation des mots de passe, des
codes daccs et dautres authentifiants (certificats) qui ont pu tre mmoriss sur la
machine, etc.

5.2.1.5 Analyse
Prcautions ncessaires (prservation de preuve) : prserver les enregistrements de
vidosurveillance, les logs de contrle daccs.
Mesures immdiates (information, dclaration, anticipation du traitement, etc.) : dpt de
plainte de lutilisateur.
Environnements potentiellement concerns : activits mtier, SSI.
Analyse de lhistorique des connexions et des journaux pour retrouver la dernire connexion,
voire les dernires actions.
Outils daide lanalyse (logiciels, tests, check-lists, centres de support, internet, etc.) : nant.
Type descalade (notamment vers le RSSI ou le RPCA) : selon organisation, impact potentiel
ou situation de lutilisateur.

5.2.1.6 Traitement
Mesures pour viter laggravation des consquences (confinement, information, vacuation,
etc.) : hors mesures prventives et blocage des accs il ny a pas dactions efficaces.
Dclarations rglementaires.
Dclencher le rapprovisionnement du matriel et sassurer que toutes les mesures prventives
de scurit ont t prises.

5.2.1.7 Actions post-incident
Recours juridique.
Assurance.
Communication spcifique (sensibilisation, etc.).
Reporting.
Audit.
Recommandations.

5.2.2 Installation dun logiciel non autoris
5.2.2.1 Dfinition de lincident
Toute tentative dinstallation de logiciel non autoris, volontaire ou non, doit tre considre
comme un incident de scurit.

Linstallation dun logiciel non autoris peut tre faite :
lors dune attaque rseau (virus),
lors dune intrusion,
lors de linstallation dun progiciel non certifi,
lors doprations de maintenance,
par un utilisateur,
lors de lutilisation dun support amovible (cl USB)
lors dune synchronisation dun smartphone comportant des applications non certifis
avec le poste fixe de lutilisateur de lentreprise/organisme.

mise en uvre dune politique antivirale : identification des besoins, des moyens
adapts au niveau de gravit des menaces, des responsabilits pour une dtection dun
code malveillant qui doit tre faite au plus prs de son arrive dans le SI,
contrle des mises en production,
certification des progiciels,
contrle des oprations de maintenance,
responsabilisation des utilisateurs et des quipes informatiques.

Mesures techniques
limiter les privilges dadministration,
anti-malware,
durcissement du poste de travail (interdiction de transferts de donnes de/vers les cls
USB, interdiction de lecture / gravure CD/DVD, listes blanches des programmes
autoriss tre excuts).

Gestion du parc.
Contrle du code.
Scellement des programmes en production (Signature des programmes dploys et dtection
dexcution du code non sign).
Dtection dintrusion.
Anti-malware.

5.2.2.4 Analyse
Dterminer le type de logiciel install et escalader vers diffrentes quipes en fonction de la
dangerosit du code.
Vrifier les droits correspondant au profil dutilisateur.


5.2.2.5 Traitement
Informer lutilisateur.
Revenir ltat initial (reconfiguration du poste).
Appliquer la rponse adapte la nature du logiciel.

Revoir les besoins dutilisateur et ventuellement adapter les profils dutilisation.
Revrifier les failles de scurit.
Sensibilisation adapte la situation de personnel.

5.2.3 Dysfonctionnement pouvant provenir dun logiciel malveillant
5.2.3.1 Dfinition de lincident
Constat dun comportement anormal ou inhabituel dun systme ou dune application
susceptible dtre caus par un malware. Lanomalie peut revtir des formes trs diverses :
perte ou modification de donnes,
blocages dapplication,
dgradation des temps de rponse,
accs disques inhabituels,
surcharge rseau inhabituelle,
messages inhabituels,
modification de laffichage,
etc.

Illustrations (exemples, diffrentes formes, etc.) : perte ou vol de donnes, de fichiers, perte
du contrle de la souris, dni de service, dgradation des performances, etc.

Classification On distingue ainsi diffrents types de logiciels malveillants ou malwares :
les virus informatiques crits dans le but de se propager d'autres ordinateurs via un
programme hte,
les bombes logiques se dclenchent suite un vnement particulier (date systme,
activation distante, etc.),
les vers sont capables de se propager travers un rseau en exploitant les diffrentes
ressources de l'ordinateur qui les hberge pour se reproduire. Ils nont pas besoin d'un
programme hte, contrairement aux virus,
les backdoors ou portes drobes permettent le contrle distance d'un PC par un
pirate. Un ordinateur infect et contrl distance par un pirate est appel BOT ou
zombie. Un rseau de PC infects est un botnet.
les rootkits permettent un pirate de maintenir dans le temps un accs frauduleux un
systme. Un rootkit s'utilise aprs une intrusion et l'installation d'une porte drobe. Il
a pour but la furtivit en cachant par exemple certains processus, certains fichiers et
clefs de registre. Il opre au niveau du noyau, do son nom de kit racine ,
les chevaux de Troie (troyens) sont conus pour effectuer diverses tches l'insu de
l'utilisateur. Cela peut aller de linstallation d'autres malwares, la dsactivation de
certains logiciels de protections (antivirus, pare-feu, etc.), en passant par lenvoi de
messages de SPAM ou bien d'autres fonctionnalits,
les spywares ou logiciels espion, mouchards ou espiogiciels sont conus pour
drober/collecter des informations/donnes, sans que l'utilisateur en ait connaissance,
les keyloggers ou enregistreurs de frappe sont des logiciels ou matriels espion qui
enregistrent les touches frappes sur le clavier et les transmettent via les rseaux, afin
de drober des mots de passe ou autres informations susceptibles d'tre recueillies par
un pirate pour les revendre (adresse e-mail, CB, etc.), obtenir un accs sur un serveur,
etc.,
les adwares sont des logiciels publicitaires qui ouvrent des fentres de publicits.

Impacts potentiels selon les deux axes interne et externe (type dimpact, niveau) :
perte de productivit variant en fonction des moyens mis en uvre pour la protection
et prvention,

atteinte limage dentreprise/organisme,
perte financire.

Potentialit de lvnement gnrateur est forte dans les situations suivantes
anti-malware non install ou dsactiv,
base de signatures danti-malware obsolte,
nouveau malwares non encore gr par lanti-malware,
bug de lanti-malware.

Domaine concern (locaux, personnel, rseau tendu, rseau local, applications,
dveloppements/maintenance, systmes, domaines mtier, scurit gnrale, SSI,
organisation, fournisseurs, etc.) :
tout dpend du contexte dans lequel se trouve la machine, si une segmentation du
rseau est ralise.

Type de propagation (immdiat, progressif, dgressif) : immdiate ou progressive (bombe
logique).

Mesures organisationnelles
mise en uvre dune politique antivirale : identification des besoins, des moyens
adapts aux niveaux de gravit des menaces, des responsabilits pour une dtection
dun code malveillant qui doit tre faite au plus prs de son arrive dans le SI,
mise en place dune procdure dalerte immdiate suite la dtection dun code
malveillant, pour assurer une ractivit maximale,
mise ne place dun contrle du bon fonctionnement des moyens : Mise jour
automatique des signatures, etc.

Mesures techniques
utiliser des moyens de protection diffrents et complmentaires ; plusieurs anti-
malware, filtrage, contrle dintgrit, paramtrage des systmes, des applications,
etc.),
application rgulire des correctifs pour diminuer la vulnrabilit des postes,
contrles multi-niveaux (passerelles HTTP, SMTP, messagerie interne, serveurs de
donnes, postes de travail),
segmentation des rseaux - Firewall, contrle dintgrit, IPS,
contrle des ordinateurs portables et supports.

Par lutilisateur.
Par analyse de lactivit (tableaux de bord).
Par des outils danalyse de comportement (IDS, IPS, SIEM
2
, etc.).

2
Security Information and Event Management

5.2.3.4 Qualification
Dans le processus de qualification il faut prendre en compte : le primtre potentiellement
concern, le comportement du malware, le recoupement rapide avec dautres incidents ou
alertes rcentes du mme type, etc.
Mesures durgence. Exemples : confiner les machines infectes, couper certains accs rseau,
communication de recommandations cibles.

5.2.3.5 Analyse
Prcautions ncessaires pour la prservation de preuves : par exemple, sous Windows, copier
le malware sur une cl USB pralablement vaccine (avec fichier autorun sain et non
supprimable), moins que le logiciel sy invite tout seul !
Vrification de lefficacit des mesures durgences (sinon les complter et les rvaluer).
Recherches pour identifier avec exactitude le malware, puis ses parades.
Recherches pour connatre ltendue relle de linfection.
Dterminer le point zro de linfection.
Choisir le plan daction correctif le plus appropri (exemple : choisir entre une simple
dsinfection par logiciel antivirus ou refaire le systme partir des sauvegardes).
Identifier les modifications effectues par le malware.
Communication des recommandations vers les utilisateurs et escalade vers le RSSI ou le
RPCA.

5.2.3.6 Traitement
Renforcement des mesures pour viter laggravation des consquences (confinement,
information, filtrage, dploiement de patchs ou patterns, etc.).
Activation ventuelle du PCA.
Rsolution de lincident (radication).
Vrification du bon retour la normale (disparition des symptmes et alertes).
Retour la situation normale : fin du confinement ou des filtres disolement, retour des
systmes sains dans le rseau.

Analyse de ce qui a bien march et de ce qui na pas fonctionn, recommandations pour
amliorer les procdures de gestion de crise virale et la politique de scurit.
Communication spcifique (information et sensibilisation des utilisateurs et des acteurs).
Audit.
Assurance.
Recours juridique.

5.2.4 Intrusions logiques
Dfinition de lincident
Intrusion logique : cest le fait pour une personne le plus souvent malveillante de pntrer,
dans un espace logique dfini o sa prsence n'est pas souhaite, aux fins 1] daccder des
informations auxquelles elle naurait pas accs en temps normal ou 2] de modifier, dtruire en
tout ou partie les informations auxquelles elle accde par cette intrusion.

La notion d'intrusion suppose qu'il existe une volont de rserver l'accs des personnes, des
ressources physiques ou logiques, certaines personnes dsignes. L'intrusion est constate
ds le franchissement de la limite entre l'extrieur et l'intrieur mme si cette limite
n'est que symbolique.

Cadre juridique :
Les intrusions logiques sont soumises (entre autres) la loi du 5 janvier 1988, relative a la
fraude informatique, dite Loi Godfrain.
Illustrations (exemples, diffrentes formes, etc.) :
personne / organisation malveillante (pirate informatique, joueur , employ
du , etc.) ralisant une intrusion (depuis le rseau interne ou de lextrieur) en vue
de rcuprer des informations confidentielles, de dtruire ou daltrer des
informations, etc.,
personne accdant involontairement dans un espace priv et sy maintenant.

Classification :
impacts potentiels selon les deux axes interne et externe :
o fuite ou vol dinformations,
o altration et/ou destruction dinformations,
o atteinte limage (communication sur la prsence dune faille),
o introduction de programme malveillant (exemples : spam, botnet, etc.),
potentialit de lvnement gnrateur est forte dans les situations suivantes:
o architecture mal conue ou mal implmente, mauvaise configuration,
correctifs de scurit non installs ou pas jour, etc.,
o zone prive mal identifie, utilisateurs non informs/sensibiliss,
o ouverture du Systme dInformation,
domaines concerns :
o systmes, applications, scurit logique, habilitations, rseaux, tlphonie,
type de propagation :
o immdiat.

politique de scurit du SI :
o politique de contrle et de gestion des droits daccs SI,
o politique daudits et de tests,
o politique de mise jour des systmes (patch),
o SMSI,
rponse aux intrusions / Cellule de crise,
sensibilisation/formation,

information sur le primtre priv (dlimitation, surveillance des accs, sanctions).

mise en place de systme de dtection dintrusion (IDS / IPS),
mise en place darchitecture scurise (cloisonnement, contrle daccs),
mise en place de leurres (honeypot),
mise en place de systme de DLP Data Leak Protection (dtection des fuites
dinformation),
tests de vulnrabilit et dintrusion.

Manifestation de lincident (une intrusion nest pas toujours visible) :
perte ou modification dinformation (destruction),
dgradation des performances, dysfonctionnements, blocages, etc.,
visualisation dinformations confidentielles lextrieur (presse, sites Web, blogs,
etc.),
rduction davantage concurrentiel (espionnage par intrusion).

Mesures organisationnelles de dtection spcifiques :
Veille.

Outils de dtection disponibles :
Analyse des logs,
IDS / IPS,
DLP.

Type dalerte (qui alerte ?, qui alerter ?) :
qui alerte : Cellule de surveillance (NOC / SOC), les administrateurs et les utilisateurs,
lauteur de lintrusion (chantage dans le cas dune intrusion malveillante, alerte
volontaire dans le cas dun accs accidentel),
qui alerter : selon le niveau de lintrusion :
o interne : RSSI, DSI, Direction Mtier, DG, ladministrateur du systme
dhabilitations concern
o externe : police, gendarmerie.

5.2.4.4 Analyse
Prcautions ncessaires (prservation de preuve) : logs.

Mesures immdiates :
activation de la Cellule de crise selon le niveau dimpact,
communication approprie.

Environnements potentiellement concerns : systmes, applications, rseaux, tlphonie.

Outils daide lanalyse : NOC / SOC, IDS / IPS, DLP.

Type descalade
interne : RSSI, DSI, Direction Mtier, DG,

externe : police, gendarmerie, huissier, diteurs concerns.
5.2.4.5 Traitement
Mesures pour viter laggravation des consquences : blocage de rseaux et /ou de systmes,
communication approprie interne / externe, dsactivation des accs au SI injustifis
constats.

Dclarations rglementaires : police, gendarmerie, assurance.

Rsolution de lincident :
reprise, rinstallation, restauration des donnes perdues ou altres,
rvision des dispositifs de cloisonnement et de filtrage, etc.

Recours juridique : dpt de plainte.

Assurance : dclaration de perte (si contrat spcifique souscrit).

Communication spcifique (sensibilisation, etc.) : sensibilisation des utilisateurs, formation
des personnes de la cellule de crise, de la cellule de gestion / suivi des incidents, etc.

Audit : ethical hacking.

Recommandation : vrification des autres domaines susceptibles dtre vulnrables la mme
intrusion. Revoir la politique de contrle des accs au SI.

5.2.5 Usage inappropri des ressources informatiques
Usage inappropri: Lincident de ce type survient quand un utilisateur excute des actions
non-conformes la politique de scurit et/ou aux rgles dutilisation du Systme
dInformation.

tlchargement doutils de piratage de mots de passe,
envoi de courriels agressant les collaborateurs,
publication du site Internet personnel,
publication ou diffusion des donnes illicites ou diffamatoires,
tlchargement ou diffusion de contenus prohibs (sites pdophiles par exemple),
publication ou acquisition des donnes / mdias pirats (images, musique, vido,
progiciels, etc.),
envoi vers les correspondants ou sites externes des donnes internes sensibles,
attaques de sites externes (Spam, DoS, altration dun site web, achats en ligne avec
les cartes de crdit voles, etc.).

Classification :
impacts potentiels selon les deux axes interne et externe (type dimpact, niveau) :
o dgradation dimage de lentreprise/organisme,
o diminution de la capacit des ressources du SI,
o impact financier,
potentialit de lvnement gnrateur :
o politique et rgles de scurit non communiques,
o absence de charte et du code de dontologie,
o droits daccs mal maitriss (trop permissifs) et vulnrabilits non maitrises,
o absence des moyens de monitoring, du contrle du contenu et dIDS,
domaines concerns (locaux, personnel, rseau tendu, rseau local, applications,
organisation, fournisseurs, etc.) :
o applications, systmes,
type de propagation (immdiat, progressif, dgressif) :
o non dtermin.

mise en uvre de la politique de scurit, de la charte,
mise en place et communication des sanctions.

mise en place de dtection par IDS/IPS,
mise en place de systmes anti-spam en entre et en sortie,
mise en place des moyens de protection rseau/protocole bloquant les outils non
autoriss (peer2peer, etc.),

mise en place des moyens de proxy et de filtrage dURLs pour verrouiller laccs aux
sites non-conformes la politique de scurit,
mise en place de contrle de contenu des messages et de pices jointes,
restriction des droits,
mise en place de surveillance des logs daccs et systmes.

5.2.5.3 Dtection
Manifestation de lincident :
signalisation par un utilisateur interne,
signalisation, plainte par un utilisateur ou organisation externe,
dtection par supervision scurit (IDS/IPS, SIEM),
utilisation anormale des ressources (CPU, mmoire, stockage, bande passante),
prsence de nouveaux, fichiers et rpertoires non identifis et/ou flux rseaux,
excution de nouveau processus non connu.

Mesures organisationnelles de dtection spcifiques : mise en place de cellule danalyse
systmatique des logs et des plaintes.

supervision scurit (IDS/IPS, SIEM),
supervision des ressources (serveurs, rseau, etc.).

Type dalerte (qui alerte ?, qui alerter ?)
qui alerte :
o cellule de surveillance (NOC / SOC),
o cellule Supervision,
o utilisateur,
o personne / organisme externe,
qui alerter - selon le type dincident :
o activit criminelle : ressources humaines, direction juridique, police,
personne/organisation externe impacte (le cas chant),
o dgradation majeure : RSSI, DSI, direction gnrale, direction de la
communication,
o dgradation ou impact mineure : RSSI, DSI, ressources humaines.

5.2.5.4 Analyse
Prcautions ncessaires (prservation de preuves) : archivage des logs et des alertes.

Mesures immdiates (information, dclaration, anticipation du traitement, etc.)
analyse pour dterminer sil sagit ou non dacte criminel,
valuation dimpact sur limage de lentreprise/organisation,
communication la direction gnrale, de la communication, juridique, ressources
humaines et la police en fonction de la nature et de la gravit de lincident,
mesures techniques conservatoires pour limiter limpact de lincident.

Environnements potentiellement concerns : ressources du SI, ressources dautres SI.

Outils daide lanalyse (logiciels, tests, check-lists, centres de support, internet, etc.) : NOC /
SOC, IDS / IPS, SIEM (supervision scurit).

Type descalade (notamment vers le RSSI ou le RPCA) :
interne : RSSI, DSI, RH, DG, Direction Juridique,
externe : police, gendarmerie.

5.2.5.5 Traitement
etc.)
sauvegarde des preuves et des traces (log)
arrt de processus non-conformes, blocage de flux rseau non-conformes,
avertissement des utilisateurs concerns.

Dclarations rglementaires : assurance, police ou gendarmerie dans le cas dacte criminel.

Rsolution de lincident (radication, reprise, dblocage, activation du PCA, filtrage, etc.) :
enqute pour dterminer les auteurs (assurer la discrtion),
suppression des programmes et des donnes non-conformes,
filtrage des flux, etc.,
mesures techniques de restauration dtat initial,
mise en uvre de moyens supplmentaires de dtection ou optimisation des rgles.

Recours juridique : sanctions, dpt de plainte (si acte criminel).

Assurance : dclaration dincident si organisme externe impact.

Communication spcifique (sensibilisation, etc.) :
sensibilisation des utilisateurs,
communication publique dans les mdias (si dgradation majeure dimage).

Audit et Recommandations

5.2.6 Incidents concernant les habilitations
verrouillage de compte privilges (de type : comptes administration, comptes de
service ou comptes dexploitation),
extension ou existence de privilge, non justifie (exemple : cration compte
privilge sans accord, compte non supprim lors du dpart dune personne),
utilisation non autorise de comptes privilge (comptes impersonnels, comptes
gnriques),
cumul de droits attribus une personne non conforme la lgislation ou la
rglementation,
usurpation didentit numrique,
lun des cas prcdents concernant un utilisateur VIP.

connexion via un compte et un mot de passe dcouverts,
o par coute passive sur le rseau (interception des comptes et mots de passe sur
le rseau),
o suite un vol de matriel informatique pouvant hberger des donnes de
connexion (PDA, ordinateur portable),
blocage de comptes privilges suite des tentatives dintrusion,
connexion des heures non autorises ou non justifies pour le profil,
connexion du compte alors que la personne nest pas prsente,
apparition de nouveaux comptes administrateurs.

Classification :
impacts potentiels selon les deux axes interne et externe (type dimpact, niveau) : fuite
dinformations, destruction dinformations, dni de service, changement de
configuration, dysfonctionnements, blocages utilisateurs, perte de productivit,
potentialit de lvnement gnrateur : mauvaise gestion des droits daccs, mots de
passe dadministration non changs,
organisation, fournisseurs, etc.),
type de propagation (immdiat, progressif, dgressif) : immdiat ou progressif.

politique de scurit du SI / Politique de traces / Politique de gestion des droits
daccs,
politique de sgrgation des tches (Segregation of Duties = SoD en anglais),
notion de Propritaire de ressource,
mise en place dune Cellule de surveillance Scurit (remonte dvnements non
conforme aux politiques),
gestion centralise des habilitations et des rgles,
mise en place daudits et de revues priodiques des habilitations systme, applications
et services,

dfinition dune politique de dtection,
information et sensibilisation.

dispositifs de contrle daccs,
outils de gestion et de suivi des identits et des droits,
outils de provisioning .

5.2.6.3 Dtection
Manifestation de lincident :
via les outils de gestion des vnements de scurit,
via les outils de dtection dintrusions,
via les revues priodiques des habilitations pilotes par les responsables des
applications, des systmes et des infrastructures,
via des outils de surveillance des activits inhabituelles (dans la limite des lgislations
et rglementations locales).

Mesures organisationnelles de dtection spcifiques : audit interne et revues priodiques.

outils de centralisation des logs, et remontes dalertes (temps rel ou reporting),
outils de dtection dintrusions, IDS/IPS,
outils daudit des habilitations.

Type dalerte :
qui alerte : Help-Desk, Cellule de surveillance Scurit, Auditeur, Responsable de
ressource,
qui alerter : Cellule de surveillance Scurit, RSSI.

5.2.6.4 Analyse
Prcautions ncessaires (prservation de preuve) :
Prservation des logs,
Ralisation dune copie des supports concerns pour faire lanalyse.

Mesures immdiates (information, dclaration, anticipation du traitement, etc.) : dsactivation
du compte, arrt de lquipement mis en cause.

Environnements potentiellement concerns : tous les lments de linfrastructure (rseau,
systme, application).

Outils daide lanalyse (logiciels, tests, check-lists, centres de support, internet, etc.) :
outils de gestion des vnements de Scurit,
outils de dtection dintrusions,
outils danalyse des logs des systmes et applications.

Type descalade (notamment vers le RSSI ou le RPCA) :
interne : RSSI, DSI, Responsable Mtier,
externe : diteurs concerns, responsable dun prestataire en cause, etc.


5.2.6.5 Traitement
etc.) :
supprimer / dsactiver le compte,
supprimer / dsactiver laccs (tentatives extrieures),
ractivation du compte en cas de verrouillage, avec rinitialisation du mot de passe,
application de correctifs (systme, applicatif, etc.),
application de procdure disciplinaire.

Dclarations rglementaires et contractuelles : police, gendarmerie, assurance.

Rsolution de lincident (radication, reprise, dblocage, activation du PCA, filtrage, etc.)
reprise, rinstallation, restauration des donnes perdues,
ajustement des droits si ncessaire.

Recours juridique : dpt de plainte.

Assurance : suivi du dossier sinistre (si contrat spcifique souscrit).

Communication spcifique (sensibilisation, etc.) :
sensibilisation des utilisateurs,
chartes Utilisateurs et Administrateurs.

Audit.

Recommandations :
gestion des habilitations en fonction des rles, profils,
limitation et surveillance des comptes gnriques,
comptes nominatifs,
authentification forte,
limitation du nombre de sessions concurrentes,
traabilit des actions sur comptes privilges,
scurisation des flux de connexion,
ralisation de revues priodiques et correction des carts,
verrouillage de comptes aprs un nombre de tentatives dfinie,
suppression des comptes aprs le dpart,
rvision des droits aprs mobilit,
rvision des processus de gestion des habilitations aprs mobilit,
changement des mots de passe par dfaut,
changement priodique des mots de passe.

5.2.7 Dni de service Messagerie par saturation du relais public de
messagerie

Dfinition de lincident :
Fortes perturbations du trafic de messagerie publique, voire prive, lies une attaque externe
sur les relais publics de messagerie (MX Mail eXchanger).

Illustrations Afflux massif de :
connexions au relais de messagerie, sans dpt de message valide,
messages pour des destinataires internes nexistant pas,
messages non sollicits pour des destinataires internes existants.

Classification :
origines possibles : spammers, hackers, concurrence, mafia,
impacts potentiels selon les deux axes interne et externe (type dimpact, niveau) :
o messages provenant de lextrieur :
parvenant aux destinataires internes avec un dlai inhabituel,
pour lequel les expditeurs externes reoivent une alerte de leur propre
messagerie indiquant un retard ou un chec de dlivrance,
o messages mis vers lextrieur :
parvenant aux destinataires externes avec un dlai inhabituel,
pour lequel les expditeurs internes reoivent une alerte de leur propre
messagerie indiquant un retard ou un chec de dlivrance,
o messages internes lentreprise/organisme :
parvenant aux destinataires avec un dlai inhabituel,
impossible envoyer (connexion avec Messagerie interrompue),
potentialit de lvnement gnrateur : forte,
domaine concern :
o personnes utilisant la messagerie,
o applications utilisant la messagerie,
o systmes hbergeant lenvironnement messagerie,
o applications hberges sur ces mmes systmes,
o rseaux hbergeant les systmes de messagerie,
type de propagation : progressif.

dfinir un plan progressif :
o dactions, pour contenir lattaque et en limiter les effets,
o de communication interne pour informer des ralentissements, et inviter les
utilisateurs utiliser des canaux de communication alternatifs.

squiper de systmes adapts pour assurer le service relais public de messagerie,
superviser attentivement les relais.

Principales caractristiques dun environnement de relais de messagerie public adapt :
ne pas mixer les services Relais public de Messagerie et Messagerie sur les
mmes systmes,
disposer de relais redonds, voir secourus :
o 2 relais (1 principal, 1secondaire),
o ventuellement, 1 troisime relais, invisible,
isoler ces relais par un pare-feu,
quiper tous les relais (et pas seulement le principal) dun systme de filtrage anti-
spam volu :
o capable de dtecter et bloquer la plupart de ces attaques massives,
o communicant avec lannuaire dentreprise/organisme, pour ne relayer au
systme de Messagerie que les messages quil pourra dlivrer,
configurer finement les relais afin quils supportent les surcharges de trafic (tailles des
queues de traitement, dlai de rtention des quarantaines, etc.),
selon contexte dsactiver les avis de non-dlivrance dun message provenant de
lextrieur vers un destinataire interne inconnu :
o car cest un moyen de DOS : Si ladresse mettrice est fausse, lavis ne sera
jamais dlivr, saturera les files dattente, voire surchargera le systme dune
autre entreprise/organisme,
o mais cela gnera les vritables utilisateurs externes qui ne seront pas prvenus
sils saisissent mal une adresse de messagerie (dupon@domain.com au lieu de
dupont@domaine.com),
adapter le TTL (Time To Live) des dclarations DNS MX (Mail eXchanger) pour
quelles soient propages rapidement (quelques minutes),
organiser le circuit de dcision et daction pour que rapidement :
o les enregistrements DNS puissent tre modifis,
o le trafic Internet vers un relais puisse tre bloqu.

5.2.7.3 Dtection
Manifestation de lincident : dlai inhabituel de dlivrance des messages.

Mesures organisationnelles de dtection spcifiques : sensibiliser le Help-desk au reprage des
symptmes utilisateurs dans les appels traits > dclenchement dalerte dans les meilleurs
dlais.

test rgulier du dlai dchange de messages entre 2 messageries publiques
indpendantes (par exemple entre partenaires, ou avec le fournisseur Internet),
superviser les relais publics de messagerie,
superviser les systmes de messagerie.

Type dalerte (qui alerte ?, qui alerter ?) :
sources : quipes Help desk ou Supervision,
cibles : quipes (trs variable selon organisations) grant :
o les applications fournissant le service relais public de messagerie (messagerie,
rseau, scurit),
o les systmes hbergeant ces applications (Windows, Unix, messagerie etc.),
o les applications de messagerie (messagerie),

o les systmes hbergeant la messagerie (Windows, Unix, etc.),
o le firewall (scurit ou rseau),
o le WAN et le LAN (rseau).

5.2.7.4 Analyse
Prcautions ncessaires (prservation de preuves) : archiver les journaux des relais de
messagerie et du firewall.
Environnements potentiellement concerns : messagerie.
Outils daide lanalyse : outils de supervision et de logs des relais et du Firewall.
Type descalade : RSSI.
Communication interne : si les dlais sallongent, alerte gnrale aux utilisateurs, avant que le
systme de messagerie devienne inoprant.

5.2.7.5 Traitement
etc.) :
identifier le relais le plus satur,
aiguiller le trafic sortant sur le relais le moins charg (voire un relais ddi la sortie),
afin quil ne soit pas impact par lattaque (action au niveau des systmes de
messagerie ou des dclarations MX du DNS priv),
aiguiller le trafic entrant sur un relais moins charg, pour absorber la suite du trafic
(action au niveau des dclarations MX du DNS public),
couper le trafic Internet vers le relais satur, le temps quil vide ses files dattente
(action au niveau du firewall, ventuel redmarrage du systme).

Dclarations rglementaires : Nant.

Pas de rsolution Il faut juste mettre en uvre les mesures vitant laggravation, et les
rpter jusqu ce que lattaque sessouffle.

Note : Les attaques ciblent souvent un seul des relais Larrter totalement pendant plusieurs
minutes peut mettre un terme lattaque.

Recours juridique : Dposer une plainte contre X (de principe, pour les statistiques les
attaques sont dorigines supra-nationales, donc aucun recours esprer).

Assurance : Risque complexe assurer (il est plus simple de se protger).

Communication spcifique (sensibilisation, etc.) : quipes techniques concernes, pour
disposer de la meilleure ractivit lors de la survenance de lincident.

Audit : Analyse rgulire des performances des relais.

Recommandations : Si limpact dune attaque a t jug intolrable, ou si les impacts
importants sont courants, il est ncessaire de rviser et renforcer larchitecture de relais public.

5.2.8 Cas des incidents lis
Des incidents sont lis lorsque lun dentre eux na t possible qu la suite de la survenance
dun incident prcdent. Le second incident nest pas une consquence directe du premier
mais sa survenance a t rendue possible ou facilite. Une chaine dincidents lis les uns aux
autres est galement possible. La difficult dans le cas dincidents lis est de faire le
rapprochement entre des incidents pouvant tre de natures trs diffrentes et dapporter une
rponse organise aux diffrents phnomnes.

Illustrations (exemples, diffrentes formes, etc.)
premier incident : dfaut de mise niveau des paramtres de scurit dun serveur
suite une opration de maintenance. Second incident : exploitation des vulnrabilits
du serveur par un utilisateur indlicat,
premier incident : infection dun poste de travail par un malware permettant den
prendre la main distance. Second incident : attaque du rseau interne partir de la
station de travail par un individu ayant connaissance de cette vulnrabilit. Dans un tel
scnario, les attaques successives sont susceptibles dintroduire de nouvelles
vulnrabilits la source de nouveaux types dincidents, par exemple attaque dune
entreprise ou un organisme tierce partir dun serveur interne vulnrable.

Classification :
les impacts dans de tels scnarios sont ceux des incidents considrs sparment, avec
une possibilit damplification due la simultanit,
la potentialit dincidents lis dpend fortement de lefficacit du processus de gestion
des incidents de scurit, c'est--dire dune part lexhaustivit des cas grs et de la
rapidit de dtection et de mise en uvre des contre-mesures,
organisation, fournisseurs, etc.). Les incidents lis peuvent concerner des domaines
diffrents,
type de propagation (immdiat, progressif, dgressif) : immdiat ou diffr.

Les mesures prventives sont celles associes aux diffrents types dincident considrs
sparment.

5.2.8.3 Dtection
Manifestation de lincident : ce sont les manifestations de chaque incident individuel.

Mesures organisationnelles de dtection spcifiques : faire en sorte que les personnes charges
de la rsolution de chaque incident aient une information sur les types dincident en cours.

Outils de dtection disponibles : centralisation des informations sur les incidents.

Type dalerte (qui alerte ?, qui alerter ?) : alerter le RSSI et les responsables des domaines
concerns.


5.2.8.4 Analyse
Prcautions ncessaires (prservation de preuve) : propres chaque type dincident.

Mesures immdiates (information, dclaration, anticipation du traitement, etc.) : lors de
lanalyse dun incident, prendre en compte les scnarios dextension possibles et identifier
lincident initial (exemple : vrifier le paramtrage des autres quipements du domaine).

Environnements potentiellement concerns : tous.

Outils daide lanalyse (logiciels, tests, check-lists, centres de support, internet, etc.)
Base des incidents, exploitation centralise des journaux et analyses de corrlations.

Type descalade (notamment vers le RSSI ou le RPCA) : RSSI.

5.2.8.5 Traitement
etc.) : tablir des priorits. En principe le premier incident gnrateur doit tre trait en
premier. Si tous les incidents ne peuvent tre traits simultanment, tablir des priorits en
fonction des impacts potentiels et de limportance des vulnrabilits rsiduelles.

Dclarations rglementaires : propres chaque type dincident concern.

propre chaque type dincident concern.

Selon type dincident : mthode, outils, etc. : propres chaque type dincident concern.

Si ncessaire, rvision des mesures de scurit (mesures prventives, etc.) pour rduire la
probabilit doccurrence dincidents lis et/ou de gestion des incidents (outils danalyse, etc.).

Communication spcifique (sensibilisation, etc.) : tablissement dun rapport de suivi.

Recours juridique : propre chaque type dincident concern.

Assurance : propre chaque type dincident concern.

6 - Glossaire (source principale : Wikipedia)

Terme Commentaire
CD
Un CD (abrviation de (en) Compact Disc ), ou disque compact, est un disque
optique utilis pour stocker des donnes sous forme numrique.
CPU
Le processeur, ou CPU (de l'anglais Central Processing Unit, Unit centrale de
traitement ), est le composant de l'ordinateur qui excute les programmes
informatiques.
CERT
Central Emergency Response Team / Coordination Center situ luniversit de
Carnegie Mellon aux Etats-Unis.
CERTA
Centre d'Expertise Gouvernemental de Rponse et de Traitement des
Attaques informatiques du gouvernement franais.
COBIT
Le CobiT (Control Objectives for Information and related Technology
Objectifs de contrle de lInformation et des Technologies Associes) est un outil
fdrateur qui permet d'instaurer un langage commun pour parler de la
Gouvernance des systmes d'information tout en tentant d'intgrer d'autres
rfrentiels tels que ISO 9000, ITIL.
CNIL
La Commission nationale de l'informatique et des liberts (CNIL) est une
autorit administrative indpendante franaise. La CNIL est charge de veiller
ce que linformatique soit au service du citoyen et quelle ne porte atteinte ni
lidentit humaine, ni aux droits de lhomme, ni la vie prive, ni aux liberts
individuelles ou publiques. Elle exerce ses missions conformment la loi n78-
17 du 6 janvier 1978 modifie le 6 aot 2004.
CSIRT
(Computer Security Incident Response Team) ou ISIRT (Information Security
Incident Response Team).
DLP
Le terme Data Loss Prevention (DLP) fait rfrence un ensemble de
techniques de protection contre la fuite d'informations en informatique.
DNS
Le Domain Name System (ou DNS, systme de noms de domaine) est un
service permettant d'tablir une correspondance entre une adresse IP et un nom
de domaine et, plus gnralement, de trouver une information partir d'un nom
de domaine.
DVD
Le DVD officiellement Digital Versatile Disc est un disque optique numrique
exploit pour la sauvegarde et le stockage de donnes, notamment la vido pour
sa dclinaison DVD Video.
Firewall
Un pare-feu, ou firewall (de l'anglais), est un logiciel et/ou un matriel, permettant
de faire respecter la politique de scurit du rseau, celle-ci dfinissant quels sont
les types de communication autoriss sur ce rseau informatique. Il mesure la
prvention des applications et des paquets.
IDS
Un systme de dtection d'intrusion (ou IDS : Intrusion Detection System) est
un mcanisme destin reprer des activits anormales ou suspectes sur la cible
analyse (un rseau ou un hte). Il permet ainsi d'avoir une connaissance sur les
tentatives russies comme choues des intrusions.
IPS
Un systme de prvention d'intrusion (ou IPS, Intrusion Prevention System) est
un outil des spcialistes en scurit des systmes d'information, similaire aux IDS,
permettant de prendre des mesures afin de diminuer les impacts d'une attaque.
C'est un IDS actif, il dtecte un balayage automatis, l'IPS peut bloquer les ports
automatiquement. Les IPS peuvent donc parer les attaques connues et
inconnues.
IT
Informatique et Tlcoms (Information Ttechnology)
ITIL
ITIL (Information Technology Infrastructure Library pour Bibliothque pour
l'infrastructure des technologies de l'information ) est un ensemble d'ouvrages
recensant les bonnes pratiques ( best practices ) pour le management du
systme d'information, dictes par l'Office public britannique du Commerce
(OGC).

Terme Commentaire
LINUX
Linux est un logiciel libre cr en 1991 par Linus Torvalds et dvelopp sur
Internet par des milliers dinformaticiens bnvoles ou salaris. C'est le noyau de
nombreux systmes dexploitation. Il est de type UNIX et compatible POSI.
MX
Un enregistrement Mail eXchanger (MX) est un type d'enregistrements du
Domain Name System qui associe un nom de domaine un serveur de
messagerie lectronique associ son numro de prfrence.
NOC
Un centre d'opration d'un rseau (en anglais, Network Operations Center,
abrg NOC) est un service charg du contrle des transactions, de la
surveillance des incidents, de la charge d'un rseau local ou interconnect
NTFS
NTFS (New Technology File System) est un systme de fichiers conu pour
Windows NT (et ses successeurs chez Microsoft) pour stocker des donnes sur
disque dur.
MSSP
Managed Security Services Provider : fournisseurs de services d'infogrance
en scurit.
PC
Personal computer ordinateur personnel.
PCA
Le plan de continuit ou plan de continuit dactivit (PCA) est la fois le nom
dun concept, dune procdure et du document qui la dcrit.
Ce plan doit permettre un groupe (gouvernement, collectivit, institution,
entreprise, hpital..) de fonctionner mme en cas de dsastre ; quitte ce que ce
soit en mode dgrad, ou en situation de crise majeure.
PDA
Un assistant numrique personnel est un appareil numrique portable, souvent
appel par son sigle anglais PDA pour Personal Digital Assistant.
Peer2peer
Le pair--pair (traduction de l'anglicisme peer-to-peer, souvent abrg P2P ),
est un modle de rseau informatique proche du modle client-serveur mais o
chaque client est aussi un serveur.
PRA
En informatique, un plan de reprise d'activit (en anglais Disaster Recovery
Plan ou DRP) permet d'assurer, en cas de crise majeure ou importante d'un
centre informatique, la reconstruction de son infrastructure et la remise en route
des applications supportant l'activit d'une organisation.
Proxy
Un serveur mandataire ou proxy (de l'anglais) est un serveur informatique qui a
pour fonction de relayer des requtes entre un poste client et un serveur.
PSSI
La politique de scurit des systmes d'information (PSSI) est un plan
d'actions dfinies pour maintenir un certain niveau de scurit. Elle reflte la vision
stratgique de la direction de l'organisme (PME, PMI, industrie, administration,
tat, unions d'tats ) en matire de scurit des systmes d'information (SSI).
RFID
La radio-identification plus souvent dsigne par le sigle RFID (de langlais
Radio Frequency IDentification) est une mthode pour mmoriser et rcuprer
des donnes distance en utilisant des marqueurs appels radio-tiquettes (
RFID tag ou RFID transponder en anglais.
RPCA
Le responsable du plan de continuit dactivit
RSSI
Le responsable de la scurit des systmes d'information
SI
Un systme d'information (SI) est un ensemble organis de ressources
(matriels, logiciels, personnel, donnes et procdures) qui permet de regrouper,
de classifier, de traiter et de diffuser de l'information sur un environnement donn
..

SIEM
Security Information and Event Management
Le principe du Security Information Management (SIM) est de grer les
vnements du Systme d'Information (SI).
Appels galement SEM (Security Event Management) ou SEIM (Security Event
Information Management) ou encore SIEM (Security Information and Event
Management), ils permettent de grer et corrler les logs. On parle de corrlation
car ces solutions sont munies de moteurs de corrlation qui permettent de relier
plusieurs vnements une mme cause.

Terme Commentaire
SMSI
Un systme de gestion de la scurit de l'information (en anglais : Information
security management system, ou ISMS) est, comme son nom le suggre, un
systme de gestion concernant la scurit de l'information.
L'expression Systme de Management de la Scurit de l'Information (SMSI) est
galement utilise en franais.
Le plus connu des SMSI est ISO/CEI 27001, publi par l'ISO en complment de
ISO/CEI 27002 (anciennement rfrenc ISO/CEI 17799.
SOC
Un centre d'opration de scurit (en anglais, Security Operations Center, abrg
SOC) est un service charg du contrle de la scurit des transactions et de la
surveillance des incidents de scurit.
SOD
Separation of Duties - La contrainte de sparation des pouvoirs est utilise pour
assurer le respect de la politique des habilitations.
SMTP
Le Simple Mail Transfer Protocol (littralement Protocole simple de transfert
de courrier ), est un protocole de communication utilis pour transfrer
le courrier lectronique (courriel) vers les serveurs de messagerie lectronique.
SSI
La scurit des systmes dinformation (SSI) est lensemble des moyens
techniques, organisationnels, juridiques et humains ncessaire et mis en place
pour conserver, rtablir, et garantir la scurit du systme d'information.
TTL
Le Time to Live ( temps de vie ), abrg TTL, indique le temps pendant lequel
une information doit tre conserve, ou le temps pendant lequel une information
doit tre garde en cache.
URL
Le sigle URL (de l'anglais Uniform Resource Locator, littralement
localisateur uniforme de ressource ), auquel se substitue informellement le terme
adresse web, dsigne une chane de caractres utilise pour adresser les
ressources du World Wide Web : document HTML, image, son, forum Usenet,
bote aux lettres lectronique, etc. Les URL constituent un sous-ensemble des
identifiants uniformiss de ressource (URI). Le format (syntaxe) d'une URL est
dcrit dans le RFC 3986.
USB
LUniversal Serial Bus (USB) est une norme relative un bus informatique en
transmission srie qui sert connecter des priphriques informatiques un
ordinateur.
VIP
VIP signifie en anglais personne trs importante (Very Important Person, de
russe viesima imenitaa persona) et dsigne par exemple les chefs d'tat, les
politiciens, les personnes trs riches, les clbrits.
VLAN
Un rseau local virtuel, communment appel VLAN (pour Virtual LAN), est
un rseau informatique logique indpendant. De nombreux VLAN peuvent
coexister sur un mme commutateur rseau (switch).
WAN
Un rseau tendu (terme recommand au Qubec), souvent dsign par
l'anglais Wide Area Network (WAN), est un rseau informatique couvrant une
grande zone gographique, typiquement l'chelle d'un pays, d'un continent,
voire de la plante entire.

L E S P R I T DE L C HANGE

CLUB DE LA SCURIT DE L'INFORMATION FRANAIS
11, rue de Mogador
75009 Paris
01 53 25 08 80
clusif@clusif.asso.fr

Tlchargez les productions du CLUSIF sur
www.clusif.asso.fr

CLUSIF 2011 Gestion Des Incidents

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CLUSIF 2011 Gestion Des Incidents

Uploaded by

Copyright:

Available Formats

LES DOSSIERS TECHNIQUES

Gestion des incidents de scurit

You might also like