FedRAMP VDR e VER richiedono prove di sicurezza continue

Le regole VDR e VER di FedRAMP richiedono prove di sicurezza continue, non solo scansioni più frequenti. Secondo l'avviso che risponde alla Direttiva Operativa Vincolante 26-04 del CISA, tutte le offerte di servizi cloud che ottengono o mantengono la certificazione FedRAMP devono soddisfare i requisiti di Vulnerability Detection and Response a partire dal 7 dicembre 2026, con un periodo di tolleranza fino al 7 marzo 2027 per le offerte che operano sotto un piano di azione correttiva. Il problema per molti programmi non è la data in sé; è che le regole sembrano un mandato di scansione ma in realtà richiedono un modello operativo diverso.

Il vecchio approccio era una scansione mensile fissa abbinata a un Plan of Actions and Milestones (POA&M), un elenco manuale di problemi irrisolti. Ora FedRAMP stabilisce la frequenza di rilevamento in base alla classe di certificazione. La regola VDR-TFR-PSD afferma che le risorse basate su macchina, come server e macchine virtuali, devono essere scansionate almeno ogni 14 giorni per i fornitori di Classe A, ogni 7 giorni per la Classe B, ogni 3 giorni per la Classe C e almeno una volta al giorno per la Classe D. Controlli separati di verifica e validazione automatica vengono eseguiti almeno mensilmente per i titolari Rev5, e con frequenza fino a ogni 3 giorni per le classi 20x superiori.

Tre disposizioni cambiano il lavoro di ingegneria più direttamente. I tempi di rimedio sono a livelli e stretti: la regola VDR-TFR-PVR stabilisce scadenze di correzione in base al PAIN rating di una vulnerabilità, un punteggio di gravità, e se è nota per essere sfruttata. Le scadenze vanno da 192 giorni nel caso più basso fino a 12 ore per un'offerta di Classe D con una vulnerabilità PAIN-5 che è sia probabilmente sfruttata che immediatamente sfruttabile da remoto. Un orologio di 12 ore non è un livello di servizio di routine per una coda di ticket; è una questione di allerta e responsabilità che deve funzionare anche in un fine settimana festivo. Anche l'onere della prova è invertito: la regola VER-EVA-AIA, chiamata Assume It's Automatable, richiede ai fornitori di presumere che gli exploit possano essere automatizzati per impostazione predefinita, a meno che non abbiano prove che dimostrino il contrario. Ogni differimento quindi necessita di un artefatto difendibile, prodotto in volume e sullo stesso orologio. Infine, i fallimenti di processo ora contano come vulnerabilità: la regola VDR-CSO-FAV afferma che i fornitori devono trattare problemi o fallimenti nei loro processi di rilevamento e risposta alle vulnerabilità come vulnerabilità. Se la pipeline di rilevamento si ferma silenziosamente, non è un intoppo operativo tranquillo; il sistema che produce prove è esso stesso nel campo di applicazione. Lette insieme, queste disposizioni cambiano il risultato da più scansioni a un sistema che produce risposte difendibili, attuali e leggibili da macchina sull'esposizione ed è responsabile quando smette di funzionare.

Il 7 dicembre è solo la prima rata. Le Consolidated Rules for 2026 hanno riorganizzato FedRAMP in set di regole e avviato una transizione molto più ampia. FedRAMP descrive Rev5 come un processo di certificazione legacy che viene sostituito interamente da FedRAMP 20x, e afferma che i fornitori devono seguire le nuove regole e adottare le nuove FedRAMP Practices dal 20x nelle loro offerte Rev5. Le nuove regole diventano obbligatorie per tutte le parti interessate il 1° gennaio 2027, e FedRAMP smette di accettare nuove domande Rev5 l'11 giugno 2027. Ciò significa che VDR e VER non sono una deviazione prima della vera transizione; sono la transizione, che arriva a rate. Il lavoro definito come superare dicembre sarà ricostruito nel 2027, mentre il lavoro definito come la prima fetta di validazione continua sarà trasferito.

