Présenter les risques AppSec à votre RSSI

Pour les responsables de la sécurité, bâtir une relation de travail solide avec votre RSSI dépend souvent de votre capacité à fournir des rapports clairs et des synthèses concises des risques. Vos rapports aident les RSSI à remplir une responsabilité essentielle de leur fonction : traduire un jargon de sécurité très technique en recommandations concrètes qui réduisent les risques et renforcent la maturité en matière de sécurité dans toute l’organisation. Et en cas de violation ou de faille zero-day, ce sont parfois les RSSI qui doivent annoncer la mauvaise nouvelle.

Pourtant, la complexité, la taille et la nature dynamique croissantes des applications modernes compliquent la visibilité des équipes de sécurité sur l’ensemble de leurs applications et la production de rapports pertinents sur les risques pour l’entreprise. Elles finissent par se concentrer sur le nombre de problèmes de sécurité détectés et résolus. Cette approche réactive laisse de nombreuses zones d’ombre : elle n’aide pas les RSSI à évaluer les progrès du programme de sécurité applicative ni à repérer les principaux axes d’amélioration.

Pour présenter correctement les risques prioritaires à un RSSI, les équipes AppSec doivent avoir une vue d’ensemble de leur paysage de sécurité applicative, y compris de tous les différents actifs basés sur le code utilisés pour le constituer.

Améliorez la visibilité globale sur la sécurité de vos applications

La visibilité est essentielle pour prendre des décisions éclairées en matière de risques et d’allocation des ressources. Aujourd’hui, la plupart des outils de sécurité applicative axent leurs rapports sur les problèmes détectés et résolus, souvent en s’appuyant sur une forme de priorisation intégrée qui manque de vision globale. Cette approche de la gestion des risques a fait ses preuves par le passé, mais les simples scores de vulnérabilité et le décompte des problèmes ne suffisent plus.

Il faut garder à l’esprit que les entreprises peuvent aujourd’hui compter des centaines d’applications et autant d’équipes de développement, chacune avec sa propre chaîne logistique logicielle. Cette chaîne comprend tous les outils utilisés pour créer, compiler, empaqueter et déployer l’application. Il s’agit d’un réseau complexe de dépendances directes et transitives qui peut paralyser votre application si une vulnérabilité est exploitée.

En bref, une gestion des risques efficace nécessite du contexte. Les applications suivantes présentent davantage de risques pour les entreprises :

• En cours de déploiement

• Accessibles depuis Internet

• Critiques pour l’activité

• Contiennent des vulnérabilités faciles à exploiter qui permettent à un tiers de prendre le contrôle ou d’accéder à des données

• Et, dans le pire des cas, les applications inconnues, c’est-à-dire celles sur lesquelles nous n’avons aucune visibilité, ou une visibilité partielle. Le Shadow IT est un exemple d’application inconnue.

Même si l’ordre ou la priorité de ces facteurs de risque varie d’une équipe à l’autre, nous savons qu’il nous faut accéder à ces données contextuelles pour prendre des décisions éclairées sur la priorisation des vulnérabilités. Une fois les risques correctement mesurés, la question devient : « Que faisons-nous pour les traiter dans le cadre d’un programme coordonné ? », plutôt que de réagir simplement à chaque signalement d’un problème critique.

Quand nous parlons de visibilité, nous parlons de deux choses. Premièrement, les équipes AppSec ont besoin d’une solution qui leur offre une visibilité complète sur leur base de code et détecte les nouveaux actifs au fur et à mesure de leur ajout. Deuxièmement, cette solution doit replacer toutes les vulnérabilités détectées dans le contexte d’un modèle de risque pertinent, qui exploite la visibilité complète sur les actifs. Les RSSI sont plus efficaces lorsque les équipes AppSec leur fournissent une visibilité étendue et contextualisée.

Comment les risques sont introduits

Comprendre l’origine des risques aide à contextualiser et à prioriser les investissements dans un programme AppSec. Un auditeur ou un attaquant ne se soucie pas de la manière dont un problème s’est retrouvé dans un système de production. Si un problème exploitable est accessible aux attaquants, en tant que professionnel AppSec, vous devez partir du principe que quelqu’un cherche à en tirer parti. Mais lorsque vous réfléchissez à la gestion de votre programme AppSec, la manière dont les risques sont introduits est très instructive.

Une hausse du nombre de problèmes ouverts peut immédiatement inquiéter. Mais en examinant de plus près les tendances dans les catégories suivantes, on obtient une image plus claire :

• Référentiel : les problèmes du référentiel sont ceux détectés lorsque le code commence à être surveillé pour la première fois. Dans un monde idéal, le code nouvellement importé ne présenterait aucun problème, mais nous savons que c’est rarement le cas. Une hausse des problèmes du référentiel témoigne d’une meilleure visibilité, signe d’une couverture accrue (nous y reviendrons).

