Evidenze per l'assessment CMMC Fase 2 — il playbook per Level 2 e Level 3

La norma che istituisce il programma CMMC, il 32 CFR Part 170, è in vigore dal 16 dicembre 2024. La norma sugli appalti che porta il CMMC nei contratti, con la clausola DFARS 252.204-7021 e la clausola di bando 252.204-7025, è in vigore dal 10 novembre 2025. La Part 170 aggancia le fasi a quella data, ognuna un anno solare dopo la precedente (§170.3(e)):

• Fase 1, dal 10 novembre 2025: il DoD intende richiedere lo status Level 1 (Self) o Level 2 (Self) come condizione di aggiudicazione, e può chiedere al suo posto il Level 2 (C3PAO).
• Fase 2, dal 10 novembre 2026: il DoD intende aggiungere lo status Level 2 (C3PAO) come condizione di aggiudicazione nei bandi e contratti interessati. Può, a sua discrezione, spostare il requisito a un periodo di opzione, e può richiedere anche il Level 3 (DIBCAC).
• Fase 3, dal 10 novembre 2027: il Level 2 (C3PAO) diventa condizione anche per esercitare i periodi di opzione, e il DoD intende richiedere il Level 3 (DIBCAC) nei bandi interessati.
• Fase 4, dal 10 novembre 2028: piena applicazione, compresi i periodi di opzione dei contratti aggiudicati prima della Fase 4.

In base alla clausola di bando 252.204-7025, un offerente può essere aggiudicatario solo se ciascun sistema informativo che tratterà, conserverà o trasmetterà FCI o CUI ha in SPRS uno status CMMC in corso di validità al livello richiesto e un'attestazione aggiornata di conformità continuativa. La clausola 252.204-7021 impone poi di mantenere quello status per tutta la durata del contratto, con un'attestazione annuale. Per tre anni dal 10 novembre 2025 la clausola si usa quando il program office stabilisce che serve un livello CMMC specifico; dopo, ogni volta che verranno trattate FCI o CUI, salvo i contratti per soli prodotti COTS.

I requisiti del Level 2 coincidono con la NIST SP 800-171 Revision 2: 110 requisiti in 14 famiglie (§170.14(c)(3)). Il NIST ha ritirato la Revision 2 a maggio 2024 in favore della Revision 3, ma la Part 170 la incorpora per rinvio, e quindi è quella la versione valutata. Il C3PAO valuta ogni requisito sugli obiettivi di assessment della NIST SP 800-171A (giugno 2018), entro il perimetro definito secondo il §170.19, e lo punteggia secondo il §170.24:

• MET solo se ogni obiettivo applicabile è soddisfatto da evidenze. Le evidenze devono essere definitive: bozze, documenti di lavoro e policy non approvate non contano.
• Il punteggio parte da 110 e sottrae 5, 3 o 1 punto per ogni requisito NOT MET.
• Conditional Level 2 (C3PAO) è possibile quando si rispettano le regole sui POA&M descritte più avanti; il POA&M va poi chiuso con un closeout assessment del C3PAO entro 180 giorni, altrimenti lo status decade.
• Final Level 2 (C3PAO) dura tre anni, con un'attestazione di conformità continuativa dell'Affirming Official dopo ogni assessment e ogni anno (§170.22).

Due regole sulle evidenze sfuggono facilmente. Il contraente deve calcolare l'hash degli artefatti usati come evidenza con un algoritmo approvato dal NIST, consegnare al C3PAO l'elenco dei nomi e dei valori di hash, e conservare gli artefatti per sei anni dalla CMMC Status Date (§170.17(c)(4)). E un requisito NOT MET può essere rivalutato durante l'assessment e nei 10 giorni lavorativi successivi solo se esistono evidenze aggiuntive, gli altri esiti MET non ne risentono e il report dei risultati non è ancora stato consegnato.

Tre requisiti, ciascuno con obiettivi di assessment che l'assessor valuta uno per uno:

• 3.11.1 Valutazione del rischio (3 punti): [a] la frequenza delle valutazioni del rischio è definita; [b] il rischio viene valutato con quella frequenza.
• 3.11.2 Scansione delle vulnerabilità (5 punti): [a] è definita una frequenza di scansione; [b] e [c] sistemi e applicazioni sono scansionati con quella frequenza; [d] ed [e] sistemi e applicazioni sono scansionati quando emergono nuove vulnerabilità che li riguardano.
• 3.11.3 Correzione delle vulnerabilità (1 punto): [a] le vulnerabilità sono individuate; [b] sono corrette in base alle valutazioni del rischio.

Per 3.11.2 e 3.11.3 l'assessor può esaminare gli strumenti di scansione e la loro documentazione di configurazione, i risultati delle scansioni e i registri di patch e gestione delle vulnerabilità; intervistare chi esegue le scansioni e le correzioni; e mettere alla prova i meccanismi di scansione e correzione.

