Nella gestione della Segregation of Duties in SAP, nella fase di risk analysis è possibile ragionare in diversi modi sul risultato ottenuto.

Se un utente ha un rischio come possiamo descrivere tale situazione? Spesso si utilizzano i termini Conflitto, Rischio o Violazione come sinonimi. È realmente così oppure no?

Rischio o violazione sono sinonimi?

Purtroppo, non c’è una risposta univoca dipende da quale strumento si utilizza per eseguire la risk analysis. Infatti, ogni strumento possiede una sua terminologia specifica. Possiamo tuttavia dire che in generare parlare di conflitto può essere sinonimo di rischio.

Il principale strumento che SAP offre per la risk analysis sia chiama SAP GRC Access Control nei suo modulo Access Risk Analysis (ARA). Questa la terminologia nella versione dello strumento 12. Utilizzeremo la terminologia di questo strumento come metro di misura.

Come ragione SAP GRC Access Control?

In SAP GRC esiste la violazione, che può essere di due tipologie.

• A livello di rischio
• A livello di permission o regola

Nel primo caso, per violazione a livello di rischio, s’intende quanti utenti hanno un certo rischio.

Nel secondo caso, per violazione a livello di permission, s’intende quante violazioni generano gli utenti che hanno quel rischio.

Vediamo più in dettaglio, nella sezione seguente, come funziona questo calcolo.

Come viene calcolata la violazione in SAP GRC Access Control?

Il termine violazione è da ricercare nella natura dello strumento GRC. Infatti, GRC, a fronte di un rischio genera n regole (come prodotto cartesiano) che rappresentano le combinazioni tra transazioni ed oggetti autorizzativi (presenti nelle function del rischio). Vedi figura seguente:

Nel management dashboard del SAP GRC Access Control modulo Access Risk Analysis è possibile decidere in che formato vedere i risultati della risk analysis.

Tramite il drill-down di dettaglio ad esempio sui rischi di livello "low", nel caso del rischio M004 avrò tredici utenti con questa tipologia di violazione vedi seguente.

Nella tabella GRACMGRISKD, è possibile visualizzare il medesimo conteggio nella vista sommario della risk analysis, di conseguenza avrò 13 inserimenti relativamente al sistema e rischio selezionato vedi figura seguente. La somma del risk count per questi utenti sarà di 960 ovvero il numero di violazioni a livello di permission.

Entrando infatti nello stesso report (vedi figura seguente) ma a permission level il valore sarà 960.

Nella tabella GRACUSERPRMVL ovvero il risultato della risk analysis di dettaglio del GRC a livello di permission, il conteggio univoco della colonna ACTRULEID sarà 960 per gli utenti sopra coinvolti. Nell’esempio sotto 78 righe per il caso l’utente chiamato LAST. Vedi seguente.

Conclusioni

Il numero di rischi per utente (ipotizzando sia questo il soggetto) è sempre minore o uguale al numero di violazioni.

Leggere la risk analysis in modalità rischi rispetto a violazioni può o meno mostrare dei risultati migliori o viceversa peggiori. 

Ragionare a rischi è più semplice soprattutto nelle fasi iniziali di gestione della Segregation of Duties. Le violazioni possono essere un driver sul quale eventualmente concentrarsi nella remediation o mitigation.

Abbassare, anche quasi completamente, il numero di violazioni, potrebbe lasciare immutato il numero di rischi sulle utenze. Rimuovere completamente i rischi è sicuramente la strada ideale da seguire per rendere davvero efficacie la fase di remediation o mitigation.