La montée en puissance de la culture DevOps au cours des dernières années a conduit à un changement majeur dans le développement de logiciels, permettant aux entreprises de réduire ou d’étendre automatiquement l’infrastructure nécessaire pour prendre en charge les nouvelles fonctionnalités et innovations, et de déployer le code plus rapidement. Est devenu. Et maintenant, alors que DevSecOps, qui intègre la sécurité dans le pipeline de développement et d’exploitation, se développe, la sécurité des applications évolue également. Cependant, les données contenues dans le nouveau rapport de l’industrie montrent qu’il existe toujours un «écart».

Le sujet des tests de sécurité évolue

Selon un nouveau rapport publié par ESG, qui a interrogé 378 développeurs d’applications et responsables de la sécurité des applications en Amérique du Nord, de nombreuses organisations et entreprises continuent de distribuer du code avec des vulnérabilités connues, même si elles estiment que leurs programmes de sécurité des applications sont robustes.

Distribuer du code vulnérable n’est en aucun cas souhaitable, mais le connaître et le distribuer vaut mieux que le distribuer sans le savoir. En effet, ces décisions sont souvent prises dans le cadre d’une évaluation des risques, de plans pour corriger les problèmes et de mesures temporaires d’atténuation. Environ la moitié des personnes interrogées ont déclaré que leurs organisations le faisaient régulièrement. De plus, un tiers des répondants ont déclaré qu’ils le faisaient par intermittence. Les raisons en étaient «l’observation d’un calendrier très important», «un faible risque de faiblesse» et «la découverte d’un problème trop tard dans le cycle de publication» (45%).

Les résultats expliquent pourquoi il est important d’incorporer les tests de sécurité le plus tôt possible dans le processus de développement. Il souligne également que la distribution de code vulnérable n’est pas nécessairement un signe qu’un programme de sécurité n’est pas robuste. Cela peut se produire pour un certain nombre de raisons, et il est impossible d’attraper tous les bogues avec un seul type de test de sécurité.

Cependant, le rapport révèle également que de nombreuses organisations sont toujours en train d’étendre leurs programmes de sécurité des applications. Plus précisément, un tiers seulement a déclaré que plus des trois quarts de la base de code était la cible des programmes de sécurité des applications. Et un tiers a répondu que le programme n’était pas la moitié de la cible.

Il a été enquêté que la personne ou le service responsable de la distribution et du choix du code vulnérable à la production diffère selon l’entreprise. Le pourcentage d’organisations dans lesquelles les responsables du développement prennent des décisions avec des analystes de sécurité était de 28%, et les responsables du développement ou analystes de sécurité seuls ont pris ces décisions à 24% et 21%, respectivement.

Cela peut être le signe qu’un programme de sécurité d’application arrive à maturité. En effet, il est important pour Devsecops de faire avancer les tests de sécurité dans le pipeline de développement lorsque cela est possible. Dans le passé, l’équipe de sécurité a effectué des tests de sécurité une fois les résultats complets.

À la suite de l’intégration de l’équipe de sécurité dans le processus de développement, l’équipe de développement effectue des tests de sécurité, et dans les entreprises qui reflètent les résultats, le responsable du développement décide souvent d’accepter la vulnérabilité. À ce stade, s’il y a un «  expert  » en sécurité qui est un développeur qui coopère avec l’équipe de sécurité ou qui est un développeur qui a des connaissances en sécurité des applications et qui a été formé dans l’équipe, la décision est prise de manière indépendante en consultant au sein de l’entreprise.

Cependant, même dans ce cas, la politique appliquée par le RSSI peut déterminer quelles applications sont en fin de compte responsables de la gestion des risques pour la sécurité des informations à l’échelle de l’entreprise, et quelles applications peuvent être plus exposées aux attaques et aux applications contenant de nombreuses informations sensibles que les pirates peuvent cibler. Vous devez prendre cette décision en vous basant sur. Ces applications peuvent avoir des règles plus strictes pour les correctifs, etc.

Défis lors de l’utilisation d’outils de test de sécurité

Si le risque n’est pas évalué avec précision, la distribution de code avec des vulnérabilités connues peut avoir de graves conséquences. À cet égard, au cours des 12 derniers mois, 60% des répondants ont admis que leurs applications de production avaient été exploitées en raison des 10 principales vulnérabilités de l’OWASP.