La Part 170 definisce «periodicamente» come un intervallo regolare stabilito dal contraente e non superiore a un anno (§170.4 e §170.14(d)). Serve quindi una frequenza scritta, e l'anno è il limite massimo, non l'obiettivo. La discussione NIST del 3.11.2 elenca cosa coprono le scansioni (livelli di patch; funzioni, porte, protocolli e servizi che non dovrebbero essere accessibili; controlli dei flussi informativi mal configurati), osserva che l'accesso privilegiato a componenti selezionati consente scansioni più approfondite e indica gli esercizi di red team come ulteriore fonte di vulnerabilità da cercare.

Quattro requisiti. I primi tre valgono punti; il quarto decide se l'assessment può svolgersi:

• 3.12.1 Verifica dei controlli di sicurezza (5 punti): [a] la frequenza delle verifiche è definita; [b] i controlli sono verificati con quella frequenza per stabilire se sono efficaci nella loro applicazione.
• 3.12.2 Piani d'azione (3 punti): [a] carenze e vulnerabilità sono individuate; [b] è predisposto un piano d'azione per correggerle; [c] il piano è attuato.
• 3.12.3 Monitoraggio continuo (5 punti): i controlli sono monitorati in modo continuativo per garantire che restino efficaci.
• 3.12.4 System security plan: senza un SSP aggiornato l'assessment non può concludersi, e l'SSP non può finire in un POA&M.

Il piano d'azione del 3.12.2 è un documento operativo, non il POA&M del CMMC, e la differenza conta. Secondo il §170.24(b)(1)(ii), le carenze temporanee affrontate in modo adeguato nei piani d'azione operativi, con revisioni delle carenze e avanzamenti visibili, sono valutate MET. Una vulnerabilità trovata dalla scansione della settimana scorsa non rende NOT MET il 3.11.2 o il 3.11.3 se il processo che l'ha trovata funziona e la correzione è tracciata e in corso.

Per il 3.12.1 la discussione NIST si aspetta risultati aggiornati, pertinenti e ottenuti con un adeguato grado di indipendenza di chi valuta, e ammette scansioni di vulnerabilità e monitoraggio dei sistemi come attività di verifica aggiuntive. Un controllo che esiste sulla carta ma non è mai stato dimostrato efficace, come una segmentazione di rete mai testata, è esattamente ciò che questo requisito deve far emergere.

Uno status Conditional, e quindi un POA&M, è ammesso solo se valgono tutte queste condizioni (§170.21(a)(2)):

• Il punteggio è almeno l'80 per cento del massimo, cioè 88 punti su 110 requisiti.
• Nessun requisito nel POA&M vale più di 1 punto, salvo SC.L2-3.13.11 quando la cifratura è usata ma non è validata FIPS.
• Nessuno dei sei requisiti esclusi espressamente vi compare, tra cui CA.L2-3.12.4, il system security plan.

Applicato alle due famiglie viste sopra: 3.11.1 (3 punti), 3.11.2 (5), 3.12.1 (5), 3.12.2 (3) e 3.12.3 (5) non possono essere rinviati, il 3.12.4 è escluso espressamente e solo il 3.11.3 (1 punto) può stare in un POA&M. Il POA&M non sostituisce l'attuazione: un requisito non attuato è valutato NOT MET che compaia o meno nel piano (§170.24). Il closeout assessment deve confermare ogni voce del POA&M entro 180 giorni dalla data dello status Conditional; altrimenti lo status decade e il contraente non può ottenere nuove aggiudicazioni che richiedono quello status per il sistema finché non ne consegue uno nuovo.

Il Level 3 è valutato dalla DCMA DIBCAC e richiede prima uno status Final Level 2 (C3PAO) sullo stesso perimetro (§170.18). Aggiunge 24 requisiti scelti dalla NIST SP 800-172 (febbraio 2021), con parametri assegnati dal DoD nella tabella 1 del §170.14(c)(4). Quelli più vicini al testing:

• CA.L3-3.12.1e: penetration test almeno una volta l'anno o quando il sistema subisce modifiche di sicurezza significative, con strumenti di scansione automatica e test ad hoc condotti da esperti della materia.
• RA.L3-3.11.5e: verificare l'efficacia delle soluzioni di sicurezza almeno una volta l'anno, quando arrivano informazioni rilevanti sulle minacce o dopo un incidente rilevante.
• RA.L3-3.11.1e e SI.L3-3.14.6e: usare threat intelligence da fonti aperte o commerciali e da eventuali fonti del DoD per orientare valutazione del rischio, rilevamento delle intrusioni e threat hunting.
• RA.L3-3.11.2e: threat hunting continuativo e non periodico, o quando gli indizi lo giustificano.
• SC.L3-3.13.4e: tecniche di isolamento fisico, logico o entrambe.

