SCURIT INFORMATIQUE ET RSEAU AU CNRS QUELLES ACTIONS ?

Jean-Luc Archimbaud, Nicole Dausque

rsum : Ce document tablit un bilan des actions menes et en cours en scurit informatique et rseau au CNRS
lautomne 2001. Ces actions sont une mise en uvre pragmatique et concrte des lments obligatoires dune politique de scurit. Ce document prsente rapidement les besoins en terme de scurit au CNRS, les spcificits de lorganisme et de ses systmes dinformation ainsi que les personnes impliques dans la scurit. Il approfondit ensuite les diffrentes actions : - La mthodologie employe pour, dans les units, sensibiliser, faire un tat des lieux, initier le travail de scurit et lancer une dynamique scurit rgionale : les oprations scurit, - Lorganisation humaine mise en place : les coordinateurs rgionaux scurit et les correspondants scurit dans les laboratoires, - La formation de ces personnes : la formation SIARS, - La diffusion et la circulation dinformations, - Le traitement des incidents, - Les recommandations, - Larchitecture rseau recommande et fortement insuffle, - Les outils techniques prconiss et fournis, - La mise en place dune autorit de certification, fondation sur laquelle pourront sappuyer toutes les applications pour assurer lauthentification, lintgrit, la confidentialit et le contrle daccs. Toutes ces actions ne couvrent pas encore lensemble des units, ni tout ce quil faudrait faire . Mais le travail ralis depuis quelques annes est important et lutilit nest plus dmontrer.

1. Deux besoins de scurit et une obligation

Linformatique et les rseaux sont prsents partout. Paralllement, le nombre de problmes de scurit, en particulier les intrusions par lInternet, a augment de manire trs importante ces dernires annes, et cette courbe ascendante ne devrait malheureusement pas sinflchir. Il ne faut pas non plus oublier les risques classiques, vols, dysfonctionnements dus des ngligences ou des actes malveillants internes, ... toujours prsents. Il est donc ncessaire de se protger. Mais que protger ? Au CNRS, on peut considrer que lon a deux besoins principaux en terme de scurit. Le premier est la protection dun outil de travail, les postes informatiques, les rseaux, les applications et les donnes, lensemble constituant le systme dinformation. En effet, cet ensemble est maintenant indispensable la fois pour les activits ncessaires la recherche (calcul, pilotage dexpriences, modlisation, traitement de linformation, communication, bureautique, ), mais aussi pour la gestion des laboratoires. tant devenu indispensable, ces outils sont protger. Une attaque peut par exemple entraner lindisponibilit du serveur de messagerie ou de calcul pendant plusieurs jours, celle-ci sera difficilement supporte par lensemble du personnel. Le second est la protection du patrimoine en particulier scientifique des laboratoires, cest dire des articles en prparation, des rsultats de recherche, des dveloppements, des contrats industriels, La recherche tant de plus en plus finance par des contrats privs, les travaux des laboratoires seront de plus en plus considrer comme confidentiels et donc protger soigneusement. Ces deux classes de besoins en scurit, qui correspondent en fait deux objectifs diffrents, peuvent tre satisfaites avec les mmes mthodes et les mmes outils. En effet si lon protge une station informatique, on protge aussi les informations confidentielles qui y sont stockes. Ces deux besoins saccompagnent dune obligation : celle qui conduit lensemble du personnel des laboratoires respecter la lgislation franaise, sur la criminalit informatique, sur ldition qui sapplique aux serveurs Web, sur la protection de la vie prive (fichiers nominatifs, courrier personnel confidentiel, ), Ce domaine est difficile, car nouveau (il y a encore trs peu de jurisprudence sur les utilisations de lInternet), et demande des rponses non pas techniques mais plutt en terme de sensibilisation, de recommandation et ventuellement de rglementation auprs des personnels.

373

Environnements scuriss

2. Handicaps et avantages du CNRS en matire de scurit

Le CNRS nest pas un milieu facile et les mesures de scurit ne sont ni videntes dfinir, ni faciles faire accepter. De par sa structure, son mode de fonctionnement et ses missions, le CNRS est un organisme qui part avec beaucoup de handicaps sur le chemin amenant une bonne scurit. On peut en citer quelques-uns : - Cest une structure clate, avec plus de 1300 laboratoires sur plusieurs centaines de sites souvent dans des environnements ouverts comme les campus. Il est donc trs difficile de dlimiter des zones (en terme de locaux ou de rseau informatique) protger. - Parmi ces laboratoires, peu sont des units propres, la grande majorit est associe dautres organismes (Universits, INSERM, INRIA, CEA). Les laboratoires doivent respecter les rgles du CNRS mais aussi celles des autres organismes de tutelle. On ne peut donc pas dcider dune politique CNRS sans concertation avec les autres organismes. - Les laboratoires manquent souvent de moyens financiers et en personnel. Il nest pas possible de recommander linstallation systmatiquement de certaines protections (un garde-barrire la porte de chaque laboratoire par exemple) car la plupart des laboratoires nauront ni largent ncessaire pour le financer, ni le personnel pour ladministrer. - Dans chaque laboratoire, il y a du personnel temporaire, tudiants, thsards, contractuels, visiteurs, .Moins sensibles la bonne marche du laboratoire que le personnel permanent, ils constituent naturellement un groupe risque qui demande une surveillance particulire. - De part son activit, la recherche fondamentale demande normment de cooprations extrieures et qui plus est souvent internationales ; la communication et louverture sont alors obligatoires. Il est donc trs difficile de limiter celles-ci, mme si ce sont des mesures videntes pour une meilleure scurit rseau par exemple. - Lactivit du CNRS couvre tous les domaines scientifiques qui ont chacun un mode de fonctionnement et mme parfois un mode de pense spcifique. Dans ces conditions, il est difficile dtablir des recommandations adaptes et acceptes par toutes ces populations diffrentes. Face ces handicaps, il est cependant possible dopposer un certain nombre davantages. Le personnel pour le domaine qui touche en particulier linformatique est gnralement comptent, avec un esprit dinitiative et de cration qui permet au CNRS dtre souvent prcurseur dans le domaine de linformatique et des rseaux malgr des moyens limits. On na pas peur de la nouveaut et on sait faire au mieux avec les moyens dont on dispose. Il existe galement une habitude douverture, dchanges et dentraide entre les ingnieurs ce qui est un avantage trs important par rapport des structures plus cloisonnes et o lesprit de comptition bloque tout travail de groupe. Lorganisation mise en place au CNRS pour traiter la scurit informatique ne pourrait dailleurs pas fonctionner sans cet esprit dquipe. Ainsi le CNRS a des spcificits trs particulires et difficiles. Mais mme si le milieu nest pas favorable lesprit de scurit il faut, sans les cacher ni les ignorer, tenir compte de ces particularismes pour dfinir une bonne politique de scurit. Il est prfrable de se fixer des objectifs limits mais ralistes plutt que de viser un modle standard, cadre rigide inacceptable par notre communaut, modle que nous natteindrons jamais aux vues de nos spcificits.

