Vue d’ensemble du modèle de plan d’évaluation (AP)

Le modèle OSCAL Assessment Plan (AP), développé par le NIST, représente ce qui doit être testé et comment les tests seront effectués. Le modèle AP permet aux organisations d’échanger des données de planification de l’évaluation dans un format standardisé. Dans CAM, un fichier JSON du plan d’évaluation correspond à un engagement. Chaque fichier AP contient le plan de test qui peut être distribué aux auditeurs et aux équipes d’attestation qui effectuent les tests de contrôle. Lorsqu’un package a plusieurs engagements, l’exportation génère plusieurs fichiers AP, un par engagement.

Qu’est-ce qui est exporté ?

L’exportation du plan d’évaluation OSCAL génère des fichiers contenant des données d’engagement et de test. L’exportation comprend :

• Métadonnées d’engagement (nom, état, objectifs, pourcentage de progression, chronologie, budget)
• Parties et rôles (utilisateurs impliqués dans leurs affectations de rôles)
• Activités représentant les tests de contrôle (descriptions des tests, méthodes, statut, procédures d’évaluation du fonctionnement)
• Procédures d’évaluation en tant qu’étapes des activités
• Contrôles examinés (contrôles et exigences inclus dans le périmètre des tests)
• Référence au plan de sécurité du système parent (SSP)

Les propriétés personnalisées sont utilisées pour les champs spécifiques à CAM qui ne sont pas pris en charge nativement par les normes OSCAL. Ces propriétés utilisent l’espace de noms ServiceNow.

Qu’est-ce qui est importé ?

L’importation du plan d’évaluation OSCAL crée automatiquement des engagements et leurs structures de test associées dans CAM. Pour chaque fichier AP, le système génère :

• Un engagement avec les métadonnées (utilisateurs, rôles, chronologie, budget)
• Tests de contrôle mappés à partir des activités AP
• Plans de tests et procédures d’évaluation mappés à partir des tâches AP
• Affectations d’utilisateurs avec des rôles (responsable de l’engagement, approbateurs, auditeurs, propriétaires des tests de contrôle)
• Sélections de contrôles et d’objectifs de contrôle spécifiant ce qui sera testé

Le processus d’importation crée la structure complète du package si elle n’existe pas dans l’instance cible : limite, package, éléments système, contrôles de la base de référence et engagements. Pour les packages existants, les objets importés apparaissent par défaut dans la liste de remplacement, ce qui vous permet d’ignorer ou de remplacer les données existantes.

Structure et validation des fichiers dans le processus d’importation AP

L’importation AP nécessite des fichiers obligatoires : catalogue, profil et SSP. Vous pouvez joindre un ou plusieurs fichiers AP en fonction du nombre d’engagements. Le système valide les fichiers téléchargés par rapport aux normes OSCAL pendant l’étape de pièce jointe. Si des erreurs de validation se produisent, le système affiche des messages d’erreur avant de continuer.

Le fichier AP doit référencer l’UUID SSP inclus dans votre importation. Si l’AP fait référence à un autre UUID SSP, la validation échoue avec un message d’erreur. Cela garantit que le plan d’évaluation est correctement lié au package en cours d’importation.

Mappage des utilisateurs et des rôles pour l’importation OSCAL

Pendant l’importation, le système mappe les utilisateurs du fichier OSCAL aux utilisateurs ServiceNow. Lorsque les noms d’utilisateur correspondent, le système les mappe automatiquement. Lorsque les noms d’utilisateur ne correspondent pas ou que l’utilisateur n’existe pas dans ServiceNow, vous devez sélectionner manuellement l’utilisateur ServiceNow correspondant. L’étape de mappage des utilisateurs garantit que tous les rôles requis sont affectés (propriétaire du système, ISSO, ISSM, responsable de l’engagement, auditeurs). Si des rôles obligatoires sont manquants après le mappage automatique, vous devez affecter manuellement les utilisateurs avant de poursuivre.

Mappage des utilisateurs et des rôles pour l’exportation OSCAL

CAM exporte les données d’engagement au format du plan d’évaluation OSCAL en utilisant la structure suivante :

• Métadonnées de l’engagement : nom, état, objectifs, pourcentage de progression, dates de chronologie (période d’audit, dates de travail sur le terrain, durée de l’engagement) et montants budgétaires Exporter vers la section des métadonnées
• Utilisateurs et rôles : Les informations sur les utilisateurs (noms complets, identifiants uniques) sont exportées vers la section des parties ; Les rôles (responsable de l’engagement, approbateurs, auditeurs, propriétaire du test de contrôle) et les affectations sont exportés vers les sections Rôles et Parties responsables
• Tests de contrôle : mappez les activités de la section Définitions locales, y compris le titre du test, la description, l’état actuel et les procédures d’évaluation du fonctionnement
• Procédures d’évaluation : mappage des étapes des activités, contenant les identificateurs, les descriptions et les étiquettes des étapes pour les exigences de contrôle
• Contrôles examinés : identifie les contrôles et les exigences qui peuvent faire l’objet d’un test
• Référence SSP : relie le plan d’évaluation à son package parent à l’aide de l’UUID du package dans la section import-ssp