• Évitables : ces problèmes auraient pu être évités par les développeurs si l’entreprise avait mis en place des outils et des processus de décalage de la sécurité vers la gauche dans le SDLC. Il peut s’agir de tests en environnement de développement local, dans le cadre du workflow de PR ou lors de la compilation. Mais si les contrôles de sécurité ne sont pas en place ou sont contournés, des problèmes à risque peuvent se retrouver en production. Les développeurs perdent alors beaucoup de temps et d’énergie à les corriger au lieu de créer davantage de valeur pour l’entreprise. L’apparition de problèmes évitables représente une formidable occasion pour les équipes de sécurité d’investir dans les outils et les processus là où ils sont le plus nécessaires.

• Non évitables : les problèmes non évitables résultent de la publication de nouvelles vulnérabilités. Votre code n’a peut-être pas changé, mais des facteurs externes rendent le code existant de votre pile vulnérable. L’annonce d’une vulnérabilité zero-day à haut risque peut révéler des dizaines, voire des centaines de nouveaux problèmes critiques qui nécessitent une attention particulière.

Même si aucune de ces catégories n’est plus importante qu’une autre du point de vue du risque absolu, le fait de répartir les risques entre ces trois groupes permet aux équipes AppSec de dégager des tendances au fil du temps. Elles peuvent ensuite les présenter aux RSSI pour les aider à orienter les comportements que les équipes doivent adopter afin d’améliorer le programme AppSec de manière stratégique et, au final, de réduire les risques.

Mesurer votre programme AppSec

La visibilité est absolument essentielle pour les équipes AppSec et la priorisation des risques, mais elle ne raconte qu’une partie de l’histoire. Les RSSI veulent également disposer d’informations qui les aideront à prendre des décisions stratégiques concernant leur programme AppSec. Par exemple, savoir comment les différentes équipes progressent vers leurs objectifs de maturité en matière de sécurité et de réduction des risques peut aider un RSSI à prendre des décisions éclairées concernant la formation et l’affectation des ressources.

Les équipes de sécurité doivent prendre en compte quatre catégories essentielles lorsqu’elles préparent des rapports destinés aux RSSI et aux responsables de la sécurité. Ce cadre les aide à obtenir une vision globale de leur programme de sécurité applicative, en mettant en évidence les réussites et les possibilités d’optimisation, avec des prochaines étapes claires et concrètes.

Exposition

L’exposition représente le risque potentiel pour la surface de vos applications. Cette vue inclut les problèmes ouverts susceptibles d’entraîner des incidents de sécurité ou des violations. L’exposition augmente lorsque de nouveaux problèmes sont introduits dans votre code, que la gravité ou le niveau d’exploitabilité des vulnérabilités s’accroît, ou que de nouvelles vulnérabilités sont détectées. Elle est gérée ou réduite lorsque les problèmes sont corrigés et que des évaluations déterminent que le risque n’est pas applicable ou qu’il est acceptable pour l’entreprise. L’exposition peut être évaluée à un moment précis (par exemple, pour un audit) ou suivie dans le temps afin de montrer les progrès réalisés, espérons-le.

Gestion

Les risques ne disparaissent pas d’eux-mêmes. Vous pouvez déployer les scanners les plus sophistiqués et les plus performants et mettre des outils à la disposition des équipes de sécurité et d’ingénierie. Mais sans action sur les risques existants, l’exposition continuera de croître. Mesurer la gestion de vos problèmes permet de comprendre avec quelle efficacité votre entreprise trie, évalue et corrige les risques qui atteignent vos applications.

Comprendre quelles applications font l’objet d’actions régulières et efficaces pour corriger ou accepter les risques permet de déterminer ce qui fonctionne bien. Cela peut s’expliquer par une bonne relation avec la sécurité ou par un responsable de l’ingénierie qui réserve un certain pourcentage du temps de sprint à la correction des problèmes de sécurité. Là où la régularité fait défaut ou où les risques ne sont pas corrigés, une occasion d’investir clairement se présente. Les différents secteurs de votre entreprise peuvent nécessiter des niveaux d’attention distincts, et vous devrez peut-être évaluer différemment leur gestion des risques.

Prévention

La prévention mesure la capacité de votre entreprise à empêcher les problèmes d’atteindre vos systèmes de production. Comme indiqué plus haut, tous les problèmes ne peuvent pas être évités. Mais si les outils que vous utilisez pour sécuriser votre SDLC connaissent une vulnérabilité à une date donnée, les développeurs devraient pouvoir s’en servir pour détecter et corriger le problème avant qu’il n’atteigne la production. L’absence de prévention entraîne non seulement une hausse de l’exposition, mais aussi un important gaspillage de temps pour les développeurs.

