Comment rédiger un Plan de Sécurité Système (SSP) efficace : Une approche stratégique pour la conformité CMMC

Le Plan de Sécurité du Système (plan de sécurité du système) joue un rôle crucial pour déterminer si un sous-traitant de la défense est prêt à gérer, partager et stocker des informations non classifiées contrôlées (CUI). En conséquence, il constitue une partie vitale du processus de conformité au modèle de certification de la maturité en cybersécurité (CMMC).

La préparation efficace du SSP nécessite une approche complète pour documenter les mesures et pratiques de sécurité que votre organisation adopte pour protéger ses actifs informationnels. La rédaction du SSP pour le CMMC implique de détailler des contrôles de sécurité spécifiques, d’assigner des rôles responsables et de délimiter les frontières du système.

De plus, il est essentiel de mettre régulièrement à jour le SSP pour refléter tout changement dans l’infrastructure du système ou la posture de sécurité. En abordant méticuleusement ces domaines, les organisations peuvent améliorer leur préparation aux évaluations CMMC et s’assurer qu’elles répondent aux normes rigoureuses établies pour sécuriser le CUI.

Ce guide révèle pourquoi votre SSP est bien plus qu’une simple documentation—c’est la base stratégique qui peut faire ou défaire vos efforts de certification CMMC.

Qu’est-ce qu’un Plan de Sécurité du Système (SSP) ?

Un Plan de Sécurité du Système est un document formel qui fournit une vue d’ensemble des exigences de sécurité d’une organisation et décrit les contrôles en place ou prévus pour répondre à ces exigences. Pour les sous-traitants de la défense manipulant des Informations Non Classifiées Contrôlées (CUI), le SSP documente spécifiquement comment votre organisation met en œuvre les exigences de sécurité décrites dans NIST 800-171.

Le SSP n’est pas simplement une case à cocher pour la conformité ; il sert de registre autoritaire de la posture de cybersécurité de votre organisation, détaillant :

• Les limites de votre système d’information
• Les contrôles de sécurité mis en œuvre dans ce système
• Comment ces contrôles sont mis en œuvre
• Qui est responsable du maintien de la sécurité
• Comment votre programme de sécurité fonctionne au quotidien

Alors que le Département de la Défense (DoD) renforce la sécurité de sa supply chain via le CMMC, votre SSP se transforme d’un document statique en une feuille de route vivante de votre programme de sécurité.

Différences entre les SSP et les Politiques de Sécurité

Bien qu’ils soient liés, un Plan de Sécurité du Système (SSP) et les politiques de sécurité organisationnelles servent des objectifs distincts.

Les politiques de sécurité sont des documents de haut niveau établissant l’intention de la direction, les attentes et les règles générales pour la sécurité à travers l’organisation. Elles définissent le ‘quoi’ – par exemple, une politique pourrait stipuler, “L’accès aux dépôts de données sensibles doit être restreint selon le principe du moindre privilège.” Les politiques fixent la direction et le cadre de gouvernance.

En revanche, le plan de sécurité du système est un document détaillé et spécifique au système décrivant le ‘comment, où, quand et qui’ de la mise en œuvre des contrôles de sécurité pour un système d’information particulier manipulant le CUI. Il traduit les exigences politiques en actions concrètes dans des limites de système définies. Par exemple, correspondant à l’exemple de politique ci-dessus, le SSP détaillerait : “L’accès au partage de fichiers CUI (\\SERVER01\CUI_Data) est contrôlé via des groupes de sécurité Active Directory. Le groupe ‘CUI_Users_ProjectX’, géré par l’administrateur IT Jane Smith, accorde un accès en lecture/écriture. Les demandes d’accès nécessitent l’approbation du manager via un ticket Service Desk (Procédure SD-015) et sont examinées trimestriellement par le propriétaire des données, Mark Lee.”

Une idée fausse courante est de considérer le SSP comme une simple collection de politiques ; en réalité, c’est un plan de mise en œuvre détaillé qui décrit la posture de sécurité d’un système spécifique, en se référant aux politiques mais en fournissant des détails opérationnels beaucoup plus profonds essentiels pour démontrer la conformité, en particulier pour un SSP pour l’évaluation CMMC.

Pourquoi les SSP sont importants

L’importance d’un SSP bien conçu va bien au-delà de la simple conformité. Votre SSP sert d’outil de gestion des risques qui fournit une approche systématique pour identifier, évaluer et gérer les risques de sécurité. En documentant minutieusement vos contrôles de sécurité, vous créez une visibilité sur les vulnérabilités potentielles et établissez un cadre robuste pour les traiter avant qu’elles ne puissent être exploitées.

Pour vos équipes techniques, le SSP fonctionne comme un guide de mise en œuvre autoritaire qui dirige le déploiement et la configuration des contrôles de sécurité dans votre environnement. Cette orientation garantit la cohérence dans votre mise en œuvre de la sécurité et aide à prévenir les dérives de configuration qui pourraient introduire des vulnérabilités. Lors des évaluations CMMC, ce même document devient votre preuve principale démontrant la mise en œuvre par votre organisation des pratiques de sécurité requises aux évaluateurs.