La discussione NIST del 3.12.1e spiega cosa si aspetta oltre le scansioni del Level 2. Il penetration test va oltre la scansione automatica delle vulnerabilità e può verificare se sono davvero sfruttabili; può essere affiancato da esercizi di red team; le regole d'ingaggio si concordano prima dell'avvio; e il team deve avere le competenze necessarie ed essere obiettivo nella valutazione. Il NIST ha ritirato l'edizione di febbraio 2021 della SP 800-172 il 13 maggio 2026, pubblicando la Revision 3. Nel testo eCFR di settembre 2026 la Part 170 incorpora ancora l'edizione 2021, su cui è costruita la tabella del Level 3.

Gli strumenti di sicurezza non stanno fuori dal perimetro CMMC. La Part 170 definisce Security Protection Data i dati conservati o trattati dagli asset che proteggono l'ambiente valutato, compresi i dati sulla configurazione o sullo stato di vulnerabilità degli asset in perimetro e le password che danno accesso all'ambiente in perimetro (§170.4). Risultati delle scansioni, finding dei penetration test e credenziali usate in un test gray box rientrano tutti in questa definizione.

Le regole di perimetro stabiliscono poi come va trattato uno strumento (§170.19(c) e la sua tabella 4):

• Uno strumento che gestisci dentro l'enclave è un Security Protection Asset: va nell'inventario degli asset, nell'SSP e nel diagramma di rete, ed è valutato sui requisiti Level 2 pertinenti a ciò che fa.
• Un External Service Provider è definito dal fatto di trattare, conservare o trasmettere CUI o Security Protection Data. Un servizio cloud che riceve i tuoi dati sulle vulnerabilità rientra nel perimetro dell'assessment ed è valutato come Security Protection Asset, e il suo uso va documentato nel tuo SSP e nella descrizione del servizio e nella customer responsibility matrix del fornitore.
• Se quel servizio cloud tratta anche CUI, come può accadere quando un test raggiunge una condivisione di file o un database, il fornitore deve rispettare i requisiti FedRAMP della DFARS 252.204-7012: autorizzazione FedRAMP Moderate o equivalente (§170.17(c)(5)).

Uno strumento di test che invia prompt e finding a un modello AI esterno ricade in queste regole come qualsiasi altro fornitore. Tenere test e modelli dentro l'enclave mantiene CUI e Security Protection Data nel perimetro che già documenti, non aggiunge fornitori esterni al perimetro e funziona anche dove l'enclave è fisicamente isolata, il tipo di separazione descritto dal requisito 3.13.4e del Level 3.

Un red team AI autonomo non è un C3PAO, non rilascia né prevede uno status CMMC e non sostituisce gli esperti della materia richiesti dal 3.12.1e. Dà al contraente un modo per eseguire e documentare, dentro l'enclave, i test che i requisiti descrivono.

• Scansione e verifica a frequenza definita e quando emergono nuove vulnerabilità (3.11.2), con finding dimostrati sfruttabili nel tuo ambiente, così che le correzioni seguano il rischio (3.11.3). Vedi correggi prima ciò che è stato dimostrato sfruttabile.
• Verifica dell'efficacia dei controlli (3.12.1): se segmentazione, autenticazione e hardening reggono a un attacco, in modalità black box dall'esterno di un segmento e gray box con gli accessi di un utente standard. Vedi black box e gray box.
• Piani d'azione che avanzano (3.12.2): ogni correzione viene ritestata con la stessa prova che ha trovato la falla.
• Regole d'ingaggio applicate dal motore: controllo del perimetro e arresto d'emergenza, cinque livelli di autonomia che stabiliscono cosa attende l'approvazione di un operatore, e proof of concept di exploit trattenuti per la revisione dell'operatore quando il livello della campagna non li consente. Vedi human in the loop.
• Integrità delle evidenze: ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline.
• AI privata dentro il perimetro: i modelli ZeroHunt Apex girano sull'appliance, senza API AI esterne e senza bisogno di connessione a internet, così CUI e Security Protection Data restano dove l'SSP dice che sono. Vedi AI privata nella cybersecurity.

• 32 CFR Part 170, Cybersecurity Maturity Model Certification (CMMC) Program (eCFR)
• Norma finale sul programma CMMC, 89 FR 83092, 15 ottobre 2024 (Federal Register)
• Norma finale DFARS Case 2019-D041, 90 FR 43560, 10 settembre 2025 (Federal Register)
• NIST SP 800-171 Rev. 2, Protecting CUI in Nonfederal Systems and Organizations (NIST CSRC)
• NIST SP 800-171A, Assessing Security Requirements for CUI (NIST CSRC)
• NIST SP 800-172, Enhanced Security Requirements for Protecting CUI, febbraio 2021 (NIST CSRC)