Exporter (0) Imprimer
Développer tout

Réponse aux incidents de sécurité informatique

Sur cette page

Introduction
Avant de commencer
Réduction du nombre et de la gravité des incidents de sécurité
Mise en place de l'équipe de réponse aux incidents de sécurité informatique de base.
Définition d'un plan de réponse aux incidents
Limitation des dommages et réduction des risques
Informations connexes

Introduction

Dans quelle mesure votre département ou votre administrateur informatique est-il prêt à gérer les incidents de sécurité ? Bon nombre d'organisations n'apprennent à répondre aux incidents de sécurité qu'après avoir subi des attaques. À ce stade, les incidents deviennent souvent beaucoup plus coûteux que nécessaire. Une réponse correcte aux incidents doit faire partie intégrante de votre stratégie de sécurité globale et de votre politique d'atténuation du risque.

La réponse aux incidents de sécurité comporte évidemment des avantages directs. Cependant, elle peut s'accompagner d'avantages financiers indirects. Par exemple, votre compagnie d'assurances est susceptible de proposer des tarifs préférentiels si vous pouvez démontrer que votre organisation est capable de gérer les attaques de façon rapide et économique. Autre exemple, si vous êtes un fournisseur de services, un plan de réponse aux incidents formalisé peut vous faire gagner des parts de marché car il démontre que la sécurité des informations revêt à vos yeux une importance primordiale.

Ce document vous propose un processus et des procédures recommandés à utiliser en réaction aux intrusions identifiées dans un environnement réseau petit à moyen. Il décrit l'intérêt de constituer une équipe de réponse aux incidents de sécurité dont les rôles des membres sont explicites, ainsi que la façon de définir un projet de réponse aux incidents de sécurité.

Pour répondre correctement aux incidents, vous devez :

  • Réduire le nombre et la gravité des incidents de sécurité.

  • Composer une équipe de réponse aux incidents de sécurité informatique de base (CSIRT).

  • Définir un plan de réponse aux incidents.

  • Limiter les dommages et réduire les risques.


Avant de commencer

Les administrateurs système passent beaucoup de temps sur les environnements réseau, et connaissent très bien les réseaux. Ils documentent les environnements et mettent en place des sauvegardes. Un processus d'audit permettant de surveiller les performances et l'utilisation doit déjà être en place. Il est nécessaire d'atteindre un certain niveau de sensibilisation avant de mettre en place une équipe de réponse aux incidents.

Quel que soit votre degré de connaissance de l'environnement réseau, le risque de subir une attaque demeure. Toute stratégie de sécurité raisonnable doit comporter des détails sur la façon de répondre aux différents types d'attaques.

Réduction du nombre et de la gravité des incidents de sécurité