Au-delà de ses fonctions techniques et de conformité, votre SSP agit également comme un atout de continuité des activités qui aide à garantir la résilience opérationnelle en documentant les procédures de sécurité qui protègent les informations critiques et permettent une récupération rapide des incidents de sécurité. Peut-être plus important encore, le SSP sert de pont de communication, fournissant une articulation claire de votre programme de sécurité qui facilite la compréhension entre le personnel technique, la direction et les évaluateurs externes.

Un SSP inadéquat peut entraîner des évaluations échouées, des certifications retardées, des contrats perdus et, finalement, des pertes financières. À l’inverse, un SSP bien développé accélère votre chemin vers la certification et offre des avantages de sécurité durables au-delà de la conformité.

Exigences du SSP selon les niveaux CMMC

Comprendre quel niveau CMMC nécessite un SSP est crucial pour la planification de la conformité :

• CMMC Niveau 1 : Un SSP n’est pas requis pour la certification de niveau 1. Les organisations doivent mettre en œuvre 17 pratiques de sauvegarde de base, mais la documentation formelle dans un format SSP n’est pas obligatoire.
• CMMC Niveau 2 : Un SSP est requis pour la certification de niveau 2. Les organisations doivent développer et maintenir un SSP complet qui documente la mise en œuvre de 110 pratiques de sécurité dérivées du NIST SP 800-171.
• CMMC Niveau 3 : Un SSP est requis pour la certification de niveau 3. Le SSP à ce niveau doit documenter la mise en œuvre de pratiques de sécurité avancées supplémentaires au-delà des exigences de niveau 2.

Pour les organisations cherchant à obtenir la certification de niveau 2 ou 3, le SSP sert d’artefact fondamental que les C3PAO évalueront lors d’une évaluation. Il fournit la feuille de route qui guide les évaluateurs à travers votre mise en œuvre de la cybersécurité et démontre votre compréhension des exigences de sécurité.

Au cours du processus d’évaluation, votre SSP sert de fondation pour une certification réussie. Avant même que les évaluateurs n’arrivent dans vos locaux, ils examineront minutieusement votre SSP pour comprendre votre environnement et préparer leur approche d’évaluation, faisant de ce document leur première impression de votre programme de sécurité. Au fur et à mesure que l’évaluation progresse, les évaluateurs compareront méthodiquement vos contrôles documentés à votre mise en œuvre réelle pour vérifier l’alignement, en utilisant le SSP comme leur feuille de route à travers votre paysage de sécurité complexe.

Toute divergence découverte entre votre SSP et les contrôles mis en œuvre sera signalée comme des lacunes potentielles nécessitant une correction, mettant potentiellement en péril la certification si elles sont significatives ou nombreuses. Un SSP clair et complet simplifie considérablement ce processus, réduisant potentiellement à la fois le temps d’évaluation et les coûts associés tout en démontrant la maturité de la sécurité de votre organisation. Dans les cas où la conformité complète n’a pas encore été atteinte, votre SSP fournit un contexte essentiel pour développer des Plans d’Action et des Jalons (POA&M) réalistes et efficaces qui peuvent satisfaire les exigences des évaluateurs.

Pour réussir la certification CMMC, votre SSP doit être précis, complet et refléter vos pratiques de sécurité réelles—les évaluateurs vérifieront que “vous faites ce que vous documentez, et documentez ce que vous faites.”

Le processus de certification CMMC est ardu mais notre feuille de route de conformité CMMC 2.0 peut vous aider.

La Fondation NIST SP 800-171 pour les SSP CMMC

Le Plan de Sécurité du Système requis pour les niveaux 2 et 3 du CMMC provient directement des exigences décrites dans NIST 800-171, “Protection des Informations Non Classifiées Contrôlées dans les Systèmes et Organisations Non Fédéraux.” Cette norme NIST forme l’épine dorsale des exigences de sécurité du CMMC.

Spécifiquement, le niveau 2 du CMMC se mappe directement aux 110 contrôles de sécurité détaillés dans le NIST SP 800-171. Une exigence centrale au sein du NIST SP 800-171 lui-même (Contrôle 3.12.4, famille d’évaluation de la sécurité) exige que les organisations “développent, documentent et maintiennent un plan de sécurité du système qui décrit les limites du système, les environnements d’exploitation du système, comment les exigences de sécurité sont mises en œuvre, et les relations avec ou les connexions à d’autres systèmes.” Par conséquent, le SSP pour le CMMC est essentiellement le plan de sécurité du système NIST SP 800-171 axé sur la protection du CUI.

