10. Réponse aux incidents

Comment votre service informatique s'est-il préparé à gérer un incident lié à la sécurité ? De nombreuses organisations apprennent à réagir face à un tel incident uniquement après avoir connu une attaque. À ce stade, le coût de l'incident est souvent beaucoup plus élevé qu'il ne l'aurait été dans d'autres conditions. Il est donc important que vous prévoyiez dès le départ, dans le cadre de vos stratégies de sécurité globale et de minimisation du risque, un plan de réponse aux incidents parfaitement adapté.

Un tel plan présente bien évidemment des avantages directs, sans oublier d'autres avantages financiers indirects. Ainsi, votre compagnie d'assurances peut vous proposer des tarifs préférentiels si vous prouvez que votre organisation est capable en permanence de gérer les attaques de façon rapide et rentable. 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 montre que la sécurisation de l'information revêt à vos yeux une importance primordiale.

Ce chapitre décrit les processus et les procédures à mettre en œuvre pour répondre efficacement aux intrusions identifiées dans un environnement Microsoft® Windows® 2000 Server. Il explique les avantages que l'on peut tirer de la formation d'une équipe de gestion des incidents de sécurité, dont les membres remplissent des rôles explicitement définis. Il traite également de la procédure requise pour établir un plan de réponse aux incidents de sécurité. Enfin, une étude de cas montre comment appliquer de façon optimale ce processus et ses procédures connexes dans votre organisation.

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

Dans tous les domaines de la vie, il vaut mieux « prévenir que guérir », et la sécurité ne fait pas exception à cette règle. Toutefois, s'il est toujours préférable d'éviter les incidents de sécurité (reportez-vous à ce sujet aux chapitres 5 à 8), cela n'est pas toujours possible. Dès lors, lorsqu'un incident de sécurité se produit, le mieux est d'essayer de limiter son impact. Pour réduire le nombre d'incidents de sécurité et leur impact, des mesures doivent être prises, tant sur le plan de la prévention que de la réaction immédiate :

· Établir avec précision toutes les stratégies et procédures requises et les mettre en œuvre de manière rigoureuse. De nombreux incidents de sécurité surviennent accidentellement parce que le personnel informatique n'a pas suivi ou compris les procédures de gestion des modifications ou qu'il a mal configuré des périphériques de sécurité, tels les pare-feu et les systèmes d'authentification. Vos stratégies et procédures doivent être testées de façon approfondie afin de s'assurer non seulement qu'elles sont fonctionnelles et claires, mais aussi qu'elles garantissent le niveau de sécurité approprié.

· Gagner l'adhésion de la direction aux stratégies de sécurité et de gestion des incidents.

· Analyser régulièrement l'environnement de façon à détecter ses vulnérabilités éventuelles. Cette tâche doit être confiée à un spécialiste de la sécurité compétent en la matière.

· Vérifier régulièrement les serveurs pour s'assurer qu'ils disposent des derniers correctifs disponibles.

· Mettre en place des programmes de formation sur la sécurité, tant pour le personnel informatique que pour les utilisateurs finals. Dans tout système, la naïveté de certains utilisateurs représente le risque majeur. Le ver ILOVEYOU a exploité cette vulnérabilité tant du côté des informaticiens que de l'utilisateur final.

· Publier des avis de sécurité qui rappellent aux utilisateurs les responsabilités qui leur incombent et les limites qu'ils ne doivent pas franchir. Il est important d'avertir les utilisateurs des poursuites auxquelles ils s'exposent en cas de violation de ces règles. Sans ces avis, il est difficile, voire impossible, de poursuivre les auteurs d'attaques informatiques. Renseignez-vous auprès d'un conseiller juridique pour qu'il vérifie si vos avis sont correctement formulés.

· Élaborer, implémenter et mettre en application une stratégie qui requiert des mots de passe de sécurité complexes. Pour plus d'informations sur les options de sécurité avec mots de passe complexes et sur les méthodes conseillées, reportez-vous au chapitre 5, « Sécurisation de l'infrastructure du domaine ».

· Surveiller et analyser en permanence le trafic réseau et les performances du système.

· Contrôler régulièrement tous les journaux et mécanismes d'enregistrement apparentés. Citons notamment les journaux des événements du système d'exploitation, les journaux d'application et les journaux de système de détection des intrusions.

· Vérifier les procédures de sauvegarde et de restauration. Vous devez connaître avec exactitude l'emplacement de stockage des sauvegardes, les personnes qui y ont accès, ainsi que les procédures de restauration des données et de récupération du système. Contrôlez régulièrement vos sauvegardes et les médias utilisés en restaurant des sélections de données.