Dans la vie, mieux vaut le plus souvent prévenir que guérir, et la sécurité ne déroge pas à la règle. Dans la mesure du possible, vous chercherez avant tout à empêcher les incidents de sécurité de se produire. Cependant, il est impossible d'empêcher tous les incidents de sécurité. Lorsqu'un incident de sécurité se produit malgré tout, vous devez veiller à en réduire l'impact. Pour réduire le nombre et l'impact des incidents de sécurité, vous devez :

  • Établir clairement et appliquer toutes les stratégies et procédures. Un grand nombre d'incidents de sécurité sont créés accidentellement par du personnel informatique qui n'a pas suivi ou n'a pas compris les procédures de gestion des modifications ou a configuré incorrectement des dispositifs de sécurité tels que les pare-feu et les systèmes d'authentification. Vous devez tester minutieusement vos stratégies et vos procédures pour vous assurer qu'elles sont pratiques et claires, et qu'elles offrent le niveau de sécurité adéquat.

  • Obtenir l'adhésion de la direction aux stratégies de sécurité et le traitement des incidents.

  • Évaluer régulièrement les vulnérabilités de votre environnement. Les évaluations doivent être conduites par un spécialiste en sécurité disposant des autorisations adéquates pour accomplir ces actions (cautionnable et investi de droits d'administrateur sur les systèmes).

  • Vérifiez régulièrement tous les systèmes informatiques et les périphériques réseau pour vous assurer qu'ils bénéficient de l'installation de tous les derniers correctifs.

  • Établir des programmes de formation à la sécurité destinés au personnel informatique et aux utilisateurs finaux. Dans tout système, la naïveté de certains utilisateurs représente le principal risque. Le ver ILOVEYOU a exploité cette vulnérabilité tant auprès des informaticiens que des utilisateurs finaux.

  • Publier des avis de sécurité rappelant aux utilisateurs leurs responsabilités et les limites à ne pas franchir, et les aviser des risques de poursuites en cas de violation. Ces avis permettent de recueillir plus facilement des preuves et de poursuivre les pirates. Vous devez vous renseigner auprès d'un juriste pour vous assurer que la formulation de vos avis de sécurité est appropriée.

  • Développer, implémenter et appliquer une stratégie nécessitant des mots de passe complexes. Vous trouverez des informations supplémentaires sur les mots de passe dans « Application de l'utilisation de mots de passe complexes à l'échelle de votre organisation » dans le kit de conseils de sécurité.

  • Surveiller et analyser régulièrement le trafic réseau et les performances du système.

  • Vérifier régulièrement tous les journaux et mécanismes de journalisation, y compris les journaux d'événements du système d'exploitation, les journaux spécifiques aux applications et les journaux du système de détection d'intrusion.

  • Vérifier vos procédures de sauvegarde et restauration. Vous devez savoir où les sauvegardes sont stockées et qui peut y accéder, et connaître vos procédures de restauration des données et de récupération du système. Contrôlez régulièrement les sauvegardes et les médias en restaurant des données de façon sélective.

  • Créer une équipe CSIRT (Computer Security Incident Response Team), responsable de la gestion des incidents liés à la sécurité informatique. Vous pourrez obtenir des détails sur l'équipe CSIRT dans la section suivante de ce document.


Mise en place de l'équipe de réponse aux incidents de sécurité informatique de base.

L'équipe CSIRT centralise le traitement des incidents de sécurité informatique dans votre environnement. Votre équipe doit se composer d'un groupe de personnes responsable du traitement des différents incidents de sécurité. Ses membres doivent avoir des tâches clairement définies, pour garantir qu'aucun aspect de votre réponse ne soit négligé.

Le fait de constituer une équipe avant l'apparition d'un incident est très important pour votre organisation et influe positivement sur le traitement futur des incidents. Une équipe efficace devra :

  • Surveiller les systèmes pour y déceler les violations de la sécurité.

  • Servir de point de communication central, tant pour la réception des rapports sur les incidents de sécurité que pour la transmission d'information vitales sur l'incident aux entités concernées.

  • Documenter et cataloguer les incidents de sécurité.

  • Favoriser la sensibilisation à la sécurité dans l'entreprise de façon à prévenir l'apparition d'incidents dans votre organisation.

  • Promouvoir l'audit du système et du réseau par l'application de processus tels que l'évaluation des vulnérabilités et les tests de pénétration.

  • S'informer des nouvelles vulnérabilités et des stratégies d'attaque employées par les pirates.

  • S'informer de la disponibilité des nouveaux correctifs logiciels.

  • Analyser et développer de nouvelles technologies permettant de réduire les failles et les risques liés à sécurité.

  • Proposer des services de conseil sur la sécurité.

  • Assurer l'amélioration et la mise à jour permanentes des systèmes et procédures existants.

Lorsque vous créez une équipe CSIRT, préparez l'équipe de sorte qu'elle soit équipée pour traiter les incidents. Pour préparer l'équipe, vous devez :

  • Former ses membres à l'utilisation et l'emplacement corrects des outils de sécurité critiques. Envisagez également de leur fournir des ordinateurs portables sur lesquels ces outils sont préinstallés, afin qu'ils ne perdent pas de temps à les installer et à les configurer en cas d'incident. Ces systèmes et les outils associés doivent être protégés correctement lorsqu'ils ne sont pas utilisés.

  • Rassembler toutes les informations de communication pertinentes. Vous devez veiller à disposer des noms et numéros de téléphone des personnes à prévenir dans votre organisation (notamment les membres de l'équipe CSIRT, les personnes responsables du support de tous vos systèmes, et celles chargées des relations avec les médias). Vous aurez également besoin d'informations précises pour votre fournisseur d'accès à Internet (FAI) et pour les autorités locales et nationales chargées de l'application de la loi. Discuter avec votre conseiller juridique de la façon de prendre contact avec les autorités locales chargées de l'application de la loi avant l'apparition d'un incident. Cela vous permettra de comprendre les procédures correctes à suivre pour communiquer les incidents et recueillir les preuves. Le conseiller juridique doit être informé de tous les contacts pris avec les autorités chargées de d'application de la loi.

  • Centraliser toutes les informations du système d'urgence dans un emplacement « hors connexion », par exemple en les conservant dans un carnet ou en les enregistrant sur un ordinateur dépourvu de connexion réseau. Ces informations comprennent notamment les mots de passe d'accès aux systèmes, les adresses IP (Internet Protocol), les informations de configuration des routeurs, les listes de définition des règles de pare-feu, les copies des clés des autorités de certification, les noms et numéros de téléphone des contacts, les procédures d'escalade, etc. Ces informations doivent être conservées dans un endroit sûr mais rester facilement accessibles. Pour cela, vous pouvez par exemple les chiffrer sur un ordinateur portable dédié à la sécurité, placé en lieu sûr, et accessible uniquement aux personnes habilitées telles que le responsable de l'équipe CSIRT, le directeur informatique ou le directeur technique.

La composition et la structure idéales de l'équipe CSIRT dépendent du type de votre organisation et de votre stratégie de gestion du risque. Cependant, l'équipe de sécurité de votre organisation doit généralement être constituée en partie ou en totalité de l'équipe CSIRT. L'équipe de base doit comporter des professionnels de la sécurité chargés de coordonner une réponse à un incident quelconque. Le nombre de membres de l'équipe CSIRT dépend généralement de la taille et de la complexité de votre organisation. Cependant, vous devez veiller à ce qu'il y ait suffisamment de membres pour prendre en charge toutes les tâches de l'équipe à tout moment.

Définition des rôles des membres de l'équipe

Une équipe CSIRT efficace compte plusieurs membres clés.

Responsable d'équipe CSIRT. L'équipe CSIRT doit comporter une personne responsable de ses activités. Le Responsable d'équipe CSIRT sera en général responsable des activités de l'équipe CSIRT et coordonnera les évaluations de ses actions. Celles-ci peuvent entraîner des modifications des politiques et des procédures suivies pour le traitement des incidents futurs.

Responsable des incidents de l'équipe CSIRT. En cas d'incident, vous devez désigner une personne chargée de coordonner la réponse. Le Responsable des incidents de l'équipe CSIRT se charge de l'incident particulier ou de l'ensemble des incidents de sécurité connexes. Toute la communication sur l'événement est coordonnée par le Responsable des incidents, et, lorsqu'il parle avec des personnes extérieures à l'équipe CSIRT, il ou elle représente l'équipe CSIRT dans sa totalité. Le Responsable des incidents choisi peut dépendre de la nature de l'incident, et n'est souvent pas le Responsable d'équipe CSIRT.

Membres associés de l'équipe CSIRT. Outre l'équipe CSIRT de base, vous devez disposer de plusieurs personnes spécifiques qui gèrent les incidents particuliers et y répondent. Les Membres associés seront issus de divers départements de votre organisation. Ils doivent se spécialiser dans des domaines qui sont concernés par les incidents de sécurité mais ne sont pas directement traités par l'équipe CSIRT de base. Les Membres associés peuvent être impliqués directement dans un incident ou servir de points d'entrée permettant de déléguer la responsabilité à une personne plus adéquate au sein de leur département. Le tableau suivant présente certains membres associés suggérés, ainsi que leurs rôles.

Membres associés de l'équipe CSIRT

Membre associé

Description du rôle

Contact informatique

Ce membre est principalement responsable de la coordination de la communication entre le Responsable des incidents de l'équipe CSIRT et le reste du groupe informatique. Le Contact informatique est susceptible de ne pas posséder le savoir-faire technique permettant de répondre à l'incident particulier ; cependant, il ou elle sera principalement responsable de trouver dans le groupe informatique des personnes qui géreront les événements de sécurité particuliers.

Représentant juridique

Ce membre est un juriste connaissant très bien les stratégies de réponse aux incidents établies. Le Représentant juridique détermine la façon de procéder pendant un incident en alliant une responsabilité légale minimale à une capacité maximale à poursuivre les contrevenants.

Avant la survenue d'un incident, il doit avoir participé à l'élaboration des stratégies de surveillance et de réponse. Il doit ainsi s'assurer que l'organisation ne s'expose à aucun risque juridique à l'occasion d'une opération de nettoyage ou de réparation. Il est essentiel de prendre en compte les implications légales liées à l'arrêt d'un système et à la violation potentielle des accords de niveau de service (SLA) ou des contrats de partenariat établis avec vos clients. De même, il est important d'être informé des conséquences du maintien en service d'un système compromis susceptible d'être à l'origine d'attaques, et des responsabilités légales auxquelles vous vous exposez en cas de dommages résultant de ces attaques.

Le représentant juridique est également chargé de la coordination des communications avec les autorités juridiques ou les organismes d'enquête externes.

Responsable des Relations publiques

Souvent issu du département des Relations publiques, ce membre est chargé de la protection et de la promotion de l'image de l'organisation.

Il n'est pas toujours l'interlocuteur direct des médias et des clients, mais a pour mission d'élaborer le message (le contenu et l'objectif du message relevant en général de la responsabilité de la direction). Toutes les demandes d'information des médias doivent être adressées aux Relations publiques.

Direction

Selon l'incident particulier, vous pouvez faire intervenir la direction du service ou la direction de l'organisation. Tout dépendra de l'impact, de l'emplacement, de la gravité et du type d'incident.

Si vous avez un point de contact au niveau de la direction, vous pouvez identifier rapidement la personne la plus adéquate dans des circonstances données. La direction est chargée de l'approbation et de la conduite de la stratégie de sécurité.

Elle doit également déterminer l'impact total (financier et autre) de l'incident sur l'organisation. La direction indique au Responsable des communications les informations à divulguer aux médias, et détermine le niveau d'interaction entre les Représentants juridiques et les autorités juridiques.

Réponse à un incident

En cas d'incident, l'équipe CSIRT coordonne une réponse émanant de son noyau central et communique avec ses membres associés. Le tableau suivant présente les responsabilités auxquelles ces personnes sont soumises pendant le processus de réponse aux incidents.

Responsabilités de l'équipe CSIRT pendant le processus de réponse aux incidents

Activité

Rôle

 

Responsable des incidents de l'équipe CSIRT

Contact informatique

Représentant juridique

Responsable des communications

Direction

Evaluation initiale

Propriétaire

Conseil

Aucun

Aucun

Aucun

Réponse initiale

Propriétaire

Implémentation

Information

Information

Information

Collecte des preuves légales

Implémentation

Conseil

Propriétaire

Aucun

Aucun

Implémentation d'un correctif provisoire

Propriétaire

Implémentation

Information

Information

Conseil

Envoi de la communication

Conseil

Conseil

Conseil

Implémentation

Propriétaire

Vérification auprès des autorités locales chargées de l'application de la loi

Information

Information

Implémentation

Information

Propriétaire

Implémentation d'un correctif définitif

Propriétaire

Implémentation

Information

Information

Information

Évaluation de l'impact financier sur l'entreprise

Information

Information

Conseil

Information

Propriétaire


Définition d'un plan de réponse aux incidents

Tous les membres de votre environnement informatique doivent savoir comment réagir en cas d'incident. Si l'équipe CSIRT met en œuvre la plupart des actions de réponse, votre personnel informatique doit, à tous les niveaux, connaître la procédure de signalement des incidents en interne. Les utilisateurs finaux informent directement le personnel informatique des activités suspectes ou s'adressent à l'assistance technique mais ils ne contactent pas directement l'équipe CSIRT.

Chaque membre de l'équipe doit examiner en détail le plan de réponse aux incidents. La mise à disposition du plan à tout le personnel informatique contribue à une application des procédures correctes en cas d'incident.

Pour initier un plan de réponse aux incidents efficace, vous devez :

  • Procéder à une évaluation initiale.

  • Communiquer l'incident.

  • Limiter les dommages et réduire le risque.

  • Identifier le type et la gravité du préjudice subi.

  • Protéger les preuves.

  • Adresser une notification aux agences externes s'il y a lieu.

  • Restaurer les systèmes.

  • Compiler et organiser la documentation sur les incidents.

  • Évaluer les dommages et le coût des incidents.

  • Examiner les stratégies de réponse et de mise à jour.

Ces étapes ne sont pas purement séquentielles. En fait, elles se déroulent tout au long de l'incident. Ainsi, la phase de documentation commence dès le début et se poursuit durant tout le cycle de vie de l'incident. De même, la communication doit être maintenue tout au long de l'incident.

D'autres aspects du processus sont exécutés en parallèle. Par exemple, l'évaluation initiale permet de se faire une idée générale de la nature de l'attaque. Il est important d'utiliser ces informations pour limiter les dommages et réduire le risque dès que possible. En agissant rapidement, vous pourrez économiser du temps et de l'argent, et protéger la réputation de votre organisation.

Toutefois, tant que vous n'aurez pas déterminé exactement le type et la gravité de l'attaque, vous ne pourrez pas minimiser les dommages et réduire le risque de façon réellement efficace. Une réponse trop précipitée risque même d'aggraver la situation par rapport à l'attaque initiale. En agissant en parallèle sur ces deux fronts, vous obtiendrez le meilleur compromis entre une action rapide et une action efficace.

Remarque : Il est très important de tester en détail le processus de réponse aux incidents avant l'apparition d'un incident. En l'absence de tests approfondis, vous ne pouvez pas être certain de l'efficacité des mesures de réponse aux incidents en vigueur.

Évaluation initiale

De nombreuses activités peuvent être interprétées comme une attaque dirigée contre votre organisation. Par exemple, une maintenance système normale effectuée par un administrateur réseau peut faire penser à une attaque lancée par un tiers. Dans d'autres cas, un système mal configuré peut entraîner plusieurs faux positifs dans un système de détection d'intrusion, ce qui peut compliquer la localisation des incidents authentiques.

Dans le cadre de votre évaluation initiale, vous devez :

  • Prendre des mesures pour déterminer si vous êtes confronté à un incident réel ou à un faux positif.

  • Vous forger une idée générale du type et de la gravité de l'attaque. Les informations ainsi rassemblées doivent être suffisantes pour entamer la phase de communication visant à approfondir les recherches et pour commencer à minimiser les dommages et réduire le risque.

  • Enregistrer vos actions de façon précise. Ces données serviront ensuite à documenter l'incident (qu'il soit réel ou non).

