Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
L'analyse des applications est l'un des meilleurs moyens de détecter les failles de sécurité des logiciels. SAST est un puissant modèle d'analyse des applications utilisé dans plusieurs organisations. Voici une discussion sur le rôle de l'analyse statique de Parasoft dans l'analyse de logiciels.
Aller à la section
Aller à la section
L'Agence des systèmes d'information de la défense (DISA), la sécurité et le développement des applications (ASD) et les guides techniques de mise en œuvre de la sécurité (STIG), connus sous le nom de DISA ASD STIG, sont un guide de mise en œuvre technique sur la sécurité et le développement des applications pour l'agence des systèmes d'information de la défense. Il existe de nombreux STIG pour sécuriser différentes parties de l'infrastructure et des services du DoD. Cependant, les directives ASD couvrent le développement d'applications internes et l'évaluation d'applications tierces.
Respect des directives DISA ASD STIG exige une preuve, généralement sous forme de documentation, qui satisfasse les auditeurs. Cet article couvre :
Le DISA ASD STIG fournit un ensemble détaillé de lignes directrices pour améliorer la sécurité des systèmes logiciels, principalement au sein du Département de la Défense (DoD). L'autorité de conformité évalue si les systèmes et les logiciels sont configurés ou non pour répondre aux exigences de la Defense Information Security Agency (DISA). Le non-respect des DISA STIG peut bloquer ou retarder le déploiement de votre logiciel.
Compte tenu de la nature étendue de cette directive de conformité, les agences gouvernementales et les sous-traitants de la défense sont souvent confrontés à plusieurs défis lorsqu'ils tentent de répondre aux exigences de conformité DISA ASD STIG. Certains de ces défis sont les suivants.
Pour atteindre la conformité, une approche de validation à trois niveaux est requise:
Ce poinçon 1-2-3 est la clé pour atteindre la conformité par la validation et la documentation. L'objectif est de faire évoluer le processus au-delà de la détection vers la prévention des vulnérabilités de sécurité.
L'ASD STIG utilise un code de catégorie de gravité (CAT I, CAT II, CAT III) pour organiser et hiérarchiser les lignes directrices en fonction de l'impact possible d'un exploit de la ligne directrice.
L'évaluation de la documentation des produits et des processus ainsi que l'observation et la vérification des fonctionnalités par rapport aux directives déterminent la conformité. En d'autres termes, le STIG exige la preuve d'une conception et d'une mise en œuvre sécurisées par la documentation, la vérification et la validation de tous les aspects du cycle de vie du développement logiciel. Cela comprend le déploiement et l'exploitation. Ces directives s'appliquent pendant toute la durée de vie du produit, depuis la configuration, le déploiement, la maintenance et la fin de vie.
L'exigence des scanners de code d'application est importante pour la discussion de cet article:
«… Un outil automatisé qui analyse le code source des applications pour détecter les failles de sécurité, les codes malveillants et les portes dérobées.» —Vue d'ensemble de DISA ASD STIG, section 4.1
Dans une terminologie plus courante, il s'agit de tests de sécurité d'application statique (SAST) implémentés via une analyse de code statique. Il «devrait être utilisé chaque fois que possible. En particulier dans l'environnement de développement où le code qui a été identifié comme nécessitant une correction peut être traité avant la publication. » L'ASD STIG contient également les conseils suivants:
«Un scanner d'application peut être utilisé pour tester les systèmes d'application de développement ou de production pour détecter les vulnérabilités de sécurité résultant d'erreurs de code d'application ou de mauvaise configuration du système d'application. Ces vulnérabilités incluent l'injection SQL, l'injection de code, le Cross Site Scripting (XSS), les divulgations de fichiers, les autorisations et d'autres vulnérabilités de sécurité qui peuvent être trouvées dans les applications accessibles par le réseau »—DISA ASD STIG Overview, Section 4.2 - Application Scanner
L'ASD STIG nécessite l'utilisation de tests de vulnérabilité actifs, par exemple des outils de test d'intrusion ou DAST, pour tester les logiciels exécutables. Ces outils sont requis pendant le développement et le déploiement pour prendre en charge les évaluations de vulnérabilité.
L'ASD STIG décrit les moyens de vérifier la conformité aux exigences, notamment:
Les équipes utilisent les rapports et les audits de l'outil SAST pour valider les applications et l'analyse du code. Les tests fonctionnels vérifient à l'aide d'outils automatisés ou de tests manuels que la vulnérabilité n'est pas présente dans le logiciel. En d’autres termes, considérez l’approche comme « faites quelque chose, vérifiez quelque chose ». Par exemple, vérifiez si l'action a fonctionné correctement et a été enregistrée si nécessaire). Ces approches conviennent aux tests automatisés en raison de l'efficacité et des outils de piste d'audit fournis.
La réalité du développement logiciel pour le DoD, qui nécessite DISA ASD STIG, est que vous devez tester toutes les exigences et vulnérabilités. Cela peut être une tâche ardue, mais l'automatisation est possible pour alléger certains fardeaux.
La recommandation de Parasoft sur la façon d'approcher la conformité à DISA ASD STIG est de tirer parti de l'automatisation là où cela a le plus de sens, comme dans les pipelines CI/CD ou les processus DevSecOps. L’objectif est d’alléger le fardeau de la conformité, d’utiliser des techniques préventives pour prévenir les vulnérabilités et, à terme, d’assurer une conformité continue.
Il est plus coûteux et plus long de détecter et de corriger les vulnérabilités lorsque le logiciel est presque terminé que pendant le développement. Pour cette raison, l'approche de Parasoft consiste à abandonner l'évaluation, la détection et la correction des vulnérabilités plus tôt dans le cycle de vie.
Le DISA ASD STIG utilise le terme «analyse d'application», qui équivaut à une analyse de code statique et à des technologies connexes telles que l'analyse de composition logicielle. En plus de l'exigence générale d'évaluation des vulnérabilités via l'analyse de code statique, il existe des exigences spécifiques pour rechercher des vulnérabilités spécifiques telles que:
Bien que cela ressemble à un petit ensemble de vulnérabilités, la réalité est que cela se traduit par de nombreuses faiblesses logicielles associées. Par exemple, le Top 10 OWASP (Open Web Application Security Project) se traduit par plus de 50 CWE. Chacun peut avoir plusieurs faiblesses liées.
Bien qu'il s'agisse d'un ensemble de vulnérabilités spécifiques à la conformité, il est prudent d'envisager un éventail plus large de vulnérabilités à détecter. En outre, il est important que les équipes élargissent leur champ d'action au-delà des lignes directrices du DISA ASD STIG pour inclure des lignes directrices préventives telles que celles incluses dans les normes de codage sécurisé communes de l'industrie.
Comme son nom l'indique, le Top 10 de l'OWASP est une organisation engagée dans l'amélioration de la sécurité des applications Web. Leur projet OWASP Top 10 fournit une liste des vulnérabilités de sécurité des applications Web les plus courantes et à fort impact.
Bien qu'il soit possible d'utiliser des outils d'analyse statique pour détecter la plupart des problèmes, certains ne sont pas statiquement analysables. La directive pour éviter les logiciels présentant des vulnérabilités connues est liée à l'analyse de la composition logicielle (SCA). Parasoft prend en charge cela en intégrant aux outils SCA notre sortie d'analyse statique dans un seul rapport, ce qui permet une couverture complète du Top 10.
L'analyse statique Parasoft prend en charge immédiatement OWASP Top 10 via des paramètres préconfigurés et des tableaux de bord Web spécifiques pour C / C ++, Java et C # /. NET. Les rapports OWASP dans Parasoft DTP fournissent un cadre de conformité entièrement auditable pour les projets. Le tableau de bord spécifique aux normes, comme celui ci-dessous pour DISA ASD STIG, offre un moyen simple de surveiller en permanence l'état.
Parasoft a mis en œuvre toutes les principales normes de sécurité des applications, telles que le codage sécurisé SEI CERT, les directives de codage CWE (Common Weakness Enumeration), UL 2900, OWASP et des tableaux de bord spécifiques à la sécurité pour chacune. Cela aide les utilisateurs à comprendre les risques et la priorité des violations/vulnérabilités/défauts de sécurité en suspens.
Les rapports de conformité sont disponibles sur demande. Les critères de conformité sont flexibles et spécifiques au projet et à la base de code de l'équipe. Les développeurs peuvent élaborer des politiques basées sur la gravité, le risque, l'impact, l'âge du code, l'importance des composants, etc. Ils peuvent les utiliser pour guider facilement le développement et montrer leurs efforts à un auditeur. Les développeurs peuvent également transmettre des politiques à l'équipe de sécurité pour les intégrer aux résultats d'autres parties des tests de sécurité, telles que le système d'exploitation, le réseau, etc.
L'un des aspects cruciaux des outils d'analyse statique est les capacités de reporting et d'analyse. Les projets créent une grande quantité de données en termes d'avertissements et sont multipliés build par build. La gestion des données est la clé du succès de l'adoption et du retour sur investissement des outils d'analyse statique.
Les tableaux de bord, les rapports et la conformité réglés pour chaque norme de codage et directive de sécurité sont essentiels. L'analyse Parasoft s'appuie sur des modèles de risque standard et de multiples techniques d'intelligence artificielle (IA) et d'apprentissage automatique (ML) pour hiérarchiser les avertissements de sécurité et aider les développeurs à se concentrer sur les problèmes les plus critiques ayant le plus grand impact.
Le DISA ASD STIG présente un ensemble impressionnant d'exigences pour sécuriser les logiciels pour les applications DoD. Il existe différentes méthodes pour démontrer le respect des règles énoncées dans le STIG. Les méthodes habituelles comprennent:
Le STIG décrit les principaux domaines d'opportunité d'automatisation tels que le code d'application et la numérisation des applications. L'analyse statique permet d'atteindre certains de ces objectifs.
Une approche pragmatique allège le fardeau de la conformité et encourage les techniques préventives qui suppriment les vulnérabilités dès le début du cycle de vie du projet. L'analyse statique de Parasoft permet une détection précoce des vulnérabilités. Cette solution applique le style et la qualité du code pour éviter le plus tôt possible les mauvaises pratiques de sécurité.
Des tests Java plus intelligents grâce à l'IA pour plus de rapidité, de couverture et de conformité