Comment mieux faire face aux incidents de cybersécurité
La réponse aux incidents de sécurité est une chose dont toute l’organisation doit se préoccuper. Et pour une bonne raison : les attaquants sont probablement déjà en train d’essayer d’infiltrer le réseau, et de nombreuses vulnérabilités sont probablement là pour leur faciliter la tâche.
Bien sûr, le temps est loin où les dirigeants étaient largement déconnectés de la fonction sécurité de l’information. Désormais, la cybersécurité est en tête des préoccupations de beaucoup, et à juste titre : il ne se passe probablement pas un jour sans qu’une entreprise ne soit la cible d’une attaque ou à tout le moins exposée à des risques de sécurité liés à l’IT.
Les menaces de sécurité et les vulnérabilités, ainsi que les incidents et brèches auxquels elles peuvent conduire, concernent les organisations de toutes natures. Littéralement n’importe quelle entreprise – grande ou petite, et sur tout secteur d’activité – est une cible pour les cyberdélinquants, et à la merci de collaborateurs négligents. La question est : quoi faire ? C’est là qu’intervient la réponse à incident.
La réponse à incident est le processus consistant à détecter les événements de sécurité qui affectent les ressources du réseau et les actifs informationnels, puis à prendre les mesures qui s’imposent pour évaluer ce qui s’est produit et y remédier. La réponse aux incidents de cybersécurité est essentielle pour les entreprises, car il y a potentiellement là beaucoup à perdre. De l’infection par maliciel apparemment bénigne au chiffrement de systèmes par ransomware, en passant par le vol d’identifiant et l’exposition de bases de données, les conséquences à court et long terme de ces incidents peuvent pénaliser longuement l’entreprise.
Pourquoi est-ce nécessaire ?
Les brèches de sécurité peuvent nécessiter d’être notifiées. Avec à la clé, le risque de perte de confiance des clients, et des amendes, en plus des coûts de remédiation. Et tout cela en même temps, de sorte que même les entreprises aux reins les plus solides peuvent se retrouver en difficulté.
Les réseaux, logiciels et utilisateurs finaux peuvent apporter un certain niveau de résilience, mais il a ses limites. Les erreurs arrivent, les négligences aussi. Ce qui compte est ce qui a été fait, par avance, pour minimiser l’impact d’un incident de sécurité sur l’entreprise. On ne peut pas empêcher les pirates d’exister, mais il est possible d’anticiper la réponse et de travailler la prévention.
C’est pourquoi disposer d’une équipe fonctionnelle, des technologies appropriées et surtout d’un plan de réponse à incident bien documenté est essentiel pour être capable de réagir à de tels événements, de manière rapide et professionnelle.
Il est tout d’abord important de faire la différence entre les menaces et les vulnérabilités.
Dans ce contexte, il est tout d’abord important de faire la différence entre les menaces et les vulnérabilités. Les premières sont des indications, comme un attaquant ou un employé malveillant cherchant à exploiter une vulnérabilité. Par vulnérabilité, on entend une faiblesse dans un système informatique ou un processus métier ou encore dans les personnes elles-mêmes, qui peut être exploitée à des fins malicieuses.
Les menaces exploitent des vulnérabilités qui, en définitive, créent des risques métier. Les conséquences potentielles sont l’accès illégitime à des actifs informationnels sensibles, le vol de données, l’interruption de service, ou encore la violation d’impératifs réglementaires ou de conformité interne. La terminologie est importante.
Brèche : incident dans le cadre duquel des données sensibles, comme de la propriété intellectuelle ou des enregistrements clients, sont exposées.
Piratage, ou attaque : l’action d’un cyberdélinquant (ou d’un groupe), voire d’un utilisateur malveillant, consistant à provoquer l’arrêt de systèmes, à installer ou distribuer un maliciel, ou voler des actifs informationnels.
Incident : une attaque réussie, conduisant à une interruption de service, à la compromission d’une ressource du système d’information, ou à l’accès non autorisé à des actifs informationnels.
Événement : potentiel problème de sécurité qui n’a pas été confirmé et dont tous les détails ne sont pas maîtrisés.
Les attaques ne conduisent pas systématiquement à des incidents, et ceux-ci ne conduisent pas toujours à des brèches. Tous constituent des événements de sécurité. Mais beaucoup de ces événements s’avèrent souvent sans gravité. Tout dépend de ce qui s’est produit et de ce qui peut être déterminé à partir des faits observés.
Quoiqu’il en soit, le but est bien de disposer des stratégies nécessaires, en impliquant les directions métiers, pour faire face aux menaces et vulnérabilités modernes plus efficacement, que l’on dispose déjà d’un programme de réponse à incident ou pas.
Construire une équipe de réponse à incident
Un bon programme de réponse à incident commence par la constitution d’une bonne équipe. Sans les bonnes personnes, les politiques de sécurité, les processus et les outils ne sont pas grand-chose. Une équipe de réponse à incident se construit à partir d’un groupe de personnes interfonctionnelles issues de différentes parties de l’entreprise, dont l’IT et la sécurité, la production, les relations publiques et le juridique. L’un de ces rôles devrait relever directement de la direction de l’entreprise : cela doit permettre une prise en compte permanente des intérêts supérieurs de l’entreprise, et d’assurer de disposer du niveau de décision le plus élevé possible.
Le but d’une équipe de réponse à incident est de détecter et de répondre aux incidents de sécurité afin d’en minimiser l’impact sur l’entreprise.
On parle souvent d’équipes de réponse aux incidents de sécurité informatique (CSIRT) ou de réponse aux urgences informatiques (CERT). De nombreux professionnels de la réponse à incident trouvent leur place dans des centres opérationnels de sécurité (SOC), dont le périmètre va au-delà de la réponse à incidents. Le nom choisi importe finalement assez peu : les objectifs sont les mêmes.
De fait, quel que soit son nom, l’équipe de réponse à incident devrait travailler à supporter son rôle dans le plan de réponse à incident, qui lui-même, devrait compléter les objectifs du programme de sécurité de l’information. Les objectifs de l’équipe de réponse à incident peuvent ainsi recouvrir des réunions régulières, la réalisation d’exercices de simulation, et surtout de travailler à réduire les délais de réponse ainsi que minimiser l’impact d’éventuels incidents. Pour obtenir des résultats, ces objectifs doivent être définis de manière très précise, en utilisant le présent et en détaillant les étapes et la chronologie, afin d’aider à la responsabilisation.
Voici quelques exemples d’objectifs pouvant être développés par l’équipe elle-même ou un comité de supervision :
Nous définissons des indicateurs pour analyser les initiatives du programme de réponse à incident qui impliquent surveillance et production d’alertes, communication entre membres de l’équipe, et évaluations technologiques.
Nous mettons à jour la documentation du plan de réponse à incident régulièrement et avec rigueur.
Nous créons et conduisons trois exercices de simulation distincts.
Nous échangeons avec le comité de sécurité et la direction pour rapporter sur les incidents de sécurité, les actions prises, et les améliorations requises.
L’équipe de réponse à incident – ou le manager du programme – peut détailler des objectifs avec les étapes intermédiaires pour chacun d’entre eux, le tout assorti d’échéances permettant à tous les membres de l’équipe de savoir ce que l’on attend d’eux et vers quoi tendre.
Les objectifs doivent être raisonnables et atteignables. Et leur réalisation doit être suivie. Sinon, ils risquent de ne devenir qu’une arrière-pensée, avant d’être pénalisants au lieu de constituer des avantages. Les choses s’avèrent particulièrement difficiles lorsque survient effectivement un incident et que l’on découvre que les procédures documentées sont inexistantes ou pas du tout suivies. A minima, il convient de souligner les différents rôles de chacun dans le plan de réponse à incident, et les responsabilités afférentes.
Un jeu de compétences étendu
L’équipe de réponse à incident doit inclure :
Une équipe technique – avec des membres de l’équipe IT et SSI.
Un dirigeant sponsor – un membre de la direction chargé de superviser la sécurité de l’information.
Un coordinateur de la réponse à incident – une personne responsable de la gestion quotidienne de l’équipe et des incidents.
Un coordinateur des relations publiques – ce sera le porte-parole de l’entreprise auprès des médias si une brèche survient.
Un analyste légiste – il peut s’agir d’un expert interne à l’entreprise comme d’un consultant externe.
Un consultant externe – un tiers expert en SSI ou en réponse à incident.
Un conseiller juridique – là encore, interne ou externe, mais chargé de représenter l’organisation autant que nécessaire pour les incidents et les brèches.
La réponse à incident requiert ainsi un éventail de compétences important. Le cœur de l’équipe reste toutefois technique, avec les spécialistes de la réponse à incident et les personnes qui défendent l’organisation contre les attaques informatiques. Celles-ci sont compétentes en sécurité du système d’information et peuvent réaliser des tâches telles que la surveillance du réseau à la recherche de vulnérabilités et de brèches, mais également la mise en place des mesures de remédiation appropriées lorsqu’elles sont nécessaires.
Les spécialistes de la réponse à incident utilisent les données disponibles pour identifier les incidents, et surtout en déterminer l’étendue et la gravité. Ils peuvent également faire des rapports sur les tendances observées, ainsi que contribuer à la sensibilisation des utilisateurs et à la communication avec les autorités compétentes.
Mais bien sûr, les compétences techniques ne sont pas tout. Comme vu plus haut, une équipe de réponse à incident robuste a besoin de profils transverses capables de réaliser des tâches non techniques, comme communiquer et traiter les questions juridiques.
Il n’est pas question d’essayer de constituer une équipe de réponse à incident avec des personnes qui n’ont aucune envie d’en faire partie.
Il est essentiel d’identifier celles et ceux qui s’intéressent au sujet et ont envie d’apporter leur valeur ajoutée à cet aspect critique de la sécurité.
Méthodologie
Le plan de réponse à incident est le document de référence vers lequel se tourner lorsque les choses tournent à l’aigre. Il décrit les qui, quoi, quand, comment et pourquoi de la gestion des événements et incidents de sécurité, voire des brèches lorsqu’elles sont confirmées. En fait, sans un plan dûment documenté, tout n’est que réaction, avec ce que cela implique comme perte de capacité à raisonner sereinement, à froid, en toute lucidité. Et d’augmenter alors le risque de prendre de mauvaises décisions. Avec un plan de réponse bien avisé, à l’inverse, il est possible de traiter l’incident avec clarté et rigueur, sans se laisser piloter par ses émotions.
Le plan de réponse à incident doit donc être développé en avance par l’équipe de réponse à incident ou son coordinateur. Les composants détaillés dans le tableau ci-dessous doivent y figurer.
Eléments du plan de réponse à incident
Chaque plan est différent, en fonction des besoins spécifiques. Toutefois, ce modèle recouvre les éléments essentiels, standard, et devant figurer dans le plan de réponse à incident de toute organisation. Et les ressources et recommandations ne manquent pas pour aller plus loin. Les frameworks sont d’ailleurs nombreux, entre ceux du NIST américain, de l’ISACA, de l’ISO/IEC, ou encore de l’institut SANS, de l’IEEE, de l’IETF et de l’Enisa. Celui du NIST, par exemple, adopte une approche de cycle de vie.
Le plan de réponse à incident ne devrait pas être combiné à des documents ou des procédures et plans de sécurité de l’organisation autres, comme le plan de continuité de l’activité (PCA) ou le plan de reprise de l’activité en cas de sinistre (PRA). Le plan de réponse à incident fonctionne mieux seul, accessible à tous les membres de l’équipe dédiée, sous forme imprimée et numérique.
Créer son plan de réponse à incident nécessite une expertise certaine et l’implication de tous les membres de l’équipe concernée. Une bonne façon de commencer consiste à répartir les différentes parties entre les membres de l’équipe. Une fois que chacun a préparé sa partie, il est possible de réunir l’ensemble dans un document unique et de commencer à travailler à la formalisation d’une version finale. Mais il convient de conserver à l’esprit qu’un plan de réponse à incident est un travail vivant, qui doit être révisé périodiquement et ajusté suivant les évolutions du système d’information, de la menace, ou de l’activité.
Quand, comment et pourquoi utiliser des outils de réponse à incident
Boucle OODA
Si la sécurité de l’information est souvent considérée comme une fonction stratégique de l’entreprise, la réponse à incident est le composant tactique du programme de sécurité. Ce n’est pas le seul parallèle avec le monde militaire : la boucle OODA – pour Observe, Orient, Decide, Act – en vient également et s’applique la réponse à incident. L’idée est d’utiliser la connaissance de la situation pour observer les incidents à mesure qu’ils évoluent et de répondre rapidement, suivant un processus d’amélioration continue, pour avancer vers la maîtrise complète de la menace. Cela permet d’en réduire l’impact métier.
La boucle OODA peut être utilisée comme approche globale de la réponse à incident et peut aider à définir quels outils de sécurité à utiliser tout au long du processus. Et ceux-ci sont nombreux, qu’il s’agisse de prévention, détection ou réponse. Par exemple, la visibilité apportée par l’analyse de paquets réseau, l’examen de ressources système ou la supervision de l’intégrité de fichiers correspondent à la phase d’observation de la boucle OODA. Les outils de gestion du renseignement sur les menaces peuvent en alimenter la phase d’orientation.
La réponse à incident est un processus, mais la technologie peut en automatiser certaines fonctions pour aider à l’accélérer et à limiter les erreurs. Et là, de nombreux outils peuvent s’avérer utiles : ceux d’analyse des flux et du trafic réseau, de gestion des vulnérabilités, les systèmes de gestion des informations et des événements de sécurité (SIEM), les outils de détection et de réponse sur les hôtes du SI (EDR), le pare-feu, les systèmes de détection/prévention d’intrusion (IDS/IPS), etc.
De nombreux outils sont commerciaux, mais les alternatives open source existent également pour la plupart de ces domaines. Il s’agit juste d’évaluer ses besoins et l’investissement nécessaire – en numéraire comme en ressources humaines –, tout en tenant compte de la pérennité des offres.
Résoudre des problèmes
La résolution de problèmes est un élément clé de réponse à incident. La boucle OODA se concentre sur la prise de décision. Mais il est important de ne pas se laisser prendre au piège de ce processus ou de toute autre méthodologie. Car il est facile de se laisser distraire et de perdre de vue ce qui est important.
C’est ce que l’on appelle la hiérarchisation : quels que soient les incidents – et plus ils sont nombreux –, il est important de déterminer ceux qui doivent être traités en priorité. Ce qui revient à déterminer ceux qui sont urgents, ceux qui sont importants et comment il faudra réagir aux différents scénarios. Là, il convient de considérer les événements, les incidents et les brèches confirmées en fonction des éléments suivants :
Qu’est-ce qui est urgent, mais pas important ?
Qu’est-ce qui est important, mais pas urgent ?
Qu’est-ce qui est à la fois urgent et important ?
Un exemple de problème urgent, mais non important serait une infection par un logiciel malveillant sur un poste de travail de vente d’une succursale qui ne se connecte au réseau du bureau ou à l’internet que via le Wi-Fi invité. Un exemple de problème important, mais non urgent, peut être celui d’un nouvel ordinateur portable récemment imagé qui est perdu, mais qui ne contient pas encore d’informations métier. Une attaque en déni de service distribué (DDoS) contre un site web de commerce électronique, une infection par un logiciel malveillant affectant les serveurs de production et des tentatives de phishing contre des cadres ou des administrateurs sont autant d’exemples de situations urgentes et importantes. C’est là qu’il faut intervenir sans perdre de temps.
En moyenne, la petite, moyenne ou grande entreprise présente d'innombrables vulnérabilités qui n'ont pas encore été reconnues.
De nombreux problèmes de sécurité observés relèvent des deux premières catégories. Ils doivent être traités d’une manière ou d’une autre, mais ils ne doivent pas distraire de l’essentiel : la troisième catégorie, celle où l’on doit concentrer la majorité de ses ressources de réponse à incident. L’important est de prendre en compte la situation dans son ensemble, pour accorder la plus haute priorité aux événements de sécurité ayant le plus d’impact sur les ressources et les actifs informationnels critiques.
Dans le monde technologique actuel, où les décisions sont souvent prises pour nous, il devient de plus en plus difficile de trouver du personnel informatique et de sécurité capable de résoudre les problèmes, surtout sous pression d’un événement de sécurité. Mais en ce qui concerne la réponse à incident, il n’est pas question de faire l’impasse dessus. Il faut donc s’assurer que la résolution de problèmes y implique les domaines appropriés : définition du problème, détermination de toutes les solutions possibles, choix de la meilleure solution et ensuite prise de mesures ciblées.
La prévention est clé
Le programme de réponse aux incidents est là pour y faire face lorsqu’ils surviennent. Mais, la première ligne de défense consiste à assurer la sécurité de son système d’information, et à veiller à ce que ses utilisateurs soient responsabilisés et sensibilisés à la sécurité. Les incidents de sécurité qui peuvent créer le plus de dégâts sont ceux qui exploitent la crédulité des utilisateurs – des maliciels – et les défauts de configuration pouvant être exploités pour une énumération et une intrusion plus poussées. Les entreprises de toutes tailles présentent d’innombrables vulnérabilités qui n’ont pas encore été identifiées, et encore moins traitées. Mais compte tenu des outils à disposition aujourd’hui, il n’y a tout simplement aucune raison d’offrir des avenues aux pirates. Des mots de passe faibles, des correctifs non appliqués et des informations non sécurisées peuvent facilement conduire à un incident ou à une brèche. Et cela ne se produit hélas que trop souvent.
Plutôt que des politiques, des processus et des contrôles techniques, ce qui est nécessaire, c’est une hygiène, une discipline, pour reconnaître les menaces et les vulnérabilités, y compris pour son programme de sécurité de l’information, jusque dans la réponse aux incidents.
La réponse à incident n’est pas seulement une question informatique supervisée et exécutée par des professionnels techniques. Il s’agit plutôt d’une fonction essentielle de l’entreprise, sans doute aussi importante que tout ce qui touche aux aspects juridiques, financiers ou opérationnels de l’entreprise – et doit ainsi être soutenue au plus haut niveau.
