What Could be Improved?

L'identification des faiblesses dans la réponse à un incident peut aider les entreprises à mieux se préparer et à réagir à l'avenir, réduisant ainsi potentiellement l'ampleur des dommages que les acteurs malveillants peuvent provoquer et minimiser l'impact sur l'entreprise. Cette leçon expliquera comment les équipes de sécurité et les parties prenantes chargées de la réponse aux incidents doivent identifier leurs lacunes et comment y remédier.

Au cours de la réunion qui suit l'incident, toutes les parties prenantes doivent prendre le temps approprié pour réfléchir aux problèmes qu'elles ont rencontrés au cours du processus. Quelqu'un a-til gâché la collecte de preuves ? L'équipe manquait-elle de ressources telles que des ordinateurs portables et des disques durs vierges ? Une fois les faiblesses identifiées, il est important de discuter de la manière dont l'organisation peut s'assurer qu'elles ne se reproduisent pas lors d'incidents futurs. Les questions qui pourraient être posées sont notamment les suivantes :

• Quelles étaient les limites en matière d'outillage ?
• Quelles étaient les limites en ce qui concerne les procédures et les directives ?
• Des personnes ou des services ont-ils entravé la réponse à l'incident ? Comment ?
• Réfléchissez à la faiblesse de chacune des étapes du cycle de vie de réponse aux incidents du NIST et à la manière dont elle peut être améliorée en termes de ressources, de personnel et de documentation.

Maintenant que les faiblesses ont été découvertes, il est important de veiller à ce qu'il y ait réellement des changements. Il ne sert à rien de mettre en évidence ces problèmes s'ils ne sont pas résolus. C'est le moment idéal pour discuter avec la direction du besoin de ressources pour renforcer la réponse à de futurs incidents. Cela peut inclure :

• Plus de budget pour le personnel de sécurité tel que les analystes judiciaires, les intervenants en cas d'incident, les commandants des incidents, etc.
• Plus de budget pour le personnel d'autres départements, tels que les services juridiques, les relations publiques, les communications ou les ressources humaines.
• Un budget plus important pour les outils susceptibles de faciliter les activités de réponse aux incidents.
• Révision de la documentation telle que les run-books, les politiques et les procédures.

mportance of Documentation

1. Incident Response

2. Lessons Learned and Reporting

3. Importance of Documentation

Comme indiqué précédemment dans ce domaine, le maintien d'un plan de réponse aux incidents (IRP) et de cahiers de réponse pour différents scénarios est essentiel pour des réponses rapides et simples. En enregistrant chaque incident en détail, si un incident similaire se produit, les analystes peuvent se référer à la documentation de l'ancien incident pour obtenir des conseils. La documentation suivante peut être mise à jour après un incident, le cas échéant :

Notes sur les cas de réponse aux incidents

Quel que soit l'outil utilisé par l'organisation pour enregistrer les notes d'enquête de sécurité (comme ServiceNow et IBM Resilient), il doit être entièrement mis à jour pour garantir que le dossier contient tout ce dont il a besoin, notamment des informations provenant de toutes les étapes du cycle de vie de la réponse à un incident. Des artefacts doivent être inclus, tels que les noms de fichiers, les hachages de fichiers, les adresses IP, les noms de domaine, etc. Des pièces jointes doivent être ajoutées au dossier, y compris les e-mails envoyés aux parties prenantes, les copies de fichiers malveillants, les fichiers journaux et tout autre élément considéré comme étant considéré comme étant important pour l'enquête.

Plan de réponse aux incidents

Peut-être que le processus de réponse global pourrait être amélioré, ce qui devrait être discuté et toute modification apportée au plan de réponse aux incidents (IRP) de l'organisation devrait être mise en œuvre. Cela peut inclure des modifications apportées aux parties prenantes faisant partie de l'équipe de réponse aux incidents, de nouvelles méthodes de communication sécurisée, des modifications des numéros de contact ou des adresses e-mail, ainsi que d'autres informations cohérentes pour tous les incidents potentiels.

Carnets de gestion des incidents

L'examen des livres de gestion relatifs au type d'incident qui s'est produit peut aider à améliorer les réponses futures en fournissant des conseils aux analystes qui réagiront à l'avenir à l'incident. Plus

ces manuels seront détaillés, mieux c'est, car ils incluront un plus grand nombre de scénarios potentiels et contribueront à rendre les réponses futures plus structurées et organisées.

Vous pouvez trouver de nombreux exemples de run-books ici pour vous faire une idée de ce à quoi ils ressemblent et de ce qu'ils incluent.

Politiques de l'organisation

L'incident s'est peut-être produit à la suite d'une action qui n'était pas correctement limitée par les politiques de l'organisation, par exemple lorsqu'un utilisateur a téléchargé un logiciel sur Internet parce que la Politique d'utilisation acceptable ne lui interdit pas de le faire. La mise à jour de cette politique indiquant que tous les logiciels doivent être acquis à partir d'un référentiel interne, ou que les employés peuvent créer un ticket auprès du service informatique pour que le logiciel soit téléchargé pour eux à partir de sources sûres connues, permettra d'éviter de futurs incidents ou, du moins, de renforcer la responsabilité. Un autre exemple serait un système connecté à Internet auquel aucune mise à jour ni aucun correctif de sécurité n'ont été appliqués, car il n'existe aucune politique de gestion des vulnérabilités ou d'application de correctifs, obligeant les propriétaires du système à le maintenir à jour et à le sécuriser. La mise en œuvre de cette mesure pourrait à nouveau contribuer à prévenir des incidents similaires à l'avenir.