Guide de Gestion Des Incidents de Sécurité Informatique - NIST [PDF]

Zitiervorschau

21/10/2020

Guide de gestion des incidents de sécurité informatique

Page 1

Publication spéciale 800-61 Révision 2

Sécurité informatique Guide de gestion des incidents Recommandations de l'Institut national des normes et de la technologie Paul Cichonski Tom Millar Tim Grance Karen Scarfone http://dx.doi.org/10.6028/NIST.SP.800-61r2

Page 2

Publication spéciale NIST 800-61 Révision 2

https://translate.googleusercontent.com/translate_f

Gestion des incidents de sécurité informatique Guider 1/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Recommandations du National Institut des normes et de la technologie Paul Cichonski Division de la sécurité informatique Laboratoire de technologie de l'information Institut national des normes et de la technologie Gaithersburg, MD Tom Millar Équipe de préparation aux urgences informatiques des États-Unis Division nationale de la cybersécurité département de la Sécurité intérieure Tim Grance Division de la sécurité informatique Laboratoire de technologie de l'information Institut national des normes et de la technologie Gaithersburg, MD Karen Scarfone Cybersécurité Scarfone

http://dx.doi.org/10.6028/NIST.SP.800-61r2

SÉCURITÉ INFORMATIQUE Août 2012

Département américain du commerce

Rebecca Blank, secrétaire par intérim

Institut national des normes et de la technologie

Patrick D. Gallagher, Sous-secrétaire au commerce pour les normes et la technologie et directeur

Page 3 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Rapports sur la technologie des systèmes informatiques Le laboratoire de technologie de l'information (ITL) de l'Institut national des normes et de la technologie (NIST) promeut l'économie américaine et le bien-être public en fournissant un leadership technique pour la Nation infrastructure de mesure et de normalisation. ITL développe des tests, des méthodes de test, des données de référence, des preuves de implémentations de concepts et analyses techniques pour faire progresser le développement et l'utilisation productive de informatique. Les responsabilités d'ITL comprennent le développement de la gestion, de l'administration, normes et directives techniques et physiques pour la sécurité et la confidentialité rentables informations relatives à la sécurité nationale dans les systèmes d'information fédéraux. La publication spéciale série 800 rend compte des recherches, des lignes directrices et des efforts de sensibilisation d'ITL en matière de sécurité des systèmes d'information, ainsi que activités de collaboration avec l'industrie, le gouvernement et les organisations universitaires.

https://translate.googleusercontent.com/translate_f

2/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

ii

Page 4 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Autorité Cette publication a été développée par le NIST pour approfondir ses responsabilités statutaires en vertu de la Loi sur la gestion de la sécurité de l'information (FISMA), droit public (PL) 107-347. Le NIST est responsable de élaborer des normes et des lignes directrices sur la sécurité de l'information, y compris des exigences minimales pour les systèmes d'information, mais ces normes et directives ne s'appliquent pas aux systèmes de sécurité nationaux sans l'approbation expresse des fonctionnaires fédéraux compétents exerçant l'autorité politique sur ces systèmes. Cette directive est conforme aux exigences du Bureau de la gestion et du budget (OMB) Circulaire A-130, section 8b (3), Systèmes d'information des agences de sécurité , telle qu'analysée dans la circulaire A130, Annexe IV: Analyse des sections clés . Des informations supplémentaires sont fournies dans la circulaire A-130, Annexe III, Sécurité des ressources d'information automatisées fédérales . Rien dans cette publication ne doit être considéré comme contraire aux normes et directives rendues obligatoires et lier les agences fédérales par le secrétaire au commerce sous l'autorité statutaire. Ne devrait pas non plus ces directives doivent être interprétées comme modifiant ou remplaçant les pouvoirs existants du Secrétaire de Commerce, directeur de l'OMB ou tout autre fonctionnaire fédéral. Cette publication peut être utilisée par organisations non gouvernementales sur une base volontaire et n'est pas soumis au droit d'auteur aux États-Unis. Une attribution serait cependant appréciée par le NIST.

Publication spéciale 800-61 Révision 2 de l'Institut national des normes et de la technologie Natl. Inst. Supporter. Technol. Spec. Publ. 800-61 Révision 2, 79 pages (août 2012) CODEN: NSPUE2

http://dx.doi.org/10.6028/NIST.SP.800-61r2 Certaines entités commerciales, équipements ou matériaux peuvent être identifiés dans ce document afin de décrire un procédure expérimentale ou concept adéquat. Cette identification ne vise pas à impliquer une recommandation ou l'endossement par le NIST, et il n'est pas destiné à impliquer que les entités, les matériaux ou l'équipement sont nécessairement les meilleur disponible pour le but. Il peut y avoir des références dans cette publication à d'autres publications actuellement en cours de développement par le NIST conformément aux responsabilités statutaires qui lui sont assignées. Les informations contenues dans cette publication, y compris les concepts et méthodologies, peuvent être utilisées par les agences fédérales avant même l'achèvement de ces publications. Ainsi, jusqu'à ce que chaque publication soit terminée, les exigences, lignes directrices et procédures actuelles, où ils existent, restent opérationnels. À des fins de planification et de transition, les organismes fédéraux souhaiteront peut-être suivre de près le développement de ces nouvelles publications par le NIST. Les organisations sont encouragées à examiner tous les projets de publications pendant les périodes de commentaires publics et à fournir retour d'information au NIST. Toutes les publications du NIST, autres que celles mentionnées ci-dessus, sont disponibles sur http://csrc.nist.gov/publications.

https://translate.googleusercontent.com/translate_f

3/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Les commentaires sur cette publication peuvent être soumis à: Institut national des normes et de la technologie À l'attention de: Division de la sécurité informatique, Laboratoire des technologies de l'information 100 Bureau Drive (Mail Stop 8930), Gaithersburg, MD 20899-8930

iii

Page 5 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Abstrait La réponse aux incidents de sécurité informatique est devenue une composante importante des technologies de l'information (TI) programmes. Parce qu'intervenir efficacement en cas d'incident est une entreprise complexe, établir un une capacité d'intervention efficace en cas d'incident nécessite une planification et des ressources importantes. Cette publication aide les organisations à mettre en place des capacités de réponse et à gérer les incidents de sécurité informatique incidents de manière efficace et efficiente. Cette publication fournit des directives pour la gestion des incidents, en particulier pour analyser les données relatives aux incidents et déterminer la réponse appropriée à chaque incident. Les directives peuvent être suivies indépendamment des plates-formes matérielles, des systèmes d'exploitation, protocoles ou applications.

Mots clés incident de sécurité informatique; gestion des incidents; réponse aux incidents; sécurité de l'information

iv

https://translate.googleusercontent.com/translate_f

4/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Page 6 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Remerciements Les auteurs, Paul Cichonski du National Institute of Standards and Technology (NIST), Tom Millar de l'équipe de préparation aux urgences informatiques des États-Unis (US-CERT), Tim Grance du NIST et Karen Scarfone de Scarfone Cybersecurity tient à remercier ses collègues qui ont révisé les brouillons de ce document et contribué à son contenu technique, y compris John Banghart du NIST; Brian Allen, Mark Austin, Brian DeWyngaert, Andrew Fuller, Chris Hallenbeck, Sharon Kim, Mischel Kwon, Lee Rock, Richard Struse et Randy Vickers de l'US-CERT; et Marcos Osorno de l'Université Johns Hopkins Applied Laboratoire de physique. Une reconnaissance spéciale va à Brent Logan de US-CERT pour ses graphismes assistance. Les auteurs tiennent également à remercier les experts en sécurité Simon Burson, Anton Chuvakin (Gartner), Fred Cohen (Fred Cohen & Associates), Mariano M. del Rio (SIClabs), Jake Evans (Tripwire), Walter Houser (SRA), Panos Kampanakis (Cisco), Kathleen Moriarty (EMC), David Schwalenberg (Agence de sécurité nationale) et Wes Young (Partage d'informations sur les réseaux de recherche et d'éducation and Analysis Center [REN-ISAC]), ainsi que des représentants du Blue Glacier Management Group, le Centres pour le contrôle et la prévention des maladies, le Département de l'énergie, le Département d'État et le Federal Aviation Administration pour leurs commentaires et suggestions particulièrement précieux. Les auteurs tiennent également à remercier les personnes qui ont contribué aux versions précédentes de la publication. Un merci spécial à Brian Kim de Booz Allen Hamilton, qui a co-écrit le version originale; à Kelly Masone du Blue Glacier Management Group, qui a co-écrit la première révision; et également à Rick Ayers, Chad Bloomquist, Vincent Hu, Peter Mell, Scott Rose, Murugiah Souppaya, Gary Stoneburner et John Wack du NIST; Don Benack et Mike Witt de l'US-CERT; et Debra Banning, Pete Coleman, Alexis Feringa, Tracee Glass, Kevin Kuhlkin, Bryan Laird, Chris Manteuffel, Ron Ritchey et Marc Stevens de Booz Allen Hamilton pour leur assistance attentive et perspicace tout au long de la développement du document, ainsi que Ron Banerjee et Gene Schultz pour leurs travaux sur un brouillon du document. Les auteurs souhaitent également exprimer leurs remerciements aux experts en sécurité Tom Baxter (NASA), Mark Bruhn (Université de l'Indiana), Brian Carrier (CERIAS, Purdue University), Eoghan Casey, Johnny Davis, Jr. (ministère des Anciens Combattants), Jim Duncan (BB&T), Dean Farrington (Wells Fargo Bank), John Hale (Université de Tulsa), Georgia Killcrece (CERT ® / CC), Barbara Laswell (CERT ® / CC), Pascal Meunier (CERIAS, Purdue University), Jeff Murphy (University of Buffalo), Todd O'Boyle (MITRE), Marc Rogers (CERIAS, Purdue University), Steve Romig (Ohio State University), Robin Ruefle (CERT ® / CC), Gene Schultz (Lawrence Berkeley National Laboratory), Michael Smith (États-Unis CERT), Holt Sorenson, Eugene Spafford (CERIAS, Purdue University), Ken van Wyk et Mark Zajicek (CERT ® / CC), ainsi que des représentants du Département du Trésor, pour leur commentaires et suggestions.

v

Page 7 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Table des matières Résumé ................................................ .................................................. ............... 1 1.

Introduction ................................................. .................................................. ................... 4 1.1 Autorité ................................................ .................................................. .................. 4 1.2 Objet et portée .............................................. .................................................. ... 4 1.3 Public ................................................ .................................................. ................. 4 1.4 Structure du document ............................................... .................................................. 4

2.

Organisation d'une capacité de réponse aux incidents de sécurité informatique ........................... 6 2.1 Événements et incidents .............................................. .................................................. 6

https://translate.googleusercontent.com/translate_f

5/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 2.2 Besoin d'intervention en cas d'incident ............................................. ......................................... 6 2.3 Création d'une politique, d'un plan et d'une procédure de réponse aux incidents ........................................ .. 7 2.3.1 Éléments de politique ............................................. ................................................ 7 2.3.2 Éléments du plan ............................................. .................................................. 8 2.3.3 Éléments de procédure ............................................. ......................................... 8 2.3.4 Partage d'informations avec des tiers .......................................... ............ 9 2.4 Structure de l'équipe d'intervention en cas d'incident ............................................. ............................ 13 2.4.1 Modèles d'équipe ............................................. .................................................. 13 2.4.2 Sélection du modèle d'équipe ............................................ ...................................... 14 2.4.3 Personnel d'intervention en cas d'incident ............................................ ........................... 16 2.4.4 Dépendances au sein des organisations ............................................ ................. 17 2.5 Services de l'équipe d'intervention en cas d'incident ............................................. ............................. 18 2.6 Recommandations ................................................ .................................................. 19 3.

Gestion d'un incident ............................................... .................................................. ...... 21 3.1 Préparation ................................................ .................................................. ............ 21 3.1.1 Préparation à la gestion des incidents ........................................... ........................... 21 3.1.2 Prévention des incidents ............................................. ........................................ 23 3.2 Détection et analyse .............................................. .............................................. 25 3.2.1 Vecteurs d'attaque ............................................. ................................................. 25 3.2.2 Signes d'un incident ........................................... ........................................... 26 3.2.3 Sources de précurseurs et indicateurs .......................................... ................. 27 3.2.4 Analyse des incidents ............................................. ............................................. 28 3.2.5 Documentation des incidents ............................................. ................................... 30 3.2.6 Hiérarchisation des incidents ............................................. ....................................... 32 3.2.7 Notification d'incident ............................................. ......................................... 33 3.3 Confinement, éradication et récupération ........................................... ...................... 35 3.3.1 Choix d'une stratégie de confinement ........................................... ..................... 35 3.3.2 Collecte et traitement des preuves ........................................... ..................... 36 3.3.3 Identification des hôtes attaquants ........................................... .......................... 37 3.3.4 Éradication et rétablissement ............................................ ................................ 37 3.4 Activité post-incident ............................................. .................................................. 38 3.4.1 Leçons apprises ............................................. ............................................. 38 3.4.2 Utilisation des données d'incident collectées ........................................... ........................... 39 3.4.3 Conservation des preuves ............................................. ......................................... 41 3.5 Liste de contrôle pour la gestion des incidents .............................................. ....................................... 42 3.6 Recommandations ................................................ .................................................. 42

4.

Coordination et partage d'informations .............................................. ............................ 45

vi

Page 8 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

4.1 Coordination ................................................ .................................................. .......... 45 4.1.1 Relations de coordination ............................................. ............................. 46 4.1.2 Accords de partage et exigences en matière de rapports ....................................... 47 4.2 Techniques de partage d'informations .............................................. ................................ 48 4.2.1 Ad Hoc ............................................. .................................................. .......... 48 4.2.2 Partiellement automatisé ............................................. ......................................... 48 4.2.3 Considérations relatives à la sécurité ............................................. .................................. 49 4.3 Partage d'informations granulaires .............................................. .................................... 49 4.3.1 Informations d'impact sur l'activité ............................................ ............................ 49 4.3.2 Informations techniques ............................................. ...................................... 50 4.4 Recommandations ................................................ .................................................. 51

Liste des annexes Annexe A - Scénarios de gestion des incidents ............................................ .............................. 52 A.1 Questions de scénario ............................................. .................................................. .. 52 A.2 Scénarios .............................................. .................................................. ................ 53 Annexe B - Éléments de données liés à l'incident .......................................... ........................... 58 B.1 Éléments de données de base ............................................ .................................................. 58 B.2 Éléments de données du gestionnaire d'incidents ........................................... ................................... 59 Annexe C - Glossaire .............................................. .................................................. .......... 60 Annexe D - Acronymes .............................................. .................................................. ........ 61 Annexe E - Ressources .............................................. .................................................. ........ 63 Annexe F - Questions fréquemment posées ............................................ .............................. 65 Annexe G - Étapes de la gestion des crises ............................................ ......................................... 68

https://translate.googleusercontent.com/translate_f

6/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Annexe H - Journal des modifications ............................................. .................................................. ...... 69

Liste des figures Figure 2-1. Communications avec des tiers .............................................. .......................dix Figure 3-1. Cycle de vie de l'intervention en cas d'incident .............................................. .................................... 21 Figure 3-2. Cycle de vie de l'intervention en cas d'incident (détection et analyse) ......................................... ..25 Figure 3-3. Cycle de vie de l'intervention en cas d'incident (confinement, éradication et récupération) ............... 35 Figure 3-4. Cycle de vie de l'intervention en cas d'incident (activité post-incident) ........................................ ...... 38 Figure 4-1. Coordination de la réponse aux incidents ............................................... .............................. 46

vii

Page 9 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Liste des tableaux Tableau 3-1. Sources communes de précurseurs et d'indicateurs ............................................ ........... 27 Tableau 3-2. Catégories d'impact fonctionnel ............................................... .................................... 33 Tableau 3-3. Catégories d'impact de l'information ............................................... .................................. 33 Tableau 3-4. Catégories d'effort de récupérabilité ............................................... ............................... 33 Tableau 3-5. Liste de contrôle pour la gestion des incidents ............................................... ....................................... 42 Tableau 4-1. Relations de coordination ................................................ ...................................... 47

https://translate.googleusercontent.com/translate_f

7/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

viii

Page 10 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Résumé La réponse aux incidents de sécurité informatique est devenue une composante importante des technologies de l'information (TI) programmes. Les attaques liées à la cybersécurité sont devenues non seulement plus nombreuses et diversifiées, mais aussi plus dommageable et perturbateur. De nouveaux types d'incidents liés à la sécurité apparaissent fréquemment. Activités préventives basé sur les résultats des évaluations des risques peut réduire le nombre d'incidents, mais tous les incidents ne peuvent pas être empêché. Une capacité de réponse aux incidents est donc nécessaire pour détecter rapidement les incidents, minimisation des pertes et destructions, atténuation des faiblesses exploitées et restauration des services informatiques. À cette fin, cette publication fournit des lignes directrices pour la gestion des incidents, en particulier pour l'analyse des incidents données connexes et déterminer la réponse appropriée à chaque incident. Les directives peuvent être suivies indépendamment des plates-formes matérielles, des systèmes d'exploitation, des protocoles ou des applications particuliers. Parce qu'intervenir efficacement en cas d'incident est une entreprise complexe, établir une la capacité d'intervention en cas d'incident nécessite une planification et des ressources importantes. Surveillance continue pour les attaques sont essentielles. L'établissement de procédures claires pour hiérarchiser le traitement des incidents est essentiel, tout comme mettre en œuvre des méthodes efficaces de collecte, d'analyse et de communication des données. Il est également vital de construire relations et établir des moyens de communication appropriés avec d'autres groupes internes (p. ressources, juridique) et avec des groupes externes (p. ex., autres équipes d'intervention en cas d'incident, application de la loi). Cette publication aide les organisations à établir des capacités de réponse aux incidents de sécurité informatique et gérer les incidents de manière efficace et efficiente. Cette révision de la publication, Révision 2, met à jour tout au long de la publication pour refléter les changements d'attaques et d'incidents. Comprendre les menaces et l'identification des attaques modernes à leurs débuts est essentielle pour éviter les compromis ultérieurs, et le partage proactif d'informations entre les organisations concernant les signes de ces attaques est un moyen de plus en plus efficace de les identifier. La mise en œuvre des exigences et recommandations suivantes devrait faciliter réponse aux incidents pour les ministères et organismes fédéraux. Les organisations doivent créer, fournir et exploiter une capacité formelle de réponse aux incidents. Fédéral la loi oblige les agences fédérales à signaler les incidents à l'urgence informatique des États-Unis Bureau de l'équipe de préparation (US-CERT) au sein du Département de la sécurité intérieure (DHS). La Federal Information Security Management Act (FISMA) oblige les agences fédérales à établir capacités de réponse aux incidents. Chaque agence civile fédérale doit désigner un point primaire et secondaire de contact (POC) avec US-CERT et signaler tous les incidents conformément à la réponse de l'agence aux incidents politique. Chaque agence est responsable de déterminer comment répondre à ces exigences. L'établissement d'une capacité d'intervention en cas d'incident doit inclure les actions suivantes: ∎ Création d'une politique et d'un plan de réponse aux incidents ∎ Développer des procédures pour la gestion des incidents et les rapports ∎ Établir des directives pour communiquer avec des tiers concernant les incidents ∎ Sélection d'une structure d'équipe et d'un modèle de dotation ∎ Établir des relations et des lignes de communication entre l'équipe d'intervention en cas d'incident et les autres groupes, à la fois internes (p. ex., service juridique) et externes (p. ex., organismes d'application de la loi) ∎ Déterminer les services que l'équipe d'intervention en cas d'incident doit fournir

1

Page 11 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Dotation en personnel et formation de l'équipe d'intervention en cas d'incident. Les organisations doivent réduire la fréquence des incidents en sécurisant efficacement les réseaux, les systèmes, et applications.

https://translate.googleusercontent.com/translate_f

8/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Prévenir les problèmes est souvent moins coûteux et plus efficace que d'y réagir après leur apparition. Donc, la prévention des incidents est un complément important à une capacité d'intervention en cas d'incident. Si les contrôles de sécurité sont Des volumes d'incidents insuffisants et élevés peuvent survenir. Cela pourrait surcharger les ressources et la capacité réponse, ce qui entraînerait une récupération retardée ou incomplète et peut-être des dommages plus importants et périodes de service plus longues et indisponibilité des données. La gestion des incidents peut être effectuée plus efficacement si les organisations complètent leur capacité d'intervention en cas d'incident avec des ressources adéquates pour maintenir activement la sécurité des réseaux, des systèmes et des applications. Cela comprend la formation du personnel informatique sur le respect des les normes de sécurité de l'organisation et sensibiliser les utilisateurs aux politiques et procédures concernant utilisation appropriée des réseaux, des systèmes et des applications. Les organisations doivent documenter leurs lignes directrices pour les interactions avec d'autres organisations concernant incidents. Lors de la gestion des incidents, l'organisation devra communiquer avec des tiers, tels que d'autres les équipes d'intervention en cas d'incident, les forces de l'ordre, les médias, les fournisseurs et les organisations de victimes. Parce que ces les communications doivent souvent avoir lieu rapidement, les organisations doivent prédéterminer la communication directives afin que seules les informations appropriées soient partagées avec les bonnes parties. Les organisations doivent être généralement préparées à gérer tout incident, mais doivent se concentrer sur prêt à gérer les incidents utilisant des vecteurs d'attaque courants. Les incidents peuvent se produire d'innombrables façons, il est donc impossible de développer des instructions étape par étape pour la gestion chaque incident. Cette publication définit plusieurs types d'incidents, basés sur des vecteurs d'attaque courants; celles-ci les catégories ne visent pas à fournir une classification définitive des incidents, mais plutôt à être utilisées comme base pour définir des procédures de manipulation plus spécifiques. Différents types d'incidents méritent une réponse différente stratégies. Les vecteurs d'attaque sont: ∎ Support externe / amovible: attaque exécutée à partir d'un support amovible (par exemple, lecteur flash, CD) ou périphérique. ∎ Attrition: attaque qui utilise des méthodes de force brute pour compromettre, dégrader ou détruire des systèmes, réseaux ou services. ∎ Web: attaque exécutée à partir d'un site Web ou d'une application Web. ∎ E-mail: attaque exécutée via un e-mail ou une pièce jointe. ∎ Utilisation incorrecte: tout incident résultant de la violation de l'utilisation acceptable d'une organisation politiques par un utilisateur autorisé, à l'exclusion des catégories ci-dessus. ∎ Perte ou vol d'équipement: la perte ou le vol d'un appareil informatique ou d'un support utilisé par le organisation, comme un ordinateur portable ou un smartphone. ∎ Autre: une attaque qui ne rentre dans aucune des autres catégories.

2

Page 12 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Les organisations doivent souligner l'importance de la détection et de l'analyse des incidents tout au long organisation. Dans une organisation, des millions de signes possibles d'incidents peuvent survenir chaque jour, enregistrés principalement par Logiciels de journalisation et de sécurité informatique. L'automatisation est nécessaire pour effectuer une analyse initiale des données et sélectionnez des événements d'intérêt pour un examen humain. Les logiciels de corrélation d'événements peuvent être d'une grande valeur automatiser le processus d'analyse. Cependant, l'efficacité du processus dépend de la qualité du les données qui y entrent. Les organisations doivent établir des normes et des procédures d'exploitation pour garantir que des informations adéquates sont collectées par des journaux et des logiciels de sécurité et que les données sont revues régulièrement. Les organisations doivent créer des directives écrites pour hiérarchiser les incidents. Donner la priorité au traitement des incidents individuels est un point de décision critique dans la réponse aux incidents processus. Un partage d'informations efficace peut aider une organisation à identifier les situations qui sont plus gravité et exigent une attention immédiate. Les incidents doivent être classés par ordre de priorité en fonction des facteurs pertinents, comme l'impact fonctionnel de l'incident (p. ex., impact négatif actuel et futur probable sur l'entreprise fonctions), l'impact de l'incident sur l'information (p. ex., effet sur la confidentialité, l'intégrité et disponibilité des informations de l'organisation), et la capacité de récupération de l'incident (par exemple, l'heure et types de ressources qui doivent être consacrées à la récupération après l'incident). Les organisations doivent utiliser le processus des leçons apprises pour tirer profit des incidents.

https://translate.googleusercontent.com/translate_f

9/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Une fois qu'un incident majeur a été traité, l'organisation doit organiser une réunion sur les leçons apprises pour examiner l'efficacité du processus de gestion des incidents et identifier les améliorations nécessaires aux contrôles et pratiques de sécurité. Des réunions sur les leçons apprises peuvent également être organisées périodiquement pour des incidents mineurs lorsque le temps et les ressources le permettent. Les informations accumulées lors de toutes les réunions sur les leçons apprises doivent être utilisé pour identifier et corriger les faiblesses systémiques et les lacunes des politiques et procédures. Suivre les rapports générés pour chaque incident résolu peuvent être importants non seulement à des fins de preuve, mais aussi pour référence dans la gestion des incidents futurs et dans la formation des nouveaux membres de l'équipe.

3

Page 13 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

1. Introduction 1.1 Autorité L'Institut national des normes et de la technologie (NIST) a élaboré ce document dans le cadre de sa responsabilités statutaires en vertu de la loi fédérale de 2002 sur la gestion de la sécurité de l'information (FISMA), Loi publique 107-347. Le NIST est chargé d'élaborer des normes et des directives, y compris des exigences minimales, pour assurer une sécurité de l'information adéquate pour toutes les opérations et tous les actifs de l'agence, mais de telles normes et les lignes directrices ne s'appliquent pas aux systèmes de sécurité nationaux. Cette directive est conforme aux exigences de la circulaire A-130 du Bureau de la gestion et du budget (OMB), section 8b (3), «Agence de garantie Systèmes d'information », tel qu'analysé dans A-130, Annexe IV: Analyse des sections clés. Supplémentaire les informations sont fournies dans l'A-130, Annexe III. Cette directive a été préparée pour être utilisée par les agences fédérales. Il peut être utilisé par des organisations non gouvernementales organisations sur une base volontaire et n'est pas soumis au droit d'auteur, bien que l'attribution soit souhaitée. Rien dans ce document ne doit être considéré comme contraire aux normes et directives rendues obligatoires et contraignant pour les agences fédérales par le secrétaire au commerce sous l'autorité statutaire, et ces les directives soient interprétées comme modifiant ou remplaçant les pouvoirs existants du Secrétaire au commerce, Directeur de l'OMB ou tout autre fonctionnaire fédéral. 1.2 Objet et portée Cette publication vise à aider les organisations à atténuer les risques liés aux incidents de sécurité informatique en fournir des directives pratiques pour réagir efficacement et efficacement aux incidents. Il comprend des lignes directrices sur l'établissement d'un programme efficace de réponse aux incidents, mais l'objectif principal du document est détecter, analyser, hiérarchiser et gérer les incidents. Les organisations sont encouragées à adapter le recommandations et solutions recommandées pour répondre à leurs exigences spécifiques de sécurité et de mission. 1.3 Public Ce document a été créé pour les équipes de réponse aux incidents de sécurité informatique (CSIRT), les systèmes et administrateurs réseau, personnel de sécurité, personnel de support technique, directeurs de la sécurité de l'information (RSSI), directeurs de l'information (DSI), gestionnaires de programmes de sécurité informatique et autres responsables pour la préparation ou la réponse aux incidents de sécurité. 1.4 Structure du document

https://translate.googleusercontent.com/translate_f

10/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Le reste de ce document est organisé dans les sections et annexes suivantes: ∎ La section 2 traite de la nécessité d'une réponse aux incidents, décrit une équipe de réponse aux incidents possibles structures, et met en évidence d'autres groupes au sein d'une organisation qui peuvent participer à un incident manipulation. ∎ La section 3 passe en revue les étapes de base de la gestion des incidents et fournit des conseils pour une gestion plus efficace, en particulier la détection et l'analyse des incidents. ∎ La section 4 examine la nécessité de coordonner la réponse aux incidents et de partager les informations.

4

Page 14 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ L'annexe A contient des scénarios de réponse aux incidents et des questions à utiliser dans la table de réponse aux incidents discussions. ∎ L'annexe B fournit des listes de champs de données suggérés à collecter pour chaque incident. ∎ Les annexes C et D contiennent respectivement un glossaire et une liste d'acronymes. ∎ L'annexe E identifie les ressources qui peuvent être utiles dans la planification et l'exécution de la réponse aux incidents. ∎ L'annexe F couvre les questions fréquemment posées sur la réponse aux incidents. ∎ L'annexe G répertorie les principales étapes à suivre lors de la gestion d'une crise liée à un incident de sécurité informatique. ∎ L'annexe H contient un journal des modifications répertoriant les modifications importantes depuis la révision précédente.

5

https://translate.googleusercontent.com/translate_f

11/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Page 15 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