3. Trois ensembles de systmes dinformation

De fait, trois ensembles de systmes dinformation coexistent au CNRS : - Le systme dinformation de gestion gr par la DSI, rparti entre les centres serveurs de la DSI et les dlgations rgionales. Le rseau qui interconnecte ces sites est un rseau priv, ensemble de liaisons point point (VPs ATM sur Renater). Ladministration de cette informatique et de ce rseau est effectue par une quipe technique centrale qui inclut une fonction de scurit. La politique de scurit classique dune entreprise multi-sites avec un rseau priv et une administration informatique centralise est applique : contrle daccs en entre du rseau priv, limitation des communications aux applications de gestion, - Quelques gros centres de service (calcul comme lIDRIS, de diffusion dinformations scientifiques comme lINIST, ). Chaque centre, situ sur un seul site, a une activit bien dfinie, des utilisateurs clairement identifis, une quipe informatique solide qui administre lensemble et un responsable de la scurit informatique. La politique de scurit mise en uvre suit le modle centre de calcul avec utilisateurs distants : contrle daccs en entre, identification des utilisateurs, - Plus de 1300 laboratoires qui ont chacun leur propre systme dinformation : rseau local, stations diverses (Unix, Win-9X, Win-NT, ), logiciels varis pour les activits bureautiques, Internet, calcul, modlisation, pilotage dexprience, Les quipements et larchitecture sont choisis librement par la direction du laboratoire, nous ne pouvons les orienter que par des recommandations ou lors doprations denvergure finances au niveau central, par le COMI Comit dOrientation des Moyens Informatiques par exemple. Dans chaque unit, cet ensemble est administr localement par un ou plusieurs administrateurs informatiques,personnel du laboratoire ou parfois par du personnel extrieur.

374

Environnements scuriss

Tous ces systmes dinformation sont interconnects par le mme rseau, Renater, lui-mme connect lInternet. Sous laspect scurit, Renater est un rseau sans contrle particulier de scurit et une connexion Renater est aussi risque quune connexion directe lInternet. Il ny a donc pas un rseau CNRS et nous navons pas dIntranet. A noter quil serait compliqu de faire autrement, la plupart des units tant mixtes, un rseau purement CNRS pourrait difficilement tre mis en place. Cette architecture de rseau partag et ouvert nous rend donc trs vulnrable aux attaques venant de lInternet. Le systme dinformation de gestion et les centres de service ont du personnel en charge de la scurit informatique et les politiques de scurit appliquer sont standards . Ils ont donc un niveau de protection correct. Par contre, pour les laboratoires, nous navions pas de modle de politique de scurit appliquer. Il a fallu innover dans les actions entreprendre et la dfinition des priorits et aussi crer un modle de scurit suffisamment modulable pour sadapter aux particularits des laboratoires.

4. Les personnes impliques au niveau national dans la scurit informatique et rseau

Plusieurs entits pilotent ou sont responsables de la scurit des systmes dinformation au CNRS. Au niveau de lensemble de lorganisme, il existe deux units nationales : - Le service du fonctionnaire de dfense avec 2 ingnieurs chargs de mission pour la scurit informatique : Robert Longeon et Jean-Luc Archimbaud. - LUREC, Unit REseaux du CNRS, avec Jean-Luc Archimbaud ingnieur et directeur technique de lUREC et deux ingnieurs Nicole Dausque et Marie-Claude Quidoz. Plus rcemment deux autres ingnieurs Claude Gross et Philippe Leca travaillent au dveloppement et la mise en place de lautorit de certification CNRS. dautres niveaux dans lorganisme il existe des personnes qui ont des fonctions lies la scurit informatique, parmi celles-ci on peut citer : - Bernard Boutherin, ingnieur, responsable scurit lIN2P3, - Lionel Maurice, ingnieur, responsable scurit lIDRIS, - Olivier Porte, ingnieur, charg de la scurit la DSI. Lensemble de ces personnes recouvre les 3 systmes dinformation du CNRS. Elles collaborent entre elles et se retrouvent au sein de groupes communs et tout particulirement au sein du groupe des coordinateurs scurit (voir chapitre 6, organisation humaine). ces personnes il faut ajouter les autres coordinateurs scurit, administrateurs systmes et rseaux dans des laboratoires ou des campus qui consacrent une partie de leur temps la scurit, pas uniquement pour leur laboratoire mais pour lensemble de la communaut. Toutes ces personnes impliques au niveau national dans la scurit informatique travaillent galement en collaboration avec les personnes en charge de la scurit informatique dans les autres organismes ou ministres, ainsi quavec le CERT-Renater et le CERT-A (CERT : Computer Emergency Response Team ).

5. Les oprations scurit

Fin 1997, lUREC et le service du fonctionnaire de Dfense, ont dcid de lancer des oprations de scurit informatique et rseau sur des groupes de laboratoires CNRS dans les rgions http://www.urec.cnrs.fr/securite/articles/ope.secu.html. Nous avons invent une mthode adapte au mode de fonctionnement de lorganisme et des laboratoires. Le but de ces oprations est daider les units amliorer leur scurit en : - Les sensibilisant la scurit (en particulier les directeurs), - Les aidant faire un bilan de leurs vulnrabilits, - Proposant des actions correctrices et des outils de scurisation, - Proposant des amliorations de lorganisation technique et humaine, - Vrifiant lapplication des recommandations CNRS, - Crant un rseau humain. Nous avons dabord rdig une liste de contrles qui fait actuellement 37 pages et qui comprend 7 chapitres : prsentation du laboratoire, organisation de la scurit, scurit sur les systmes Unix, scurit des rseaux, services et outils de scurit Unix, scurit sur les systmes NT, scurit des rseaux de micro-ordinateurs. Cest un questionnaire qui regroupe toutes les vulnrabilits les plus rpandues notre connaissance dans les laboratoires et qui propose pour chaque point une recommandation et ventuellement une correction approprie. Ainsi ce nest pas un outil daudit mais daide aux laboratoires et aux administrateurs qui grent le rseau et les quipements informatiques. Cette liste a t rdige par 11 experts, responsables scurit de centres de service, ingnieurs UREC et charg de mission scurit mais aussi administrateurs informatiques de laboratoire. Cette liste est rgulirement mise jour par les ingnieurs de lUREC, aprs chaque opration scurit en tenant compte des remarques des participants et des nouveaux types dintrusions qui nous sont signales par les laboratoires ou par le CERT-Renater et le CERT-A. La valeur de cette liste est surtout due sa taille raisonnable . Il est trs facile de rdiger une liste gnrale de contrles effectuer, il en existe dailleurs

