CLUSIF 2011 Gestion Des Incidents

8/13/2019 CLUSIF 2011 Gestion Des Incidents

1/60

LES DOSSIERS TECHNIQUES

Gestion des incidents de scuritdu systme dinformation (SSI)

Mai 2011

Groupe de travail Gestion des incidents

CLUB DE LA SECURITE DE LINFORMATION FRANAIS

11 rue de Mogador - 75009 ParisTl. : +33 1 53 25 08 80 Fax : +33 1 53 25 08 [email protected] www.clusif.asso.fr


2/60

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 reproductionsstrictement rserves l'usage priv du copiste et non destines une utilisation collective et, d'autre part, que les analyseset 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 lesarticles 425 et suivants du Code Pnal


3/60

Gestion des incidents I CLUSIF 2011

Table des matires

Remerciements.........................................................................................................................IV1 - Introduction...........................................................................................................................92 - Primtre du document ....................................................................................................... 10

2.1. Objectifs du document ............................................................................................. 102.2. Dfinition dun incident SSI dans le cadre de ce document..................................... 11

3 - Organisation de la gestion des incidents SSI ...................................................................... 123.1. Introduction ..............................................................................................................123.2. Politique de gestion des incidents de scurit .......................................................... 123.3. Les Mesures mettre en place.................................................................................. 123.4. Organisation .............................................................................................................15

3.4.1 Prambule......................................................................................................... 153.4.2 quipe de rponse aux incidents SSI ...............................................................16

3.4.2.1 Fonctionnement............................................................................................ 173.4.2.2 Services et primtre .................................................................................... 193.5. Processus de traitement des incidents ...................................................................... 22

4 - Gestion des incidents de SSI............................................................................................... 244.1. Dtection et signalement .......................................................................................... 244.2. Prise en compte ........................................................................................................ 24

4.2.1 Enregistrement de lincident ............................................................................ 244.2.2 Catgorisation par une quipe support ............................................................. 254.2.3 Qualification par lquipe de rponse aux incidents de scurit ...................... 25

4.3. Rponse lincident SSI .......................................................................................... 264.3.1 Mesures de rponses immdiates ..................................................................... 264.3.2 Investigations.................................................................................................... 26

4.3.2.1 Prservation des traces ................................................................................. 264.3.2.2 Environnements potentiellement concerns................................................. 274.3.2.3 Aide lanalyse ............................................................................................ 274.3.2.4 Identification du fait gnrateur et analyse de limpact................................ 27

4.3.3 Traitement ........................................................................................................ 284.3.3.1 Mesures pour viter laggravation des consquences................................... 284.3.3.2 Dclarations aux assurances......................................................................... 284.3.3.3 Rsolution de lincident ............................................................................... 294.3.3.4 Mthodes et outils ........................................................................................30

4.3.3.5 Exemples de traitements............................................................................... 304.4. Revues post-incident ................................................................................................ 314.4.1 Investigation post-incident ............................................................................... 314.4.2 Rapport de synthse..........................................................................................314.4.3 Analyse post-incident .......................................................................................32

4.5. Actions post-incident................................................................................................ 324.5.1 Bilan de lincident ............................................................................................ 324.5.2 Le Recours........................................................................................................ 324.5.3 Rvision des contrats........................................................................................ 334.5.4 Communication interne spcifique (sensibilisation, etc.) ................................ 33

4.6. Amlioration de la gestion des incidents SSI........................................................... 335 - Exemples de typologie des incidents .................................................................................. 35

5.1. Prsentation du format des fiches par type dincident.............................................. 35


4/60

Gestion des incidents II CLUSIF 2011

5.1.1 Description du type dincident de scurit ....................................................... 355.1.2 Mesures prventives possibles ......................................................................... 355.1.3 Moyens de dtection......................................................................................... 355.1.4 Qualification.....................................................................................................365.1.5 Analyse .............................................................................................................36

5.1.6 Traitement ........................................................................................................ 365.1.7 Actions post-incident........................................................................................ 36

5.2. Fiches par type dincident ........................................................................................375.2.1 Vol de PC portable ........................................................................................... 37

5.2.1.1 Description du type dincident de scurit ................................................... 375.2.1.2 Mesures prventives possibles ..................................................................... 375.2.1.3 Moyens de dtection..................................................................................... 375.2.1.4 Qualification................................................................................................. 385.2.1.5 Analyse ......................................................................................................... 385.2.1.6 Traitement .................................................................................................... 38