Les 10 principales vulnérabilités de l’OWASP incluent les risques de sécurité les plus importants posés aux applications Web. ▲ Injection SQL ▲ Authentification faible ▲ Exposition des données sensibles ▲ Contrôle d’accès faible ▲ Configuration de sécurité incorrecte ▲ Utilisation de composants tiers présentant des vulnérabilités connues. Ce sont généralement des problèmes qui ne devraient pas être autorisés dans le code de production.

Selon le rapport ESG du cabinet d’études de marché, les entreprises utilisent divers outils de test de sécurité des applications. Outil de sécurité API (ASV) 56%, outil de sécurité Infrastructure as Code (IaC) 40% pour se protéger contre les erreurs de configuration, outil de test de sécurité d’application statique (SAST) 40%, outil de test d’analyse de composition logicielle (SCA) 38%, IAST (Interactive A application security testing) outils 38%, outils DAST (Dynamic Application Security Testing) 36%, plug-ins IDE (Integrated Development Environment) qui aident à identifier et résoudre les problèmes de sécurité, 29%, utilisés pour les conteneurs et les référentiels, et les microservices 29% des outils de numérisation d’images, 16% des outils de fuzzing et 15% des outils de sécurité de configuration d’exécution de conteneurs.

Les répondants sont confrontés au plus grand défi lorsqu’ils utilisent ces outils ▲ Manque de connaissances pour atténuer les problèmes qu’ils ont identifiés (29%) ▲ Les développeurs n’utilisent pas efficacement les outils que l’entreprise a investis (24%) ▲ Les outils de test de sécurité ont des frictions Problèmes provoquant et retardant le cycle de développement (26%) ▲ Le problème de l’intégration insuffisante des outils de sécurité applicative de plusieurs fournisseurs (26%) a été cité.

Environ 80% des organisations et entreprises affirment que les analystes de sécurité travaillent directement avec les développeurs pour évaluer les fonctionnalités et le code, modéliser les menaces et participer à des réunions quotidiennes de développement Scrum, mais il semble qu’il n’y ait pas beaucoup de formations à la sécurité pour les développeurs. C’est pourquoi seuls 19% et 26% des développeurs individuels ou des responsables de développement se disent responsables des tests de sécurité des applications. Un tiers et 29% des personnes interrogées ont déclaré que la responsabilité en était confiée à un analyste de sécurité dédié et que l’équipe de développement et l’équipe de sécurité étaient conjointement responsables.

Moins d’un tiers des organisations et des entreprises nécessitent une formation formelle de sécurité dans la moitié. Seulement 15% de tous les développeurs avaient besoin de cette formation. Moins de la moitié des organisations exigent que les développeurs participent à une formation formelle sur la sécurité au moins une fois par an, et 16% s’attendent à ce que les développeurs apprennent par eux-mêmes. Seuls 20% des développeurs offrent une formation à la sécurité lorsqu’ils rejoignent l’équipe.

Même lorsqu’elles fournissent ou nécessitent une formation en matière de sécurité, la plupart des organisations ne suivent pas correctement l’efficacité de cette formation. Seuls 40% des organisations et des organisations suivent une matrice d’introduction des problèmes de sécurité et d’amélioration continue pour les équipes de développement ou les développeurs individuels.

L’une des sociétés de sécurité des applications qui a parrainé la recherche ESG, Veracode, a récemment lancé Veracode, une plate-forme intégrée au navigateur qui offre un accès gratuit à des applications conteneurisées qui permettent aux développeurs de pratiquer des dizaines de cours d’apprentissage sur la sécurité des applications, d’exploits et de correctifs. Lancement de l’édition communautaire Veracode Security Labs.

Composants open source ciblés d’attaques de la chaîne d’approvisionnement

Un programme de sécurité des applications mature doit traiter des composants et des cadres open source. En effet, il occupe une grande partie de la base de code d’application moderne, et il existe un risque d’hériter de vulnérabilités et un risque d’attaques de la chaîne d’approvisionnement. Selon les résultats de l’enquête ESG, environ la moitié ont déclaré que plus de 50% de leur base de code est constituée de composants open source. 8% d’entre eux ont déclaré qu’ils représentaient plus des deux tiers du code. Cependant, seulement 48% des organisations ont investi dans la gestion des vulnérabilités open source.