· Créer une équipe CSIRT (Computer Security Incident Response Team), responsable de la gestion des incidents touchant la sécurité informatique. Les tâches attribuées à chacun des membres de cette équipe doivent être clairement définies, de telle sorte qu'aucun aspect du plan de réponse aux incidents ne puisse être négligé (pour plus d'informations sur la constitution d'une équipe CSIRT, voyez plus loin dans ce chapitre).

· Former les membres de l'équipe CSIRT à l'utilisation correcte des outils de sécurité essentiels et à la recherche de l'emplacement idéal pour les conserver. 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. L'accès à ces systèmes et à leurs outils doit être correctement protégé en cas de non-utilisation.

· Rassembler toutes les informations de communication pertinentes. Vous devez posséder les noms et numéros de téléphones des personnes à avertir au sein de votre organisation (y compris les membres de l'équipe CSIRT, les responsables du support technique pour tous les systèmes et les personnes chargées des relations avec les médias). Vous avez également besoin d'informations précises pour votre fournisseur de services Internet et pour les organismes locaux et nationaux chargés de l'application de la loi. N'hésitez pas à consulter l'autorité juridique locale concernée avant qu'un incident survienne. Vous serez ainsi mieux armé pour appliquer les procédures correctes de notification des incidents et de regroupement des preuves.

· 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 au 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, et ainsi de suite. Ces informations doivent être conservées dans un endroit sûr mais rester facilement accessibles. Pour cela, vous pouvez par exemple les crypter 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 du CSIRT, le directeur de l’information ou des technologies.

Constitution du noyau central du CSIRT

Le CSIRT (Computer Security Incident Response Team) est le centre névralgique chargé de la gestion des incidents de sécurité informatique dans votre environnement. Sa mission s'organise comme suit :

· analyser les systèmes à la recherche des violations de sécurité ;

· centraliser les communications, en recevant les rapports sur les incidents de sécurité et en distribuant les informations capitales aux entités voulues ;

· documenter et cataloguer les incidents de sécurité ;

· sensibiliser le personnel de l'entreprise aux problèmes de sécurité de façon à mieux prévenir les incidents ;

· promouvoir l'audit des systèmes et du réseau par l'application de processus tels que l'évaluation des vulnérabilités et les tests de pénétration ;

· se tenir informé des nouvelles vulnérabilités et stratégies d'attaque mises en œuvre par les pirates informatiques ;

· s'informer de la disponibilité des nouveaux correctifs ;

· analyser et développer de nouvelles technologies pour réduire les vulnérabilités et les risques liés à la 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.

La structure idéale d'une équipe CSIRT dépend du type de l'organisation et de la stratégie de gestion des risques mise en œuvre. En général, elle comprend une partie ou l'ensemble de vos équipes de sécurité. Le noyau central est constitué de professionnels de la sécurité chargés de la coordination des réponses aux incidents. Le nombre de membres que compte le CSIRT varie en fonction de la taille et de la complexité de l'organisation. Vérifiez néanmoins qu'il est suffisant pour que ce groupe puisse assurer correctement et à tout moment les missions qui lui sont confiées.

Responsable du CSIRT

Il est essentiel que le CSIRT soit dirigé par une seule et même personne. Le responsable est souvent chargé des activités du groupe, et il coordonne les révisions de ses actions. Celles-ci peuvent donner lieu à des changements dans les stratégies et les procédures de gestion des incidents futurs.

Responsable des incidents au sein du CSIRT

En cas d'incident, il doit y avoir une personne chargée de la coordination de la réponse. Le responsable des incidents au sein du CSIRT est chargé d'un incident spécifique ou d'un ensemble connexe d'incidents de sécurité. C'est lui qui assure la coordination de toutes les communications relatives à l'événement et qui est l'interlocuteur privilégié du CSIRT vis-à-vis de l'extérieur. Selon la nature de l'incident, une autre personne peut endosser cette responsabilité. Ce rôle est rarement cumulé avec celui de responsable du CSIRT.

Membres associés du CSIRT

Outre le noyau central du CSIRT, vous devez disposer d'un certain nombre de personnes capables de gérer des incidents particuliers et d'y réagir. Issus de services très divers de l'organisation, les membres associés du CSIRT sont spécialisés dans les domaines touchés par des incidents de sécurité, mais dont le noyau central ne s'occupe pas directement. Ces membres associés peuvent soit participer directement à la gestion d'un incident, soit servir d'intermédiaire en vue d'en déléguer la responsabilité à la personne adéquate au sein de leur service. Le tableau 10-1 ci-dessous présente quelques suggestions de membres associés ainsi que leurs rôles.

Tableau 10.1. Membres associés du groupe CSIRT

Membre associé Description du rôle

Contact informatique Principalement chargé de la coordination des communications entre le responsable des incidents du CSIRT et le reste du groupe informatique. Si cette personne ne doit pas nécessairement posséder les compétences techniques pour répondre immédiatement à un incident, son rôle consiste à trouver des ressources au sein du groupe informatique pour gérer des événements de sécurité particuliers.

Représentant juridique En général, il s'agit d'un membre du service juridique interne, familiarisé avec les stratégies en vigueur en matière de réponse aux incidents. Le représentant juridique détermine la procédure à suivre au cours d’un incident en définissant une responsabilité légale minimale et la capacité juridique maximale à traduire les contrevenants en justice.
Avant la survenue d'un incident, il doit avoir participé à l'élaboration des stratégies de surveillance et de réponse. De plus, il doit s'être assuré que l'organisation ne s'expose à aucun risque juridique à l'occasion d'une opération de nettoyage ou de réparation. Il est impératif 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 qu'il y a à ne pas arrêter un système compromis susceptible d'être à l'origine d'attaques et des responsabilités légales 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 des commissions d'enquête externes.

Responsable de la communication Souvent issu du département des relations publiques, le responsable de la communication est chargé de la protection et de la promotion de l'image de l'organisation.
S'il n'est pas toujours l'interlocuteur direct des médias et des clients, il a pour mission d'élaborer le message (étant entendu que le contenu et l'objectif du message sont en général sous la responsabilité de la direction). Toutes les requêtes émanant des médias doivent lui être adressées.

Direction Selon les cas, il s'agira de la direction du service ou de l'organisation. Tout dépend de l'impact, du lieu, de la gravité et du type de l'incident.
Vous devez être en mesure de contacter rapidement le membre adéquat de la direction selon la situation. La direction est chargée de l'approbation et de la conduite de la stratégie de sécurité.
Elle détermine également l'impact total (financier et autres) de l'incident sur l'organisation. Enfin, elle transmet les consignes à suivre au responsable de la communication quant aux informations à divulguer aux médias et détermine le niveau d'interaction entre le représentant juridique et les autorités juridiques.

Gestion d'un incident par le CSIRT

En cas d'incident, le CSIRT coordonne une réponse émanant du noyau central du CSIRT et communique avec les membres associés. Le tableau 10-2 suivant répertorie les responsabilités de chacun de ces intervenants lors du processus de réponse aux incidents.

Tableau 10.2. Responsabilités du CSIRT au cours du processus de réponse aux incidents

Activité	Rôle
	Responsable des incidents au sein du CSIRT	Contact informatique	Représentant juridique	Responsable de la communication	Direction
Évaluation initiale	Propriétaire	Conseil	Aucun	Aucun	Aucun
Réponse initiale	Propriétaire	Implémentation	Mise à jour	Mise à jour	Mise à jour
Collecte des preuves	Implémentation	Conseil	Propriétaire	Aucun	Aucun
Implémentation du correctif temporaire	Propriétaire	Implémentation	Mise à jour	Mise à jour	Conseil
Envoi du message	Conseil	Conseil	Conseil	Implémentation	Propriétaire
Vérification par rapport à la législation en vigueur	Mise à jour	Mise à jour	Implémentation	Mise à jour	Propriétaire
Implémentation du correctif définitif	Propriétaire	Implémentation	Mise à jour	Mise à jour	Mise à jour
Évaluation de l'impact financier sur l'entreprise	Mise à jour	Mise à jour	Conseil	Mise à jour	Propriétaire

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

Tous les membres de votre environnement informatique doivent savoir comment réagir face à un incident. Si le 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 finals informent directement le personnel informatique des activités suspectes ou s'adressent à l'assistance technique mais ils ne contactent pas directement le CSIRT.

Le plan de réponse aux incidents est alors étudié en détail par tous les membres de l'équipe et mis à la disposition de l'ensemble du personnel du service informatique. De cette manière, le respect des procédures correctes est garanti en cas d'incident.

Le plan de réponse aux incidents doit inclure les étapes ci-après :

· évaluation initiale ;

· communication de l'incident ;

· minimisation des dommages et du risque ;

· identification du type et de la gravité du compromis ;

· protection des preuves ;

· notification aux organismes externes ;

· récupération des systèmes ;

· compilation et organisation de la documentation sur l'incident ;

· évaluation des dommages et des coûts de l'incident ;

· révision de la réponse et mise à jour des stratégies.

Remarque : L'aide-mémoire sur la réponse aux incidents (documents en anglais, JA1001.doc) peut servir de liste de contrôle pendant un incident, afin de s'assurer que toutes les phases ont été exécutées correctement.

Ces étapes ne se déroulent pas toujours de façon séquentielle. Elles surviennent 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 minimiser les dommages et le risque dès que possible. Si vous agissez rapidement, vous gagnerez du temps et de l'argent, et vous préserverez 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 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 menant de front ces deux batailles, vous obtiendrez le compromis idéal 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 qu'un incident ne survienne. 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 ressembler à une attaque lancée par un tiers. Dans d'autres cas, un système mal configuré peut provoquer de fausses alertes dans un système de détection des intrusions, ce qui complique la détection des vrais incidents.

L'évaluation initiale s'organise comme suit :

· Vous devez déterminer avant tout si vous êtes confronté à un incident réel ou à une fausse alerte.

· Vous devez avoir une idée globale 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 le risque.

· Vous devez 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

Après avoir décelé un incident de sécurité potentiel, vous devez rapidement informer le reste des membres du noyau central du CSIRT de la violation de sécurité. Le responsable des incidents, conjointement avec le reste du groupe, doit rapidement identifier les personnes à contacter en dehors du groupe. Cela permet de conserver la maîtrise de l'incident, d'en assurer la coordination et de minimiser l'ampleur des dégâts. Sachez que les dommages peuvent se présenter sous plusieurs 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 groupe déterminera ultérieurement qui doit être prévenu. Il peut s'agir de personnes isolées dans l'entreprise, de l'ensemble du personnel et de clients externes.

Minimisation des dégâts et du risque

En agissant activement pour réduire les effets réels et potentiels d'une attaque, vous pouvez faire la différence entre un événement mineur et un événement majeur. La RFC 2196 définit une série de priorités permettant de contenir les dommages dans un environnement. La réponse exacte dépend de l'organisation et de la nature de l'attaque à laquelle elle doit faire face. Vous pouvez toutefois envisager les priorités suivantes comme point de départ :

1. Protection de la vie humaine et de la sécurité des personnes. Telle est bien évidemment la priorité numéro un dans tous les cas.

2. Protection des données sensibles ou confidentielles. Lors de la planification de la réponse aux incidents, vous devez définir clairement quelles sont les données confidentielles et sensibles. Vous êtes ainsi plus à même d'affecter un ordre de priorité aux données à protéger.

3. Protection des autres données, notamment les données propriétaires, scientifiques et de gestion. D'autres données de l'environnement peuvent avoir de la valeur. Vous devez en premier lieu protéger les données stratégiques avant de vous occuper des données moins importantes.

4. Protection du matériel et des logiciels contre les attaques. Il faut notamment se prémunir contre la perte ou l'altération des fichiers système ou encore contre les dommages physiques du matériel. Les dommages causés aux systèmes peuvent provoquer des périodes d'arrêt très coûteuses.

5. Limitation de la durée d'interruption du fonctionnement des ressources informatiques (processus inclus). Bien que la disponibilité d'un système soit très importante dans la majorité des environnements, le maintenir opérationnel à tout prix au cours d'une attaque peut entraîner des problèmes plus graves par la suite. Par conséquent, la limitation de la durée d'interruption du fonctionnement arrive en dernier dans les priorités.

Vous pouvez appliquer un certain nombre de mesures pour limiter les dommages et les risques au sein de l'environnement, et partant :

· Essayer de faire en sorte que les auteurs de l'attaque ne se sachent pas découverts. Cette tâche peut être délicate puisque certaines mesures de réponse peuvent les alerter. En effet, un intrus interne peut savoir que vous soupçonnez un incident si, par exemple, une réunion d'urgence du CSIRT est organisée ou que vous demandez le changement immédiat de tous les mots de passe.

· Comparer le coût de mise hors service des systèmes compromis et des systèmes connexes au risque posé par la poursuite des opérations. Le plus souvent, vous devez immédiatement déconnecter le système du réseau. Toutefois, il se peut que certains accords de niveau de service (SLA) en vigueur nécessitent la disponibilité des systèmes, même si cela risque d’entraîner d’autres dommages. Si tel est le cas, vous pouvez choisir de conserver un système en ligne avec toutefois une connectivité limitée. Vous pouvez ainsi 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 graves que vous pouvez être amené à 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 les points d'accès utilisés par l'intrus et mettre en œuvre des mesures permettant d'éviter que ces failles soient exploitées à l'avenir. 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 bien l'ajout des dispositifs et procédés de sécurité physiques.

· Penser à 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 coupables). Veillez à modifier tous les mots de passe locaux, ainsi que les mots de passe des comptes d'administration et de service partout ailleurs dans l'environnement.

Identification de la gravité des préjudices subis

Pour rétablir le fonctionnement normal des systèmes à la suite d'une attaque, vous devez déterminer l'importance des dommages subis. Vous saurez ainsi quelle approche adopter par la suite pour minimiser le risque, le 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-elle votre organisation en particulier et des informations spécifiques, ou était-ce une attaque casuelle ?) ;