2. Organisation d'une capacité de réponse aux incidents de sécurité informatique L'organisation d'une capacité efficace de réponse aux incidents de sécurité informatique (CSIRC) implique plusieurs décisions et actions. L'une des premières considérations devrait être de créer une organisation spécifique définition du terme «incident» afin que la portée du terme soit claire. L'organisation doit décider quels services l'équipe d'intervention en cas d'incident devrait fournir, considérez quelles structures et quels modèles d'équipe peuvent fournir ces services et sélectionner et mettre en œuvre une ou plusieurs équipes d'intervention en cas d'incident. Réponse aux incidents la création d'un plan, d'une politique et d'une procédure est un élément important de la constitution d'une équipe, de sorte que la réponse aux incidents est effectuée de manière efficace, efficiente et cohérente, et afin que l'équipe soit habilitée à faire ce dont elle a besoin être fait. Le plan, les politiques et les procédures doivent refléter les interactions de l'équipe avec les autres équipes au sein de l'organisation ainsi qu'avec des parties extérieures, telles que les forces de l'ordre, les médias et d'autres organisations de réponse aux incidents. Cette section ne fournit pas seulement des directives qui devraient être utiles pour organisations qui mettent en place des capacités de réponse aux incidents, mais aussi des conseils sur la maintenance et améliorer les capacités existantes. 2.1 Événements et incidents Un événement est toute occurrence observable dans un système ou un réseau. Les événements incluent un utilisateur se connectant à un fichier partager, un serveur recevant une demande de page Web, un utilisateur envoyant un e-mail et un pare-feu bloquant un tentative de connexion. Les événements indésirables sont des événements ayant une conséquence négative, tels que des pannes du système, inondations de paquets, utilisation non autorisée des privilèges système, accès non autorisé aux données sensibles et exécution des logiciels malveillants qui détruisent les données. Ce guide traite uniquement des événements indésirables liés à la sécurité informatique. liés, pas ceux causés par des catastrophes naturelles, des pannes de courant, etc. Un incident de sécurité informatique est une violation ou une menace imminente de violation 1 des politiques de sécurité informatique, politiques d'utilisation acceptables ou pratiques de sécurité standard. Exemples d'incidents 2 : ∎ Un attaquant commande à un botnet d'envoyer des volumes élevés de demandes de connexion à un serveur Web, provoquant il s'écrase. ∎ Les utilisateurs sont amenés à ouvrir un «rapport trimestriel» envoyé par e-mail qui est en fait un malware; exécuter le outil a infecté leurs ordinateurs et établi des connexions avec un hôte externe. ∎ Un attaquant obtient des données sensibles et menace que les détails soient rendus publics si le l'organisation ne paie pas une somme d'argent désignée. ∎ Un utilisateur fournit ou expose des informations sensibles à d'autres par le biais de services de partage de fichiers d'égal à égal. 2.2 Besoin de réponse aux incidents Les attaques compromettent fréquemment les données personnelles et professionnelles, et il est essentiel de réagir rapidement et efficacement lorsque des failles de sécurité se produisent. Le concept de réponse aux incidents de sécurité informatique est devenu largement accepté et mis en œuvre. L'un des avantages d'avoir une capacité de réponse aux incidents est qu'elle prend en charge la réponse systématique aux incidents (c.-à-d. après une gestion cohérente des incidents méthodologie) afin que les actions appropriées soient prises. La réponse aux incidents aide le personnel à minimiser la perte ou le vol d'informations et l'interruption des services causés par des incidents. Un autre avantage de l'incident la réponse est la capacité d'utiliser les informations obtenues lors du traitement des incidents pour mieux se préparer au traitement

1

2

Une «menace imminente de violation» fait référence à une situation dans laquelle l'organisation a une base factuelle pour croire qu'une un incident spécifique est sur le point de se produire. Par exemple, les responsables de la maintenance du logiciel antivirus peuvent recevoir un bulletin du logiciel fournisseur, les avertissant de la présence de nouveaux logiciels malveillants qui se répandent rapidement sur Internet. Pour le reste de ce document, les termes «incident» et «incident de sécurité informatique» sont interchangeables.

6

Page 16 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

les incidents futurs et pour renforcer la protection des systèmes et des données. Une capacité de réponse aux incidents aide également à traiter correctement les problèmes juridiques pouvant survenir lors d'incidents. Outre les raisons commerciales de mettre en place une capacité de réponse aux incidents, les départements fédéraux et les agences doivent se conformer à la loi, à la réglementation et à la politique qui dirigent une défense coordonnée et efficace contre menaces de sécurité de l'information. Les principaux d'entre eux sont les suivants: ∎ Circulaire n ° A-130, Annexe III, 3 de l' OMB publiée en 2000, qui ordonne aux organismes fédéraux de «S'assurer qu'il existe une capacité à fournir une aide aux utilisateurs lorsqu'un incident de sécurité se produit dans le système et partager des informations sur les vulnérabilités et les menaces courantes. Cette capacité doit partager informations avec d'autres organisations… et devrait aider l'agence à poursuivre action, conformément aux directives du ministère de la Justice. » ∎ FISMA (à partir de 2002) 4, qui oblige les agences à avoir «des procédures pour détecter, signaler et

https://translate.googleusercontent.com/translate_f

12/62

21/10/2020

Guide de gestion des incidents de sécurité informatique réponse aux incidents de sécurité »et établit un incident de sécurité de l'information fédéral centralisé centre, en partie pour:

- «Fournir une assistance technique en temps opportun aux opérateurs des systèmes d'information des agences… y compris conseils sur la détection et le traitement des incidents liés à la sécurité des informations…

- Compiler et analyser les informations sur les incidents qui menacent la sécurité des informations… - Informer les opérateurs des systèmes d'information des agences sur la sécurité de l'information actuelle et potentielle menaces et vulnérabilités… » ∎ Federal Information Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems 5 , mars 2006, qui spécifie les exigences minimales de sécurité pour les systèmes d'information et d'information fédéraux, y compris la réponse aux incidents. Le spécifique les exigences sont définies dans la publication spéciale NIST (SP) 800-53, Contrôles de sécurité recommandés pour les systèmes d'information et les organisations fédérales . ∎ Mémorandum de l'OMB M-07-16, Protéger contre la violation des Informations identifiables 6 , mai 2007, qui fournit des conseils sur le signalement des incidents de sécurité impliquent PII. 2.3 Création d'une politique, d'un plan et d'une procédure de réponse aux incidents Cette section traite des politiques, plans et procédures liés à la réponse aux incidents, en mettant l'accent sur interactions avec des tiers. 2.3.1 Éléments de politique La politique régissant la réponse aux incidents est hautement personnalisée pour l'organisation. Cependant, la plupart des politiques inclure les mêmes éléments clés: ∎ Déclaration d'engagement de la direction ∎ Objet et objectifs de la politique

3 4 5 6

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html http://csrc.nist.gov/drivers/documents/FISMA-final.pdf http://csrc.nist.gov/publications/PubsFIPS.html http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf

7

Page 17 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Portée de la politique (à qui et à quoi elle s'applique et dans quelles circonstances) ∎ Définition des incidents de sécurité informatique et termes associés ∎ Structure organisationnelle et définition des rôles, responsabilités et niveaux d'autorité; devrait inclure le pouvoir de l'équipe d'intervention en cas d'incident de confisquer ou de déconnecter l'équipement et de surveiller les activités suspectes, les exigences pour signaler certains types d'incidents, les exigences et des lignes directrices pour les communications externes et le partage d'informations (par exemple, avec quoi qui, quand et sur quels canaux), et les points de transfert et d'escalade de l'incident processus de gestion ∎ Hiérarchisation ou évaluation de la gravité des incidents ∎ Mesures du rendement (comme indiqué à la section 3.4.2) ∎ Formulaires de signalement et de contact. 2.3.2 Éléments du plan Les organisations doivent avoir une approche formelle, ciblée et coordonnée pour répondre aux incidents, y compris un plan de réponse aux incidents qui fournit la feuille de route pour la mise en œuvre de la réponse aux incidents aptitude. Chaque organisation a besoin d'un plan qui répond à ses exigences uniques, qui se rapportent à mission, taille, structure et fonctions de l'organisation. Le plan doit prévoir les ressources nécessaires et soutien à la gestion. Le plan d'intervention en cas d'incident doit comprendre les éléments suivants: ∎ Mission ∎ Stratégies et objectifs ∎ Approbation de la haute direction ∎ Approche organisationnelle de la réponse aux incidents ∎ Comment l'équipe d'intervention en cas d'incident communiquera avec le reste de l'organisation et avec les autres

https://translate.googleusercontent.com/translate_f

13/62

21/10/2020

Guide de gestion des incidents de sécurité informatique les organisations ∎ Mesures pour mesurer la capacité de réponse aux incidents et son efficacité ∎ Feuille de route pour la maturation de la capacité de réponse aux incidents ∎ Comment le programme s'intègre dans l'organisation globale. La mission, les stratégies et les objectifs de l'organisation en matière de réponse aux incidents devraient aider à déterminer les structure de sa capacité d’intervention en cas d’incident. La structure du programme d'intervention en cas d'incident doit également être discuté dans le plan. La section 2.4.1 traite des types de structures. Une fois qu'une organisation élabore un plan et obtient l'approbation de la direction, l'organisation doit mettre en œuvre le plan et l'examiner au moins une fois par an pour s'assurer que l'organisation suit la feuille de route pour mûrir la capacité et atteindre leurs objectifs de réponse aux incidents. 2.3.3 Éléments de procédure Les procédures doivent être basées sur la politique et le plan de réponse aux incidents. Procédures d'utilisation normalisées (SOP) sont une délimitation des processus techniques spécifiques, des techniques, des listes de contrôle et des formulaires utilisés par le équipe d'intervention en cas d'incident. Les SOP doivent être raisonnablement complètes et détaillées pour garantir que les

8

Page 18 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

les priorités de l'organisation se reflètent dans les opérations de réponse. De plus, suivant la norme les réponses doivent minimiser les erreurs, en particulier celles qui pourraient être causées par une gestion des incidents stressants situations. Les SOP doivent être testées pour valider leur exactitude et leur utilité, puis distribuées à toute l'équipe membres. Une formation devrait être fournie aux utilisateurs des SOP; les documents SOP peuvent être utilisés comme une instruction outil. Les éléments de POS suggérés sont présentés tout au long de la section 3. 2.3.4 Partage d'informations avec des tiers Les organisations ont souvent besoin de communiquer avec des tiers au sujet d'un incident, et elles devraient le faire ainsi, le cas échéant, comme contacter les forces de l'ordre, répondre aux demandes des médias et rechercher une expertise externe. Un autre exemple est la discussion d'incidents avec d'autres parties impliquées, comme Internet les fournisseurs de services (FAI), le fournisseur de logiciels vulnérables ou d'autres équipes d'intervention en cas d'incident. Les organisations peuvent également partager de manière proactive des informations pertinentes sur les indicateurs d'incident avec leurs pairs pour améliorer détection et analyse des incidents. L'équipe d'intervention en cas d'incident doit discuter du partage d'informations avec le bureau des affaires publiques, le service juridique et la direction de l'organisation avant qu'un incident ne survienne établir des politiques et des procédures concernant le partage d'informations. Sinon, des informations sensibles concernant les incidents peuvent être fournis à des parties non autorisées, ce qui peut entraîner des perturbations supplémentaires et perte financière. L'équipe doit documenter tous les contacts et communications avec des tiers pour responsabilité et à des fins de preuve. Les sections suivantes fournissent des directives sur la communication avec plusieurs types de tiers extérieurs, comme représenté sur la figure 2-1. Les flèches à deux têtes indiquent que l'une ou l'autre des parties peut initier des communications. Voir la section 4 pour plus d'informations sur la communication avec des tiers, et voir la section 2.4 pour un discussion des communications impliquant des sous-traitants en réponse aux incidents.

https://translate.googleusercontent.com/translate_f

14/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

9

Page 19 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Figure 2-1. Communications avec des tiers

2.3.4.1 Les médias L'équipe de gestion des incidents doit établir des procédures de communication avec les médias conformes aux les politiques de l'organisation en matière d'interaction avec les médias et de divulgation d'informations. 7 Pour discuter des incidents avec le médias, les organisations trouvent souvent utile de désigner un point de contact unique (POC) et au moins un contact de sauvegarde. Les actions suivantes sont recommandées pour préparer ces contacts désignés et devrait également être envisagée pour préparer d'autres personnes susceptibles de communiquer avec les médias: ∎ Organiser des sessions de formation sur l'interaction avec les médias concernant les incidents, qui devraient inclure l'importance de ne pas révéler d'informations sensibles, telles que les détails techniques des contre-mesures pourrait aider d'autres attaquants, et les aspects positifs de la communication d'informations importantes au public pleinement et efficacement. ∎ Établir des procédures pour informer les contacts des médias sur les problèmes et les sensibilités concernant un incident avant d'en discuter avec les médias.

7

Par exemple, une organisation peut souhaiter que les membres de son bureau des affaires publiques et de son service juridique participent à tous discussions sur l'incident avec les médias.

dix

Page 20 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Tenir à jour un état de l'état actuel de l'incident afin que les communications avec les médias soient cohérente et à jour. ∎ Rappeler à tout le personnel les procédures générales de traitement des demandes des médias.

https://translate.googleusercontent.com/translate_f

15/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Organisez des entretiens simulés et des conférences de presse pendant les exercices de gestion des incidents. Les suivants sont exemples de questions à poser au contact média:

- Qui vous a attaqué? Pourquoi? - Quand est-ce arrivé? Comment est-ce arrivé? Est-ce que cela s'est produit parce que vous avez une mauvaise sécurité les pratiques?

- Quelle est l'ampleur de cet incident? Quelles mesures prenez-vous pour déterminer ce qui s'est passé et empêcher de futures occurrences?

- Quel est l'impact de cet incident? Des informations personnelles identifiables (PII) ont-elles été exposées? Quel est le coût estimé de cet incident? 2.3.4.2 Application de la loi L'une des raisons pour lesquelles de nombreux incidents liés à la sécurité n'entraînent pas de condamnations est que certaines organisations pas correctement contacter les forces de l'ordre. Plusieurs niveaux d'application de la loi sont disponibles pour enquêter incidents: par exemple, aux États-Unis, les agences d'enquête fédérales (par exemple, le Federal Bureau des enquêtes [FBI] et des services secrets américains), des procureurs de district, des forces de l'ordre de l'État et application de la loi locale (par exemple, comté). Les services répressifs d'autres pays peuvent également être impliqués, comme pour les attaques lancées depuis ou dirigées vers des endroits en dehors des États-Unis. De plus, les agences ont un Bureau de l'inspecteur général (BIG) pour enquêter sur la violation de la loi au sein de chaque agence. le l'équipe d'intervention en cas d'incident doit se familiariser avec ses différents représentants des forces de l'ordre avant un incident survient pour discuter des conditions dans lesquelles les incidents doivent leur être signalés, de la des rapports doivent être effectués, quelles preuves doivent être collectées et comment elles doivent être collectées. Les forces de l'ordre doivent être contactées par l'intermédiaire de personnes désignées d'une manière conforme aux exigences de la loi et des procédures de l'organisation. De nombreuses organisations préfèrent en nommer un membre de l'équipe d'intervention en cas d'incident en tant que POC principal avec les forces de l'ordre. Cette personne doit être familière avec les procédures de signalement de tous les organismes d'application de la loi concernés et bien préparé à recommander quelle agence, le cas échéant, doit être contactée. Notez que l'organisation ne doit généralement pas contacter plusieurs agences, car cela pourrait entraîner des conflits de compétence. L'équipe de réponse aux incidents devrait comprendre quels sont les problèmes juridictionnels potentiels (p. ex. emplacement physique - une organisation basé dans un état a un serveur situé dans un deuxième état attaqué par un système dans un troisième état, en cours d'utilisation à distance par un attaquant dans un quatrième état). 2.3.4.3 Organisations de signalement des incidents La FISMA oblige les agences fédérales à signaler les incidents au service d'urgence informatique des États-Unis Team (US-CERT), 8 qui est une organisation gouvernementale d'intervention en cas d'incident qui assiste le gouvernement fédéral les agences civiles dans leurs efforts de gestion des incidents. US-CERT ne remplace pas la réponse de l'agence existante équipes; il augmente plutôt les efforts des agences civiles fédérales en servant de point focal pour traiter avec des incidents. L'US-CERT analyse les informations fournies par l'agence pour identifier les tendances et les indicateurs attaques; ceux-ci sont plus faciles à discerner lors de l'examen des données de nombreuses organisations que lors de l'examen les données d'une seule organisation. 8

http://www.us-cert.gov/

11

Page 21 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Chaque agence doit désigner un POC principal et secondaire avec US-CERT et signaler tous les incidents conformément à la politique de réponse aux incidents de l'agence. Les organisations devraient créer une politique qui stipule qui est désigné pour signaler les incidents et comment les incidents doivent être signalés. Exigences, catégories, et les délais pour signaler les incidents à l'US-CERT se trouvent sur le site Web de l'US-CERT. 9 Toutes les agences fédérales doivent s'assurer que leurs procédures de réponse aux incidents respectent les exigences de signalement de l'US-CERT et que les procédures sont suivies correctement. Toutes les organisations sont encouragées à signaler les incidents à leurs CSIRT appropriés. Si une organisation fait ne pas avoir son propre CSIRT à contacter, il peut signaler des incidents à d'autres organisations, y compris des informations Centres de partage et d'analyse (ISAC) . L'une des fonctions de ce secteur privé spécifique à l'industrie groupes est de partager des informations importantes liées à la sécurité informatique entre leurs membres. Plusieurs ISAC ont été formés pour des secteurs industriels tels que les communications, le secteur électrique, les services financiers, Technologie de l'information, et recherche et éducation. dix 2.3.4.4 Autres parties extérieures Une organisation peut souhaiter discuter des incidents avec d'autres groupes, y compris ceux répertoriés ci-dessous. Quand tendre la main à ces parties externes, une organisation peut souhaiter travailler via l'US-CERT ou son ISAC, en tant qu '«introducteur de confiance» pour négocier la relation. Il est probable que d'autres rencontrent des problèmes similaires, et l'introducteur de confiance peut s'assurer que ces modèles sont identifiés et pris en considération. ∎ FSI de l'organisation. Une organisation peut avoir besoin de l'aide de son FAI pour bloquer un réseau majeur. attaque basée ou retracer son origine.

https://translate.googleusercontent.com/translate_f

16/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Propriétaires d'adresses attaquantes. Si les attaques proviennent de l'adresse IP d'une organisation externe espace d'adressage, les gestionnaires d'incidents peuvent souhaiter parler aux contacts de sécurité désignés pour le l'organisation pour les alerter de l'activité ou leur demander de recueillir des preuves. Il est fortement recommandé pour coordonner ces communications avec l'US-CERT ou un ISAC. ∎ Fournisseurs de logiciels. Les gestionnaires d'incidents peuvent vouloir parler à un fournisseur de logiciels de activité. Ce contact peut inclure des questions concernant la signification de certaines entrées de journal ou faux positifs connus pour certaines signatures de détection d'intrusion, où des informations minimales concernant l'incident devra peut-être être révélé. Des informations supplémentaires peuvent être nécessaires dans certains cas - pour Par exemple, si un serveur semble avoir été compromis par une vulnérabilité logicielle inconnue. Les éditeurs de logiciels peuvent également fournir des informations sur les menaces connues (par exemple, les nouvelles attaques) pour aider les organisations comprennent l'environnement actuel des menaces. ∎ Autres équipes d'intervention en cas d'incident. Une organisation peut rencontrer un incident similaire à ceux géré par d'autres équipes; le partage proactif des informations peut faciliter gestion des incidents (p. ex., avertissement préalable, amélioration de la préparation, développement conscience). Des groupes tels que le Forum of Incident Response and Security Teams (FIRST) 11 , le Forum gouvernemental des équipes de réponse aux incidents et de sécurité (GFIRST) 12 et Anti-Phishing Les groupes de travail (APWG) 13 ne sont pas des équipes d'intervention en cas d'incident, mais ils favorisent le partage d'informations parmi les équipes d'intervention en cas d'incident. ∎ Parties externes affectées. Un incident peut affecter directement des parties externes, par exemple, un l'organisation peut contacter l'organisation et affirmer que l'un des utilisateurs de l'organisation attaque 9 dix 11 12 13

http://www.us-cert.gov/federation/reportingRequirements.html Voir le site Web du Conseil national des ISAC à http://www.isaccouncil.org/ pour une liste des ISAC. http://www.first.org/ GFIRST s'adresse spécifiquement aux ministères et organismes fédéraux. ( http://www.us-cert.gov/federation/gfirst.html) http://www.antiphishing.org/

12

Page 22 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

il. Une autre manière dont les parties externes peuvent être affectées est si un attaquant accède à des les informations les concernant, telles que les informations de carte de crédit. Dans certaines juridictions, les organisations tenu d'aviser toutes les parties concernées par un tel incident. Quelles que soient les circonstances, il est préférable pour l'organisation d'aviser les parties externes concernées d'un incident avant les médias ou d'autres organisations externes le font. Les manutentionnaires doivent veiller à ne donner que les informations: les parties concernées peuvent demander des détails sur les enquêtes internes qui ne devraient pas révélé publiquement. Mémorandum de l'OMB M-07-16, Protéger contre la violation des Informations identifiables , oblige les agences fédérales à développer et mettre en œuvre une notification de violation politique relative aux informations personnelles identifiables (PII). 14 Les gestionnaires d'incidents doivent comprendre comment leur les actions de gestion des incidents doivent différer lorsqu'une violation des informations personnelles est suspectée, telle que notifier d'autres parties ou notifier des parties dans un délai plus court. Recommandations spécifiques pour les politiques de notification de violation de PII sont présentées dans le mémorandum de l'OMB M-07-16. En outre, le National La Conférence des législatures des États a une liste des lois sur la notification des violations de la sécurité des États. 15 2.4 Structure de l'équipe d'intervention en cas d'incident Une équipe d'intervention en cas d'incident devrait être disponible pour quiconque découvre ou soupçonne qu'un incident impliquant l'organisation a eu lieu. Un ou plusieurs membres de l'équipe, selon l'ampleur du incident et la disponibilité du personnel, s'occupera alors de l'incident. Les gestionnaires d'incidents analysent les les données de l'incident, déterminer l'impact de l'incident et agir de manière appropriée pour limiter les dommages et restaurer services normaux. Le succès de l'équipe d'intervention en cas d'incident dépend de la participation et de la coopération de individus dans l’ensemble de l’organisation. Cette section identifie ces personnes, discute des incidents des modèles de l'équipe d'intervention et fournit des conseils sur le choix d'un modèle approprié. 2.4.1 Modèles d'équipe Les structures possibles pour une équipe d'intervention en cas d'incident sont les suivantes: ∎ Équipe centrale d'intervention en cas d'incident. Une seule équipe d'intervention en cas d'incident gère les incidents organisation. Ce modèle est efficace pour les petites organisations et pour les organisations avec un minimum diversité géographique en termes de ressources informatiques. ∎ Équipes de réponse aux incidents réparties. L'organisation dispose de plusieurs équipes d'intervention en cas d'incident, chacune responsable d'un segment logique ou physique particulier de l'organisation. Ce modèle est efficace pour grandes organisations (p. ex., une équipe par division) et pour les organisations ayant une informatique majeure ressources à des endroits éloignés (par exemple, une équipe par région géographique, une équipe par grande installation). Cependant, les équipes doivent faire partie d'une seule entité coordonnée afin que le processus de réponse aux incidents est cohérente dans toute l'organisation et les informations sont partagées entre les équipes. C'est particulièrement important car plusieurs équipes peuvent voir les composants du même incident ou gérer des

https://translate.googleusercontent.com/translate_f

17/62

21/10/2020

Guide de gestion des incidents de sécurité informatique incidents. ∎ Équipe de coordination. Une équipe d'intervention en cas d'incident conseille les autres équipes sans avoir autorité sur ces équipes - par exemple, une équipe à l'échelle du département peut aider des agences individuelles équipes. Ce modèle peut être considéré comme un CSIRT pour les CSIRT. Parce que l'objectif de ce document est

14 15

http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf http://www.ncsl.org/default.aspx?tabid=13489

13

Page 23 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

CSIRT centralisés et distribués, le modèle de l'équipe de coordination n'est pas traité en détail dans ce document. 16 Les équipes d'intervention en cas d'incident peuvent également utiliser l'un des trois modèles de dotation suivants: ∎ Employés. L'organisation effectue l'ensemble de son travail de réponse aux incidents, avec des moyens techniques et soutien administratif des entrepreneurs. ∎ Partiellement externalisé. L'organisation sous-traite une partie de son travail de réponse aux incidents. La section 2.4.2 traite des principaux facteurs à prendre en compte lors de l'externalisation. Bien que les tâches de réponse aux incidents peuvent être réparties entre l'organisation et un ou plusieurs sous-traitants dans de nombreux moyens, quelques arrangements sont devenus monnaie courante:

- L'arrangement le plus répandu est pour l'organisation d'externaliser 24 heures sur 24, 7 jours sur 7. surveillance hebdomadaire (24/7) des capteurs de détection d'intrusion, des pare-feu et d'autres dispositifs de sécurité fournisseur de services de sécurité gérés hors site (MSSP). Le MSSP identifie et analyse les l'activité et signale chaque incident détecté à l'équipe d'intervention en cas d'incident de l'organisation.

- Certaines organisations effectuent un travail de réponse aux incidents de base en interne et font appel à des aider à gérer les incidents, en particulier ceux qui sont plus graves ou plus répandus. ∎ Entièrement externalisé. L'organisation sous-traite complètement son travail de réponse aux incidents, généralement à un entrepreneur sur place. Ce modèle est le plus susceptible d'être utilisé lorsque l'organisation a besoin d'un l'équipe d'intervention en cas d'incident sur place mais ne dispose pas de suffisamment d'employés qualifiés et disponibles. Il est supposé que l'organisation aura des employés pour superviser et superviser le travail de l'externalisateur. 2.4.2 Sélection du modèle d'équipe Lors de la sélection de la structure et des modèles de dotation appropriés pour une équipe d'intervention en cas d'incident, les organisations devrait tenir compte des facteurs suivants: ∎ Le besoin d'une disponibilité 24/7. La plupart des organisations ont besoin d'un personnel d'intervention en cas d'incident disponible 24h / 24 et 7j / 7. Cela signifie généralement que les gestionnaires d'incidents peuvent être contactés par téléphone, mais cela peut également signifier qu'un une présence sur place est requise. La disponibilité en temps réel est la meilleure pour la réponse aux incidents, car plus un incident dure, plus il y a de risques de dommages et de pertes. Un contact en temps réel est souvent nécessaire lorsque vous travaillez avec d'autres organisations, par exemple, retracer une attaque jusqu'à sa source. ∎ Membres de l'équipe à temps plein ou à temps partiel. Organisations dont le financement, la dotation en personnel ou les besoins de réponse aux incidents peuvent avoir uniquement des membres de l'équipe de réponse aux incidents à temps partiel, une équipe virtuelle de réponse aux incidents. Dans ce cas, l'équipe d'intervention en cas d'incident peut être considérée comme un service d'incendie volontaire. Lorsqu'une urgence survient, les membres de l'équipe sont contactés rapidement et ceux qui peuvent aider le font. Un groupe existant tel que le service d'assistance informatique peut servir de premier POC pour Rapports d'incidents. Les membres du service d'assistance peuvent être formés pour effectuer l'enquête initiale et les données rassembler puis alerter l'équipe d'intervention en cas d'incident s'il semble qu'un incident grave s'est produit. ∎ Moral des employés. Le travail d'intervention en cas d'incident est très stressant, tout comme les responsabilités de garde de la plupart membres de l'équipe. Cette combinaison permet aux membres de l'équipe d'intervention en cas d'incident de devenir trop stressé. De nombreuses organisations auront également du mal à trouver des personnes disposées, disponibles, expérimentées et des personnes correctement qualifiées pour participer, en particulier à une assistance 24 heures sur 24. Séparation des rôles, en particulier

16

Des informations sur le modèle d'équipe de coordination, ainsi que des informations détaillées sur d'autres modèles d'équipe, sont disponibles dans un Document CERT ® / CC intitulé Modèles organisationnels pour les équipes de réponse aux incidents de sécurité informatique (CSIRT) ( http://www.cert.org/archive/pdf/03hb001.pdf ) .

14

Page 24 https://translate.googleusercontent.com/translate_f

18/62

21/10/2020

Guide de gestion des incidents de sécurité informatique C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

