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

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.

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 à l'origine de vulnérabilités. Ce champ de détection plus large inclut l'analyse des applications et l'application des normes de codage du secteur, telles que l'OWASP, le CWE ou le codage sécurisé CERT. Il inclut également des directives telles que la suppression de « le code sent", qui sont de mauvaises pratiques connues pour être la cause principale des vulnérabilités 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 à la recherche de failles de sécurité, de codes malveillants et de portes dérobées. » — Présentation de DISA ASD STIG, section 4.1

En termes plus courants, il s'agit de tests statiques de sécurité des applications (SAST) mis en œuvre par analyse statique du code. « Ils doivent être utilisés autant que possible, en particulier dans un environnement de développement où le code identifié comme nécessitant une correction peut être traité avant sa publication. » Le STIG ASD contient également les recommandations suivantes :

Un scanner d'applications permet de tester les systèmes d'applications de développement ou de production afin de détecter les vulnérabilités de sécurité résultant d'erreurs de code ou de configurations système incorrectes. Ces vulnérabilités incluent les injections SQL, les injections de code, les scripts intersites (XSS), les divulgations de fichiers, les autorisations et d'autres vulnérabilités de sécurité présentes dans les applications accessibles par le réseau. — Présentation du DISA ASD STIG, section 4.2 – Scanner d'applications

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 audits des outils SAST pour valider les applications et l'analyse du code. Les tests fonctionnels consistent à vérifier, à l'aide d'outils automatisés ou de tests manuels, l'absence de vulnérabilité dans le logiciel. Autrement dit, il s'agit d'une approche consistant à « faire quelque chose, vérifier quelque chose ». Par exemple, vérifier si l'action a fonctionné correctement et si elle a été consignée si nécessaire. Ces approches sont adaptées aux tests automatisés en raison de leur efficacité et des outils de suivi d'audit qu'ils fournissent.

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 STIG DISA ASD utilise le terme « analyse d'application », qui englobe l'analyse statique du code et les technologies associées, telles que l'analyse de la composition logicielle. Outre l'exigence générale d'évaluation des vulnérabilités par analyse statique du code, des exigences spécifiques s'appliquent à l'analyse de 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.

Tableau de bord Parasoft DISA ASD STIG

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.

Rapport de conformité Parasoft OWASP Top 10

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