· les systèmes compromis ;

· les fichiers auxquels des personnes ont accédé et dans quelle mesure ils contiennent des informations sensibles.

Une fois ces détails identifiés, vous serez en mesure de déterminer les réponses qui s'imposent en fonction de l'environnement. Un plan de réponse aux incidents efficace indique 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. Comme le temps est précieux dans ce type de situation, les procédures rapides précèdent souvent les procédures plus longues. Pour mesurer plus facilement la gravité des préjudices subis, procédez comme suit :

· Contactez les autres membres de l'équipe de réponse aux incidents pour les informer de vos découvertes et les laisser vérifier les résultats. Demandez-leur s’ils sont au courant d’activités connexes ou d'autres attaques potentielles et aidez-les à déterminer s'il s'agit d'une fausse alerte. Dans certains cas, ce qui semble être un véritable incident d'après l'évaluation initiale s'avère être une fausse alerte.

· Déterminez si du matériel non autorisé a été connecté au réseau ou si certains signes semblent indiquer un accès non autorisé par la transgression des contrôles de sécurité physiques.

· Examinez les groupes principaux (Administrateurs de domaine, Administrateurs, etc.) afin de vous assurer qu'ils ne contiennent pas de membres non autorisés.

· Recherchez d'éventuels logiciels d'exploitation ou d'évaluation de la sécurité. À l'occasion du recueil de preuves, des utilitaires de décodage illégal sont souvent découverts sur les systèmes compromis.

