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.