Compliance Automated Standard Solution (COMPASS), Parte 1 Personas e Ruoli
COMPASS, Part 1 - Personas and Roles
(Nota: Un elenco di collegamenti per tutti gli articoli di questa serie può essere trovato alla conclusione di questo articolo.)
Questa è la prima parte della nostra serie di post del blog che illustrano le sfide che le organizzazioni e i fornitori di cloud affrontano nel tentativo di raggiungere la conformità continua. La serie fornirà i concetti chiave, le tecnologie e gli standard del settore che aprono la strada verso una soluzione operativa, scalabile ed efficace end-to-end.
Inizieremo introducendo le persone coinvolte nella conformità e i loro ruoli e azioni nei processi di conformità. Comprendere le persone, i loro ruoli e le loro esigenze è fondamentale per le decisioni di progettazione e architettura per l’automazione della Governance, Risk e Compliance (GRC) dettagliata nei nostri successivi post del blog.
Nel secondo post del blog di questa serie, esamineremo gli artefatti di conformità gestiti nel processo di conformità su larga scala e la progettazione della loro rappresentazione sia per il consumo umano da parte delle varie persone che per l’abilitazione programmabile come codice.
- Vector Database Che cos’è e perché tutta questa eccitazione?
- DeepBrain AI Recensione Il miglior generatore di avatar AI? (2023)
- PaaS4GenAI Collegamento di Generative AI (WatsonX) sulla piattaforma IBM Cloud da Oracle Integration Cloud
I blog di follow-up copriranno la nostra soluzione gerarchica di Governance, Risk e Compliance (GRC) con i suoi vari tipi di Orchestratori di Politiche e Orchestratori di Validazione delle Politiche, un protocollo di scambio standardizzato per consentire l’interoperabilità tra gli Strumenti di Validazione delle Politiche e gli Orchestratori, un supporto basato sull’attraversamento delle regolamentazioni basato su IA per gli Orchestratori di Politiche e alcune tecniche specifiche di automazione della validazione delle politiche. Restate sintonizzati.
L’Importanza della Conformità Continua
Oggi, la conformità regolamentare è un rischio per le aziende. Il mondo aziendale sta passando da audit sporadici a regimi di conformità continua, in cui la posizione del sistema deve essere disponibile con un semplice pannello di controllo. Per raggiungere la conformità continua, abbiamo bisogno sia di automazione che di standardizzazione. Raggiungere l’automazione è un’impresa impegnativa a causa dei processi di governance frammentati, della disconnessione tra le politiche organizzative e la loro corrispondente implementazione tecnica e della complessità dell’implementazione e della misurazione della conformità.
Si noti che più ci avviciniamo a sistemi, API e rappresentazione dati programmabile, più è facile guidare la digitalizzazione e l’automazione. Nel frattempo, più ci avviciniamo a processi manuali e rappresentazione dati in formato umano, più difficile diventa guidare la digitalizzazione e la trasformazione. La conformità si trova nella seconda categoria – con i suoi PDF e documenti Word per regolamenti, linee guida e interpretazioni – e le sue procedure manuali per raccogliere prove campione e generare rapporti in formato foglio di calcolo. Pertanto, per iniziare il percorso di automazione della conformità, dobbiamo comprendere quelle procedure manuali, semi-automatiche e frammentate e le esigenze dei loro facilitatori.
In questo post del blog, esaminiamo gli stakeholder e i loro ruoli e azioni nel framework di gestione della Governance, Risk e Compliance (GRC) – dalla redazione delle regolamentazioni alla raccolta di prove fino alla segnalazione dell’audit. Poiché il nostro focus in questa serie è sulla conformità, gli aspetti di rischio saranno inclusi in un secondo momento. Introduciamo quindi gli artefatti di conformità associati a queste persone e ne esemplifichiamo la rappresentazione come conformità come codice e politica come codice per abilitare l’automazione. La copertura completa degli artefatti di conformità sarà oggetto del nostro prossimo post del blog.
Persone di Conformità
Figura 1: Azioni delle persone di conformità nel framework di gestione della Governance, Risk e Compliance
Come illustrato in Figura 1, gli stakeholder principali della conformità coinvolti in un framework di gestione della Governance, Risk e Compliance (GRC) e il flusso di azioni di queste persone sono i seguenti:
- Regolatori definiscono regolamenti, leggi e standard come cataloghi con controlli e parametri. Stabiliscono inoltre requisiti di conformità predefiniti in baselines o profili.
- CISO architetti aziendali, ingegneri della sicurezza e responsabili della conformità sono responsabili dell’interpretazione dei regolamenti, della definizione, personalizzazione e associazione di linee guida con profili e controlli selezionati per i loro ambienti e le loro architetture di riferimento.
- Fornitori di Controlli – come produttori di prodotti, fornitori di servizi e manutentori di progetti OSS – implementano i controlli dai cataloghi di regolamentazione nei loro prodotti (ad esempio, hardware, software, servizi, processi) seguendo l’interpretazione e la guida del CISO e del responsabile della conformità. Per dichiarare come sono implementati i controlli, devono tradurre ciascun controllo in regole tecniche applicate ai parametri di configurazione e al comportamento del prodotto in modo da riflettere la guida di controllo. Questa traduzione viene effettuata affermando la corrispondenza tra il controllo e le regole tecniche. I fornitori di controlli possono anche esporre la natura della prova associata a ciascuna regola (ad esempio, schema, modello, payload API).
- Le regole tecniche devono essere testate o applicate per verificare o garantire che gli ambienti regolamentati o le architetture di riferimento siano configurati e si comportino secondo il regolamento, la baseline o i profili predefiniti dei Regolatori. Valutatori dei Controlli – come fornitori di strumenti di valutazione, fornitori di servizi, manutentori di progetti OSS ed ingegneri della conformità – implementano controlli o prodotti che ospitano controlli per testare ambienti regolamentati o architetture di riferimento per l’allineamento ai requisiti di conformità previsti. I loro controlli si basano sul formato delle prove dichiarato dai fornitori di controlli e hanno stati di output per i controlli come “fallito,” “superato,” “errore” e “impossibile eseguire”.
- Proprietari di Sistema e CIO sono responsabili dell’approvvigionamento complessivo, dello sviluppo, dell’integrazione, della modifica, dell’esercizio, della manutenzione e dello smaltimento delle piattaforme aziendali, dei sistemi, dei sistemi operativi, delle reti, dei database e delle applicazioni. Sono responsabili di garantire la conformità ai profili selezionati dagli Ingegneri della Sicurezza CISO.
- CISO architetti aziendali, ingegneri della sicurezza e ingegneri della conformità sono anche responsabili di creare nuove regole tecniche per le loro architetture aziendali regolamentate e di riferimento per coprire controlli aggiuntivi attraverso capacità e comportamenti combinati tra prodotti. Queste nuove regole si tradurranno in nuovi controlli per testare ulteriormente che gli ambienti regolamentati e le architetture di riferimento siano configurati e si comportino secondo i profili selezionati dagli Ingegneri della Sicurezza CISO. Questi controlli si basano sul formato delle prove dichiarato dai fornitori di controlli (o dal CISO nel caso di strumenti e processi personalizzati) e hanno stati di output come “fallito,” “superato,” “errore” e “impossibile eseguire”.
- CISO sono anche il collegamento tra il Proprietario del Sistema e gli Ufficiali di Audit per i quali devono preparare il pacchetto per l’Autorizzazione all’Operazione (ATO) (cioè il Piano di Sicurezza del Sistema (SSP) e i Risultati della Valutazione del Sistema (SAR) per l’azienda).
- In base ai profili selezionati dal CISO, al SSP o ai Piani di Valutazione del Sistema (SAP), i Valutatori dei Controlli testano tutte le regole tecniche applicabili e generano Risultati della Valutazione del Sistema (SAR) che contengono la posizione di conformità dei sistemi nell’ambiente regolamentato o nell’architettura di riferimento. I SAR vengono condivisi con il CISO e con i Proprietari di Sistema e/o i team Operativi.
- CISO e/o Proprietari di Sistema possono generare piani d’azione basati sui fallimenti della posizione SAR. I Proprietari di Sistema sono responsabili di garantire la conformità ai profili selezionati dal CISO. Recuperano il SAR dai Valutatori dei Controlli e devono intraprendere azioni correttive per ridurre o elimin
Nella tabella sottostante, riassumiamo le persone coinvolte nei processi di conformità a livello aziendale e le loro azioni:
Tabella 1: Persone e azioni nei processi di conformità a livello aziendale
Principali artefatti di conformità
Figura 2: Esempi illustrativi per diversi artefatti di conformità e la loro rappresentazione programmata. Regolamenti in formato PDF (in alto) vs. controlli e regole espresse come Conformità come Codice (al centro) vs. script di controllo come Politica come Codice per testare i sistemi (in basso).
La figura 2 rappresenta i principali artefatti di conformità con esempi concreti e la loro rappresentazione in linguaggio umano come codice di conformità o codice di politica. Illustra i seguenti aspetti chiave degli artefatti di conformità:
- I regolamenti e i controlli dei regolamenti sul lato della governance sono espressi come dichiarazioni ampie in linguaggio umano (ad esempio, “SC-28 Il sistema informativo protegge la [riservatezza; integrità] delle [informazioni a riposo].”) mentre le regole tecniche sul lato tecnico sono espresse come dichiarazioni specifiche per i prodotti e i processi che implementano i controlli (ad esempio, “Assicurarsi che l’archiviazione degli oggetti cloud sia crittografata con KYOK”). Nella maggior parte dei casi, la formulazione della regola tecnica riflette indirettamente l’affermazione del controllo, richiedendo a un esperto di prodotto di generare le regole e rendendo difficile per un non esperto o per l’intelligenza artificiale valutare la copertura della dichiarazione di controllo. Mostreremo in un futuro blog come l’intelligenza artificiale (AI) possa supportare l’esperto di conformità nella navigazione delle dichiarazioni di regolamentazione tramite collegamenti incrociati.
- Il formato di rappresentazione di questi artefatti di conformità evolve da PDF, testo libero e fogli di calcolo a conformità come codice (ad esempio, NIST OSCAL) e politica come codice (ad esempio, OPA – Open Policy Agent) per raggiungere l’automazione. Da un lato, mentre abbiamo ancora bisogno di PDF, testo libero e fogli di calcolo per facilitare la creazione e il consumo di cataloghi, profili e regole di prodotti e parametri di fornitori da parte degli utenti, dobbiamo passare alla conformità come codice per consentire agli strumenti e ai servizi di conformità di scambiare, applicare e controllare continuamente tali artefatti di conformità negli ambienti. D’altra parte, abbiamo anche bisogno che i processi di valutazione delle prove manuali passino alla politica come codice, come gli script in Python, JavaScript o OPA Rego, per testare continuamente le regole tecniche dei prodotti implementati nell’ambiente regolamentato. Nel prossimo blog, mostreremo come il framework NIST OSCAL e il suo linguaggio standard possano essere utilizzati per rappresentare gli artefatti GRC tipici come codice.
- La chiave per raggiungere l’automazione della conformità e la conformità continua è la rappresentazione programmata del mapping dalle dichiarazioni di controllo ampie in linguaggio umano alle regole tecniche specifiche e ai loro parametri e controlli associati. Il processo a più fasi per generare questo artefatto chiave, registrarlo con il framework GRC e usarlo per fornire la posizione di conformità sarà oggetto del nostro post sul blog sul Protocollo di scambio GRC.
Conclusione
In questo primo post del blog di questa serie multi-blog, abbiamo coperto le principali persone previste nel framework di gestione della Governance, del Rischio e della Conformità (GRC). Come avrete certamente notato, abbiamo definito un insieme specifico di azioni che si concentrano su una separazione teorica dei compiti per ogni persona. Tuttavia, in un’organizzazione reale, un individuo può ricoprire più ruoli, nel qual caso svolgerà le azioni associate a tutte quelle persone.
Cosa verrà dopo?
Nel nostro prossimo post del blog, pianifichiamo di fornirvi una copertura dettagliata degli artefatti di conformità gestiti nel flusso di conformità end-to-end, dalla rappresentazione dei regolamenti alla posizione di conformità ai rapporti degli auditor. Forniremo anche la loro rappresentazione come codice utilizzando lo standard NIST OSCAL, con esempi concreti pronti all’uso per l’implementazione della conformità continua dei cataloghi che rappresentano gli standard (ad esempio, NIST 800-53), i profili che rappresentano le linee guida, i risultati delle valutazioni e altro ancora, insieme alle loro interdipendenze nel framework di Governance, Rischio e Conformità e alle relazioni con i ruoli e le azioni delle persone introdotte in questo blog.
Di seguito sono riportati i collegamenti ad altri articoli di questa serie:
- Soluzione standard automatizzata di conformità (COMPASS), Parte 2: Trestle SDK
- Soluzione standard automatizzata di conformità (COMPASS), Parte 3: Artefatti e Persone
- Soluzione standard automatizzata di conformità (COMPASS), Parte 4: Topologie dei Centri di Amministrazione delle Politiche di Conformità
- Soluzione standard automatizzata di conformità (COMPASS), Parte 5: Una mancanza di confini di rete invita a una mancanza di conformità
- Soluzione standard automatizzata di conformità (COMPASS), Parte 6: Conformità alle Politiche per Più Cluster Kubernetes
