Introduction au DoDAF dans la documentation d'architecture de sécurité

Le cadre d'architecture du Département de la défense (DoDAF) sert d'outil fondamental pour décrire les architectures d'entreprise dans l'ensemble du Département de la défense des États-Unis. Appliquée à l'architecture de sécurité, le DoDAF offre une méthode disciplinée et structurée pour documenter les relations complexes entre les contrôles de sécurité, les composantes du système, les missions opérationnelles et les paysages de menaces. Ce cadre n'est pas seulement un ensemble de diagrammes; il s'agit d'une approche globale pour s'assurer que les considérations de sécurité sont intégrées dans chaque couche de conception du système, de la planification des capacités à la mise en oeuvre et au maintien en état.

Sans cadre structuré, la documentation de sécurité devient souvent fragmentée, incohérente ou déconnectée du contexte système plus large. DoDAF s'attaque à cette question en offrant des vues et des méta-modèles normalisés qui forcent l'exhaustivité, la traçabilité et la cohérence. Pour les organisations qui naviguent sur les complexités de l'acquisition de défense, l'adoption de DoDAF pour l'architecture de sécurité n'est pas facultative.

Points de vue DoDAF de base relatifs à l'architecture de sécurité

Pour l'architecture de sécurité, tous les points de vue ne sont pas également importants, mais un ensemble de documents exhaustifs s'inspirera de points de vue multiples pour créer une image complète. Comprendre quels points de vue utiliser et comment les adapter aux préoccupations de sécurité est la première pratique optimale.

Tous les points de vue (AV) – Contexte et portée

Le point de vue All fournit un contexte global, y compris le but, la portée, les hypothèses et les contraintes de l'architecture. Les architectes de sécurité devraient utiliser l'AV-1 (Aperçu général et sommaire) pour énoncer explicitement les objectifs de sécurité, les mandats réglementaires et les hypothèses de menace qui animent l'architecture. L'AV-2 (Dictionnaire intégré) est essentiel pour définir les termes liés à la sécurité de façon cohérente dans l'ensemble de la documentation, éliminant la confusion sur les termes comme -l'autorisation limite, -------------------------------------------------------------------------------------------------------------------------------------------

Point de vue sur les capacités (CV) – Ce que le système doit accomplir

Pour la sécurité, cela inclut des capacités telles que la gestion de l'identité, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Point de vue opérationnel (OV) – Comment fonctionne la sécurité dans le contexte de la mission

Les points de vue opérationnels spécifiques à la sécurité aident à illustrer comment les fonctions de sécurité, telles que l'authentification, l'autorisation, la vérification et la gestion des incidents, sont intégrées dans les flux de travail des missions. OV-1 (High-Level Operational Concept Graphic) peut montrer où il existe des points de contrôle de sécurité dans une chaîne de destruction ou un cycle de vie d'acquisition. OV-5 (Activity Model) est particulièrement utile pour documenter les activités opérationnelles de sécurité, y compris les procédures de balayage de vulnérabilité, de gestion des patchs et de centre d'opérations de sécurité (SOC).

Point de vue des systèmes (SV) – Mise en œuvre technique des contrôles de sécurité