375

Environnements scuriss

plusieurs sur lInternet, il suffirait de les compiler. Le problme est que le rsultat serait trop volumineux pour tre appliqu dans les laboratoires. Par opposition, dans cette liste, nous nous limitons ce qui est le plus important vrifier en se basant sur notre exprience et sur les nouvelles attaques dont nous avons connaissance dans notre communaut. Avec cette liste comme outil de base, plusieurs tapes constituent ensuite le droulement dune opration scurit. Nous choisissons une dlgation (ou une communaut spcifique, nous avons par exemple fait une opration pour les laboratoires SHS de Paris). Au dpart nous sollicitions certaines dlgations, maintenant on nous demande dintervenir. Nous contactons 2 (parfois 3 maintenant) ingnieurs en informatique de la rgion qui connaissent les laboratoires dpendant de la dlgation, les problmes de scurit, et qui ont un sens du travail en groupe et de la coordination et qui sont volontaires pour consacrer du temps pour la collectivit CNRS . Ce peut tre ladministrateur du rseau du campus CNRS quand il y en a un dans la rgion, le responsable des systmes dinformation (RSI) de la dlgation, un ingnieur en informatique dun laboratoire, Nous contactons ensuite le dlgu pour lui exposer lobjet de ces oprations et lui proposer ces personnes pour piloter lopration dans sa rgion. Avec son accord et laccord des directeurs concerns, ces personnes sont dsignes coordinateurs scurit. Avec ces coordinateurs et le dlgu nous tablissons la liste des laboratoires qui vont participer lopration (en moyenne 15, plutt proches du CNRS), la liste des directeurs et des administrateurs informatiques, le planning, lorganisation, Le droulement se poursuit ainsi : - Nous intervenons 2 jours dans la rgion : Une demi-journe de sensibilisation des directeurs des units qui participent lopration, avec une intervention du dlgu rgional, de lUREC, du fonctionnaire de dfense, de la DST. Lopration est dtaille aux participants. Un jour et demi de travail avec les administrateurs o nous prsentons la liste de contrles, effectuons un tour de table o les administrateurs dcrivent leur environnement, leurs problmes, permettant ainsi des changes et la cration dun groupe ; des prsentations techniques adaptes aux laboratoires participants compltent systmatiquement les points prcdents. Deux ingnieurs de lUREC pilotent ce travail. - Nous laissons travailler les administrateurs 20 jours environ dans leur laboratoire pour quils appliquent la liste de contrles sur leurs serveurs et sur un chantillon reprsentatif de leur matriel et commencent installer quelques outils de scurit. Les coordinateurs crent une liste lectronique pour permettre lchange dinformations entre ces administrateurs et ils peuvent aider, dans lutilisation de cette liste de contrles, certains laboratoires qui manquent de personnel. - Les coordinateurs recueillent les listes de contrles remplies et en font une compilation. - Deux ingnieurs de lUREC interviennent ensuite 1 jour pour faire un bilan : Prsentation de la compilation des rponses par les coordinateurs. Tour de table pour recueillir les remarques des administrateurs et les vulnrabilits importantes dcouvertes dans leur laboratoire. Bilan provisoire de notre part. Complment de prsentations techniques. - Nous rdigeons un rapport qui rsume les points les plus vulnrables que nous avons dcouverts et qui inclut certaines propositions (besoin de demande de poste, de mise en place dorganisation, dachat dquipement particulier, ). Celui-ci est envoy au dlgu rgional, au fonctionnaire de dfense, aux directeurs et aux administrateurs informatiques. Les coordinateurs de lopration suivante assistent lopration en cours. Sont aussi invits les responsables des structures non CNRS qui peuvent tre impliqus dans la scurit : administrateurs du rseau mtropolitain, rgional, responsables de CRI universitaire, RSSI universit, Ces personnes font souvent des prsentations lors des oprations. A Lyon, lopration a ainsi t faite en collaboration avec les universits. Cette participation externe tient compte de la ralit des laboratoires du CNRS o les interactions avec les universits, en particulier, sont trs fortes. Chaque opration est ainsi diffrente et sadapte aux spcificits de la rgion. ce jour nous avons men 14 oprations. Nous avons dbut par 3 oprations pilotes, Sophia (12/97), Toulouse (03/98), Grenoble (06/98). Devant le succs de ces oprations nous avons continu par Marseille (09/98), Nancy (10/98), Gif (04/99), Orlans (11/99), SHS Paris (03/00), Strasbourg (05/00), Besanon (09/00), Orsay (10/00), Lyon (12/00), Montpellier (03/01), Meudon (05/01). La prochaine sera Thiais en octobre-novembre 2001, puis sur le campus de Jussieu et avec en prvision la rgion Ouest. Notre rythme est ainsi de 3 4 voire 5 oprations par an. Ces oprations ont t compltes par la diffusion dun logiciel de simulation de vulnrabilits Internet Scanner , prsent au chapitre 12 (Les outils techniques recommands et fournis).

376

Environnements scuriss

6. Lorganisation humaine mise en place