· Recherchez des processus ou des applications non autorisés en cours d'exécution ou dont l'exécution est planifiée, par l'analyse des dossiers de démarrage ou des entrées du Registre.

· Examinez les journaux système pour vérifier la présence ou l'absence de violations de sécurité.

· Recherchez d'éventuels indices d'intrusion dans les journaux système de détection des intrusions, les systèmes susceptibles d'avoir subi des dommages, les méthodes employées pour l'attaque, l'heure et la durée de l'attaque et l'étendue globale des dégâts potentiels.

· Examinez 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 échecs de tentatives d'ouverture de session, 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.

· Comparez 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 ainsi que les changements de contrôle et d'autorisations présents dans le système de fichiers et le Registre. Si vous identifiez les éléments compromis et les domaines qui nécessitent des mesures de récupération, vous gagnerez un temps précieux lors de la réponse aux incidents.

· Recherchez des données sensibles (comme des numéros de carte de crédit et des données relatives aux clients ou aux employés) qui auraient pu être 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 susceptibles de vous aider dans votre enquête. Si de telles recherches risquent d'enfreindre la sécurité ou la législation, contactez votre service juridique avant de poursuivre.

· Comparez les performances des systèmes suspects par rapport aux niveaux de performances de référence. Il est clair que cette opération n'est possible que si des critères de référence ont été établis et mis à jour correctement. Pour plus d'informations sur la création d'une ligne de base en matière de performances, reportez-vous au chapitre 27 du Kit de ressources de Windows 2000 Professionnel (Microsoft Press, ISBN : 1-57231-808-2), « Overview of Performance Monitoring » (Présentation de l'analyse des performances).

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 peuvent prévoir l'imminence d'une attaque tandis que d'autres outils permettent d'identifier les modifications apportées aux fichiers sur vos systèmes. Pour plus d’informations sur ces outils, consultez le chapitre 9, « Audit et détection des intrusions ».

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 coupables. Vous serez alors amené à réunir des preuves qui, le cas échéant, seront utilisées contre eux. Il est très important de sauvegarder les systèmes compromis dans les meilleurs délais, et ce, avant d'effectuer 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 sert uniquement de preuve pour poursuivre les coupables ; elle doit être conservée en lieu sûr jusqu'à son utilisation. Les autres sauvegardes peuvent servir à la récupération des données. Comme elles servent à des fins juridiques, il est nécessaire de les protéger physiquement. Vous devez également documenter tout ce qui a trait aux sauvegardes, notamment leurs auteurs, les dates de création, les mesures prises pour les protéger et toutes les personnes qui y ont eu accès.