Remarque : Même si, dans la mesure du possible, vous préférez éviter les fausses alertes, il est toujours préférable de réagir à une fausse alerte qu'ignorer un incident réel. L'évaluation initiale doit donc être aussi courte que possible tout en tentant d'éliminer les fausses alertes évidentes.

Communication de l'incident

Lorsque vous soupçonnez la présence d'un incident de sécurité, vous devez rapidement communiquer l'infraction au reste de l'équipe CSIRT de base. Le responsable des incidents, avec le reste de l'équipe, doit rapidement identifier les personnes à contacter hors de l'équipe CSIRT de base. Cela permet de conserver la maîtrise de l'incident, d'en assurer la coordination et de réduire l'ampleur des dommages.

Sachez que les dommages peuvent revêtir de nombreuses formes : une violation de sécurité qui fait la une des journaux peut avoir des répercussions bien plus graves que bon nombre d'autres intrusions dans un système. Pour cette raison, mais aussi pour éviter qu'un intrus n'en soit avisé, seules les personnes jouant un rôle dans la réponse à l'incident doivent être informées, et ce, aussi longtemps que le problème n'est pas totalement maîtrisé. En fonction de la situation, votre équipe déterminera ultérieurement qui doit être informé de l'incident. Il peut s'agir de personnes isolées dans l'entreprise, de l'ensemble du personnel et de clients externes. La communication à l'extérieur doit être coordonnée avec le Représentant juridique.