réduire la quantité de travail administratif que les membres de l'équipe sont responsables d'effectuer, peut être un bon coup de pouce au moral. ∎ Coût. Le coût est un facteur majeur, surtout si les employés doivent être sur place 24h / 24 et 7j / 7. Organisations peut ne pas inclure les coûts liés à l'intervention en cas d'incident dans les budgets, comme un financement suffisant pour la formation et le maintien des compétences. Parce que l'équipe de réponse aux incidents travaille avec tant de facettes de l'informatique, son les membres ont besoin de connaissances beaucoup plus larges que la plupart des membres du personnel informatique. Ils doivent également comprendre comment d'utiliser les outils de réponse aux incidents, tels que les logiciels de criminalistique numérique. Autres coûts qui peuvent être la sécurité physique des zones de travail et des mécanismes de communication de l'équipe est négligée. ∎ Expertise du personnel. La gestion des incidents nécessite des connaissances et une expérience spécialisées dans plusieurs domaines techniques; l'étendue et la profondeur des connaissances requises varient en fonction de la gravité de la risques de l'organisation. Les sous-traitants peuvent posséder une connaissance plus approfondie de la détection d'intrusion, de la criminalistique, vulnérabilités, exploits et autres aspects de la sécurité que les employés de l'organisation. Aussi, Les MSSP peuvent être en mesure de corréler les événements entre les clients afin qu'ils puissent identifier davantage les nouvelles menaces plus rapidement que n’importe quel client individuel. Cependant, les membres du personnel technique au sein du l'organisation a généralement une bien meilleure connaissance de l'environnement de l'organisation qu'un externalisateur, ce qui peut être bénéfique pour identifier les faux positifs associés à l'organisation comportement spécifique et criticité des cibles. La section 2.4.3 contient des informations supplémentaires sur compétences recommandées des membres de l’équipe. Lorsqu'elles envisagent d'externaliser, les organisations doivent garder ces questions à l'esprit: ∎ Qualité du travail actuelle et future. Les organisations doivent considérer non seulement la qualité actuelle (ampleur et profondeur) du travail du sous-traitant, mais aussi des efforts pour assurer la qualité des travaux futurs par exemple, minimiser le roulement et l'épuisement professionnel et offrir un programme de formation solide pour les nouveaux des employés. Les organisations devraient réfléchir à la manière dont elles pourraient évaluer objectivement la qualité des travail de sous-traitant. ∎ Division des responsabilités. Les organisations sont souvent peu disposées à donner à un sous-traitant le pouvoir de prendre des décisions opérationnelles pour l'environnement (par exemple, déconnecter un serveur Web). Il est important de documenter les actions appropriées pour ces points de décision. Par exemple, une personne partiellement externalisée le modèle résout ce problème en demandant au sous-traitant de fournir des données d'incident à l'organisation l'équipe interne, ainsi que des recommandations pour la poursuite du traitement de l'incident. L'équipe interne prend en fin de compte les décisions opérationnelles, le sous-traitant continuant à fournir nécessaire. ∎ Information sensible révélée à l'entrepreneur. Diviser les responsabilités de réponse aux incidents et restreindre l'accès aux informations sensibles peut limiter cela. Par exemple, un entrepreneur peut déterminer quel ID utilisateur a été utilisé lors d'un incident (par exemple, ID 123456) mais ne sait pas à quelle personne est associée l'ID utilisateur. Les employés peuvent alors reprendre l'enquête. Les accords de non-divulgation (NDA) sont une option possible pour protéger la divulgation d'informations sensibles. ∎ Manque de connaissances spécifiques à l'organisation. Une analyse précise et une hiérarchisation des incidents sont dépend de la connaissance spécifique de l'environnement de l'organisation. L'organisation devrait fournir le sous-traitant met régulièrement à jour des documents définissant les incidents dont il est concerné, les ressources sont essentielles et le niveau de réponse devrait être dans divers ensembles de circonstances. L'organisation doit également signaler toutes les modifications et mises à jour apportées à son infrastructure informatique, à son réseau configuration et systèmes. Sinon, l'entrepreneur doit faire une meilleure estimation de la façon dont chaque l'incident doit être géré, entraînant inévitablement des incidents mal gérés et de la frustration des deux côtés. Le manque de connaissances spécifiques à l'organisation peut également être un problème lorsque la réponse aux incidents n'est pas externalisées si les communications sont faibles entre les équipes ou si l'organisation ne collecte tout simplement pas les informations nécessaires.

15

Page 25 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Manque de corrélation. La corrélation entre plusieurs sources de données est très importante. Si l'intrusion le système de détection enregistre une tentative d'attaque contre un serveur Web, mais le sous-traitant n'a pas accès à les journaux du serveur, il peut être incapable de déterminer si l'attaque a réussi. Pour être efficace, le le sous-traitant exigera à distance des privilèges administratifs sur les systèmes critiques et les journaux des dispositifs de sécurité via un canal sécurisé. Cela augmentera les frais d'administration, introduira une entrée d'accès supplémentaire points et augmentent le risque de divulgation non autorisée d'informations sensibles. ∎ Gestion des incidents à plusieurs endroits. Un travail efficace de réponse aux incidents nécessite souvent un présence physique dans les installations de l'organisation. Si le sous-traitant est hors site, considérez où le sous-traitant est localisé, à quelle vitesse il peut avoir une équipe d'intervention en cas d'incident dans n'importe quel établissement et comment beaucoup cela coûtera. Envisagez des visites sur place; il y a peut-être certaines installations ou zones où le sous-traitant ne doit pas être autorisé à travailler. ∎ Maintenir les compétences de réponse aux incidents en interne. Organisations qui externalisent complètement les incidents La réponse doit s'efforcer de maintenir en interne les compétences de base en matière de réponse aux incidents. Des situations peuvent survenir

https://translate.googleusercontent.com/translate_f

19/62

21/10/2020

Guide de gestion des incidents de sécurité informatique dont le sous-traitant n'est pas disponible, l'organisation doit donc être prête à exécuter ses propres gestion des incidents. Le personnel technique de l'organisation doit également être en mesure de comprendre la signification, implications techniques et impact des recommandations du sous-traitant. 2.4.3 Personnel d'intervention en cas d'incident Un seul employé, avec un ou plusieurs suppléants désignés, devrait être responsable de la réponse aux incidents. Dans un modèle entièrement externalisé, cette personne supervise et évalue le travail de l'externalisateur. Tous les autres modèles ont généralement un chef d'équipe et un ou plusieurs adjoints qui assume l'autorité en l'absence du responsable d'équipe, cadre. Les gestionnaires exécutent généralement diverses tâches, y compris la liaison avec les la direction et d'autres équipes et organisations, désamorcer les situations de crise et s'assurer que l'équipe a le personnel, les ressources et les compétences nécessaires. Les gestionnaires doivent être techniquement compétents et avoir d'excellents aptitudes à la communication, en particulier une capacité à communiquer avec un large éventail de publics. Les gestionnaires sont responsable en dernier ressort de s'assurer que les activités de réponse aux incidents sont exécutées correctement. Outre le chef d'équipe et l'adjoint, certaines équipes ont également un responsable technique - une personne avec compétences techniques et expérience de la réponse aux incidents qui assume la supervision et la responsabilité finale qualité du travail technique de l'équipe. Le poste de responsable technique ne doit pas être confondu avec le position du responsable de l'incident. Les équipes plus importantes attribuent souvent un responsable d'incident comme principal POC pour gérer un incident spécifique; le responsable de l'incident est tenu responsable de la gestion de l'incident. Selon la taille de l'équipe d'intervention et l'ampleur de l'incident, le responsable de l'incident peut ne pas effectuer la gestion des incidents, mais plutôt coordonner les activités des gestionnaires, recueillir des informations des gestionnaires, fournissez des mises à jour sur les incidents aux autres groupes et assurez-vous que les besoins de l'équipe sont satisfaits. Les membres de l'équipe d'intervention en cas d'incident doivent avoir d'excellentes compétences techniques, telles que le système administration, administration réseau, programmation, support technique ou détection d'intrusion. Chaque le membre de l'équipe doit avoir de bonnes compétences en résolution de problèmes et des capacités de réflexion critique. Ce n'est pas nécessaire pour que chaque membre de l'équipe soit un expert technique - dans une large mesure, des considérations pratiques et financières dictera cela, mais avoir au moins une personne hautement compétente dans chaque domaine technologique majeur (par exemple, systèmes d'exploitation et applications couramment attaqués) est une nécessité. Il peut également être utile d'avoir certains membres de l'équipe se spécialisent dans des domaines techniques particuliers, tels que la détection d'intrusion réseau, les logiciels malveillants analyse ou criminalistique. Il est également souvent utile de faire appel temporairement à des spécialistes techniques qui ne fait normalement partie de l'équipe. Il est important de lutter contre l'épuisement du personnel en offrant des possibilités d'apprentissage et de croissance. Suggestions pour développer et maintenir les compétences sont les suivantes:

16

Piste 26 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Prévoyez suffisamment de fonds pour maintenir, améliorer et étendre les compétences dans les domaines techniques et de sécurité disciplines, ainsi que des sujets moins techniques tels que les aspects juridiques de la réponse aux incidents. Ceci devrait inclure l'envoi de personnel à des conférences et encourager ou autrement encourager la participation à conférences, garantissant la disponibilité de références techniques favorisant une comprendre, et parfois faire appel à des experts extérieurs (par exemple, des entrepreneurs) ayant une connaissances dans les domaines nécessaires dans la mesure où le financement le permet. ∎ Donnez aux membres de l'équipe la possibilité d'effectuer d'autres tâches, telles que la création de matériel pédagogique, organiser des ateliers de sensibilisation à la sécurité et effectuer des recherches. ∎ Envisagez la rotation des membres du personnel dans et hors de l'équipe d'intervention en cas d'incident, et participez échanges dans lesquels les membres de l'équipe échangent temporairement des places avec d'autres (par exemple, les administrateurs réseau) pour acquérir de nouvelles compétences techniques. ∎ Maintenir une dotation en personnel suffisante pour que les membres de l'équipe puissent s'absenter du travail sans interruption (p. les vacances). ∎ Créer un programme de mentorat pour permettre au personnel technique senior d'aider le personnel moins expérimenté à apprendre gestion des incidents. ∎ Développez des scénarios de gestion des incidents et demandez aux membres de l'équipe de discuter de la manière leur. L'annexe A contient un ensemble de scénarios et une liste de questions à utiliser pendant le scénario discussions. Les membres de l'équipe d'intervention en cas d'incident doivent avoir d'autres compétences en plus de l'expertise technique. Travail en équipe les compétences sont d'une importance fondamentale car la coopération et la coordination sont nécessaires pour réussir réponse aux incidents. Chaque membre de l'équipe doit également avoir de bonnes compétences en communication. Les compétences orales sont important car l'équipe interagira avec une grande variété de personnes et les compétences en rédaction sont importantes lorsque les membres de l'équipe préparent des avis et des procédures. Même si tout le monde au sein d'une équipe n'a pas besoin pour avoir de solides compétences en rédaction et en expression orale, au moins quelques personnes au sein de chaque équipe devraient les posséder. l'équipe peut bien se représenter devant les autres. 2.4.4 Dépendances au sein des organisations

https://translate.googleusercontent.com/translate_f

20/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Il est important d'identifier d'autres groupes au sein de l'organisation qui pourraient avoir besoin de participer à un incident traitement afin que leur coopération puisse être sollicitée avant qu'elle ne soit nécessaire. Chaque équipe d'intervention en cas d'incident compte sur l'expertise, le jugement et les capacités des autres, y compris: ∎ Gestion . La direction établit la politique de réponse aux incidents, le budget et la dotation en personnel. En fin de compte, la direction est tenue de coordonner la réponse aux incidents entre les différentes parties prenantes, minimiser les dommages et faire rapport au Congrès, à l'OMB, au General Accounting Office (GAO) et autres parties. ∎ Assurance de l'information. Des membres du personnel de sécurité de l'information peuvent être nécessaires à certaines étapes de gestion des incidents (prévention, confinement, éradication et récupération) - par exemple, pour modifier le réseau contrôles de sécurité (par exemple, ensembles de règles de pare-feu). ∎ Assistance informatique. Les experts techniques informatiques (par exemple, les administrateurs système et réseau) n'ont pas seulement les compétences pour aider, mais ont généralement la meilleure compréhension de la technologie qu'ils gèrent au quotidien base. Cette compréhension peut garantir que les mesures appropriées sont prises pour le système affecté, comme s'il faut déconnecter un système attaqué.

17

Page 27 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Département juridique. Les juristes doivent examiner les plans, politiques et procédures de réponse aux incidents assurer leur conformité avec la loi et les directives fédérales, y compris le droit à la vie privée. De plus, le les conseils de l'avocat général ou du service juridique doivent être demandés s'il y a des raisons de croire un incident peut avoir des ramifications juridiques, y compris la collecte de preuves, la poursuite d'un suspect ou un poursuite, ou s'il peut être nécessaire de conclure un protocole d'accord (MOU) ou autre accords comportant des limitations de responsabilité pour le partage d'informations. ∎ Affaires publiques et relations avec les médias. Selon la nature et l'impact d'un incident, un besoin peut existent pour informer les médias et, par extension, le public. ∎ Ressources humaines . Si un employé est soupçonné d'avoir causé un incident, les ressources humaines le département peut être impliqué - par exemple, pour aider à la procédure disciplinaire. ∎ Planification de la continuité des activités. Les organisations doivent s'assurer que les politiques de réponse aux incidents et les procédures et les processus de continuité d’activité sont synchronisés. Les incidents de sécurité informatique sapent le résilience commerciale d'une organisation. Des professionnels de la planification de la continuité des activités devraient conscients des incidents et de leurs impacts afin qu'ils puissent affiner les évaluations d'impact sur l'entreprise, les risques évaluations et continuité des plans d’exploitation. De plus, parce que les planificateurs de la continuité des activités une vaste expertise dans la minimisation des perturbations opérationnelles dans des circonstances graves, ils peuvent être utile dans la planification des réponses à certaines situations, telles que les conditions de déni de service (DoS). ∎ Sécurité physique et gestion des installations. Certains incidents de sécurité informatique se produisent via atteintes à la sécurité physique ou impliquent des attaques logiques et physiques coordonnées. L'incident l'équipe d'intervention peut également avoir besoin d'accéder aux installations pendant le traitement des incidents, par exemple, pour acquérir un poste de travail compromis depuis un bureau verrouillé. 2.5 Services de l'équipe d'intervention en cas d'incident Le principal objectif d'une équipe d'intervention en cas d'incident est de répondre aux incidents, mais c'est assez rare pour un équipe pour effectuer la réponse aux incidents uniquement. Voici des exemples d'autres services qu'une équipe pourrait offrir: ∎ Détection d'intrusion. Le premier niveau d'une équipe d'intervention en cas d'incident assume souvent la responsabilité détection d'intrusion. 17 L'équipe en bénéficie généralement car elle doit être prête à analyser les incidents plus rapidement et plus précisément, sur la base des connaissances acquises sur les technologies de détection d'intrusion. ∎ Distribution consultative. Une équipe peut émettre des avis au sein de l'organisation concernant de vulnérabilités et menaces. 18 Des méthodes automatisées devraient être utilisées chaque fois que cela est approprié pour diffuser information; par exemple, la National Vulnerability Database (NVD) fournit des informations via XML et les flux RSS lorsque de nouvelles vulnérabilités y sont ajoutées. 19 Les avis sont souvent les plus nécessaires lorsque de nouvelles menaces émergent, comme un événement social ou politique de haut niveau (p. ex. mariage de célébrités) les attaquants sont susceptibles de tirer parti de leur ingénierie sociale. Un seul groupe au sein de l'organisation devrait diffuser des avis de sécurité informatique pour éviter les efforts redondants et les informations contradictoires. ∎ Éducation et sensibilisation. L'éducation et la sensibilisation sont des multiplicateurs de ressources - plus les utilisateurs sont nombreux et le personnel technique sait comment détecter, signaler et réagir aux incidents, moins il y en a

17

18

Voir NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) pour plus d'informations sur IDPS les technologies. Il est disponible à http://csrc.nist.gov/publications/PubsSPs.html#800-94 . Les équipes doivent rédiger des avertissements afin de ne blâmer personne ou organisation pour des problèmes de sécurité. Les équipes doivent se rencontrer avec des conseillers juridiques pour discuter de la nécessité éventuelle d'un avertissement dans les avis, indiquant que l'équipe et l'organisation n'ont pas responsabilité en ce qui concerne l'exactitude de l'avis. Ceci est plus pertinent lorsque des avis peuvent être envoyés aux entrepreneurs, fournisseurs et autres non-employés qui utilisent les ressources informatiques de l'organisation.

https://translate.googleusercontent.com/translate_f

21/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 19

http://nvd.nist.gov/

18

Page 28 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

devrait faire partie de l'équipe d'intervention en cas d'incident. Ces informations peuvent être communiquées via de nombreux signifie: des ateliers, des sites Web, des bulletins d'information, des affiches et même des autocollants sur les moniteurs et les ordinateurs portables. ∎ Partage d'informations. Les équipes d'intervention en cas d'incident participent souvent à des groupes de partage d'informations, en tant que ISAC ou partenariats régionaux. Par conséquent, les équipes d'intervention en cas d'incident gèrent souvent les efforts de partage d'informations sur les incidents de l'organisation, tels que l'agrégation d'informations liées incidents et de partager efficacement ces informations avec d'autres organisations, ainsi que de s'assurer que les informations pertinentes sont partagées au sein de l'entreprise. 2.6 Recommandations Les principales recommandations présentées dans cette section pour organiser une gestion des incidents de sécurité informatique capacités sont résumées ci-dessous. ∎ Établir une capacité formelle de réponse aux incidents. Les organisations doivent être prêtes à réagir rapidement et efficacement en cas de violation des défenses de sécurité informatique. La FISMA exige le gouvernement fédéral agences pour établir des capacités de réponse aux incidents. ∎ Créez une stratégie de réponse aux incidents. La politique de réponse aux incidents est le fondement de l'incident programme de réponse. Il définit quels événements sont considérés comme des incidents, établit les structure de réponse aux incidents, définit les rôles et les responsabilités et énumère les exigences signaler des incidents, entre autres. ∎ Développer un plan de réponse aux incidents basé sur la politique de réponse aux incidents. La réponse à l'incident plan fournit une feuille de route pour la mise en œuvre d'un programme de réponse aux incidents basé sur les politique. Le plan indique les objectifs à court et à long terme du programme, y compris les paramètres mesurer le programme. Le plan d'intervention en cas d'incident doit également indiquer à quelle fréquence les gestionnaires d'incidents devraient être formés et les exigences pour les gestionnaires d'incidents. ∎ Développer des procédures de réponse aux incidents. Les procédures de réponse aux incidents fournissent des étapes détaillées pour répondre à un incident. Les procédures doivent couvrir toutes les phases de l'intervention en cas d'incident processus. Les procédures doivent être basées sur la politique et le plan de réponse aux incidents. ∎ Établir des politiques et des procédures concernant le partage d'informations liées aux incidents. le l'organisation doit communiquer les détails appropriés de l'incident à des parties extérieures, telles que les médias, les organismes d'application de la loi et les organisations de signalement des incidents. L'équipe d'intervention en cas d'incident doit en discuter avec le bureau des affaires publiques, le service juridique et la direction de l'organisation pour établir des politiques et des procédures concernant le partage d'informations. L'équipe doit se conformer politique d'organisation existante sur l'interaction avec les médias et d'autres parties extérieures. ∎ Fournir des informations pertinentes sur les incidents à l'organisation appropriée. Civil fédéral les agences sont tenues de signaler les incidents à l'US-CERT; d'autres organisations peuvent contacter US-CERT et / ou leur ISAC. Le reporting est avantageux car l'US-CERT et les ISAC utilisent les données déclarées pour fournir des informations aux parties déclarantes concernant les nouvelles menaces et les tendances des incidents. ∎ Tenez compte des facteurs pertinents lors de la sélection d'un modèle d'équipe d'intervention en cas d'incident. Organisations devrait peser soigneusement les avantages et les inconvénients de chaque modèle de structure d'équipe possible et modèle de dotation dans le contexte des besoins de l'organisation et des ressources disponibles. ∎ Sélectionnez des personnes possédant les compétences appropriées pour l'équipe d'intervention en cas d'incident. La crédibilité et la compétence de l'équipe dépend dans une large mesure des compétences techniques et des capacités de réflexion critique de ses membres. Les compétences techniques essentielles comprennent l'administration système, l'administration réseau, programmation, support technique et détection d'intrusion. Les compétences en travail d'équipe et en communication sont

19

Page 29 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

également nécessaire pour une gestion efficace des incidents. La formation nécessaire doit être fournie à toute l'équipe membres. ∎ Identifiez d'autres groupes au sein de l'organisation qui pourraient avoir besoin de participer à la gestion des incidents. Chaque équipe d'intervention en cas d'incident s'appuie sur l'expertise, le jugement et les capacités d'autres équipes, y compris gestion, assurance de l'information, support informatique, juridique, affaires publiques et gestion des installations.

https://translate.googleusercontent.com/translate_f

22/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Déterminez les services que l'équipe doit offrir. Bien que l'objectif principal de l'équipe soit l'incident réponse, la plupart des équipes exécutent des fonctions supplémentaires. Les exemples incluent la surveillance de la détection d'intrusion capteurs, diffuser des avis de sécurité et éduquer les utilisateurs sur la sécurité.

20

Piste 30 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

3. Gestion d'un incident Le processus de réponse aux incidents comporte plusieurs phases. La phase initiale consiste à établir et à former un l'équipe d'intervention en cas d'incident et l'acquisition des outils et des ressources nécessaires. Pendant la préparation, le l'organisation tente également de limiter le nombre d'incidents qui se produiront en sélectionnant et en mettant en œuvre un ensemble de contrôles basés sur les résultats des évaluations des risques. Cependant, le risque résiduel persistera inévitablement après la mise en œuvre des contrôles. La détection des failles de sécurité est donc nécessaire pour alerter l'organisation chaque fois que des incidents se produisent. Compte tenu de la gravité de l'incident, l'organisation peut atténuer les l'impact de l'incident en le contenant et finalement en s'en remettant. Pendant cette phase, l'activité souvent retourne à la détection et à l'analyse, par exemple, pour voir si des hôtes supplémentaires sont infectés par des logiciels malveillants tout en supprimant un incident de malware. Une fois l'incident correctement traité, l'organisation émet un rapport qui détaille la cause et le coût de l'incident et les mesures que l'organisation devrait prendre pour éviter incidents futurs. Cette section décrit les principales phases du processus de réponse aux incidents: préparation, détection et analyse, confinement, éradication et récupération, et activité post-incident - en détail. La figure 3-1 illustre le cycle de vie de l'intervention en cas d'incident.

https://translate.googleusercontent.com/translate_f

23/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Figure 3-1. Cycle de vie de la réponse aux incidents

3.1 Préparation Les méthodologies de réponse aux incidents mettent généralement l'accent sur la préparation - pas seulement sur l'établissement d'un incident capacité de réponse afin que l'organisation soit prête à répondre aux incidents, mais aussi à prévenir les incidents en veillant à ce que les systèmes, réseaux et applications soient suffisamment sécurisés. Bien que l'incident l'équipe d'intervention n'est généralement pas responsable de la prévention des incidents, elle est fondamentale pour le succès de programmes de réponse aux incidents. Cette section fournit des conseils de base sur la préparation à la gestion des incidents et sur prévenir les incidents. 3.1.1 Se préparer à gérer les incidents Les listes ci-dessous fournissent des exemples d'outils et de ressources disponibles qui peuvent être utiles lors d'un incident manipulation. Ces listes sont destinées à être un point de départ pour des discussions sur les outils et les ressources les gestionnaires d'incidents de l'organisation ont besoin. Par exemple, les smartphones sont un moyen d'avoir une urgence résiliente

21

Piste 31 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

mécanismes de communication et de coordination. Une organisation doit avoir plusieurs (séparés et différents) mécanismes de communication et de coordination en cas de défaillance d'un mécanisme. Communications et installations du gestionnaire d'incidents: ∎ Coordonnées des membres de l'équipe et d'autres personnes à l'intérieur et à l'extérieur de l'organisation ( contacts de secours), comme les forces de l'ordre et d'autres équipes d'intervention en cas d'incident; l'information peut inclure les numéros de téléphone, les adresses e-mail, les clés de cryptage publiques (conformément au cryptage logiciel décrit ci-dessous) et des instructions pour vérifier l'identité du contact ∎ Informations de garde pour les autres équipes de l'organisation, y compris les informations d'escalade ∎ Mécanismes de signalement des incidents, tels que numéros de téléphone, adresses e-mail, formulaires en ligne et les systèmes de messagerie instantanée que les utilisateurs peuvent utiliser pour signaler les incidents suspects; au moins un mécanisme devrait permettre aux gens de signaler les incidents de manière anonyme ∎ Système de suivi des problèmes pour suivre les informations sur les incidents, leur statut, etc. ∎ Les téléphones intelligents doivent être portés par les membres de l'équipe pour une assistance en dehors des heures d'ouverture et des communications sur site ∎ Logiciel de cryptage à utiliser pour les communications entre les membres de l'équipe, au sein de l'organisation et avec des parties externes; pour les agences fédérales, le logiciel doit utiliser un cryptage validé FIPS algorithme 20 ∎ Salle de guerre pour la communication et la coordination centrales; si une salle de guerre permanente n'est pas nécessaire ou pratique, l'équipe devrait créer une procédure pour se procurer une salle de guerre temporaire en cas de besoin ∎ Installation de stockage sécurisée pour sécuriser les preuves et autres matériels sensibles Matériel et logiciel d'analyse des incidents: ∎ Postes de travail de criminalistique numérique 21 et / ou périphériques de sauvegarde pour créer des images disque, conserver les fichiers journaux et enregistrer d'autres données d'incident pertinentes ∎ Ordinateurs portables pour des activités telles que l'analyse des données, la détection de paquets et la rédaction de rapports ∎ Stations de travail, serveurs et équipements réseau de rechange, ou équivalents virtualisés , qui peut être utilisé à de nombreuses fins, telles que la restauration de sauvegardes et l'essai de logiciels malveillants ∎ Supports amovibles vierges ∎ Imprimante portable pour imprimer des copies de fichiers journaux et autres preuves à partir de systèmes hors réseau ∎ Renifleurs de paquets et analyseurs de protocoles pour capturer et analyser le trafic réseau ∎ Logiciel de criminalistique numérique pour analyser les images disque

https://translate.googleusercontent.com/translate_f

24/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Supports amovibles avec des versions fiables de programmes à utiliser pour recueillir des preuves auprès des systèmes ∎ Accessoires de collecte de preuves , y compris les ordinateurs portables reliés, les appareils photo numériques, les enregistreurs audio, les formulaires de chaîne de possession, les sacs et étiquettes de stockage des preuves, et le ruban adhésif pour actions judiciaires possibles 20 21

FIPS 140-2, Exigences de sécurité pour les modules cryptographiques , http://csrc.nist.gov/publications/PubsFIPS.html . Un poste de travail médico-légal numérique est spécialement conçu pour aider les gestionnaires d'incidents à acquérir et à analyser des données. Celles-ci les postes de travail contiennent généralement un ensemble de disques durs amovibles qui peuvent être utilisés pour le stockage des preuves.

22

Piste 32 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Ressources d'analyse des incidents: ∎ Listes de ports, y compris les ports couramment utilisés et les ports de chevaux de Troie ∎ Documentation pour les systèmes d'exploitation, les applications, les protocoles et les produits de détection d'intrusion et antivirus ∎ Diagrammes de réseau et listes d'actifs critiques, tels que les serveurs de base de données ∎ Lignes de base actuelles de l'activité attendue du réseau, du système et des applications ∎ Hachage cryptographique des fichiers critiques 22 pour accélérer l'analyse, la vérification et l'éradication des incidents Logiciel d'atténuation des incidents: ∎ Accès aux images d'installations d'OS et d'applications propres à des fins de restauration et de récupération De nombreuses équipes d'intervention en cas d'incident créent un kit de saut , qui est une mallette portable contenant des matériaux pouvant être nécessaire lors d’une enquête. Le kit de saut doit être prêt à fonctionner à tout moment. Les kits de saut contiennent plusieurs des mêmes éléments répertoriés dans les listes à puces ci-dessus. Par exemple, chaque kit de saut comprend généralement un ordinateur portable, équipé de logiciels appropriés (p. ex. renifleurs de paquets, criminalistique numérique). Autre important le matériel comprend des périphériques de sauvegarde, des supports vierges et des équipements et câbles réseau de base. Parce que le le but d'avoir un kit de saut est de faciliter des réponses plus rapides, l'équipe doit éviter d'emprunter des articles à le kit de saut. Chaque gestionnaire d'incidents doit avoir accès à au moins deux appareils informatiques (par exemple, des ordinateurs portables). Un, comme celui du kit de saut, doit être utilisé pour effectuer le reniflage de paquets, l'analyse des logiciels malveillants et tous les autres les actions qui risquent de contaminer l'ordinateur portable qui les exécute. Cet ordinateur portable doit être nettoyé et tout logiciel réinstallé avant d'être utilisé pour un autre incident. Notez que parce que cet ordinateur portable est à usage spécial, il est susceptible d'utiliser des logiciels autres que les outils et configurations d'entreprise standard, et à chaque fois il est possible que les gestionnaires d'incidents soient autorisés à spécifier les exigences techniques de base pour ces ordinateurs portables d’enquête. En plus d'un ordinateur portable d'enquête, chaque gestionnaire d'incident doit également avoir un ordinateur portable standard, un téléphone intelligent ou un autre appareil informatique pour rédiger des rapports, lire des e-mails et effectuer d'autres tâches non liées à l'analyse pratique des incidents. Les exercices impliquant des incidents simulés peuvent également être très utiles pour préparer le personnel à la gestion des incidents; voir NIST SP 800-84 pour plus d'informations sur les exercices 23 et l'annexe A pour des exemples de scénarios d'exercices. 3.1.2 Prévention des incidents Il est très important de maintenir le nombre d'incidents raisonnablement bas pour protéger les processus métier du organisation. Si les contrôles de sécurité sont insuffisants, des volumes plus élevés d'incidents peuvent survenir, l'équipe d'intervention en cas d'incident. Cela peut conduire à des réponses lentes et incomplètes, qui se traduisent par une impact commercial négatif (par exemple, dommages plus importants, périodes de service plus longues et indisponibilité des données). Il n'entre pas dans le cadre de ce document de fournir des conseils spécifiques sur la sécurisation des réseaux, des systèmes et applications. Bien que les équipes d'intervention en cas d'incident ne soient généralement pas responsables de la sécurisation des ressources, elles peuvent être les défenseurs de bonnes pratiques de sécurité. Une équipe d'intervention en cas d'incident peut être en mesure d'identifier les problèmes dont l'organisation n'est pas au courant autrement; l'équipe peut jouer un rôle clé dans l'évaluation des risques et formation en identifiant les lacunes. D'autres documents fournissent déjà des conseils sur les concepts généraux de sécurité et 22

23

Le projet NSRL (National Software Reference Library) conserve des enregistrements de hachages de divers fichiers, y compris fichiers d'image système, d'application et graphique. Les hachages peuvent être téléchargés depuishttp://www.nsrl.nist.gov/ . Guide des programmes de test, de formation et d'exercices pour les plans et capacités informatiques, http://csrc.nist.gov/publications/PubsSPs.html#800-84

23