SV-1 (Description de l'interface système) montre comment les appareils de sécurité, les appareils cryptographiques, les fournisseurs d'identité et les outils de surveillance se connectent. SV-4 (Description de la fonctionnalité système) décompose les fonctions que les systèmes de sécurité exécutent. En utilisant ces vues, les architectes peuvent tracer un contrôle de sécurité (p. ex., cryptage) de ses besoins opérationnels (OV) à la conception du système (SV) jusqu'à la mise en œuvre physique.

Point de vue des données et des informations (DIV) – Protéger les données au repos et en mouvement

Les architectes de la sécurité utilisent le DIV-1 (modèle de données conceptuelles) pour identifier et classer les éléments de données sensibles. Le DIV-2 (modèle de données logiques) spécifie les attributs de données pertinents à la sécurité, tels que les marquages de classification, les listes de contrôle d'accès et les hachages d'intégrité. Le DIV-3 (modèle de données physiologiques) traite des schémas de stockage et des mécanismes de chiffrement réels.

Autres points de vue avec pertinence de sécurité

Bien que moins souvent souligné, le Project Viewpoint (PV) peut saisir les étapes de sécurité et les contraintes en matière de ressources, et le Standards Viewpoint (StdV) peut énumérer l'applicabilité des normes NIST, ISO et FedRAMP. Le Service Viewpoint (SvcV) est utile pour les architectures axées sur le service où la sécurité est fournie comme service, comme les courtiers en sécurité d'accès au cloud (CASB) ou la gestion d'informations et d'événements de sécurité (SIEM) comme service.

Meilleure pratique 1: Définir des objectifs clairs en matière de sécurité avec traçabilité

Chaque effort d'architecture de sécurité doit commencer par des objectifs de sécurité clairement définis et alignés sur la mission. Ces objectifs vont au-delà des énoncés génériques comme -protect data- , et au contraire spécifier les résultats qui peuvent être mesurés, vérifiés et liés aux vues DoDAF. Par exemple, un objectif peut être --Assurer que toutes les données critiques de mission en transit entre les nœuds tactiques sont chiffrées à l'aide d'AES-256-GCM, avec des clés gérées via un module de sécurité matérielle (HSM).

Les objectifs de sécurité devraient être consignés dans l'AV-1 et affinés dans le CV-1. Il faut les tracer à travers l'architecture pour montrer comment chaque objectif mène à des activités opérationnelles spécifiques (OV-5), des capacités système (SV-4) et des protections de données (DIV-2). L'établissement de cette chaîne de traçabilité prévient rapidement le fluage de la portée et garantit que l'architecture de sécurité ne se déconnecte pas des besoins réels de la mission.

Meilleure pratique 2: Sélectionner et adapter les vues DoDAF pour la pertinence de la sécurité

L'utilisation de chaque vue DoDAF disponible par défaut conduit à une documentation gonflée et inutile. Au lieu de cela, les architectes de sécurité ne doivent sélectionner que les vues qui servent directement les besoins de communication et d'analyse de sécurité.

  • AV-1 pour établir la portée des objectifs et des hypothèses en matière de sécurité.
  • CV-2 pour la taxonomie de la capacité de sécurité.
  • OV-1 et OV-5 pour les processus de sécurité opérationnels.
  • SV-1 et SV-4 pour les fonctions et les interconnexions de sécurité du système.
  • DIV-2 pour les exigences de classification et de protection des données.
  • StdV-1 pour les normes de sécurité appliquées.

Par exemple, sur un diagramme SV-1, inclure des attributs de sécurité tels que la force de chiffrement, la méthode d'authentification et la limite de conformité sur les lignes d'interface. Sur OV-5, les activités de code couleur qui déclenchent des événements de sécurité ou nécessitent un accès privilégié. Cette adaptation devrait être décrite et justifiée dans l'AV-1 afin que les évaluateurs comprennent les conventions.

Pratique exemplaire 3 : Intégrer les normes et les cadres de sécurité

L'architecture de sécurité produite indépendamment des normes établies comme la publication spéciale 800-53 du NIST, ISO/IEC 27001, le cadre de gestion des risques du DoD (RMF) et la certification du modèle de maturité de la cybersécurité (CMMC) échoueront inévitablement au cours de l'accréditation ou de l'audit. Le DoDAF fournit un mécanisme naturel pour la cartographie de ces normes externes sur des éléments architecturaux.

Par exemple, la carte NIST 800-53 contrôle AU-3 (Contenu des dossiers d'audit) à une activité OV-5 -Génère le journal d'audit et une fonction SV-4 -Sécurité d'enregistrement , , , spécifie ensuite les attributs de données dans DIV-2 qui définissent les champs contenus dans le dossier d'audit. Cette cartographie crée une matrice de traçabilité prête à l'audit que les évaluateurs de sécurité peuvent inspecter directement à partir de la documentation d'architecture. De plus, s'aligner sur la Intelligence Community , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Pratique exemplaire 4 : Maintenir la cohérence dans la terminologie et la notation

Chaque discipline a son propre jargon, qui peut mener à des interprétations contradictoires. L'AV-2 (Dictionnaire intégré) est l'outil d'architecte de sécurité pour faire respecter la cohérence. Chaque terme spécifique à la sécurité—authentification[, autorisation[, non-répudiation[, encryption[, contrôle compensateur[—doit être défini une fois et utilisé de façon cohérente dans toutes les vues. Si l'architecture utilise des termes comme --- et -[ contre-mesure=] interchangeablement, document dans l'AV-2 qu'ils sont synonymes pour cette architecture.

La cohérence de la notation est également importante. Que l'on utilise UML, SysML, IDEF0 ou BPMN pour différentes vues, il faut que le style de notation, les types de lignes, les palettes de couleurs et les ensembles d'icônes soient normalisés dans le jeu de documentation. Les architectes de sécurité devraient créer un guide de style spécifique à l'architecture de sécurité – par exemple, en utilisant le rouge pour les contrôles de sécurité physiques, le bleu pour les contrôles logiques et le vert pour les contrôles administratifs.

Pratique exemplaire 5 : Mettre à jour régulièrement la documentation pour refléter le changement

Pour demeurer utile, la documentation sur l'architecture doit être un artefact vivant qui subit une gestion de configuration disciplinée. Établir une cadence pour les examens – trimestriel pour les programmes actifs, chaque année pour les systèmes à état stationnaire – et relier les mises à jour à la phase de surveillance continue du FGR DoD. Chaque mise à jour devrait comprendre un journal des changements qui identifie les changements, les raisons et les vues qui ont été touchés.

Par exemple, si un modèle d'appareil de sécurité en SV-1 est remplacé par un nouveau produit, le changement devrait être propagé aux activités OV-5 qui dépendent de cet appareil et aux attributs de données DIV-2 qui utilisent ses capacités de chiffrement. Sans cette automatisation, les mises à jour manuelles risquent de laisser des informations inexistantes qui trompent les intervenants et ne vérifient pas la conformité. Les programmes DoD nécessitent souvent un plan de gestion de la configuration de l'architecture, qui devrait traiter explicitement des déclencheurs de mise à jour de l'architecture de sécurité et des flux de travail d'approbation.

Meilleure pratique 6 : Engager des équipes interdisciplinaires

La documentation efficace de sécurité du DoDAF exige une collaboration entre les ingénieurs de sécurité, les architectes de systèmes, les propriétaires de missions, les professionnels de l'acquisition, les ingénieurs de réseau et les agents de protection de la vie privée. Chaque intervenant apporte une perspective unique qui influence les vues et le niveau de détail. Par exemple, les propriétaires de missions peuvent valider que les graphiques de concepts opérationnels OV-1 représentent fidèlement les points de contrôle de sécurité; les ingénieurs de réseau peuvent confirmer que les définitions d'interface SV-1 respectent les contraintes de routage et de bande passante imposées par les frais généraux de chiffrement.

Lorsqu'il s'agit de constituer une équipe interdisciplinaire, assignez un architecte responsable de la sécurité responsable de la cohérence des vues de sécurité dans l'ensemble de la documentation. Cette personne doit être compétente dans les domaines de la méthodologie et de la cybersécurité du DoDAF. Inclure également un délégué aux données qui peut s'assurer que les vues du DIV sont correctement classifiées et contrôlées par l'accès.

Pratique exemplaire 7: Tirer parti des diagrammes visuels et des récits

Pour améliorer la communication, investir dans des diagrammes de haute qualité qui racontent une histoire claire. Par exemple, un graphique OV-1 pourrait utiliser des icônes pour dépeindre les utilisateurs, les attaquants, les défenses et les flux de données dans un scénario de mission, avec un codage en couleur pour indiquer les limites de confiance. Un diagramme réseau SV-1 devrait clairement montrer les pare-feu, les fournisseurs d'identité, les passerelles de chiffrement et les sondes de surveillance, y compris les types de connexion et les annotations de protocole.

Pour les cadres supérieurs, créez un résumé des vues qui met en évidence les principales capacités de sécurité et les postures de risque.Pour les équipes techniques, produisez des vues détaillées avec les paramètres de configuration et les spécifications de l'interface. Utilisez des fils narratifs cohérents : par exemple, -Un utilisateur authentifie par CAC (OV-5) → le processus d'identité appelle le service PKI (SV-4) → les certificats sont stockés dans un data store (DIV-3) crypté avec un algorithme validé FIPS 140-2. - Ce narratif peut être présenté comme une suite d'étapes soulignées sur une série de vues liées.

Relever les défis communs dans la documentation de sécurité du DoDAF

Même avec les meilleures pratiques en place, les praticiens rencontrent des difficultés récurrentes. Un défi est la tension entre l'exhaustivité et la lisibilité. Les architectes de la sécurité se sentent souvent pressés de documenter chaque contrôle possible, conduisant à des ensembles de vues massives que personne ne lit. La solution est de prioriser – tous les contrôles n'ont pas besoin de leur propre vue.

Un troisième défi consiste à gérer des relations de sécurité dynamiques telles que des architectures de confiance zéro où les frontières de confiance changent en fonction du contexte. Les vues traditionnelles du DoDAF, conçues pour les systèmes statiques, peuvent devoir être complétées par des vues basées sur les capacités qui décrivent des comportements adaptatifs. Les architectes peuvent étendre le DoDAF en ajoutant des diagrammes de machine d'état ou en utilisant des cas dans le point de vue OV pour saisir des décisions de confiance dynamiques.

Outils et technologies pour l'architecture de sécurité DoDAF

Choisir la bonne chaîne d'outils est un multiplicateur de force. Les outils d'architecture d'entreprise qui supportent directement DoDAF et DM2 incluent IBM Rational System Architect[, Aucun modèle de systèmes Cameo magique, et Sparx Enterprise Architect avec add-on .Ces outils permettent la création de données conformes DM2, la génération de matrices de traçabilité et la validation automatisée.Pour une analyse spécifique à la sécurité, intégrer des outils comme NIST=S National Vulnerability Database pour l'importation de données de menace ou MITRE ATT&CK[ pour la cartographie des tactiques adverses aux activités OV-5.

Exporter les vues en format PDF haute résolution avec un index cliquable pour les grands documents. Maintenir un portail d'architecture en ligne (p. ex., en utilisant SharePoint ou Confluence) qui permet l'accès en lecture aux dernières versions, avec des balises de métadonnées pour la classification de sécurité. La documentation doit être contrôlée en version et sauvegardée conformément aux politiques de sécurité informatique du programme. Pour la collaboration basée sur le cloud, s'assurer que le portail d'architecture est hébergé dans un environnement autorisé (p. ex., les environnements DoD=s milCloud ou Impact Niveau 4/5) pour protéger les informations sensibles.

Conclusion

En définissant des objectifs clairs, en choisissant des points de vue appropriés, en intégrant des normes, en maintenant la cohérence, en embrassant le changement, en collaborant largement et en utilisant des visuels puissants, les architectes de sécurité peuvent créer des documents qui non seulement répondent aux exigences d'acquisition mais améliorent aussi véritablement la posture de sécurité. L'investissement dans la documentation d'architecture de haute qualité basée sur le DODAF verse des dividendes tout au long du cycle de vie du système – pendant le développement, les essais, l'accréditation, les opérations et la modernisation.

Pour plus de précisions, voir le catalogue de contrôle du DoDAF 2.02 et le NIST SP 800-53 Rev. 5. Ces ressources fournissent le contexte et les détails autorisés nécessaires pour mettre en œuvre les pratiques décrites ici avec précision.