6.1 Les coordinateurs scurit Les oprations scurit ont permis progressivement de mettre en place une organisation humaine coordonne par lUREC. Nous avons ainsi regroup les coordinateurs des oprations scurit, les responsables scurit (DSI, IDRIS, IN2P3, ) et quelques experts dans un groupe national actuellement compos de 44 personnes. Une liste de diffusion lectronique regroupe ces coordinateurs scurit et nous les runissons maintenant rgulirement, au minimum 2 fois par an. Ils sont notre interface vers les laboratoires pour diffuser les recommandations, intervenir en cas dincident de scurit, faire remonter les demandes, Ils participent aussi des groupes de travail que nous pilotons pour tester et choisir certains logiciels, rdiger des recommandations, monter des formations (cf. formation SIARS). Ils constituent le noyau dur sur lequel nous nous appuyons. 6.2 Les correspondants scurit Dans les laboratoires nous avons les correspondants scurit, administrateurs informatiques et rseaux qui ont particip aux oprations scurit, actuellement un peu plus de 300. Une liste de diffusion lectronique regroupe ces correspondants scurit permettant ainsi lUREC de diffuser directement et rapidement toutes informations de scurit les concernant. En rgion, chaque quipe de coordinateurs runit aussi souvent que possible, par exemple chaque mois, les correspondants scurit des laboratoires pour effectuer le mme travail quau niveau national. Ces runions rgionales permettent de crer ainsi des groupes dadministrateurs informatiques qui partagent leurs problmes et leurs expriences et ainsi cooprent, sans perdre du temps redcouvrir ce quun autre administrateur a dj rsolu. Ceci rompt lisolement des ingnieurs informatiques, un des points faibles inhrent lorganisation des laboratoires au CNRS. Nous avons ainsi un rseau 2 niveaux. Ce rseau et tous les changes qui sy font permettent daider les laboratoires tout en tirant partie dun avantage du CNRS dj cit, les diffrentes comptences rparties dans les units. Ce rseau a permis ainsi de mettre en place facilement les actions dcrites dans la suite de ce document : formation, diffusion dinformations, gestion des incidents, 6.3 Problme de cette organisation Le talon dAchille, qui certainement posera des problmes moyen terme, est que ce dispositif repose sur des personnes rattaches des laboratoires qui assurent ces tches, avec laccord de leur directeur, en plus de leur travail quotidien dans leur unit. Dynamiques, ces personnes sont facilement volontaires pour participer ou mener des actions dans le domaine nouveau et techniquement intressant de la scurit o beaucoup de choses restent dcouvrir . Mais cette nouveaut risque de ne pas durer et devenir plus routinire et moins attrayante. Il faudrait sans doute revoir ce principe du volontariat systmatique. Mais ce nest pas le but de ce document qui se veut uniquement tre un bilan.

7. La formation SIARS : Scurit Informatique pour les Administrateurs Rseaux et Systmes

Des journes de formation (sensibilisation, protection du patrimoine, ) sont organises par diffrentes structures (DCSSI, ministre, ....) o des places sont rserves au personnel CNRS. Mais elles ne couvrent pas les besoins de base des administrateurs systmes et rseaux des laboratoires. A chaque opration scurit, nous assurons des prsentations ponctuelles doutils et de mcanismes de scurit. Mais nous ne pouvons rpondre toutes les attentes dinformation. Nous avons aussi fait le constat que les ingnieurs dans les laboratoires nont pas t forms pour dfinir une politique de scurit informatique dans leur laboratoire et se trouvent dpourvus au moment de choisir et dinstaller les bons outils. En parallle, les produits de protection sont maintenant nombreux et un ensemble de mthodes, de techniques et doutils, souvent du domaine public, acceptables par un laboratoire sont disponibles. Ce sont les raisons pour lesquelles les coordinateurs et les correspondants scurit nous ont demand une formation de base dans ce domaine mais concrte et adapte aux laboratoires. Nous avons fait un tour dhorizon des diffrentes formations proposes par les entreprises ou organismes spcialiss. Notre conclusion est quelles sont coteuses (environ 3000 F par jour par personne), trop dtailles (une semaine pour chaque type de systme informatique par exemple) ou trop gnrales (sans prsentation doutils concrets). En rsum, elles ne sont pas adaptes des ingnieurs qui administrent des quipements rseau et des systmes informatiques trs varis et qui doivent aussi veiller leur scurit. LUREC a donc dcid de mettre en place une formation dans ce domaine en coopration avec la formation permanente du CNRS http://www.urec.cnrs.fr/securite/formation.6.pdf. Nicole Dausque (UREC) en assure la coordination. Le bureau national de la formation permanente nous appuie totalement dans ce projet.

377

Environnements scuriss

Un comit de pilotage a t constitu et sest runi en octobre 2000. Compos de A. Marchal dlgu rgional de Bretagne (prsident), Y. Ellien bureau national de la formation permanente, N. Lucciani-Chapuis responsable formation permanente Marseille, P. Richy expert extrieur (France Tlcom, enseignant ENST), Y. Deswartes expert CNRS (Directeur de recherche au LAAS), A. Schwenck Fonctionnaire de dfense, S. Manoussis charg de mission informatique du dpartement SDU, M-A Caron DRH, J. Marchand administrateur informatique laboratoire de Maths, J-L Archimbaud et N. Dausque UREC, ce comit nous a vivement encourag dans cette dmarche et sest montr trs intress suivre le droulement. Le principe le plus efficace et le moins coteux que nous avons retenu est de former les coordinateurs pour quils forment leur tour les correspondants. Les coordinateurs seront donc des formateurs. Nous avons dfini et suivons 3 tapes : 1. Prparation du programme et du support de cours avec un sous-ensemble des coordinateurs, chaque participant amenant une comptence dans un domaine. Ce sont 15 rdacteurs qui ont ralis un travail collaboratif (cf. annexe 14.1). Ce travail sest droul fin 2000. On dispose ainsi dun support de cours, ouvrage collectif, de plus de 400 pages. Les chapitres, ayant tous trait la scurit, sont : - Organisation, mthodologie et lgislation - lments de base (TCP/IP, cryptographie, IGC, ) - Unix - Windows-NT et Windows-2000 - Services rseaux locaux - Services Internet - Postes individuels - Applications - Architectures rseaux - Outils de scurit et applications scurises - Recommandations, mise en uvre 2. Avec le bureau national de la formation permanente, mise en place de la formation de tous les coordinateurs scurit pendant 2 semaines en janvier 2001. La partie technique a t assure par les rdacteurs du cours, une journe consacre la pdagogie a t ralise par une socit externe. Lobjectif tait de former ces coordinateurs pour quils acquirent les bases techniques ncessaires pour leur travail de coordination et pour quils puissent redonner cette formation dautres ingnieurs : les correspondants scurit. Cette formation sest trs bien passe et tous les coordinateurs ont t volontaires pour organiser cette formation dans leur rgion respective. 3. Formation des correspondants scurit des laboratoires dune dure de 6 jours, organise par les coordinateurs avec le responsable de la formation permanente de chaque dlgation. Les cours seront assurs par les coordinateurs locaux ou dautres rgions et des intervenants locaux si besoin. Lobjectif est de former les administrateurs informatiques de laboratoire pour quils puissent dfinir une politique de scurit adapte leur laboratoire. Cest dire conseiller et aider ces administrateurs pour quils acquirent une mthodologie et une dmarche scurit, une vue des techniques et des outils de protection actuels, et soient aptes installer un ensemble minimum doutils de scurit dans leur laboratoire, ceci avec des critres compatibles avec la vie des laboratoires de recherche. Ces formations sont tales sur lanne 2001, certaines sont dj ralises dautres sont planifies avant la fin 2001 ou sur le premier trimestre 2002. On espre ainsi que les 300 correspondants scurit auront reu la formation durant lanne 2001 et le premier semestre 2002. Une seconde session de formation, voire une troisime pourront tre organises (comme cest le cas sur Grenoble). La mise jour du support de cours, indispensable dans ce domaine trs volutif de la scurit informatique, est ralise par les rdacteurs. Si le support de cours, les dernires corrections faites, est dune bonne qualit, nous envisageons de le diffuser sur le Web et peut-tre sous forme dune dition papier. Les universits et dautres organismes de recherche sont dj intresss. Les mmes besoins quau CNRS existent et ce support de cours pourrait tre ainsi mis leur disposition.