L’annexe E du NIST SP 800-171 fournit un contenu et une structure suggérés pour ce plan, décrivant des sections clés telles que l’Identification du Système, l’Environnement d’Exploitation du Système et la Mise en Œuvre des Exigences de Sécurité. Les organisations développant leur SSP pour le CMMC devraient fortement s’appuyer sur le NIST SP 800-171 et les ressources associées du NIST (comme le NIST Handbook 162 pour les procédures d’évaluation) pour s’assurer que tous les éléments requis sont abordés de manière exhaustive, car les évaluateurs évalueront le SSP par rapport à ces normes fondamentales.

Composants Clés d’un SSP Efficace

Un SSP conforme et utile contient plusieurs éléments essentiels qui travaillent ensemble pour présenter une vue d’ensemble de votre programme de sécurité. À sa base, le SSP doit inclure une identification et une définition des limites du système qui articulent clairement le but, les limites et les interconnexions du système d’information. Cette section fondamentale devrait incorporer des diagrammes de réseau détaillés, des diagrammes de flux de données et des inventaires de systèmes qui délimitent précisément les environnements CUI des systèmes commerciaux généraux.

Le cœur de votre SSP réside dans ses déclarations de mise en œuvre des contrôles de sécurité. Pour chaque contrôle applicable NIST 800-171, votre SSP devrait fournir des descriptions détaillées expliquant comment le contrôle est mis en œuvre, où il est mis en œuvre à travers vos composants ou systèmes, qui est responsable du maintien du contrôle, quand les activités de contrôle sont effectuées, et quelles preuves spécifiques démontrent la conformité. Ces déclarations de mise en œuvre forment le contenu principal que les évaluateurs évalueront lors de la certification.

Votre SSP doit également documenter la structure organisationnelle soutenant votre programme de sécurité en détaillant des rôles de sécurité spécifiques, des responsabilités et des informations de contact pour le personnel clé. Cela devrait être complété par des descriptions complètes de l’architecture du système d’information couvrant le matériel, les logiciels, l’architecture réseau, les domaines de sécurité et les relations de confiance qui définissent votre environnement.

Le contexte opérationnel de votre système est tout aussi important. Votre SSP devrait documenter de manière exhaustive l’environnement de sécurité technique, physique et personnel dans lequel le système fonctionne, ainsi que des détails spécifiques sur la façon dont le CUI est identifié, marqué, manipulé, stocké, traité et transmis tout au long de son cycle de vie. Cette section de sécurité des données s’avère particulièrement critique pour les évaluations CMMC axées sur la protection du CUI.

Pour démontrer un engagement continu en matière de sécurité, incluez une stratégie de surveillance continue détaillée qui décrit votre approche de l’évaluation continue des contrôles, de la gestion des vulnérabilités et du reporting de l’état de la sécurité. Enfin, référencez toute la documentation de support telle que les politiques, procédures et configurations techniques qui étayent vos affirmations de mise en œuvre des contrôles et fournissent un contexte supplémentaire pour les évaluateurs.

Le SSP devrait être organisé pour faciliter à la fois la supervision de la gestion et la mise en œuvre technique, servant de source unique de vérité pour votre programme de cybersécurité.

Processus et Critères d’Évaluation du SSP

Lors d’une évaluation CMMC, l’Organisation d’Évaluation Tiers CMMC (C3PAO) évalue rigoureusement le Plan de Sécurité du Système (SSP).

Le processus commence généralement par une revue documentaire pré-évaluation où les évaluateurs examinent le SSP pour en vérifier l’exhaustivité, la clarté et l’exactitude apparente. Ils recherchent spécifiquement : des descriptions détaillées pour chaque pratique CMMC applicable (dérivée du NIST SP 800-171 pour le niveau 2), une limite de système clairement définie, une représentation précise de l’environnement du système, l’identification du personnel responsable, et des références aux preuves de support (politiques, procédures, configurations).

Les raisons courantes pour lesquelles les SSP échouent à l’évaluation incluent des descriptions de contrôle vagues ou génériques, une documentation de pratique manquante, des informations obsolètes qui ne correspondent pas à l’environnement actuel, des limites de système mal définies ou inexactes, un manque de preuves référencées, ou une dépendance excessive sur des Plans d’Action et Jalons immatures (POA&Ms).

Après la revue documentaire, lors de l’évaluation elle-même (souvent impliquant des composants sur site ou à distance), les évaluateurs valident les affirmations du SSP par des entretiens avec le personnel clé (personnel IT, direction, utilisateurs) et des méthodes de vérification technique comme l’examen des configurations système, l’observation des processus, la révision des journaux et l’inspection des mesures de sécurité physique. Ils confirment que l’organisation “fait ce qu’elle documente.”

Un plan de sécurité du système prêt pour la certification est actuel, complet, très détaillé, reflète avec précision les contrôles mis en œuvre, référence directement les preuves de support, et s’aligne parfaitement avec la réalité opérationnelle vérifiée lors des entretiens d’évaluation et des vérifications techniques.

Top 10 des Meilleures Pratiques pour Rédiger un SSP Efficace