5.2.1.7 Actions post-incident.................................................................................... 385.2.2 Installation dun logiciel non autoris .............................................................. 395.2.2.1 Dfinition de lincident ................................................................................ 395.2.2.2 Mesures prventives possibles ..................................................................... 395.2.2.3 Moyens de dtection..................................................................................... 395.2.2.4 Analyse ......................................................................................................... 395.2.2.5 Traitement .................................................................................................... 405.2.2.6 Actions post-incident.................................................................................... 40

5.2.3 Dysfonctionnement pouvant provenir dun logiciel malveillant...................... 415.2.3.1 Dfinition de lincident ................................................................................ 415.2.3.2 Mesures prventives possibles ..................................................................... 42

5.2.3.3 Moyens de dtection..................................................................................... 425.2.3.4 Qualification................................................................................................. 435.2.3.5 Analyse......................................................................................................... 435.2.3.6 Traitement .................................................................................................... 435.2.3.7 Actions post-incident.................................................................................... 43

5.2.4 Intrusions logiques ........................................................................................... 445.2.4.1 Description du type dincident de scurit ................................................... 445.2.4.2 Mesures prventives possibles ..................................................................... 445.2.4.3 Moyens de dtection..................................................................................... 455.2.4.4 Analyse......................................................................................................... 45

5.2.4.5 Traitement .................................................................................................... 465.2.4.6 Actions post-incident.................................................................................... 465.2.5 Usage inappropri des ressources informatiques ............................................. 47

5.2.5.1 Description du type dincident de scurit ................................................... 475.2.5.2 Mesures prventives possibles ..................................................................... 475.2.5.3 Dtection ...................................................................................................... 485.2.5.4 Analyse......................................................................................................... 485.2.5.5 Traitement .................................................................................................... 495.2.5.6 Actions post-incident.................................................................................... 49

5.2.6 Incidents concernant les habilitations............................................................... 505.2.6.1 Description du type dincident de scurit ................................................... 50

5.2.6.2 Mesures prventives possibles ..................................................................... 505.2.6.3 Dtection ...................................................................................................... 51


5/60

Gestion des incidents III CLUSIF 2011

5.2.6.4 Analyse ......................................................................................................... 515.2.6.5 Traitement .................................................................................................... 525.2.6.6 Actions post-incident.................................................................................... 52

5.2.7 Dni de service Messagerie par saturation du relais public de messagerie ...... 535.2.7.1 Description du type dincident de scurit ................................................... 53

5.2.7.2 Mesures prventives possibles ..................................................................... 535.2.7.3 Dtection ...................................................................................................... 545.2.7.4 Analyse ......................................................................................................... 555.2.7.5 Traitement .................................................................................................... 555.2.7.6 Actions post-incident.................................................................................... 55

5.2.8 Cas des incidents lis........................................................................................565.2.8.1 Description du type dincident de scurit ................................................... 565.2.8.2 Mesures prventives possibles ..................................................................... 565.2.8.3 Dtection ...................................................................................................... 565.2.8.4 Analyse ......................................................................................................... 57

5.2.8.5 Traitement .................................................................................................... 575.2.8.6 Actions post-incident.................................................................................... 576 - Glossaire (source principale : Wikipedia)............................................................... 58

Table des figures

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


6/60

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 PRIEURHP ENTERPRISE SERVICES

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


7/60

Gestion des incidents 9 / 60 CLUSIF 2011

1 - Introduction

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

Concernant les Systmes dInformation, il existe diffrentes dfinitions de la notiondincident :

pour le COBIT :Incident informatique : tout vnement qui ne fait pas partie du fonctionnement normaldun 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 dunservice et qui cause, ou peut causer, une interruption ou une diminution de la qualitde ce service.Problme : la cause inconnue dun incident significatif ou la collection de plusieursincidents 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 linformationindsirable(s) ou inattendu(s) prsentant une probabilit forte de compromettre lesoprations lies lactivit de lorganisme et de menacer la scurit de linformation[ISO/CEI TR 18044:20041].

Quelle que soit lapproche, la gestion des incidents a pour objectif la dtection et le traitementdes incidents ( priori et posteriori). Le processus de gestion des incidents inclut en gnralla 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 dunegestion efficace des incidents et des problmes. La gestion des incidents est galement undispositif amont essentiel du Plan de Reprise dActivit car elle dfinit les procduresdescalade qui permettent dtre plus ractif pour le dclenchement des plans de secours.

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