8. La diffusion et la circulation dinformations

Actuellement, 2 serveurs Web, 3 listes de diffusion, un bulletin dinformation et un guide sont nos principaux outils pour diffuser des informations. LUREC administre un serveur Web de rfrence pour les laboratoires http://www.urec.cnrs.fr/ comportant une rubrique sur la scurit informatique et rseaux. Rgulirement mise jour, la rubrique scurit comprend les pages suivantes : - Des Brves de clavier qui annoncent les nouveauts : lois, outils, - Les informations propres la Scurit au CNRS qui dcrivent lorganisation en place, les contacts, que faire en cas dincident, les chartes, les recommandations CNRS (serveurs Web, architecture, ), la description de la formation SIARS, des pages rserves aux coordinateurs scurit (accs avec certificat), des pages rserves aux correspondants scurit (accs avec certificat)

378

Environnements scuriss

- Des documentations sur la scurit produites par lUREC : Articles, Supports de cours et prsentations - Des Outils de scurit (audit ou prvention) tests et recommands par lUREC pour Unix et Windows (cf. chapitre 12) - Des pointeurs sur les anti-virus, les Virus et les canulars - Des pointeurs sur les CERTs et les avis du CERT-Renater - Des pointeurs vers dAutres serveurs : service juridique du CNRS, CNIL, DCSSI, CRU, Ainsi que des informations sur les IGC - Infrastructure de Gestion de Cls : Politique de certification CNRS, serveur de Certificats CNRS et Documentation et sur la formation SIARS. Les rubriques du serveur de lUREC, ayant traits la scurit ne sont pas des rubriques caractre gnraliste, elles sont cibles sur ce qui peut tre utile dans ce domaine aux laboratoires du CNRS. Robert Longeon administre un serveur Web complmentaire dans ce domaine : http://www.cnrs.fr/Infosecu/accueil.html avec 4 parties : - Des informations rapides : annonces de stages, formations, - La protection du patrimoine - La revue Scurit informatique (cf. ci-aprs) - Les virus : documentation, pointeurs, anti-virus, Trois principales listes de diffusions sont utilises par les laboratoires : - sos-virus, liste trs active avec 5 10 messages par jour sur les virus, elle comprend prs de 500 abonns et est ouverte des personnes dautres organismes que le CNRS http://www.services.cnrs.fr/wws/info/sos-virus. - csec qui regroupe les coordinateurs scurit (44 abonns). Elle permet ce groupe de travailler ensemble. La diffusion dans cette liste est contrle par certificat CNRS-SSI. - corres-secu, modre et contrle et qui regroupe plus de 300 correspondants scurit des laboratoires CNRS. Les avis du CERT-Renater et du CERT-A sur les vulnrabilits dcouvertes sont diffuss dans cette liste. Le CERT-Renater a ainsi mis environ 400 annonces de vulnrabilits durant lanne 2000 qui ont t rediffuses dans cette liste. Cest aussi notre moyen de diffusion pour transmettre les recommandations CNRS, formations, et insister sur certains avis de scurit du CERT-Renater que nous jugeons importants. Laccs cette liste est restreint aux correspondants scurit du CNRS. Le bulletin Scurit informatique http://www.cnrs.fr/Infosecu/Revue.html dont le responsable de la publication est Robert Longeon, avec une parution de 5 numros par an, propose des articles de fond sur la scurit. A titre dexemple, les derniers numros ont trait de : - La politique de scurit informatique - La correspondance prive et le courrier lectronique - Les virus - Les produits de simulations dintrusion Tir plusieurs milliers dexemplaires la fois sous forme papier et avec une diffusion lectronique il est trs connu et trs lu dans les laboratoires et maintenant reconnu lextrieur de lorganisme comme un bulletin de rfrence. Un Guide de la scurit des systmes dinformation lusage des Directeurs : http://www.cnrs.fr/Infosecu/guide/guide.pdf de 90 pages a t rdig par Robert Longeon et Jean-Luc Archimbaud. Tir plusieurs milliers dexemplaires, il a t envoy tous les directeurs dunit CNRS au cours du deuxime semestre 1999. Destin sensibiliser les directions aux problmes de scurit et prsenter les principales vulnrabilits et les premires protections mettre en place, il a aussi t diffus dans dautres organismes de recherche qui taient intresss par cet ouvrage. Autre lment de sensibilisation, lors du stage destin aux nouveaux directeurs, un crneau est rserv la protection du patrimoine et la scurit des systmes dinformation. Cette intervention, assure par le fonctionnaire de dfense, permet un dialogue direct avec les nouveaux directeurs.

9. Le traitement des incidents

Une procdure connue des correspondants scurit de laboratoire et disponible en ligne http://www.urec.cnrs.fr/securite/chartes/quefaire.html dcrit les mesures prendre en cas de dtection dun incident de scurit (intrusion par exemple). Elles consistent : - Avertir le responsable scurit et le directeur du laboratoire. - Supprimer laccs au systme depuis lextrieur et faire une sauvegarde pour garder des traces. - Remplir la fiche suivi dincident http://www.urec.cnrs.fr/securite/chartes/fiche_suivi_incident.txt et lenvoyer au CERT-Renater avec copie aux coordinateurs scurit nationaux mayday@urec.cnrs.fr et aux coordinateurs scurit de la rgion. - En accord avec le directeur du laboratoire, contacter le fonctionnaire de dfense si un dpt de plainte est envisag.

