sécurité informatique

S O M M A I R E
• Éditorial par J. Illand
• Chronique d’un incident
ordinaire en laboratoire
par É. Blanc
• Incidents informatiques :
l’exploitation des données par
le CERT RENATER par F. Ducrot
• Illustrations des missions
du CERTA : rootkits et IPv6
par P. Mercier et F. Pouget
• Les exercices de crise SSI
par I. Morel
S É C U R I T É I N F O R M AT I Q U E
numéro 57
octobre 2006
S É C U R I T É
D E S
éd i t o r i a l
S
S Y S T È M E
D
’
T I O N
I N F O R M A
Chronique d’un incident
ordinaire en laboratoire
Septembre au balcon,
pirates au charbon…
par Éric Blanc
Cruelle coïncidence! Alors que se préparait le présent bulletin consacré à
la gestion des incidents informatiques, le CNRS enregistrait en septembre
un record d’incidents (intrusions, compromissions de serveurs, détournements de messagerie, défiguration de sites Web, vols de portables…).
Effervescence de hackers en mal de reprise d’activité après la plage, ou
vigilance accrue des informaticiens, ou encore meilleure remontée des
déclarations d’incidents? Cela justifie d’autant plus le coup de projecteur du présent bulletin sur les incidents informatiques.
Le témoignage d’un responsable informatique de terrain (Éric Blanc)
plante le décor, mettant l’accent sur le «désarroi» du responsable de
terrain face à la question du «que faire?».
L’activité des CERTs (CERT RENATER et CERTA) est rappelée et illustrée par
l’article de François Ducrot (RENATER) et par celui de Pascal Mercier et
de Fabien Pouget du CERTA (SDGN/DCSSI).
Une maîtrise des «incidents ordinaires» s’avère une excellente mise en
jambe pour l’affrontement de situations plus graves. L’anticipation de
telles situations de crise fait l’objet de plans nationaux et d’exercices de
crise présentés ici par Isabelle Morel.
Organisation, information, vigilance et anticipation, voilà quelques mots
clés qui devraient encourager les hackers à retourner à la plage.
Joseph Illand
Fonctionnaire de Sécurité de Défense
Administrateur systèmes et réseaux à l’UMR6098
Architecture et fonction des macromolécules biologiques
Le 13 avril dernier, le responsable de l’université de
Luminy, destinataire des messages adressés à
« abuse », reçoit une plainte d’un utilisateur étranger,
spammé par une des machines du domaine. Il transfère cet avis au secteur concerné, en l’occurrence
notre unité de recherche.
Ce spam n’émane pas de notre domaine, mais le message en question s’avère un cas typique d’« hameçonnage ». Le mail invite l’internaute à renouveler ses
coordonnées sous peine de désactivation de son
compte. Le tout est, bien sûr, empreint d’urgence ;
des messages ont déjà été envoyés, celui-ci est l’ultime appel… Bref, il faut se connecter immédiatement
à un serveur Web. Le lien affiché pointe sur un nom
DNS /alias/ vers l’adresse IP de mon serveur de mail.
Lorsque l’on clique sur ce lien, la fenêtre de connexion
de mon portail webmail sous « Horde » apparaît.
J’avais déjà pu constater un ralentissement de la
machine durant la semaine et j’avais donc commencé
la vérification de la machine. Tout était correct, il ne
restait plus qu’à patcher « Horde », justement
« Horde » dont le serveur de distribution se trouvait
surchargé… coïncidence problématique ! J’ai donc
éteint et débranché la machine et installé en urgence
un service de secours, sans webmail, rapidement.
* Avec l’aimable autorisation de Maya Sitruk, rédactrice de l’article «Noël aux tisons,
pirates au charbon», SI n° 49.
La cryptologie de nouveau à l’honneur :
le mathématicien Jacques STERN,
médaille d’or 2006 du CNRS
La médaille d’or 2006 du CNRS a été décernée au mathématicien Jacques
STERN, professeur, directeur du Laboratoire d’Informatique de l’École Normale
Supérieure (ENS), chercheur mondialement connu pour ses travaux en cryptologie.
Jacques STERN avait récemment apporté sa contribution à Sécurité Informatique
(n° 55) en présentant les perspectives de la recherche en cryptologie.
Cette science est encore une fois à l’honneur, puisque la médaille d’or du CNRS
avait été attribuée, en 2005, au physicien Alain ASPECT pour des recherches touchant notamment à la cryptographie quantique.
Pour en savoir plus :
http://www2.cnrs.fr/sites/communique/fichier/dp_medaille_d_or_2006.
L’UREC contactée m’a renvoyé sur le CERT RENATER qui m’a
confirmé, par l’analyse des logs que je lui ai fournis, une intrusion via la faille déjà identifiée sur d’autres machines de la
communauté RENATER. Un avis de sécurité avait effectivement été émis par le CERT, mais je n’avais pas encore eu le
temps de mettre à jour le logiciel. En application de la procédure UREC « Que faire en cas d’incident ? », j’ai rempli et
transmis la fiche d’incident à l’UREC pour communication au
CERT RENATER.
Que faire ensuite ?
La question doit être posée : la machine a été piratée, il y a
eu « intrusion dans un système d’information ». Un dépôt de
plainte s’impose sans doute. Mais il ne sert à rien d’encomsuite page 2
brer les piles de dossiers de la police. Et puis,
sécurité informatique
octobre 2006 - n° 57
suite de la page 1
comment caractériser et évaluer le préjudice ?
Bien sûr, on peut déjà se poser quelques
questions basiques:
• Les données sensibles du laboratoire
ont-elles été compromises ?
• Un compte utilisateur a-t-il été compromis ?
• Des messages privés ont-ils été lus, ou
interceptés ?
• La machine a-t-elle été utilisée pour
pirater un autre système ?
• La machine a-t-elle servi de rebond
pour atteindre d’autres systèmes ?
• L’image du CNRS peut elle pâtir de cet
incident ?
S’agissant d’un problème pouvant
« nous » impliquer vis-à-vis de l’extérieur, il
paraissait important, pour au moins
dégager notre responsabilité dans cette
attaque d’hameçonnage, de déposer
une plainte.
Le principe étant donc retenu, deux
autres questions ont surgi immédiatement :
• Qui doit porter plainte ? (qui a autorité
pour porter plainte ?)
• Auprès de qui ?
Commentaires de Joseph Illand, Fonctionnaire
de Sécurité de Défense (CNRS)
Ce n’est pas tant l’aspect technique qui a posé problème que l’aspect juridique.
Les mesures techniques à prendre, le plus souvent dans l’urgence, sont définies
par les consignes nationales (UREC, CERT). Dans le doute, les experts de l’UREC
peuvent être sollicités.
En revanche, l’administrateur systèmes et réseaux se sent un peu désarmé pour
mesurer certains impacts touchant la protection du patrimoine scientifique, pour
apprécier la chaîne de responsabilités, pour mesurer ce qu’il peut ou non « révéler » à son directeur, pour apprécier l’opportunité de porter plainte, pour identifier
qui doit porter plainte et auprès de qui.
Face à ces incertitudes et à défaut de consignes nationales explicites, on ne peut
que conseiller de s’adresser à la voie fonctionnelle SSI dont relève l’unité (CNRS
ou université en l’occurrence), mais pour autant qu’un arbitrage entre tutelles ait
déterminé préalablement l’entité « pilote » en matière de SSI.
Par ailleurs, dès que l’incident revêt une composante sensible (atteinte au patrimoine scientifique et technique) et/ou juridique (opportunité de plainte, mise en
cause de personnes…), le service du FSD doit être impérativement contacté.
En complément des conseils techniques déjà disponibles et touchant en particulier aux mesures conservatoires d’urgence, il est clair qu’une meilleure information
des responsables informatiques de terrain sur la gestion des incidents est indispensable.
Dans ce sens des consignes viennent très récemment d’être mises en ligne sur le
site du FSD du CNRS (http://www.sg.cnrs.fr/FSD/securite-systemes/que-faire1.htm)
Elles devraient permettre, autant que faire se peut, de lever quelques incertitudes
sur la manière d’appréhender les situations d’incident.
La politique de sécurité des systèmes d’information, en cours d’approbation au
CNRS, fournira très bientôt un cadre organisationnel et de responsabilités servant
de référence.
La publication, prochaine également, de la nouvelle charte des utilisateurs de l’informatique va contribuer à compléter le dispositif.
La clarification des responsabilités en matière SSI entre des tutelles d’unités mixtes
(en particulier entre le CNRS et les universités) est une démarche indispensable.
Elle doit permettre l’identification de la chaîne fonctionnelle SSI à laquelle se rattache prioritairement l’unité.
Mais toutes ces directives nationales ne peuvent avoir leur effet qu’au travers de
la PSSI d’unité permettant de décliner et d’adapter au niveau d’unité les
consignes nationales et de préciser les chaînes locales de responsabilité, en liaison avec la chaîne fonctionnelle SSI de l’unité. ■
[email protected]
Et, en toile de fond, subsistait cette question angoissante : notre responsabilité
était-elle engagée ? (la mienne en tant
que responsable informatique, celle du
directeur, celle du CNRS en tant que personne morale ou encore celle de l’université).
Pour ce qui est de la détermination de
l’autorité devant porter plainte, la question n’apparaissait pas simple, du fait, en
particulier, de la nature mixte du laboratoire, à la fois sous tutelle universitaire et
sous tutelle CNRS.
Le serveur de mail compromis est une
machine connectée sur le réseau informatique de l’université de la Méditerranée. Mais il est administré par des
agents de statut CNRS.
Dans mon esprit, l’autorité devant porter
plainte était à rechercher auprès de l’administrateur systèmes et réseaux, du
directeur de l’unité, du délégué régional
du CNRS, du fonctionnaire de sécurité de
défense du CNRS (FSD), du responsable
réseau du campus, du responsable
réseau de l’université ou du doyen de
l’université…
Après avoir sollicité l’avis de plusieurs services, la réponse n’apparaissait pas évidente. Le FSD du CNRS me suggère soit
un dépôt de plainte, par lui-même,
auprès de l’OCLCTIC, soit un dépôt de
plainte au niveau local auprès du SRPJ.
Auquel cas ce pourrait être le directeur ?
Encore faudrait-il que le plaignant ait les
compétences techniques suffisantes
pour décrire l’objet de la plainte.
Restait aussi la détermination du service
de police auprès duquel la plainte
devait être déposée.
L’OCLCTIC consulté me renvoie sur le
SRPJ de Marseille, section économique
et financière.
Finalement, la plainte a été déposée
auprès de ce service, par le directeur du
laboratoire. Elle l’a été au nom du laboratoire, puisque c’est la seule entité à
laquelle le directeur puisse se référer en
n’arbitrant pas entre CNRS et université.
Elle l’a été sans garantie certaine que le
directeur était bien habilité à déposer
plainte. Dans cette affaire, j’ai eu la
chance de n’avoir pas eu de compromission de données personnelles. Si tel
avait été le cas, du fait de mon astreinte
au secret professionnel, aurais-je pu transmettre (« divulguer ») auprès de mon
directeur toutes les données nécessaires
au dépôt de plainte ? Autre question ! ■
É[email protected]
2
sécurité informatique
octobre 2006 - n° 57
Incidents informatiques : l’exploitation
des données par le CERT RENATER
Par François Ducrot (CERT RENATER)
Lorsqu’un incident lié à un problème de sécurité informatique lui est signalé, le
CERT RENATER recommande au RSSI concerné de collecter un grand nombre
d’informations permettant le traitement de l’incident. Ces remontées de données comprennent en particulier les fichiers de journalisation du système incriminé dans lesquels les activités de l’intrus pourraient avoir été enregistrées: description du système, services actifs, fichiers recensant les requêtes envoyées à
un serveur, fichiers recensant les tentatives de connexion sur un système, historiques des commandes passées par un utilisateur, résultats d’analyse antivirale, programmes récupérés sur les systèmes, rejets d’ACLs de routeurs, etc.
Le RSSI est à juste titre en droit de s’interroger sur l’utilité de faire remonter ces informations et sur l’utilisation qui en est faite
par le CERT RENATER.
Pour un utilisateur en effet, la collecte des
informations relatives à un incident de
sécurité peut sembler une activité limitée,
voire peu utile. D’ailleurs, s’il y a dépôt de
plainte, l’analyse devra être effectuée via
la police, et, dans le cas inverse, pourquoi
attendre avant de remonter la machine?
Une réponse à cette observation est déjà
que l’analyse permet de savoir quelle partie du système a été attaquée et ainsi
d’éviter la reproduction de l’attaque.
Pour le CERT RENATER, l’un des tout premiers usages est d’utiliser certaines de ces
données pour alimenter en partie le
contenu du bulletin de statistiques hebdomadaires qu’il envoie à ses correspondants chaque vendredi. La fonction de ce
bulletin est de rendre compte au plus près
des problèmes d’actualité. Toutefois, celuici ne représente que l’usage le plus visible
de cette source précieuse d’informations.
Les données issues des incidents sont utilisées de plusieurs manières, profitables tout
à la fois pour l’utilisateur qui les a envoyées
et pour les autres experts, RSSI et utilisateurs
du réseau et bien sûr à notre niveau.
Grâce aux données qui lui sont remontées,
le CERT RENATER peut connaître le type
d’attaques à la mode et savoir si elles visent
plus particulièrement la communauté
RENATER ou non. Les avantages, bien
qu’instructifs, sont néanmoins faibles pour
celui ou celle qui a diagnostiqué l’attaque,
mais cela va grandement faciliter l’analyse
pour d’autres personnes qui vont rencontrer un jour un problème similaire et vont
donc pouvoir bénéficier de l’expérience
acquise lors des précédents traitements.
L’une des fonctions du CERT RENATER est
d’agir en tant que coordinateur lors des
incidents de sécurité informatique. De ce
fait, il est à même de voir de nombreux cas
d’attaques.
Tout se joue dans les premiers moments de
l’attaque, la première analyse qui en est
faite sera utile pour reconnaître rapidement
les suivantes et rendre le diagnostic plus
rapide,précis et éventuellement salutaire.
Les informations recueillies par le
CERT RENATER pourront être utilisées au
profit de l’ensemble de la communauté
des utilisateurs de RENATER.
Prenons le cas d’un RSSI qui, après expertise, détecte un programme ayant servi à
exploiter une vulnérabilité. S’il nous
remonte l’information, l’analyse de ce programme nous permettra de connaître la
vulnérabilité associée. C’est précisément
ce qu’il s’est passé cette année dans la
découverte de certaines failles dans des
applications développées en langage
PHP (phpbb, claroline, mambo ou autres,
pour ne citer qu’eux). Après la découverte
d’un serveur attaqué, le CERT RENATER a
pu orienter l’analyse et ainsi vérifier quelle
faille, connue ou non, était en cours d’exploitation.
Un autre aspect de l’activité du CERT
RENATER est la veille technologique. Cette
activité, associée aux informations fournies
par les correspondants, permet la découverte de cibles potentielles d’attaques qui
n’avaient pas été identifiées jusque-là.
Cela peut être illustré par exemple par le
problème relatif aux vulnérabilités des serveurs Web. L’analyse de plusieurs incidents
a permis de recenser et de mieux
connaître les requêtes apparaissant dans
les fichiers de journalisation lors d’une
compromission réussie. Le fait de pouvoir
récupérer les fichiers déposés par le pirate
permet de comprendre quel usage il peut
tirer d’une machine compromise par cette
méthode (phishing, défiguration de site
3
web, propagation de virus…) Ces informations ont, en particulier, conduit à découvrir
l’emploi par des pirates de nombreux
scripts de type « reverse backdoor » permettant de contrôler la machine victime à
distance ou de l’utiliser pour lancer de
nouvelles attaques par rebonds.
De façon plus générale, les informations
acquises lors d’une compromission, si elles
sont conservées uniquement au niveau du
site concerné, n’apporteront aucune aide
aux autres membres de la communauté.A
ce titre, le CERT RENATER peut être vu
comme le dépositaire d’expérience et du
travail des experts de notre communauté.
Chaque incident analysé permettant
d’enrichir les connaissances et d’améliorer
l’analyse des suivants.
Enfin, le CERT RENATER est en position d’exploiter les informations recueillies lors d’une
compromission afin de prévenir les personnes dont les machines sont impactées,
tant en indiquant au RSSI du site initial des
éléments qui ont pu lui échapper qu’en
avertissant ceux d’autres sites éventuellement impliqués.
Son rôle de guichet unique pour la communauté des sites RENATER lui permet de
faciliter et de coordonner les échanges
tant entre sites français qu’étrangers. De
par sa présence internationale (dans les
groupes FIRST & TF-CSIRT), le CERT RENATER
est connu de ses homologues étrangers.
Cela permet d’échanger facilement des
informations entre personnes de confiance
et de bénéficier de l’expertise d’ingénieurs
sécurité du monde entier. Grâce à ces
contacts, le CERT RENATER est à même de
tirer le meilleur parti des éléments collectés
sur les réseaux lors de l’analyse d’une compromission. Au niveau européen, le projet
GN2 comprend un groupe d’échange
visant à faciliter l’échange d’informations
entre les différentes équipes.
Il convient donc de rappeler que le rôle du
CERT RENATER n’est pas simplement d’enregistrer les incidents qui lui sont signalés,
mais aussi d’en tirer le meilleur parti pour
l’ensemble de sa communauté. Chaque
incident accroît l’expérience de l’équipe,
facilitant ainsi l’étude du suivant et permettant de focaliser le suivi sur les aspects les
plus sensibles de l’actualité de la sécurité.■
[email protected]
sécurité informatique
octobre 2006 - n° 57
Illustrations des missions du CERTA: rootkits et IPv6
par Pascal Mercier et Fabien Pouget du CERTA (SGDN/DCSSI)
Au sein du Secrétariat Général de la Défense Nationale (SGDN) et, plus précisément, de sa Direction Centrale de la Sécurité des Systèmes d’information
(DCSSI1), un Centre opérationnel, le COSSI, assure une veille permanente dans
le domaine de la sécurité des systèmes d’information. Il est composé de
deux entités, le CEVECS, centre de veille, de conduite et de synthèse, qui
assure une surveillance 24 heures sur 24 et se tient prêt à conduire l’action
et à assurer l’information des hautes autorités en cas de crise, et le CERTA,
Centre d’Expertise gouvernemental de Réponse et de Traitement des
Attaques informatiques, qui constitue son pôle d’expertise technique.
Le CERTA participe activement au réseau
mondial des CSIRTs (Computer Security
Incident Response Teams) et développe
des outils et des méthodes afin de parvenir
à traiter tout type d’incidents. Ses trois principaux objectifs sont d’assurer:
1) l’identification des vulnérabilités;
2) la résolution des incidents concernant la
sécurité des systèmes d’information;
3) l’aide à la mise en place de moyens
permettant de se prémunir contre de
futurs incidents.
Deux exemples concrets récents, présentés
dans les paragraphes suivants,illustrent l’activité quotidienne du CERTA dans le cadre
de ces objectifs. L’un concerne les outils
appelés rootkits,l’autre le protocole IPv6.
Les rootkits
Alors que les systèmes d’exploitation se
complexifient toujours davantage et
empilent les technologies, on peut observer que les attaquants maîtrisent de
mieux en mieux l’accès au cœur des différents environnements. De ce fait, les
attaques ciblent les couches les plus
basses des systèmes. Dans le cadre de sa
mission de veille, le CERTA a vu croître l’utilisation de rootkits («outils de dissimulation
d’activité »). L’utilisation de ces logiciels
malveillants, installés dans les couches
basses du système afin de cacher une
activité illicite sur une machine victime, ne
se cantonne plus aux seuls systèmes UNIX,
mais s’applique progressivement aux systèmes Microsoft Windows.
Le premier cas de rootkit sur Windows
découvert à l’occasion d’un traitement
d’incident par le CERTA, il y a un peu
moins d’un an, est un cas pédagogique.
Un administrateur réseau s’est étonné de
la brusque apparition d’un flux TCP/IP à
destination d’un port jusqu’alors peu uti-
lisé. Ayant identifié la machine Windows
impliquée par ce flux, il lui a été cependant impossible de cerner la source du
problème.
L’analyse a mis en évidence qu’un rootkit avait été installé. Ce rootkit permettait
à l’attaquant de cacher un serveur
d’échange de fichiers illicites (FTP), en
falsifiant toutes les parties du système
d’exploitation qui auraient permis de
mettre en évidence la compromission :
• les fichiers dont le nom portait un certain préfixe ;
• les processus lancés par le serveur FTP
et par le rootkit ;
• les pilotes (ce rootkit s’installait comme
un pilote) ;
• les services ouverts, à savoir un service
d’administration à distance, certaines
clefs et valeurs de la base de registres ;
• l’affichage de l’espace disque.
Dans ces conditions, il était impossible de
découvrir la compromission en analysant
la machine sans utiliser une méthodologie particulière et des outils spécialement conçus.
Le CERTA disposant de tels outils (analyse
bas niveau des disques, analyse bas
niveau du système, etc.), l’analyse a permis de déceler la faille ayant conduit à la
compromission. Par ailleurs, il a été développé des outils supplémentaires afin
d’aider les administrations qui seraient
victimes du même type de codes malveillants. Depuis, de nombreux cas similaires ont pu être recensés. C’est pourquoi il convient d’être le plus rigoureux
possible dans l’analyse régulière et la
gestion des différents indicateurs des systèmes d’information (journaux d’événements des équipements périphériques, filtrage adéquat, maîtrise des services
proposés, etc.) : l’absence d’information
explicite sur le système ne signifie pas
qu’il n’est pas pour autant compromis.
4
Le protocole IPv6
Les actions d’un CERT sont à mettre en
corrélation avec les évolutions permanentes des nouvelles technologies.
Un exemple concret est l’apparition discrète, mais insidieuse, de nouveaux protocoles liés à IPv6 dans les systèmes d’information. Plusieurs cœurs de réseaux les
utilisent déjà, tandis que les systèmes d’exploitation les plus récents (Linux 2.6.X,
Windows XP ou Vista, BSD, MacOS, etc.) les
supportent, voire les activent par défaut.
Les travaux à l’initiative de ces protocoles
semblent concerner, sur papier du moins,
certains aspects de sécurité.
Le CERTA voit, en revanche, dans ces protocoles une nouvelle technologie complexe, imposant avant toute chose une
clarification avant leurs déploiements. Il a
donc étudié les mises en œuvre actuelles
et les points d’actualité faisant débat,
notamment les différentes méthodes de
transition entre IPv4 et son successeur (protocoles Teredo, ISATAP, 6to4, etc.) et son
application dans le monde de la mobilité
(MIPv6). Il en découle plusieurs remarques:
• il a été mis en évidence certaines
approximations dans les standards protocolaires, ainsi que des faiblesses dans leur
mise en œuvre. Certaines d’entre elles
ont fait l’objet d’avis. Il ne serait pas étonnant de voir une augmentation des vulnérabilités découvertes dans ce domaine
dans les prochains mois;
• des méthodes existent déjà pour
conduire plusieurs catégories d’attaques
suite page 5
comme des dénis
1. http://www.ssi.gouv.fr
A2IMP : Aide à l’Acquisition
d’Information sur une
Machine Piratée
Sauvegarder les données indispensables à un
dépit de plainte, et ce, en situation d’urgence,
impose de bons réflexes. Acquérir ce savoir faire
était au cœur de la formation de formateurs organisée par l’UREC du 13 au 15 septembre dernier,
en collaboration avec le CERTA et le CERT
RENATER. Cette formation a regroupé 56 participants aptes maintenant à transférer leur connaissance aux administrateurs systèmes et réseaux.
Contact : [email protected]
sécurité informatique
octobre 2006 - n° 57
suite de la page 4
de service, des usurpations d’identités
(routeurs), des collectes d’informations sur
la topologie du réseau ou pour construire
des canaux cachés;
• on constate des limitations évidentes des
outils actuels de protection vis-à-vis de
ces protocoles (pare-feu, détection d’intrusion, etc.);
• il est proposé une série de recommandations aux administrations afin de
s’assurer que les réseaux dont elles ont
la charge prennent correctement en
considération tout le trafic associé à
IPv6, y compris les diverses méthodes
d’encapsulation existantes.
Le CERTA poursuivra cette démarche
dans les mois à venir pour accompagner
l’évolution de cette nouvelle technologie
et aider les administrations vers une transition maîtrisée. Il maintient une note d’information sur son site Internet à ce sujet
(CERTA-2006--INF-004).
[email protected]
et [email protected]
Contact CERTA : [email protected] - Site du CERTA : http://www.certa.ssi.gouv.fr
Note d’information sur les enjeux de sécurité liés à IPv6:
http://www.certa.ssi.gouv.fr/site/CERTA-2006-INF-004
Terminologie d’usage au CERTA : http://www.certa.ssi.gouv.fr/site/CERTA-2006INF-002
Les mémentos du CERTA : http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-002
Les exercices de crise SSI
par Isabelle MOREL, Fonctionnaire de Sécurité des Systèmes d’Information
(ministère de l’éducation nationale, de l’enseignement supérieur et de la recherche)
L’objectif quotidien de la sécurité
des systèmes d’information (SSI) est
de prévenir les accidents afin de
pouvoir disposer de l’information au
moment voulu (c’est la disponibilité),
sans qu’elle ait été modifiée de façon
illégale (c’est l’intégrité), et sans
divulgation au-delà des destinataires
autorisés (c’est la confidentialité).
nels dans son périmètre de responsabilité.
Aujourd’hui, il convient de tester la validité des procédures mises en place et la
réactivité des chaînes d’alertes fonctionnelles et opérationnelles. C’est dans ce
but que le Secrétariat général de la
défense nationale (SGDN) organise régulièrement des exercices de crise SSI.
Il est un second objectif qui vise à protéger les systèmes d’information en cas de
crise majeure. Le caractère stratégique
des SI de notre ministère rend l’entité plus
vulnérable en situation de crise. La
meilleure façon de gérer une crise est de
s’y préparer en élaborant un plan de gestion de crise et en le testant régulièrement
dans le cadre d’exercices. En effet, un
plan ne sera efficace que s’il s’avère exécutable. La gestion de crise ne se limite
pas à réagir a posteriori. Il est possible de
pressentir et d’anticiper certaines crises au
vu de signes avant-coureurs qui peuvent
être caractérisés comme des menaces.
La protection des SI en cas de crise
majeure est prévue au niveau de l’État
dans les plans gouvernementaux Vigipirate, activé en fonction du niveau de
probabilité de la menace, et Piranet,
activé en cas de crise avérée.
Ces plans sont transmis par le Haut
Fonctionnaire de Défense (HFD) aux
« autorités qualifiées pour la sécurité des
systèmes d’information » (AQSSI) du ministère (le secrétaire général pour l’administration centrale, les recteurs pour les services déconcentrés, les présidents pour
les universités, les directeurs généraux
pour les organismes de recherche).
Chaque entité a pour mission de décliner
ces plans génériques en plans opération-
La préparation de l’État
face aux crises et risques
majeurs
Le SGDN est notamment chargé d’élaborer les plans de sécurité nationale et
de veiller à la cohérence des exercices
dans ce domaine. Il peut s’agir du
contexte de la lutte contre le terrorisme
tel que prévu dans le plan « Vigipirate » et
la famille des plans « Pirate » : Piratox, en
cas de menace de nature chimique ;
Piratome, concernant les risques radioactifs ; Piratair, en cas de détournement
d’avion etc., et Piranet, en cas d’attaque
majeure sur les systèmes d’information.
Parallèlement, d’autres plans traitent
d’autres types de menaces telles que les
risques de crues de la Seine ou de pandémie grippale.
Tous ces plans gouvernementaux font
l’objet régulièrement d’exercices, dont
certains dits « majeurs ». Ceux-ci associent
les instances ministérielles au plus haut
niveau décisionnel, les services des administrations centrales et déconcentrées
ainsi que les grands opérateurs ministériels tels que les grands aéroports, la RATP,
mais aussi l’ANPE ou la CNAM.
Ces exercices majeurs servent à entraîner
les équipes gouvernementales, valider les
5
mesures, vérifier que les plans sont toujours
valables face à des menaces actualisées. Ils sont suivis d’une évaluation et
d’un retour d’expérience qui peuvent
amener, si nécessaire, à revoir les mesures
ou adapter les chaînes de transmission.
Dans tous les cas, les plans comportent
une phase de préalerte en cas de
menaces et une phase d’alerte en cas de
crise avérée. Ensuite le processus d’ingénierie de crise gouvernementale se met
en place : réunion interministérielle
conduite par le Premier ministre, activation
de la cellule interministérielle de crise
(CIC), activation des cellules de crise ministérielles concernées, activation des cellules de crise des opérateurs concernés.
Au niveau international
Le SGDN assure également la coordination française dans le cadre d’exercices
internationaux : Crise Management
Exercice (CME) au niveau UE, Digital
Storm exercice interarmées au niveau
OTAN, CME/CMX exercices conjoints UE
et OTAN, ou encore dans le cadre
d’exercices mis en place à l’initiative de
quelques pays européens.
Aux USA, le DHS (Department of Homeland
Security) organise régulièrement l’exercice
Cyberstorm. Le dernier, organisé sur quatre
jours en février 2006, avait pour but d’auditer, entre autres, la coordination de la crise
par le National Cyber Response Coordination Group, d’identifier les points névralgiques des systèmes d’information, et
d’améliorer les interactions entre les
domaines publics et privés. Cent quinze
organismes américains, australiens, canasuite page 6
dien, anglais et néo-zélan-
sécurité informatique
octobre 2006 - n° 57
suite de la page 5
La participation du
MENESR aux exercices SSI
Le ministère a participé à six exercices
depuis 2003, dont un exercice « PIRANET
05 » dit exercice majeur. Il s’agissait d’apprécier les capacités de réaction des
pouvoirs publics en situation de crise
face à des dysfonctionnements multiples
et simultanés de services de l’État et de
services publics critiques liés à des
attaques sur des systèmes d’information.
Les différents types d’entité du ministère
étaient représentés :
• l’administration centrale du ministère;
• quelques académies (services d’administration déconcentrée et centre de
ressources informatiques à destination
des établissements scolaires);
• quelques universités;
• des organismes de recherche sous tutelle
dont le CNRS,le CNES,RENATER;
• un prestataire extérieur.
La répartition géographique des sites
étaient elle-même très distribuée : Paris,
Île-de-France, Province, DOM.
Les exercices étaient animés, pour le
ministère, par la Fonctionnaire de
Sécurité des Systèmes d’Information
(FSSI) sous l’autorité du HFD.
Le déroulement
des exercices
Un exercice est basé sur une suite d’éléments de base. Un événement est un
message envoyé par moyen électronique ou communiqué oralement aux
participants. Il a pour objet d’informer ou
de préciser les actions à tenir, suite à des
faits SSI. Un événement peut donc être
un message d’information, de mise en
garde, d’alerte, de changement de
niveau de vigilance, de déclenchement
de Piranet, voire de posture réactive.
L’ensemble des événements prédéfinis
et planifiés constituent le scénario de
l’exercice. Ce scénario est envoyé aux
animateurs quelques jours avant l’exercice. Le scénario peut être personnalisé
afin de mieux répondre aux spécificités
des organismes et ce en accord avec la
direction d’animation.
Les exercices doivent être joués dans des
conditions normales de fonctionnement
et sur la base des procédures de gestion
de crise mises en place dans chaque
entité participante. Les actions peuvent
être simulées pour ne pas désorganiser
les opérationnels mais les communications sont réelles.
Le temps est réel ou compressé dans
certaines phases des événements
(période précédant les événements et
période de retour au calme). Les exercices se déroulent sur 24 heures, voire
plusieurs jours. Les joueurs fonctionnent
avec leurs structures opérationnelles en
position d’astreinte ou de permanence
s’ils en disposent. Sinon, ils participent en
heures ouvrables et s’assurent du suivi
des informations et événements survenus
en heures non ouvrables. Un scénario
particulier a été ajouté en heures non
ouvrables afin de tester les mesures mises
en place par Renater dans le cadre de
son rôle particulier en cas de crise SSI.
Le scénario de l’exercice majeur 2005 ne
s’est pas limité à une validation technique
du plan gouvernemental PIRANET. Il a créé
une situation permettant de valider un
processus de réponse gouvernementale
globale face à des attaques présumées
terroristes sur les systèmes d’information. La
chaîne fonctionnelle a été activée jusqu’au niveau du Premier ministre, une cellule interministérielle de crise (CIC) a été
activée et la communication gouvernementale a été impliquée.
En fin d’exercice, une procédure d’évaluation et de retour d’expérience est prévue en plusieurs étapes : avant, pendant,
dès la fin de l’exercice (à chaud), en
réunion finale d’évaluation (à froid).
Le rôle des CERTs
Aujourd’hui, des procédures opérationnelles et décisionnelles ont été mises en
place afin de pouvoir répondre 24 heures
sur 24 et ce au bénéfice de l’ensemble de
la communauté éducation, enseignement
supérieur et recherche. Ces procédures ont
été testées lors des exercices hors heures
ouvrables avec notamment le CNES et le
CNRS qui disposent d’un service d’astreinte
générale de sécurité en 24 heures sur 24.
Les enseignements retirés
des exercices
Les exercices sont riches d’enseignements. Ils sont l’occasion pour chaque
entité de mettre à jour et de fiabiliser
annuaires d’alerte, listes de diffusion et
procédures de communication associées.
La gestion de crise de type Piranet
implique différents acteurs, tant au
niveau décisionnel, opérationnel, communication et logistique qu’utilisateurs
finaux. L’identification et le rôle de
chaque type d’acteur sont des points
qui restent à améliorer. Il reste aussi à
associer d’autres acteurs tels que les
prestataires extérieurs, les laboratoires
mixtes de recherche (université, CNRS,
INSERM…), voire les collectivités locales.
Isabelle MOREL :
[email protected]
<mailto:[email protected]>
ou [email protected]
<mailto:[email protected]>
Éric Singer :
SGDN-DCSSI Sous-direction opérations :
[email protected]
<mailto:[email protected]>
COSSI SGDN-DCSSI Centre opérationnel
SSI [email protected]
<mailto:[email protected]>
Tél. : 01 71 75 84 68
S É C U R I T É I N F O R M AT I Q U E
numéro 57
É
S É C U R I T
Les CERTA, CERT RENATER et CERT IST
jouent leur propre rôle et peuvent devenir des centres de compétences sur lesquels pourra s’appuyer la cellule interministérielle de crise (CIC). Le centre
opérationnel de la sécurité des systèmes
d’information (COSSI) de la DCSSI joue
son rôle de conduite SSI de gestion de
crise interministérielle.
octobre 2006
D E S
S
S Y S T È M E
D
’
T I O N
I N F O R M A
Sujets traités : tout ce qui concerne
la sécurité informatique. Gratuit.
Périodicité : 4 numéros par an.
Lectorat : toutes les formations CNRS.
Responsable de la publication :
JOSEPH ILLAND
Fonctionnaire de sécurité de défense
Centre national de la recherche scientifique
3, rue Michel-Ange, 75794 Paris XVI
Tél. 01 44 96 41 88
Courriel : [email protected]
http://www.sg.cnrs.fr/fsd
Rédacteur en chef de ce numéro :
JOSEPH ILLAND, CNRS/FSD
Le rôle de RENATER
RENATER s’est vu confier par le HFD un rôle
particulier dans les situations de crise SSI.
6
ISSN 1257-8819
Commission paritaire n° 1010 B 07548
La reproduction totale ou partielle
des articles est autorisée sous réserve
de mention d’origine
Conception et réalisation: La Souris 01 45210961
dais ont participé. Parmi les entreprises privées, il est à noter la présence de Microsoft,
VeriSign, Symantec, Cisco Systems, Intel ainsi
que de la Croix Rouge américaine.