Six étapes pour atteindre le zero trust dans la sécurité des applications
trait de séparation
Temps de lecture : 6 minutes
Les cyberattaques contre les grandes entreprises n’ont de cesse de croître, associée à une accélération de la transformation numérique, a obligé les organisations à réévaluer leurs stratégies et leur infrastructure de sécurité. Cette augmentation a entraîné une croissance de l'adoption de la sécurité et de la conformité des applications Zero-Trust.
L'approche zero trust signifie qu'aucun appareil ou logiciel ne doit être approuvé par défaut, même s'il dispose d'autorisations et d'une vérification préalable. Chaque composant doit être scanné, analysé et testé pour les vulnérabilités.
À la suite d’échanges entre Luc BROGAN, Mend, et leur partenaire néerlandais, Logic Technology, cet article de blog est né. Il met en évidence six des principaux moyens de construire une stratégie zero trust réussie.
- Étape 1. Décaler la sécurité et la conformité open source vers la gauche
- Étape 2 : Combinez SCA pour l'open source et SAST pour le code personnalisé
- Étape 3 : Découvrir de nouvelles vulnérabilités zero-day ou pré-CVE/NVD
- Étape 4 : Éviter les failles de sécurité courantes dans le code propriétaire
- Étape 5 : Hiérarchiser les vulnérabilités
- Étape 6 : Déployer les SBOM
Étape 1. Décaler la sécurité et la conformité open source vers la gauche
Il est largement reconnu qu'entre 70 et 80 % du code d'application est open source . D'énormes quantités de logiciels et de bibliothèques sont déjà pré-écrites et prêtes à l'emploi. C'est formidable pour la vitesse d'intégration, mais le modèle traditionnel de « zero trust » pose des risques de sécurité. Si la confiance est supposée, la vigilance est laxiste et les packages compromis ou le code vulnérable peuvent être négligés, entraînant des vulnérabilités des applications. C'est un problème commun. La solution consiste à prévenir ces problèmes le plus tôt possible dans le cycle de vie du développement logiciel (SDLC) en déplaçant la sécurité vers la gauche (Shift Left), idéalement lors de l'écriture de code ou de la recherche de nouveaux composants. La détection et la correction immédiate des vulnérabilités au début du SDLC permettent de surmonter les flux de travail inefficaces auxquels les équipes de développement sont confrontées lorsqu'elles sont obligées de détecter et de corriger séparément.
Réduction des risques de sécurité des applications d'entreprise : Plus de travail doit être fait !
Étape 2 : Combinez SCA pour l'open source et SAST pour le code personnalisé
L'analyse de la composition logicielle (SCA) fait un excellent travail d'analyse et de correction des 70 à 80 % de logiciels open source, mais laisse toujours les 20 à 30 % de code propriétaire non protégés. Le test de sécurité des applications statiques (SAST) est l'un des principaux moyens de protéger le code personnalisé des vulnérabilités. Cependant, l'utilisation d'outils séparés par type de code entrave vraiment le développement, parfois à un point tel que les développeurs ignorent les vulnérabilités et les mises à jour qui pourraient exposer la base de code r à des faiblesses à l'avenir.
Parce qu'il est plus facile d'avoir une solution qui s'intègre à l'ensemble du SDLC, l'unification des deux solutions offre le plus grand avantage en matière de sécurité. Cela vous donne le contrôle tout au long du cycle de vie du développement, en vous assurant que les processus existants ne sont pas entravés.
De plus, la plupart des outils se concentrent sur l'identification des problèmes dans votre code, mais peu d'accent a été mis sur la correction pour les résoudre. Cela est en train de changer, et c'est quelque chose que Mend a lancé en offrant non seulement la détection des vulnérabilités pour SAST, mais également une correction automatisée . Cela permet à vos développeurs de produire plus rapidement des logiciels de qualité et leur permet de se concentrer sur de nouvelles fonctionnalités et sur les fonctionnalités de leurs logiciels, plutôt que de rechercher des problèmes de sécurité.
Parce qu'il est plus facile d'avoir une solution qui s'intègre à l'ensemble du SDLC, l'unification des deux solutions offre le plus grand avantage en matière de sécurité. Cela vous donne le contrôle tout au long du cycle de vie du développement, en vous assurant que les processus existants ne sont pas entravés.
De plus, la plupart des outils se concentrent sur l'identification des problèmes dans votre code, mais peu d'accent a été mis sur la correction pour les résoudre. Cela est en train de changer, et c'est quelque chose que Mend a lancé en offrant non seulement la détection des vulnérabilités pour SAST, mais également une correction automatisée . Cela permet à vos développeurs de produire plus rapidement des logiciels de qualité et leur permet de se concentrer sur de nouvelles fonctionnalités et sur les fonctionnalités de leurs logiciels, plutôt que de rechercher des problèmes de sécurité.
Étape 3 : Découvrir de nouvelles vulnérabilités zero-day ou pré-CVE/NVD
Même avec une solution de sécurité robuste en place, des vulnérabilités peuvent survenir qui ne sont pas encore connues comme une vulnérabilité et une exposition courantes (CVE) ou connues de la base de données nationale sur les vulnérabilités (NVD). À mesure que les volumes de vulnérabilités augmentent, il est de plus en plus important de les détecter et d'y remédier rapidement.
Chez Mend, une équipe de recherche sur les menaces se consacre à trouver de nouvelles vulnérabilités et faiblesses dans les cadres communs, et à alerter rapidement les clients pour empêcher le pipeline de créer l'artefact. Cela se fait par le biais de moteurs de politique. Ainsi, par exemple, si une vulnérabilité zero-day, telle que Log4j, est déclenchée, tous les pipelines de production sont arrêtés pour résoudre le problème très rapidement et rouvrir les pipelines en toute sécurité.
Chez Mend, une équipe de recherche sur les menaces se consacre à trouver de nouvelles vulnérabilités et faiblesses dans les cadres communs, et à alerter rapidement les clients pour empêcher le pipeline de créer l'artefact. Cela se fait par le biais de moteurs de politique. Ainsi, par exemple, si une vulnérabilité zero-day, telle que Log4j, est déclenchée, tous les pipelines de production sont arrêtés pour résoudre le problème très rapidement et rouvrir les pipelines en toute sécurité.
Étape 4 : Éviter les failles de sécurité courantes dans le code propriétaire
Avec SAST , Mend dispose désormais de la technologie pour résoudre les problèmes au sein de l'environnement de développement intégré (IDE), généralement lorsque les développeurs écrivent du code. L'utilisation de cette nouvelle génération de SAST offre une meilleure facilité d'intégration et une plus grande rapidité qu'auparavant. De plus, vous pouvez renforcer vos processus de sécurité en améliorant l'éducation et la sensibilisation, encourageant ainsi une adoption accrue des outils de sécurité. L'adoption est accélérée lorsque le logiciel est facile à utiliser, et les développeurs peuvent être sûrs qu'il ne ralentira pas le développement.
Prenez Visual Studio Code comme exemple. Avoir l'intégration où vous pouvez rechercher les vulnérabilités open source et les faiblesses du code propriétaire est essentiel. Il facilite et accélère la numérisation. Ensuite, fournir le code corrigé est vraiment l'objectif numéro un.
Disons que le développeur peut alors voir qu'il y a une entrée non nettoyée, peut-être une attaque potentielle par injection SQL. Il pourrait y avoir 70 à 80 types différents de faiblesses communes. Mais nous fournissons également le correctif dans l'IDE. Par conséquent, tout ce qui devrait être nécessaire est de copier et coller le code et de relancer l'analyse, ce qui ne prend que quelques secondes. Ensuite, vous pourrez, espérons-le, voir cette faiblesse disparaître. Cela montre que la combinaison de la facilité d'intégration, de la vitesse d'analyse et de la meilleure connaissance de l'outil par les développeurs constitue la meilleure pratique pour sécuriser le code.
Prenez Visual Studio Code comme exemple. Avoir l'intégration où vous pouvez rechercher les vulnérabilités open source et les faiblesses du code propriétaire est essentiel. Il facilite et accélère la numérisation. Ensuite, fournir le code corrigé est vraiment l'objectif numéro un.
Disons que le développeur peut alors voir qu'il y a une entrée non nettoyée, peut-être une attaque potentielle par injection SQL. Il pourrait y avoir 70 à 80 types différents de faiblesses communes. Mais nous fournissons également le correctif dans l'IDE. Par conséquent, tout ce qui devrait être nécessaire est de copier et coller le code et de relancer l'analyse, ce qui ne prend que quelques secondes. Ensuite, vous pourrez, espérons-le, voir cette faiblesse disparaître. Cela montre que la combinaison de la facilité d'intégration, de la vitesse d'analyse et de la meilleure connaissance de l'outil par les développeurs constitue la meilleure pratique pour sécuriser le code.
Étape 5 : Hiérarchiser les vulnérabilités
Historiquement, la plupart des organisations ont classé les vulnérabilités par gravité, en utilisant les scores CVS. Ils examinent les métriques pour établir des facteurs tels que si une élévation privilégiée est requise et de quel type d'attaque réseau il s'agit. Logiquement, il semble correct de se concentrer sur les vulnérabilités critiques, mais une question plus importante est de savoir si la vulnérabilité en question est exploitable. Une hiérarchisation efficace analyse le code et identifie non seulement quand il y a une fonction ou une procédure qui présente une vulnérabilité, mais aussi si vous avez importé la bibliothèque, si elle est utilisée, et donc si chaque vulnérabilité est vraiment une priorité. Ceux qui ne sont pas importés ou que vous n'utilisez pas peuvent constituer une menace dans d'autres contextes, mais pas le vôtre, et peuvent donc être dépriorisés. En conséquence, vous ne perdrez pas de temps et de ressources à rechercher et à corriger des vulnérabilités qui représentent peu ou pas de menace pour votre base de code.
Quelques exploits de sécurité courants dans la technologie avec logiciel embarqué
Protocole de transfert de données TCP/IP
La technologie avec logiciel embarqué pose ses propres défis. Un bon exemple de facteur d'attaque dans ce contexte est le protocole de transfert de données TCP/IP. C'est le protocole de transfert de données le plus répandu en raison de sa grande compatibilité. Cependant, il existe de nombreuses vulnérabilités TCP/IP connues des pirates car le protocole utilise des canaux ouverts pour le transfert de données. Ainsi, les attaquants pourraient essentiellement en abuser pour accéder, écouter et modifier le trafic.
Il existe d'autres projets open source bien connus, tels que les distributions Linux qui sont répandues dans les systèmes embarqués. L'exploit Linux le plus célèbre est probablement celui du thermostat Nest en 2016. Un groupe de chercheurs britanniques a démontré qu'ils pouvaient prendre le contrôle de l'appareil en utilisant un ransomware pour exploiter une vulnérabilité dans les composants open source.
Stuxnet
Un autre exemple célèbre est Stuxnet, lorsqu'un ver informatique malveillant a ciblé des systèmes de contrôle de supervision et d'acquisition de données (SCADA) et a causé des dommages à un programme nucléaire gouvernemental en ciblant des contrôleurs logiques programmables (PLC) qui étaient utilisés pour contrôler les centrifugeuses à gaz qui séparaient les matières nucléaires. Le ver a utilisé cinq exploits zero-day : le rootkit Windows, le premier rootkit PLC connu, des techniques d'évasion antivirus, des mises à jour peer-to-peer et des certificats volés à des autorités de certification de confiance.
Polkit
Une vulnérabilité révélée plus récemment affectant le composant Polkit était présente sur plusieurs distributions Linux depuis plus de 12 ans. La vulnérabilité est facilement exploitable et permet aux utilisateurs non privilégiés d'obtenir des privilèges root complets sur un hôte vulnérable. Polkit est couramment utilisé pour contrôler les privilèges du système d'exploitation dans les distributions Linux. Tout comme Log4j, c'est un bon exemple d'une vulnérabilité de longue date mais inconnue qui peut déclencher des problèmes importants une fois qu'un CVE est diffusé dans la nature. Nous ne savons pas combien de fois il a été exploité ou utilisé, mais il y a eu jusqu'à 12 ans d'exposition, ce qui est significatif.
Projets Yocto
Les projets Yocto sont étroitement liés à Linux, et Yocto est au cœur de nombreux produits embarqués. Un bon exemple est un client qui a développé des microphones directionnels, dont certains sont utilisés par l'armée, pour détecter où se trouvent les tireurs d'élite en fonction du son. Yocto peut utiliser de nombreux composants open source, et le défi est de s'assurer que toutes les vulnérabilités sont détectées et corrigées.
Protocole de transfert de données TCP/IP
La technologie avec logiciel embarqué pose ses propres défis. Un bon exemple de facteur d'attaque dans ce contexte est le protocole de transfert de données TCP/IP. C'est le protocole de transfert de données le plus répandu en raison de sa grande compatibilité. Cependant, il existe de nombreuses vulnérabilités TCP/IP connues des pirates car le protocole utilise des canaux ouverts pour le transfert de données. Ainsi, les attaquants pourraient essentiellement en abuser pour accéder, écouter et modifier le trafic.
Il existe d'autres projets open source bien connus, tels que les distributions Linux qui sont répandues dans les systèmes embarqués. L'exploit Linux le plus célèbre est probablement celui du thermostat Nest en 2016. Un groupe de chercheurs britanniques a démontré qu'ils pouvaient prendre le contrôle de l'appareil en utilisant un ransomware pour exploiter une vulnérabilité dans les composants open source.
Stuxnet
Un autre exemple célèbre est Stuxnet, lorsqu'un ver informatique malveillant a ciblé des systèmes de contrôle de supervision et d'acquisition de données (SCADA) et a causé des dommages à un programme nucléaire gouvernemental en ciblant des contrôleurs logiques programmables (PLC) qui étaient utilisés pour contrôler les centrifugeuses à gaz qui séparaient les matières nucléaires. Le ver a utilisé cinq exploits zero-day : le rootkit Windows, le premier rootkit PLC connu, des techniques d'évasion antivirus, des mises à jour peer-to-peer et des certificats volés à des autorités de certification de confiance.
Polkit
Une vulnérabilité révélée plus récemment affectant le composant Polkit était présente sur plusieurs distributions Linux depuis plus de 12 ans. La vulnérabilité est facilement exploitable et permet aux utilisateurs non privilégiés d'obtenir des privilèges root complets sur un hôte vulnérable. Polkit est couramment utilisé pour contrôler les privilèges du système d'exploitation dans les distributions Linux. Tout comme Log4j, c'est un bon exemple d'une vulnérabilité de longue date mais inconnue qui peut déclencher des problèmes importants une fois qu'un CVE est diffusé dans la nature. Nous ne savons pas combien de fois il a été exploité ou utilisé, mais il y a eu jusqu'à 12 ans d'exposition, ce qui est significatif.
Projets Yocto
Les projets Yocto sont étroitement liés à Linux, et Yocto est au cœur de nombreux produits embarqués. Un bon exemple est un client qui a développé des microphones directionnels, dont certains sont utilisés par l'armée, pour détecter où se trouvent les tireurs d'élite en fonction du son. Yocto peut utiliser de nombreux composants open source, et le défi est de s'assurer que toutes les vulnérabilités sont détectées et corrigées.
Alors, comment les organisations peuvent-elles identifier et bloquer ces menaces le plus tôt possible dans le SDLC ? Comment pouvez-vous être sûr que ces types de logiciels sont sécurisés ?
Étape 6 : Déployer les SBOM
La meilleure façon d'atténuer ces types d'attaques est d'avoir une nomenclature logicielle (SBOM) - essentiellement une liste de tous les composants logiciels de ces produits. Ceci est important car une fois que vous savez ce qui est utilisé, vous connaissez les versions et l'état de sécurité de chaque composant. Grâce à ces connaissances, vous pouvez identifier si un projet présente des exploits ou des vulnérabilités de type zero-day. Ensuite, vous pouvez mettre à niveau les composants et atténuer tout risque le plus rapidement possible.
Le déploiement d'une solution SCA vous permet d'analyser les conteneurs et les registres Docker et de créer un SBOM pour l'application. Vous n'êtes pas limité à un référentiel ou à un pipeline. De nombreux fournisseurs et technologies embarquées regrouperont l'application et pourraient utiliser une distribution embarquée de Linux ou Unix. Vous pouvez également scanner ce conteneur pour produire le SBOM. Une fois que vous avez cette nomenclature, vous comprendrez exactement quelle est la menace et quelles sont les faiblesses de sécurité du projet.
Le déploiement d'une solution SCA vous permet d'analyser les conteneurs et les registres Docker et de créer un SBOM pour l'application. Vous n'êtes pas limité à un référentiel ou à un pipeline. De nombreux fournisseurs et technologies embarquées regrouperont l'application et pourraient utiliser une distribution embarquée de Linux ou Unix. Vous pouvez également scanner ce conteneur pour produire le SBOM. Une fois que vous avez cette nomenclature, vous comprendrez exactement quelle est la menace et quelles sont les faiblesses de sécurité du projet.