Limitation des dommages et réduction des risques

En agissant rapidement pour réduire les effets réels et potentiels d'une attaque, vous pouvez empêcher une attaque mineure de prendre des proportions démesurées. La réponse exacte dépend de votre organisation et de la nature de l'attaque subie. Cependant, les priorités suivantes sont suggérées comme point de départ :

  1. Protection de la vie humaine et de la sécurité des personnes. Cela doit naturellement constituer votre priorité absolue dans tous les cas.

  2. Protection des données confidentielles et sensibles. Dans le cadre de votre planification de la réponse aux incidents, vous devez définir clairement les données confidentielles et les données sensibles. Cela vous permettra de hiérarchiser vos réponses pour la protection des données.

  3. Protection des autres données, notamment les données privées, scientifiques et de gestion. D'autres données de votre environnement peuvent cependant avoir de la valeur. Vous devez vous employer à protéger en priorité les données stratégiques avant de vous occuper d'autres données moins importantes.

  4. Protection du matériel et des logiciels contre les attaques. Cela concerne notamment la protection contre la perte ou l'altération de fichiers système, et les dommages physiques du matériel. Les dommages causés aux systèmes peuvent entraîner des temps d'immobilisation coûteux.

  5. Limitation de la durée d'interruption du fonctionnement des ressources informatiques (processus inclus). La disponibilité des systèmes est certes essentielle dans la plupart des environnements, mais leur maintien en service pendant une attaque peut entraîner des problèmes plus graves par la suite. En conséquence, la limitation de la durée d'interruption des ressources informatiques doit en général constituer une priorité relativement basse.