Basé sur notre expérience d’évaluation de centaines de sous-traitants de la défense, nous avons identifié ces meilleures pratiques critiques pour développer un SSP qui soutiendra vos efforts de certification CMMC :

1. Définir des Limites de Système Claires

Délimitez précisément ce qui est dans le périmètre par rapport à ce qui est hors périmètre pour votre environnement CUI. De nombreux échecs d’évaluation proviennent de limites ambiguës qui laissent les évaluateurs incertains quant à l’endroit où les contrôles doivent être appliqués.

Approche Recommandée : Créez des diagrammes de réseau détaillés qui identifient précisément les limites de votre environnement CUI avec des distinctions visuelles claires pour tous les points d’entrée et de sortie, les domaines de sécurité et les relations de confiance. Utilisez un codage visuel cohérent, tel que des schémas de couleurs, pour distinguer les environnements CUI des systèmes commerciaux généraux, rendant les limites immédiatement apparentes à la fois pour votre équipe et les évaluateurs. Ces diagrammes devraient être complétés par des descriptions textuelles explicites qui ne laissent aucune place à l’ambiguïté quant aux systèmes qui relèvent du périmètre des contrôles CMMC. Mettez à jour ces définitions de limites chaque fois que votre environnement change pour garantir une précision continue tout au long de votre parcours de certification.

Piège à Éviter : Ne faites pas en sorte que votre limite soit si large qu’elle englobe des systèmes inutiles pour le traitement du CUI, car cela élargit inutilement votre périmètre de conformité.

2. Fournir des Descriptions Détaillées de la Mise en Œuvre des Contrôles

Des déclarations génériques comme “nous utilisons le chiffrement” ou “nous avons des pare-feu” sont insuffisantes. Les évaluateurs ont besoin de détails spécifiques sur la façon dont chaque contrôle est mis en œuvre dans votre environnement.

Approche Recommandée : Pour chaque contrôle, développez des descriptions complètes qui articulent précisément comment les objectifs de contrôle sont atteints dans votre environnement spécifique. Détaillez les technologies ou processus exacts employés, y compris les noms de fournisseurs, les versions et les configurations spécifiques qui satisfont aux exigences de sécurité. Expliquez comment chaque solution est configurée et gérée pour répondre à l’objectif de contrôle spécifique, allant au-delà des simples mentions technologiques pour décrire les processus opérationnels. Documentez comment ces contrôles sont surveillés pour leur efficacité et à quelle fréquence ils font l’objet d’une révision pour garantir une conformité continue. Incluez suffisamment de spécificité technique pour qu’un autre professionnel de la sécurité puisse comprendre et valider votre mise en œuvre sans nécessiter d’explication supplémentaire.

Exemple : Pour le contrôle d’accès (AC.L2-3.1.1), au lieu de déclarer “Nous limitons l’accès au système aux utilisateurs autorisés,” fournissez des détails tels que : “L’accès aux systèmes CUI nécessite une authentification multifactorielle utilisant des jetons matériels Yubikey en conjonction avec des mots de passe complexes (minimum 12 caractères). Toutes les demandes d’accès suivent la procédure de gestion des accès (AMP-201) nécessitant une approbation documentée de la direction et une révision trimestrielle.”

3. Inclure des Références à la Documentation et aux Preuves de Support

Votre SSP devrait référencer les politiques, procédures et preuves spécifiques qui soutiennent chaque mise en œuvre de contrôle.

Approche Recommandée : Développez un système de référencement complet qui crée des connexions claires entre votre SSP et toute la documentation de support. Pour chaque déclaration de mise en œuvre de contrôle, incluez des références précises aux documents de politique formels pertinents avec des IDs de document spécifiques et des numéros de section qui autorisent le contrôle. Référencez les procédures opérationnelles détaillées qui mettent en œuvre chaque exigence politique, garantissant la traçabilité de la gouvernance de haut niveau aux pratiques quotidiennes. Incluez des citations aux normes techniques ou aux bases de sécurité applicables qui guident les décisions de mise en œuvre. Documentez les emplacements spécifiques où les preuves de support peuvent être trouvées, créant une carte des preuves qui facilite une évaluation efficace sans intégrer de données sensibles dans le SSP lui-même. Cette architecture de référence garantit que votre SSP sert d’outil de navigation efficace à travers votre écosystème de documentation de sécurité plus large.

Piège à Éviter : N’incluez pas d’informations sensibles comme des identifiants réels, des clés privées ou des configurations de sécurité détaillées dans le SSP lui-même.

4. Traiter Correctement les POA&Ms

Aucune organisation ne met en œuvre parfaitement chaque contrôle dès le premier jour. Les Plans d’Action et Jalons (POA&Ms) documentent votre approche pour traiter les lacunes identifiées.