Piste 33 https://translate.googleusercontent.com/translate_f

25/62

21/10/2020

Guide de gestion des incidents de sécurité informatique C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

système d'exploitation et directives spécifiques à l'application. 24 Le texte suivant, cependant, fournit un bref aperçu de certaines des principales pratiques recommandées pour sécuriser les réseaux, les systèmes et les applications: ∎ Évaluations des risques. Les évaluations périodiques des risques des systèmes et des applications devraient déterminer les risques sont posés par des combinaisons de menaces et de vulnérabilités. 25 Cela devrait inclure la compréhension du les menaces applicables, y compris les menaces spécifiques à l'organisation. Chaque risque doit être priorisé et le les risques peuvent être atténués, transférés ou acceptés jusqu'à ce qu'un niveau global de risque raisonnable soit atteint. Un autre avantage de la réalisation régulière d'évaluations des risques est que les ressources critiques sont identifiées, permettant au personnel de mettre l'accent sur les activités de suivi et d'intervention pour ces ressources. 26 ∎ Sécurité de l'hôte. Tous les hôtes doivent être renforcés de manière appropriée en utilisant des configurations standard. en outre pour garder chaque hôte correctement patché, les hôtes doivent être configurés pour suivre le principe du moins privilège: accordant aux utilisateurs uniquement les privilèges nécessaires pour exécuter leurs tâches autorisées. Hôtes doit avoir l'audit activé et doit consigner les événements importants liés à la sécurité. La sécurité des hôtes et leurs configurations doivent être surveillées en permanence. 27 De nombreuses organisations utilisent la sécurité Content Automation Protocol (SCAP) 28 exprimé le système d'exploitation et la configuration de l'application des listes de contrôle pour aider à sécuriser les hôtes de manière cohérente et efficace. 29 ∎ Sécurité du réseau. Le périmètre du réseau doit être configuré pour refuser toute activité qui n'est pas expressément autorisé. Cela inclut la sécurisation de tous les points de connexion, tels que les réseaux privés virtuels (VPN) et des connexions dédiées à d'autres organisations. ∎ Prévention des logiciels malveillants. Les logiciels de détection et d'arrêt des logiciels malveillants doivent être déployés organisation. La protection contre les logiciels malveillants doit être déployée au niveau de l'hôte (par exemple, serveur et poste de travail systèmes d'exploitation), le niveau du serveur d'application (par exemple, serveur de messagerie, proxy Web) et l'application niveau client (par exemple, clients de messagerie, clients de messagerie instantanée). 30 ∎ Sensibilisation et formation des utilisateurs. Les utilisateurs doivent être informés des politiques et procédures concernant utilisation appropriée des réseaux, des systèmes et des applications. Les leçons applicables tirées des les incidents doivent également être partagés avec les utilisateurs afin qu'ils puissent voir comment leurs actions peuvent affecter organisation. Améliorer la sensibilisation des utilisateurs aux incidents devrait réduire la fréquence des incidents. Le personnel informatique doit être formé afin de pouvoir maintenir ses réseaux, systèmes et applications conformément aux normes de sécurité de l'organisation.

24

25

26

27

28

29 30

http://csrc.nist.gov/publications/PubsSPs.html fournit des liens vers les publications spéciales du NIST sur la sécurité informatique , qui inclure des documents sur le système d'exploitation et les références de sécurité des applications. Des lignes directrices sur l'évaluation des risques sont disponibles dans NIST SP 800-30, Guide for Conducting Risk Assessments , à l' adresse http://csrc.nist.gov/publications/PubsSPs.html#800-30-Rev1 . Les informations sur l'identification des ressources critiques sont traitées dans la norme FIPS 199, Standards for Security Catégorization of Federal Information and Information Systems , à http://csrc.nist.gov/publications/PubsFIPS.html . Pour plus d'informations sur la surveillance continue, voir NIST SP 800-137, Information Security Continuous Monitoring for Systèmes d'information et organisations fédérales ( http://csrc.nist.gov/publications/PubsSPs.html#800-137 ) . Plus d'informations sur SCAP sont disponibles dans NIST SP 800-117 Revision 1, Guide to Adopting and Using the Security Protocole d'automatisation du contenu (SCAP) version 1.2 ( http://csrc.nist.gov/publications/PubsSPs.html#800-117 ) . Le NIST héberge un référentiel de listes de contrôle de sécurité à l' adresse http://checklists.nist.gov/ . Pour plus d'informations sur la prévention des logiciels malveillants, consultez le NIST SP 800-83, Guide to Malware Incident Prevention et Manipulation ( http://csrc.nist.gov/publications/PubsSPs.html#800-83 ) .

24

Piste 34 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

3.2 Détection et analyse

https://translate.googleusercontent.com/translate_f

26/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Figure 3-2. Cycle de vie de la réponse aux incidents (détection et analyse)

3.2.1 Vecteurs d'attaque Les incidents peuvent se produire d'innombrables façons, il est donc impossible de développer des instructions étape par étape pour la gestion chaque incident. Les organisations doivent être généralement préparées à gérer tout incident, mais doivent se concentrer sur être prêt à gérer les incidents utilisant des vecteurs d'attaque courants. Différents types d'incidents méritent différentes stratégies de réponse. Les vecteurs d'attaque énumérés ci-dessous ne sont pas destinés à fournir des classification des incidents; au contraire, ils énumèrent simplement les méthodes d'attaque courantes, qui peuvent être utilisées comme base pour définir des procédures de manipulation plus spécifiques. ∎ Support externe / amovible: attaque exécutée à partir d'un support amovible ou d'un périphérique Par exemple, un code malveillant se propage sur un système à partir d'une clé USB infectée. ∎ Attrition: attaque qui utilise des méthodes de force brute pour compromettre, dégrader ou détruire des systèmes, réseaux ou services (par exemple, un DDoS destiné à empêcher ou à refuser l'accès à un service ou une application; attaque par force brute contre un mécanisme d'authentification, tel que les mots de passe, CAPTCHAS ou numérique signatures). ∎ Web: attaque exécutée à partir d'un site Web ou d'une application Web, par exemple, un site intersite attaque de script utilisée pour voler des informations d'identification ou une redirection vers un site qui exploite une vulnérabilité de navigateur et installe des logiciels malveillants. ∎ E-mail: attaque exécutée via un e-mail ou une pièce jointe - par exemple, un code d'exploitation déguisé sous forme de document joint ou de lien vers un site Web malveillant dans le corps d'un e-mail. ∎ Usurpation d'identité: attaque impliquant le remplacement d'un élément bénin par un élément malveillant. par exemple, usurpation d'identité, attaques par l'homme du milieu, points d'accès sans fil non autorisés et injection SQL les attaques impliquent toutes une usurpation d'identité. ∎ Utilisation incorrecte: tout incident résultant de la violation de l'utilisation acceptable d'une organisation les politiques par un utilisateur autorisé, à l'exclusion des catégories ci-dessus; par exemple, un utilisateur installe le partage de fichiers logiciel, entraînant la perte de données sensibles; ou un utilisateur effectue des activités illégales sur un système.

25

Piste 35 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Perte ou vol d'équipement: la perte ou le vol d'un appareil informatique ou d'un support utilisé par le organisation, comme un ordinateur portable, un smartphone ou un jeton d'authentification. ∎ Autre: une attaque qui ne rentre dans aucune des autres catégories. Cette section se concentre sur les pratiques recommandées pour gérer tout type d'incident. C'est hors de portée de cette publication pour donner des conseils spécifiques basés sur les vecteurs d'attaque; de telles directives seraient fournies dans des publications séparées traitant d'autres sujets de gestion des incidents, tels que NIST SP 800-83 sur les logiciels malveillants prévention et traitement des incidents. 3.2.2 Signes d'un incident Pour de nombreuses organisations, la partie la plus difficile du processus de réponse aux incidents est la détection précise et évaluer les incidents possibles - déterminer si un incident s'est produit et, dans l'affirmative, le type, l’étendue et l’ampleur du problème. Ce qui rend cela si difficile est une combinaison de trois facteurs: ∎ Les incidents peuvent être détectés par de nombreux moyens différents, avec différents niveaux de détail et de fidélité. Les capacités de détection automatisées comprennent les IDPS basés sur le réseau et sur l'hôte, les logiciels antivirus, et analyseurs de journaux. Les incidents peuvent également être détectés par des moyens manuels, tels que les problèmes signalés par les utilisateurs. Certains incidents ont des signes évidents qui peuvent être facilement détectés, tandis que d'autres sont presque impossible à détecter. ∎ Le volume de signes potentiels d'incidents est généralement élevé - par exemple, il n'est pas rare qu'un organisation pour recevoir des milliers, voire des millions d'alertes de capteurs de détection d'intrusion par jour. (Voir Section 3.2.4 pour plus d'informations sur l'analyse de ces alertes.) ∎ Des connaissances techniques approfondies et spécialisées et une vaste expérience sont nécessaires pour analyse efficace des données relatives aux incidents. Les signes d'un incident appartiennent à l'une des deux catégories suivantes: les précurseurs et les indicateurs. Un précurseur est un signe que un incident peut se produire dans le futur. Un indicateur est un signe qu'un incident peut s'être produit ou se produisant maintenant. La plupart des attaques n'ont pas de précurseurs identifiables ou détectables du point de vue de la cible. Si précurseurs sont détectés, l'organisation peut avoir la possibilité de prévenir l'incident en modifiant son

https://translate.googleusercontent.com/translate_f

27/62

21/10/2020

Guide de gestion des incidents de sécurité informatique posture de sécurité pour sauver une cible d'une attaque. Au minimum, l'organisation pourrait surveiller l'activité impliquer plus étroitement la cible. Des exemples de précurseurs sont: ∎ Entrées du journal du serveur Web qui montrent l'utilisation d'un scanner de vulnérabilité ∎ Une annonce d'un nouvel exploit qui cible une vulnérabilité du serveur de messagerie de l'organisation ∎ Une menace d'un groupe indiquant que le groupe attaquera l'organisation. Si les précurseurs sont relativement rares, les indicateurs sont trop courants. Il existe trop de types d'indicateurs pour les lister de manière exhaustive, mais quelques exemples sont listés ci-dessous: ∎ Un capteur de détection d'intrusion réseau alerte lorsqu'une tentative de dépassement de tampon se produit sur une base de données serveur. ∎ Le logiciel antivirus alerte lorsqu'il détecte qu'un hôte est infecté par un logiciel malveillant. ∎ Un administrateur système voit un nom de fichier avec des caractères inhabituels. ∎ Un hôte enregistre un changement de configuration d'audit dans son journal.

26

Piste 36 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Une application enregistre plusieurs tentatives de connexion infructueuses à partir d'un système distant inconnu. ∎ Un administrateur de messagerie voit un grand nombre d'e-mails rejetés avec un contenu suspect. ∎ Un administrateur réseau remarque un écart inhabituel par rapport aux flux de trafic réseau typiques. 3.2.3 Sources de précurseurs et indicateurs Les précurseurs et les indicateurs sont identifiés à l'aide de nombreuses sources différentes, la plus courante étant alertes de logiciels de sécurité informatique, journaux, informations accessibles au public et personnes. Tableau 3-2 listes sources communes de précurseurs et d'indicateurs pour chaque catégorie. Tableau 3-1. Sources communes de précurseurs et d'indicateurs La source

La description Alertes

IDPS

Les produits IDPS identifient les événements suspects et enregistrent les données pertinentes les concernant, y compris date et heure de détection de l'attaque, type d'attaque, adresse IP source et destination adresses et le nom d'utilisateur (le cas échéant et connu). La plupart des produits IDPS utilisent l'attaque signatures pour identifier les activités malveillantes; les signatures doivent être tenues à jour afin que le les attaques les plus récentes peuvent être détectées. Les logiciels IDPS produisent souvent des faux positifs - des alertes qui indiquent qu'une activité malveillante est en cours, alors qu'en fait il n'y en a pas eu. Les analystes devraient valider manuellement les alertes IDPS soit en examinant attentivement les données de support enregistrées, soit en obtenir des données connexes à partir d'autres sources. 31

SIEM

Les produits SIEM (Security Information and Event Management) sont similaires aux produits IDPS, mais ils génèrent des alertes basées sur l'analyse des données du journal (voir ci-dessous).

Antivirus et anti-spam Logiciel

Le logiciel antivirus détecte diverses formes de logiciels malveillants, génère des alertes et empêche les logiciels malveillants des hôtes infectants. Les produits antivirus actuels sont efficaces pour arrêter de nombreuses instances de malware si leurs signatures sont tenues à jour. Un logiciel antispam est utilisé pour détecter le spam et l'empêcher d'atteindre les boîtes aux lettres des utilisateurs. Le spam peut contenir des logiciels malveillants, des attaques de phishing et tout autre contenu malveillant, de sorte que les alertes des logiciels anti-spam peuvent indiquer des tentatives d'attaque.

Intégrité des fichiers vérification Logiciel

Un logiciel de vérification de l'intégrité des fichiers peut détecter les modifications apportées aux fichiers importants lors d'incidents. Il utilise un algorithme de hachage pour obtenir une somme de contrôle cryptographique pour chaque fichier désigné. Si le fichier est modifiée et la somme de contrôle est recalculée, il existe une probabilité extrêmement élevée que le nouveau la somme de contrôle ne correspondra pas à l'ancienne somme de contrôle. En recalculant régulièrement les sommes de contrôle et en comparant avec les valeurs précédentes, les modifications apportées aux fichiers peuvent être détectées.

Tierce personne surveillance prestations de service

Les tiers offrent une variété de services de surveillance gratuits et par abonnement. Un exemple est des services de détection de fraude qui informeront une organisation si ses adresses IP, noms de domaine, etc. sont associés aux incidents actuels impliquant d'autres organisations. Il existe également des listes noires en temps réel avec des informations similaires. Un autre exemple de service de surveillance tiers est une liste de notification du CSIRC; ces listes ne sont souvent disponibles que pour les autres équipes d'intervention en cas d'incident.

en fonctionnement système, service et application journaux

Les journaux des systèmes d'exploitation, des services et des applications (en particulier les données d'audit) sont souvent d'une grande valeur lorsqu'un incident se produit, comme l'enregistrement des comptes accédé et quelles actions ont été effectuées. Les organisations devraient exiger un niveau de base de journalisation sur tous les systèmes et un niveau de référence plus élevé sur les systèmes critiques. Les journaux peuvent être utilisés pour analyse en corrélant les informations d'événement. En fonction des informations sur l'événement, une alerte peut être généré pour indiquer un incident. La section 3.2.4 traite de la valeur de la journalisation centralisée.

Réseau journaux de l'appareil

Les journaux des périphériques réseau tels que les pare-feu et les routeurs ne sont généralement pas une source principale de précurseurs ou indicateurs. Bien que ces appareils soient généralement configurés pour se connecter bloqués tentatives de connexion, ils fournissent peu d'informations sur la nature de l'activité. Pourtant, ils peuvent être utile pour identifier les tendances du réseau et pour corréler les événements détectés par d'autres appareils.

Journaux

31

Voir NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems, pour plus d'informations sur les produits IDPS. Il est disponible à http://csrc.nist.gov/publications/PubsSPs.html#800-94 .

https://translate.googleusercontent.com/translate_f

28/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

27

Piste 37 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

La source

La description

Flux réseau Un flux réseau est une session de communication particulière se produisant entre les hôtes. Routeurs et d'autres périphériques réseau peuvent fournir des informations sur le flux réseau, qui peuvent être utilisées pour trouver activité réseau anormale causée par des logiciels malveillants, l'exfiltration de données et d'autres actes malveillants. Là Il existe de nombreuses normes pour les formats de données de flux, notamment NetFlow, sFlow et IPFIX. Informations accessibles au public Des informations sur Nouveau vulnérabilités et exploits

Se tenir au courant des nouvelles vulnérabilités et exploits peut empêcher certains incidents de se produire et aider à détecter et analyser les nouvelles attaques. La base de données nationale sur les vulnérabilités (NVD) contient des informations sur les vulnérabilités. 32 organisations telles que US-CERT 33 et CERT ® / CC fournir périodiquement des informations de mise à jour sur les menaces via des briefings, des publications Web et des listes de diffusion.

Des gens de dans le organisation

Utilisateurs, administrateurs système, administrateurs réseau, personnel de sécurité et autres personnes l'organisation peut signaler des signes d'incidents. Il est important de valider tous ces rapports. Un approche consiste à demander aux personnes qui fournissent de telles informations dans quelle mesure elles ont confiance en l'exactitude des informations. L'enregistrement de cette estimation avec les informations fournies peut aider considérablement lors de l'analyse des incidents, en particulier lorsque des données contradictoires sont découvertes.

Des gens de autre les organisations

Les rapports d'incidents provenant de l'extérieur doivent être pris au sérieux. Par exemple, le l'organisation peut être contactée par une partie affirmant qu'un système de l'organisation attaque son systèmes. Les utilisateurs externes peuvent également signaler d'autres indicateurs, tels qu'une page Web dégradée ou un service indisponible. D'autres équipes d'intervention en cas d'incident peuvent également signaler des incidents. Il est important de mettre en place des mécanismes permettant aux parties externes de rendre compte des indicateurs et au personnel formé pour surveiller ces mécanismes soigneusement; cela peut être aussi simple que de configurer un numéro de téléphone et une adresse e-mail adresse, configurée pour transférer les messages vers le service d'assistance.

Gens

3.2.4 Analyse des incidents La détection et l'analyse des incidents seraient faciles si chaque précurseur ou indicateur était garanti précis; Malheureusement, ce n'est pas le cas. Par exemple, les indicateurs fournis par l'utilisateur, comme une plainte un serveur étant indisponible sont souvent incorrects. Les systèmes de détection d'intrusion peuvent produire des faux positifs— indicateurs incorrects. Ces exemples montrent ce qui rend la détection et l'analyse des incidents si difficiles: chaque indicateur devrait idéalement être évalué pour déterminer s'il est légitime. Pour aggraver les choses, le total le nombre d'indicateurs peut être de milliers ou de millions par jour. Trouver les vrais incidents de sécurité qui se sont produits de tous les indicateurs peut être une tâche ardue. Même si un indicateur est précis, cela ne signifie pas nécessairement qu'un incident s'est produit. Certains des indicateurs, comme une panne du serveur ou la modification de fichiers critiques, peuvent survenir pour plusieurs raisons, d'autres qu'un incident de sécurité, y compris une erreur humaine. Compte tenu de l'apparition d'indicateurs, cependant, il est raisonnable de soupçonner qu'un incident pourrait se produire et d'agir en conséquence. Déterminer si un événement particulier est en fait un incident est parfois une question de jugement. Il peut être nécessaire de collaborer avec d'autres membres du personnel technique et de sécurité de l'information pour prendre une décision. Dans de nombreux cas, une situation doit être traitée de la même manière, qu'elle soit ou non liée à la sécurité. Par exemple, si un l'organisation perd sa connectivité Internet toutes les 12 heures et personne ne connaît la cause, le personnel veulent résoudre le problème tout aussi rapidement et utiliseraient les mêmes ressources pour diagnostiquer le problème, quelle que soit sa cause. Certains incidents sont faciles à détecter, comme une page Web manifestement altérée. Cependant, de nombreux incidents sont pas associé à des symptômes aussi clairs. Petits signes tels qu'une modification dans un fichier de configuration système peuvent être les seuls indicateurs qu'un incident s'est produit. Dans la gestion des incidents, la détection peut être la plus tâche difficile. Les gestionnaires d'incidents sont chargés d'analyser les éléments ambigus, contradictoires et incomplets symptômes pour déterminer ce qui s’est passé. Bien que des solutions techniques existent pour permettre la détection 32 33

http://nvd.nist.gov/ http://www.us-cert.gov/cas/signup.html

28

Piste 38 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

plus facile, le meilleur remède est de constituer une équipe de membres du personnel hautement expérimentés et compétents qui peuvent analyser les précurseurs et les indicateurs de manière efficace et efficiente et prendre les mesures appropriées. Sans un personnel bien formé et compétent, la détection et l'analyse des incidents seront menées de manière inefficace et coûteuse des erreurs seront commises. L'équipe d'intervention en cas d'incident doit travailler rapidement pour analyser et valider chaque incident, après une

https://translate.googleusercontent.com/translate_f

29/62

21/10/2020

Guide de gestion des incidents de sécurité informatique processus défini et documentant étape prise. l'équipe estime qu'un s'est l'équipe doit effectuer rapidementchaque une analyse initialeLorsque pour déterminer la portée de incident l'incident, parproduit, exemple les réseaux, systèmes ou applications sont affectés; qui ou quoi est à l'origine de l'incident; et comment l'incident se produit (par exemple, quels outils ou méthodes d'attaque sont utilisés, quelles vulnérabilités sont exploitées). L'analyse initiale doit fournir suffisamment d'informations pour permettre à l'équipe de prioriser les activités ultérieures, comme le confinement de l'incident et une analyse plus approfondie des effets de l'incident. Effectuer l'analyse et la validation initiales est un défi. Voici des recommandations pour rendre l'analyse des incidents plus simple et plus efficace: ∎ Profil des réseaux et des systèmes. Le profilage consiste à mesurer les caractéristiques de l'activité attendue afin que les modifications apportées peuvent être plus facilement identifiées. Des exemples de profilage exécutent la vérification de l'intégrité des fichiers logiciel sur les hôtes pour obtenir des sommes de contrôle pour les fichiers critiques et surveiller l'utilisation de la bande passante du réseau pour déterminer quels sont les niveaux d'utilisation moyens et maximaux à différents jours et heures. En pratique, c'est difficile de détecter les incidents avec précision à l'aide de la plupart des techniques de profilage; les organisations devraient utiliser le profilage comme l'une des nombreuses techniques de détection et d'analyse. ∎ Comprendre les comportements normaux. Les membres de l'équipe d'intervention en cas d'incident doivent étudier les réseaux, les systèmes, et les applications pour comprendre quel est leur comportement normal afin qu'un comportement anormal puisse être reconnu plus facilement. Aucun gestionnaire d'incidents n'aura une connaissance approfondie de tous les comportements dans tout l'environnement, mais les gestionnaires doivent savoir quels experts pourraient combler les lacunes. Une manière pour acquérir ces connaissances, il faut consulter les entrées de journal et les alertes de sécurité. Cela peut être fastidieux si le filtrage n'est pas utilisé pour condenser les journaux à une taille raisonnable. À mesure que les gestionnaires se familiarisent avec les journaux et les alertes, ils devraient pouvoir se concentrer sur les entrées inexpliquées, qui sont généralement plus important d'enquêter. La réalisation d'examens fréquents des journaux devrait garder les connaissances à jour et l'analyste doit être capable de remarquer les tendances et les changements au fil du temps. Les revues donnent également à l'analyste un indication de la fiabilité de chaque source. ∎ Créez une stratégie de conservation des journaux. Les informations relatives à un incident peuvent être enregistrées à plusieurs endroits, tels que le pare-feu, l'IDPS et les journaux d'application. Création et mise en œuvre d'une politique de rétention des journaux spécifie la durée de conservation des données de journal peut être extrêmement utile dans l'analyse car les entrées de journal peuvent montrer une activité de reconnaissance ou des instances antérieures d'attaques similaires. Une autre raison pour la conservation des journaux, les incidents peuvent ne pas être découverts avant des jours, des semaines ou même des mois plus tard. le la durée de conservation des données du journal dépend de plusieurs facteurs, y compris les données de l'organisation les politiques de rétention et le volume de données. Voir NIST SP 800-92, Guide to Computer Security Log Gestion des recommandations supplémentaires liées à la journalisation. 34 ∎ Effectuer une corrélation d'événements. Les preuves d'un incident peuvent être consignées dans plusieurs journaux qui contiennent différents types de données - un journal de pare-feu peut avoir l'adresse IP source qui a été utilisée, alors que un journal d'application peut contenir un nom d'utilisateur. Un IDPS réseau peut détecter qu'une attaque a été lancée contre un hôte particulier, mais il peut ne pas savoir si l'attaque a réussi. L'analyste devra peut-être examinez les journaux de l'hôte pour déterminer ces informations. Corréler les événements entre plusieurs indicateurs les sources peuvent être inestimables pour valider si un incident particulier s'est produit.

34

http://csrc.nist.gov/publications/PubsSPs.html#800-92

29

Piste 39 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Gardez toutes les horloges de l'hôte synchronisées. Protocoles tels que le Network Time Protocol (NTP) synchroniser les horloges entre les hôtes. 35 La corrélation des événements sera plus compliquée si les appareils les événements ont des paramètres d'horloge incohérents. Du point de vue de la preuve, il est préférable d'avoir horodatage cohérent dans les journaux, par exemple, pour avoir trois journaux indiquant qu'une attaque s'est produite à 00:07:01, plutôt que des journaux indiquant que l'attaque s'est produite à 12:07:01, 12:10:35 et 11:07:06. ∎ Maintenir et utiliser une base de connaissances d'informations. La base de connaissances devrait inclure informations dont les gestionnaires ont besoin pour référencer rapidement lors de l'analyse des incidents. Bien que ce soit possible de construire une base de connaissances avec une structure complexe, une approche simple peut être efficace. Texte des documents, des feuilles de calcul et des bases de données relativement simples fournissent des outils efficaces, flexibles et interrogeables mécanismes de partage des données entre les membres de l'équipe. La base de connaissances doit également contenir un variété d'informations, y compris des explications sur l'importance et la validité des précurseurs et indicateurs, tels que les alertes IDPS, les entrées de journal du système d'exploitation et les codes d'erreur d'application. ∎ Utilisez les moteurs de recherche Internet pour la recherche. Les moteurs de recherche Internet peuvent aider les analystes à trouver informations sur une activité inhabituelle. Par exemple, un analyste peut voir des tentatives de connexion inhabituelles ciblant le port TCP 22912. Une recherche sur les termes «TCP», «port» et «22912» peut renvoyer certains hits qui contiennent des journaux d'activité similaire ou même une explication de l'importance du port nombre. Notez que des postes de travail séparés doivent être utilisés pour la recherche afin de minimiser le risque organisation de mener ces recherches. ∎ Exécutez Packet Sniffers pour collecter des données supplémentaires. Parfois, les indicateurs n'enregistrent pas suffisamment détail pour permettre au gestionnaire de comprendre ce qui se passe. Si un incident survient sur une réseau, le moyen le plus rapide de collecter les données nécessaires peut être d'avoir un réseau de capture de renifleur de paquets trafic. La configuration du sniffer pour enregistrer le trafic qui correspond aux critères spécifiés doit conserver le volume

https://translate.googleusercontent.com/translate_f

30/62

21/10/2020

Guide de gestion des incidents de sécurité informatique de données gérables et minimiser la capture accidentelle d’autres informations. En raison de la confidentialité préoccupations, certaines organisations peuvent exiger que les gestionnaires d'incidents demandent et reçoivent l'autorisation avant en utilisant des renifleurs de paquets. ∎ Filtrer les données. Il n'y a tout simplement pas assez de temps pour examiner et analyser tous les indicateurs; à au minimum, l'activité la plus suspecte doit faire l'objet d'une enquête. Une stratégie efficace consiste à filtrer catégories d'indicateurs qui ont tendance à être insignifiantes. Une autre stratégie de filtrage consiste à n'afficher que les les catégories d'indicateurs les plus significatives; cependant, cette approche comporte des risque parce qu'une nouvelle activité malveillante peut ne pas entrer dans l'une des catégories d'indicateurs choisies. ∎ Demandez l'aide d'autres personnes. Parfois, l'équipe sera incapable de déterminer la cause complète et la nature d'un incident. Si l'équipe ne dispose pas d'informations suffisantes pour contenir et éradiquer l'incident, il devrait ensuite consulter les ressources internes (p. ex., le personnel chargé de la sécurité de l'information) et les ressources externes (par exemple, US-CERT, autres CSIRT, sous-traitants ayant une expertise en réponse aux incidents). Il est important de déterminer avec précision la cause de chaque incident afin qu'il puisse être entièrement contenu et exploité les vulnérabilités peuvent être atténuées pour empêcher des incidents similaires de se produire. 3.2.5 Documentation des incidents Une équipe d'intervention en cas d'incident qui soupçonne qu'un incident s'est produit doit immédiatement commencer à enregistrer tous les faits concernant l'incident. 36 Un journal de bord est un moyen efficace et simple pour cela, 37 mais les ordinateurs portables,

35 36

37

De plus amples informations sur NTP sont disponibles sur http://www.ntp.org/ . Les gestionnaires d'incidents doivent enregistrer uniquement les faits concernant l'incident, et non les opinions ou conclusions personnelles. Matériel subjectif doivent être présentés dans les rapports d'incident et non enregistrés comme preuves. Si un journal est utilisé, il est préférable que le journal soit relié et que les gestionnaires d'incident numérotent les pages, écrivent à l'encre, et laissez le journal intacte (c.-à-d. ne déchirez aucune page).

30

Piste 40 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