Vous pouvez prendre un certain nombre de mesures pour limiter les dommages et réduire le risque au sein de votre environnement. Vous devez au minimum :

  • Essayer d'éviter d'indiquer aux pirates que vous êtes conscient de leurs activités. Cela peut s'avérer difficile, parce que certaines mesures de réponse essentielles sont susceptibles de les alerter. Par exemple, si une réunion d'urgence de l'équipe CSIRT est organisée, ou que vous demandez une modification immédiate de tous les mots de passe, des pirates internes peuvent en déduire que vous êtes conscient d'un incident.

  • Comparer le coût lié à la mise hors ligne des systèmes compromis et des systèmes connexes au risque lié à la poursuite les opérations. Dans l'immense majorité des cas, vous devez immédiatement déconnecter le système du réseau. Cependant, vous pouvez être lié par des contrats de service prévoyant que la disponibilité des systèmes doit être maintenue même si cela risque d’entraîner d’autres dommages. Si tel est le cas, vous pouvez choisir de maintenir un système en ligne avec une connectivité limitée afin de réunir des preuves supplémentaires pendant une attaque en cours.
    Dans certains cas, les dommages et l'ampleur d'un incident peuvent être si vastes que vous devrez peut-être intenter une action se prévalant des clauses pénales spécifiées dans vos accords de niveau de service. Dans tous les cas, il est très important que les actions intentées en cas d'incident soient étudiées à l'avance et présentées dans le plan de réponse afin de lancer immédiatement la procédure lors d'une attaque.

  • Déterminer le ou les points d'accès utilisés par le pirate et implémenter des mesures permettant d'empêcher un accès futur. Ces mesures peuvent inclure la désactivation d'un modem, l'ajout d'entrées de contrôle d'accès à un routeur ou à un pare-feu, ou le renforcement des dispositifs de sécurité physiques.

  • Envisager de reconstruire un système entièrement neuf, avec de nouveaux disques durs (les disques durs existants doivent être retirés du système et stockés pour servir de preuves si vous décidez de poursuivre les pirates). Veillez à modifier les mots de passe locaux. Vous devez également modifier les mots de passe des comptes d'administration et de service partout ailleurs dans l'environnement.

Identification de la gravité du préjudice subi

Pour rétablir le fonctionnement normal des systèmes à la suite d'une attaque, vous devez déterminer le niveau de gravité du préjudice subi par vos systèmes. Vous saurez ainsi quelle approche adopter par la suite pour réduire le risque, quel mode de récupération appliquer, la rapidité avec laquelle l'incident sera signalé et à qui, et s'il faut ou non exiger réparation.

