La sécurité applicative axée sur les actifs : qu’est-ce que c’est et quels sont ses avantages ?

La plupart des stratégies de sécurité applicative visent à réduire le nombre de vulnérabilités : elles identifient les problèmes de sécurité tout au long du cycle de développement logiciel (SDLC) et les corrigent. Mais dans un environnement logiciel complexe, il est difficile de déterminer si chacune de ces vulnérabilités représente réellement un risque pour l’organisation ou s’il s’agit simplement d’une alerte redondante ou erronée. Par exemple, une erreur de configuration cloud dans un environnement sandbox n’aura peut-être pas d’incidence sur l’entreprise à long terme, car elle n’est pas liée aux applications stratégiques et est isolée par d’autres couches de sécurité. Chaque problème de sécurité nécessite du contexte pour comprendre le risque qu’il représente pour l’organisation. Cela a donné lieu à de nouvelles approches de la sécurité, ainsi qu’à de nouveaux outils pour les mettre en œuvre, sous la forme de l’ASPM.

Une approche axée sur les actifs envisage la sécurité sous l’angle métier et protège tous les actifs en fonction de leur usage prévu. Dans cet article, nous aborderons les notions fondamentales de la sécurité applicative axée sur les actifs, notamment :

• La définition d’un « actif »

• Le fonctionnement de la sécurité applicative axée sur les actifs

• L’importance de l’AppSec axée sur les actifs

• Comment réaliser une analyse des lacunes en sécurité applicative

• L’approche de Snyk en matière d’AppSec axée sur les actifs

Qu’est-ce qu’un actif ?

Un « actif » désigne tout composant, entité ou activité de l’environnement de sécurité applicative qui nécessite des contrôles de sécurité. Dans une chaîne d’approvisionnement logicielle classique, les équipes gèrent les types d’actifs suivants :

• code source

• dépendances

• images de conteneurs

• services

• points de terminaison

• hôtes

• équipes de développement

Qu’est-ce que la sécurité applicative axée sur les actifs ?

Une approche axée sur les actifs consiste à envisager toutes les activités de sécurité applicative sous l’angle métier. Ces informations contextuelles permettent aux équipes de filtrer les données de sécurité et de protéger ce qui compte le plus. La sécurité applicative axée sur les actifs rend également les activités de sécurité habituelles, comme la gestion des secrets, l’analyse des vulnérabilités et le DevSecOps, bien mieux adaptées aux besoins et aux priorités de l’entreprise.   

Une approche de sécurité applicative axée sur les actifs comporte trois étapes : cartographier les actifs pour déterminer le périmètre de l’équipe AppSec, examiner les problèmes à la lumière de cette cartographie et prioriser les contrôles de sécurité en fonction de ces informations contextuelles approfondies.

Pourquoi la sécurité applicative axée sur les actifs est-elle importante ?

Aujourd’hui, de nombreuses équipes sont dépassées et déconcertées par le nombre considérable de vulnérabilités présentes dans leurs environnements. Une approche axée sur les actifs simplifie l’AppSec en évaluant les risques de manière pertinente, plutôt qu’en traquant les vulnérabilités uniquement selon leur niveau de gravité. Cette approche de la sécurité de la chaîne d’approvisionnement logicielle profite aux équipes suivantes :

Dirigeants

L’AppSec axée sur les actifs fournit aux dirigeants des données pertinentes et contextualisées pour prendre des décisions et évaluer les risques. Par exemple, un rapport indiquant que l’environnement présente « 200 vulnérabilités critiques » n’est pas exploitable par l’équipe dirigeante. À l’inverse, une approche axée sur les actifs se concentre sur les priorités globales et présente des informations telles que : « Notre actif principal est exposé à cinq risques différents. » Ces précisions permettent aux dirigeants de cibler les initiatives qui auront un réel impact, au lieu de réagir à une liste interminable de problèmes de sécurité.

Équipes de sécurité applicative

Les équipes AppSec ne peuvent pas protéger ce dont elles ignorent l’existence et sont constamment en sous-effectif par rapport aux développeurs. En donnant la priorité à la découverte des actifs et à la gestion de l’inventaire, une approche axée sur les actifs leur permet de repérer les lacunes en matière de visibilité et de couverture des outils. Elle aide également les équipes à identifier les actifs critiques pour l’entreprise et à leur attribuer automatiquement une priorité, ce qui leur fait gagner du temps et leur permet de se concentrer sur les problèmes qui comptent vraiment pour leur activité. 

