Quanto conosci della tua matrice dei rischi?
Indipendentemente dallo strumento che utilizzi per effettuare l'analisi dei rischi di accesso, potrebbe essere utile approfondire.
Si tratta della matrice SoD del prodotto GRC Access Control, in particolare del modulo chiamato Access Risk Analysis.
In GRC, viene chiamata insieme di regole, ovvero di tutte le combinazioni che vengono generate tra gli oggetti della matrice (action e permission), leggi qui l'articolo di approfondimento.
A valle del progetto di gestione della SoD, se non vengono definiti, come previsto della metodologia di gestione della Segregation Of Duties suggerita da SAP, i processi di continuous compliance, la matrice spesso viene abbandonata per anni.
Cosa significa questo e cosa comporta ad esempio?
Significa che stai basando le tue analisi dei rischi di accesso su dati non aggiornati e potenzialmente non del tutto corretti. Generando anche dei falsi negativi.
Quando sopra è vero solo nel caso del sistema SAP GRC Access Control? In realtà no.
Vale potenzialmente per tutti i sistemi che permetto di effettuare delle risk analysis analoghi al SAP GRC Access Control per i sistemi SAP.
Cosa intendo dire? Spesso, anzi, direi quasi sempre la matrice viene caricata in modo massivo nel sistema GRC. Questo comporta, in alcuni casi, che diverse parametrizzazioni non siano corrette.
Questo non significa che sia sbagliato caricarla in maniera massiva. Un errore può essere commesso caricandola in maniera massiva ma anche puntualmente.
La criticità di quanto sopra può tuttavia portare a dei falsi negativi. Ovvero il sistema non rileva dei rischi potenziali che in realtà ci sono.
Ad esempio?
1) Transazioni che non esistono a sistema ma sono presenti in matrice (in questo caso non è una criticità vera e propria). Ma perché tenere in matrice dei dati non corretti? In realtà questo aspetto è vero per problemi di "battitura dati" Es. scrivo ME2wN anziché ME22N o casi simili.
2) Oggetti che non esistono. Questo è un caso più grave. GRC non troverà mai quella regola. In quanto stiamo chiedendo a GRC di trovare degli oggetti che non esistono a sistema es. M_MSEG_LOG anziché M_MSEG_LGO
3) Valori di oggetti che non esistono. Come sopra. Cerco il valore dell'attività 81 quando per un certo oggetto autorizzativo quella attività non è previste. Il GRC in questo caso non troverà mai quella regola a sistema.
Sono solo alcuni esempi, per questo motivo, come Aglea, abbiamo definito una serie di regole di verifica della matrice dei rischi.
Certo, non stiamo parlando di errori o mancanze a livello di processo, questo sarebbe più difficile da rilevare (richiede un investimento maggiore di tempo rispetto a rilevare errori tecnici). Ma anche l'aspetto tecnico della matrice deve essere considerato.
Sei davvero sicuro che nella tua matrice non siano presenti errori tecnici?