379

Environnements scuriss

- Regarder les dgts et dterminer la cause de lincident : http://www.CRU.fr/securite/Documents-generaux/Recommandations.html. - Informer en concertation avec le directeur du laboratoire, le/les centre(s) fournisseur(s) de ressources (calcul, bases de donnes) avec lesquels les utilisateurs du laboratoire travaillent rgulirement. - Examiner toutes les autres machines pouvant tre compromises et en particulier changer tous les mots de passe si linstallation dun renifleur a t dtecte. - Rinstaller la machine compromise en ayant soin davoir corrig la/les failles de scurit. - Faire une sauvegarde et une empreinte du systme. - Rinstaller les comptes utilisateurs. - Reconnecter la machine au rseau. Nous rappelons ces conseils lors de chaque opration scurit pour sensibiliser mais aussi rassurer les administrateurs qui sont souvent trs perturbs par une intrusion. Lors des intrusions venant de lInternet, ces dernires annes cest le CERT-Renater avec ses 4 permanents qui a assur lassistance technique aux sites de manire trs efficace : http://www.renater.fr/Securite/CERT_Renater.htm. Nous intervenons pour mettre en contact le CERT-Renater avec le correspondant scurit du laboratoire (ou inversement), en cas de besoin spcifique CNRS, pour sassurer que les recommandations CNRS sont suivies, que les diffrents acteurs (direction, ventuellement dautres laboratoires) sont au courant et pour dventuels conseils de fond (revoir larchitecture du rseau par exemple). Durant lanne 2000, 61 incidents scurit nous ont t signals, en grande majorit des intrusions Internet. Ces chiffres nincluent pas les tests classiques de vulnrabilit sur Internet (scans) qui ne donnent pas lieu rellement des intrusions.

10. Les recommandations

Plusieurs recommandations ont t mises dans le domaine de la scurit informatique et sont toujours dactualit. La plus importante est la Charte utilisateur pour lusage des ressources informatiques et de services Internet http://www.cnrs.fr/Infosecu/Charte.pdf. Celle-ci a t publie au bulletin officiel du CNRS en fvrier 1999. De fait, elle est donc incluse dans le rglement intrieur de chaque unit. Il est recommand de la faire largement connatre dans les laboratoires (affichage, ) et de la faire signer aux personnes non permanentes dans les laboratoires avant quelles accdent aux ressources informatiques et rseaux du laboratoire. Elle permet entre autre de rappeler la lgislation franaise en vigueur (toute tentative de piratage est punie par la loi ), que la scurit est laffaire de tous, que les utilisateurs ont des devoirs et que lutilisation de ces ressources nest autorise que dans le cadre de lactivit professionnelle. Cette charte est maintenant largement connue et applique dans la grande majorit des units. Dautres recommandations ont t galement diffuses, pour en particulier mieux administrer les services de diffusion dinformation Internet. Les laboratoires ont t des pionniers dans linstallation de ces services et ceux-ci avaient t crs dans un esprit de libert avec un Internet acadmique convivial, par des bonnes volonts . Ces recommandations, rdiges par le comit de coordination Web sont destines mieux cadrer ces diffusions pour respecter la lgislation et tre en accord avec les missions du CNRS. Actuellement elles sont appliques sauf exception. Elles sont regroupes dans la page : http://www.urec.cnrs.fr/securite/recommandations_cnrs.html : - Installation et gestion dun serveur WWW - Cration, administration et gestion des FTP anonymes - Cration, administration et gestion des listes de diffusion la demande de la DCAJ Direction des Contrats et des Affaires Juridiques et du COMI, nous avons rcemment cr un groupe de travail afin dessayer dtablir des Recommandations dans la pratique du mtier dadministrateur systmes et rseaux dans un laboratoire CNRS. Le but est dinformer les administrateurs sur leurs droits mais aussi leurs devoirs (respect de la lgislation : confidentialit des correspondances prives, ). Lobjectif est de prvenir, dans un sens ou dans un autre, les excs des administrateurs : comportement trop laxiste o on ne surveille plus rien car tout est considr comme confidentiel, comportement trop policier o tout est contrl. Toutes ces recommandations ont pour but dviter les drives et si possible danticiper les problmes qui pourraient survenir dans les laboratoires dans le monde trs volutif des systmes dinformation, des rseaux et plus globalement de lInternet o l il ny a encore ni rglementations, ni lois, ni jurisprudences trs prcises.

380

Environnements scuriss

11. Larchitecture rseau

La plupart des rseaux dans les laboratoires et les campus datent du milieu des annes 90 et les laboratoires travers ces rseaux sont connects lInternet (Renater pour nous) depuis son origine. Lors du choix de larchitecture interne de ces rseaux et de leur connexion Renater, le but principal tait alors que toutes les machines des sites, sans exception, puissent accder et tre accdes de lInternet (ouverture totale). LInternet ntait quun ensemble convivial de rseaux de recherche. Il nexistait pas dattaque de spam, scan, smurf, flood, spoofing, sniffer, trojans (nota : anglicisme voulu par les auteurs). Maintenant cest devenu un outil de communication mondial, utilis par des bons mais aussi des mauvais citoyens et toutes les dviances courantes y sont prsentes. Il a donc fallu revoir larchitecture de nos rseaux pour viter la prolifration des intrusions. Nous avons tabli en janvier 2000 un modle de rfrence darchitecture (cf. annexe 14.2) bas sur une segmentation du rseau interne avec : - Une zone pour les serveurs publics (machines accdes depuis lInternet : serveur Web, messagerie, bases de donnes publiques, ). Nous recommandons que ces services soient sur des machines ddies. - Plusieurs zones internes : une par laboratoire ou quipe de recherche, une pour les salles de TP, une autre pour les serveurs internes, - Des filtrages entre ces zones autorisant ou non certains trafics. - Un filtrage en entre de site pour ne laisser passer que ce qui est vraiment utile et protger les machines internes des attaques. Cette architecture ne rduit pas les services de lInternet pour le personnel de laboratoire, elle devrait tre transparente. Elle permet simplement de faire un tri, ce qui facilite ladministration et la surveillance, et de bien protger ce qui doit ltre. Nous prsentons cette architecture http://www.urec.cnrs.fr/securite/articles/archi.reseau.pdf dans toutes les oprations scurit et cette occasion vrifions que les laboratoires voluent dans ce sens. Tout fait compris et admis, lvolution vers ce modle est partout en bonne voie. Cest certainement cela qui nous a mis labri dune avalanche dattaques qui seraient arrives si nous navions pas pris temps ce virage vers une architecture scurise. Cette recommandation, largement connue, est reprise par la plupart des organismes de recherche et des universits. Il reste actuellement un besoin essentiel prendre en compte : comment permettre aux utilisateurs lextrieur de leur laboratoire, depuis leur domicile, en congrs, daccder leur boite aux lettres, ventuellement leur machine et leurs donnes, donc certains services de leur laboratoire ceci de manire scurise (sans que par exemple leur mot de passe soit cout durant leur connexion). Des solutions techniques existent (SSH, Webmail, IMAPS, IPSec, ) et commencent tre mises en place dans des units. Mais ce domaine touffu et complexe demande un travail de fond. Nous avons rcemment cr un groupe de travail pour valuer toutes ces mthodes et faire des recommandations pratiques pour les laboratoires : quels produits utiliser pour quels services ? Marie-Claude Quidoz (UREC) anime ce groupe de travail accs distants scuriss (Prsentation aux Journes JRES2001 : Accs distants scuriss : un essai de bilan des solutions possibles par Marie-Claude Quidoz).