Développeurs 

Aujourd’hui, les développeurs sont responsables de plusieurs domaines de la chaîne d’approvisionnement logicielle, notamment l’infrastructure cloud, les conteneurs, les ressources tierces et le code développé en interne. Compte tenu de l’étendue de leurs responsabilités, ils ont besoin d’un soutien pour corriger les différents problèmes de sécurité tout au long du SDLC. 

Sans approche axée sur les actifs, ces responsabilités deviennent très difficiles à gérer pour les développeurs. Ils ne savent pas où se trouve un problème de sécurité : il peut concerner une application stratégique à sécuriser au plus vite ou une application interne qui ne contribue pas à la surface d’attaque. De plus, les développeurs ignorent si leurs contrôles de sécurité signalent la même vulnérabilité sous deux angles différents (par exemple, dans le cloud et dans l’IaC) et ne savent pas où intervenir pour corriger la cause première. Cette approche sans contexte entraîne une lassitude face aux alertes et de la frustration.

Une approche axée sur les actifs allège considérablement cette charge de responsabilité en permettant aux développeurs de traiter les problèmes de sécurité dans leur contexte. Ils peuvent ainsi identifier en un rien de temps le responsable de l’actif concerné et appliquer rapidement des correctifs ciblés. Cet état d’esprit axé sur les actifs permet également aux équipes AppSec et aux développeurs de parler le même langage en matière de sécurité.

Analyse des lacunes en sécurité applicative

Une analyse des lacunes aide les équipes à comprendre quels actifs sont déjà protégés et où ajouter des contrôles de sécurité. Elle leur permet d’affecter des ressources aux projets les plus importants et d’éviter de perdre du temps sur des activités redondantes ou sans pertinence. Une analyse des lacunes en sécurité applicative peut inclure les tâches suivantes :

Inventorier les actifs

Vos équipes doivent savoir quels actifs leur appartiennent et les classer selon leur contexte. L’automatisation est souvent la meilleure solution pour suivre tous les actifs existants.

Comprendre les contrôles existants

Que fait déjà votre équipe pour protéger les actifs ? Pour répondre à cette question, vos équipes doivent analyser tous les contrôles de sécurité existants, notamment des activités comme les revues de code et les tests d’intrusion, des outils comme les tests statiques de sécurité des applications (SAST) et les solutions d’analyse de la composition logicielle (SCA), ainsi que des initiatives comme les programmes de référents en sécurité et les formations au code sécurisé.

Mesurer les résultats

Après avoir dressé la liste exhaustive des contrôles de sécurité existants, les équipes doivent évaluer chacun d’eux en fonction de sa fonction et de son objectif. Par exemple, vous pouvez mesurer le taux de réussite d’un outil d’analyse des vulnérabilités en calculant le pourcentage de vulnérabilités critiques corrigées dans les applications essentielles. Vous pouvez également mesurer le succès d’un programme de référents en sécurité en analysant son taux d’adoption.

Le modèle de Snyk ASPM fondé sur les actifs

Notre approche de l’ASPM permet aux développeurs de travailler rapidement tout en restant protégés. La complexité des applications actuelles exige une priorisation pertinente pour les sécuriser sans ralentir les pipelines de développement. La sécurité applicative fondée sur les actifs permet de hiérarchiser les contrôles de sécurité selon le contexte métier et les risques potentiels dans le monde réel, plutôt qu’en fonction du seul nombre ou niveau de gravité des vulnérabilités. Elle facilite également la mise en place de garde-fous et de workflows automatisés par les équipes de sécurité. 

Pour obtenir ce niveau de contextualisation, Snyk aborde l’ASPM en trois étapes :

• Découvrir et classer les actifs à l’aide de politiques qui tiennent compte de la criticité métier de chacun.

• Mettre en place des contrôles de sécurité en fonction de la classification de chaque actif.

• Prioriser les problèmes liés aux actifs qui présentent un risque plus élevé pour l’organisation.

Pour en savoir plus sur la mise en œuvre d’une stratégie de sécurité applicative avec Snyk, consultez notre guide complet de l’AppSec.