Il est impératif de déterminer les éléments suivants :

  • La nature de l'attaque (qui peut être différente de ce que suggère l'évaluation initiale).

  • Le point d'origine de l'attaque.

  • Le but de l'attaque. L'attaque visait votre organisation en particulier pour l'acquisition d'informations spécifiques, ou a-t-elle été lancée de façon aléatoire ?

  • Les systèmes compromis.

  • Les fichiers auxquels des personnes ont accédé et la sensibilité de ces fichiers.

Après quoi, vous pourrez déterminer les réponses adéquates pour votre environnement. Un plan de réponse aux incidents efficace décrit les procédures précises à appliquer à mesure que vous en apprenez davantage sur l'attaque En général, la nature des symptômes de l'attaque détermine l'ordre dans lequel les procédures du plan sont mises en œuvre. Le temps étant précieux dans ce type de situation, les procédures rapides doivent souvent précéder les procédures plus longues. Pour mieux déterminer la gravité du préjudice subi, vous devez :

  • Contacter les autres membres de l'équipe de réponse pour les informer de vos découvertes, leur demander de vérifier vos résultats, déterminer s'ils sont informés d'une activité d'attaque connexe ou d'autres attaques potentielles et les aider à déterminer si l'incident est un faux positif. Dans certains cas, ce qui peut passer pour un incident authentique lors de l'évaluation initiale s'avère être un faux positif.

  • Déterminer si du matériel non autorisé a été connecté au réseau ou si certains signes suggèrent un accès non autorisé au moyen d'une transgression des contrôles de sécurité physiques.

  • Examiner les groupes clés (administrateurs de domaine, administrateurs, etc.) afin de vous assurer qu'ils ne contiennent pas de membres non autorisés.

  • Rechercher des logiciels d'évaluation de la sécurité ou d'exploitation. À l'occasion de la collecte de preuves, des utilitaires de décodage illégal sont souvent découverts sur les systèmes compromis.

  • Rechercher des processus ou des applications non autorisées en cours d'exécution ou paramétrés pour s'exécuter via les dossiers de démarrage ou des entrées du Registre.

  • Rechercher des écarts éventuels dans les journaux système, ou l'absence de journaux systèmes.

  • Examiner les journaux systèmes de détection d'intrusion pour y rechercher des signes d'intrusion, les systèmes susceptibles d'avoir été touchés, les méthodes d'attaque, l'heure et la durée de l'attaque, et l'étendue globale des dommages potentiels.

  • Examiner les autres fichiers journaux pour y rechercher des connexions inhabituelles, des défaillances dans les audits de sécurité, un nombre anormalement élevé d'audits de sécurité réussis, des tentatives d'ouverture de session infructueuses, des tentatives d'ouverture de session avec des comptes par défaut, une activité en dehors des heures de travail, des changements d'autorisations d'accès aux fichiers, aux répertoires et aux partages ainsi que des modifications ou des élévations de privilèges utilisateur.

  • Comparer l'état actuel des systèmes avec les contrôles d'intégrité effectués précédemment sur les fichiers et les systèmes. Vous pourrez ainsi constater les ajouts, les suppressions, les modifications, et les changements de contrôle et d'autorisations présents sur le système de fichiers et le Registre. Vous pouvez gagner beaucoup de temps en répondant aux incidents si vous identifiez exactement les éléments compromis et les domaines nécessitant des mesures de récupération.

  • Rechercher des données sensibles (telles que des numéros de carte de crédit et des données relatives aux clients ou aux employés) susceptibles d'avoir été déplacées ou masquées en vue d'être extraites ou modifiées ultérieurement. Il peut également être nécessaire de rechercher dans les systèmes des données non professionnelles, les copies illégales de logiciels ainsi que des messages électroniques ou d'autres enregistrements de nature à vous aider dans votre enquête. Si ces recherches risquent d'enfreindre la sécurité ou la législation, contactez votre service juridique avant de poursuivre.

  • Comparer les performances des systèmes suspects aux niveaux de performances de référence Cette opération n'est naturellement possible que si des critères de référence ont été établis et mis à jour correctement.

Pour identifier les systèmes compromis et déterminer dans quelle mesure ils l'ont été, vous devez généralement comparer les systèmes aux critères de référence auxquels ils répondaient avant leur attaque. Si vous partez du principe qu'un instantané récent du système suffit pour la comparaison, vous risquez d’être confronté à des difficultés dans le cas où l'instantané en question proviendrait d'un système qui a déjà subi une attaque.

Remarque : Des outils tels qu'EventCombMT, DumpEL et Microsoft Operations Manager (MOM) peuvent vous aider à déterminer l'étendue de l'attaque menée contre un système. Des systèmes tiers de détection des intrusions vous signalent à l'avance des attaques, tandis que d'autres outils permettent d'identifier les modifications apportées aux fichiers sur vos systèmes.

Protection des preuves

