Mise en place d’une infrastructure et d’un service antivirus dédiés afin de prémunir Airbus des intentions malveillantes

Texte intégral

(1)Mise en place d’une infrastructure et d’un service antivirus dédiés afin de prémunir Airbus des intentions malveillantes Guerric Le Bozec. To cite this version: Guerric Le Bozec. Mise en place d’une infrastructure et d’un service antivirus dédiés afin de prémunir Airbus des intentions malveillantes. Cryptographie et sécurité [cs.CR]. 2013. �dumas-01304307�. HAL Id: dumas-01304307 https://dumas.ccsd.cnrs.fr/dumas-01304307 Submitted on 19 Apr 2016. HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.. L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés..

(2) CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL MIDI-PYRENEES ___________________. MEMOIRE présenté en vue d'obtenir le DIPLOME D'INGENIEUR CNAM. SPECIALITE : Informatique OPTION : Réseaux, Systèmes et Multimédia. par. Guerric LE BOZEC ___________________. Mise en place d’une infrastructure et d’un service antivirus dédiés afin de prémunir Airbus des intentions malveillantes Soutenu le 05 février 2013 _________________ JURY PRESIDENT : Monsieur Yann POLLET - Professeur des Universités - Cnam MEMBRES :. Monsieur Hadj BATATIA - Maître de Conférence - Cnam Monsieur Bertrand RAIFF - Maître de Conférence - Cnam Madame Caroline ST MARTIN - Back Office Security Service Manager - Airbus Monsieur Alan ZACCARDELLE - Program Manager for Security Tools & Solutions - Airbus.

(3) Remerciements. Je remercie Caroline ST MARTIN pour m’avoir confié la prise en charge de ce projet. Son encadrement, son aide et son soutien actif ont grandement contribué à la concrétisation de ce mémoire. Je remercie également Alan ZACCARDELLE pour m’avoir fait partager ses connaissances, sa vision et ses recherches sur la sécurité. Sa générosité, ses conseils, sa rigueur et son exigence ont été essentiels dans la réussite de ce projet. J’adresse mes remerciements à Jean-Jacques FOREST pour l’intérêt qu’il a porté à mon projet professionnel ainsi que pour son soutien et ses encouragements. Mes remerciements vont également à Christine LOIZELET et Evelyne SAINTSUPERY qui ont apporté leur avis et une vision extérieure lors de la rédaction de ce mémoire. Je souhaite remercier Joël DELOISON pour m’avoir permis d’intégrer la nouvelle offre de sécurité de Steria. J’ai ainsi pu trouver mon sujet de mémoire. Je remercie Monsieur Bertrand RAIFF pour ses nombreux conseils dans la rédaction de ce mémoire..

(4) Liste des abréviations DMZ : Demilitarized Zone, une zone démilitarisée, c’est un sous-réseau ouvert sur Internet et séparé du réseau local de l’entreprise par un pare-feu. EPO : McAfee ePolicy Orchestrator, console d’administration centralisée pour les produits McAfee. ICT : Information and Communication Technology, Technologies de l’information. LAN: Local Area Network, réseau local. LDAP: Lightweight Directory Access Protocol, protocole pour les systèmes d'annuaires. MOM : Minutes Of Meeting, résumé des actions et des décisions prises lors d’une réunion. ORS : Operation Requirement Sheet, document Airbus propre à une application qui liste les actions techniques à réaliser dans le cas d’un incident ou d’une demande. PDF : Portable Document Format est un format de fichier informatique créé par Adobe Systems. SASHA : Service Mode for Antivirus Solutions and Harmonised Architecture, projet d’harmonisation et de centralisation de la gestion de l’antivirus chez Airbus. SLA : Service-Level Agreement, accord contractuel sur le niveau du service rendu. SRS : Scheduling Requirement Sheet, documentation Airbus permettant la mise en place d’une sauvegarde spécifique pour les serveurs. STAMP : Standard Management and Process, guide de la gouvernance Airbus des standards. TRS : Tivoli Requirement Sheet, document Airbus qui prévoit une surveillance spécifique des serveurs ou à une application. VSE : McAfee VirusScan Enterprise, logiciel antivirus de McAfee..

(5) Glossaire Agent McAfee : logiciel client qui récupère les règles et les stratégies depuis le serveur ePolicy Orchestrator et les applique sur le système. Il récupère et installe les mises à jour et renvoie au serveur antivirus les évènements survenus sur le système. AVFiler : Serveur hébergeant l’antivirus spécialisé dans la protection des serveurs de fichiers (McAfee VirusScan Enterprise for Storage). Back Office : domaine qui gère tous les types de serveurs. Correctif / patch : mise à jour logicielle corrigeant une vulnérabilité ou un problème sur des systèmes. DAT : définition des virus contenant les dernières signatures virales pour l’antivirus McAfee. ePolicy Orchestrator : console d’administration centralisée pour les produits McAfee. ExtraDAT : nouvelles signatures virales permettant à l’antivirus de détecter et de supprimer un nouveau virus. Faux positif : détection erronée d’un fichier sain comme un virus. Front Office : domaine qui gère tous les types de postes de travail. INBT5 : chez Airbus, c’est le service qui a en charge d’assurer la transformation et la continuité de l’infrastructure du système d’information. IGXS : au sein de l’organisation Airbus, c’est le service qui a en charge de définir et d’appliquer les standards et les solutions de sécurité pour les technologies de l’information. NetApp : solution de stockage en réseau. Référentiel distribué (Distributed repositories) : serveur hébergeant un espace partagé qui permet aux systèmes gérés, d’accéder aux mises à jours des signatures antivirus, aux sources d’installation et aux correctifs des logiciels antivirus. Remedy : outil BMC Software pour la gestion du changement dans le système d’information. Rescue ePO : serveur applicatif de secours utilisé en cas de défaillance du serveur applicatif principal. Il permet de maintenir les systèmes avec la dernière mise à jour antivirus..

(6) Rescue ePO Database : serveur de base de données secondaire, configuré en miroir, qui peut relayer le serveur primaire de base de données. Il permet de maintenir la disponibilité de l’application ePolicy Orchestrator. Semaphore : outil pour la gestion des incidents dans le système d’information chez Airbus. Tivoli : logiciel utilisé pour la surveillance des systèmes informatiques. Virus : code malveillant.. 5.