Une fois les sauvegardes effectuées, il faut retirer les disques durs d'origine et les stocker 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 conservation 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 sont pas réalisables. Il est préférable de sauvegarder tous les fichiers journaux ainsi qu'une sélection de parties endommagées.

Si possible, sauvegardez aussi l'é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 irréfutables. Signez et datez chaque page de cette 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 reconstruire de nouveaux. L'organisation peut ainsi reprendre rapidement une activité normale. 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 faut recourir à une sauvegarde distincte de celle utilisée pour la procédure judiciaire.

Notification aux organismes externes

Une fois l'incident maîtrisé et les données sauvegardées en vue de poursuites éventuelles, vous devez en informer les entités externes appropriées. Parmi celles-ci, citons les organismes locaux et nationaux chargés 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 similaires. Cela peut vous aider dans la procédure de récupération du système et permet d'éviter que l'incident se reproduise.

Dans certains secteurs d'activités et types de violations spécifiques, il est parfois nécessaire d'avertir des clients particuliers ou le public en général, notamment si l'incident a 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 organismes chargés de l'application de la loi.

Dans le cas d'entreprises et d'incidents de grande envergure, l'information doit parfois être communiquée aux médias. 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 ; elle est par ailleurs bénéfique pour l'entreprise, qui témoigne ainsi d'une attitude proactive en signalant l'incident. En revanche, il est indispensable que les procédures de réponse aux incidents définissent clairement les personnes autorisées à s'adresser aux médias. En principe, il s'agit du département des relations publiques de l'organisation. Il est souvent déconseillé de nier qu'un incident est survenu. 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. Cela ne veut pas dire qu'il faut informer les médias de chaque incident, quelle que soit sa nature ou sa gravité. En fait, la réaction à adopter face aux médias doit être décidée au cas par cas.

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 le plus possible intact ou s'il faut le reconstruire complètement.