Si votre environnement a fait l'objet d'une attaque délibérée, vous devrez le plus souvent prendre des mesures légales à l'encontre des auteurs des faits. Pour conserver cette possibilité, vous devez réunir des preuves pouvant être utilisées contre eux, même si l'est finalement décidé de ne pas donner suite à cette action. Il est essentiel de sauvegarder les systèmes compromis dès que possible. Sauvegardez les systèmes avant d'entreprendre toute action susceptible de nuire à l'intégrité des données sur le support d'origine.

Vous devez vous entourer des services d'une personne compétente en la matière pour effectuer au moins deux sauvegardes intégrales bit par bit du système complet, à l'aide de supports entièrement neufs. Au moins une sauvegarde doit être effectuée sur des supports non réinscriptibles (WORM) tels qu'un CD ou un DVD en lecture seule. Cette sauvegarde ne servira que pour poursuivre les coupables et doit être conservée en lieu sûr jusqu'à son utilisation.

L'autre sauvegarde peut être utilisée pour la récupération de données. Ces sauvegardes ne devant être utilisées qu'à des fins juridiques, il est nécessaire de les protéger physiquement. Vous devez également fournir des informations sur les sauvegardes, précisant notamment par qui elles ont été effectuées, à quel moment, comment elles ont été protégées et qui y a eu accès.

Une fois les sauvegardes effectuées, vous devez retirer les disques durs d'origine et les ranger en lieu sûr. Ceux-ci pourront servir de preuves en cas de poursuites judiciaires. De nouveaux disques durs doivent être utilisés pour la restauration du système.

Dans certains cas, l'avantage offert par la préservation des données n'équivaut pas au coût induit par le retard qu'elle provoque dans la réponse et la récupération du système. Les coûts et les avantages de la préservation des données doivent être comparés à ceux d'une récupération plus rapide pour chaque événement.

Pour les très gros systèmes, des sauvegardes complètes de tous les systèmes compromis ne seront peut-être pas réalisables. Il est préférable de sauvegarder tous les fichiers journaux ainsi qu'une sélection des parties touchées du système.

Si possible, sauvegardez également les données d'état du système. Il peut se passer des mois, voire des années, avant que l'affaire soit jugée. Aussi est-il important d'archiver un maximum d'informations sur l'incident en vue d'une utilisation future.

Souvent, dans le cadre des poursuites intentées contre l'auteur d'un délit informatique, la difficulté majeure consiste à réunir des preuves acceptables d'un point de vue légal par la juridiction concernée. Par conséquent, l'élément essentiel de la procédure judiciaire consiste à élaborer une documentation détaillée et complète sur la façon dont les systèmes ont été gérés, par qui et quand, afin d'établir des preuves fiables. Signez et datez chaque page de la documentation.

Après avoir vérifié les sauvegardes et vous être assuré de leur bon fonctionnement, vous pouvez éliminer les systèmes compromis et en reconstituer de nouveaux. Cela vous permettra de reprendre l'exploitation. Ce sont les sauvegardes qui fournissent les preuves stratégiques et irréfutables requises dans le cadre d'une action en justice. Pour la restauration des données, il convient de recourir à une sauvegarde distincte de celle utilisée pour la procédure judiciaire.

Notification adressée aux organismes externes

Une fois l'incident maîtrisé et les données sauvegardées en vue de poursuites éventuelles, vous devez déterminer l'opportunité d'en informer les entités externes appropriées. Toutes les révélations externes doivent être coordonnées avec votre Représentant juridique. Les entités potentielles sont notamment les autorités locales et nationales chargées de l'application de la loi, les organismes de sécurité externes et les experts en matière de virus. Les organismes externes peuvent vous fournir une assistance technique, en vous proposant une procédure de résolution plus rapide et des informations obtenues à la suite d'incidents du même ordre. Ainsi, vous pourrez effectuer une récupération totale du système et l'incident ne pourra pas se reproduire.

Dans certains secteurs d'activités et avec certains types de violations spécifiques, il est parfois nécessaire d'avertir des clients particuliers ou le grand public, notamment si l'incident peut avoir des répercussions directes sur les clients.

Si l'événement a eu un impact financier important, vous devrez peut-être le signaler également aux autorités chargées de l'application de la loi.

Dans le cas d'entreprises et d'incidents de grande envergure, les médias peuvent entrer en jeu. S'il n'est jamais bon d'attirer l'attention de ces derniers sur un incident lié à la sécurité, leur intervention est souvent inévitable. L'attention des médias permet à votre organisation d'adopter une attitude proactive en communiquant l'incident. Il est indispensable que les procédures de réponse aux incidents définissent au minimum clairement les personnes autorisées à s'adresser aux médias.

En principe, c'est le département des relations publiques de l'organisation qui s'exprime. Il est déconseillé de nier la réalité d'un incident. En effet, un déni porte, en général, davantage atteinte à la réputation de l'entreprise qu'une approche proactive qui admet les dommages subis et explique les mesures prises pour les pallier. Pour autant, vous n'êtes pas tenu d'informer les médias de chaque incident, quel que soit sa nature ou sa gravité. En fait, vous devez décider au cas par cas de la réaction à adopter face aux médias.

Récupération des systèmes