8/60


2 - Primtre du document

2.1.Objectifs du document

Ce document na pas pour ambition de couvrir tous les types dincident. Son objet est deconstituer un guide de mise en place dun systme de gestion des incidents de Scurit duSystme 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 scuritles plus courants.

Le document concerne donc principalement dans une organisation, les personnes encharge 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 peuventtre 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 delimpact 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).


9/60


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 unvnement, potentiel (au sens signes prcurseurs ) ou avr, indsirable et/ou inattendu,impactant ou prsentant une probabilit forte dimpacter la scurit de linformation dans sescritres de Disponibilit, d'Intgrit, de Confidentialit et/ou de Preuve.

Un incident SSI correspond une action malveillante dlibre, au non-respect dune rgle dela Politique de Scurit du Systme dInformation (PSSI) ou, dune manire gnrale, touteatteinte aux informations, toute augmentation des menaces sur la scurit des informations outoute 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 (pannedun serveur). Une atteinte la disponibilit pourra tre considre comme tant un incidentde scurit (dni de service suite intrusion) ou non (panne de serveur suite dfaillance duncomposant), aprs analyse des causes.


10/60


11/60


2. Il doit tre demand tous les salaris, contractants et utilisateurs tiers des systmes etservices dinformation de noter et de signaler toute faille de scurit observe ousouponne 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 lascurit de linformation,

le mcanisme de signalement doit tre le plus simple, le plus accessible et le plusdisponible possible. Il est recommand ces personnes de ne jamais tenter dapporterla preuve de failles de scurit souponnes.

3. Des responsabilits et des procdures doivent tre tablies, permettant de garantir unerponse 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 desvulnrabilits 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 delinformation,

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 delinformation 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 sontrvalues la fin de lincident,

lvaluation dincidents lis la scurit de linformation peut faire apparatre lancessit damliorer les mesures existantes ou den crer de nouvelles, afin de limiterla frquence des futurs incidents ainsi que les dommages et les cots associs, ou afindintgrer ces mesures dans le processus de rexamen de la politique de scurit. En cesens, une analyse froid des incidents ayant donn lieu une cellule de crise estralise lors des comits excutifs (afin didentifier les ventuelles actions prventives engager),

une revue des incidents ralise rgulirement permet notamment de quantifier etsurveiller les diffrents types dincidents lis la scurit de linformation ainsi queleur volume, les cots associs et leurs impacts sur les processus mtier.


12/60


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 delorganisme. La dfinition du primtre assurer fait en rgle gnrale l'objet d'uneanalyse de risques mene avec l'assureur. Il faut valuer le plus prcisment possible, lanature 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 surcotdexploitation 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, leslments de preuve doivent tre recueillis, conservs et prsents conformment auxdispositions 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 leuraccs,

seules les autorits judiciaires sont autorises collecter les preuves lgales.


13/60


3.4.Organisation

3.4.1 Prambule

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

En fonction de la taille de lentreprise ou de lorganisme cette quipe peut avoir uneorganisation trs diffrente :

modle centralis (CCSIRT) une quipe unique et centralise prenant en charge tousles incidents de lorganisation/entreprise. Ce modle est efficace pour les organisations

de taille limite ou les grandes organisations avec les moyens informatiques trscentraliss,

modle distribu (DCSIRT) plusieurs quipes disperses gographiquement enfonction de la localisation de centres dhbergement de ressources informatiques. Il estimportant, pour une meilleure efficacit et communication, que ces quipes soientmalgr tout administres par une autorit centrale pour garantir lapplication desprocdures homognes et un change efficace dinformations entre les quipes,

entit de coordination dans le cas du modle distribu fortement dispers ou dunecommunaut dorganisations indpendantes lquipe de coordination remplit les rlessuivants :

