Mesurer la sécurité des applications natives du cloud
Les applications modernes natives du cloud, de même que la culture et les pratiques DevSecOps utilisées pour les gérer, impliquent de nouveaux défis pour la mesure de la sécurité dans un environnement déjà complexe.
Historiquement, la sécurité était mesurée sur une base régulière mais uniquement à des moments précis. Mais à mesure que les organisations se sont modernisées, notamment avec l'adoption du cloud et des pratiques DevSecOps, les entreprises ont accéléré le rythme de leurs déploiements.
En une seule journée, le niveau de sécurité peut complètement changer et rendre les mesures précédemment effectuées éphémères voire obsolètes. C’est la raison pour laquelle il est aujourd’hui nécessaire d’intégrer la mesure de la sécurité dans un processus continu. Mais comment assurer une mesure efficace de la sécurité au sein des organisations ?
Intégrer les bonnes mesures…
En plus de la nécessité d’intégrer la mesure du niveau de sécurité à un processus continu, le choix des manières de la mesurer et leur compréhension est primordial. Par exemple, le nombre total de vulnérabilités ouvertes dans les applications des équipes ou dans des parties désignées d'une application semble être une bonne mesure de la sécurité des applications, mais elle n'est pas toujours pertinente. En effet, une équipe qui signale peu de vulnérabilités n’est pas forcément plus performante qu’une équipe qui en signale beaucoup plus. La nuance réside à la fois dans la capacité d’une équipe à détecter des vulnérabilités, mais aussi dans le niveau de criticité de ces dernières. Si de nombreuses vulnérabilités sont détectées mais qu’elles sont de bas niveau, les conséquences de leur exploitation par des cybercriminels n’auraient que peu d’effet, alors qu’une seule vulnérabilité de haut niveau pourrait entraîner de gros problèmes de sécurité pour l’organisation. En termes de criticité, il faut accorder beaucoup plus d'importance à la résolution des vulnérabilités de haut niveau qu'à celles de nature plus superficielle.
Une autre mesure utile est le temps pris pour remédier aux vulnérabilités. Si elle peut être intéressante car elle permet de mesurer le travail fourni par les équipes, il convient de faire preuve de prudence dans son utilisation. Certaines vulnérabilités peuvent être corrigées très rapidement, là où d'autres peuvent nécessiter un travail beaucoup plus important. Ainsi, alors qu'un développeur peut corriger 20 vulnérabilités en une seule matinée, un autre peut n'en corriger qu'une seule, mais il aura dû travailler beaucoup plus dur et de manière plus créative.
Le management de l’organisation a besoin d'un aperçu fiable et compréhensible de l'état de sécurité des applications. Cela lui permet de prendre des décisions basées sur des données, de reconnaître les hautes performances et de comprendre où des investissements supplémentaires pourraient être nécessaires.
… et les rendre plus concrètes
Pour faire face au rythme dynamique du développement logiciel moderne, les visualisations de données en temps réel doivent remplacer l'idée de scores instantanés. Les équipes doivent être capables de fournir une série de mesures et de comprendre la relation entre ces chiffres : la proportion de vulnérabilités de bas niveau, par exemple, aura un impact sur la proportion de problèmes de haut niveau, et probablement aussi sur le nombre total. L'inventaire des mesures de sécurité de l'organisation comprendra chacun de ces chiffres, ainsi que le temps moyen de remédiation, les données fournies par les outils SAST (Test Statique de Sécurité des Applications) et DAST (Test Dynamique de Sécurité des Applications), le nombre de commits et d'autres sources.
Il est aussi nécessaire de comprendre les relations entre ces chiffres et d’éliminer les doublons : en disposant déjà du nombre de vulnérabilités de bas et de haut niveau, avoir une mesure distincte pour le nombre total de vulnérabilités n'apporte aucune valeur ajoutée et peut même obscurcir les détails nécessaires à la compréhension.
Visualiser le flux pour un meilleur niveau de sécurité
Grâce à des outils comme le diagramme de boucle causale, il est possible de représenter les relations entre les chiffres, en visualisant la nature continue et dynamique des informations. Pour la mesure de la sécurité, il faut représenter la manière dont les changements dans les éléments de données se répercutent les uns sur les autres au fil du temps. De plus, le diagramme de boucle causale ayant un temps de vie illimité, il est possible d’y ajouter de nouveaux nœuds et de nouvelles boucles, et donc, de nouveaux éléments de données provenant de nouvelles technologies. Il devrait ainsi être plus facile de voir les mesures les plus utiles. Commencer en déterminant où se trouvent les doublons, puis en recherchant dans le diagramme les nœuds qui n'ont que des relations causales entrantes, mais aucune, ou peut-être une seule, relation causale sortante, permet de déceler un élément de données de haut niveau.
Pour finir, il faut pondérer la valeur de ces éléments les plus importants pour obtenir un score global qui pourrait être visualisé sous la forme d'une ligne de tendance. Malheureusement, il n'existe pas de formule universelle à copier ici : chaque organisation est différente en termes de prise de risque, de composition de l'environnement et d'approche globale de ses programmes de sécurité.
Une fois ce système de mesure de la sécurité créé, il est essentiel que les décideurs comprennent les composantes des scores afin de pouvoir adapter les mesures au besoin. Enfin, il est important de réaliser que l'important n'est pas d'atteindre un score en particulier, mais plutôt que la sécurité soit un processus continu. Il n'y a pas de point final ou de score suffisant, il faut seulement s’efforcer d’améliorer constamment la sécurité pour répondre aux menaces en perpétuelle évolution.