les enregistreurs audio et les appareils photo numériques peuvent également servir à cette fin. 38 Documenter les événements du système, les conversations et les changements observés dans les fichiers peuvent conduire à un processus plus efficace, plus systématique et moins d'erreurs. gestion encline du problème. Chaque étape prise depuis le moment où l'incident a été détecté jusqu'à sa fin la résolution doit être documentée et horodatée. Chaque document concernant l'incident doit être daté et signé par le gestionnaire d'incident. Des informations de cette nature peuvent également être utilisées comme preuve dans un tribunal si des poursuites judiciaires sont engagées. Dans la mesure du possible, les manutentionnaires doivent travailler en équipes d'au moins deux: une personne peut enregistrer et consigner les événements tandis que l'autre effectue les tâches techniques. Section 3.3.2 présente plus d'informations sur les preuves. 39 L'équipe d'intervention en cas d'incident doit conserver des enregistrements sur l'état des incidents, ainsi que d'autres information pertinente. 40 L' utilisation d'une application ou d'une base de données, comme un système de suivi des problèmes, permet de garantir que les incidents sont traités et résolus en temps opportun. Le système de suivi des problèmes doit contenir informations sur les éléments suivants: ∎ L'état actuel de l'incident (nouveau, en cours, transmis pour enquête, résolu, etc.) ∎ Un résumé de l'incident ∎ Indicateurs liés à l'incident ∎ Autres incidents liés à cet incident ∎ Mesures prises par tous les gestionnaires d'incidents sur cet incident ∎ Chaîne de contrôle, le cas échéant ∎ Analyses d'impact liées à l'incident ∎ Coordonnées des autres parties impliquées (par exemple, propriétaires de système, administrateurs système) ∎ Une liste des preuves recueillies lors de l'enquête sur l'incident ∎ Commentaires des gestionnaires d'incidents ∎ Prochaines étapes à suivre (par exemple, reconstruire l'hôte, mettre à niveau une application). 41 L'équipe d'intervention en cas d'incident doit protéger les données d'incident et en limiter l'accès car contient des informations sensibles, par exemple des données sur des vulnérabilités exploitées, des failles de sécurité récentes, et les utilisateurs qui peuvent avoir effectué des actions inappropriées. Par exemple, seul le personnel autorisé doit avoir accès à la base de données des incidents. Les communications sur les incidents (par exemple, les courriels) et les documents doivent être cryptés ou protégés d'une autre manière afin que seul le personnel autorisé puisse les lire.

38

Considérez l'admissibilité des preuves recueillies avec un appareil avant de l'utiliser. Par exemple, tout appareil potentiellement

https://translate.googleusercontent.com/translate_f

31/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 39

40

41

les sources de preuves pasForensic elles-mêmes être utilisées pour enregistrer NIST SP 800-86, Guidenetodevraient Integrating Techniques into Incident Response,d'autres fournitpreuves. des informations détaillées sur l'établissement d'une capacité médico-légale, y compris l'élaboration de politiques et de procédures. L'annexe B contient une liste suggérée d'éléments de données à recueillir lorsque des incidents sont signalés. Aussi, le CERT ® / CC le document State of the Practice of Computer Security Incident Response Teams (CSIRT) fournit plusieurs exemples d'incidents formulaires de déclaration. Le document est disponible à http://www.cert.org/archive/pdf/03tr001.pdf . L'Association transeuropéenne de mise en réseau de la recherche et de l'éducation (TERENA) a développé la RFC 3067, TERENA Description des objets d'incident et exigences de format d'échange ( http://www.ietf.org/rfc/rfc3067.txt ) . Le document fournit des recommandations sur les informations à collecter pour chaque incident. L'incident étendu de l'IETF Groupe de travail Manipulation (pouces) (http://www.cert.org/ietf/inch/inch.html ) a créé un RFC qui étend les work — RFC 5070, Format d'échange de description d'objet d'incident ( http://www.ietf.org/rfc/rfc5070.txt ) .

31

Piste 41 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

3.2.6 Hiérarchisation des incidents Donner la priorité au traitement de l'incident est peut-être le point de décision le plus critique dans le traitement de l'incident processus. Les incidents ne doivent pas être traités sur la base du premier arrivé, premier servi en raison des ressources limites. Au lieu de cela, la gestion doit être hiérarchisée en fonction des facteurs pertinents, tels que les suivants: ∎ Impact fonctionnel de l'incident. Les incidents ciblant les systèmes informatiques ont généralement un impact sur l'entreprise fonctionnalité fournie par ces systèmes, entraînant un certain type d'impact négatif pour les utilisateurs ces systèmes. Les gestionnaires d'incidents devraient considérer l'impact de l'incident sur le fonctionnalité des systèmes concernés. Les gestionnaires d'incidents ne doivent pas seulement tenir compte des l'impact fonctionnel de l'incident, mais aussi l'impact fonctionnel futur probable de l'incident s'il ne l'est pas contenue immédiatement. ∎ Impact informationnel de l'incident. Les incidents peuvent affecter la confidentialité, l'intégrité et disponibilité des informations de l'organisation. Par exemple, un agent malveillant peut exfiltrer des information. Les gestionnaires d'incidents doivent réfléchir à l'impact de cette exfiltration d'informations sur le mission globale de l'organisation. Un incident entraînant l'exfiltration d'informations sensibles peut affectent également d'autres organisations si l'une des données se rapporte à une organisation partenaire. ∎ Récupérabilité de l'incident. La taille de l'incident et le type de ressources qu'il affecte déterminez le temps et les ressources à consacrer à la récupération après cet incident. Dans dans certains cas, il n'est pas possible de se remettre d'un incident (par exemple, si la confidentialité l'information a été compromise) et il ne serait pas logique de consacrer des ressources limitées à un cycle de traitement des incidents allongé, à moins que cet effort ne vise à garantir qu'un incident similaire n'a pas eu lieu à l'avenir. Dans d'autres cas, un incident peut nécessiter beaucoup plus de ressources à gérer que ce qu'une organisation a à sa disposition. Les gestionnaires d'incidents devraient envisager l'effort nécessaire pour se remettre d'un incident et peser soigneusement cela par rapport à la valeur que l'effort de récupération créera et toutes les exigences liées à la gestion des incidents. Combinant l'impact fonctionnel sur les systèmes de l'organisation et l'impact sur les les informations déterminent l'impact commercial de l'incident, par exemple, un déni de service distribué une attaque contre un serveur Web public peut temporairement réduire la fonctionnalité pour les utilisateurs qui tentent d'accéder le serveur, alors qu'un accès non autorisé au niveau racine à un serveur Web public peut entraîner l'exfiltration de des informations personnelles identifiables (PII), qui pourraient avoir un impact durable sur les réputation. La récupérabilité de l'incident détermine les réponses possibles que l'équipe peut prendre lorsque gérer l'incident. Un incident avec un impact fonctionnel élevé et un faible effort de récupération est un idéal candidat pour une action immédiate de l'équipe. Cependant, certains incidents peuvent ne pas avoir une récupération en douceur et peut devoir être mis en file d'attente pour une réponse de niveau plus stratégique, par exemple, un incident qui permet à un attaquant d'exfiltrer et de publier publiquement des gigaoctets de données sensibles sans récupération facile chemin puisque les données sont déjà exposées; dans ce cas, l'équipe peut transférer une partie de la responsabilité gérer l'incident d'exfiltration de données à une équipe de niveau plus stratégique qui développe une stratégie de prévention futures violations et crée un plan de sensibilisation pour alerter les individus ou organisations dont les données a été exfiltré. L'équipe doit prioriser la réponse à chaque incident en fonction de son estimation du l'impact commercial causé par l'incident et les efforts estimés nécessaires pour se remettre de l'incident. Une organisation peut mieux quantifier l'effet de ses propres incidents en raison de sa conscience de la situation. Le tableau 3-2 fournit des exemples de catégories d'impact fonctionnel qu'une organisation pourrait utiliser pour évaluer ses propres incidents. L'évaluation des incidents peut être utile pour hiérarchiser les ressources limitées.

32

Piste 42 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

https://translate.googleusercontent.com/translate_f

32/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Tableau 3-2. Catégories d'impact fonctionnel Catégorie

Définition

Aucun

Aucun effet sur la capacité de l'organisation à fournir tous les services à tous les utilisateurs

Faible

Effet minimal; l'organisation peut toujours fournir tous les services critiques à tous les utilisateurs mais a perdu Efficacité

Moyen

L'organisation a perdu la capacité de fournir un service critique à un sous-ensemble d'utilisateurs du système

Haute

L'organisation n'est plus en mesure de fournir certains services essentiels à aucun utilisateur

Le tableau 3-3 donne des exemples de catégories d'impact d'information possibles qui décrivent l'étendue de compromission d’informations survenue lors de l’incident. Dans ce tableau, à l'exception du 'Aucun' valeur, les catégories ne s’excluent pas mutuellement et l’organisation peut en choisir plusieurs. Tableau 3-3. Catégories d'impact de l'information Catégorie

Définition

Aucun

Aucune information n'a été exfiltrée, modifiée, supprimée ou autrement compromise

Intimité Violation

Informations personnelles sensibles (PII) des contribuables, employés, bénéficiaires, etc. a été accédé ou exfiltré

Propriétaire Violation

Informations exclusives non classées, telles que les informations sur les infrastructures critiques protégées (PCII), a été accédé ou exfiltré

Intégrité Perte

Des informations sensibles ou exclusives ont été modifiées ou supprimées

Le tableau 3-4 montre des exemples de catégories d'effort de récupérabilité qui reflètent le niveau et le type de ressources nécessaire pour se remettre de l'incident. Tableau 3-4. Catégories d'effort de récupérabilité Catégorie

Définition

Ordinaire

Le temps de récupération est prévisible avec les ressources existantes

Complété

Le temps de récupération est prévisible avec des ressources supplémentaires

Élargi

Le temps de récupération est imprévisible; des ressources supplémentaires et une aide extérieure sont nécessaires

Non récupérable La récupération après l'incident n'est pas possible (par exemple, des données sensibles exfiltrées et publiées publiquement); lancer une enquête

Les organisations doivent également établir un processus d'escalade pour les instances lorsque l'équipe ne répondre à un incident dans le délai imparti. Cela peut se produire pour de nombreuses raisons: par exemple, la cellule les téléphones peuvent tomber en panne ou des personnes peuvent avoir des urgences personnelles. Le processus d'escalade doit indiquer combien de temps une personne doit attendre une réponse et que faire si aucune réponse ne se produit. Généralement, la première étape consiste à dupliquer le contact initial. Après avoir attendu un bref instant, peut-être 15 minutes, l'appelant doit faire remonter l'incident à un niveau supérieur, tel que le responsable de l'équipe d'intervention en cas d'incident. Si cette personne ne répondre dans un certain laps de temps, puis l'incident doit être à nouveau escaladé à un niveau supérieur de la gestion. Ce processus doit être répété jusqu'à ce que quelqu'un réponde. 3.2.7 Notification d'incident Lorsqu'un incident est analysé et hiérarchisé, l'équipe d'intervention en cas d'incident doit notifier le les individus afin que tous ceux qui doivent être impliqués jouent leur rôle. Les politiques de réponse aux incidents doivent

33

Piste 43 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

inclure des dispositions concernant les rapports d'incident - au minimum, ce qui doit être signalé à qui et à à quelles heures (par exemple, notification initiale, mises à jour régulières de l'état). Les exigences exactes en matière de rapports varient selon les organisations, mais les parties qui sont généralement notifiées incluent: ∎ CIO ∎ Responsable de la sécurité de l'information ∎ Responsable local de la sécurité des informations ∎ Autres équipes de réponse aux incidents au sein de l'organisation ∎ Équipes externes d'intervention en cas d'incident (le cas échéant) ∎ Propriétaire du système ∎ Ressources humaines (pour les cas impliquant des employés, comme le harcèlement par e-mail)

https://translate.googleusercontent.com/translate_f

33/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Affaires publiques (pour les incidents susceptibles de générer de la publicité) ∎ Service juridique (pour les incidents ayant des ramifications juridiques potentielles) ∎ US-CERT (requis pour les agences et systèmes fédéraux exploités pour le compte du gouvernement fédéral; voir section 2.3.4.3) ∎ Application de la loi (le cas échéant) Lors de la gestion des incidents, l'équipe peut avoir besoin de fournir des mises à jour de statut à certaines parties, même dans certaines cas toute l'organisation. L'équipe doit planifier et préparer plusieurs méthodes de communication, y compris les méthodes hors bande (p. ex., en personne, sur papier), et sélectionnez les méthodes appropriées pour un incident particulier. Les méthodes de communication possibles comprennent: ∎ Courriel ∎ Site Web (interne, externe ou portail) ∎ Appels téléphoniques ∎ En personne (p. Ex., Séances d'information quotidiennes) ∎ Message d'accueil de la boîte vocale (par exemple, configurer une boîte vocale distincte pour les mises à jour des incidents, et mettre à jour le message d'accueil pour refléter l'état actuel de l'incident; utiliser le message d'accueil de la messagerie vocale du service d'assistance) ∎ Papier (p. Ex., Afficher des avis sur les tableaux d'affichage et les portes, distribuer des avis à tous les points d'entrée).

34

Piste 44 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

3.3 Confinement, éradication et récupération

Figure 3-3. Cycle de vie de la réponse aux incidents (confinement, éradication et récupération)

3.3.1 Choix d'une stratégie de confinement Le confinement est important avant qu'un incident ne submerge les ressources ou n'augmente les dégâts. La plupart des incidents nécessitent un confinement, c'est donc une considération importante au début du traitement de chaque incident. Le confinement donne du temps pour développer une stratégie d'assainissement personnalisée. Une partie essentielle de le confinement est la prise de décision (par exemple, arrêter un système, le déconnecter d'un réseau, désactiver certains les fonctions). De telles décisions sont beaucoup plus faciles à prendre s'il existe des stratégies et des procédures prédéterminées pour contenir l'incident. Les organisations doivent définir les risques acceptables dans la gestion des incidents et élaborer des stratégies en conséquence. Les stratégies de confinement varient en fonction du type d'incident. Par exemple, la stratégie pour contenir un L'infection par des logiciels malveillants transmis par e-mail est très différente de celle d'une attaque DDoS basée sur le réseau. Organisations

https://translate.googleusercontent.com/translate_f

34/62

21/10/2020

Guide de gestion des incidents de sécurité informatique devrait créer des stratégies de confinement distinctes pour chaque type d'incident majeur, avec des critères documentés clairement pour faciliter la prise de décision. Les critères pour déterminer la stratégie appropriée comprennent: ∎ Dommages potentiels et vol de ressources ∎ Nécessité de préserver les preuves ∎ Disponibilité des services (par exemple, connectivité réseau, services fournis à des parties externes) ∎ Temps et ressources nécessaires pour mettre en œuvre la stratégie ∎ Efficacité de la stratégie (p. Ex. Confinement partiel, confinement complet) ∎ Durée de la solution (par exemple, solution de contournement d'urgence à supprimer dans quatre heures, solution de contournement à supprimer dans deux semaines, solution permanente). Dans certains cas, certaines organisations redirigent l'attaquant vers un sandbox (une forme de confinement) afin que ils peuvent surveiller l'activité de l'attaquant, généralement pour recueillir des preuves supplémentaires. L'équipe de réponse aux incidents devrait discuter de cette stratégie avec son service juridique pour déterminer si elle est faisable. Moyens de surveiller un

35

Piste 45 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

L'activité de l'attaquant autre que le sandbox ne doit pas être utilisée; si une organisation sait qu'un système a été compromis et permet au compromis de continuer, il peut être tenu responsable si l'attaquant utilise le système compromis pour attaquer d'autres systèmes. La stratégie de confinement retardé est dangereuse car un l'attaquant pourrait escalader un accès non autorisé ou compromettre d'autres systèmes. Un autre problème potentiel concernant le confinement est que certaines attaques peuvent causer des dommages supplémentaires lorsque ils sont contenus. Par exemple, un hôte compromis peut exécuter un processus malveillant qui envoie un ping à un autre hôte périodiquement. Lorsque le gestionnaire d'incident tente de contenir l'incident en déconnectant le hôte compromis du réseau, les pings suivants échoueront. À la suite de l'échec, le processus malveillant peut écraser ou crypter toutes les données sur le disque dur de l'hôte. Les gestionnaires ne doivent pas supposons que juste parce qu'un hôte a été déconnecté du réseau, d'autres dommages à l'hôte été empêché. 3.3.2 Collecte et traitement des preuves Bien que la principale raison de recueillir des preuves lors d'un incident soit de résoudre l'incident, cela peut également nécessaire pour les procédures judiciaires. 42 Dans de tels cas, il est important de documenter clairement comment tous les preuves, y compris les systèmes compromis, ont été préservées. 43 Les preuves doivent être collectées selon aux procédures qui respectent toutes les lois et réglementations applicables élaborées à partir de discussions avec le personnel juridique et les organismes d'application de la loi appropriés afin que toute preuve puisse être recevable en justice. 44 En outre, les preuves doivent être comptabilisés en tout temps; chaque fois que la preuve est transférés de personne à personne, les formulaires de chaîne de traçabilité doivent détailler le transfert et inclure chaque signature du parti. Un journal détaillé doit être conservé pour toutes les preuves, y compris les éléments suivants: ∎ Informations d'identification (par exemple, l'emplacement, le numéro de série, le numéro de modèle, le nom d'hôte, l'accès au support adresses de contrôle (MAC) et adresses IP d'un ordinateur) ∎ Nom, titre et numéro de téléphone de chaque personne qui a recueilli ou manipulé les preuves pendant enquête ∎ Heure et date (y compris le fuseau horaire) de chaque occurrence de traitement des preuves ∎ Lieux où les preuves ont été stockées. La collecte de preuves à partir de ressources informatiques présente certains défis. Il est généralement souhaitable de acquérir des preuves d'un système d'intérêt dès que l'on soupçonne qu'un incident peut s'être produit. De nombreux incidents provoquent une chaîne dynamique d'événements; un instantané initial du système peut faire plus de bien identifier le problème et sa source que la plupart des autres mesures qui peuvent être prises à ce stade. D'un du point de vue de la preuve, il est préférable d'obtenir un instantané du système tel quel plutôt que de le faire après les gestionnaires d'incidents, les administrateurs système et autres ont modifié par inadvertance l'état de la machine pendant l’enquête. Les utilisateurs et les administrateurs système doivent être informés des étapes qu'ils devrait prendre pour préserver les preuves. Voir NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response , pour plus d'informations sur la conservation des preuves.

42

43

44

NIST SP 800-86, Guide to Integrating Forensic Techniques in Incident Response, fournit des informations détaillées sur établir une capacité médico-légale. Il se concentre sur les techniques médico-légales pour les PC, mais une grande partie du matériel est applicable à d'autres systèmes. Le document peut être trouvé à http://csrc.nist.gov/publications/PubsSPs.html#800-86 . La collecte et la gestion des preuves ne sont généralement pas effectuées pour chaque incident qui se produit, par exemple, la plupart des logiciels malveillants les incidents ne méritent pas l'acquisition de preuves. Dans de nombreuses organisations, la criminalistique numérique n'est pas nécessaire pour la plupart des incidents. Recherche et saisie d'ordinateurs et obtention de preuves électroniques dans les enquêtes criminelles , à partir de la criminalité informatique et la Section de la propriété intellectuelle (CCIPS) du ministère de la Justice, fournit des conseils juridiques sur la collecte de preuves. le Le document est disponible à http://www.cybercrime.gov/ssmanual/index.html .

https://translate.googleusercontent.com/translate_f

35/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 36

Piste 46 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

3.3.3 Identification des hôtes attaquants Lors de la gestion des incidents, les propriétaires du système et d'autres personnes souhaitent ou doivent parfois identifier l'attaquant hôte ou hôtes. Bien que ces informations puissent être importantes, les gestionnaires d'incidents doivent généralement rester concentrés sur le confinement, l'éradication et la récupération. L'identification d'un hôte attaquant peut prendre du temps et processus futile qui peut empêcher une équipe d'atteindre son objectif principal: minimiser l'impact commercial. Les éléments suivants décrivent les activités les plus couramment exécutées pour attaquer l'identification de l'hôte: ∎ Validation de l'adresse IP de l'hôte attaquant. Les nouveaux gestionnaires d'incidents se concentrent souvent sur l'attaque l'adresse IP de l'hôte. Le gestionnaire peut tenter de valider que l'adresse n'a pas été usurpée en vérifiant connectivité à celui-ci; cependant, cela indique simplement qu'un hôte à cette adresse répond ou ne répond pas aux demandes. Un échec de réponse ne signifie pas que l'adresse n'est pas réelle - par exemple, un hôte peut être configuré pour ignorer les pings et les traceroutes. De plus, l'attaquant peut avoir reçu une adresse qui a déjà été réaffectée à quelqu'un d'autre. ∎ Recherche de l'hôte attaquant via les moteurs de recherche. Effectuer une recherche Internet à l'aide du l'adresse IP source apparente d'une attaque peut conduire à plus d'informations sur l'attaque, par exemple, une message de liste de diffusion concernant une attaque similaire. ∎ Utilisation des bases de données d'incidents. Plusieurs groupes collectent et consolident les données d'incidents de divers organisations dans des bases de données d'incidents. Ce partage d'informations peut prendre de nombreuses formes, telles que comme trackers et listes noires en temps réel. L'organisation peut également vérifier sa propre base de connaissances ou problème système de suivi des activités connexes. ∎ Surveillance des canaux de communication possibles des attaquants. Les gestionnaires d'incidents peuvent surveiller canaux de communication pouvant être utilisés par un hôte attaquant. Par exemple, de nombreux robots utilisent IRC comme leurs principaux moyens de communication. De plus, les attaquants peuvent se rassembler sur certains canaux IRC pour se vanter de leurs compromis et partager des informations. Cependant, les gestionnaires d'incidents doivent traiter ces informations qu’ils acquièrent uniquement en tant que piste potentielle et non en tant que fait. 3.3.4 Éradication et rétablissement Une fois qu'un incident a été maîtrisé, l'éradication peut être nécessaire pour éliminer les composants du incident, comme la suppression de logiciels malveillants et la désactivation des comptes d'utilisateurs violés, ainsi que l'identification et atténuer toutes les vulnérabilités qui ont été exploitées. Pendant l'éradication, il est important d'identifier tous les hébergés au sein de l'organisation afin qu'ils puissent être corrigés. Pour certains incidents, l'éradication n'est pas non plus nécessaire ou est effectuée pendant la récupération. Lors de la récupération, les administrateurs restaurent les systèmes à un fonctionnement normal, confirment que les systèmes fonctionnent normalement, et (le cas échéant) corrigez les vulnérabilités pour éviter des incidents similaires. La récupération peut impliquer des actions telles que la restauration de systèmes à partir de sauvegardes propres, la reconstruction de systèmes à partir de zéro, le remplacement fichiers compromis avec des versions propres, installation de correctifs, modification des mots de passe et renforcement du réseau sécurité du périmètre (par exemple, ensembles de règles de pare-feu, listes de contrôle d'accès des routeurs de limite). Niveaux de système plus élevés la journalisation ou la surveillance du réseau font souvent partie du processus de récupération. Une fois qu'une ressource est réussie attaqué, il est souvent attaqué à nouveau, ou d'autres ressources au sein de l'organisation sont attaquées dans un manière. L'éradication et la récupération doivent être effectuées selon une approche par étapes afin que les étapes de remédiation soient hiérarchisées. Pour les incidents à grande échelle, le rétablissement peut prendre des mois; l'intention des premières phases devrait être d'augmenter la sécurité globale avec des changements relativement rapides (jours à semaines) de grande valeur pour éviter de futurs incidents. Les phases ultérieures devraient se concentrer sur les changements à plus long terme (p. Ex., Les changements d'infrastructure) et les travaux en cours pour garder l'entreprise aussi sécurisée que possible.

37

Piste 47 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Étant donné que les actions d'éradication et de récupération sont généralement spécifiques au système d'exploitation ou à l'application, les recommandations et conseils les concernant n'entrent pas dans le cadre de ce document. 3.4 Activité post-incident

https://translate.googleusercontent.com/translate_f

36/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Figure 3-4. Cycle de vie de la réponse aux incidents (activité post-incident)

3.4.1 Leçons apprises L'une des parties les plus importantes de la réponse aux incidents est également la plus souvent omise: l'apprentissage et amélioration. Chaque équipe d'intervention en cas d'incident doit évoluer pour refléter les nouvelles menaces, l'amélioration de la technologie et leçons apprises. Tenir une réunion sur les «leçons apprises» avec toutes les parties concernées après un incident majeur, et éventuellement périodiquement après des incidents moins importants, dans la mesure où les ressources le permettent, peut être extrêmement utile pour améliorer les mesures de sécurité et le processus de traitement des incidents lui-même. Plusieurs incidents peuvent être couverts en un seul réunion sur les leçons apprises. Cette réunion offre la possibilité de clôturer un incident en examiner ce qui s'est passé, ce qui a été fait pour intervenir et dans quelle mesure l'intervention a fonctionné. La réunion doit avoir lieu dans les quelques jours suivant la fin de l’incident. Questions auxquelles il faut répondre lors de la réunion comprendre: ∎ Que s'est-il passé exactement et à quelle heure? ∎ Dans quelle mesure le personnel et la direction ont-ils réussi à gérer l'incident? Étaient-ils documentés procédures suivies? Étaient-ils adéquats? ∎ Quelles informations étaient nécessaires plus tôt? ∎ Des mesures ou actions ont-elles été prises qui auraient pu empêcher la récupération? ∎ Que feraient le personnel et la direction différemment la prochaine fois qu'un incident similaire se produirait? ∎ Comment le partage d'informations avec d'autres organisations aurait-il pu être amélioré? ∎ Quelles actions correctives peuvent empêcher des incidents similaires à l'avenir? ∎ Quels précurseurs ou indicateurs faut-il surveiller à l'avenir pour détecter des incidents similaires?

38

Piste 48 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Quels outils ou ressources supplémentaires sont nécessaires pour détecter, analyser et atténuer les futurs incidents? Les petits incidents nécessitent une analyse post-incident limitée, à l'exception des incidents de nouvelles méthodes d’attaque qui suscitent l’intérêt et la préoccupation de tous. Après de graves attaques, il est Cela vaut généralement la peine de tenir des réunions post-mortem qui traversent les frontières de l'équipe et de l'organisation pour fournir un mécanisme de partage d'informations. La principale considération lors de la tenue de telles réunions est s'assurer que les bonnes personnes sont impliquées. Non seulement il est important d'inviter des personnes qui ont été impliqué dans l'incident analysé, mais il est également judicieux de déterminer qui devrait être invité pour objectif de faciliter la coopération future. Le succès de ces réunions dépend également de l'ordre du jour. Recueillir des commentaires sur les attentes et les besoins (y compris les sujets suggérés à couvrir) des participants avant la réunion augmente la probabilité les besoins des participants seront satisfaits. De plus, l'établissement de règles de commande avant ou pendant le début d'un une réunion peut minimiser la confusion et la discorde. Avoir un ou plusieurs modérateurs qualifiés en groupe la facilitation peut être très rentable. Enfin, il est également important de documenter les principaux points de accord et mesures à prendre et de les communiquer aux parties qui n’ont pas pu assister à la réunion. Les réunions sur les leçons apprises offrent d'autres avantages. Les rapports de ces réunions sont un bon matériel pour former les nouveaux membres de l'équipe en leur montrant comment les membres plus expérimentés de l'équipe réagissent aux incidents. La mise à jour des politiques et procédures de réponse aux incidents est un autre élément important des leçons apprises processus. L'analyse post-mortem de la façon dont un incident a été traité révèle souvent une étape manquante ou une inexactitude dans une procédure, donnant une impulsion au changement. En raison de la nature changeante des informations la technologie et les changements de personnel, l'équipe d'intervention en cas d'incident doit examiner toute la documentation connexe et les procédures de traitement des incidents à des intervalles déterminés. Une autre activité post-incident importante consiste à créer un rapport de suivi pour chaque incident, qui peut être

https://translate.googleusercontent.com/translate_f

37/62

21/10/2020

Guide de gestion des incidents de sécurité informatique très précieux pour une utilisation future. Le rapport fournit une référence qui peut être utilisée pour aider à gérer des incidents. Création d'une chronologie formelle des événements (y compris des informations horodatées telles que les données de journal des systèmes) est importante pour des raisons juridiques, tout comme la création d'une estimation monétaire du montant des dommages l'incident causé. Cette estimation peut devenir la base des poursuites ultérieures des entités comme le bureau du procureur général des États-Unis. Les rapports de suivi doivent être conservés pendant un certain temps spécifié dans les politiques de conservation des enregistrements. 45 3.4.2 Utilisation des données d'incident collectées Les activités tirées des leçons doivent produire un ensemble de données objectives et subjectives concernant chaque incident. Au fil du temps, les données d'incident collectées devraient être utiles à plusieurs titres. Les données, en particulier les le nombre total d'heures d'implication et le coût peuvent être utilisés pour justifier un financement supplémentaire de l'intervention en cas d'incident équipe. Une étude des caractéristiques des incidents peut également indiquer des faiblesses et des menaces de sécurité systémiques comme changements dans les tendances des incidents. Ces données peuvent être réintroduites dans le processus d'évaluation des risques, conduisant à la sélection et à la mise en œuvre de contrôles supplémentaires. Une autre bonne utilisation des données est mesurer le succès de l'équipe d'intervention en cas d'incident. Si les données d'incident sont collectées et stockées correctement, elles devrait fournir plusieurs mesures du succès (ou du moins des activités) de l'équipe d'intervention en cas d'incident. Les données d'incident peuvent également être collectées pour déterminer si une modification des capacités de réponse aux incidents entraîne un changement correspondant dans la performance de l'équipe (par exemple, amélioration de l'efficacité, réduction des coûts). En outre, les organisations qui sont tenues de signaler des informations sur les incidents devront collecter les

45

General Records Schedule (GRS) 24, Information Technology Operations and Management Records , précise que «Les enregistrements relatifs au traitement, à la notification et au suivi des incidents de sécurité informatique» doivent être détruits «3 ans après tout les actions de suivi sont terminées. » GRS 24 est disponible auprès de la National Archives and Records Administration à http://www.archives.gov/records-mgmt/grs/grs24.html .

39

Piste 49 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