(7) Table des matières Remerciements ...................................................................................................................... 2 Liste des abréviations ............................................................................................................ 3 Glossaire ................................................................................................................................ 4 Table des matières ................................................................................................................. 6 Introduction ........................................................................................................................... 7 I. Présentation du contexte ................................................................................................ 9 I.1 I.2. STERIA : SERVICE RIGHT SECURITY ................................................................................................. 9 AIRBUS : ICT .................................................................................................................................... 13. Mise en place de l’architecture antivirus dédiée ......................................................... 16. II. II.1 II.2. III. ANCIENNE ARCHITECTURE ......................................................................................................... 16 NOUVELLE ARCHITECTURE......................................................................................................... 19. Mise en place du service antivirus Back Office .......................................................... 24. III.1 III.2 III.3. CYCLE DE VIE DE LA DOCUMENTATION ...................................................................................... 24 PRODUCTION D’INDICATEURS ET DE RAPPORTS ......................................................................... 27 MISE EN PLACE D’UNE COMMUNICATION POUR LE SERVICE ..................................................... 34. IV Amélioration de la protection antivirale ...................................................................... 42 IV.1 IV.2 IV.3. V. RETOUR D’EXPERIENCE LORS DES CRISES VIRALES ................................................................... 42 MISE A L’EPREUVE DE LA PROTECTION ANTIVIRUS ................................................................... 46 OPTIMISATION ET SECURISATION DES REGLES DE PROTECTION ANTIVIRUS ............................ 60. Gestion des incidents dans le service .......................................................................... 67 V.1 V.2 V.3. INCIDENTS LIES AU FONCTIONNEMENT DE L’ANTIVIRUS ........................................................... 67 MISE EN PLACE D’ALERTES ET D’ACTIONS AUTOMATISEES....................................................... 75 PLANIFICATION DE SCANS PERIODIQUES .................................................................................... 79. VI Elaboration du catalogue de service ............................................................................ 83 VI.1 VI.2. RECENSEMENT DES DIFFERENTES ACTIONS REALISEES ............................................................. 83 TRADUCTION DE L’ACTIVITE EN MODE CATALOGUE ................................................................. 86. Conclusion ........................................................................................................................... 95 Bibliographie ....................................................................................................................... 97 Table des annexes .............................................................................................................. 100 Annexe 1 Rapport Back Office sur la solution antivirus ................................................... 101 Annexe 2 Stratégie antivirus sécurisée pour SharePoint ................................................... 117 Liste des figures ................................................................................................................. 120 Liste des tableaux .............................................................................................................. 122. 6.

(8) Introduction. Mettre en place une équipe dédiée aux serveurs et spécialisée dans la protection antivirale, c’est l’ambition du projet SASHA1. Pour atteindre ce but, il est nécessaire de repenser l’architecture des infrastructures utilisées, résoudre la problématique entre les besoins métiers du client et la limitation des risques, et aussi compléter la couverture antivirus. Ainsi, le problème réside dans la défaillance du processus de support antivirus pour les serveurs. Pour ces systèmes, il n’y a pas de surveillance ni d’interprétation de l’information venant de l’antivirus. L’absence d’actions préventives et correctives, l’insuffisance dans l’amélioration de la couverture antivirus et son évolution, représentent une vulnérabilité importante pour le système d’information. De plus, le problème constaté met aussi en évidence une faible réactivité en cas d’attaque virale. Ce mémoire porte sur l’analyse de ce problème de sécurité, la conception ainsi que la réalisation d’un système et d’un service antivirus dédiés aux serveurs. Comment construire un service antivirus dédié aux serveurs, autonome et indépendant de celui en charge des postes de travail? L’exigence d’un tel service est de protéger les systèmes gérés et de maintenir un niveau de protection équilibré à tout le parc serveurs. Un service qui prend en compte, s’adapte et répond efficacement aux contraintes métiers liées aux serveurs et aux applications hébergées. Pour le bon fonctionnement de ce service, je constate qu’il est indispensable de développer des procédures et des outils afin de contrôler régulièrement les divers fichiers présents dans le système d’information. Les contraintes de disponibilité des différents systèmes doivent être prises en compte pour éviter toute dégradation ou interruption de service. L’élaboration régulière de tableaux de bord, d’états sur l’ensemble du parc des serveurs, permet de mettre en évidence les avancées et les points à améliorer concernant la couverture antivirale. Ces rapports doivent montrer le travail accompli et assurer le suivi de la mise en conformité des systèmes au regard de la protection antivirus. Je montre que ces. 1. Service Mode for Antivirus Solutions and Harmonised Architecture. 7.

(9) indicateurs sont des outils de communication nécessaires pour le pilotage de l’activité du service. Suite aux différentes attaques virales, je présente les retours d’expériences qui ont conduit à la mise en place d’un service antivirus, dédié aux serveurs. La mise en place de ce service est ainsi devenue une évidence chez Airbus. Ces attaques ont démontré, la nécessité d’une grande réactivité pour limiter les dégâts potentiels. Je mets aussi en évidence qu’une équipe consacrée à la protection antivirale des serveurs est le moyen le plus efficace pour mener un diagnostic, des contre-mesures et des actions de corrections dans les meilleurs délais. Dans des situations de crise, la réactivité est un facteur déterminant pour limiter les conséquences pour l’entreprise. Pour prévenir et se protéger aux mieux des futures attaques virales, je montre que le service doit améliorer la protection des serveurs en concevant des stratégies et des règles antivirus qui allient performance et sécurité. Pour cela, il faudra limiter les exceptions aux règles de sécurité, et ainsi, réduire la prise de risque au strict nécessaire tout en assurant une gestion rigoureuse et documentée des exceptions implémentées. De plus, le service antivirus devra disposer d’une gestion des incidents, réactive et efficace pour apporter une réponse adéquate aux divers problèmes qui peuvent survenir. La priorité est d’éviter l’apparition d’une situation de blocage pour réduire l’impact métier. Enfin, je traite de l’étape de transformation du service qui consiste à auditer notre manière de travailler pour réussir à recenser toutes les actions exécutées pour les traduire en famille de prestations facturables au client. Cette transformation nécessite de décomposer et de classifier les différentes tâches accomplies dans l’activité de ce service. Cette analyse débouchera sur la création d’un catalogue de services, recensant les différentes prestations offertes au client.. 8.

(10) I Présentation du contexte I.1 Steria : Service Right Security Steria est une société de services en ingénierie informatique (SSII) avec 20 000 collaborateurs répartis dans 16 pays. Steria délivre des services qui s’appuient sur les nouvelles technologies et qui permettent aux administrations et aux entreprises d’améliorer leur efficacité et leur rentabilité. Créé en 1969, Steria est présent en Europe, en Inde, en Afrique du Nord et en Asie du Sud-Est. Le Groupe Steria a réalisé un chiffre d’affaires de 1,75 milliard d’euros en 2011. En 2012, Steria lance la première offre de sécurité de bout en bout externalisée selon un modèle de tarification à l’usage. Dans ce service, Steria regroupe des experts autour de la sécurité : des ingénieurs et des consultants. Steria met à la disposition du client, à la demande, un accès à un centre d’expertise que le client va pouvoir utiliser au fur et à mesure de ses besoins. Le service Right Security fournit une offre globale de services de sécurité et de gouvernance des risques, basée sur la méthodologie IPPCoR :. - Risk Identification : Identifier les risques - Prevention Planning : Organiser la prévention - Protection Deployment : Déployer les protections - Control and Management : Vérifier et superviser - Reporting and Measurement : Informer et Mesurer. Figure 1: Méthodologie IPPCoR. 9.

(11) IPPCoR est une méthodologie développée par Steria qui est basée sur la norme ISO 270012 et sur les principes du CISM (Certified Information Security Manager). Elle donne un cadre aux fonctions de sécurité en définissant des services adaptés aux besoins des clients. Steria apporte son expertise de la sécurité combinée aux meilleures pratiques industrielles liées à l’automatisation des outils et à une forte réutilisation pour permettre à ses clients d’optimiser la valeur de leurs investissements en matière de sécurité. Au sein du service Right Security, j’ai intégré l’équipe Produits dirigée par Jean Jacques Forest. Notre équipe gère et recommande aux clients, des configurations sécurisées pour les infrastructures et les logiciels de sécurité tels que : . les solutions McAfee : VirusScan Enterprise, VirusScan Enterprise for Storage, VirusScan Enterprise for use with the SAP NetWeaver platform, Security for Microsoft SharePoint, Host Intrusion Prevention, Ensure Web Interoperability for Customers, ePolicy Orchestrator ;. . la solution de chiffrement Arkoon : Security Box ;. . la solution Microsoft de protection de données : BitLocker Drive Encryption ;. . et aussi celle développée par Sophos : Safeguard Easy.. L’activité de l’équipe Produits est centrée sur la protection des actifs (serveurs et postes de travail) et sur le chiffrement des données. Ce service répond aux besoins suivants:. 2. . études d’évolutions et d’améliorations des solutions existantes ;. . conception de nouvelles solutions ;. . réalisation de maquettes comparatives pour apporter une aide au choix ;. . une expertise sur des problèmes techniques et d’architectures ;. http://www.iso.org/iso/fr/catalogue_detail?csnumber=42103. 10.