Approche Recommandée : Développez une approche structurée pour documenter les lacunes de conformité qui démontre votre engagement envers l’amélioration continue. Pour chaque lacune identifiée, créez une entrée POA&M qui référence explicitement l’exigence de contrôle spécifique non entièrement mise en œuvre, en utilisant des identifiants cohérents qui s’alignent avec la structure de votre SSP. Fournissez une description détaillée de l’état actuel qui articule clairement la nature précise de la lacune de conformité sans minimiser son importance. Documentez des plans de remédiation complets avec des actions techniques et procédurales spécifiques qui traiteront entièrement la lacune, décomposées en jalons logiques. Assignez une responsabilité claire pour la mise en œuvre à des individus ayant l’autorité et la capacité technique appropriées. Établissez des délais réalistes qui reflètent à la fois le niveau de risque de la lacune et la complexité de la remédiation, démontrant l’urgence pour les éléments à haut risque tout en reconnaissant les contraintes de mise en œuvre.

Perspicacité Critique : Bien que les POA&Ms soient autorisés, ils devraient traiter une minorité de contrôles. Un excès de POA&Ms indique un programme de sécurité qui n’est pas suffisamment mature pour la certification.

5. Maintenir une Mise en Forme et une Organisation Cohérentes

Un SSP bien organisé facilite à la fois les processus de développement et d’évaluation.

Approche Recommandée : Mettez en œuvre un cadre de documentation standardisé qui améliore la navigation et la compréhension de vos contrôles de sécurité. Adoptez un format de description de contrôle cohérent qui présente chaque exigence de sécurité dans le même schéma structurel, permettant aux évaluateurs de localiser rapidement des informations spécifiques à travers plusieurs contrôles. Utilisez un système de numérotation qui s’aligne directement avec les identifiants de contrôle NIST 800-171, créant une traçabilité immédiate entre les exigences et les mises en œuvre. Développez une table des matières complète avec une organisation hiérarchique et des hyperliens qui permettent une navigation efficace à travers votre document. Utilisez des annexes pour des informations supplémentaires qui fournissent un contexte important sans perturber le flux principal du document. Considérez des éléments visuels comme des tableaux, des diagrammes et une mise en forme cohérente pour améliorer la lisibilité et mettre en évidence les informations clés, rendant votre SSP à la fois techniquement précis et accessible à divers intervenants.

Recommandation d’Outil : Envisagez d’utiliser le modèle SSP gratuit du NIST comme point de départ, en le personnalisant selon les besoins de votre organisation.

6. Mettre à Jour Régulièrement pour Refléter les Changements du Système

Votre SSP est un document vivant qui doit évoluer à mesure que vos systèmes et contrôles de sécurité changent.

Approche Recommandée : Établissez un processus formel de gestion des changements spécifiquement pour maintenir l’exactitude du SSP tout au long de l’évolution de votre programme de sécurité. Mettez en œuvre des procédures de révision documentées qui déclenchent automatiquement des évaluations du SSP après des changements significatifs du système, garantissant que la documentation technique reste alignée avec la mise en œuvre réelle. Effectuez des révisions trimestrielles complètes au minimum pour identifier tout changement progressif qui pourrait autrement ne pas être documenté. Maintenez une documentation détaillée de toutes les activités de révision et approbations, créant une piste d’audit de la maintenance du SSP qui démontre une gouvernance continue. Mettez en œuvre un contrôle de version robuste pour le SSP et tous les documents de support pour fournir un enregistrement historique clair de l’évolution des contrôles de sécurité au fil du temps. Cette approche disciplinée de la maintenance du SSP garantit que votre documentation de conformité reflète en permanence votre environnement actuel plutôt que de devenir une image de plus en plus inexacte des pratiques passées.

Piège à Éviter : Un SSP obsolète qui ne reflète pas votre environnement actuel compromettra le succès de l’évaluation et pourrait entraîner des vulnérabilités de sécurité.

7. Impliquer les Parties Prenantes Interfonctionnelles

Les contrôles de sécurité couvrent les domaines techniques, physiques et administratifs, nécessitant l’apport de l’ensemble de votre organisation.

Approche Recommandée : Créez une équipe de développement SSP multidisciplinaire qui rassemble l’expertise de l’ensemble du paysage opérationnel de votre organisation. Incluez du personnel de sécurité IT dédié qui comprend les objectifs de contrôle et les mises en œuvre techniques aux côtés des administrateurs système qui gèrent les opérations quotidiennes des systèmes critiques. Engagez des ingénieurs réseau qui peuvent documenter avec précision la connectivité et les contrôles de limites, complétés par des représentants des RH qui peuvent aborder les exigences de sécurité du personnel. Intégrez la gestion des installations pour aborder les contrôles de sécurité physique et des experts juridiques/conformité pour garantir l’alignement réglementaire. Obtenez un parrainage exécutif qui fournit à la fois l’autorité et les ressources pour un développement SSP complet. Cette équipe diversifiée garantit que votre SSP aborde les contrôles de sécurité de manière holistique à travers tous les domaines plutôt que de se concentrer exclusivement sur les contrôles techniques tout en négligeant les sauvegardes administratives et physiques tout aussi importantes.