Couverture

La couverture est l’un des aspects les plus fondamentaux de la sécurité, et votre RSSI y accorde une grande importance. Parmi tous les actifs — c’est-à-dire les composants, entités ou activités de l’environnement de sécurité applicative qui nécessitent des contrôles de sécurité — qui constituent vos applications, combien sont sécurisés, et à quel niveau ? Cela peut inclure différents types d’analyse (SCA, SAST, DAST, etc.), la fréquence de la surveillance, la robustesse des contrôles tout au long du SDLC, et bien plus encore. Vous pouvez être satisfait du niveau d’exposition aux risques, de l’efficacité de vos équipes dans la correction des problèmes et des résultats de vos efforts de prévention, mais si vous n’avez de visibilité que sur les deux tiers de vos applications, êtes-vous vraiment bien protégé ?

Poser les bonnes questions

Jusqu’à présent, les rapports de Snyk visaient à aider les entreprises à détecter et à prioriser les problèmes en fonction d’indicateurs clés, comme le risque. Cette approche tactique permet aux équipes d’agir rapidement pour résoudre les problèmes les plus menaçants. Avec Enterprise Analytics, les clients Snyk bénéficient désormais aussi d’un accompagnement stratégique pour mesurer et développer leur programme AppSec.

Analyses intergroupes

Les utilisateurs peuvent filtrer au niveau du groupe ou de l’organisation

Enterprise Analytics permet désormais d’obtenir une vue transversale des groupes dans Snyk. Cette capacité élargie de création de rapports permet aux utilisateurs de surveiller l’activité dans l’ensemble de leur environnement Snyk, quel que soit le groupe. En ventilant les informations par groupe, les responsables de la sécurité peuvent cibler les équipes qui ont le plus besoin d’efforts de correction et de formation.

Partager les analyses avec les parties prenantes

Démontrer une gestion adéquate des risques est essentiel pour vos investisseurs et les parties prenantes de votre entreprise. Les RSSI et les responsables de la sécurité doivent rendre compte des KPI et des tendances en matière de risques, ainsi que montrer comment leurs efforts traitent les risques existants et les réduisent au fil du temps.

Grâce à Enterprise Analytics, les RSSI peuvent désormais facilement rendre compte des tendances en matière de risques, notamment l’exposition, la gestion, la prévention et la couverture, et mettre en avant les réussites ainsi que les pistes d’amélioration. Par exemple, une hausse des problèmes évitables peut indiquer que certaines équipes n’ont pas pleinement adopté les bonnes pratiques Snyk.

Snyk révèle une hausse des problèmes évitables dans la nouvelle fonctionnalité de reporting, Enterprise Analytics.

On observe ici une hausse des problèmes évitables vers la fin novembre, qui s’est stabilisée au 3 décembre. Dans leur rapport au RSSI, les équipes peuvent montrer à quelle vitesse elles ont pu :

1. Repérer l’équipe qui avait besoin d’un accompagnement supplémentaire pour adopter Snyk (Financial Org)

2. Former l’équipe aux produits afin de l’aider à utiliser les PR de correction et les automatisations Snyk pour réduire les vulnérabilités évitables,

3. Et, au final, ramener la hausse au niveau de référence (zéro problème).

Snyk facilite le partage des conclusions avec les parties prenantes grâce au bouton Copy URL situé en haut à droite de la page de l’application, ou en permettant d’exporter les rapports au format PDF ou CSV.

« Adopter Snyk permet à Applied Systems d’aligner ses objectifs de sécurité et de développement afin d’apporter davantage de valeur à ses clients. Snyk accélère notre processus de développement et permet à nos ingénieurs de disposer des meilleures informations possibles pour renforcer la sécurité de notre portefeuille de produits. »

— Tanner Randolph, RSSI chez Applied Systems

Commencez à rendre compte des risques

Pour présenter les risques à votre CISO, vous devez : 1) disposer d’une visibilité maximale sur la sécurité de vos applications, 2) comprendre comment et où des risques peuvent être introduits, 3) savoir comment mesurer l’exposition, la gestion, la prévention et la couverture de votre programme AppSec, et 4) pouvoir regrouper ces informations à l’intention des dirigeants. Pour y parvenir, vous aurez besoin des bons outils.

Enterprise Analytics est la dernière d’une série d’annonces qui témoignent de l’engagement de Snyk à offrir à ses clients une visibilité et une analyse de premier ordre de leurs données applicatives. Enterprise Analytics est disponible en version bêta pour tous les clients Snyk disposant de l’offre Snyk Enterprise. Pour commencer à utiliser ces nouvelles fonctionnalités d’analyse, il vous suffit d’en demander l’accès à votre représentant Snyk.

Si vous découvrez Snyk, demandez une démo avec un expert technique pour démarrer.