12. Les outils recommands et fournis

Il nexiste malheureusement pas une boite ou un logiciel qui rsoudrait tous les problmes de scurit des laboratoires. Par contre il existe de nombreux outils, souvent du domaine public, qui peuvent amliorer la scurit et certains sont adapts notre environnement. Il faut donc faire un choix. Avec laide des coordinateurs et des correspondants, nous tenons jour une liste doutils que nous avons tests et que nous recommandons. La liste des outils pour Windows-NT et Windows-2000 sest par exemple beaucoup toffe suite de nombreux tests raliss. Rgulirement de nouvelles valuations sont effectues sur de nouveaux logiciels. Ces outils logiciels (vrification de la solidit des mots de passe, contrles daccs rseau, vrification de ltat des systmes, ) sont disponibles sur le serveur de lUREC dans les pages : http://www.urec.cnrs.fr/securite/outils/ et http://www.urec.cnrs.fr/securite/outils/nt/. Les principaux sont prsents dans la liste de contrles utilise pour les oprations scurit et ils sont aussi longuement dcrits dans le cours de formation SIARS. Il y a donc une mme recommandation entre ces diffrents moyens de diffusion. Paralllement, les laboratoires peuvent obtenir gratuitement certains antivirus (Norton, Fsecure-AVP, Virus scan) auprs principalement des CRI des universits. Pour complter les oprations scurit en 1999 nous avons achet 2000 licences, avec 2 ans de maintenance, dun logiciel de dtection de vulnrabilits par simulation dintrusions sur le rseau, appel IS Internet Scanner http://www.iss.net/. Ce logiciel est en fait une liste de 700 contrles qui sexcutent automatiquement depuis un poste vers des stations via le rseau. Il a t diffus par lUREC aux laboratoires qui ont suivi les oprations scurit. Pouvant tre dangereux dans une utilisation non contrle, cette diffusion a t accompagne dune mthodologie de mise en uvre : rdaction de recommandations dutilisation

381

Environnements scuriss

http://www.urec.cnrs.fr/securite/articles/si_recommandations.pdf, formation des administrateurs, utilisation par ces administrateurs dans leur unit et bilan. Pour poursuivre lemploi de ce type de produit dans les laboratoires, car ils font partie de la politique de scurit, le logiciel NESSUS http://www.nessus.comest galement prsent avec les mmes recommandations dutilisation.

13. Lautorit de certification

Les actions dcrites dans les chapitres prcdents sont des mesures prventives et galement dfensives, afin de se protger contre des attaques. Cependant toutes ne permettent pas dapporter des services de scurit (authentification, intgrit, confidentialit, contrle daccs) pour les applications utilises au CNRS : messagerie, accs aux serveurs Web, applications de gestion, .... La mise en place dune autorit de certification, la cration et lutilisation de certificats lectroniques, vont dans le sens dune scurit active. Et ces lments constituent la fondation sur laquelle pourront sappuyer toutes les applications au CNRS http://www.urec.cnrs.fr/securite/articles/certificats.kezako.pdf. De plus, ces mcanismes pourront permettre des conomies importantes en utilisant mieux le rseau. Ainsi lorsque chaque personne travaillant dans un laboratoire aura un certificat, ceci permettra : - De diffuser toutes les notes officielles (ou quivalentes) par voie lectronique. Actuellement cette option techniquement possible est trop dangereuse, car lorigine des messages nest pas garantie. Quand chaque directeur et responsable aura un certificat, il pourra signer tous ses envois lectroniques et ainsi garantir lorigine et lintgrit des messages mis. - Les certificats pouvant tre utiliss pour assurer en plus la confidentialit et lintgrit des messages, ceci permettra dutiliser la messagerie lectronique pour les lections, les notations, la gestion du personnel, - Toutes les applications de gestion pourront sappuyer sur un seul type de contrle daccs : les certificats, mcanisme qui permettra dhomogniser les diffrentes mthodes actuelles. - On pourra crer des Intranet de personnes pour mettre en ligne des documents uniquement accessibles aux agents CNRS, un dpartement scientifique, un laboratoire, des communauts particulires, Actuellement ceci trs difficilement ralisable. - Les certificats devraient faciliter la mise en place doutils pour accder distance sa boite aux lettres, des machines du laboratoire, sans circulation du mot de passe en clair sur le rseau. - Les certificats permettent dauthentifier les machines, ainsi il sera possible de dployer de manire scurise des applications avec un serveur et plusieurs agents distants par exemple. - Les certificats sont obligatoires dans toute mise en commun de ressources distribues comme les grilles de calcul o les utilisateurs mais aussi les machines et leurs quipements doivent tre authentifies. LUREC a mont une plate-forme de test dune autorit de certification CNRS-Test en fvrier 2000 pour valuer les potentialits des certificats, les procdures et les logiciels mettre en place, la faisabilit http://www.urec.cnrs.fr/securite/articles/CA.CNRS-Test.pdf. Des logiciels ont t dvelopps partir de briques du domaine public, des procdures crites et mises en oeuvre et actuellement plus de 200 certificats (utilisateurs et serveurs) ont t dlivrs. On peut demander un certificat en suivant le mode demploi : http://igc.services.cnrs.fr/CNRS-Test/. Ces certificats ont t en grande partie tests par les coordinateurs et correspondants scurit qui les ont utiliss pour : - Signer les avis de scurit du CERT-Renater, garantissant ainsi lorigine et lintgrit de ces avis de scurit, - Chiffrer parfois des communications sensibles (rapports dincidents de scurit par exemple), - Contrler laccs des pages sur un serveur Web, pages rserves aux coordinateurs scurit, - Construire le cours SIARS avec une quinzaine dauteurs distance : mise en ligne des diffrentes parties du cours, accs contrl par certificat en lecture et criture pour y accder, les modifier, .... Ces certificats ont aussi t utiliss des fins de tests pour mettre en uvre les grilles de calcul dans le projet Datagrid http://grid-france.in2p3.fr/ o un certificat est ncessaire pour chaque station et chaque utilisateur, ainsi que pour scuriser les communications avec certains serveurs Web, passerelle daccs distance la messagerie interne dun laboratoire par exemple. Tous ces tests, trs encourageants puisque montrant tous les avantages quun organisme clat comme le CNRS pouvait tirer de ces mcanismes ont t entrins par la dcision, en juillet 2000, de la direction du CNRS de crer une autorit de certification et den confier la mise en uvre lUREC http://www.urec.cnrs.fr/securite/certifications/decision_creation_AC_cnrs.pdf. Un comit de pilotage et un comit technique ont commenc travailler lautomne 2000. Une politique de certification et une description des procdures, compatible avec les recommandations du DCSSI Direction Centrale de la Scurit des Systmes dInformation et de la commission interministrielle sur le sujet, ont t rdiges. Un ensemble de logiciels dIGC Infrastructure de Gestion de Cls a t crit par deux ingnieurs de lUREC, Claude Gross et Philippe Leca. Un groupe de sites pilotes a t choisi (LAAS, DR de Bordeaux, DR de Toulouse, DSI, IMAG, Datagrid-fr, scurit). Ces sites utilisent depuis mai 2001 les logiciels IGC dvelopps et les procdures