I cambiamenti strutturali mostrano dove sta andando il programma. Il System Security Plan e i suoi allegati lasciano il posto a un Certification Package Overview e a un Security Decision Record. I Plans of Action and Milestones sono stati eliminati completamente e sostituiti con un elenco di Accepted Weaknesses. Il Continuous Monitoring è rinominato Ongoing Certification perché il vecchio termine era diventato sinonimo di scansioni di vulnerabilità, ma i nuovi requisiti sono molto più ampi. FedRAMP è stato diretto nel colmare le lacune dove i documenti sostituivano la realtà: i fornitori dovranno costruire o acquistare capacità GRC moderne, governance, rischio e conformità, e popolarle usando l'automazione basata su dati del mondo reale ove possibile, piuttosto che mantenere documenti creati a mano. Quasi nulla di tutto ciò è una richiesta di nuova sicurezza; controllo degli accessi, identità, crittografia, registrazione, procedure di incidente e formazione sono in gran parte intatti. Ciò che è cambiato è che descriverli non conta più come prova della loro esistenza.

Il lavoro è ancora conformità, ma il risultato ora è ingegneria. I fornitori devono consegnare una serie di validazioni in esecuzione che attingono dai sistemi che detengono la verità, come la configurazione cloud, il provider di identità, un SIEM che aggrega i log di sicurezza, CI/CD, il processo automatizzato di build e deployment, e il ticketing, ed emettono risultati leggibili da macchina secondo una pianificazione. FedRAMP attualmente elenca 49 Key Security Indicators in dieci categorie nel CR26, e i fornitori devono validarli persistentemente; questo è un requisito di ingresso, quindi ogni piano di transizione è sotto sotto un piano di ingegneria dell'automazione. Qualcuno deve possedere l'operazione continua: il monitoraggio mensile aveva una data di scadenza e un ritmo naturale di recupero, ma una cadenza di validazione o funziona costantemente o si ferma silenziosamente, e la differenza è invisibile finché un valutatore o un cliente non la trova. Prima di costruire pipeline, i team dovrebbero rispondere a domande operative: chi viene avvisato quando una validazione fallisce, qual è il tempo di risposta e chi si accorge quando una fonte di prove cambia silenziosamente la sua API. FedRAMP definisce persistentemente come qualcosa che avviene in modo fermo e costante, ripetuto per un lungo periodo di tempo nonostante ostacoli o difficoltà, una descrizione di uno stato operativo piuttosto che una data. I team che costruiscono verso una singola presentazione costruiranno un sistema tarato per un momento e poi lo ricostruiranno dopo.

Una volta che le prove diventano dati strutturati invece di narrazione, smettono di appartenere a un singolo framework. Le prove di identità che soddisfano un indicatore FedRAMP sono le stesse prove che un revisore SOC 2 vuole e le stesse prove che il team di due diligence di un grande cliente richiede. La conformità smette di essere un insieme di progetti paralleli che ricostruiscono ciascuno la stessa immagine con un vocabolario diverso e diventa un unico substrato da cui molti consumatori leggono. L'economia si inverte: i costi di conformità puntuale aumentano con ogni framework e regione aggiunti, perché ogni aggiunta è più descrizione da produrre e mantenere. La validazione continua costa di più per essere avviata e appena di più per essere eseguita. Il 7 dicembre è una data fissa, ma i supervisori dei servizi finanziari, i regimi di resilienza e sicurezza dei prodotti dell'UE e i team di approvvigionamento aziendali stanno convergendo sulla stessa richiesta: mostrare lo stato attuale, non la descrizione dell'anno scorso. FedRAMP è arrivato prima perché aveva il mandato più chiaro e la minore pazienza. Per le organizzazioni che gestiscono i propri siti web, account cloud o infrastrutture al di fuori del programma FedRAMP, vale lo stesso principio: prove attuali e leggibili da macchina della tua postura di sicurezza sono più utili di un certificato annuale. AEU-I fornisce IT, infrastruttura e consulenza security-first che possono aiutare i team a costruire e mantenere quel tipo di validazione continua.