La restauration des données suppose que vous disposiez de sauvegardes dites « 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 juste avant l'alerte est valable et qu'elle doit être conservée pour la reconstruction du système compromis.

Il est possible qu'un incident endommage des données pendant quelques 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

Le CSIRT doit documenter en détail tous les processus de gestion de l'incident. Il doit pour cela fournir notamment une description de la violation de sécurité et des détails sur chaque action entreprise (responsable, 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 protéger les preuves réunies lors de la phase concernée. Il est préférable que deux personnes soient présentes pendant toutes les phases, pour valider chacune d'elles par sa signature. Vous réduirez ainsi les risques que des preuves soient considérées comme inacceptables ou modifiées après les faits.

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 ardue. Une documentation correcte est é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, pensez à la fois aux coûts directs et aux coûts indirects, parmi lesquels :

· 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 du personnel requis pour 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 auprès des clients ou la perte de confiance de la part de ces derniers.

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. Il vous faudra probablement modifier l'une ou l'autre procédure de façon à améliorer à l'avenir la gestion des incidents.

Il est logique que vous découvriez 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 » prévu ici. L'exercice a pour but d'identifier les domaines à améliorer, point de départ d'un tout nouveau processus de planification de la réponse aux incidents.

Scénario : gestion des incidents au sein de la société Contoso

Pour illustrer la manière dont sont gérées les différentes étapes de la réponse aux incidents en cas d'attaque, une étude de cas montre la réaction adoptée par le groupe CSIRT de la société Contoso face à une infection par le virus Code Red II. Même s'il s'agit d'une étude de cas fictive, elle met en lumière des mesures réalistes, très similaires à celles adoptées par les organisations réelles en cas d'attaque.

Tableau 10.3. Étude de cas de Contoso

Étape de réponse à l'incident Action entreprise

Évaluation initiale Membre du centre d'appel du CSIRT, Samantha Smith reçoit par radiomessagerie une courte description d'un événement enregistré par le système de détection des intrusions de Contoso. Le système indique un incident potentiel, causé par le virus Code Red II sur le serveur Web, WEB2. Samantha examine le fichier journal IIS de WEB2 pour y rechercher la chaîne de signature du virus et vérifie la présence de root.exe dans c:\inetpub\scripts. Les résultats de ces investigations laissent penser qu'il ne s'agit pas d'une fausse alerte.

Communication de l'incident Samantha avertit par téléphone le reste du CSIRT pour leur faire part de ses constatations initiales. Elle s'engage à leur communiquer des détails supplémentaires dès qu'ils seront disponibles.

Minimisation des dommages et des risques La stratégie de réponse aux incidents de Contoso stipule que la vérification de la présence d'un ver requiert le retrait du système visé du réseau. Samantha débranche le câble qui relie WEB2 au réseau. Heureusement, WEB2 fait partie d'un ensemble de serveurs à équilibrage de charge, si bien que les clients n'ont à subir aucun temps d'immobilisation.

Communication de l'incident Samantha communique ses conclusions aux autres membres du CSIRT par courrier électronique et contacte directement le responsable du CSIRT.