o coordinateur des actions des diffrents DCSIRT quand lincident a un impactsur 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 dutilisateursdInternet est le CERT/CC (Central Emergency Response Team / CoordinationCenter situ luniversit de Carnegie Mellon aux tats-Unis) ou le CERTA(Centre d'Expertise Gouvernemental de Rponse et de Traitement des Attaquesinformatiques) du gouvernement franais (liste non exhaustive).

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

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

Dans le cas le plus simple lquipe est constitue demploys de lentreprise ou delorganisme 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


14/60


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

loppos du modle prcdent il est possible dexternaliser entirement la gestion desincidents 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 leprestataire et les actions correctives et de restitution des services sont faites en collaborationavec les quipes de production (internes ou externes).

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

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

Enfin, les quipes oprationnelles, dans de nombreux cas, seront obliges de communiqueravec les dcideurs, ladministration et le support technique. Elles doivent donc disposer toutmoment 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'unestructure existe et qu'elle soit ddie la gestion d'incidents. Les sigles CERT (ComputerEmergency 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 techniquespour qualifier des vnements et intervenir sur un incident de scurit. Pour cela, cette quipedoit tre clairement identifie comme un point de passage oblig dans tout circuit denotification 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 donctre impliqu dans la dfinition des objectifs de l'quipe et tre bnficiaire de services offertspar l'quipe.


15/60


3.4.2.1 Fonctionnement

Une quipe de rponse aux incidents de scurit doit rpondre diffrents objectifs imposspar 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 (conformitrglementaire, 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

CSIRT1 2 3 4 5 6INTEXT

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


16/60


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

Pour tre contacte rapidement, l'quipe de rponse aux incidents doit bnficier d'une bonnevisibilit en interne comme en externe. Latteinte de cet objectif ncessite du temps et la miseen 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 detlphone.

Les comptences requises au sein de l'quipe de rponse aux incidents sont multiples etdpendent 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 oprationneldans lequel lincident sest produit et identifier rapidement des contre-mesurespouvant 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.


17/60


3.4.2.2 Services et primtre

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

services ractifs, services proactifs, services qualitatifs.

AlertesIncident

- Analyse- Traitement- Support- Coordination

Vulnrabilits- Analyse- Correction- Coordination

Outils dattaque- Analyse- Traitement- Coordination

Annonces

Veille technologique

Audits scurit

Administration decomposants 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 traitementd'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 pourraapporter une simple assistance tlphonique, fournir des modes opratoires ou assisterphysiquement les quipes oprationnelles lors de cet incident. L'quipe intervenant surl'incident aura sa charge la dtection, l'isolation et la remdiation de la menaceassocie l'incident. Un service sous intervention est prfrable mais demande descomptences multiples, des procdures rodes et de l'outillage,

service de gestion des vulnrabilits : ce service consiste centraliser les vulnrabilitssur le primtre de l'entreprise ou de lorganisme, les analyser et coordonner leurcorrection,

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


18/60


intgre aux procdures dalerte et de qualification du PCA. L'quipe de rponse auxincidents 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'unincident ou tout du moins d'anticiper son traitement. Les services suivants sont rattachs audomaine proactif :

annonces : diffusion d'informations permettant d'anticiper une menace (informationsconcernant les vulnrabilits ou ltat de la propagation d'une menace constate enexterne),

veille technologique : mise disposition d'une synthse sur les informations descurit essentielles sur une priode donne,

audits de scurit et tests d'intrusion : ces services permettent d'avoir une meilleurevisibilit du niveau du risque et de reprer les points de faiblesse de certains pans duSI,

administration de composants scurit : ce service permet dassurer ladministrationdes briques de linfrastructure scurit de faon garantir la matrise du traitement encas 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 anormauxprobablement caractristiques d'un incident de scurit.

Services qualitatifs

Le domaine qualitatif regroupe des services qui participent l'lvation du niveau de scuritpar des actions de fond. Ces services ne sont pas propres la gestion d'incident, mais unequipe de raction aux incidents peut souvent y apporter une forte valeur ajoute. Les servicessuivants sont rattachs ce domaine :

analyse de risques : une quipe de rponse aux incidents peut apporter une aideprcieuse pour identifier rapidement les menaces et leurs impacts sur un actif del'entreprise ou de lorganisme. Dans ce cas, une interaction doit tre cre entre lesquipes projets ou d'architecture en charge des analyses de risque et l'quipe deraction aux incidents,

PCA/PRA : une quipe de rponse aux incidents acquire rapidement de lexpriencesur les typologies dincidents rencontrs dans lentreprise ou lorganisme et sur lemode de traitement le plus adapt pour leur radication. L'quipe de rponse auxincidents pourra contribuer la gestion de crise selon la nature de lincident,

qualification des incidents de scurit : lquipe de rponse aux incidents de scuritcontribue llaboration de guides de qualification des incidents, notamment pourlquipe dassistance de premier niveau,

conseils : la bonne matrise des attaques et des contremesures confre l'quipe derponse aux incidents des connaissances qui pourront tre mises contributions pour


19/60


des missions de conseil. Tout du moins, il est important que l'quipe soit reconnue parles quipes projet pour solliciter son conseil sur des points prcis,

sensibilisation : les incidents rencontrs par l'quipe de rponse aux incidents luiprocurent une bonne visibilit des choses faire et viter. Cette connaissance peuttre 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 danslentreprise/organisme,

validation de produits : dans certains cas, il peut tre pertinent de disposer danslentreprise/organisme dune quipe mme de tester certains produits tiers pour lesestampiller comme respectueux des engagements de qualit attendus.

La liste des services n'est pas exhaustive et la mise en uvre devra tenir compte du contextede 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 delorganisation d'identifier tous les acteurs qui offrent ces services et d'tablir un contactdurable entre eux et lquipe de rponse aux incidents de scurit.

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


20/60


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 derponse aux incidents de scurit. Les autres volets du processus appartiennent soit auprocessus 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

RponseImmdiate

Investigations

Communication

ActivationCrise

Plan deGestion de

CriseTraitement

Crise

SituationCritique

Incident de scuritpotentiel

Qualificationconfirme

!

!

Source(humaine/technique)

Prise en compte(Help desk)

Equipe de rponse auxincidents de scurit

Cellule de crise

Autresincidents

Requalification

Figure 3 Schmatique du processus de gestion des incidents

Le signalement dun vnement susceptible dtre qualifi dincident de scurit est ralissoit par une personne (utilisateur, administrateur, etc.) ou par des moyens techniques (outilsde 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 enfaire 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 quipescomptentes pour leur traitement (support).


21/60


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

Les incidents qualifis de scurit font alors lobjet dun traitement spcifique dont lesparticularits sont dveloppes dans le chapitre suivant. Outre les investigationscomplmentaires, le traitement des incidents de scurit peut ncessiter des actionsspcifiques 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 estalerte et juge de lopportunit de passer en mode gestion de crise .


22/60


4 - Gestion des incidents de SSICe chapitre dtaille les tapes du processus de gestion des incidents prsent dune maniregnrale 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 dunepersonne),

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 decontrles.

Lanomalie doit pouvoir tre signale une personne comptente dans les plus brefs dlais. Lecontact habituel pour lutilisateur est le help desk. Cependant, il doit galement tre possiblede contacter directement un responsable de la scurit en toute discrtion si la situationlexige. 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, ycompris en dehors des heures ouvres, pour permettre une rponse adapte (empcher quelincident se poursuive, prserver les preuves, etc.).

Des mesures immdiates peuvent tre associes la dtection, soit sous forme de consignespour 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 diffrentespersonnes, en gnral le help desk, selon des procdures devant tre connues de tous. Danstous 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 ilest catgoris. Lenregistrement de lvnement doit comporter minima la date et lheure delalerte, son origine (personne ou dispositif technique), les coordonnes du dclarant, unedescription aussi prcise que possible de lvnement et sa catgorisation. Comme pour toutincident, un numro de dossier est gnr et communiqu si ncessaire au dclarant. La

personne qui enregistre lvnement doit galement mentionner laction immdiate


23/60


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

Lenregistrement de lvnement est essentiel plusieurs titres. Il permet de garder une tracede 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 cadredanalyses de risques, pour valuer lefficacit des dispositifs en place ou pour identifier desincidents 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 peuttre habilite pour prendre des mesures ou transmettre lincident lquipe de gestion desincidents de scurit.

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

Pour les incidents identifis, ces consignes indiquent le mode opratoire du traitement de cesincidents pour les quipes de support. Dans les autres cas, cest lquipe de rponse auxincidents 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 doriginemalveillante ou concernant certains quipements ou logiciels ou encore signal par certainsdispositifs 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 ouinfirme 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 investigationscomplmentaires pour qualifier lvnement. Les critres dvaluation dimpact prenant encompte diffrents axes danalyse (impacts financiers, impacts sur limage, impacts sur lesclients ou partenaires, risques de poursuite judiciaire, etc.) doivent tre prtablis et mis ladisposition 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 dssollicitation de lquipe.


24/60


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 etprserver les traces. En effet, mme sans connatre prcisment la nature de lincident, sonorigine ou son impact rel qui seront lobjet de la phase danalyse, le simple fait didentifier letype de danger peut dclencher des actions palliatives, comme par exemple :

un confinement (ex : dbranchement du rseau dun poste infect pour le mettre dansun 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 delquipe scurit.Si ces mesures savrent insuffisantes ou/et si la situation nest pas maitrise ou/et si le niveaudimpact de lincident le justifie, au regard des critres dvaluation, la cellule de crise doittre 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 lesconclusions de linvestigation peuvent conduire lactivation de la cellule de crise.

4.3.2.1 Prservation des tracesCertaines prcautions doivent tre prises. En particulier, en cas de piratage (par exemple), si lebut de lanalyse est de remonter la source de la manipulation frauduleuse et de prendre desmesures 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 destraces qui se confondent ensuite avec les traces laisses par lagresseur), voire effacer, lestraces du passage dun attaquant. De fait, il est ncessaire de sauvegarder (par exemple viaune copie intgrale, de type bit bit) les informations avant d'entreprendre toute actionsusceptible 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 moinsconserver une copie des logs (journaux de connexions au systme). Toutefois, cettesauvegarde nest pas toujours simple mettre en uvre et peut ncessiter des outils et/ou des

comptences particulires.


25/60


Enfin, les donnes ainsi sauvegardes doivent tre protges physiquement et un cadreopratoire doit tre mis en uvre qui prcisera notamment par qui ces sauvegardes ont teffectues, quel moment, comment elles ont t protges et qui y a eu accs. En fonctiondes 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 preuvesen cas de poursuites judiciaires.

4.3.2.2 Environnements potentiellement concernsDurant 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 lanalyseDans chaque environnement technique il existe des outils qui peuvent aider dterminerl'tendue de l'attaque mene.

Des procdures peuvent galement tre mises en uvre, intgrant des check-lists quipermettent de raliser lanalyse dans les meilleures conditions. Par exemple, on peutpositionner 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 descomptes 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 contiennentpas de membres non autoriss, etc.

4.3.2.4 Identification du fait gnrateur et analyse de limpactLobjet principal de lanalyse de lincident proprement dit permet de rpondre plusieursquestions qui se posent, comme par exemple :

quelle est la vulnrabilit ou la faiblesse qui a rendu possible lincident ? Cest laquestion la plus importante ! En effet, si aucune rponse claire nest trouve cettequestion, le systme restera vulnrable une fois remis en service ; il pourrait treattaqu nouveau,


26/60


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

4.3.3 Traitement

4.3.3.1 Mesures pour viter laggravation des consquencesEn complment des mesures de rponses immdiates dj prises ds la qualification delincident, des mesures peuvent tre prises pour viter laggravation des consquences.

Disposant ce stade des informations obtenues lors des investigations, ces mesures serontplus cibles que les rponses conservatoires durgence :

activation de la Cellule de Crise : selle na pas t active lors de la phase de rponseimmdiate, la gestion de crise du PCA peut tre dclenche ce stade, si la situationsest dgrade entre temps et limpose,

restrictions temporaires daccs aux rseaux ou/et aux applications : ces restrictionspeuvent 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 trsrapidement la dure de la perturbation (exemple : valuer la dure de restauration parrapport au volume de donnes restaurer en cas de pertes de donnes). On identifietrois 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 peututiliser si besoin la communication de crise prvue dans le cadre du PCA.

4.3.3.2 Dclarations aux assurancesProcder 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 parhuissier et faire mettre toutes les preuves sous scells.


27/60


4.3.3.3 Rsolution de lincidentSans 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 quiinterviendront distance ou sur site et quil faut rserver en priorit en raison des dlaisdintervention.

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 bienordonnancer les tapes.

Dtermination du point zro de lincidentLes 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 mesurescorrectives et de rduire le risque de reproduction.

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

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


28/60


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 outilssystmes bases de prfrence sur un OS diffrent de celui qui est install etpouvant 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 estindispensable pour communiquer ou sinformer.

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

4.3.3.5 Exemples de traitementsQuelques 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.


29/60


4.4.Revues post-incident

4.4.1 Investigation post-incidentUne fois lincident matris, il est possible quil soit ncessaire de lancer des investigationscomplmentaires 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 ledossier de synthse.

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

4.4.2 Rapport de synthseChaque incident de scurit doit tre accompagn dun dossier de suivi et si possible dunrapport de synthse. Ce rapport doit tre rdig par lquipe en charge de la rsolution delincident. 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 afindviter que le temps nefface dans la mmoire des acteurs des lments ou des dtailsimportants pour la comprhension et lanalyse de lincident.

Le rapport doit prioritairement prsenter des conclusions claires comprhensibles par lesresponsables.


30/60


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

4.4.3 Analyse post-incidentLanalyse post-incident sinscrit dans une dmarche damlioration continue et de qualitPDCA permettant de prendre connaissance des lments qui doivent voluer dans le SystmedInformation.

Cette analyse post-incident doit impliquer les responsables pour que les engagements soientpris rapidement en matire dvolution du Systme dInformation. Celle-ci peut prendre laforme dun comit de pilotage ou tout autre type de runion impliquant les dcideursadquats.

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

4.5.Actions post-incident

4.5.1 Bilan de lincident

Les informations et les mesures dtermines lors du traitement de lincident doivent treconserves et permettre denrichir la base de connaissances.

Dans le traitement d'un incident majeur, il est important danalyser avec recul, ce qui a bienfonctionn 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 pnalrelatifs au piratage informatique) et les pirates sont passibles de sanctions parfoisconsquentes. C'est pourquoi, il ne faut pas hsiter lutiliser si vous tes victime dunetentative 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,


31/60


une liste, la plus complte possible, de tous les prjudices subis (dommages, prjudicefinancier, perte de temps pour vrification de l'intgrit du site ou des donnes, pertede crdibilit auprs des internautes ou des clients de l'entreprise, etc.),

les lments de preuve constitus lors de lanalyse de lincident (pour que ces lmentsaient 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 quec'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 desfournisseurs.

4.5.4 Communication interne spcifique (sensibilisation, etc.)

Les incidents rencontrs par l'quipe de rponse aux incidents lui procurent une bonnevisibilit des choses faire et viter. Cette connaissance peut tre mise contribution pourdes 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 impactfort 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 monitoringo analyse :

problmatique de prservation des preuves, classification, lapprciation des risques,

o actions : correction (ex : rtablissement dun service),


32/60


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.


33/60


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

Dans ce thme, on retrouve les points suivants : mesures organisationnelles, mesures techniques.

5.1.3 Moyens de dtectionDans ce thme, on retrouve les points suivants :

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


34/60


5.1.4 Qualification

Dans ce thme, on retrouve les points suivants : 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

Dans ce thme, on retrouve les points suivants : 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

Dans ce thme, on retrouve les points suivants : 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

Dans ce thme, on retrouve les points suivants : recours juridique, assurance, communication spcifique (sensibilisation, etc.), audit, recommandations, rexamen de lapprciation des risques.


35/60


5.2.Fiches par type dincident

5.2.1 Vol de PC portable

5.2.1.1 Description du type dincident de scuritDclaration de vol de portable par un utilisateur.Exemples : Vol de portable dans les locaux de lentreprise/organisme, vol de portable dans lestransports 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 desconsignes,

type de propagation : immdiat pour le matriel, progressif possible pour le contenu.

5.2.1.2 Mesures prventives possiblesMesures 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 dtectionManifestation de lincident : dclaration de vol.Mesures organisationnelles de dtection spcifiques : dcouverte lors dun contrledinventaire.Outils de dtection disponibles : vidosurveillance, portique de dtection (RFID).Type dalerte (qui alerte : lutilisateur concern ; qui alerter : selon organisation).


36/60


5.2.1.4 QualificationLe niveau de gravit dincident dpend de la fonction du dtenteur, de lusage du portable, dulieu du vol, etc.

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

5.2.1.5 AnalysePrcautions ncessaires (prservation de preuve) : prserver les enregistrements devidosurveillance, les logs de contrle daccs.Mesures immdiates (information, dclaration, anticipation du traitement, etc.) : dpt deplainte 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 potentielou situation de lutilisateur.

5.2.1.6 TraitementMesures 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 prventivesde scurit ont t prises.

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


37/60


5.2.2 Installation dun logiciel non autoris

5.2.2.1 Dfinition de lincidentToute tentative dinstallation de logiciel non autoris, volontaire ou non, doit tre considrecomme 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 moyensadapts au niveau de gravit des menaces, des responsabilits pour une dtection duncode 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 programmesautoriss tre excuts).

5.2.2.3 Moyens de dtectionGestion du parc.

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

5.2.2.4 AnalyseDterminer le type de logiciel install et escalader vers diffrentes quipes en fonction de ladangerosit du code.Vrifier les droits correspondant au profil dutilisateur.


38/60


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

5.2.2.6 Actions post-incidentRevoir les besoins dutilisateur et ventuellement adapter les profils dutilisation.Revrifier les failles de scurit.Sensibilisation adapte la situation de personnel.


39/60


5.2.3 Dysfonctionnement pouvant provenir dun logiciel malveillant

5.2.3.1 Dfinition de lincidentConstat dun comportement anormal ou inhabituel dun systme ou dune applicationsusceptible 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'unprogramme hte, contrairement aux virus,

les backdoors ou portes drobes permettent le contrle distance d'un PC par unpirate. Un ordinateur infect et contrl distance par un pirate est appel BOT ouzombie. Un rseau de PC infects est un botnet.

les rootkits permettent un pirate de maintenir dans le temps un accs frauduleux unsystme. Un rootkit s'utilise aprs une intrusion et l'installation d'une porte drobe. Ila pour but la furtivit en cachant par exemple certains processus, certains fichiers etclefs 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 del'utilisateur. Cela peut aller de linstallation d'autres malwares, la dsactivation decertains logiciels de protections (antivirus, pare-feu, etc.), en passant par lenvoi demessages de SPAM ou bien d'autres fonctionnalits,

les spywares ou logiciels espion, mouchards ou espiogiciels sont conus pourdrober/collecter des informations/donnes, sans que l'utilisateur en ait connaissance,

les keyloggers ou enregistreurs de frappe sont des logiciels ou matriels espion quienregistrent les touches frappes sur le clavier et les transmettent via les rseaux, afinde drober des mots de passe ou autres informations susceptibles d'tre recueillies parun 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 protectionet prvention,


40/60


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 durseau est ralise.

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

5.2.3.2 Mesures prventives possiblesMesures organisationnelles

mise en uvre dune politique antivirale : identification des besoins, des moyensadapts aux niveaux de gravit des menaces, des responsabilits pour une dtectiondun 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 codemalveillant, pour assurer une ractivit maximale,

mise ne place dun contrle du bon fonctionnement des moyens : Mise jourautomatique 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.

5.2.3.3 Moyens de dtectionPar lutilisateur.Par analyse de lactivit (tableaux de bord).Par des outils danalyse de comportement (IDS, IPS, SIEM2, etc.).

2Security Information and Event Management


41/60


5.2.3.4 QualificationDans le processus de qualification il faut prendre en compte : le primtre potentiellementconcern, le comportement du malware, le recoupement rapide avec dautres incidents oualertes rcentes du mme type, etc.Mesures durgence. Exemples : confiner les machines infectes, couper certains accs rseau,

communication de recommandations cibles.

5.2.3.5 AnalysePrcautions ncessaires pour la prservation de preuves : par exemple, sous Windows, copierle malware sur une cl USB pralablement vaccine (avec fichier autorun sain et nonsupprimable), 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 simpledsinfection 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 leRPCA.

5.2.3.6 TraitementRenforcement 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 dessystmes sains dans le rseau.

5.2.3.7 Actions post-incidentAnalyse de ce qui a bien march et de ce qui na pas fonctionn, recommandations pouramliorer 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.


42/60


5.2.4 Intrusions logiques

5.2.4.1 Description du type dincident de scuritDfinition de lincidentIntrusion 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 desinformations auxquelles elle naurait pas accs en temps normal ou 2] de modifier, dtruire entout 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, desressources physiques ou logiques, certaines personnes dsignes. L'intrusion est constateds le franchissement de la limite entre l'extrieur et l'intrieur mme si cette limiten'est que symbolique.

Cadre juridique :Les intrusions logiques sont soumises (entre autres) la loi du 5 janvier 1988, relative a lafraude 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 vuede rcuprer des informations confidentielles, de dtruire ou daltrer desinformations, 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,


43/60


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

Mesures techniques : 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.

5.2.4.3 Moyens de dtectionManifestation 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, alertevolontaire dans le cas dun accs accidentel),

qui alerter : selon le niveau de lintrusion :o interne : RSSI, DSI, Direction Mtier, DG, ladministrateur du systme

dhabilitations concerno externe : police, gendarmerie.

5.2.4.4 AnalysePrcautions ncessaires (prservation de preuve) : logs.

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

Environnements potentiellement concerns : systmes, applications

Documents

CLUSIF 2011 Gestion Des Incidents