données nécessaires pour répondre à leurs besoins. Voir la section 4 pour plus d'informations sur le partage d'incident données avec d’autres organisations. Les organisations devraient se concentrer sur la collecte de données exploitables, plutôt que sur la simple collecte de données car il est disponible. Par exemple, compter le nombre d'analyses de ports précurseurs qui se produisent chaque semaine et produire un graphique à la fin de l'année qui montre que les scans de ports ont augmenté de huit pour cent n'est pas très utile et peut prendre beaucoup de temps. Les nombres absolus ne sont pas informatifs - comprendre comment ce qui compte, c'est qu'ils représentent des menaces pour les processus métier de l'organisation. Les organisations devraient décider des données d'incident à collecter en fonction des exigences en matière de rapports et du rendement attendu investissement à partir des données (p. ex., identifier une nouvelle menace et atténuer les vulnérabilités associées avant ils peuvent être exploités.) Les mesures possibles pour les données relatives aux incidents comprennent: ∎ Nombre d'incidents traités. 46 Gérer plus d'incidents n'est pas nécessairement mieux - par exemple, le nombre d'incidents traités peut diminuer grâce à de meilleurs contrôles de sécurité du réseau et de l'hôte, pas à cause de la négligence de l'équipe d'intervention en cas d'incident. Le nombre d'incidents traités est le meilleur pris comme mesure de la quantité relative de travail que l'équipe d'intervention en cas d'incident a dû effectuer, et non comme mesure de la qualité de l'équipe, sauf si elle est considérée dans le contexte d'autres mesures donnent collectivement une indication de la qualité du travail. Il est plus efficace de produire un incident séparé compte pour chaque catégorie d'incident. Les sous-catégories peuvent également être utilisées pour fournir plus d'informations. Pour Par exemple, un nombre croissant d'incidents commis par des initiés pourrait inciter à renforcer la politique dispositions concernant les enquêtes sur les antécédents du personnel et l'utilisation abusive des ressources informatiques et des contrôles de sécurité plus stricts sur les réseaux internes (p. ex., déployer un logiciel de détection d'intrusion pour plus de réseaux internes et d'hôtes). ∎ Temps par incident. Pour chaque incident, le temps peut être mesuré de plusieurs manières:

- Quantité totale de travail consacrée à l'incident - Temps écoulé depuis le début de l'incident jusqu'à la découverte de l'incident, jusqu'à l'impact initial évaluation et à chaque étape du processus de gestion des incidents (p. ex. confinement, récupération)

- Combien de temps a mis l'équipe d'intervention en cas d'incident pour répondre au rapport initial de l'incident - Combien de temps a-t-il fallu pour signaler l'incident à la direction et, si nécessaire, à l'externe approprié entités (par exemple, US-CERT). ∎ Évaluation objective de chaque incident. La réponse à un incident qui a été résolu peut être analysé pour déterminer son efficacité. Voici des exemples de réalisation d'un objectif évaluation d'un incident:

- Examiner les journaux, formulaires, rapports et autres documents d'incident pour vérifier le respect des politiques et procédures de réponse aux incidents

- Identifier quels précurseurs et indicateurs de l'incident ont été enregistrés pour déterminer comment effectivement l'incident a été enregistré et identifié

https://translate.googleusercontent.com/translate_f

38/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

- Déterminer si l'incident a causé des dommages avant qu'il ne soit détecté 46

Les mesures telles que le nombre d'incidents traités ne sont généralement pas utiles dans une comparaison de plusieurs organisations car chaque organisation est susceptible d'avoir défini les termes clés différemment. Par exemple, la plupart des organisations définissent «incident» en termes de leurs propres politiques et pratiques, et ce qu'une organisation considère qu'un seul incident peut être considéré incidents multiples par d'autres. Des mesures plus spécifiques, telles que le nombre de scans de ports, sont également de peu de valeur comparaisons organisationnelles. Par exemple, il est hautement improbable que différents systèmes de sécurité, tels qu'une intrusion réseau les capteurs de détection, utiliseraient tous les mêmes critères dans l'activité d'étiquetage qu'une analyse de port.

40

Piste 50 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

- déterminer si la cause réelle de l'incident a été identifiée et identifier le vecteur d'attaque, les vulnérabilités exploitées et les caractéristiques des systèmes ciblés ou victimisés, réseaux et applications

- Déterminer si l'incident est une récurrence d'un incident antérieur - Calcul des dommages monétaires estimés de l'incident (p. Ex., Informations et processus métier affectés négativement par l'incident)

- Mesurer la différence entre l'analyse d'impact initiale et l'analyse d'impact finale (voir section 3.2.6)

- Identifier quelles mesures, le cas échéant, auraient pu empêcher l'incident. ∎ Évaluation subjective de chaque incident. Les membres de l'équipe d'intervention en cas d'incident peuvent être invités à évaluer leur propre performance, ainsi que celle des autres membres de l'équipe et de toute l'équipe. Un autre précieuse source d'entrée est le propriétaire d'une ressource qui a été attaquée, afin de déterminer si le le propriétaire pense que l'incident a été géré efficacement et si le résultat a été satisfaisant. En plus d'utiliser ces mesures pour mesurer le succès de l'équipe, les organisations peuvent également trouver utile de vérifier périodiquement leurs programmes de réponse aux incidents. Les audits identifieront les problèmes et les lacunes peut alors être corrigé. Au minimum, un audit de réponse aux incidents doit évaluer les éléments suivants contre les réglementations, politiques et pratiques généralement acceptées applicables: ∎ Politiques, plans et procédures de réponse aux incidents ∎ Outils et ressources ∎ Modèle et structure de l'équipe ∎ Formation et éducation des gestionnaires d'incidents ∎ Documentation et rapports d'incident ∎ Les mesures du succès évoquées plus haut dans cette section. 3.4.3 Conservation des preuves Les organisations devraient établir une politique sur la durée de conservation des preuves d'un incident. Plus les organisations choisissent de conserver toutes les preuves pendant des mois ou des années après la fin de l'incident. Le suivant les facteurs doivent être pris en compte lors de l'élaboration de la politique: ∎ Poursuites. S'il est possible que l'attaquant soit poursuivi, des preuves devront peut-être être conservées jusqu'à ce que toutes les actions en justice soient terminées. Dans certains cas, cela peut prendre plusieurs années. En outre, des preuves qui semblent insignifiantes maintenant pourraient devenir plus importantes à l'avenir. Par exemple, si un l'attaquant est capable d'utiliser les connaissances recueillies lors d'une attaque pour effectuer une attaque plus sévère plus tard, les preuves de la première attaque peuvent être essentielles pour expliquer comment la deuxième attaque a été accomplie. ∎ Conservation des données. La plupart des organisations ont des politiques de conservation des données qui indiquent pendant combien de temps certains types de les données peuvent être conservées. Par exemple, une organisation peut déclarer que les messages électroniques doivent être conservés pendant seulement 180 jours. Si une image disque contient des milliers d'e-mails, l'organisation peut ne pas vouloir l'image à conserver plus de 180 jours sauf en cas de nécessité absolue. Comme indiqué dans la section 3.4.2, Le calendrier général des enregistrements (GRS) 24 spécifie que les enregistrements de traitement des incidents doivent être conservés trois ans.

41

Piste 51 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

https://translate.googleusercontent.com/translate_f

39/62

21/10/2020

Guide de gestion des incidents de sécurité informatique ∎ Coût. Matériel d'origine (par exemple, disques durs, systèmes compromis) qui est également stocké comme preuve en tant que disques durs et supports amovibles utilisés pour contenir des images de disque, sont généralement peu coûteux. Cependant, si une organisation stocke de nombreux composants de ce type pendant des années, le coût peut être substantiel. L'organisation doit également conserver des ordinateurs fonctionnels pouvant utiliser le matériel stocké et les médias. 3.5 Liste de contrôle pour la gestion des incidents La liste de contrôle du tableau 3-5 présente les principales étapes à suivre pour gérer un incident. Remarque que les étapes réelles effectuées peuvent varier en fonction du type d'incident et de la nature de l'individu incidents. Par exemple, si le gestionnaire sait exactement ce qui s'est passé sur la base de l'analyse des indicateurs (Étape 1.1), il peut être inutile d'effectuer les étapes 1.2 ou 1.3 pour approfondir la recherche sur l'activité. La liste de contrôle fournit des directives aux manutentionnaires sur les principales étapes à exécuter; il ne dicte pas l'exact séquence d'étapes qui doivent toujours être suivies. Tableau 3-5. Liste de contrôle pour la gestion des incidents action

Terminé

Détection et analyse 1.

Déterminer si un incident s'est produit 1.1

Analyser les précurseurs et les indicateurs

1.2

Rechercher des informations corrélées

1,3

Effectuer des recherches (p. Ex., Moteurs de recherche, base de connaissances)

1,4

Dès que le gestionnaire pense qu'un incident s'est produit, commencez à documenter l'enquête et la collecte de preuves

2.

Prioriser la gestion de l'incident en fonction des facteurs pertinents (impact fonctionnel, informations impact, effort de récupérabilité, etc.)

3.

Signaler l'incident au personnel interne approprié et aux organisations externes

4.

Acquérir, conserver, sécuriser et documenter des preuves

5.

Contenir l'incident

Confinement, éradication et récupération

6.

Éradiquer l'incident 6.1

Identifiez et atténuez toutes les vulnérabilités qui ont été exploitées

6.2

Supprimez les logiciels malveillants, les contenus inappropriés et d'autres composants

6.3

Si plus d'hôtes affectés sont découverts (par exemple, de nouvelles infections de logiciels malveillants), répétez les étapes de détection et d'analyse (1.1, 1.2) pour identifier tous les autres hôtes affectés, puis contenir (5) et éradiquer (6) l'incident pour eux

7.

Récupérer de l'incident 7,1

Remettre les systèmes concernés dans un état opérationnel

7,2

Confirmez que les systèmes concernés fonctionnent normalement

7,3

Si nécessaire, mettez en œuvre une surveillance supplémentaire pour rechercher les activités futures liées Activité post-incident

8.

Créer un rapport de suivi

9.

Tenir une réunion sur les leçons apprises (obligatoire pour les incidents majeurs, facultative dans le cas contraire)

3.6 Recommandations Les principales recommandations présentées dans cette section pour la gestion des incidents sont résumées ci-dessous.

42

Piste 52 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Acquérir des outils et des ressources qui peuvent être utiles lors de la gestion des incidents. L'équipe sera plus efficace pour gérer les incidents si divers outils et ressources sont déjà à leur disposition. Les exemples incluent les listes de contacts, les logiciels de cryptage, les diagrammes de réseau, les périphériques de sauvegarde, les logiciels médico-légaux et listes de ports. ∎ Empêchez les incidents de se produire en vous assurant que les réseaux, les systèmes et les applications suffisamment sûr. La prévention des incidents est bénéfique pour l'organisation et réduit également les charge de travail de l'équipe d'intervention en cas d'incident. Effectuer des évaluations périodiques des risques et réduire les risques identifiés à un niveau acceptable sont efficaces pour réduire le nombre d'incidents. Conscience de les politiques et procédures de sécurité des utilisateurs, du personnel informatique et de la direction sont également très importantes. ∎ Identifier les précurseurs et les indicateurs grâce aux alertes générées par plusieurs types de sécurité Logiciel. Systèmes de détection et de prévention des intrusions, logiciels antivirus et vérification de l'intégrité des fichiers les logiciels sont précieux pour détecter les signes d'incidents. Chaque type de logiciel peut détecter des incidents qui les autres types de logiciels ne le peuvent pas, donc l'utilisation de plusieurs types de logiciels de sécurité informatique est fortement conseillé. Les services de surveillance tiers peuvent également être utiles. ∎ Mettre en place des mécanismes permettant aux tiers de signaler les incidents. Des tiers peuvent souhaiter signaler

https://translate.googleusercontent.com/translate_f

40/62

21/10/2020

Guide de gestion des incidents de sécurité informatique incidents à l'organisation - par exemple, ils peuvent croire que l'un des utilisateurs de l'organisation est les attaquer. Les organisations doivent publier un numéro de téléphone et une adresse e-mail que des tiers peut utiliser pour signaler de tels incidents. ∎ Exiger un niveau de base de journalisation et d'audit sur tous les systèmes, et un niveau de référence plus élevé sur tous systèmes critiques. Les journaux des systèmes d'exploitation, des services et des applications fournissent souvent de la valeur pendant l'analyse des incidents, en particulier si l'audit a été activé. Les journaux peuvent fournir des informations telles comme quels comptes ont été accédés et quelles actions ont été effectuées. ∎ Profil des réseaux et des systèmes. Le profilage mesure les caractéristiques des niveaux d'activité attendus afin que les changements de modèles peuvent être plus facilement identifiés. Si le processus de profilage est automatisé, les écarts des niveaux d'activité attendus peuvent être détectés et signalés aux administrateurs rapidement, ce qui accélère détection d'incidents et de problèmes opérationnels. ∎ Comprendre les comportements normaux des réseaux, des systèmes et des applications. Les membres de l'équipe qui comprendre un comportement normal devrait être capable de reconnaître plus facilement un comportement anormal. Cette La meilleure façon d’acquérir des connaissances consiste à examiner les entrées de journal et les alertes de sécurité; les gestionnaires devraient se familiariser avec les données typiques et étudier les entrées inhabituelles pour acquérir plus de connaissances. ∎ Créez une stratégie de rétention des journaux. Les informations concernant un incident peuvent être enregistrées à plusieurs endroits. Création et mise en œuvre d'une stratégie de conservation des journaux qui spécifie la durée des données de journal maintenue peut être extrêmement utile dans l'analyse, car les anciennes entrées de journal peuvent afficher une reconnaissance activité ou des instances précédentes d'attaques similaires. ∎ Effectuer une corrélation d'événements. Les preuves d'un incident peuvent être enregistrées dans plusieurs journaux. Corréler les événements entre plusieurs sources peuvent être inestimables dans la collecte de toutes les informations disponibles pour un l'incident et valider si l'incident s'est produit. ∎ Gardez toutes les horloges de l'hôte synchronisées. Si les appareils signalant des événements ont des paramètres d'horloge incohérents, la corrélation des événements sera plus compliquée. Les écarts d'horloge peuvent également causer des problèmes point de vue de la preuve. ∎ Maintenir et utiliser une base de connaissances d'informations. Les gestionnaires doivent référencer des informations rapidement lors de l'analyse des incidents; une base de connaissances centralisée fournit une solution cohérente et maintenable source d'information. La base de connaissances doit inclure des informations générales, telles que des données sur précurseurs et indicateurs d'incidents antérieurs.

43

Piste 53 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Commencez à enregistrer toutes les informations dès que l'équipe soupçonne qu'un incident s'est produit. Chaque mesure prise, depuis le moment où l'incident a été détecté jusqu'à sa résolution finale, doit être documenté et horodaté. Les informations de cette nature peuvent servir de preuve devant un tribunal si des poursuites judiciaires sont engagées. L'enregistrement des étapes effectuées peut également conduire à une traitement systématique et moins sujet aux erreurs du problème. ∎ Protégez les données d'incident. Il contient souvent des informations sensibles sur des éléments tels que vulnérabilités, failles de sécurité et utilisateurs susceptibles d'avoir effectué des actions inappropriées. L'équipe devrait garantir que l'accès aux données sur les incidents est correctement restreint, à la fois logiquement et physiquement. ∎ Donner la priorité au traitement des incidents en fonction des facteurs pertinents. En raison des limitations de ressources, les incidents ne doivent pas être traités sur la base du premier arrivé, premier servi. Au lieu de cela, les organisations devraient établir des lignes directrices écrites décrivant la rapidité avec laquelle l'équipe doit réagir à l'incident et ce des actions doivent être effectuées, sur la base de facteurs pertinents tels que l'impact fonctionnel et informationnel de l'incident, et la possibilité de récupérer de l'incident. Cela permet de gagner du temps pour l'incident gestionnaires et fournit une justification à la direction et aux propriétaires de systèmes pour leurs actions. Les organisations doivent également établir un processus d'escalade pour les instances lorsque l'équipe ne répondre à un incident dans le délai imparti. ∎ Inclure des dispositions concernant le signalement des incidents dans la politique de réponse aux incidents de l'organisation. Les organisations doivent spécifier quels incidents doivent être signalés, quand ils doivent être signalés et qui. Les parties les plus communément notifiées sont le CIO, responsable de la sécurité de l'information, local responsable de la sécurité de l'information, autres équipes d'intervention en cas d'incident au sein de l'organisation et système les propriétaires. ∎ Établir des stratégies et des procédures pour contenir les incidents. Il est important de contenir les incidents rapidement et efficacement pour limiter leur impact commercial. Les organisations doivent définir les risques acceptables contenir les incidents et élaborer des stratégies et des procédures en conséquence. Stratégies de confinement devrait varier en fonction du type d'incident. ∎ Suivez les procédures établies pour la collecte et le traitement des preuves. L'équipe doit clairement documentez comment toutes les preuves ont été conservées. Les preuves doivent être prises en compte à tout moment. le l'équipe devrait rencontrer le personnel juridique et les organismes d'application de la loi pour discuter du traitement des preuves, puis élaborer des procédures basées sur ces discussions. ∎ Capturez les données volatiles des systèmes comme preuves. Cela inclut des listes de connexions réseau, processus, sessions de connexion, fichiers ouverts, configurations d'interface réseau et contenu de la mémoire.

https://translate.googleusercontent.com/translate_f

41/62

21/10/2020

Guide de gestion des incidents de sécurité informatique L'exécution de commandes soigneusement choisies à partir de supports de confiance peut collecter les informations nécessaires sans endommager les preuves du système. ∎ Obtenez des instantanés système via des images de disque d'analyse complète, et non des sauvegardes du système de fichiers. Images de disque doit être conçu sur un support purifié, protégé en écriture ou à écriture unique. Ce processus est supérieur à un fichier sauvegarde du système à des fins d'enquête et de preuve. L'imagerie est également précieuse en ce qu'elle est plus sûr d'analyser une image que d'effectuer une analyse sur le système d'origine car l'analyse peut altérer l'original par inadvertance. ∎ Tenir des réunions sur les leçons apprises après des incidents majeurs. Les réunions de leçons apprises sont extrêmement utile pour améliorer les mesures de sécurité et le processus de gestion des incidents lui-même.

44

Piste 54 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

4. Coordination et partage d'informations La nature des menaces et des attaques contemporaines rend plus important que jamais pour les organisations travailler ensemble pendant la réponse aux incidents. Les organisations doivent veiller à coordonner efficacement parties de leurs activités de réponse aux incidents avec les partenaires appropriés. L'aspect le plus important de La coordination de la réponse aux incidents est le partage d'informations, où différentes organisations partagent des menaces, des attaques, et les informations de vulnérabilité entre eux afin que les connaissances de chaque organisation profitent à l'autre. Le partage d'informations sur les incidents est souvent mutuellement bénéfique car les mêmes menaces et attaques affectent plusieurs organisations simultanément. Comme mentionné dans la section 2, la coordination et le partage d'informations avec les organisations partenaires peuvent renforcer la capacité de l'organisation à répondre efficacement aux incidents informatiques. Par exemple, si une organisation identifie certains comportements sur son réseau qui semblent suspects et envoie des informations sur l'événement à un ensemble de partenaires de confiance, quelqu'un d'autre dans ce réseau peut avoir déjà vu un comportement similaire et être en mesure pour répondre avec des détails supplémentaires sur l'activité suspecte, y compris des signatures, d'autres indicateurs rechercher ou suggérer des actions de correction. La collaboration avec le partenaire de confiance peut permettre organisation pour répondre à l'incident plus rapidement et plus efficacement qu'une organisation opérant dans isolement. Cette augmentation de l'efficacité des techniques standard de réponse aux incidents n'est pas la seule incitation à coordination de l'organisation et partage d'informations. Une autre incitation au partage d'informations est la capacité à répondre aux incidents en utilisant des techniques qui peuvent ne pas être disponibles pour une seule organisation, surtout si cette organisation est de petite à moyenne taille. Par exemple, une petite organisation qui identifie un une instance particulièrement complexe de malware sur son réseau peut ne pas disposer des ressources internes nécessaires pour analyser le malware et déterminer son effet sur le système. Dans ce cas, l'organisation peut être en mesure de tirer parti d'un réseau de partage d'informations de confiance pour externaliser efficacement l'analyse de ce malware vers des ressources tierces dotées des capacités techniques adéquates pour effectuer l'analyse des logiciels malveillants. Cette section du document met l'accent sur la coordination et le partage d'informations. La section 4.1 présente un aperçu de la coordination de la réponse aux incidents et met l'accent sur la nécessité d'une coordination interorganisationnelle pour compléter les processus de réponse aux incidents de l'organisation. La section 4.2 traite des techniques d'information le partage entre les organisations et la section 4.3 examine comment restreindre les informations partagées ou non partagé avec d’autres organisations. 4.1 Coordination Comme indiqué dans la section 2.3.4, une organisation peut avoir besoin d'interagir avec plusieurs types de organisations dans le cadre des activités de réponse aux incidents. Exemples de ces organisations inclure d'autres équipes d'intervention en cas d'incident, des organismes d'application de la loi, des fournisseurs de services Internet et mandants et clients. L'équipe d'intervention en cas d'incident d'une organisation doit planifier son incident coordination avec ces parties avant que les incidents ne se produisent pour s'assurer que toutes les parties connaissent leurs rôles et que des voies de communication efficaces sont établies . La figure 4-1 fournit un exemple de vue dans une organisation effectuer la coordination à chaque phase du cycle de vie de la réponse aux incidents, en mettant en évidence cette coordination est précieux tout au long du cycle de vie.

https://translate.googleusercontent.com/translate_f

42/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 45

Piste 55 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Figure 4-1. Coordination de la réponse aux incidents

4.1.1 Relations de coordination Une équipe d'intervention en cas d'incident au sein d'une organisation peut participer à différents types de coordination selon le type d’organisme avec lequel il se coordonne. Par exemple, l'équipe les membres responsables des détails techniques de l'intervention en cas d'incident peuvent coordonner collègues des organisations partenaires pour partager des stratégies pour atténuer une attaque couvrant plusieurs organisations. Alternativement, au cours du même incident, le responsable de l'équipe de réponse aux incidents peut coordonner avec les ISAC pour satisfaire les exigences de rapport nécessaires et demander des conseils et des ressources pour répondre avec succès à l'incident . Le tableau 4-1 donne quelques exemples de coordination relations qui peuvent exister lors de la collaboration avec des organisations extérieures.

46

Piste 56 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Tableau 4-1. Relations de coordination Catégorie Équipe à équipe

Définition Des relations d'équipe à équipe existent à chaque fois répondeurs aux incidents techniques dans différents les organisations collaborent avec leurs pairs pendant n'importe quelle phase de la vie de gestion des incidents cycle. Les organisations participant à cette type de relation sont généralement des pairs sans

https://translate.googleusercontent.com/translate_f

Informations partagées Les informations les plus fréquemment partagées dans Team-toles relations d'équipe sont tactiques et techniques (p. ex. indicateurs techniques de compromis, suggérés mesures correctives) mais peut également inclure d'autres types d'informations (plans, procédures, leçons appris) si elle est menée dans le cadre de la préparation phase.

43/62

21/10/2020

Guide de gestion des incidents de sécurité informatique toute autorité les uns sur lesmettre autresenetcommun choisissent partager des informations, desde ressources et réutiliser connaissances pour résoudre des problèmes communs aux deux équipes. Équipe à coordonner équipe

Des relations d'équipe à équipe de coordination existent entre une réponse à un incident organisationnel équipe et une organisation distincte qui agit comme un point central pour un incident coordonné réponse et gestion comme les États-Unis CERT ou ISAC. Ce type de relation peut inclure un certain degré de requis rapports des organisations membres par l'organe de coordination, ainsi que le l'attente que l'équipe de coordination diffuser des informations opportunes et utiles pour organisations membres participantes.

Les équipes et les équipes de coordination partagent fréquemment informations tactiques et techniques ainsi que des informations concernant les menaces, les vulnérabilités et les risques communauté servie par l'équipe de coordination. le l'équipe de coordination peut également avoir besoin d'un impact spécifique des informations sur les incidents afin d'aider à décisions sur où concentrer ses ressources et attention.

Coordonner équipe à coordonner équipe

Relations entre plusieurs coordinations des équipes telles que l'US-CERT et les ISAC existent de partager des informations relatives aux incidents pouvant affecter plusieurs communautés. Les équipes de coordination agissent sur au nom de leur membre respectif de la communauté organisations à partager des informations sur nature et étendue des incidents transversaux et des stratégies d'atténuation réutilisables pour aider à réponse intercommunautaire.

Le type d'informations partagées par la coordination les équipes avec leurs homologues se composent souvent de résumés périodiques pendant «l'état d'équilibre» des opérations, rythmées par l'échange de tactiques, détails techniques, plans d'intervention et impact ou risque informations d'évaluation lors d'un incident coordonné activités de réponse.