Ce dernier désigne Taylor Maxwell, directeur du département de la sécurité informatique, comme responsable de la gestion de l'incident. Taylor est chargé de coordonner toutes les activités ainsi que les communications échangées avec le noyau principal du CSIRT.

Taylor avertit le directeur des technologies et l'équipe informatique de service que le serveur Web a été déconnecté du réseau et qu'il sera débarrassé du ver avant sa reconnexion.

Il informe également la direction, le responsable de la communication et le représentant juridique, qui l'invite à suivre les procédures requises pour rassembler des preuves, bien qu'une action en justice soit impossible.

Identification de la gravité des préjudices subis Samantha analyse les fichiers journaux des autres serveurs pour déterminer si le ver s'est propagé. Elle découvre que ce n'est pas le cas.

Minimisation des dommages et des risques Un autre membre du CSIRT, Robert Brown, exécute l'utilitaire Microsoft Baseline Security Analyzer (MBSA). Cet outil permet aux administrateurs de s'assurer, à partir d'un emplacement central, que tous les serveurs Microsoft® Windows NT® version 4.0, Windows 2000, et Microsoft® Windows® XP sont dotés de correctifs à jour. Dans ce cas particulier, Robert vérifie si les autres serveurs sont dotés du correctif concernant le virus Code Red II : il constate que deux autres serveurs n'ont pas été mis à jour et leur applique immédiatement le correctif requis.

Identification de la gravité des préjudices subis Robert effectue une analyse plus approfondie des fichiers journaux de tous les autres serveurs IIS et ne trouve aucune trace d'une instance de Code Red II pour l'instant.

Protection des preuves Tout indique que seul WEB2 a été touché. Ayant réussi à limiter raisonnablement les dégâts et invité par le service juridique à réunir des preuves, Taylor décide de se mettre immédiatement au travail, avant qu'une analyse du système plus poussée vienne altérer ou détruire des preuves. D'autres membres de l'équipe continuent à surveiller les autres serveurs Web et à consigner des informations sur les activités suspectes.

Un membre du CSIRT formé pour rassembler des preuves judiciaires crée deux instantanés (des sauvegardes physiques complètes) du système compromis. Le premier est conservé soigneusement en vue de l'enquête judiciaire à venir. Le second pourra être utilisé dans le cadre du processus de récupération, en complément des sauvegardes propres et sécurisées effectuées avant l'événement. Des supports neufs non réinscriptibles ont été employés pour la sauvegarde réalisée à des fins judiciaires. Conformément à la stratégie de sécurité, cette sauvegarde est soigneusement documentée, scellée et placée en lieu sûr, avec les disques durs du serveur.

Identification du type et de la gravité de l'attaque L'ordinateur portable équipé du jeu d’outils de sécurité (notamment à usage judiciaire) de l'organisation permet de rechercher dans la sauvegarde de récupération des signes pouvant laisser présager des dégâts supplémentaires. Les entrées du Registre et les dossiers sont passés en revue pour effectuer des recherches dans les zones d'exécution de logiciels au démarrage, tels que les répertoires de profils/démarrage, les clés de Registre Run et RunOnce. Les comptes d'utilisateur et de groupe sont également analysés, parallèlement aux stratégies de sécurité et aux droits des utilisateurs, de façon à détecter d'éventuelles modifications. Un examen des journaux de sécurité vise à identifier toute autre activité suspecte.

Notification aux organismes externes Dans la mesure où Contoso participe à d'importants projets de sécurité publics aux États-Unis, Taylor signale l'incident au National Infrastructure Protection Center du FBI.

Comme les informations sur les clients et l'accès aux systèmes n'ont pas été compromis, les clients ne sont pas informés de l'attaque.

Récupération des systèmes Bien qu'il existe des outils capables d'éradiquer Code Red II de WEB2, le CSIRT et l'équipe de support technique de WEB2 choisissent de réinstaller le système d'exploitation sur de nouveaux supports. Cette décision et le recours au Microsoft Security Toolkit leur garantit un système « propre », n'offrant aucune porte d'entrée aux pirates et dépourvu de fichiers endommagés.

Une fois Windows 2000 réinstallé, un verrou de sécurité est appliqué au système, conformément aux consignes spécifiées dans les chapitres 5 à 7 de ce guide.
Une sauvegarde non infectée est localisée puis, conformément aux procédures documentées, les données sont restaurées. Si les données sont disponibles uniquement à partir de la sauvegarde compromise, elles sont restaurées sur un système hors connexion distinct, puis réintégrées sur WEB2 lorsqu'il a été prouvé qu'elles ne présentent plus le moindre danger de contamination.

Le CSIRT effectue une évaluation complète des vulnérabilités du système en documentant toutes les informations découvertes dans le processus.