382

Environnements scuriss

dfinies pour dlivrer des certificats en suivant la politique de certification rdige. Le second semestre 2001 devrait tre consacr dfinir la mthode et les moyens mettre en uvre pour dployer la distribution des certificats dans lensemble de lorganisme. En quelques mots, la politique de certification prvoit de dlivrer des certificats pour toute personne travaillant dans une unit CNRS (pas uniquement aux agents CNRS) ou sur un projet CNRS, pour tout service rseau (serveur Web, routeur, ) dune unit, ventuellement pour des codes dvelopps dans les laboratoires (applets par exemple).Trois sous-autorits ont t cres : - Une autorit CNRS-Standard qui dlivre des certificats pour des usages courants, lautorit denregistrement (la personne qui dcide de dlivrer ou non un certificat) sera le directeur de lunit ou son reprsentant. - Une autorit CNRS-Plus qui dlivre des certificats pour des actes administratifs. Lautorit denregistrement pourrait tre le dlgu ou son reprsentant. Ces certificats pourraient tre stocks sur une carte puce, cette option est ltude. Cette autorit est galement utilise pour dlivrer les certificats des autorits denregistrement. - Une autorit CNRS-Projets pour des projets dure de vie limite, qui peuvent impliquer dautres organismes, chaque projet dpendant dune autorit fille et lautorit denregistrement tant le responsable du projet. Cest le cas par exemple de lautorit de certification SSI, sous-autorit de certification de lautorit CNRSProjets et qui peut dlivrer des certificats des coordinateurs ou des correspondants scurit informatique du CNRS pour des applications lies cette activit. Ceci est un vaste projet qui peut entraner une rvision complte de toutes les procdures administratives bases actuellement sur lutilisation du papier, avec des gains trs importants de productivit et defficacit si celles-ci basculaient en procdures lectroniques dmatrialises. Ce projet fait lobjet dune prsentation aux Journes JRES2001 : Mise en place progressive dune IGC au CNRS par Jean-Luc Archimbaud.

14 Annexes
14.1 Formation SIARS et travail collaboratif Pour rpondre au besoin de formation nous nous sommes poss la question comment utiliser et partager les connaissances et les comptences l o elles sont ? . Lorganisation humaine mise en place et tout particulirement le rseau des coordinateurs scurit a t la premire partie de la rponse, la seconde nous lavons trouv dans lutilisation des rseaux et applications scurises. Aprs avoir dcid que le travail serait collaboratif, les tapes suivantes ont permis dobtenir une premire version provisoire du support en janvier 2001 : - Runion des coordinateurs pour une prsentation du projet - laboration des listes de rdacteurs, relecteurs et intervenants - valuation du volume lignes des chapitres tant pour le support que pour les prsentations - valuation de la rpartition horaire entre les diffrents thmes abords - Finalisation du programme propos pour cette formation - Dfinition du planning pour la rdaction et la relecture - Rpartition dans les sous-groupes de rdacteurs des diffrents sujets aborder - Dfinition de modle de prsentation (feuille de style,) - Organisation de la relecture, de la concatnation des sous-chapitres - laboration du support provisoire par concatnation de tous les chapitres Pour raliser ce travail de mise en commun des comptences dun rseau humain, un espace scuris et une liste de diffusion avec certificats ont t utiliss. Les services de bases en scurit ont t mis en uvre : authentification, intgrit, confidentialit et non rpudiation ainsi que lutilisation des contrles daccs des ressources. Ces services sont rendus en utilisant un espace scuris accessible depuis le serveur de lUREC avec comme support technique : un serveur https (Apache + OpenSSL + ModSSL), des certificats X509 pour la gestion des clefs publiques des serveurs et des utilisateurs. Lespace de travail scuris sert galement pour la communication des supports de prsentation pour les sessions organises en rgion. Ces supports de prsentations sont soient ceux crs pour la formation des coordinateurs, soient spcifiques la rgion. Dans tous les cas, aucun modle na t impos laissant ainsi chacun le soin dutiliser le style le mieux adapt au thme expos. Cest la liste de diffusion CSEC, contrle par certificats CNRS-SSI, qui est utilise pour la communication. Ainsi lors de la rdaction du support, lensemble des coordinateurs sest trouv inform de lvolution de celuici et cest ce qui a conduit un certain nombre dentre eux tre volontaires pour la relecture des chapitres. Chacun sest trouv ainsi encore plus concern par la formation SIARS, le travail accompli jusqu ce jour est notable.

383

Environnements scuriss

14.2 Architecture scurise et filtres

384

Environnements scuriss