Meilleure Pratique : Organisez des ateliers collaboratifs pour recueillir les contributions des parties prenantes concernées lors de l’élaboration des descriptions de contrôle.

8. S’Aligner avec les Familles de Contrôles NIST 800-171

Organisez votre SSP pour refléter la structure du NIST 800-171, facilitant ainsi la vérification de la conformité par les évaluateurs.

Approche Recommandée : Structurez votre SSP selon l’organisation logique du cadre NIST 800-171, qui regroupe les contrôles connexes en 14 familles cohérentes couvrant l’ensemble des exigences de cybersécurité. Commencez par les fondamentaux du Contrôle d’Accès qui restreignent l’accès au système aux utilisateurs et transactions autorisés, suivis des contrôles de Sensibilisation et Formation qui garantissent que le personnel comprend ses responsabilités en matière de sécurité. Continuez avec les mesures d’Audit et de Responsabilité qui créent de la transparence grâce à la surveillance et à la révision, aux côtés des pratiques de Gestion de la Configuration qui établissent et maintiennent l’intégrité du système. Abordez les exigences d’Identification et d’Authentification pour vérifier les identités des utilisateurs, puis documentez les procédures de Réponse aux Incidents pour les événements de sécurité. Incluez des contrôles de Maintenance pour l’entretien du système, la Protection des Médias pour la manipulation des informations, la Sécurité du Personnel pour l’assurance de la main-d’œuvre, et la Protection Physique pour les sauvegardes des installations. Complétez votre couverture avec des processus d’Évaluation des Risques, des pratiques d’Évaluation de la Sécurité, des mécanismes de Protection du Système et des Communications, et des sauvegardes d’Intégrité du Système et de l’Information. Cette structure complète assure une couverture méthodique de tous les domaines de sécurité tout en facilitant une évaluation efficace en s’alignant parfaitement avec le cadre d’évaluation utilisé par les C3PAO.

Perspicacité Critique : Cet alignement simplifie la cartographie entre votre SSP et les critères d’évaluation, rationalisant le processus de certification.

9. Aborder les Considérations de la Supply Chain

Le CMMC met l’accent sur la sécurisation de l’ensemble de la supply chain de la défense, y compris vos relations avec les fournisseurs et prestataires de services.

Approche Recommandée : Développez une stratégie de sécurité de la supply chain complète qui aborde les limites de sécurité étendues créées par vos partenariats externes. Documentez en détail comment les prestataires tiers soutiennent directement des contrôles de sécurité spécifiques, en mappant ces relations aux exigences individuelles du CMMC pour démontrer une couverture complète. Établissez et documentez des exigences de sécurité claires pour tous les fournisseurs qui manipulent ou traitent le CUI, y compris les obligations contractuelles et les mécanismes de vérification. Définissez des limites de responsabilité précises pour les contrôles partagés, articulant clairement quelle organisation maintient la responsabilité de la mise en œuvre, de la surveillance et du reporting pour chaque aspect de sécurité. Mettez en œuvre et documentez des procédures de surveillance et de supervision robustes pour vérifier la conformité continue des fournisseurs, y compris des évaluations régulières, la collecte de preuves et le suivi des remédiations. Cette approche détaillée de la documentation de la supply chain démontre aux évaluateurs que vous comprenez et gérez activement les implications complexes de sécurité de vos relations externes.

Piège à Éviter : Ne supposez pas que l’utilisation d’un fournisseur de services cloud transfère automatiquement la responsabilité de la sécurité loin de votre organisation—vous devez documenter comment vous assurez que les contrôles du fournisseur répondent aux exigences du CMMC.

Besoin de vous conformer au CMMC ? Voici votre checklist de conformité CMMC complète.

10. Documenter les Justifications d’Exception

Certains contrôles peuvent ne pas s’appliquer à votre environnement spécifique, mais vous devez justifier ces exceptions plutôt que de simplement les marquer “Non Applicable”.

Approche Recommandée : Développez des justifications rigoureuses et fondées sur des preuves pour tout contrôle qui ne s’applique pas réellement à votre environnement spécifique. Pour chaque exception, fournissez une documentation détaillée qui commence par une citation précise de l’exigence de contrôle spécifique exemptée, garantissant la clarté sur ce qui est exactement exclu. Présentez une explication complète de pourquoi le contrôle ne s’applique pas à votre environnement, fondée sur l’architecture technique, les processus commerciaux ou les capacités du système plutôt que sur la difficulté de mise en œuvre. Documentez tout contrôle compensatoire qui atténue les risques que le contrôle original était conçu pour aborder, démontrant que les objectifs de sécurité sont toujours atteints par des moyens alternatifs. Incluez des preuves d’approbation formelle montrant que les exceptions ont été examinées et autorisées par les autorités de gouvernance de la sécurité appropriées au sein de votre organisation. Cette approche rigoureuse des exceptions démontre la maturité de la sécurité en montrant que les exclusions résultent d’une analyse réfléchie plutôt que d’une évitement des contrôles difficiles.