Dans son rapport sur l’état de la chaîne d’approvisionnement des logiciels en 2020, la société de gouvernance open source Sonatype a rapporté que les attaques ciblant des projets de logiciels open source ont augmenté de 430% par an. Une telle attaque n’est pas une attaque passive dans laquelle l’attaquant exploite la vulnérabilité révélée. L’attaquant tente d’injecter du code malveillant en violant le projet open source amont où le développeur introduit le code dans son application.

En mai, l’équipe de sécurité de GitHub a mis en garde contre une campagne de malware appelée Octopus Scanner qui tentait une attaque par porte dérobée contre le projet IDE NetBeans. Ces composants contrefaits et malveillants sont régulièrement distribués dans des référentiels de packages tels que npm et PyPi.

Les dépendances complexes rendent ce problème difficile à traiter. En 2019, des chercheurs de l’Université de Darmstadt ont analysé l’écosystème npm, la principale source de composants JavaScript. Et il s’avère que les packages typiques chargent en moyenne 79 packages tiers provenant de 39 mainteneurs différents. Les cinq packages les plus populaires sur npm chargeaient entre 134 774 et 166 086 packages différents.

Dans ce rapport, Sonatype a déclaré: «Si un code malveillant est injecté intentionnellement et secrètement dans un projet open source en amont, il est fort probable que le reste des personnes, à l’exception de la personne qui l’a implanté, ne saura pas l’existence du code malveillant. C’est un moyen d’aider les forces malveillantes à piéger secrètement en amont et à lancer des attaques en aval à mesure que les vulnérabilités se développent dans la chaîne d’approvisionnement. »

Selon Sonatype, entre février 2015 et juin 2019, 216 attaques de la chaîne d’approvisionnement de «  nouvelle génération  » ont été signalées. Cependant, 929 attaques supplémentaires ont été enregistrées entre juillet 2019 et mai 2020. Cela signifie qu’il est devenu un vecteur d’attaque très populaire.

Dans le cas d’une attaque traditionnelle dans laquelle des hackers exploitent les vulnérabilités connues d’un composant, on estime que les entreprises ne peuvent pas réagir assez rapidement. Par exemple, pour Apache Struts 2, qui a causé la faille Equifax en 2017, les attaquants ont commencé à exploiter la vulnérabilité dans les 72 heures suivant la connaissance de la vulnérabilité. Plus récemment, une vulnérabilité signalée à SaltStack a été exploitée moins de trois jours après son annonce, provoquant la faillite de nombreuses entreprises.

Selon les résultats de l’enquête de Sonatype auprès de 679 personnes en charge du développement logiciel, seulement 17% des organisations ont identifié des vulnérabilités open source dans la journée suivant leur publication. Après la première semaine et une semaine, les pourcentages identifiés étaient respectivement de 1/3 et environ la moitié. En outre, environ la moitié des organisations ont mis plus d’une semaine à identifier et à répondre aux vulnérabilités. Et environ la moitié des organisations avec cette période de plus d’un mois.

Les composants open source disponibles chaque année et leur consommation augmentent. Plus de 500 000 nouveaux composants ont été publiés par la communauté JavaScript l’année dernière. Par conséquent, le répertoire rpm contient 1,3 million de packages. En mai, les développeurs avaient téléchargé le package 86 milliards de fois à partir de npm. Sonartype prédit que le nombre de téléchargements atteindra 1 billion d’ici la fin de cette année. L’une des préoccupations du rapport publié l’année dernière par l’Université de Darmstadt est que 40% des packages npm contiennent des vulnérabilités connues. En outre, le pourcentage de vulnérabilités dans les packages npm qui n’ont pas été corrigés est de 66%.

Pour l’écosystème Java, les développeurs ont téléchargé 226 milliards de composants open source à partir du référentiel central Maven en 2019. Il s’agit d’une augmentation de 55% par rapport à 2018. Sonatype estime que, sur la base des statistiques de 2020, les téléchargements de composants Java atteindront 375 milliards cette année. Sonatype, qui gère un référentiel central et dispose d’une grande connaissance de ces données, a expliqué que 1/10 des téléchargements de composants avec des vulnérabilités connues existent.

Une analyse de 1 700 applications d’entreprise a révélé qu’en moyenne, 135 composants logiciels tiers étaient inclus, dont 90% étaient open source. Parmi ces composants open source, 11% de ces composants open source contiennent au moins une vulnérabilité. Cependant, l’application hérite en moyenne de 38 vulnérabilités connues dans ces composants. Les applications sont généralement construites avec 2 000 à 4 000 composants open source. Cela montre que l’écosystème open source joue un rôle important dans le développement de logiciels modernes.

