Le rôle de SAST pour l'analyse des applications dans la conformité DISA ASD STIG

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 :

• Défis associés à la mise en conformité avec DISA ASD STIG
• L'approche recommandée par Parasoft pour assurer la conformité d'une manière efficace, moins risquée et rentable.
• Exigences qui spécifient l'utilisation de scanners d'application ou de scanners de code d'application, que les équipes peuvent valider avec analyseurs statiques.

Comprendre les défis de conformité DISA ASD STIG

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.

• Les exigences sont complexes. Les DISA ASD STIG comprennent un grand nombre de contrôles de sécurité, de configurations et de recommandations spécifiques. Ces directives couvrent un large éventail de domaines, tels que l'authentification, le contrôle d'accès, le cryptage, les paramètres réseau, etc. Le grand nombre de lignes directrices, ainsi que leur profondeur technique, peuvent rendre difficile pour les organisations de les comprendre, de les interpréter et de les mettre en œuvre correctement. S’assurer que chaque directive est correctement prise en compte dans les différents systèmes et composants nécessite une attention méticuleuse aux détails et une expertise dans les configurations de sécurité.
• Problèmes avec les systèmes existants. De nombreuses agences gouvernementales et branches du DoD exploitent des systèmes existants qui sont utilisés depuis des années, voire des décennies. Ces systèmes n’ont peut-être pas été conçus en tenant compte des principes de sécurité modernes et leur architecture pourrait être incompatible avec certaines exigences STIG. La reconfiguration de ces systèmes existants pour répondre aux normes de sécurité actuelles peut constituer un défi de taille. Très souvent, cela implique de réécrire du code, de mettre à jour le matériel ou même de remplacer entièrement les systèmes, ce qui peut s'avérer coûteux et perturbateur.
• Documentation et rapports. La conformité DISA ASD STIG nécessite une documentation complète des configurations de sécurité, des modifications apportées et de la justification de ces modifications. Les organisations doivent conserver des dossiers détaillés pour démontrer leur adhésion aux lignes directrices. Il est essentiel de générer des rapports précis et complets à des fins d'audit, mais cela peut prendre du temps et entraîner des frais administratifs. Le fait de ne pas conserver une documentation appropriée peut entraîner des difficultés lors des audits ou lors de la résolution d'incidents de sécurité.
• Infrastructure informatique diversifiée. Les organisations gouvernementales et les composants du DoD exploitent souvent des environnements informatiques complexes et diversifiés. Ils peuvent utiliser une variété de systèmes d’exploitation, de matériel informatique, d’applications logicielles et d’équipements réseau. Chacun de ces composants peut avoir des exigences et des paramètres de sécurité différents. Par conséquent, personnaliser la mise en œuvre des directives STIG en fonction des caractéristiques spécifiques de chaque technologie peut prendre du temps et nécessiter des connaissances spécialisées et principalement des efforts manuels.
• Équilibrer sécurité et interopérabilité. La collaboration et le partage d’informations sont essentiels au sein des institutions gouvernementales et de défense. Différentes agences ou composantes doivent souvent travailler ensemble en utilisant des systèmes interconnectés. Cependant, la mise en œuvre de contrôles de sécurité stricts pour assurer la conformité pourrait entraver l’interopérabilité ou le partage de données au sein de ces agences. Le défi ici consiste donc à trouver le bon équilibre entre l’application des mesures de sécurité et le maintien d’une communication transparente. En essayant d'assurer le bon équilibre, des ajustements devront peut-être être apportés aux configurations ou aux flux de travail pour répondre aux besoins de sécurité et de collaboration.
• Surveillance et maintenance continue. La conformité n’est pas une tâche ponctuelle. Cela nécessite une surveillance et une maintenance chaque fois que le système est mis à jour pour garantir que les systèmes restent sécurisés au fil du temps. Atteindre la conformité initiale aux directives DISA ASD STIG n’est que le point de départ. L'essentiel du travail consiste à assurer une conformité continue, ce qui oblige les organisations à établir des processus de surveillance et de maintenance continues. Cela peut impliquer de revoir régulièrement les systèmes, les configurations et les mesures de sécurité pour identifier tout écart par rapport aux exigences STIG établies. Cependant, cette tâche peut s'avérer ardue en raison de facteurs tels que l'évolution des directives DISA ASD STIG, les modifications du système, l'évolution du paysage des menaces et le coût de l'effort manuel généralement nécessaire pour assurer la conformité.

Approche à trois niveaux de la conformité du développement logiciel

Pour atteindre la conformité, une approche de validation à trois niveaux est requise:

• Analyse du code d'application détecte les vulnérabilités avec des outils d'analyse statique pour assurer la correction dans l'application. L'ASD STIG a des directives spécifiques sur les classes de vulnérabilités à détecter et à corriger.
• Test du système pour la sécurité avec des outils de tests fonctionnels et d'intrusion, vérifie et valide les exigences DISA ASD STIG.
• Conformité Shift-Left avec les processus préventifs élimine les mauvaises pratiques de codage qui conduisent à des vulnérabilités. Cette zone de détection plus large inclut l’analyse des applications et l’application de normes de codage industrielles telles que le codage sécurisé OWASP, CWE ou CERT. Il comprend également des directives telles que la suppression de «le code sent», Qui sont de mauvaises pratiques connues pour être à l'origine des failles de sécurité des logiciels.

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é.

Que signifie la conformité avec DISA ASD STIG?

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.

Test de sécurité des applications statiques

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é.

Méthodes de validation DISA ASD STIG

L'ASD STIG décrit les moyens de vérifier la conformité aux exigences, notamment:

• Code d'application et numérisation des applications
• Revue manuelle
• Test de sécurité fonctionnelle

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.

Une approche pragmatique de la conformité DISA ASD STIG avec des outils d'analyse statique

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.

Satisfaire les exigences d'analyse des applications DISA ASD STIG avec analyse statique

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:

• OWASP Top 10 (V-69513)
• Débordements (V-70277)
• Conditions de course (V-70185)
• Traitement des erreurs (V-70391)

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.

Intégration avec les outils SCA

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 ++, Javaet 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.

Rapports axés sur la sécurité

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.

Assurer la conformité DISA ASD STIG avec SAST

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:

• Audits de documentation
• Rapports d'outils tels que les analyseurs statiques et autres
• Effort manuel pour enquêter sur les journaux d'application, si nécessaire

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é.