Principales approches pour une gestion et une hiérarchisation efficaces des risques de sécurité

Il n’existe pas de moyen simple d’être sûr à 100 %. Et même s’il est possible de renforcer votre sécurité, il n’y a certainement pas qu’une seule façon d’y parvenir. « Le plus sûr, c’est de ne rien faire » est un bon cliché, mais en matière de sécurité logicielle, c’est presque toujours faux. Dès la première ligne de code que nous écrivons, le point de non-retour est franchi : nous avons introduit un risque de sécurité qu’il faut gérer.

La « gestion des risques » est un terme générique qui englobe une grande variété d’approches. Je crois fermement à l’importance de nommer les choses : il est plus facile d’être efficace quand on peut expliquer (et mesurer) clairement ses objectifs. Dans cet article, nous allons présenter quelques approches clés et, parce que chez Snyk nous croyons fermement à l’importance de passer à l’action, vous proposer également des moyens de les mettre en œuvre.

Une remarque avant d’examiner les différentes approches. Le niveau de risque de sécurité associé à une vulnérabilité ne peut être déterminé qu’après avoir pris en compte TOUS les facteurs qui l’influencent : gravité, exploitabilité, type de vulnérabilité, accessibilité, ainsi que d’autres facteurs liés à l’environnement et à l’activité. Calculer le risque avec précision et sans faux positifs est un défi de taille. Dans cet article, nous partons du principe que vous en êtes capable (et si ce n’est pas le cas, sachez que Snyk peut vous aider !).

Approches de la gestion des risques de sécurité

Approche A : centrée sur le risqueDans cette approche, le risque est votre principale préoccupation. S’il est élevé, la vulnérabilité doit être corrigée AU PLUS VITE, quel que soit l’effort nécessaire. En revanche, un risque faible vous préoccupe moins, même si la correction demande peu d’efforts.

Approche B : centrée sur le retour sur investissementTout est une question d’efficacité : le temps, c’est de l’argent ! Pour choisir la marche à suivre, vous accordez la priorité au rapport entre l’effort nécessaire et le gain attendu. Un risque moyen facile à corriger ? Avec plaisir ! Un risque élevé très difficile à corriger ? Peut-être pas tout de suite. Si nous attendons un peu, la vulnérabilité sera peut-être plus facile à corriger.

Approche C : axée sur les tendances généralesLes détails vous importent moins que la tendance générale, c’est-à-dire la surface d’attaque totale. Veillons à ce que les équipes aient de moins en moins de vulnérabilités au fil du temps. Qu’elles corrigent trois vulnérabilités élevées ou quatre moyennes cette semaine n’a pas vraiment d’importance, tant que nous corrigeons les problèmes et réduisons la surface d’attaque. (Ne poussez pas cette logique à l’extrême :) Cela ne signifie pas qu’il faut corriger toutes les vulnérabilités faibles et ignorer celles qui sont critiques !)

Approche D : conformitéParfois, il faut simplement faire le nécessaire. La conformité prend de nombreuses formes, de l’audit de sécurité annuel réalisé par un tiers au « badge » que nous voulons afficher. Cette approche diffère de l’approche A, car elle applique des critères plus stricts à certaines propriétés. Si, dans l’approche A, seul le risque critique vous importe, ici, on peut vous demander de corriger toutes les vulnérabilités de gravité critique, même après les avoir évaluées et alors que vous êtes certain qu’elles ne présentent aucun risque (par exemple, parce qu’elles ne sont pas accessibles dans votre contexte).

Quelle approche de la gestion des risques de sécurité choisiriez-vous ?

Vous avez ces deux vulnérabilités. Laquelle corrigeriez-vous, et pourquoi ?

Approche A : Corrigez le risque critique. Pour le risque moyen, faites comme bon vous semble.

Approche B : Corrigez le risque moyen. Espérez que le risque critique sera bientôt plus facile à corriger. Et finissez par le corriger lui aussi.

Approche C : Ne vous posez pas trop de questions : corrigez-en une maintenant et l’autre plus tard. L’essentiel est de réduire la surface d’attaque.

Approche D : Voyons comment définit ces deux vulnérabilités et quel seuil est requis.

Adopteriez-vous plusieurs approches, ou vous demandez-vous simplement laquelle est « la bonne » ?

Il n’y a pas de mauvaise approche, mais plusieurs chemins peuvent vous mener à une meilleure sécurité. Comme le dit le chat du Cheshire dans Alice au pays des merveilles : « Tout dépend beaucoup de l’endroit où vous voulez aller. »

1. Si vous intégrez une nouvelle équipe, nous vous conseillons l’approche B, axée sur le retour sur investissement et les gains rapides. C’est une bonne façon de convaincre les développeurs et d’éviter de leur demander des efforts trop importants avant qu’ils ne soient impliqués.

2. Si vous travaillez avec une équipe expérimentée en sous-effectif sur une tâche urgente, l’approche A sera peut-être préférable : vous pourrez ainsi l’aider à rester concentrée tout en réduisant les risques par ordre de priorité.

3. Si vous préparez votre audit annuel de conformité, l’approche D est votre alliée. Vous savez sans doute à quoi vous attendre : autant prendre les devants !

4. Si vous êtes RSSI dans une grande entreprise, l’approche C vous intéressera peut-être surtout (mais votre équipe AppSec gagnerait sans doute à adopter une autre approche).

Chacune a ses avantages. Choisissez celle qui vous convient le mieux, et laissez Snyk vous accompagner !

Comment Snyk vous aide à gérer les risques de sécurité

En réalité, aucune des entreprises avec lesquelles nous échangeons ne s’en tient à une seule approche. Les pratiques des équipes varient selon leur expérience, le type de projet et leur charge de travail, entre autres. Et même si le RSSI et les équipes AppSec peuvent partager une approche, la faire adopter de manière cohérente par toutes les équipes reste un défi dans n’importe quelle entreprise.

Snyk vous aide, vous et vos équipes, à passer de la théorie à l’action face aux vulnérabilités. En apportant le contexte nécessaire à une évaluation précise du risque dans votre projet, Snyk vous aide à hiérarchiser intelligemment les problèmes.

Voici un aperçu rapide de quelques fonctionnalités utiles de Snyk :

• Un service n’est pas accessible de l’extérieur ? Attribuez-lui l’attribut « interne » et utilisez une stratégie de sécurité pour reclasser en faible la gravité d’une vulnérabilité DDoS.

• La fonctionnalité Maturité des exploits de Snyk vous indique si un exploit existe, un élément qui peut fortement influer sur le risque réel.

• Snyk analyse les chemins d’exécution du code appelé pour déterminer si vous avez affaire à des vulnérabilités atteignables ou non.

Ce ne sont là que quelques-uns des facteurs utilisés par Snyk pour vous aider à hiérarchiser les problèmes. Chacun fournit des données précieuses, mais ce dont vous avez besoin, c’est d’intelligence. Snyk vous la fournit notamment grâce à son relativement nouveau Score de priorité Snyk. En s’appuyant sur les informations ci-dessus et sur d’autres facteurs, comme l’ancienneté de la vulnérabilité et la disponibilité d’un correctif, Snyk attribue un score de 0 à 1 000 : plus le score est élevé, plus la vulnérabilité doit être corrigée en priorité. Vous pouvez ainsi consacrer vos efforts de sécurité dans l’ordre qui vous apportera le plus de valeur en matière de réduction des risques, tout en comprenant suffisamment le calcul du score pour pouvoir lui faire confiance.