Perspicacité Critique : Les exceptions devraient être rares et soigneusement justifiées. Les évaluateurs examineront de près les justifications d’exception.

Modèles et Ressources pour le SSP

Plusieurs ressources sont disponibles pour aider les organisations à développer leur Plan de Sécurité du Système (SSP) pour la conformité CMMC.

L’annexe E du NIST SP 800-171 fournit une structure de modèle officielle, bien que de haut niveau, qui décrit les sections attendues d’un SSP. Bien qu’elle soit précieuse comme point de départ, ce modèle NIST nécessite une personnalisation significative. Évitez le piège d’utiliser un contenu générique ; votre SSP doit refléter avec précision votre limite de système spécifique, vos technologies, configurations, politiques et procédures. Un SSP générique ne passera pas une évaluation CMMC.

Pour illustrer le niveau de détail nécessaire, considérez une section pour la pratique CMMC AC.L2-3.1.5 (Empêcher les utilisateurs non privilégiés d’exécuter des fonctions privilégiées) : “L’exécution de fonctions privilégiées (par exemple, modifications de configuration du système, installation de logiciels) est restreinte au personnel au sein des groupes Active Directory ‘Domain Admins’ et ‘Server Operators’. Les comptes d’utilisateurs standard n’ont pas de droits administratifs sur les postes de travail et serveurs dans la limite CUI. Le contrôle de compte utilisateur (UAC) est activé sur tous les points de terminaison Windows selon la configuration de base [Config-Std-Win10-v2.1]. Les tentatives d’accès privilégié sont enregistrées de manière centralisée dans [Nom de l’outil SIEM] et examinées selon [ID de la procédure de révision des journaux].”

Pour gérer le développement et la maintenance du SSP, les options vont de l’utilisation de modèles de traitement de texte personnalisés et de feuilles de calcul (adaptées aux environnements moins complexes, mais nécessitant un suivi manuel) à des plateformes logicielles de Gouvernance, Risque et Conformité (GRC) dédiées. Les outils GRC (souvent des solutions payantes) offrent des fonctionnalités telles que la cartographie automatique des contrôles, le contrôle de version, la gestion des preuves, le suivi des POA&M et le reporting, qui peuvent être très bénéfiques pour les organisations plus grandes ou plus complexes visant un processus SSP pour le CMMC efficace. Les ressources gratuites comme les publications NIST restent des références essentielles quel que soit l’outil utilisé.

Comment Kiteworks Fournit un Support de Documentation SSP

Un Plan de Sécurité du Système bien conçu est la pierre angulaire d’une certification CMMC réussie. Il transforme la conformité d’un défi intimidant en un processus structuré avec des jalons et des responsabilités clairs.

Rappelez-vous que votre SSP est plus qu’une simple documentation ; c’est un atout stratégique qui permet à votre organisation de :

• Mettre en œuvre systématiquement les contrôles de sécurité requis
• Démontrer la conformité aux évaluateurs
• Identifier et traiter les lacunes de sécurité
• Établir une base pour une amélioration continue de la sécurité

En suivant les meilleures pratiques décrites dans ce guide et en utilisant des solutions conçues à cet effet comme Kiteworks, vous pouvez développer un SSP qui non seulement soutient vos objectifs de certification CMMC mais améliore également votre posture de sécurité globale. Kiteworks aide les organisations à documenter leur conformité pour le développement du SSP, y compris :

• Preuves de Mise en Œuvre des Contrôles : Kiteworks fournit des rapports de sécurité configurables et des journaux d’audit qui servent de preuves directes pour la mise en œuvre des contrôles.
• Documentation de l’Application des Politiques : Les capacités d’application des politiques de la plateforme garantissent et documentent l’application cohérente des contrôles de sécurité à travers le traitement du CUI.
• Définition des Limites du Système : Kiteworks aide à établir des limites claires pour les environnements CUI grâce à des canaux de communication de contenu sécurisés.
• Support d’Évaluation des Risques : Les analyses de sécurité de la plateforme aident à identifier et documenter les vulnérabilités potentielles pour la documentation de l’évaluation des risques.

Kiteworks a également développé des capacités axées sur le CMMC pour rationaliser la conformité, y compris :

• Cartographie des Contrôles CMMC : Kiteworks fournit une documentation détaillée mappant ses fonctionnalités aux contrôles spécifiques du niveau 2 du CMMC, simplifiant le développement du SSP.
• Flux de Travail de Gestion du CUI : La plateforme inclut des flux de travail préconfigurés conçus spécifiquement pour la gestion conforme du CUI.
• Collaboration Sécurisée : Kiteworks permet une collaboration sécurisée avec des partenaires externes sans compromettre la conformité CMMC.
• Surveillance Continue : Les outils de surveillance de sécurité intégrés soutiennent l’évaluation continue de l’efficacité des contrôles de sécurité.

