Pourquoi le personnel, les processus et la réponse aux incidents sont les plus importants
La technologie de cybersécurité fournit des quantités incroyables de données brutes aux équipes SOC des soins de santé. Cette technologie doit s’accompagner à la fois de maturité et de flexibilité du côté humain.
Par exemple, une alerte SIEM concernant un script Microsoft PowerShell exécuté sur un contrôleur de domaine Active Directory pourrait être le premier signe d’un problème majeur, ou cela pourrait n’avoir rien d’extraordinaire. Pour se différencier, le SIEM doit fournir un contexte, et le contexte doit provenir de l’organisation elle-même. Quelle est l’identité qui exécute le script ? Existe-t-il un ticket de modification, même non approuvé, pour ce serveur ? Existe-t-il d’autres alertes pour cette identité ou ce serveur dans le même laps de temps ? S’agit-il d’un système critique ou d’un serveur de laboratoire sur lequel quelqu’un s’entraîne pour sa prochaine certification ?
L’alerte doit être transformée en incident, avec toutes les informations et le contexte à l’appui, avant d’être transmise à un analyste. Sans ces étapes, l’analyste ne peut pas prendre de décisions et doit collecter ces informations manuellement, de manière ponctuelle et chronophage.
Il est facile de penser que davantage de technologie est la solution, mais ce n’est pas la bonne façon d’envisager le problème. La solution consiste à augmenter votre technologie existante de manière à ce que le côté humain puisse intervenir et résoudre le problème rapidement. Si les équipes sont cloisonnées par technologie ou par responsabilité, si le flux de travail d’un incident est constitué de messages instantanés informels, si l’incident ne peut pas être géré jusqu’à ce que la bonne personne arrive en poste avec la bonne mémoire institutionnelle, alors le délai moyen de réponse (MTTR) en souffre. Les équipes informatiques peuvent avoir la capacité de résoudre le problème, mais pas la capacité de le faire dans les délais qui comptent.
Il y a une citation que l’on entend souvent lorsque les professionnels de la sécurité parlent de leur charge d’alerte : si tout est urgent, alors rien n’est urgent. Résoudre le problème du bruit excessif est essentiel à l’efficacité de l’équipe de sécurité de toute organisation.
Répondre aux menaces nécessite également une boucle de rétroaction humaine continue vers la technologie. Les SIEM et XDR généreront du bruit, et ce bruit deviendra de plus en plus fort à mesure que le monde deviendra plus méchant. Les équipes informatiques doivent réagir aux outils de sécurité pour affiner les règles de corrélation, mettre à jour les informations contextuelles, améliorer le filtrage de ce qu’elles voient et mettre à jour les processus en fonction des enseignements tirés.
Tout cela prend du temps et ne sera jamais entièrement automatisé. Cette boucle de rétroaction finale visant à améliorer le rapport signal/bruit nécessite un engagement de la part de la direction informatique, en affectant les bonnes personnes dotées des capacités appropriées et le temps supplémentaire dont elles ont besoin pour assurer un cycle d’amélioration continue.
Réussir le test : SecOps est-il prêt sur le plan opérationnel ?
Dans sa forme la plus simple, les opérations de sécurité sont un cycle en quatre étapes : collecter les journaux, enrichir les incidents, normaliser la réponse et, après l’incident, fournir des commentaires pour améliorer les outils et les processus. La technologie rend cela possible, mais dans un rôle de soutien ; les personnes et les processus déterminent tout.
Les responsables informatiques peuvent s’auto-auditer pour voir s’ils équilibrent les investissements technologiques avec des processus et des ressources humaines appropriés. Le MTTR des incidents est-il mesuré en minutes et heures, ou en jours et semaines ? Les alertes hautement prioritaires sont-elles suffisamment enrichies pour que la première étape d’un analyste soit de décider comment y remédier, ou doit-il perdre du temps à croiser les journaux et les bases de données de configuration ? Le flux de travail pour les problèmes les plus courants dans un playbook est-il standardisé et testé, ou la réponse varie-t-elle en fonction de la personne assise devant la console ? Les incidents majeurs sont-ils accompagnés d’une analyse des causes profondes qui alimente le réglage et éclaire le playbook des incidents ?
La création d’un SOC mature nécessite un contexte humain, c’est-à-dire des personnes et des flux de travail qui définissent la manière dont les menaces sont identifiées, traitées et résolues. Les investissements existants dans la technologie de sécurité prennent en charge ces flux de travail. Faire cela correctement n’est pas un travail du jour au lendemain ; par exemple, l’automatisation commence par l’enrichissement et le contexte des incidents, en extrayant les informations des systèmes de gestion des identités et des accès, des bases de données de configuration avec la criticité des actifs et des données, de l’historique des correctifs et des sources Internet telles que les listes de vulnérabilités connues. Une fois que cela est solide, l’ajout d’une réponse automatisée et d’un confinement constitue une excellente prochaine étape.
La maturité technologique doit aller de pair avec la maturité organisationnelle : les équipes doivent être sur la même longueur d’onde lorsqu’il s’agit d’isoler un système compromis ou de mettre hors service un serveur de production. Le moment de se battre à ce sujet est avant qu’un incident ne se produise, ou lors d’une analyse post-mortem, mais pas lorsqu’un incident réel est en cours.
Face à l’omniprésence des attaquants utilisant l’IA, la rapidité de réponse est la mesure la plus critique. Lorsqu’une menace peut être atténuée par l’automatisation, elle devrait l’être. La technologie de sécurité offre de la visibilité, mais la présence de personnes et de processus en place assure la rapidité.