La tendance de la consommation de composants dans l’écosystème .NET et l’écosystème des microservices est également similaire. DockerHub a reçu 2,2 images de conteneurs l’année dernière et cette année, les développeurs ont demandé à récupérer 96 milliards d’images. Les images de conteneurs malveillantes hébergées sur Docker Hub sont impliquées dans l’attaque de la chaîne d’approvisionnement publique, et il y a une forte probabilité que l’image soit mal configurée ou présente une vulnérabilité.

«  Calibration as code  » requis pour IaC

DevOps a fait une différence majeure dans le développement de logiciels, en mettant en œuvre une nouvelle architecture de microservices qui maintient les applications monolithiques traditionnelles séparées en services individuels exécutés dans leurs propres conteneurs. Les applications ne contiennent plus uniquement le code nécessaire à la fonction. Il comprend un fichier de configuration qui définit et automatise le déploiement sur une plateforme cloud, ainsi que les ressources nécessaires. Dans le cas de DevSecOps, l’équipe de développement est responsable du déploiement d’une infrastructure sécurisée en plus de l’écriture de code sécurisé.

Une clé codée en dur avec des privilèges sur la configuration utilisée pour provisionner les ressources informatiques, selon un nouveau rapport publié par Accurics, une société de sécurité cloud qui exploite une plate-forme capable de détecter les configurations vulnérables dans les modèles IaC et les déploiements cloud. Le pourcentage de déploiements qui avaient une stratégie de gestion des identités et des accès (IAM) qui avaient provisionné des ressources et sur-approuvés était de 41%. De plus, la plupart des règles de routage étaient mal configurées.

Selon Accurix, ce problème a de nombreux cas d’exploitation. Faille CenturyLink en septembre 2019, avec 2,8 millions d’enregistrements clients exposés, brèche Imperva en août 2019, où des instantanés de base de données contenant des mots de passe et des e-mails hachés au sel ont été exposés, 2019 Par exemple, l’invasion de Capital One, qui a touché 100 millions de résidents américains en juillet 2010.

Accurix devrait introduire et appliquer la «politique en tant que code» afin que les meilleures pratiques telles que le chiffrement de la base de données, la rotation des clés d’accès et l’authentification multiple soient appliquées. Dans le même temps, cependant, une modélisation automatisée des menaces est également nécessaire pour déterminer si un chemin de violation s’est produit dans les déploiements cloud en raison de l’augmentation des privilèges et des changements d’itinéraire. Les entreprises doivent renforcer les politiques en tant que code avec la sécurité en tant que code lors de la définition de leur infrastructure pendant le développement (infrastructure en tant que code). »

Selon Accurix CTO Om Mulchandani, une nouvelle pratique appelée «  Remediation as code  » est en augmentation. Cela signifie que l’outil de sécurité peut rechercher les vulnérabilités dans le modèle de configuration cloud, s’exécuter sur le déploiement lui-même et générer automatiquement le code nécessaire pour résoudre le problème et le suggérer au développeur. Cela peut améliorer le temps requis pour la résolution. C’est une question très importante. Jusqu’à présent, ce processus est souvent manuel et de nombreux problèmes ont été ignorés.

Au cours des dernières années, de nombreux fournisseurs de sécurité des applications et des infrastructures ont mis à niveau leurs produits pour assurer une bonne intégration avec les outils de développement. Les développeurs ont des attentes différentes et la manière dont ils travaillent avec l’équipe de sécurité. Il existe également un certain nombre d’outils open source qui peuvent être testés par rapport aux déploiements cloud.

La société de test d’intrusion Bishop Fox a lancé un outil appelé Smogcloud lors de la conférence Black Hat USA. Les ingénieurs en sécurité et les administrateurs cloud s’ouvrent à Internet avec FQDN (nom de domaine complet) et IP, les actifs cloud AWS exposés à des erreurs de configuration ou des vulnérabilités, des actifs qui ne sont plus utilisés, des services qui ne sont pas actuellement surveillés et d’autres ombres. C’est un outil qui vous aide à identifier les problèmes informatiques. Accurix fournit également plusieurs outils open source et une version gratuite de la plateforme de test de déploiement cloud. editor@itworld.co.kr