En intégrant Kiteworks dans votre stratégie de conformité CMMC, vous obtenez à la fois les contrôles techniques nécessaires pour la certification et le support documentaire pour développer un SSP complet.

Kiteworks Soutient la Conformité CMMC 2.0

Le Réseau de Contenu Privé de Kiteworks, une plateforme de partage et de transfert de fichiers sécurisée validée FIPS 140-2 Level, consolide la messagerie électronique, le partage de fichiers, les formulaires web, le SFTP, le transfert sécurisé de fichiers, et une solution de gestion des droits numériques de nouvelle génération afin que les organisations contrôlent, protègent, et suivent chaque fichier à mesure qu’il entre et sort de l’organisation.

Kiteworks prend en charge près de 90 % des contrôles de conformité du niveau 2 du CMMC 2.0 prêts à l’emploi. En conséquence, les entrepreneurs et sous-traitants du DoD peuvent accélérer leur processus d’accréditation CMMC 2.0 niveau 2 en s’assurant qu’ils disposent de la bonne plateforme de communication de contenu sensible.

Kiteworks permet une conformité rapide au CMMC 2.0 avec des capacités et fonctionnalités clés, y compris :

• Certification avec les normes et exigences de conformité clés du gouvernement américain, y compris SSAE-16/SOC 2, NIST SP 800-171, et NIST SP 800-172
• Validation FIPS 140-2 Niveau 1
• Autorisé FedRAMP pour le niveau d’impact modéré CUI
• Chiffrement AES 256 bits pour les données au repos, TLS 1.2 pour les données en transit, et propriété exclusive de la clé de chiffrement

Pour en savoir plus sur Kiteworks, réservez une démo personnalisée dès aujourd’hui.

FAQs sur le Plan de Sécurité du Système
1. Quelle devrait être la longueur d’un plan de sécurité du système ?
Il n’y a pas de nombre de pages prescrit pour un plan de sécurité du système. La longueur dépend entièrement de la complexité du système d’information, du nombre de contrôles applicables (par exemple, 110 pour le CMMC Niveau 2), et du niveau de détail nécessaire pour décrire avec précision la mise en œuvre. La clarté, l’exhaustivité et l’exactitude sont bien plus importantes que la longueur. Un SSP complet pour le CMMC pourrait facilement aller de 50 à plusieurs centaines de pages.
2. À quelle fréquence un SSP doit-il être mis à jour ?
Le plan de sécurité du système est un document vivant. NIST 800-171 exige qu’il soit révisé et mis à jour au moins annuellement, ou chaque fois que des changements significatifs se produisent dans le système, son environnement d’exploitation, les contrôles de sécurité, ou le personnel. Pour le CMMC, maintenir le SSP à jour est crucial pour conserver la certification.
3. Que se passe-t-il si les évaluateurs CMMC trouvent des divergences entre le SSP et la mise en œuvre réelle ?
Les évaluateurs vérifient que ce qui est documenté dans le plan de sécurité du système correspond à la réalité. Les divergences sont signalées comme des constatations ou des lacunes. Les divergences mineures peuvent être traitées pendant l’évaluation, mais des écarts significatifs (par exemple, un contrôle documenté comme mis en œuvre est en fait manquant ou mal configuré) peuvent entraîner un échec de l’évaluation ou nécessiter des entrées détaillées dans un Plan d’Action et Jalons (POA&M), retardant potentiellement la certification CMMC.
4. Les organisations peuvent-elles inclure des services cloud (par exemple, IaaS, PaaS, SaaS comme Microsoft 365 GCC High) dans notre SSP pour le CMMC ?
Absolument. Si des services cloud font partie du système traitant, stockant ou transmettant le CUI, ils doivent être inclus dans la limite de système définie dans votre plan de sécurité du système. Vous devez documenter clairement le modèle de responsabilité partagée, détaillant quels contrôles sont entièrement ou partiellement hérités du fournisseur de services cloud (CSP) et lesquels relèvent de la responsabilité de l’organisation. Les preuves de conformité du CSP (par exemple, autorisation FedRAMP, rapports SOC) doivent être référencées.
5. Comment les organisations documentent-elles correctement les contrôles de sécurité hérités dans le SSP ?
Pour les contrôles hérités de tiers (comme les CSP ou les fournisseurs de services gérés), identifiez le contrôle spécifique et le fournisseur dans votre plan de sécurité du système. Référencez la documentation de conformité du fournisseur (par exemple, FedRAMP Plan de Sécurité du Système, Matrice de Responsabilité Client). Il est crucial de décrire comment votre organisation vérifie que le contrôle hérité répond à l’exigence CMMC et comment vous gérez vos responsabilités dans le modèle partagé. Se contenter de déclarer qu’un contrôle est hérité est insuffisant ; vous devez démontrer une diligence raisonnable.