(12) . conduite de projet : mise en production d’une nouvelle application de sécurité.. Notre équipe fait partie intégrante de l’organisation mise en place pour le service Right Security :. 11.

(13) Figure 2: Organigramme du service Right Security. Au sein de l’équipe Produits, je suis en charge de la partie opérationnelle des outils de sécurité présents sur les serveurs d’Airbus. C'est dans ce cadre que je mène le projet de mise en place d’une infrastructure et d’un service antivirus dédiés pour ce client.. 12.

(14) I.2 Airbus : ICT Airbus est l'un des principaux avionneurs mondiaux, il capte régulièrement environ la moitié de toutes les commandes d'avions de plus de 100 places. La gamme d’avions chez Airbus couvre un éventail complet. de. quatre. familles. d'appareils allant du monocouloir de 100 sièges au plus gros avion civil au monde, l'A380 à double pont. ainsi. que. des. avions. militaires. En 2011, Airbus a atteint un chiffre d'affaires autour de 33 milliards d’euros et assuré le. Figure 3: Ligne d'assemblage final de l'A380 à Toulouse. support de plus de 7 000 avions actuellement en service auprès de plus de 300 opérateurs sur les cinq continents. Airbus emploie quelque 55 000 personnes de plus de 100 nationalités. Airbus est une filiale du groupe industriel EADS3. Au sein du pôle ICT4, le service IGXS5 a en charge la conception de l’architecture des solutions de sécurité, la définition des standards de sécurité et le contrôle de leur bonne application. Le service INBT56 assure la transformation et la continuité de l’infrastructure du système d’information. Au travers de l’offre Right Security Services, Steria apporte à ces deux services son expertise : . pour IGXS : développer des axes d’amélioration pour renforcer le niveau de sécurité et veiller à l’application des standards.. . pour INBT5 : augmenter la couverture des outils de sécurité exploités par le service et apporter un support opérationnel pour l’application des standards de sécurité.. 3. European Aeronautic Defence and Space Company Information and Communication Technology : Technologies de l’information 5 Service standards et solutions de sécurité 6 Transformation et continuité du service 4. 13.

(15) . /DJRXYHUQDQFHGHODVpFXULWpHWOHS{OH,QIUDVWUXFWXUHGHVV\VWqPHVVRQWOLpVGDQVOH V\VWqPHG¶LQIRUPDWLRQG¶$LUEXV. )LJXUH2UJDQLJUDPPHGHVVHUYLFHV,*;6HW,1%7. 'DQVOHFDGUHGHFHSURMHWPRQU{OHHVWGHPHWWUHHQSODFHXQVHUYLFHRSpUDWLRQQHO GpGLpjODVROXWLRQDQWLYLUXVSRXUOHVVHUYHXUV&HQRXYHDXVHUYLFHVHUDSLORWpSDU,1%7 3RXUFHODMHGRLVUHVSHFWHUOHVFRQWUDLQWHVGpILQLHVSDU,*;6 DUFKLWHFWXUHHWVWDQGDUGVGH VpFXULWp