WEB2 est reconnecté au réseau, puis placé sous surveillance afin d'identifier immédiatement tout signe de nouvelle infection.

Compilation et organisation des preuves

relatives à l'incident Taylor et le CSIRT recherchent l'origine de la vulnérabilité : ils découvrent que le système a été récemment réinstallé et que les correctifs n'ont pas été appliqués. Cette omission va évidemment à l'encontre de la stratégie en vigueur, pourtant clairement définie.
Trois négligences expliquent cet événement. Tout d'abord, les membres de l'équipe de support technique n'ont pas réinstallé les correctifs. Ensuite, le service de sécurité informatique n'a pas audité les correctifs appliqués de façon opportune. Et enfin, le groupe de gestion de la configuration n'a pas identifié le besoin d'appliquer des correctifs et n'a pas demandé à l'équipe chargée de la sécurité informatique de vérifier le système avant sa « remise en ligne ». Le respect de l'une de ces procédures au moins aurait permis d'éviter l'incident.
Le CSIRT décide de mettre en œuvre une nouvelle procédure pour éviter qu'un tel incident ne se reproduise. Il élabore une liste de contrôle qui doit être complétée par chacune des entités responsables de la gestion des modifications, du support du serveur Web et de la sécurité informatique, avant que ce dernier service n'approuve la réintégration d'un système dans le réseau interne. Cette liste doit être mise en œuvre avant que le service de sécurité informatique ne reconfigure le pare-feu pour permettre l'accès externe en provenance ou à destination de ce système. Le département chargé de l'audit doit également vérifier régulièrement que les listes de contrôle sont complétées de façon précise et exhaustive.
Taylor et le CSIRT compilent toute la documentation pour déterminer les tâches de réponse à l'incident effectuées, la durée de chacune d'entre elles et la personne qui les a mises en œuvre. Ces informations sont envoyées aux services financiers pour qu'ils calculent les coûts, conformément aux normes comptables (les « Generally-Accepted Accounting Principles » aux États-Unis), portant sur les dommages informatiques.
Le responsable du CSIRT s'assure que la direction est consciente du coût total de l'incident, des raisons pour lesquelles celui-ci a pu se produire et des mesures à prendre pour éviter qu'il ne se reproduise. Il est important que la direction comprenne les conséquences sérieuses que peuvent avoir le manque de procédures ou le non-respect de celles-ci ainsi que l'absence de ressources (telles le CSIRT) en place.
La documentation globale sur l'incident, les leçons tirées ainsi que les stratégies, suivies ou non, sont passées en revue par les membres de l'équipe concernée.
La documentation et les procédures relatives à la mise en œuvre de poursuites judiciaires sont analysées par le représentant juridique, le responsable du CSIRT, le responsable des incidents au sein du CSIRT et la direction.

Résumé

Ce chapitre traite principalement des mesures à prendre pour minimiser les risques d'attaque. Toutefois, l'approche idéale pour une organisation en matière de gestion de la sécurité consiste à admettre qu'une attaque est possible et à mettre tout en œuvre pour limiter un tel risque. Dans le cadre de ce processus, il faut notamment mettre en place un audit approfondi de l'attaque (reportez-vous au chapitre 9, « Audit et détection des intrusions »), mais il est tout aussi important de définir un ensemble de réactions à adopter en cas d'attaque.

Autres références

Hacking Exposed Windows 2000, par Joel Scambray et Stuart McClure (McGraw-Hill Professional Publishing, ISBN : 0072192623).

Computer Security Institute : publication d'une étude annuelle intitulée « Computer Crime and Security Survey » (http://www.gocsi.com).

Informations complémentaires

Handbook for Computer Security Incident Response Teams :
http://interactive.sei.cmu.edu/Recent_Publications/1999/March/98hb001.htm.

Forum of Incident Response and Security Teams (FIRST) :

http://www.polarisgroup.com/products.asp

Incident Response : Investigating Computer Crime, par Chris Prosise et Kevin Mandia (McGraw-Hill Professional Publishing, ISBN : 0072131829).

The Internet Security Guidebook : From Planning to Deployment, par Juanita Ellis, Tim Speed et William P. Crowell (Academic Pr, ISBN : 0122374711).

RFC 2196 : http://www.ietf.org/rfc/rfc2196.txt?number=2196.

Chapitre 27, « Overview of Performance Planning », du Kit de ressources techniques de Windows 2000 Professionnel :

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000pro/reskit/part6/proch27.asp (en anglais).

Commande d'un exemplaire gratuit du Microsoft Security Toolkit : http://www.microsoft.com/security/kitinfo.asp.

Cert Coordination Center (CERT/CC) : http://www.cert.org/