Les organisations peuvent trouver difficile d'établir les relations nécessaires à la coordination. Bons endroits pour commencer à bâtir une communauté inclure le secteur industriel auquel l'organisation appartient et le secteur géographique région où l'organisation opère. L'équipe d'intervention en cas d'incident d'une organisation peut essayer de former relations avec d'autres équipes (au niveau d'équipe à équipe) au sein de son propre secteur industriel et de sa propre région, ou rejoindre des organismes établis du secteur industriel qui facilitent déjà le partage d'informations. Un autre la considération pour l'établissement de relations est que certaines relations sont obligatoires et d'autres volontaires; pour exemple, les relations d'équipe à équipe de coordination sont souvent obligatoires, tandis que les relations d'équipe à équipe sont généralement volontaires. Les organisations entretiennent des relations volontaires parce qu'elles s'épanouissent mutuellement intérêts. Les relations obligatoires sont généralement définies par un organisme de réglementation de l'industrie ou par une autre entité. 4.1.2 Ententes de partage et exigences de rapport Les organisations qui tentent de partager des informations avec des organisations externes devraient consulter leurs département avant de lancer des efforts de coordination. Il peut y avoir des contrats ou d'autres accords doivent être mis en place avant les discussions. Un exemple est un accord de non-divulgation (NDA) pour protéger la confidentialité des informations les plus sensibles de l'organisation. Les organisations devraient également prendre en compte toutes les exigences existantes en matière de signalement, telles que le partage d'informations sur les incidents avec un ISAC ou signaler les incidents à un CIRT de niveau supérieur.

47

Psaumes 57 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

4.2 Techniques de partage d'informations Le partage d'informations est un élément clé pour permettre la coordination entre les organisations. Même le plus petit les organisations doivent pouvoir partager des informations sur les incidents avec leurs pairs et partenaires afin de de nombreux incidents efficacement. Les organisations devraient effectuer ce partage d'informations tout au long cycle de vie de la réponse à un incident et n'attendez pas qu'un incident soit entièrement résolu avant de partager les détails avec les autres. La section 4.3 traite des types d'informations sur les incidents que les organisations peuvent ou non veulent partager avec les autres. Cette section se concentre sur les techniques de partage d'informations. La section 4.2.1 examine les méthodes ad hoc, tandis que La section 4.2.2 examine les méthodes partiellement automatisées. Enfin, la section 4.2.3 traite de la sécurité considérations liées au partage d'informations. 4.2.1 Ad Hoc La plupart des échanges d'informations sur les incidents se font traditionnellement par des méthodes ad hoc, telles que le courrier électronique, clients de messagerie instantanée et téléphone. Les mécanismes de partage d'informations ad hoc reposent normalement sur un les relations de chaque employé avec les employés des équipes d'intervention en cas d'incident des organisations partenaires. L'employé utilise ces connexions pour partager manuellement des informations avec ses pairs et se coordonner avec eux pour élaborer des stratégies de réponse à un incident. Selon la taille de l'organisation, ces annonces les techniques ad hoc peuvent être le moyen le plus rentable de partager des informations avec les organisations partenaires. Cependant, en raison de la nature informelle du partage d'informations ad hoc, il n'est pas possible de garantir que le les processus de partage d'informations fonctionneront toujours. Par exemple, si une connexion particulièrement l'employé démissionne d'une équipe d'intervention en cas d'incident, cette équipe peut temporairement perdre la majorité des les canaux de partage d'informations sur lesquels il s'appuie pour assurer une coordination efficace avec les organisations extérieures.

https://translate.googleusercontent.com/translate_f

44/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Les méthodes de partage d'informations ad hoc sont également largement non standardisées en termes d'informations communiquée et comment cette communication se produit. En raison du manque de standardisation, ils ont tendance à nécessitent une intervention manuelle et nécessitent plus de ressources à traiter que l'alternative, en partie méthodes automatisées. Dans la mesure du possible, une organisation doit tenter de formaliser ses informations partager des stratégies par le biais d'accords formels avec des organisations partenaires et des mécanismes techniques aidera à automatiser partiellement le partage d'informations. 4.2.2 Partiellement automatisé Les organisations doivent essayer d'automatiser autant que possible le processus de partage d'informations pour coordination interorganisationnelle efficace et rentable. En réalité, il ne sera pas possible de automatiser le partage de toutes les informations sur les incidents, ce ne sera pas non plus souhaitable pour des raisons de sécurité et de confiance considérations. Les organisations devraient essayer de parvenir à un équilibre entre le partage automatisé d'informations superposé à des processus centrés sur l'humain pour gérer le flux d'informations. Lorsqu'elles conçoivent des solutions automatisées de partage d'informations, les organisations doivent d'abord types d'informations qu'ils communiqueront avec les partenaires. L'organisation peut vouloir construire un dictionnaire de données formel énumérant toutes les entités et relations entre entités qu'elles souhaiteront partager. Une fois que l'organisation comprend les types d'informations qu'elle partagera, il est nécessaire de construire des modèles formels, traitables par machine pour capturer ces informations. Dans la mesure du possible, un l'organisation devrait utiliser les normes d'échange de données existantes pour représenter les informations dont elle a besoin

48

Psaumes 58 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

partager. 47 L'organisation doit travailler avec ses organisations partenaires lorsqu'elle décide de l'échange de données des modèles pour s'assurer que les normes sélectionnées sont compatibles avec l'incident de l'organisation partenaire systèmes de réponse. Lors de la sélection des modèles d'échange de données existants, les organisations peuvent préférer plusieurs modèles qui modélisent différents aspects du domaine de la réponse aux incidents, puis les exploitent modèles de manière modulaire, en ne communiquant que les informations nécessaires à un point de décision spécifique le cycle de vie. L'annexe E fournit une liste non exhaustive des normes existantes définissant l'échange de données modèles applicables au domaine de la réponse aux incidents. En plus de sélectionner les modèles d'échange de données pour partager les informations sur les incidents, une organisation doit travaille également avec ses organisations partenaires pour convenir des mécanismes techniques de transport permettant de l'échange d'informations doit avoir lieu de manière automatisée. Ces mécanismes de transport comprennent, à un minimum, le protocole de transport pour l'échange des informations, le modèle architectural pour communiquer avec une ressource d'information et les ports et noms de domaine applicables pour accéder à un ressource d'information dans une organisation particulière. Par exemple, un groupe d'organisations partenaires peut Décider d'échanger des informations sur les incidents en utilisant une architecture REST (Representational State Transfer) pour échanger des données IODEF / Real-Time Inter-Network Defense (RID) via Hypertext Transfer Protocol Secure (HTTPS) sur le port 4590 d'un nom de domaine spécifique dans la DMZ de chaque organisation. 4.2.3 Considérations de sécurité Les équipes d'intervention en cas d'incident doivent tenir compte de plusieurs considérations de sécurité lors de la planification leur partage d'informations. L'un est de pouvoir désigner qui peut voir quels éléments de l'incident informations (par exemple, protection des informations sensibles). Il peut également être nécessaire d'effectuer des données désinfection ou nettoyage pour supprimer les données sensibles des informations d'incident sans perturber les informations sur les précurseurs, les indicateurs et autres informations techniques. Voir la section 4.3 pour plus d'informations sur le partage d'informations granulaires. L'équipe d'intervention en cas d'incident doit également s'assurer que les mesures nécessaires sont prises pour protéger les informations partagées avec l'équipe par d'autres organisations. Il existe également de nombreuses questions juridiques à considérer concernant le partage de données. Voir la section 4.1.2 pour plus information. 4.3 Partage d'informations granulaires Les organisations doivent équilibrer les avantages du partage d'informations avec les inconvénients du partage informations, idéalement en partageant les informations nécessaires et uniquement les informations nécessaires avec le parties appropriées. Les organisations peuvent considérer leurs informations d'incident comme étant de deux types d'informations: impact commercial et technique. Les informations sur l'impact commercial sont souvent partagées dans le contexte d'une relation d'équipe à équipe de coordination telle que définie à la section 4.1.1, tandis que les informations techniques sont souvent partagées dans les trois types de relations de coordination. Cette section traite des deux types de informations et fournit des recommandations pour effectuer un partage d'informations granulaires. 4.3.1 Informations d'impact sur l'activité Les informations sur l'impact sur les activités concernent la manière dont l'incident affecte l'organisation en termes de mission

https://translate.googleusercontent.com/translate_f

45/62

21/10/2020

Guide de gestion des incidents de sécurité informatique impact, impact etc. Ces informations, au moinspour à un communiquer niveau de synthèse, sont souvent à des coordination desfinancier, équipes d'intervention en cas d'incident une estimation des communiquées dommages causés par incident. Les équipes d'intervention de coordination peuvent avoir besoin de ces informations d'impact pour prendre des décisions concernant

47

Selon la National Technology Transfer and Advancement Act (NTTAA), «tous les organismes et départements fédéraux doit utiliser des normes techniques élaborées ou adoptées par des organismes de normalisation par consensus volontaire ». Voir http://standards.gov/nttaa.cfm pour plus de détails.

49

Piste 59 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

degré d'assistance à fournir à l'organisation déclarante. Une équipe de coordination peut également utiliser cette des informations permettant de prendre des décisions sur la manière dont un incident spécifique affectera d'autres organisations communauté qu’ils représentent. Les équipes de coordination peuvent exiger des organisations membres qu'elles rendent compte d'un certain degré d'impact commercial information. Par exemple, une équipe de coordination peut demander à une organisation membre de signaler l'impact informations utilisant les catégories définies à la section 3 .2.6. Dans ce cas, pour un incident hypothétique un l'organisation signale qu'elle a un impact fonctionnel sur le support , un impact sur l'information nul , et nécessitera un temps de récupération prolongé . Ces informations de haut niveau alerteraient l'équipe de coordination que l'organisation membre a besoin d'un certain niveau de ressources supplémentaires pour se remettre de l'incident. L'équipe de coordination pourrait alors poursuivre une communication supplémentaire avec l'organisation membre pour déterminer le nombre de ressources nécessaires ainsi que le type de ressources en fonction des informations fournies sur l'incident. Les informations sur l’impact commercial ne sont utiles que pour les rapports aux organisations qui assurer la mission de l'organisation victime de l'incident. Dans de nombreux cas, la réponse aux incidents les équipes doivent éviter de partager des informations sur l'impact commercial avec des organisations extérieures à moins qu'il n'y ait une proposition de valeur ou exigences de rapport formel. Lors du partage d'informations avec des pairs et des partenaires organisations, les équipes d'intervention en cas d'incident doivent se concentrer sur l'échange d'informations techniques comme indiqué dans Section 4.3.2 . 4.3.2 Informations techniques Il existe de nombreux types différents d'indicateurs techniques indiquant la survenue d'un incident dans un organisation. Ces indicateurs proviennent de la variété des informations techniques associées à incidents, tels que les noms d'hôte et les adresses IP des hôtes attaquants, des échantillons de logiciels malveillants, des précurseurs et les indicateurs d'incidents similaires et les types de vulnérabilités exploitées lors d'un incident. Section 3.2. 2 fournit un aperçu de la façon dont les organisations devraient collecter et utiliser ces indicateurs pour aider à identifier un incident qui est en cours. En outre, la section 3.2. 3 fournit une liste des sources courantes d'indicateur d'incident Les données. Si les organisations gagnent en valeur en collectant leurs propres indicateurs internes, elles peuvent valeur de l'analyse des indicateurs reçus des organisations partenaires et du partage d'indicateurs internes analyse externe et utilisation. Si l'organisation reçoit des données d'indicateur externe relatives à un incident, elle n'ont pas vu, ils peuvent utiliser ces données d'indicateur pour identifier l'incident au moment où il commence à se produire. De même, un l'organisation peut utiliser des données d'indicateurs externes pour détecter un incident en cours dont elle n'était pas au courant en raison le manque de ressources internes pour saisir les données spécifiques des indicateurs. Les organisations peuvent également bénéficier de partager leurs données d'indicateurs internes avec des organisations externes. Par exemple, s'ils partagent des informations relatives à un incident auquel elles sont confrontées, une organisation partenaire peut répondre par un une stratégie de correction suggérée pour gérer cet incident. Les organisations devraient partager autant de ces informations que possible; cependant, il peut y avoir à la fois sécurité et les raisons de responsabilité pour lesquelles une organisation ne voudrait pas révéler les détails d'un exploit vulnérabilité. Indicateurs externes, tels que les caractéristiques générales des attaques et l'identité des attaquant les hôtes, peuvent généralement être partagés en toute sécurité avec d’autres. Les organisations devraient considérer quels types de les informations techniques devraient ou ne devraient pas être partagées avec différentes parties, puis s'efforcer de une grande partie des informations appropriées que possible avec d’autres organisations. Les données des indicateurs techniques sont utiles lorsqu'elles permettent à une organisation d'identifier un incident réel. cependant, les données sur les indicateurs reçues de sources externes ne se rapporteront pas toutes à l'organisation qui les reçoit. Dans certaines

50

Piste 60 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

https://translate.googleusercontent.com/translate_f

46/62

21/10/2020

Guide de gestion des incidents de sécurité informatique cas, ces données externes généreront des faux positifs au sein du réseau de l'organisation destinataire et peuvent faire dépenser des ressources sur des problèmes inexistants. Les organisations participant au partage d'informations sur les incidents doivent disposer d'un personnel qualifié des informations sur les indicateurs provenant du partage des communautés et de la diffusion de ces informations entreprise, de préférence de manière automatisée. Les organisations devraient également essayer de s'assurer qu'elles partagent un indicateur pour lequel ils ont un niveau de confiance relativement élevé qu'il signifie un incident. 4.4 Recommandations Les principales recommandations présentées dans cette section pour la gestion des incidents sont résumées ci-dessous. ∎ Planifier la coordination des incidents avec les parties externes avant que les incidents ne se produisent. Exemples de les parties comprennent d'autres équipes d'intervention en cas d'incident, des organismes d'application de la loi, des fournisseurs de services Internet, et les mandants et les clients. Cette planification permet de s'assurer que toutes les parties connaissent leurs rôles et que des voies de communication efficaces sont établies. ∎ Consultez le service juridique avant d'entamer des efforts de coordination. Il peut y avoir contrats ou autres accords qui doivent être mis en place avant les discussions. ∎ Effectuer le partage d'informations sur les incidents tout au long du cycle de vie de la réponse aux incidents. Information le partage est un élément clé pour permettre la coordination entre les organisations. Les organisations ne devraient pas attendre jusqu'à ce qu'un incident soit entièrement résolu avant d'en partager les détails avec d'autres. ∎ Tenter d'automatiser autant que possible le processus de partage d'informations. Cela rend crosscoordination organisationnelle efficace et rentable. Les organisations devraient tenter de parvenir à un équilibre entre le partage automatisé d'informations et des processus centrés sur l'humain pour gérer flux d'information. ∎ Équilibrez les avantages du partage d'informations avec les inconvénients du partage information. Idéalement, les organisations devraient partager les informations nécessaires et uniquement les informations avec les parties concernées. Les informations sur l'impact commercial sont souvent partagées en équipe coordonner les relations d'équipe, tandis que les informations techniques sont souvent partagées dans tous les types relations de coordination. Lors du partage d'informations avec des organisations homologues et partenaires, incident les équipes d'intervention devraient se concentrer sur l'échange d'informations techniques. ∎ Partagez autant que possible les informations d'incident appropriées avec d'autres organisations. Les organisations devraient réfléchir aux types d'informations techniques qui devraient ou ne devraient pas être partagées avec diverses parties. Par exemple, des indicateurs externes, tels que les caractéristiques générales des attaques et l'identité des hôtes attaquants, sont généralement sûrs à partager avec d'autres, mais il peut y avoir les deux raisons de sécurité et de responsabilité pour lesquelles une organisation ne voudrait pas révéler les détails d'un exploit vulnérabilité.

51

Piste 61 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe A - Scénarios de gestion des incidents Les scénarios de gestion des incidents constituent un moyen peu coûteux et efficace de développer des compétences de réponse aux incidents et identifier les problèmes potentiels liés aux processus de réponse aux incidents. L'équipe ou les membres de l'équipe d'intervention en cas d'incident sont présentés avec un scénario et une liste de questions connexes. L'équipe discute ensuite de chaque question et détermine la réponse la plus probable. Le but est de déterminer ce que l'équipe ferait réellement et de comparer cela avec les politiques, procédures et pratiques généralement recommandées pour identifier les écarts ou carences. Par exemple, la réponse à une question peut indiquer que la réponse serait retardée parce que l'équipe n'a pas de logiciel ou parce qu'une autre équipe ne fournit pas d'assistance en dehors des heures de bureau. Les questions énumérées ci-dessous s'appliquent à presque tous les scénarios. Chaque question est suivie d'une référence à la (aux) section (s) connexe (s) du document. Après les questions se trouvent des scénarios, chacun étant suivi par questions supplémentaires spécifiques à un incident. Les organisations sont fortement encouragées à adapter ces questions et scénarios à utiliser dans leurs propres exercices de réponse aux incidents. 48 A.1 Questions de scénario Préparation:

https://translate.googleusercontent.com/translate_f

47/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 1. L'organisation considérerait-elle cette activité comme un incident? Dans l'affirmative, laquelle des organisations politiques que cette activité enfreint-elle? (Section 2.1) 2. Quelles mesures sont en place pour tenter d'empêcher ce type d'incident de se produire ou pour limiter son impact? (Section 3.1.2) Détection et analyse: 1. Quels précurseurs de l'incident, le cas échéant, l'organisation pourrait-elle détecter? Est-ce que des précurseurs amener l'organisation à prendre des mesures avant que l'incident ne se produise? (Sections 3.2.2, 3.2.3) 2. Quels indicateurs de l'incident l'organisation pourrait-elle détecter? Quels indicateurs provoqueraient quelqu'un pour penser qu'un incident a pu se produire? (Sections 3.2.2, 3.2.3) 3. Quels outils supplémentaires pourraient être nécessaires pour détecter cet incident particulier? (Section 3.2.3) 4. Comment l'équipe d'intervention en cas d'incident analyserait-elle et validerait-elle cet incident? Quel personnel être impliqué dans le processus d'analyse et de validation? (Section 3.2.4) 5. À quelles personnes et groupes au sein de l'organisation l'équipe rapporterait-elle l'incident? (Section 3.2.7) 6. Comment l'équipe prioriserait-elle le traitement de cet incident? (Section 3.2.6) Confinement, éradication et récupération: 1. Quelle stratégie l'organisation devrait-elle adopter pour contenir l'incident? Pourquoi cette stratégie est-elle préférable aux autres? (Section 3.3.1) 2. Que pourrait-il se passer si l'incident n'était pas maîtrisé? (Section 3.3.1) 3. Quels outils supplémentaires pourraient être nécessaires pour répondre à cet incident particulier? (Sections 3.3.1, 3.3.4) 4. Quel personnel serait impliqué dans les processus de confinement, d'éradication et / ou de récupération? (Sections 3.3.1, 3.3.4)

48

Pour plus d'informations sur les exercices, voir NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities , disponible sur http://csrc.nist.gov/publications/PubsSPs.html#800-84 .

52

Piste 62 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

5. Quelles sources de preuves, le cas échéant, l'organisation devrait-elle acquérir? Comment serait la preuve acquis? Où serait-il stocké? Combien de temps doit-il être conservé? (Sections 3.2.5, 3.3.2, 3.4.3) Activité post-incident: 1. Qui participerait à la réunion sur les leçons apprises concernant cet incident? (Section 3.4.1) 2. Que pourrait-on faire pour éviter que des incidents similaires ne se reproduisent à l'avenir? (Section 3.1.2) 3. Que pourrait-on faire pour améliorer la détection d'incidents similaires? (Section 3.1.2) Questions générales: 1. Combien de membres de l'équipe d'intervention en cas d'incident participeraient à la gestion de cet incident? (Section 2.4.3) 2. Outre l'équipe d'intervention en cas d'incident, quels groupes au sein de l'organisation seraient impliqués gérer cet incident? (Section 2.4.4) 3. À quelles parties externes l'équipe rapporterait-elle l'incident? Quand chaque rapport aurait-il lieu? Comment chaque rapport serait-il rédigé? Quelles informations rapporteriez-vous ou non, et pourquoi? (Section 2.3.2) 4. Quelles autres communications avec des parties externes peuvent avoir lieu? (Section 2.3.2) 5. Quels outils et ressources l'équipe utiliserait-elle pour gérer cet incident? (Section 3.1.1) 6. Quels aspects du traitement auraient été différents si l'incident s'était produit à un jour et heure (on-hours versus off-hours)? (Section 2.4.2) 7. Quels aspects du traitement auraient été différents si l'incident s'était produit à un emplacement physique (sur site ou hors site)? (Section 2.4.2) A.2 Scénarios Scénario 1: Déni de service (DoS) du serveur DNS (Domain Name System) Un samedi après-midi, les utilisateurs externes commencent à avoir des problèmes pour accéder au public de l'organisation sites Internet. Au cours de l'heure suivante, le problème s'aggrave au point où presque toutes les tentatives d'accès échouent. Pendant ce temps, un membre du personnel de réseau de l'organisation répond aux alertes d'une frontière Internet routeur et détermine que la bande passante Internet de l'organisation est consommée par un volume de paquets UDP (User Datagram Protocol) vers et depuis le DNS public de l'organisation les serveurs. L'analyse du trafic montre que les serveurs DNS reçoivent des volumes élevés de requêtes d'un

https://translate.googleusercontent.com/translate_f

48/62

21/10/2020

Guide de gestion des incidents de sécurité informatique adresse IP externe unique. De plus, toutes les requêtes DNS de cette adresse proviennent du même port source. Voici des questions supplémentaires pour ce scénario: 1. À qui l'organisation doit-elle s'adresser concernant l'adresse IP externe en question? 2. Supposons qu'après la mise en place des mesures de confinement initiales, les administrateurs réseau a détecté que neuf hôtes internes tentaient également les mêmes requêtes inhabituelles au DNS serveur. Comment cela affecterait-il la gestion de cet incident? 3. Supposons que deux des neuf hôtes internes déconnectés du réseau avant leur système les propriétaires ont été identifiés. Comment les propriétaires du système seraient-ils identifiés? Scénario 2: Infestation par un ver et un agent de déni de service distribué (DDoS) Un mardi matin, un nouveau ver est libéré; il se propage à travers un support amovible, et il peut se copier pour ouvrir les partages Windows. Lorsque le ver infecte un hôte, il installe un agent DDoS. le

53

Piste 63 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

l'organisation a déjà subi des infections généralisées avant que les signatures antivirus ne soient disponibles plusieurs heures après que le ver a commencé à se propager. Voici des questions supplémentaires pour ce scénario: 1. Comment l'équipe d'intervention en cas d'incident identifierait-elle tous les hôtes infectés? 2. Comment l'organisation tenterait-elle d'empêcher le ver d'entrer dans l'organisation avant des signatures antivirus ont été publiées? 3. Comment l'organisation tenterait-elle d'empêcher la propagation du ver par des hôtes infectés? avant la publication des signatures antivirus? 4. L'organisation tenterait-elle de corriger toutes les machines vulnérables? Si oui, comment cela se ferait-il? 5. Comment la gestion de cet incident changerait-elle si les hôtes infectés ayant reçu le DDoS l'agent avait été configuré pour attaquer le site Web d'une autre organisation le lendemain matin? 6. Comment la gestion de cet incident changerait-elle si un ou plusieurs des hôtes infectés contenaient des informations personnelles sensibles concernant les employés de l'organisation? 7. Comment l'équipe d'intervention en cas d'incident tiendrait-elle les utilisateurs de l'organisation informés de l'état de L'incident? 8. Quelles mesures supplémentaires l'équipe effectuerait-elle pour les hôtes qui ne sont pas actuellement connectés le réseau (p. ex., membres du personnel en vacances, employés hors site qui se connectent occasionnellement)? Scénario 3: documents volés Un lundi matin, le service juridique de l'organisation reçoit un appel du Bureau fédéral de Enquête (FBI) concernant une activité suspecte impliquant les systèmes de l'organisation. Plus tard que jour, un agent du FBI rencontre des membres de la direction et du service juridique pour discuter de l'activité. Le FBI a enquêté sur des activités impliquant l'affichage public de documents gouvernementaux sensibles, et certains des documents appartiendraient à l'organisation. L'agent demande les l'assistance et la direction demande l'aide de l'équipe d'intervention en cas d'incident pour acquérir les des preuves pour déterminer si ces documents sont légitimes ou non et comment ils ont pu être divulgués. Voici des questions supplémentaires pour ce scénario: 1. De quelles sources l'équipe d'intervention en cas d'incident pourrait-elle recueillir des preuves? 2. Que ferait l'équipe pour garder l'enquête confidentielle? 3. Comment le traitement de cet incident changerait-il si l'équipe identifiait un hôte interne responsable? pour les fuites? 4. Comment la gestion de cet incident changerait-elle si l'équipe trouvait un rootkit installé sur le hôte interne responsable des fuites? Scénario 4: serveur de base de données compromis Un mardi soir, un administrateur de base de données effectue une maintenance en dehors des heures d'ouverture sur plusieurs serveurs de base de données. L'administrateur remarque des noms de répertoires inconnus et inhabituels sur l'un des les serveurs. Après avoir examiné les listes de répertoires et consulté certains des fichiers, l'administrateur conclut que le serveur a été attaqué et appelle l'équipe d'intervention en cas d'incident pour obtenir de l'aide. Les équipes l'enquête détermine que l'attaquant a réussi à obtenir un accès root au serveur il y a six semaines. Voici des questions supplémentaires pour ce scénario: 1. Quelles sources l'équipe pourrait-elle utiliser pour déterminer quand le compromis s'est produit?

54

https://translate.googleusercontent.com/translate_f

49/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Piste 64 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

2. Comment la gestion de cet incident changerait-elle si l'équipe découvrait que le serveur de base de données exécuté un renifleur de paquets et capturé les mots de passe du réseau? 3. Comment la gestion de cet incident changerait-elle si l'équipe découvrait que le serveur exécutait un processus qui copierait une base de données contenant des informations client sensibles (y compris informations personnellement identifiables) chaque nuit et les transférer à une adresse externe? 4. Comment la gestion de cet incident changerait-elle si l'équipe découvrait un rootkit sur le serveur? Scénario 5: Exfiltration inconnue Un dimanche soir, l'un des capteurs de détection d'intrusion réseau de l'organisation alerte en cas d'anomalie activité réseau sortante impliquant des transferts de fichiers volumineux. L'analyste d'intrusion examine les alertes; il semble que des milliers de fichiers .RAR sont copiés d'un hôte interne vers un hôte externe, et le l'hôte externe est situé dans un autre pays. L'analyste contacte l'équipe d'intervention en cas d'incident afin qu'elle puisse enquêter davantage sur l'activité. L'équipe ne peut pas voir ce que contiennent les fichiers .RAR car leur contenu sont cryptés. L'analyse de l'hôte interne contenant les fichiers .RAR montre des signes d'une installation de bot. Voici des questions supplémentaires pour ce scénario: 1. Comment l'équipe déterminerait-elle ce qui était le plus probable dans les fichiers .RAR? Quelles autres équipes pourrait aider l'équipe d'intervention en cas d'incident? 2. Si l'équipe d'intervention en cas d'incident a déterminé que le compromis initial avait été une carte réseau sans fil dans l'hôte interne, comment l'équipe enquêterait-elle davantage sur cette activité? 3. Si l'équipe d'intervention en cas d'incident a déterminé que l'hôte interne était utilisé pour la mise en scène fichiers provenant d'autres hôtes au sein de l'entreprise, comment l'équipe étudierait-elle plus avant cette activité? Scénario 6: Accès non autorisé aux enregistrements de paie Un mercredi soir, l'équipe de sécurité physique de l'organisation reçoit un appel d'une paie administratrice qui a vu une personne inconnue quitter son bureau, courir dans le couloir et sortir du bâtiment. L'administrateur avait laissé son poste de travail déverrouillé et sans surveillance pendant quelques minutes seulement. La paie programme est toujours connecté et dans le menu principal, comme il l'était quand elle l'a quitté, mais l'administrateur remarque que la souris semble avoir été déplacée. Il a été demandé à l'équipe d'intervention en cas d'incident d'acquérir les preuves liées à l'incident et pour déterminer quelles actions ont été effectuées. Voici des questions supplémentaires pour ce scénario: 1. Comment l'équipe déterminerait-elle quelles actions ont été effectuées? 2. En quoi le traitement de cet incident différerait-il si l'administrateur de la paie avait reconnu le personne quittant son bureau en tant qu'ancienne employée du service de la paie? 3. En quoi le traitement de cet incident différerait-il si l'équipe avait des raisons de croire que la personne était un employé actuel? 4. En quoi le traitement de cet incident différerait-il si l'équipe de sécurité physique déterminait que le personne avait utilisé des techniques d'ingénierie sociale pour accéder physiquement au bâtiment? 5. En quoi le traitement de cet incident différerait-il si les journaux de la semaine précédente indiquaient un nombre inhabituellement élevé de tentatives de connexion à distance échouées à l'aide de l'ID utilisateur de l'administrateur de la paie? 6. En quoi le traitement de cet incident différerait-il si l'équipe d'intervention en cas d'incident découvrait qu'un l'enregistreur de frappe a été installé sur l'ordinateur deux semaines plus tôt?

55

Piste 65 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Scénario 7: Disparition de l'hôte Un jeudi après-midi, un capteur de détection d'intrusion sur le réseau enregistre l'activité d'analyse des vulnérabilités dirigé vers les hôtes internes qui est généré par une adresse IP interne. Parce que la détection d'intrusion l'analyste n'est au courant d'aucune activité d'analyse de vulnérabilité autorisée et planifiée, elle signale l'activité à l'équipe d'intervention en cas d'incident. Lorsque l'équipe commence l'analyse, elle découvre que l'activité s'est arrêtée et qu'il n'y a plus d'hôte utilisant l'adresse IP. Voici des questions supplémentaires pour ce scénario: 1. Quelles sources de données peuvent contenir des informations concernant l'identité de l'analyse de vulnérabilité

https://translate.googleusercontent.com/translate_f

50/62

21/10/2020

Guide de gestion des incidents de sécurité informatique hôte? 2. Comment l'équipe identifierait-elle qui avait effectué les analyses de vulnérabilité? 3. En quoi la gestion de cet incident différerait-elle si l'analyse de vulnérabilité était dirigée vers le les hôtes les plus critiques de l'organisation? 4. En quoi la gestion de cet incident serait-elle différente si l'analyse de vulnérabilité était dirigée vers hôtes externes? 5. En quoi le traitement de cet incident différerait-il si l'adresse IP interne était associée au réseau invité sans fil de l'organisation? 6. En quoi le traitement de cet incident différerait-il si le personnel de sécurité physique découvrait que quelqu'un était entré par effraction dans l'installation une demi-heure avant le scan de vulnérabilité? Scénario 8: Compromis du télétravail Un samedi soir, le logiciel de détection d'intrusion réseau enregistre une connexion entrante provenant à partir d'une adresse IP de liste de surveillance. L'analyste de détection d'intrusion détermine que la connexion est établie au serveur VPN de l'organisation et contacte l'équipe de réponse aux incidents. L'équipe examine l'intrusion la détection, le pare-feu et le serveur VPN enregistrent et identifient l'ID utilisateur qui a été authentifié pour la session et le nom de l'utilisateur associé à l'ID utilisateur. Voici des questions supplémentaires pour ce scénario: 1. Quelle devrait être la prochaine étape de l'équipe (par exemple, appeler l'utilisateur à la maison, désactiver l'ID utilisateur, déconnecter la session VPN)? Pourquoi cette étape devrait-elle être effectuée en premier? Quelle étape devrait être effectué deuxième? 2. En quoi la gestion de cet incident serait-elle différente si l'adresse IP externe appartenait à un Procuration? 3. En quoi la gestion de cet incident différerait-elle si l'ID avait été utilisé pour lancer le VPN connexions à partir de plusieurs adresses IP externes à l'insu de l'utilisateur? 4. Supposons que l'ordinateur de l'utilisateur identifié ait été compromis par un jeu contenant un Cheval de Troie téléchargé par un membre de la famille. Comment cela affecterait-il l'équipe analyse de l'incident? Comment cela affecterait-il la collecte et le traitement des preuves? Qu'est-ce que doit l'équipe fait-elle en termes d'éradication de l'incident de l'ordinateur de l'utilisateur? 5. Supposons que l'utilisateur a installé un logiciel antivirus et a déterminé que le cheval de Troie avait inclus un enregistreur de frappe. Comment cela affecterait-il la gestion de l'incident? Comment cela affecter la gestion de l'incident si l'utilisateur était un administrateur système? Comment cela affecterait-il la gestion de l'incident si l'utilisateur était un cadre de haut rang dans l'organisation?

56

Piste 66 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Scénario 9: menace anonyme Un jeudi après-midi, l'équipe de sécurité physique de l'organisation reçoit un appel d'un responsable informatique, rapportant que deux de ses employés viennent de recevoir des menaces anonymes contre les systèmes de l'organisation. Sur la base d'une enquête, l'équipe de sécurité physique estime que les menaces doivent être prises au sérieux et informe les équipes internes appropriées, y compris l'équipe d'intervention en cas d'incident, des menaces. Voici des questions supplémentaires pour ce scénario: 1. Que devrait faire différemment l'équipe d'intervention en cas d'incident, le cas échéant, en réponse à la notification des menaces? 2. Quel impact pourrait avoir des contrôles de sécurité physique accrus sur les réponses de l'équipe aux incidents? Scénario 10: Partage de fichiers peer-to-peer L'organisation interdit l'utilisation de services de partage de fichiers peer-to-peer. Le réseau de l'organisation Les capteurs de détection d'intrusion ont des signatures activées qui peuvent détecter l'utilisation de plusieurs services de partage de fichiers par les pairs. Un lundi soir, un analyste de détection d'intrusion remarque que plusieurs fichiers des alertes de partage se sont produites au cours des trois dernières heures, toutes impliquant la même adresse IP interne. 1. Quels facteurs devraient être utilisés pour hiérarchiser le traitement de cet incident (par exemple, le contenu apparent des fichiers partagés)? 2. Quelles considérations de confidentialité peuvent avoir une incidence sur le traitement de cet incident? 3. En quoi la gestion de cet incident serait-elle différente si l'ordinateur exécutant le fichier peer-to-peer partage contient également des informations sensibles personnellement identifiables? Scénario 11: Point d'accès sans fil inconnu

https://translate.googleusercontent.com/translate_f

51/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Un lundi matin, le service d'assistance de l'organisation reçoit les appels de trois utilisateurs au même étage d'un bâtiment qui déclarent avoir des problèmes avec leur accès sans fil. Un administrateur réseau qui est invité à aider à résoudre le problème apporte un ordinateur portable avec accès sans fil à l'étage des utilisateurs. Comme il visualise sa configuration de réseau sans fil, il remarque qu'un nouveau point d'accès est répertorié comme étant disponible. Il vérifie avec ses coéquipiers et constate que ce point d'accès n'a pas été déployé par son team, de sorte qu'il s'agit probablement d'un point d'accès non autorisé qui a été établi sans autorisation. 1. Quelle devrait être la première étape majeure dans la gestion de cet incident (par exemple, trouver physiquement le point d'accès, se connectant logiquement au point d'accès)? 2. Quel est le moyen le plus rapide de localiser le point d'accès? Quelle est la manière la plus secrète de localiser point d'accès? 3. En quoi le traitement de cet incident différerait-il si le point d'accès avait été déployé par un partie externe (p. ex., entrepreneur) travaillant temporairement au bureau de l'organisation? 4. En quoi le traitement de cet incident différerait-il si un analyste de détection d'intrusion signalait des signes de activité suspecte impliquant certains postes de travail au même étage de l'immeuble? 5. En quoi la gestion de cet incident différerait-elle si le point d'accès avait été retiré alors que le l'équipe essayait toujours de le localiser physiquement?

57

Piste 67 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe B - Éléments de données relatifs aux incidents Les organisations doivent identifier un ensemble standard d'éléments de données relatifs aux incidents à collecter pour chaque incident. Cet effort facilitera non seulement une gestion des incidents plus efficace et cohérente, mais aidera également l'organisation en respectant les exigences applicables en matière de rapport d'incident. L'organisation doit désigner un ensemble d'éléments de base (p. ex. le nom, le numéro de téléphone et l'emplacement du déclarant d'incident) à recueillir lorsque l'incident est signalé et un ensemble supplémentaire d'éléments à collecter par les gestionnaires d'incident pendant leur réponse. Les deux ensembles d'éléments constitueraient la base de la base de données des rapports d'incidents, auparavant discuté dans la section 3.2.5. Les listes ci-dessous fournissent des suggestions sur les informations à collecter pour incidents et ne se veulent pas exhaustifs. Chaque organisation doit créer sa propre liste de éléments basés sur plusieurs facteurs, y compris son modèle et sa structure d'équipe d'intervention en cas d'incident définition du terme «incident». B.1 Éléments de données de base ∎ Coordonnées du rapporteur et du gestionnaire d'incidents

- Nom - Rôle - Unité organisationnelle (p. Ex. Agence, département, division, équipe) et affiliation - Adresse e-mail - Numéro de téléphone - Emplacement (par exemple, adresse postale, numéro de bureau) ∎ Détails de l'incident

- Date / horodatage du changement d'état (y compris le fuseau horaire): quand l'incident a commencé, quand le incident a été découvert / détecté, lorsque l'incident a été signalé, lorsque l'incident résolu / terminé, etc.

- Emplacement physique de l'incident (par exemple, ville, état) - État actuel de l'incident (par exemple, attaque en cours) - Source / cause de l'incident (si connue), y compris les noms d'hôte et les adresses IP - Description de l'incident (par exemple, comment il a été détecté, ce qui s'est passé) - Description des ressources affectées (par exemple, réseaux, hôtes, applications, données), y compris les systèmes noms d'hôte, adresses IP et fonction