(16) HWIRXUQLUXQVXSSRUWSRXUOHVDFWLRQVjUpDOLVHUSDU,1%7 $LQVLSRXUOHFRPSWHG¶,*;6M¶DLHQFKDUJHGH x GpILQLUHWVpFXULVHUOHVVWUDWpJLHVDQWLYLUXVVSpFLILTXHVDX[VHUYHXUV x LGHQWLILHUHWpUDGLTXHUOHVILFKLHUVPDOYHLOODQWVVXUOHVVHUYHXUV 3RXU,1%7PRQU{OHHVWGH x PHWWUH HQ SODFH OHV SURFpGXUHV HW OD FRPPXQLFDWLRQ GX QRXYHDX VHUYLFH DQWLYLUXV x JpUHU OHV LQFLGHQWV OLpV j OD FRQILJXUDWLRQ HW DX[ LQWHUDFWLRQV GH O¶DQWLYLUXV VXUOHVVHUYHXUV. . .

(17) . définir un catalogue de services ;. . faire évoluer l’architecture en fonction du cycle de vie logiciel antivirus ;. . appliquer la démarche d’amélioration continue du service ;. . mettre en place des rapports hebdomadaires et mensuels ;. . prévoir les augmentations de capacités de l’infrastructure antivirus.. Le service aura la responsabilité d’assurer la protection antivirus sur les serveurs et les systèmes de partage de fichiers. Son périmètre sera transnational, il gèrera les configurations de l’antivirus pour les sites Airbus suivants : . Allemagne : Brême, Buxtehude, Fuhlsbüttel, Hambourg, Nordenham, Stade et Varel.. . Australie : Sydney.. . Chine : Hong Kong, Pékin et Tianjin.. . Emirats Arabes Unis : Dubaï.. . Espagne : Getafe, Puerto Real et Séville.. . France : Méaulte, Nantes, Saint-Nazaire et Toulouse.. . Japon : Tokyo.. . Inde : Bangalore.. . Irlande : Dublin.. . Royaume Uni : Broughton et Filton.. . Russie : Moscou.. 15.

(18) II Mise en place de l’architecture antivirus dédiée La solution antivirus déployée chez Airbus est celle de l’éditeur McAfee qui comprend une application serveur et une application cliente. Le logiciel serveur (ePolicy Orchestrator) propose une console d’administration centralisée pour gérer les stratégies déployées, les versions des logiciels McAfee utilisées et les mises à jour. L’application cliente se charge de récupérer et d’appliquer les règles sur le système protégé. Cette architecture est sous la responsabilité d’IGXS.. II.1 Ancienne architecture Il existait chez Airbus plusieurs plateformes antivirus dans les différents sites Airbus : . en Allemagne : une plateforme pour les contrôleurs de domaines, une autre pour les serveurs et les postes de travail des sites allemands ;. . en Chine : un serveur antivirus pour les serveurs et les postes de travail présents sur les sites en Chine ;. . en France : pour les serveurs et les postes de travail. Le périmètre de cette plateforme est plus important que les autres consoles locales car elle gère aussi des systèmes présents sur d’autres sites Airbus ;. . au Royaume Uni : pour les serveurs et les postes de travail des sites de Filton et Broughton.. La gestion de ces plateformes était confiée aux équipes de chaque site. Il n’y avait pas de concertation entre les différentes équipes sur les règles et les exclusions appliquées sur chaque site. Les équipes suivaient leurs propres processus de validation. Il n’existait pas de standard antivirus unique, centralisé et global à tous les sites Airbus. Chaque plateforme antivirus récupérait les mises à jour des signatures antivirales (DAT) mise à disposition tous les jours par McAfee. La responsabilité revenait ainsi à chaque site de maintenir le niveau de protection de leurs systèmes. Les systèmes Airbus avaient en fait des protections antivirus hétérogènes.. 16.

(19) Figure 5: Ancienne architecture antivirus chez Airbus [1]. De plus, les postes de travail et les serveurs étaient gérés à partir des mêmes consoles d’administration antivirus. Cette gestion unique, pour tous les types de systèmes, pose trois problèmes majeurs : . en cas d’indisponibilité de la plateforme antivirus (problème matériel, attaque virale extérieure, instabilité de la base de données), tous les systèmes sont alors impactés par cet incident ;. . aucune redondance n’est prévue pour assurer la continuité du service antivirus : il n’y a pas de plateforme de secours dans chaque site ; 17.

(20) . en cas d’erreur de manipulation de la part d’un administrateur de la solution ePolicy Orchestrator, il existe alors un risque d’interrelation de la gestion des configurations antivirus pour ces deux types de matériels.. Ces problèmes justifient d’une part la centralisation de l’administration antivirus des systèmes Airbus pour harmoniser toutes les règles antivirus, et d’autre part, la séparation de l’administration des deux types de systèmes (postes de travail et serveurs) dans des consoles antivirus séparées. La redondance de ces deux plateformes devient nécessaire pour assurer le service même en mode dégradé. De plus, la séparation du périmètre de l’administration antivirus permet d’envisager la possibilité de mettre en place une solution antivirus différente sur les postes de travail ou sur les serveurs. Avec deux logiciels antivirus distincts, l’efficacité de ces solutions sera mis en concurrence entre elles. En effet, les différences dans les détections virales mettront en évidence les virus qui échappent à l’un des deux moteurs antivirus mais pas à l’autre. La plateforme antivirus située en France, est gérée par une équipe dédiée aux postes de travail. Il n’y avait pas d’équivalent pour les serveurs. Cependant, une équipe système peut intervenir sur cette plateforme mais seulement après avoir reçu une demande de changement qui doit être documentée et validée. La lenteur de ce type d’intervention n’est pas adaptée en cas d’incident ou lors d’une crise virale. Ainsi, il n’y avait pas de contrôle régulier concernant le taux de couverture antivirus ni de surveillance du nombre de détections virales pour les serveurs. Le projet SASHA va donc réduire le nombre de plateformes antivirus présentes dans les différents sites Airbus et uniformiser les différentes règles et les versions de l’antivirus pour l’ensemble du parc Airbus.. 18.

(21) II.2 Nouvelle architecture La nouvelle architecture antivirus a été définie dans le dossier d’architecture SASHA [1]. Elle introduit la stricte séparation entre les deux types de systèmes gérés (serveurs et postes de travail) dans une organisation globale chez Airbus. Ces deux types de systèmes ont désormais leurs propres infrastructures antivirus dans les environnements de test, de validation et de production. Elles sont totalement indépendantes entre elles. La nouvelle architecture réduit le nombre de plateformes existantes en centralisant l’administration antivirus de tous les systèmes Airbus sur uniquement deux plateformes : . ePO Front Office : une console d’administration pour tous les postes de travail Airbus : c’est l’infrastructure antivirus avec le périmètre le plus étendu (celle située en France) qui est choisie;. . ePO Back Office : console d’administration dédiée aux serveurs Airbus : une nouvelle infrastructure antivirus est alors créée.. Figure 6: Architecture antivirus actuelle chez Airbus [1]. 19.

(22) Les administrateurs de ces deux plateformes antivirus, sont différents. La responsabilité des deux consoles incombe à des services distincts. Il n’y a plus d’interrelation entre la gestion des configurations antivirus des serveurs et des postes de travail. Les liens sont ainsi coupés et les conséquences des changements sont limitées aux périmètres de la console concernée. En local, sur chaque site Airbus, il y a dorénavant au moins un serveur qui sert de référentiel distribué pour la réplication des mises à jour antivirus. Ces mises à jour sont déposées par les deux consoles antivirus dans des espaces distincts. L’autre avantage des référentiels distribués est de soulager le serveur principal. Plus il y a un nombre important de systèmes gérés, plus le serveur ePolicy Orchestrator sera sollicité. Les serveurs distribués permettent ainsi de décharger le serveur ePO de la tâche journalière de mise à jour. Un fois que l’agent McAfee est installé sur les systèmes protégés, il vérifie régulièrement, sur les référentiels distribués, la présence d’une nouvelle mise à jour, la télécharge et l’applique.. 20.

(23) Figure 7: Stratégie en cas de défaillance applicative [1]. L’auteur Tamara Dean recommande [2] en complément de la protection antivirus, de mettre en place une tolérance aux pannes qui est un facteur clé pour garantir la disponibilité et l’intégrité des données. Le concept de basculement (fail-over) peut s’appliquer à l’architecture antivirus. Désormais, la continuité du service antivirus est renforcée par deux serveurs de secours (Rescue ePO). Ainsi, en cas d’indisponibilité d’un des deux serveurs applicatifs (ePO Back Office et Front Office), les deux serveurs de secours peuvent prendre le relais. La configuration d’un serveur applicatif de secours est similaire au serveur principal, à l’exception d’un point : il ne gère pas la configuration des systèmes clients. En effet le rôle du serveur applicatif de secours, est de maintenir la mise à disposition des mises à jour antivirus sur tous les serveurs référentiels distribués. Les serveurs et les postes de travail Airbus disposeront d’un antivirus à jour malgré l’indisponibilité des serveurs antivirus principaux.. 21.

(24) Figure 8: Stratégie en cas de défaillance du serveur de base de données [1]. Autre amélioration introduite par cette architecture, la mise en place de serveurs secondaires de base de données (Rescue SQL). Ils sont configurés en miroir avec le serveur de base de données principal. Dans ce scénario, ce n’est plus le serveur applicatif ePolicy Orchestrator qui est visé mais le serveur de base de données qui lui est rattaché. Dans l’hypothèse d’une indisponibilité de la base de données ou du serveur hébergeant la base, le serveur applicatif peut être réorienté manuellement vers le serveur de base de données secondaire. Ainsi, les administrateurs antivirus pourront continuer à utiliser la console centralisée le temps du retour de la base de données hébergée par le serveur primaire. Pour les plateformes antivirus présentes dans les différentes DMZ, la nouvelle architecture aura un impact limité : pas de réduction du nombre de serveur antivirus mais elles seront rattachées à la plateforme ePO Back Office. Comme il n’y a que des serveurs dans les consoles ePO en DMZ, le rattachement est cohérent et consolide la séparation des deux plateformes antivirus. 22.

(25) Dès la livraison de la plateforme antivirus Back Office par le projet SASHA, INBT5 confie à Steria la mise en place, le paramétrage et la gestion du nouveau service antivirus dédié.. 23.

(26) III Mise en place du service antivirus Back Office Chez Airbus, les opérations menées par ce nouveau service sont placées sous la responsabilité de Caroline ST Martin (INBT5). Ainsi, toutes les étapes de ce projet sont soumises à son contrôle et sa validation. Le service antivirus pour les serveurs devra maintenir sa documentation technique au fil des évolutions. Il mettra en place différents états pour mettre à disposition du client, une vision claire sur les activités du nouveau service. Il devra se doter d’une communication compréhensible de tous les autres acteurs du système d’information.. III.1 Cycle de vie de la documentation Un des problèmes à résoudre est la gestion documentaire. Le service antivirus Back Office doit maintenir au fil des évolutions les documents qui s’appliquent à l’application ePolicy Orchestrator. Ce sont des documents utilisés par les équipes systèmes en charge des serveurs chez Airbus. Pour le service antivirus, nous utilisons trois types de document. Ils ont des objectifs distincts : . Operation Requirement Sheet (ORS): c’est le recueil des besoins opérationnels pour une application donnée. Les actes techniques demandés aux équipes opérationnelles doivent y être décrits : les conditions de déclenchement, une description détaillée de l’acte et les vérifications nécessaires. Un ORS est soumis préalablement à la validation des équipes systèmes Airbus. Après cette validation, le document s’impose à ces équipes : l’ORS est mis en production.. . Tivoli Requirement Sheet (TRS) : dans ce document, nous devons indiquer les surveillances et les envois d’alerte à mettre en place pour tous les serveurs de l’architecture antivirus : l’état du serveur, l’espace disque, le démarrage des services nécessaires à l’application, etc... Pour chaque surveillance, une liste d’action est donnée. Ces actions peuvent être liées à celles décrites dans l’ORS.. . Scheduling Requirement Sheet (SRS) : ce document doit être renseigné pour y spécifier les sauvegardes nécessaires pour l’application antivirus. Les données sur les serveurs ainsi que les bases de données sont concernées. Il faut détailler à quelle fréquence la sauvegarde doit être réalisée et où se trouvent les zones à sauvegarder.. 24.

(27) Lors de la mise en place du service antivirus Back Office, il a été nécessaire de reprendre ces documents et de vérifier que les besoins du nouveau service étaient correctement spécifiés. Des corrections ainsi que des ajouts, ont été apportés lors de l’entrée en fonction de nouveaux serveurs et lors de montées de version de l’application antivirus. Deux fonctionnalités ont dû être décrites et intégrées à cette documentation pour assurer la continuité du service rendu : la procédure d’activation des serveurs applicatifs de secours (Rescue ePO) et des serveurs secondaires de base de données (Rescue SQL). Ainsi, pour intégrer ces deux fonctionnalités dans le périmètre des équipes opérationnelles, l’ORS a été enrichi. L’architecture et le fonctionnement y sont documentés. Selon la nature de l’indisponibilité, les équipes demandent l’autorisation d’activer l’une ou l’autre infrastructure de secours. C’est l’entité IGXS, en tant que responsable de l’application antivirus, qui donne son accord. A partir de ce moment, les équipes systèmes doivent suivre les instructions contenues dans l’ORS. Il y est décrit précisément toutes les étapes à suivre pour activer la solution de secours et pour s’assurer qu’elle est opérationnelle. Une fois l’incident résolu, l’opération inverse est aussi prévue dans la documentation opérationnelle. Les intervenants systèmes doivent neutraliser le serveur de secours et remettre en service le serveur principal. Après la prise en compte de ces fonctionnalités de secours par les équipes systèmes, nous avons mis en place tous les 6 mois, une simulation d’une panne système. Ainsi régulièrement, les équipes systèmes déroulent complètement les procédures prévues pour ces fonctionnalités de secours. Comme ils éprouvent la documentation, ils remontent les problèmes rencontrés et les améliorations souhaitées. La documentation est modifiée en conséquence, si nécessaire. De plus, ces exercices permettent de familiariser les équipes avec ce type de procédure. Ainsi en cas de panne réelle, la réactivité des équipes sera optimisée afin de réduire le temps d’indisponibilité de l’infrastructure antivirus. Lors de l’entrée d’un nouveau logiciel dans le périmètre de ce service, les documentations techniques sont délivrées par les équipes projets. Ces documentations font partie intégrante de la procédure de recette du nouveau logiciel. Elles doivent être suffisantes pour réaliser l’exploitation et les actions liées à ce nouveau logiciel. Donc, le service Back Office émettra un avis concernant le niveau des documentations techniques livrées. De plus, ces documentations sont indispensables pour transmettre les actes à. 25.

(28) réaliser entre les différents intervenants et surtout de pouvoir reconstruire les paramétrages en cas de besoin. La gestion de la documentation au sein du service est impérative pour conserver la maîtrise de l’architecture (mise en place de surveillances et de sauvegardes) et pour assurer le service rendu (documentations techniques).. 26.

(29) III.2 Production d’indicateurs et de rapports Le service antivirus Back Office se doit de disposer de tableaux de bord pour pouvoir montrer une vision précise de l’état de la protection antivirale sur l’ensemble du parc des serveurs Airbus. Ces indicateurs doivent être pertinents, ainsi, les responsables clients disposeront de l’état réel de la protection de leurs serveurs face aux attaques virales. Il est nécessaire de maîtriser le parc des serveurs du client pour mettre en relief les axes d’améliorations possibles. Les avantages liés aux indicateurs sont présentés par Patrick Boulet[3] et selon l’auteur, les tableaux de bord de sécurité permettent de : . mieux piloter l’application de la politique de sécurité ;. . mieux constater les écarts par rapport aux objectifs ;. . mieux communiquer vers la direction générale mais aussi vers les services opérationnels.. Le concept d’indicateur est défini dans la norme ISO/CEI 27001 7, qui utilise le principe du PDCA (Plan-Do-Check-Act) : planifier, réaliser, contrôler et ajuster. Pour Alexandre Fernandez-Toro [4], les tableaux de bord doivent offrir une vision claire et synthétique et ils doivent aussi mettre en évidence l’état des lieux dans les domaines clés de la sécurité. Les tableaux de bord sont aussi couverts par la norme ISO/CEI 270028. Un travail a été fait avec le client pour formaliser et structurer ces indicateurs dans des rapports qui respectent les modèles utilisés chez Airbus et répondent à ses besoins. Le rapport Back Office sur la solution antivirus9 a été mis en chantier dès le début du projet (deuxième trimestre 2011). Le but de ce rapport est de proposer une vue qui traduit fidèlement l’activité du service antivirus Back Office et la situation de la protection antivirale. Le rapport se présente sous la forme d’un fichier Microsoft PowerPoint, et il est projeté et présenté lors de la réunion hebdomadaire avec le client.. 7. http://www.iso.org/iso/fr/catalogue_detail?csnumber=42103 http://www.iso.org/iso/fr/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50297 9 Cf. Annexe n°1, Back Office Reporting for Antivirus Solution (McAfee) 8. 27.

(30) Les différents états et indicateurs se basent sur l’activité de la semaine qui précède celle du rapport. Le client exige que toutes les semaines, un rapport soit produit. Un cahier des charges est alors donné : une mise en page adéquate, une présentation soignée, la fréquence de sortie, les indicateurs requis. Au fil des livraisons, le rapport évoluera en qualité et s’étoffera de nouveaux états en fonction des évolutions, de l’activité et des nouveaux projets. Les premières moutures du rapport étaient composées de 3 pages comprenant les indicateurs suivants : . un suivi des changements et des incidents : leur état d’avancement y est décrit ;. . les. risques. sur. l’obsolescence. de. l’infrastructure antivirus : le client est alerté sur la fin de support des versions des produits McAfee qu’il utilise ; . les résultats des détections de virus sur l’ensemble des serveurs gérés ;. . Figure 9: Page de garde du rapport Back Office sur la solution antivirus (semaine 14, 2011). un état de la couverture transnationale de la protection antivirale: nombre total de serveurs protégés ;. . la répartition des versions installées du logiciel antivirus sur l’ensemble du parc ;. . le taux de déploiement de la dernière mise à jour antivirus ;. . le récapitulatif des versions des produits McAfee qui sont conformes aux exigences de la sécurité Airbus (IGXS) : les versions standards et celles qui sont obsolètes ;. . le nombre de serveurs de fichiers couverts par l’antivirus spécialisé dans la protection des systèmes de stockage de données. Ce sont les serveurs de fichiers NetApp, solution propriétaire qui nécessite un composant antivirus spécifique : McAfee VirusScan Enterprise for Storage.. L’élaboration des premiers rapports a mis en évidence la difficulté de respecter l’exigence d’une sortie hebdomadaire. En effet, les rapports ultérieurs à ce premier rapport, n’ont couvert que les semaines 15, 17, 18, 22, 24 et 28. 28.

(31) Les principales difficultés venaient de l’absence d’automatisation dans la génération du rapport, mais aussi d’un manque de réutilisation et d’une mauvaise planification. Selon Patrick Boulet [3], les informations nécessaires pour construire les tableaux de bord de la sécurité doivent être facilement extractibles et les résultats reproductibles. Un travail a été réalisé pour réduire cette charge de travail. L’accent a été porté sur l’automatisation et la réutilisation pour la construction du rapport antivirus Back Office: . automatisation de l’extraction des données depuis la console ePolicy Orchestrator : utilisation de requêtes formalisées et création de tâches automatisées et récurrentes ;. . transformation du fichier de données en un modèle préconfiguré ;. . création de lien entre le fichier de données et le rapport final pour la prise en compte automatique des nouvelles données : rafraîchissement des états. C’est à partir de la semaine 28 de l’année 2011, que le rapport Back Office a enfin. couvert toutes les semaines. L’effort d’industrialisation du rapport a aussi permis de confier son élaboration à une autre équipe chez Steria. La charge de travail a ainsi pu être distribuée entre les différentes équipes (ingénieurs et techniciens). Suite à l’automatisation et à la réutilisation de modèles, mon rôle s’est limité à vérifier, finaliser et présenter le rapport. Dans sa forme actuelle, le rapport Back Office sur la solution antivirus n’évolue que très rarement. Il comporte désormais 12 pages avec les indicateurs suivants : . un. suivi. des. changements. et. des. incidents ; . un suivi des incidents spécifiques à l’antivirus pour les serveurs de fichiers;. . les. risques. et. une. prévision. sur. l’évolution de l’infrastructure : prévision concernant l’entrée en production d’un nouveau logiciel de sécurité, ou d’une migration vers une version supérieure ;. 29. Figure 10: Page de garde du rapport Back Office sur la solution antivirus (semaine 41, 2012).

(32) . les détections de virus par le scan antivirus à l’accès : le nombre de souches virales détectées par l’antivirus est représenté, ainsi. que. les. serveurs. impactés. (classement reprenant les dix serveurs ayant le plus de détections virales) ; . l’état du déploiement de la dernière signature antivirus sur l’ensemble des serveurs gérés par la solution antivirus (figure 11) ;. . Figure 11: Etat du déploiement des signatures antivirus. les détections de virus par le scan à la demande : un scan antivirus est programmé sur les serveurs présents dans le classement des dix serveurs les plus infectés de la semaine précédente. Cet indicateur reprend le résultat des scans programmés ;. . des. indicateurs. pour. les. serveurs. de. messagerie : les virus trouvés sur ces serveurs y sont reportés ainsi que le taux d’application des signatures virales et le nombre de serveurs de messagerie gérés par l’infrastructure antivirus ; . Figure 12: Etat sur les détections de virus. des indicateurs pour les serveurs de fichiers : ils portent sur les virus trouvés, le taux de serveurs avec un antivirus à jour et enfin les dix serveurs de fichiers les plus infectés ;. . Etats sur les détections de virus par le scan à la demande sur les serveurs de fichiers : régulièrement des. scans. antivirus. contrôlent. l’ensemble des fichiers présents sur ces serveurs. Ce rapport reprend les résultats de ces scans ;. Figure 13: Liste des virus trouvés sur les serveurs de fichiers. 30.

(33) . une liste exhaustive de l’ensemble des virus détectés (figure 13) : les noms des souches virales sont indiquées ainsi que le nombre de fois qu’elles ont été détectées ;. . l’état de la couverture transnationale de la protection antivirus: sur le réseau local (figure 14) et sur les différentes DMZ ;. . la. répartition. des. versions. installées du logiciel antivirus sur l’ensemble du parc serveurs ; . le récapitulatif des versions des produits. McAfee. qui. sont. conformes aux exigences de la gouvernance. sécurité. Figure 14: Couverture de la console Back Office pour sites Airbus. Airbus. (IGXS) ; . une représentation de l’avancement de la couverture antivirus pour les serveurs de fichiers ;. . une liste de serveurs non conformes par rapport à l’antivirus : ce sont des serveurs qui ont un agent McAfee ou un antivirus avec une version obsolète ;. . Figure 15: Versions des produits McAfee validées par IGXS. un récapitulatif des déploiements de mises. à. jour. urgentes. pour. l’antivirus :. régulièrement des souches virales sont repérées sur les serveurs mais ne sont pas détectées par l’antivirus McAfee. Pour y remédier, le support McAfee fournit à notre demande une mise à jour spécifique (ExtraDAT) pour compléter la base de signature virale (DAT) de l’antivirus.. Figure 16: Etat sur la conformité des serveurs par rapport à l'antivirus. Un autre rapport sur l’activité antivirus est réalisé pour le pôle ICT: des indicateurs antivirus intègrent le tableau de bord ICT mensuel qui permet à la gouvernance ICT de 31.

(34) suivre l’activité globale Back Office. Il doit donc être livré tous les mois. Nous disposons d’un espace limité pour réaliser ce rapport : les différents états sur l’activité du service antivirus Back Office doivent tenir en une seule page. En effet, cette page d’indicateurs devra intégrer un rapport global (INB Flash Report) sur toute l’activité du département INB : chaque service dispose d’une page. Pour ce tableau de bord mensuel, nous avons sélectionné les indicateurs les plus importants pour donner une vue globale de l’activité. Comme l’espace est limité, ce rapport ne peut pas descendre au même niveau de détail que le rapport hebdomadaire. Les indicateurs sélectionnés sont : . l’état du déploiement de la dernière signature antivirus sur l’ensemble des serveurs gérés par la solution antivirus. C’est une réutilisation du même état qui est présent dans le rapport hebdomadaire ;. . un graphique (figure 17) reprenant le nombre de menaces détectées sur une échelle glissante d’une année ;. Figure 17: Nombre de détections de fichiers malveillants sur une année glissante. . l’état de la couverture transnationale de la protection antivirus (figure 18): il diffère légèrement de celui du rapport Back Office car il regroupe dans le même graphique, les serveurs qui sont sur le réseau local et en DMZ ;. 32.

(35) Figure 18: Couverture de la console Back Office en LAN & DMZ. . un graphique (figure 19) représentant le nombre de déploiement de mises à jour urgentes pour les signatures antivirus (ExtraDAT).. Figure 19: Graphique représentant le nombre de déploiements urgents de mises à jour ExtraDAT. L’élaboration de ses différents rapports a permis de mettre en place une méthode pour répondre plus rapidement aux nouvelles demandes du client. En effet, ces demandes portent souvent sur une partie plus spécifique : une vue plus générale ou plus précise. Nous pouvons ainsi généraliser la méthode d’élaboration des états sur ces nouvelles demandes en réutilisant le travail de collecte déjà fait. Cela permet un gain de temps et donc la réponse à la demande est plus rapide, ainsi qu’une plus grande cohérence entre les différents tableaux de bord présentés au client. De plus, l’organisation du travail à accomplir entre les différents acteurs (ingénieurs et techniciens) contribue à une meilleure distribution des tâches et au respect des délais pour le client.. 33.

(36) III.3 Mise en place d’une communication pour le service Pour accompagner le changement, une communication doit être réalisée à l’attention des autres acteurs du système d’information. Elle permet de guider la communauté pour utiliser le nouveau système mis en place pour les serveurs. Lors d’un changement, la communication entre les différents services, est importante pour une organisation. Elle permet d’anticiper les problèmes et de désigner un point de contact unique. Dans ce domaine, la démarche est de communiquer sur un changement pour avertir et transmettre des informations concrètes sur ce qui est modifié ou ajouté. Mais aussi, la communication est faite sur la planification et sur les conséquences éventuelles à l’égard des systèmes et des applications. Ensuite, l’intérêt est aussi de proposer un point de contact unique pouvant répondre aux besoins spécifiques et aux problèmes éventuels. McAfee publie régulièrement des patchs et des nouvelles versions de ses produits. Il arrête aussi le support des versions plus anciennes de ses produits. Chez Airbus, l’infrastructure et les applications antivirus doivent être maintenues à niveau pour conserver le support de l’éditeur. A cela s’ajoute le déploiement occasionnel de signatures virales complémentaires. Ainsi, les changements pouvant être planifiés sont les suivants : . l’installation d’une version supérieure ou d’un patch pour les applications de l’infrastructure antivirus : McAfee ePolicy Orchestrator et VirusScan Enterprise for Storage. Ce type de modification impacte les serveurs de l’infrastructure antivirus et peut avoir une répercussion sur la disponibilité du service rendu par cette infrastructure ;. . le déploiement d’une nouvelle version ou de patchs pour la solution antivirus installée en local sur tous les serveurs chez Airbus : l’agent McAfee et VirusScan Enterprise. Ce type de changement peut avoir un impact significatif sur les performances des serveurs touchés et sur les disponibilités des applications métiers présentes sur ces serveurs. Même si dans la majorité des cas, un redémarrage n’est pas nécessaire, une montée de version de l’antivirus peut provoquer des interactions avec d’autres applications ;. . le déploiement d’une mise à jour antivirale complémentaire (ExtraDAT) en urgence : lorsqu’un virus est trouvé sur un système mais que l’antivirus ne 34.

(37) le détecte pas, il est alors nécessaire de déployer un complément de signatures virales. Suite à cet ajout, l’antivirus est capable de détecter, corriger et supprimer la menace. De même, on déploie une mise à jour antivirale pour corriger un faux positif : lorsqu’un fichier légitime est détecté comme un virus. Lors de la montée de version de l’antivirus (VirusScan 8.5 vers 8.8) sur les serveurs en environnement de production, nous avons été confrontés à un incident majeur : la nouvelle version installée bloquait des scripts utilisés par une application métier. Cet incident est survenu sur des serveurs en production qui hébergeaient une application particulière. En conséquence, nous avons complétement revu la méthode de déploiement. Dans notre analyse, il a été mis en évidence la nécessité d’informer et d’impliquer les équipes opérationnelles dès le début d’un tel projet. La méthode de déploiement est désormais conçue en 5 phases de validation et de contrôle successifs. Elle s’applique aux montées de version de l’infrastructure antivirus et du logiciel antivirus. Pour ce type modification, le déploiement est réalisé selon cinq étapes successives : . phase de test : le changement est réalisé sur une maquette de test ;. . phase pilote : plusieurs systèmes sont identifiés pour être les premiers à implémenter le changement, la liste des serveurs doit représenter la diversité des serveurs et des applications utilisés par le client ;. . phase de validation : les prochains systèmes impactés sont les serveurs rattachés à l’environnement de validation ;. . phase de production : à cette étape, le changement est appliqué sur les serveurs en environnement de production ;. . phase critique : les derniers serveurs ciblés sont les serveurs de production qui sont critiques pour l’entreprise.. Cette méthode de déploiement peut être déclinée selon la criticité : . déploiement standard : sur cinq semaines, une semaine par phase ;. . déploiement en urgence : sur cinq jours, un jour par phase ;. 35.

(38) Chaque phase doit être validée pour passer à la suivante. Des tests doivent être réalisés concernant le déploiement correct et le bon fonctionnement des applications. Le but de cette méthode de déploiement est d’identifier les problèmes au plus tôt. Il faut éviter d’engendrer des incidents sur les serveurs de production. Après la phase de test, chaque phase doit être précédée d’une communication vers les équipes en charges des serveurs. La communication est très importante pour informer les responsables des serveurs et des applications sur le changement réalisé : la nature du changement et le périmètre. Le but recherché n’est pas seulement d’informer mais aussi de les impliquer dans le changement. Leurs serveurs doivent être présents dans la phase pilote et aussi celle de validation. Les spécificités de chaque infrastructure touchée doivent être couvertes par ces deux phases. Si un incident survient, les conséquences sur les applications sont maitrisées et limitées aux serveurs identifiés. L’accès aux phases suivantes est donc conditionné à la vérification d’absence de tout effet de bord sur les systèmes. Un modèle pour la communication du service antivirus a été mis en place. Il comporte plusieurs parties : . identité visuelle du service ;. . l’application concernée par le changement ;. . le périmètre : les sites Airbus impactés sont listés ;. . les environnements touchés : intégration, validation et production ;. . une description de l’action à réaliser ;. . les systèmes impactés ;. . une description de l’impact pour l’utilisateur du système ;. . la date à laquelle le changement est prévu ;. . la personne ou le service en charge de l’action. . la personne ou le service responsable de l’action. . un point de contact unique pour les demandes d’information et en cas d’incident.. Ce modèle de communication est adapté aux trois types de changements : infrastructure antivirus, solution antivirus déployée sur les serveurs et ajout de signatures. 36.

(39) virales. Ci-dessous, la figure 20 est un exemple où le modèle de communication a été réutilisé pour présenter le changement et annoncer la stratégie utilisée pour déployer la nouvelle version de l’antivirus sur tous les serveurs Airbus. C’est un déploiement sur plusieurs semaines qui a été utilisé.. Figure 20: Communication lors de la montée de version vers VirusScan 8.8 Patch 1. 37.

(40) Les destinataires de cette communication sont les responsables des serveurs, des applications, les équipes opérationnelles ainsi que les responsables de la Gouvernance Sécurité. Le modèle a été décliné dans le but de communiquer sur le résultat d’un changement (figure 21). Nous reprenons les états qui ont été créés pour les rapports du service antivirus Back Office :. 38.

(41) . )LJXUH&RPPXQLFDWLRQSRXUSUpVHQWHUO pWDWG DYDQFHPHQWGXFKDQJHPHQW. . .

(42) Autre exemple de réutilisation, la figure suivante annonce le déploiement de nouvelles signatures antivirales en urgence :. Figure 22: Communication pour annoncer le déploiement en urgence d'un ExtraDAT. La méthode de déploiement et le modèle de communication ont été généralisés au Front Office (service gérant la solution antivirus pour les postes de travail). Ainsi, l’équipe en charge des postes de travail a abandonné leur ancien modèle de communication et repris notre modèle en l’adaptant à leurs besoins : 40.

(43) Avant :. Figure 23: Ancienne communication du Front Office lors d'un déploiement d'un ExtraDAT. Après :. Figure 24: Nouvelle communication du Front Office en réutilisant notre modèle. 41.

(44) IV Amélioration de la protection antivirale Pour améliorer la protection antivirale du client, il est important de tirer des enseignements sur l’expérience acquise durant les crises, mais aussi de connaitre les limites de la solution antivirus utilisée, et de la configuration mise en place, pour apporter des axes efficaces d’amélioration.. IV.1 Retour d’expérience lors des crises virales Airbus a connu plusieurs crises virales importantes qui ont touché son système d’information. Suite à ces crises, il a été mis en évidence que les virus exploitaient des failles de sécurité pour leur propagation. Tout d’abord, la première faiblesse est venue du retard dans l’application des patchs de sécurité Microsoft sur les serveurs. En effet, des virus ont profité de l’absence de certains correctifs de sécurité pour se répandre. S’ils avaient été appliqués, l’infection aurait pu être ralentie ou bloquée. Dans le cadre du service antivirus Back Office, nous avons intégré ce problème à nos processus par la vérification de l’application des correctifs de sécurité lorsqu’un virus, connu pour utiliser ce type de faille, est détecté sur un serveur. Cela permet de compléter les actions correctives déjà mises en œuvre lors d’une désinfection d’un serveur. Un virus illustre l’exploitation de failles de sécurités Windows pour se propager : le virus Conficker [5]. Il profite d’une vulnérabilité du service serveur pour exécuter un code à distance [6]. Lorsqu’un serveur est déjà infecté, l’antivirus ne suffit pas, il faut installer le patch Microsoft pour corriger la faille de sécurité. De plus, un redémarrage du système est aussi nécessaire à l’antivirus pour terminer l’éradication de Conficker. Le projet d’amélioration du déploiement des patchs de sécurité Microsoft est devenu une priorité pour Airbus. Ensuite, les virus se sont répandus aussi grâce aux serveurs de fichiers (NetApp) qui ne disposaient pas de protection antivirale spécifique. Les fichiers, présents sur ces espaces de stockage, n’étaient pas contrôlés par une solution antivirus. C’est pour cette raison que le projet pour protéger les serveurs de fichiers a été lancé. Les contraintes posées par Airbus sont les suivantes : la future solution antivirus doit être d’un coût faible, être déployé dans un délai réduit et qu’il prenne en charge la protection des serveurs de fichiers NetApp. La solution McAfee (VirusScan for Storage) a été retenue. Cet antivirus peut être géré depuis la console centralisée ePolicy Orchestrator (solution existante). Ainsi, 42.

(45) le coût est réduit grâce à la réutilisation de l’infrastructure antivirus existante. Autre avantage, le temps nécessaire pour déployer cette nouvelle solution est réduit car l’infrastructure antivirus peut la déployer. En effet, la console centralisée permet de déployer l’installation et la configuration de VirusScan Entreprise for Storage. Les administrateurs de cet antivirus peuvent ainsi utiliser la même console d’administration. La documentation nécessaire est aussi réduite du fait de la réutilisation de l’infrastructure existante. Enfin, ce produit est garantie par l’éditeur comme compatible avec le système de fichiers NetApp. C’est le service antivirus Back Office qui pilote cette solution. Pour limiter les infections venant des périphériques USB, la sécurité chez Airbus a décidé la désactivation de la fonction de démarrage automatique (AutoRun). Cette fonction permet d’exécuter un fichier dès l’introduction d’une clef USB par exemple. Le fichier exécuté peut être un fichier malveillant. Dans ce cas, le système est infecté de façon automatique. La désactivation de la fonctionnalité de lancement automatique d’un exécutable permet d’éviter de nombreuses infections. Pour ce type d’attaque, l’antivirus supprime le fichier infecté mais laisse, sur le système, le fichier configuré pour lancer le virus (autorun.inf). Ce comportement de l’antivirus a été démontré par Eric Filiol et Alan Zaccardelle [7] pour le virus Conficker. Pour corriger cette situation, nous avons systématiquement soumis à McAfee, tous ces fichiers pour qu’ils soient traités comme un fichier malveillant : qu’ils soient supprimés du système avec le virus. Lors d’une crise virale, il est très important de pouvoir déployer rapidement une nouvelle signature virale : . la réactivité est un facteur déterminant pour limiter les éventuels impacts pour une entreprise. Afin de s’affranchir des horaires de bureau, il faut que les actes techniques nécessaires dans de telles circonstances soient documentés. Les différentes équipes opérationnelles chez Airbus doivent être capables de réaliser ces actes par eux-mêmes. Ces actes techniques ont donc été intégrés aux documents maintenus par le service antivirus Back Office. Il faut aussi prévoir de faire réaliser régulièrement ces actes par les équipes opérationnelles pour qu’elles se familiarisent avec les actions demandées. Le temps pour réaliser ces actions peut ainsi être amélioré et lorsque les circonstances exigeront une grande réactivité, les équipes connaitront les actes et pourront ainsi optimiser leur temps de réalisation ;. 43.

(46) . la maîtrise du parc des serveurs est essentielle pour assurer le déploiement d’une mise à jour antivirus sur l’ensemble des serveurs. Les incidents empêchant une mise à jour de s’installer sur un système doivent être traités. Les solutions de ces incidents doivent être étudiées pour mettre en place des solutions documentées et réutilisables. Les outils de surveillance des systèmes peuvent ainsi être utilisés pour créer des alertes spécifiques associées avec une solution corrective : o antivirus désactivé : dans le cas où le service de l’antivirus a été arrêté, une alerte est remontée aux responsables et aux équipes opérationnelles. Ces équipes savent grâce à la documentation, quels services il faut relancer ; o espace disque : lorsque le disque système commence à être saturé, une alerte est remontée vers les équipes systèmes. Si l’espace disque est insuffisant, l’antivirus ne pourra pas se mettre à jour ; o problème avec le logiciel antivirus : ce sont les serveurs ayant des retards dans le niveau des signatures virales. Ils sont recensés et corrigés par le service antivirus Back Office ;. . lors d’une crise virale, des rapports doivent être réalisés pour montrer le résultat de l’investigation et la progression de l’éradication d’une attaque virale.. L’expérience tirée de ces crises virales, a montré qu’il est indispensable de ne pas se reposer complètement sur l’antivirus pour garantir un environnement serveur sans fichiers malveillants. L’antivirus a dévoilé ses limites dans la détection de nouveaux ou d’anciens virus informatiques : certains de ces virus n’étaient tout simplement pas détectés par l’antivirus. Lorsque l’antivirus scanne complètement un système et ne détecte rien de particulier, nous ne pouvons pas nous contenter de ce constat. En effet, pour remédier aux limites de l’antivirus, nous devons surveiller et détecter les comportements suspects sur un système. L’antivirus installé sur les systèmes serveurs et les postes de travail n’est pas suffisant, en effet, Laurent Bloch et Christophe Wolfhugel [8] montrent qu’il est nécessaire de compléter la protection antivirale par un contrôle des flux en provenance de l’extérieur. Ainsi, un premier filtre est opéré par ces passerelles centralisées. Et en cas de présence 44.