Améliorer la sécurité pour prévenir les cyber-incidents
TL;DR
Le risque n'est que ce que nous ne voyons pas. Gérer et répondre c'est réagir à ce que nous voyons. Prévenir c'est mettre des barrières contre ce que nous ne voyons pas pour que nous ne le voyons jamais. Mieux prévenir c'est ajouter de petites barrières en plus de celles qui existent déjà, de manière minutieuse et à chacune de nos habitudes, pour que ce que nous ne voulons jamais voir s'éloigne même de nos angles morts.
Contexte
Imaginez une entreprise qui subie des attaques à répétition de manière régulière et possède un processus de réponse aux incidents absolument remarquable. Une équipe de "super-héros" de la cybersécurité qui, jour après jour, affronte des attaques ransomware avec une précision chirurgicale. Leurs sauvegardes sont impeccables, leurs procédures de restauration sont quasi-instantanées, et le business continue comme si de rien n'était. Le rêve absolu de tout RSSI, n'est-ce pas ?
Mais derrière cette façade de perfection technique se cache une réalité bien plus sombre. Les membres de l'équipe, constamment sur le qui-vive, accumulent les heures supplémentaires, sacrifiant leur vie personnelle sur l'autel de l'excellence opérationnelle. Leurs familles ne les voient plus, leur santé mentale s'érode, et pour quoi ? Pour maintenir l'illusion d'une invulnérabilité qui n'existe pas. Cette situation, en apparence maîtrisée, cache en réalité un piège redoutable : le syndrome du héros d'un point de vu cybersécurité.
Car soyons honnêtes : cette approche "pompier de service", aussi brillante soit-elle, n'est qu'un pansement sur une plaie béante. Ce n'est pas une situation confortable, c'est une bombe à retardement.
Voyons pourquoi :
Tout d’abord, il y a toujours un delta de données perdu entre l’attaque subie et la restauration des données
L'entreprise est fortement faillible en plus d'être exposée aux attaques, il faut comprendre pourquoi
Sur le long terme les employés seront grandement épuisé par ce processus incessant
L'entreprise mise tout sur la gestion et la réponse à incident, cela témoigne un déséquilibre dans la stratégie de sécurité
Les pertes financières suite à ces attaques enchaînées sont réelles pour l'entreprise sans parler de sa réputation.
Du point de vue de l’attaquant, chacune de ces attaques sont des réussites et chaque donnée récoltée est non négligeable.
Ce n'est pas un problème me direz-vous, tant que l'entreprise s'en remet ? En fait si et c'est tout l'objet de cet article.
Introduction
Reprenons nos basiques. Le principe de la sécurité informatique est de préserver les CIA de la donnée (Confidentiality, Integrity, Availability) de toutes menaces. En d'autres termes, comme je le dis souvent, notre objectif est d'éviter toutes attaques, c'est à dire que le critère d'acceptabilité de la sécurité d'un produit est sa résistance aux menaces.
Cela est atteignable de différentes manières, les processus au sein d'un service de sécurité informatique sont divers et variés et rentre en général dans l'une des grandes cases suivantes :
Prévention (GRC & APPSEC)
Détection (SOC & SECOPS)
Réponse (CERT)
(GIAC)
Dans notre cas les deux derniers rentrerait dans la partie Gestion (gros raccourcis).
Les efforts de notre équipe sécurité devraient être répartis sur tous ces aspects pour une posture de sécurité adéquate. Toutefois je défend le point de vue selon lequel la prévention est un pilier important de cette posture. Pour justifier mon propos je vais développer ma compréhension de la gestion d'incident avant d'expliquer pourquoi la prévention d'incidents est si importante.
Gestion d’incidents
Réponse à incidents
La réponse à incident désigne les "processus et technologies d’une organisation pour détecter et répondre aux cyber-menaces, aux violations de la sécurité et aux cyberattaques." (IBM)
L’objectif de la réponse aux incidents est de prévenir les cyberattaques avant qu’elles ne se produisent, et de minimiser les coûts et les perturbations de l’activité résultant des cyberattaques qui se produisent. La réponse aux incidents est la partie technique de la gestion des incidents, qui comprend également la gestion exécutive, RH et juridique d'un incident grave.
— (IBM)
Pourquoi on fait de la gestion d'incident ?
A l’échelle des services d’une entreprise “La gestion des incidents vise à identifier et à corriger les problèmes tout en assurant un fonctionnement normal et en minimisant l’impact sur l’entreprise.” (IBM). On fait donc de la gestion d’incident pour assurer la continuité d’activité de l’entreprise, en interne comme en externe, pour assurer la délivrance continue de la valeur ajoutée que les clients perçoivent de la part de l’organisation. En sécurité informatique comme dans d’autres domaines, un incident peut avoir des impacts néfaste sur l’activité d’une entreprise. En voici quelques examples par secteur d’activité :
Secteur bancaire : Interruption des services bancaires en ligne, gel des transactions, atteinte à la confiance des clients en cas de fuite de données financières
Secteur médical : Impossibilité d'accéder aux dossiers patients, perturbation des systèmes de suivi médical, report d'interventions programmées
Commerce en ligne : Paralysie de la plateforme de vente, perte de chiffre d'affaires directe, atteinte à la réputation
Industrie manufacturière : Arrêt des chaînes de production automatisées, retards de livraison, pertes financières liées à l'interruption
Transport : Perturbation des systèmes de réservation, désorganisation des plannings, impact sur la gestion du trafic
Services publics : Interruption des services aux citoyens, compromission de données sensibles, perte de confiance du public
Pour ne citer que ceux là.
D’où la nécessité de prendre au sérieux sa gestion d’incidents, cyber en particulier, et de l’aligner à une stratégie de sécurité adapté au besoin de sécurité de l’organisation déterminé à la suite d’une analyse de risques. Cependant un bon processus de gestion d’incident ne se valorise qu’en prenant en compte tout le cycle qui permet à l’entreprise d’apporter de la valeur ajoutée (le développement d’un produit, la mise en place d’une ligne industrielle, l’etc.) pour permettre d’allouer convenablement les efforts à fournir. Il faut donc prévenir l’incident.
Prévention d’incidents
La prévention dans la réponse à incident (préparation)
Lors de l’apparition (la détection) d’un incident de sécurité, nous devons lancer un ensemble de procédures nous permettant de résoudre ce dernier : la réponse à incident. Un processus de réponse à incident a pour objectif de “coordonner la détection, l'endiguement et la reprise après une attaque d’origine cyber ou un autre incident de sécurité au sein d'une organisation.” (Checkpoint). Les deux méthodologies de réponse à incident les plus connu sont ceux développées par me NIST et le SANS. Ils fournissent les bases et les standards nécessaires à la mise en place d’un plan de réponse à incident. Ces deux méthodologies placent comme première étape à un plan de réponse à incident la préparation.
Cette dernière est différente de la prévention dont nous parlions plus tôt de plusieurs manières :
Elle est incluse dans le processus de réponse à incident qui lui même fait partie des trois grandes cases dans lesquelles nous avons classifier les processus de sécurité en général, à côté de la prévention et de la détection.
Elle consiste entre autre à
Définir la portée et les objectifs du plan de RI
Identifier les parties prenantes qui doivent être impliquées dans le processus
Elaborer des procédures qui couvrent toutes les phases du RI
Identifier les risques de manière régulière pour considérer des mesures de sécurité appropriées.
Voici donc ce qu’est la préparation dans le cadre d’un plan de réponse à incident. La prévention plus largement est là pour nous guider dans la définition de notre stratégie de sécurité, elle doit inclure toute l’organisation et permet la mise en place de mesures de sécurité pour protéger les données de toute modification, destruction ou divulgation non autorisée, qu’elle soit accidentelle ou intentionnelle. (GIAC)
Prévenir les incidents en amont
Considérons que l'objectif de la sécurité est d'éviter qu'un incident survienne, la préparation à la réponse à un incident peut se faire avant même de réfléchir à ce qu'on est sensé faire en cas d'incident, c'est à dire prévenir toutes vulnérabilités avant même que notre produit soit publié (c’est le principe de l’approche shift-left).
La prévention inclus de manière historique la définition des politiques de sécurité, socle de la stratégie de sécurité d’une organisation, la sensibilisation des employés aux sujets de sécurité et la gestion des accès (authentification et autorisation). Avec une approche shift-left, nous incluons également la définition de mesures de sécurité au sein du cycle de développement.
Prévenir avec des processus sécurisé
Le cycle de développement communément appelé SDLC (Software Development Lifecycle), est un ensemble de phase décrivant les processus nécessaire à la définition, le développement, la validation et le déployer d’un logiciel. Cela inclus aussi bien les applications web, les interfaces en ligne de commandes, les configurations d’Infrastructure as Code et autres. C’est la base de la plupart des méthodologies que nous connaissons et se compose en général de 6 grandes phases.
En incluons donc les besoins en sécurité pas qu’à la définition de notre projet, mais à chacune des étapes de ce cycle et de manière itérative, nous obtenons donc un cycle de développement sécurisé, autrement dit SSDLC. Le SSDLC, Secure Software Development Lifecycle, est la mise en place des pratiques de sécurité (automatisées) au sein des processus de développement.
En mon sens, le SSDLC est là pour apporter un plus à une stratégie de sécurité défini en amont et renforce la posture de sécurité globale de l’organisation. Il ne permet pas de répondre à tous les besoins de sécurité à lui seule.
Nous avons abordé ici la sécurité au sein du cycle de développement comme moyen d’améliorer sa prévention d’incidents. Cependant la même logique peut être appliqué à d’autres secteur, comme mon exemple précédent sur la conception de ligne industrielle notamment en évaluant les risques de sabotage ou d’espionnage industriel avant de choisir les protocoles de communication. Evidemment dans le secteur industriel, où les systèmes (OT/IT) sont souvent critiques et interconnectés, cette approche permet également de réduire les risques, les coûts et les vulnérabilités.
De nos jours nous parlons vaguement du concept de “Security by Design” comme on peut parler d’intégration d’IA (LLM) à une plateforme en ligne (analogie que je ne vais pas développer). Très proche du shift-left, ces deux approches portent le même message, l’objectif est d’intégrer la sécurité dès la conception d'un système, d'une application ou d'un produit, plutôt que de l'ajouter a posteriori comme une couche supplémentaire. Cela de manière profonde et pas superficielle (dans chaque service, à chaque processus et à toute reflexion).
Tout cela permet de prévenir les incidents en amont et éviter la surcharge de procédure de dernière minute en cas d’incidents ou en cas de manquement.
Conclusion
Pour finir, il est important de noter le schema qui se dessine. Historiquement, la sécurité n’a pas toujours été un sujet important au sein des organisations. Aujourd’hui cela se paie avec des systèmes d’informations vulnérables aux failles qui deviennent de plus en plus vulgarisées. Pour “guérir” de ces maux, la politique de certaines organisations est d’appliquer des pansements sans prendre le serum nécessaire. Les nouvelles visions vise plutôt à se faire “vacciner” pour ne pas avoir besoin de “guérir”. Le coût moyen d’un incident de sécurité pour une entreprise est de 4,45 millions de dollars (IBM, 2023), alors que des mesures préventives coûtent bien moins cher. Assurément, la prévention limite les dommages irréversibles comme des pertes humaines, de données ou de réputation.
Ainsi il est préférable de prévenir que de guérir. Idéalement nous pourrions appliquer une loi de pareto à ce que nous venons d'évoquer : 80% de nos efforts dans la prévention d'incidents et 20% dans gestion de nos processus, comprendre également détection et réponse. Effectivement même une entreprise mature dans ses pratiques de sécurité aura toujours des aspects d'amélioration à placer dans sa prévention. Toutefois une entreprise est une structure complexe et ne peux pas toujours répondre aux "idéaux" théoriques d'où l'importance de l'effort porté à l'amélioration continue.
Retenons donc que le risque n'est que ce que nous ne voyons pas. Gérer et répondre c'est réagir à ce que nous voyons. Prévenir c'est mettre des barrière contre ce que nous ne voyons pas pour que nous ne le voyons jamais. Mieux prévenir c'est ajouter de petites barrières en plus de celles qui existent déjà, de manière minutieuse et à chacune de nos habitudes, pour que ce que nous ne voulons jamais voir s'éloigne même de nos angles morts.