- Si connu, catégorie d'incident, vecteurs d'attaque associés à l'incident et indicateurs associés à l'incident (modèles de trafic, clés de registre, etc.)

- Facteurs de priorisation (impact fonctionnel, impact informationnel, récupérabilité, etc.) - Facteurs atténuants (par exemple, un ordinateur portable volé contenant des données sensibles utilisait un cryptage complet du disque) - Actions de réponse effectuées (par exemple, éteindre l'hôte, l'hôte déconnecté du réseau) https://translate.googleusercontent.com/translate_f

52/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

- Autres organisations contactées (par exemple, fournisseur de logiciels) ∎ Commentaires généraux

58

Piste 68 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

B.2 Éléments de données du gestionnaire d'incidents ∎ État actuel de la réponse à l'incident ∎ Résumé de l'incident ∎ Actions de gestion des incidents

- Journal des actions entreprises par tous les gestionnaires - Coordonnées de toutes les parties impliquées - Liste des preuves recueillies ∎ Commentaires du gestionnaire d'incidents ∎ Cause de l'incident (par exemple, application mal configurée, hôte non corrigé) ∎ Coût de l'incident ∎ Impact commercial de l'incident 49

49

L'impact commercial de l'incident peut être soit une description de l'effet de l'incident (par exemple, le service comptable pour effectuer des tâches pendant deux jours) ou une catégorie d'impact basée sur le coût (par exemple, un incident «majeur» a un coût de plus de 100 000 $).

59

Piste 69 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe C - Glossaire

https://translate.googleusercontent.com/translate_f

53/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Certains termes utilisés dans la publication sont définis ci-dessous. Analyse de base: surveillance des ressources pour déterminer les modèles d'utilisation typiques afin que les écarts importants peut être détecté. Incident de sécurité informatique: voir «incident». Équipe d'intervention en cas d'incident de sécurité informatique (CSIRT): une capacité mise en place dans le but d'aider pour répondre aux incidents liés à la sécurité informatique; également appelé équipe de réponse aux incidents informatiques (CIRT) ou CIRC (Computer Incident Response Center, Computer Incident Response Capability). Événement: toute occurrence observable dans un réseau ou un système. Faux positif: une alerte qui indique à tort qu'une activité malveillante est en cours. Incident: violation ou menace imminente de violation des politiques de sécurité informatique, utilisation acceptable politiques ou pratiques de sécurité standard. Gestion des incidents: atténuation des violations des politiques de sécurité et des pratiques recommandées. Réponse aux incidents: voir «gestion des incidents». Indicateur: signe qu'un incident peut s'être produit ou se produire actuellement. Système de détection et de prévention des intrusions (IDPS) : logiciel qui automatise le processus de surveillance les événements survenant dans un système informatique ou un réseau et les analyser pour détecter des signes d'incidents possibles et tenter d'arrêter les incidents potentiels détectés. Logiciel malveillant: virus, ver, cheval de Troie ou autre entité malveillante basée sur un code qui infecte avec succès un hôte. Précurseur: signe qu'un attaquant peut se préparer à provoquer un incident. Profilage: mesurer les caractéristiques de l'activité attendue afin que les changements puissent être plus facilement identifié. Signature: un modèle reconnaissable et distinctif associé à une attaque, comme une chaîne binaire dans un virus ou un ensemble particulier de frappes utilisées pour obtenir un accès non autorisé à un système. Ingénierie sociale: tentative de tromper quelqu'un pour qu'il révèle des informations (par exemple, un mot de passe) être utilisé pour attaquer des systèmes ou des réseaux. Menace: la source potentielle d'un événement indésirable. Vulnérabilité: une faiblesse dans un système, une application ou un réseau qui fait l'objet d'une exploitation ou d'une mauvaise utilisation.

60

Piste 70 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe D - Acronymes Certains acronymes utilisés dans la publication sont définis ci-dessous. CCIPS CERIAS CERT ® / CC CIO CIRC CIRC CIRT RSSI CSIRC CSIRT DDoS DHS DNS DoS FAQ

Section de la criminalité informatique et de la propriété intellectuelle Centre d'éducation et de recherche en assurance et sécurité de l'information Centre de coordination CERT ® Directeur informatique Capacité de réponse aux incidents informatiques Centre de réponse aux incidents informatiques Équipe de réponse aux incidents informatiques Directeur de la sécurité de l'information Capacité de réponse aux incidents de sécurité informatique Équipe d'intervention en cas d'incident de sécurité informatique Déni de service distribué département de la Sécurité intérieure Système de noms de domaines Déni de service Questions fréquemment posées

https://translate.googleusercontent.com/translate_f

54/62

21/10/2020

Guide de gestion des incidents de sécurité informatique FBI FIPS PREMIER FISMA GAO GFIRST GRS HTTP IANA IDPS IETF IP IR IRC ISAC FAI IL ITL MAC MOU MSSP NAT NDA NIST NSRL NTP NVD OIG OMB OS PII ÉPINGLE

Bureau fédéral d'enquête Normes fédérales de traitement de l'information Forum des équipes de réponse aux incidents et de sécurité Loi fédérale sur la gestion de la sécurité de l'information Bureau de la responsabilité générale Forum gouvernemental des équipes d'intervention et de sécurité en cas d'incident Calendrier des archives générales Protocole de transfert hypertexte L'autorité d'assignation des numéros internet Système de détection et de prévention des intrusions Groupe de travail sur l'ingénierie Internet protocole Internet Rapport interinstitutions Chat relais Internet Centre de partage et d'analyse des informations Fournisseur de services Internet Informatique Laboratoire de technologie de l'information Contrôle d'accès au support Protocole d'entente Fournisseur de services de sécurité gérés Traduction d'adresses réseau Accord de non-divulgation Institut national des normes et de la technologie Bibliothèque nationale de référence logicielle Protocole de temps réseau Base de données nationale sur la vulnérabilité Bureau de l'inspecteur général Bureau de la gestion et du budget Système opérateur Informations personnellement identifiables Numéro d'identification personnel

61

Piste 71 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

POC Point de contact REN-ISAC Centre de partage et d'analyse de l'information sur les réseaux de recherche et d'éducation RFC Demande de commentaire DÉBARRASSER Défense inter-réseaux en temps réel SIEM Informations de sécurité et gestion des événements SLA Accord de niveau de service AMADOUER Procédure d'opération standard SP Publication spéciale TCP Protocole de contrôle de transmission TCP / IP Protocole de contrôle de transmission / protocole Internet TERENA Association transeuropéenne de mise en réseau de la recherche et de l'éducation UDP Protocole de datagramme utilisateur URL Localisateur de ressources uniformes US-CERT Équipe de préparation aux urgences informatiques des États-Unis VPN Réseau privé virtuel

https://translate.googleusercontent.com/translate_f

55/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

62

Psaumes 72 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe E - Ressources Les listes ci-dessous fournissent des exemples de ressources qui peuvent être utiles pour établir et maintenir un capacité d'intervention en cas d'incident. Organisations d'intervention en cas d'incident Organisation

URL

Groupe de travail anti-hameçonnage (APWG)

http://www.antiphishing.org/

Section de la criminalité informatique et de la propriété intellectuelle (CCIPS), États-Unis département de la Justice

http://www.cybercrime.gov/

Centre de coordination CERT ® , Université Carnegie Mellon (CERT ® / CC)

http://www.cert.org/

Agence européenne chargée de la sécurité des réseaux et de l'information (ENISA)

http://www.enisa.europa.eu/activities/cert

Forum des équipes de réponse aux incidents et de sécurité (FIRST)

http://www.first.org/

Forum gouvernemental des équipes d'intervention et de sécurité en cas d'incident (GFIRST)

http://www.us-cert.gov/federation/gfirst.html

Association des enquêtes criminelles de haute technologie (HTCIA)

http://www.htcia.org/

InfraGard

http://www.infragard.net/

Internet Storm Center (ISC)

http://isc.sans.edu/

Conseil national des ISAC

http://www.isaccouncil.org/

Équipe d'intervention d'urgence informatique des États-Unis (US-CERT)

http://www.us-cert.gov/

Publications du NIST Nom de la ressource

URL

NIST SP 800-53 Révision 3, sécurité recommandée Contrôles des systèmes d'information fédéraux et Organisations

http://csrc.nist.gov/publications/PubsSPs.html#800-53

NIST SP 800-83, Guide de prévention des incidents liés aux logiciels malveillantshttp://csrc.nist.gov/publications/PubsSPs.html#800-83 et manutention NIST SP 800-84, Guide de test, de formation et d'exercice Programmes pour les plans et capacités informatiques

http://csrc.nist.gov/publications/PubsSPs.html#800-84

NIST SP 800-86, Guide d'intégration de la criminalistique Techniques de réponse aux incidents

http://csrc.nist.gov/publications/PubsSPs.html#800-86

NIST SP 800-92, Guide du journal de sécurité informatique La gestion

http://csrc.nist.gov/publications/PubsSPs.html#800-92

NIST SP 800-94, Guide de détection d'intrusion et Systèmes de prévention (IDPS)

http://csrc.nist.gov/publications/PubsSPs.html#800-94

NIST SP 800-115, Guide technique de l'information Test et évaluation de la sécurité

http://csrc.nist.gov/publications/PubsSPs.html#800-115

NIST SP 800-128, Guide pour la sécurité Gestion de la configuration des systèmes d'information

http://csrc.nist.gov/publications/PubsSPs.html#800-128

63

https://translate.googleusercontent.com/translate_f

56/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

Piste 73 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Spécifications d'échange de données applicables à la gestion des incidents Titre

La description

Information additionnelle

IA

Identification des actifs

http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7693

ARF

Format des résultats des actifs

http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7694

CAPEC

Énumération des modèles d'attaque courants et classification

http://capec.mitre.org/

CCE

Énumération de configuration commune

http://cce.mitre.org/

CEE

Expression d'événement commune

http://cee.mitre.org/

CPE

Énumération de plate-forme commune

http://cpe.mitre.org/

CVE

Vulnérabilités et expositions courantes http://cve.mitre.org/

CVSS

Système commun de notation des vulnérabilités

http://www.first.org/cvss/cvss-guide

CWE

Énumération commune des faiblesses

http://cwe.mitre.org/

CybOX

Cyber-expression observable

http://cybox.mitre.org/

MAEC

Énumération des attributs de logiciels malveillants et Caractérisation

http://maec.mitre.org/

OCIL

Ouvrir le langage interactif de la liste de contrôle

http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7692

OVALE

Évaluation ouverte de la vulnérabilité Langue

http://oval.mitre.org/

Échange de messages de détection d'intrusion RFC 4765 Format (IDMEF)

http://www.ietf.org/rfc/rfc4765.txt

Échange de description d'objet d'incident RFC 5070 Format (IODEF)

http://www.ietf.org/rfc/rfc5070.txt

Extensions de la RFC 5901 à l'IODEF pour la création de rapports Hameçonnage

http://www.ietf.org/rfc/rfc5901.txt

RFC 5941 Partage des données de fraude sur les transactions

http://www.ietf.org/rfc/rfc5941.txt

RFC 6545 Défense inter-réseau en temps réel (RID)

http://www.ietf.org/rfc/rfc6545.txt

RFC 6546 Transport de l'inter-réseau en temps réel Messages de défense (RID) sur HTTP / TLS

http://www.ietf.org/rfc/rfc6546.txt

SCAP

Protocole d'automatisation du contenu de sécurité

http://csrc.nist.gov/publications/PubsSPs.html # SP-800126-Rév.% 202

XCCDF

Liste de contrôle de configuration extensible Description Format

http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7275-r4

64

Piste 74 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe F - Questions fréquemment posées Les utilisateurs, administrateurs système, membres du personnel de sécurité de l'information et autres personnes au sein des organisations peuvent avez des questions sur la réponse aux incidents. Voici les questions fréquemment posées (FAQ). Les organisations sont encouragées à personnaliser cette FAQ et à la mettre à la disposition de leur communauté d'utilisateurs. 1. Qu'est-ce qu'un incident? En général, un incident est une violation des politiques de sécurité informatique, des politiques d'utilisation acceptable ou pratiques de sécurité informatique standard. Des exemples d'incidents sont: ∎ Un attaquant commande à un botnet d'envoyer des volumes élevés de demandes de connexion à l'un des

https://translate.googleusercontent.com/translate_f

57/62

21/10/2020

Guide de gestion des incidents de sécurité informatique les serveurs Web de l'organisation, provoquant son plantage. ∎ Les utilisateurs sont amenés à ouvrir un «rapport trimestriel» envoyé par e-mail qui est en fait un malware; l'exécution de l'outil a infecté leurs ordinateurs et établi des connexions avec un hôte. ∎ Un auteur obtient un accès non autorisé à des données sensibles et menace de divulguer les détails à la presse si l'organisation ne paie pas une somme d'argent désignée. ∎ Un utilisateur fournit des copies illégales de logiciels à d'autres via des services de partage de fichiers d'égal à égal. 2. Qu'est-ce que la gestion des incidents? La gestion des incidents est le processus de détection et d'analyse des incidents et de limitation des effet. Par exemple, si un attaquant pénètre dans un système via Internet, la gestion des incidents processus doit détecter la faille de sécurité. Les gestionnaires d'incidents analyseront ensuite les données et déterminer la gravité de l'attaque. L'incident sera priorisé et les gestionnaires d'incident prendra des mesures pour s'assurer que la progression de l'incident est interrompue et que les systèmes concernés revenir au fonctionnement normal dès que possible. 3. Qu'est-ce que la réponse aux incidents? Les termes «gestion des incidents» et «réponse aux incidents» sont synonymes dans ce document. 50 4. Qu'est-ce qu'une équipe d'intervention en cas d'incident? Une équipe de réponse aux incidents (également appelée équipe de réponse aux incidents de sécurité informatique [CSIRT]) est chargé de fournir des services de réponse aux incidents à une partie ou à la totalité d'une organisation. L'équipe reçoit des informations sur d'éventuels incidents, les examine et prend des mesures pour s'assurer que les dommages causés par les incidents soient minimisés. 5. Quels services l'équipe d'intervention en cas d'incident fournit-elle? Les services particuliers proposés par les équipes d'intervention en cas d'incident varient considérablement d'une organisation à l'autre. Outre la gestion des incidents, la plupart des équipes assument également la responsabilité des intrusions surveillance et gestion du système de détection. Une équipe peut également diffuser des avis concernant nouvelles menaces, et informez les utilisateurs et le personnel informatique de leurs rôles dans la prévention et la gestion des incidents. 6. À qui les incidents doivent-ils être signalés? Les organisations doivent établir des points de contact clairs (POC) pour signaler les incidents en interne. Certaines organisations structureront leur capacité de réponse aux incidents afin que tous les incidents soient signalé directement à l'équipe de réponse aux incidents, tandis que d'autres utiliseront le support existant 50

Les définitions de «gestion des incidents» et de «réponse aux incidents» varient considérablement. Par exemple, CERT ® / CC utilise la «gestion des incidents» pour faire référence au processus global de détection, de rapport, d'analyse et de réponse des incidents, alors que «réponse aux incidents» fait référence spécifiquement au confinement des incidents, à la récupération et à la notification des autres. Voir http://www.cert.org/csirts/csirt_faq.html pour Plus d'information.

65

Piste 75 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

structures, telles que le service d'assistance informatique, pour un POC initial. L'organisation doit reconnaître que des parties externes, telles que d'autres équipes d'intervention en cas d'incident, signalaient certains incidents. Fédéral les agences sont tenues, en vertu de la loi, de signaler tous les incidents à l'ordinateur des États-Unis Équipe de préparation aux situations d'urgence (US-CERT). Toutes les organisations sont encouragées à signaler les incidents à leurs équipes d'intervention en cas d'incident de sécurité informatique (CSIRT) appropriées. Si une organisation fait ne pas avoir son propre CSIRT à contacter, il peut signaler des incidents à d'autres organisations, y compris Centres de partage et d'analyse de l'information (ISAC) . 7. Comment les incidents sont-ils signalés? La plupart des organisations disposent de plusieurs méthodes pour signaler un incident. Différentes méthodes de reporting peut être préférable en raison de variations dans les compétences de la personne déclarant l'activité, le l'urgence de l'incident et la sensibilité de l'incident. Un numéro de téléphone doit être établi pour signaler les urgences. Une adresse e-mail peut être fournie pour le signalement informel des incidents, tandis qu'un formulaire en ligne peut être utile pour signaler un incident formel. Les informations sensibles peuvent être fournie à l'équipe en utilisant une clé publique publiée par l'équipe pour crypter le matériel. 8. Quelles informations doivent être fournies lors du signalement d'un incident? Plus les informations sont précises, mieux c'est. Par exemple, si un poste de travail semble avoir été infecté par un logiciel malveillant, le rapport d'incident doit inclure autant de données que pratique: ∎ Le nom de l'utilisateur, l'ID utilisateur et les informations de contact (par exemple, numéro de téléphone, adresse e-mail) ∎ L'emplacement, le numéro de modèle, le numéro de série, le nom d'hôte et l'adresse IP du poste de travail ∎ La date et l'heure auxquelles l'incident s'est produit ∎ Une explication étape par étape de ce qui s'est passé, y compris ce qui a été fait sur le poste de travail après la découverte de l'infection. Cette explication doit être détaillée, y compris les le libellé des messages, tels que ceux affichés par le malware ou par les alertes du logiciel antivirus. À

https://translate.googleusercontent.com/translate_f

58/62

21/10/2020

Guide de gestion des incidents de sécurité informatique 9. À quelle vitesse l'équipe d'intervention en cas d'incident répond-elle à un rapport d'incident? Le temps de réponse dépend de plusieurs facteurs, tels que le type d'incident, la criticité du ressources et données affectées, gravité de l'incident, niveau de service existant Accords (SLA) pour les ressources affectées, l'heure et le jour de la semaine et autres incidents l'équipe s'occupe. En règle générale, la plus haute priorité est la gestion des incidents susceptibles de provoquer le plus de dommages à l'organisation ou à d'autres organisations. 10. Quand une personne impliquée dans un incident doit-elle contacter les forces de l'ordre? Les communications avec les forces de l'ordre doivent être initiées par l'équipe d'intervention en cas d'incident membres, le responsable de l’information (CIO) ou tout autre fonctionnaire désigné - utilisateurs, système les administrateurs, les propriétaires de système et les autres parties impliquées ne doivent pas prendre contact. 11. Que doit faire une personne qui découvre qu'un système a été attaqué? La personne doit immédiatement cesser d'utiliser le système et contacter l'équipe d'intervention en cas d'incident. le personne peut avoir besoin d'aider à la gestion initiale de l'incident - par exemple, physiquement surveiller le système jusqu'à l'arrivée des gestionnaires d'incidents pour protéger les preuves sur le système. 12. Que devrait faire une personne contactée par les médias au sujet d'un incident? Une personne peut répondre aux questions des médias conformément à la politique de l'organisation concernant les incidents et les tiers. Si la personne n'est pas qualifiée pour représenter l'organisation en termes de discussion de l'incident, la personne ne doit faire aucun commentaire sur l'incident,

66

Psaumes 76 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

autre que de renvoyer l'appelant au bureau des affaires publiques de l'organisation. Cela permettra au public bureau des affaires pour fournir des informations exactes et cohérentes aux médias et au public.

https://translate.googleusercontent.com/translate_f

59/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

67

Piste 77 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe G - Étapes de gestion des crises Voici une liste des principales étapes à suivre lorsqu'un professionnel technique estime qu'un un incident grave s'est produit et l'organisation ne dispose d'aucune capacité d'intervention en cas d'incident. Cela sert de référence de base sur ce qu'il faut faire pour quelqu'un qui est confronté à une crise et qui n'a pas il est temps de lire tout ce document. 1. Documentez tout. Cet effort comprend chaque action effectuée, chaque élément de preuve, et chaque conversation avec les utilisateurs, les propriétaires du système et d'autres personnes concernant l'incident. 2. Trouvez un collègue qui peut vous aider. La gestion de l'incident sera beaucoup plus facile si deux ou plus de personnes travaillent ensemble. Par exemple, une personne peut effectuer des actions tandis que les autres documents leur. 3. Analysez les preuves pour confirmer qu'un incident s'est produit. Effectuer des recherches supplémentaires comme nécessaire (p. ex., moteurs de recherche Internet, documentation logicielle) pour mieux comprendre les preuves. Contactez d'autres professionnels techniques au sein de l'organisation pour obtenir une aide supplémentaire. 4. Avisez les personnes appropriées au sein de l'organisation . Cela devrait inclure les principales informations (CIO), le responsable de la sécurité de l'information et le responsable local de la sécurité. Faites preuve de discrétion lorsque discuter des détails d'un incident avec d'autres; dire uniquement aux personnes qui ont besoin de connaître et d'utiliser mécanismes de communication raisonnablement sûrs. (Si l'attaquant a compromis le courrier électronique services, n'envoyez pas d'e-mails concernant l'incident.) 5. Informez l'US-CERT et / ou d'autres organisations externes pour obtenir de l'aide pour faire face à l'incident. 6. Arrêtez l'incident s'il est toujours en cours. La manière la plus courante de procéder est de déconnecter systèmes du réseau. Dans certains cas, les configurations du pare-feu et du routeur peuvent devoir être modifiées pour arrêter le trafic réseau qui fait partie d'un incident, tel qu'une attaque par déni de service (DoS). 7. Conservez les preuves de l'incident. Faire des sauvegardes (de préférence des sauvegardes d'image disque, pas de système de fichiers sauvegardes) des systèmes concernés. Faites des copies des fichiers journaux contenant des preuves liées à l'incident. 8. Supprimez tous les effets de l'incident. Cet effort comprend des infections de logiciels malveillants, des contenus inappropriés (par exemple, logiciels piratés), fichiers de chevaux de Troie et toute autre modification apportée aux systèmes par des incidents. Si un système a été entièrement compromis, reconstruisez-le à partir de zéro ou restaurez-le à partir d'une bonne sauvegarde connue. 9. Identifiez et atténuez toutes les vulnérabilités qui ont été exploitées. L'incident peut s'être produit par tirer parti des vulnérabilités des systèmes d'exploitation ou des applications. Il est essentiel d'identifier ces vulnérabilités et les éliminer ou les atténuer d'une autre manière afin que l'incident ne se reproduise pas. 10. Confirmez que les opérations sont revenues à la normale. Assurez-vous que les données, les applications et les autres services touchés par l'incident ont repris leurs activités normales. 11. Créez un rapport final. Ce rapport doit détailler le processus de gestion des incidents. Il devrait également fournir un résumé de ce qui s'est passé et de la façon dont une capacité d'intervention officielle en cas d'incident aurait a aidé à gérer la situation, à atténuer les risques et à limiter les dommages plus rapidement.

68

Piste 78 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

Annexe H - Journal des modifications

https://translate.googleusercontent.com/translate_f

60/62

21/10/2020

Guide de gestion des incidents de sécurité informatique Révision 2 Draft 1 - Janvier 2012 Éditorial: ∎ Rédaction renforcée tout au long de la publication ∎ Modifications mineures de mise en forme tout au long de la publication Modifications techniques: ∎ Documentation élargie sur le partage d'informations (tout au long de la section 2) ∎ Mise à jour des listes des organisations de signalement des incidents (section 2.3.4.3) ∎ Liste mise à jour des services courants de l'équipe d'intervention en cas d'incident (section 2.5) ∎ Révision des diagrammes du cycle de vie des interventions en cas d'incident (tout au long de la section 3) ∎ Refonte de la liste des vecteurs d'attaque (section 3.2.1) ∎ Réorganisé les facteurs de hiérarchisation de la gestion des incidents (section 3.2.6) ∎ Changement de focalisation de l'identification de l'attaquant à l'identification de l'hôte attaquant (section 3.3.3) ∎ Élargissement de la liste des mesures d'incidents possibles (section 3.4.2) ∎ Mise à jour des scénarios de gestion des incidents pour refléter les menaces actuelles (ancienne annexe B, nouvelle annexe A) ∎ Mise à jour mineure des suggestions de champs de données relatives aux incidents (ancienne annexe C, nouvelle annexe B) ∎ Mise à jour de toutes les listes d'outils et de ressources (ancienne annexe G, nouvelle annexe E) ∎ Mise à jour des questions fréquemment posées et des étapes de gestion des crises pour refléter les changements apportés ailleurs dans la publication (anciennes annexes H et I, nouvelles annexes F et G) Suppressions: ∎ Suppression du matériel en double sur la criminalistique, pointant les lecteurs vers SP 800-86 pour les mêmes informations (Section 3.3.2) ∎ Éléments supprimés spécifiques aux anciennes catégories d'incidents (sections 4 à 8) ∎ Suppression de la liste de recommandations en double (ancienne annexe A) ∎ Liste des ressources d'impression supprimée (ancienne annexe F) ∎ Suppression des catégories de rapports d'incidents des agences fédérales (ancienne annexe J)

Révision 2 Final - août 2012 Éditorial: ∎ Révisions mineures tout au long de la publication Modifications techniques: ∎ Ajout du partage d'informations en tant que service d'équipe (Section 2.5) ∎ Conversion du tableau 3-1 en listes à puces (section 3.1.1) ∎ Ajout d'une mention d'exercices (section 3.1.1) ∎ Révision des vecteurs d'attaque (anciennement catégories d'incidents) (section 3.2.1)

69

Piste 79 C ORDINATEUR S ECURITE I NCIDENT H ANUTENTION G UIDE

∎ Ajout des SIEM, des flux de réseau comme sources communes de précurseurs et d'indicateurs (section 3.2.3) ∎ Discussion élargie sur l'éradication et la récupération (section 3.3.4) ∎ Ajout d'une section sur la coordination et le partage d'informations (section 4) ∎ Ajout d'un tableau des spécifications d'échange de données applicables à la gestion des incidents (Annexe E)

https://translate.googleusercontent.com/translate_f

61/62

21/10/2020

Guide de gestion des incidents de sécurité informatique

70

https://translate.googleusercontent.com/translate_f

62/62