Dans cet article, nous abordons certaines des questions les plus fréquentes qui nous sont posées au sujet de la sécurité informatique. Qu'il s'agisse de comprendre l'importance d'intégrer des mesures de sécurité dès la phase de gestion des exigences ou de se tenir informé des dernières tendances en matière de sécurité, nous explorerons également le rôle essentiel que joue la sécurité dans le processus de développement et proposerons des pistes pour sécuriser les systèmes existants et mettre en place des contrôles internes continus.
Le Top 10 de l’OWASP est un excellent guide à suivre ; il s’agit d’une liste des vulnérabilités les plus courantes dans les applications web. OWASP signifie « Open Web Application Security » et désigne une organisation qui œuvre en faveur de la sécurité des applications logicielles.
Il y a quelques années, l’OWASP ASVS (Application Security Verification Standard) a été publié ; il s’agit d’un excellent recueil à consulter pour détecter les problèmes de sécurité lors de la gestion des exigences. Il peut servir de cahier des charges pour les applications. L’ASVS s’apparente à une liste de contrôle articulée en trois niveaux distincts : commencez par le niveau 1, comparez-le à ce que vous avez déjà mis en place et à ce qui doit être mis en œuvre, puis passez au niveau suivant. Toutes les applications doivent être en mesure de satisfaire aux exigences du niveau 1. Si vous souhaitez intégrer la sécurité à vos exigences, je vous conseille de commencer par là. Un conseil : commencez modestement et progressez graduellement. De nombreuses entreprises commettent l’erreur d’appliquer trop de mesures à la fois, ce que l’organisation n’est finalement pas en mesure de gérer.
Nous suivons de nombreux experts en sécurité sur Twitter, où nous obtenons des informations fiables lorsqu'un incident se produit ou qu'un nouvel outil est lancé. Nous suivons également des blogs consacrés à la sécurité, comme celui de Daniel Miessler, Podcast ou encore Darknet Diaries. Par ailleurs, nous recherchons des outils, des extraits de code ou des scripts que des personnes ont publiés ou sont en train de publier, et nous cherchons à comprendre ce qu’ils visent à faire.
En ce qui concerne les vulnérabilités, nous ne passons pas nos journées à surveiller si une nouvelle vulnérabilité a été signalée pour un produit spécifique. C’est lorsque nous avons des missions impliquant une application dotée d’une certaine architecture logicielle que nous examinons quelles vulnérabilités existent actuellement. Sinon, LinkedIn est une bonne source pour se tenir au courant des nouvelles vulnérabilités publiées.
Avant la Covid, de grands événements consacrés à la sécurité étaient organisés chaque été à Las Vegas : Black Hat, Def Con et BSides. C’était l’endroit idéal pour nouer des contacts et assister à des sessions passionnantes.
Si l’on se place du point de vue des tests d’intrusion et d’après nos missions, nous avons remarqué que la sécurité n’est intégrée aux projets de développement que très tardivement. Souvent, ce n’est qu’au moment où le produit est sur le point d’être mis en production que l’entreprise se rend compte qu’elle doit effectuer un test de sécurité. Et dans le pire des cas, nous découvrons de nombreuses vulnérabilités qui doivent être corrigées. Cela entraîne un retard dans le projet et une augmentation des coûts.
Nous aimerions que les entreprises intègrent la sécurité plus tôt dans la phase de développement. On parle généralement de « Shift Left Testing » en matière de sécurité, c’est-à-dire qu’il ne s’agit pas d’appliquer la sécurité comme une fonctionnalité supplémentaire à la fin, mais de l’intégrer dès le début. La sécurité doit être incluse dans les exigences.
En mettant en place des mesures de sécurité tout autour du système, par exemple des contrôles compensatoires à tous les niveaux avec des pare-feu de couche 7, l’inspection approfondie des paquets et en examinant la couche applicative. Envisagez également de vous doter d’un système de détection d’intrusion (IDS) et/ou d’un système de prévention d’intrusion (IPS). Voici quelques options pour sécuriser vos systèmes un peu plus anciens.
Appuyez-vous sur les 20 contrôles CIS. Quels sont les contrôles actuellement en place au sein de l'entreprise ?
Lorsque l'on parle de contrôles, cela englobe tout, depuis :
– Disposez-vous d’un système antivirus ?
– Assurez-vous le suivi de vos actifs au sein de l’entreprise ?
– Avez-vous une vue d’ensemble des applications utilisées au sein de l’entreprise ?
– Effectuez-vous régulièrement des tests d’intrusion ?
– Avez-vous des connaissances en matière de privilèges d'administration ?
– Utilisez-vous une solution de messagerie sécurisée ?
C’est un sujet assez vaste, mais c’est une très bonne piste à suivre si vous souhaitez commencer à mettre en place un contrôle, une structure et un suivi. Comme pour tout le reste, ne vous attaquez pas à tout d’un coup : commencez modestement et prenez votre temps. La sécurité n’est pas quelque chose que l’on met en place en un mois, c’est un long processus. Les grandes entreprises travaillent sans relâche et rencontrent des difficultés constantes avec les contrôles CIS ; c’est un défi de taille à relever si vous souhaitez vous conformer à l’ensemble des 20 contrôles.
Si l’on sépare l’infrastructure de l’application et que l’on commence par la partie application, nous ne voyons pas de grande différence dans l’approche ni dans ce qu’elle doit être capable de gérer. En revanche, l’infrastructure, notamment la gestion des clés et des secrets, diffère de ce que l’on ferait sur site, dans un centre de données. Le cloud offre directement de nombreuses fonctionnalités de sécurité dont vous ne disposez peut-être pas dans votre propre centre de données, telles que la traçabilité des accès. Mais pour que cela fonctionne comme prévu, il est nécessaire de le configurer, et de le configurer correctement. Le cloud n’est pas sécurisé par défaut, et c’est à l’utilisateur qu’il revient de configurer et d’activer ces fonctionnalités avant la mise en service sur Internet.
Oui, l’OWASP ASVS
Oui, grâce à la méthodologie « Shift Left ». Intégrez la sécurité dès le tout début du développement et testez le produit dès les premières étapes. D’autres moyens de vérifier que votre produit est sécurisé sont les tests d’intrusion, l’analyse SAST (analyse statique) et l’analyse dynamique sous forme d’analyse d’applications web. Ces méthodes vous permettent d’assurer le suivi de votre application sur le long terme.
Vous pouvez également recourir à la modélisation des menaces. Réunissez vos développeurs devant un tableau blanc et dessinez l’architecture de votre application. Vous pouvez la décomposer en composants plus petits ou la représenter de manière plus simplifiée. Examinez les flux de données : comment et par où elles entrent et sortent, quelles fonctions sont disponibles, puis commencez à répertorier les différents modes d’attaque possibles et les vulnérabilités potentielles. Essayez ensuite d’intégrer des mesures de sécurité à l’application.
La « Privacy by Design » est une expression plus élégante qui signifie que vous devez réfléchir à la sécurité dès les premières étapes du projet, en l'intégrant dès le départ dans vos spécifications.
La modélisation des menaces, telle que décrite ci-dessus, dès les premières phases du développement, constitue un très bon point de départ. Identifiez les données à caractère personnel dont vous disposez et essayez de respecter les directives légales : le RGPD s’applique aux données à caractère personnel et la norme PCI DSS est un document juridique bien établi qui définit les modalités de traitement des données de cartes bancaires. En ce qui concerne les informations confidentielles, vous pouvez vérifier quels cadres juridiques vous devez prendre en compte. Ensuite, il est important de mettre en place des processus de sécurité, tels que les exigences de sécurité, la modélisation des menaces, la revue de code, les outils DAST, les tests d’intrusion et les tests d’infrastructure à l’aide d’outils d’automatisation.
Nous vous recommandons d’automatiser davantage lorsque cela est possible. Nous pensons que vous pouvez effectuer toutes les vérifications automatisables, par exemple dans ASVS ou dans un processus CICD. Utilisez des outils automatisés, des outils DAST, des outils de révision de code ou similaires.
Notre expertise est nécessaire pour les questions plus complexes et lorsque des tests plus poussés doivent être effectués. Souvent, lorsque nous nous apprêtons à réaliser des tests d’intrusion, les entreprises n’ont effectué ni revue de code ni analyse à l’aide d’outils DAST. Cela signifie que nous devons identifier tous les types de vulnérabilités, ce qui représente un travail considérable. Les meilleurs cas de figure sont ceux où nous recevons un rapport d’un outil d’analyse de vulnérabilités et où, en examinant l’infrastructure, nous constatons que des revues de code et des outils DAST ont bien été utilisés. Notre travail peut alors se concentrer sur tous les autres aspects que les outils ne peuvent pas traiter lorsqu’il s’agit de logique pure. Par exemple, la gestion de la logique au sein d’une application, la logique métier pure et autres aspects similaires. Les outils automatisés ne sont pas particulièrement efficaces pour identifier ces éléments, car ils n’ont aucune idée de la manière dont l’application elle-même est censée fonctionner. Il faut automatiser autant que possible et utiliser notre expertise pour les aspects que les outils ne peuvent pas gérer.
Examens que nous recommandons :
OWASP ASVS, niveau 1, est conçu pour vous permettre de l'automatiser presque entièrement. Il y a également le Guide de test OWASP, un excellent guide sur les types de problèmes et la manière d'identifier les vulnérabilités.
En ce qui concerne les outils, tout dépend de l'entreprise. Il n'existe pas d'outil universel.