Le mode de récupération du système choisi dépend généralement de l'ampleur de l'incident de sécurité. Vous devez déterminer si vous pouvez restaurer le système existant en le laissant aussi intact que possible, ou s'il est nécessaire de le reconstituer complètement.

La restauration des données suppose que vous disposiez de sauvegardes « propres », effectuées avant l'incident. Des logiciels d'intégrité des fichiers peuvent faciliter l'identification du premier dommage subi. Si le logiciel signale un fichier modifié, vous êtes certain que la sauvegarde réalisée avant l'alerte est valable et qu'elle doit être conservée pour la reconstitution du système compromis.

Un incident peut endommager des données pendant de longs mois avant d'être découvert. Il est donc très important que vous déterminiez, dans le cadre du processus de réponse aux incidents, la durée de l'incident (les logiciels d'intégrité des fichiers et des systèmes, ainsi que les systèmes de détection des intrusions, peuvent vous y aider). Dans certains cas, il se peut que la dernière sauvegarde, voire les quelques sauvegardes antérieures ne suffisent pas à ramener le système à la normale. Aussi est-il fortement recommandé d'archiver régulièrement les sauvegardes de données en lieu sûr, hors du site.

Compilation et organisation des preuves relatives à l'incident

L'équipe CSIRT doit documenter en détail tous les processus intervenant dans la gestion d'un incident. Pour cela, elle doit notamment fournir une description de la violation de sécurité et des détails sur chaque action entreprise (auteur, date et motif de l'action). Le processus de réponse doit signaler toute personne participant au processus et autorisée.

La documentation doit ensuite être organisée chronologiquement. Il faut s'assurer qu'elle est complète, signée et révisée par des représentants de la direction et des services juridiques. Vous devez également préserver les preuves réunies lors de la phase de protection de celles-ci. Il est préférable que deux personnes soient présentes pendant toutes les phases, pour valider chacune d'elles par leur signature. Vous réduirez ainsi les risques que des preuves soient irrecevables ou modifiées après coup.

Rappelez-vous que le coupable peut être un employé, un sous-traitant, un intérimaire ou une autre personne de l'organisation. En l'absence d'une documentation approfondie et détaillée, l'identification d'un intrus interne est très difficile. Une documentation correcte constitue également un sérieux atout pour engager des poursuites contre les coupables.

Évaluation des dommages et des coûts de l'incident

Lorsque vous déterminez les dommages subis par votre organisation, vous devez prendre en compte les coûts directs et les coûts indirects. Les dommages et les coûts liés à l'incident constitueront des preuves importantes qui vous seront nécessaires pour intenter des poursuites. Il peut notamment s'agir des éléments suivants :

  • Les coûts liés à la perte encourue par l'entreprise en termes de compétitivité à la suite de la fuite d'informations propriétaires ou sensibles.

  • Les frais de justice.

  • Les coûts de main-d'œuvre nécessaires à l'analyse des violations de sécurité, à la réinstallation des logiciels et à la récupération des données

  • Les coûts associés à l'arrêt du système (par exemple, la perte de productivité des employés, le manque à gagner en termes de ventes, le remplacement du matériel, des logiciels et autres biens).

  • Les coûts de réparation et, le cas échéant, de mise à jour des moyens de sécurité physiques inefficaces ou endommagés (verrous, murs, racks, etc.).

  • D'autres dommages consécutifs, tels que la dégradation de la réputation de l'entreprise ou la perte de confiance de la part des clients.

Révision des stratégies de réponse et de mise à jour

Au terme des phases de documentation et de récupération, vous devez revoir intégralement la procédure. Avec le concours de toute l'équipe, déterminez les étapes exécutées correctement et les erreurs commises. Dans l'immense majorité des cas, vous constaterez que vous devez modifier certains processus pour mieux gérer les futurs incidents.

Vous découvrirez assurément certaines failles dans votre plan de réponse aux incidents, la recherche de celles-ci étant d'ailleurs l'objet de l'exercice « post mortem ». Il a pour but d'identifier les domaines à améliorer, point de départ d'un tout nouveau cycle du processus de planification de la réponse aux incidents.

Informations connexes

Une bonne partie de ce document a traité des mesures que vous pouvez prendre pour réduire le risque d'attaques. Cependant, c'est lorsque les organisations font tout leur possible pour réduire les risques d'attaque, et qu'elles planifient ensuite les mesures à prendre en cas d'attaque, que les organisations parviennent le mieux à atteindre leurs objectifs de sécurité. Dans le cadre de ce processus, il faut notamment mettre en place un audit approfondi de l'attaque. Toutefois, il est tout aussi important de définir un ensemble de réactions à adopter en cas d'attaque.

Pour plus d'informations sur la création d'un plan de réponse aux incidents, consultez les documents suivants :

Pour plus d'informations sur la sécurité, consultez les ressources suivantes :

  • The Internet Security Guidebook: >From Planning to Deployment de Juanita Ellis et Tim Speed (Academic Press, ISBN: 0223747).


Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft