Pourquoi le triage pourrait disparaître

S’il y a un aspect de la sécurité qui peut être amélioré dans son ensemble, c’est bien sa réputation de ralentir les organisations.

L’un des principaux responsables de cette réputation est le « triage » : le processus qui consiste à vérifier si une alerte de sécurité concerne réellement votre organisation, à évaluer son impact potentiel et à déterminer comment y remédier.

Dans cet article, nous allons examiner pourquoi le triage peut rapidement devenir un goulot d’étranglement pour les organisations, et expliquer pourquoi nous devrions toutes et tous chercher à l’éviter pour nous concentrer sur la correction des vulnérabilités.

Un workflow de triage exemplaire

Essayons d’imaginer à quoi pourrait ressembler le workflow de triage d’une alerte signalant une nouvelle vulnérabilité.

Prenons l’exemple de la récente vulnérabilité RCE (Remote Code Execution, ou exécution de code à distance) dans Apache Struts, qui a finalement été exploitée dans l’affaire Equifax. On peut imaginer comment une entreprise de cette taille pourrait traiter une telle vulnérabilité :

• Une personne de l’équipe sécurité reçoit une alerte signalant l’existence de la vulnérabilité. Cela suppose qu’elle soit abonnée aux listes de diffusion pertinentes ou qu’elle utilise des outils capables de l’alerter (et qu’elle lise ces alertes) !

• Cette personne demanderait à l’un des ingénieurs de produire un rapport recensant toutes les applications du portefeuille de l’entreprise qui utilisent Apache Struts. Rien que cette étape représente un travail conséquent : gérer l’inventaire et la composition logicielle est un véritable défi, surtout pour les entreprises qui existent depuis longtemps. La tâche se complique encore pour celles qui ont réalisé des fusions et acquisitions et intégré, au fil des ans, plusieurs équipes utilisant différentes piles technologiques. Supposons néanmoins que l’organisation parvienne à produire un rapport répertoriant 100 projets utilisant Apache Struts.

• La personne de l’équipe sécurité créerait ensuite 100 tickets Jira, tous classés comme « critiques », et déclencherait la procédure d’urgence de l’entreprise pour que le problème soit traité immédiatement.

• Il faudrait suivre 100 ingénieurs de différents services de l’organisation et leur confier la correction de cette vulnérabilité.

Imaginons maintenant la situation du point de vue des développeurs. Le développeur travaille probablement sur une fonctionnalité à forte valeur ajoutée et souhaite la livrer rapidement pour respecter une échéance ou atteindre un objectif commercial important. Il s’agit néanmoins d’une alerte de sécurité importante, qu’il devra donc traiter. Voici les étapes qu’il devra suivre :

• Lire les informations sur la vulnérabilité concernée.

• Se documenter sur l’exécution de code à distance et sur la catégorie de vulnérabilité en question.

• Déterminer si la vulnérabilité concerne son application. Il devra peut-être rechercher l’exploit réel et vérifier s’il s’applique ou non.

• Rechercher les solutions possibles pour corriger cette vulnérabilité.

• Appliquer les corrections.

• Vérifier que la vulnérabilité a bien été supprimée.

Cela représente beaucoup de travail, dont une partie exige une véritable expertise en sécurité. Selon la lourdeur des processus internes de votre entreprise, le workflow de triage peut prendre des jours, des semaines, voire des mois. Et ce n’est pas une bonne chose.

Peut-on créer des logiciels pour faciliter le triage ?

Probablement ! Grâce à l’instrumentation du code et au machine learning, nous pourrions créer un système capable de vous indiquer si des chemins d’exécution utilisent la méthode vulnérable dans les bibliothèques concernées. Si le système est précis (c’est-à-dire qu’il génère peu de faux positifs et de faux négatifs), il pourrait réduire certaines étapes du triage pour les développeurs. Cependant, même si nous prouvons que la vulnérabilité est exploitable dans notre contexte, le développeur devra toujours trouver comment y remédier !

Un risque souvent plus grand apparaît lorsque les outils nous indiquent que, dans le contexte actuel, il n’existe peut-être pas de flux de données permettant une exploitation. Dans ces cas-là, de nombreuses organisations désactivent ou ignorent l’alerte, et c’est là que réside le danger.

Le fait que le code ne comporte peut-être pas de flux de données vulnérables aujourd’hui ne signifie pas que ce sera encore le cas demain. Une méthode qui n’est pas appelée aujourd’hui pourrait l’être après le prochain commit d’un développeur. Le développeur suivant n’aura probablement aucun moyen de savoir qu’une méthode vulnérable se cache dans la bibliothèque qu’il utilise, ni que l’alerte correspondante a été désactivée parce que cette méthode n’était pas appelée jusqu’à présent. Fonder votre posture de sécurité sur le principe que la méthode n’est pas appelée aujourd’hui relève presque de l’imprudence.

À y regarder de plus près, le triage n’est qu’une étape préalable à la correction des vulnérabilités. On y recourt parce que corriger les vulnérabilités est perçu comme difficile et exigeant. Mais au lieu d’utiliser des logiciels pour faciliter le triage, pourquoi ne pas tout simplement le contourner et automatiser les corrections ?

Les pull requests d’alerte de Snyk, c’est le top !

Lorsque vous ajoutez vos projets à Snyk, nous tenons à jour un inventaire précis et continu de toutes vos dépendances. Ainsi, lorsqu’une vulnérabilité importante comme la RCE d’Apache Struts est divulguée, nous pouvons vous en avertir en temps réel. Plus important encore, nous pouvons vous indiquer exactement quelles applications sont concernées. Lorsque vous connectez Snyk à votre gestionnaire de code source (comme Github, Gitlab ou BitBucket), nous pouvons aller encore plus loin et envoyer directement à vos dépôts concernés une pull request contenant la correction.

Pour supprimer la vulnérabilité de votre code, il vous suffit d’approuver la pull request. Corriger la vulnérabilité est la bonne chose à faire, que le code soit ou non exécuté aujourd’hui dans vos flux de données.

Non seulement l’ensemble du workflow de triage peut être remplacé par un simple clic sur le bouton « Accepter » de la pull request, mais cela réduit aussi le niveau d’expertise en sécurité nécessaire au sein de l’organisation pour appliquer les corrections. Une sécurité simple et rapide : plutôt sympa, non ?