Progetto Segregation of Duties: quanti rischi devono essere definiti?

In questo momento stai affrontando un progetto di Segregation of Duties (SoD) o dovrai farlo nel futuro? Devi definire i rischi ma non sai quanti?

Ogni società ha i suoi processi, non tutti sono SoD relevant: non c’è sicuramente un numero di riferimento. Una delle domande più frequenti durante gli incontri per la definizione della matrice SoD è sicuramente: quanti rischi dobbiamo definire?

Non esiste chiaramente una risposta univoca, ma possiamo vedere cosa hanno fatto dieci società italiane!

Attenzione: questo non significa che quanto hanno fatto debba diventare una regola fissa da applicare, tuttavia può dare un’idea di massima.

Quali sono le fasi del progetto di gestione della SoD?

La Segregation of Duties prevede questi passaggi per essere gestita:

• Definizione dei rischi
• Analisi del sistema
• Remediation
• Mitigation
• Continuous compliance

Vediamo la fase di definizione dei rischi.

Quali sono i suggerimenti prima di iniziare?

• All’inizio, identificare pochi rischi ma ben riconosciuti all’interno dell’area di business di riferimento. Questi rischi devono essere facilmente comprensibili ed accettati dagli interlocutori e soprattutto dagli owner dei rischi. In molti casi, partendo da matrici pre-configurate è facile incorrere in rischi che non sono tali nella propria organizzazione.
• Per i rischi che sono stati identificati, cerca di effettuare tutto il percorso della SoD. Questo ti può aiutare a comprendere meglio le varie difficoltà nei diversi passaggi di progetto.
• A seguito dell’introduzione dei rischi e della loro gestione completa, amplia gradualmente lo spettro.

Spesso, viene commesso un errore comune tra le figure professionali che, in azienda, devono collaborare su questo genere di progetti. I settori coinvolti sono diversi, ma i più frequenti sono:

• IT
• Audit
• Business

È possibile che - soprattutto nelle società più strutturate - lavorino all’interno dell’IT diverse figure come: CIO, CISO, IT Manager, Key User, Business Process Owner...

Un progetto di gestione della SoD riguarda il reparto business, così come l’identificazione e la risoluzione organizzativa dei rischi; l’IT, qualsiasi figura essa sia, deve essere solo a supporto e può essere coinvolto in prima persona quando si parla di rischi dei processi legati al suo settore. In questo caso, diventa un attore attivo nel progetto.

Quindi, quanti rischi definire?

Qui di seguito, il grafico mostra il numero di rischi per 10 società italiane a confronto con la matrice standard del prodotto SAP GRC Access Control.

Sulle ordinate: il numero di rischi (colonna blu), numero di Duties (colonna Rossa), il numero delle transazioni SoD relevant in matrice (linea continua con triangolo rosso).

Che cosa emerge da questi dati?

Il numero medio di rischi presenti nelle matrici prese in esame è 85. Questo numero è molto più basso rispetto ai rischi presenti nella matrice standard SAP del prodotto Access Control: in questo strumento i rischi sono 300.Anche il numero di transazioni considerate SoD relevant è diverso: la media, tuttavia, è di 700.

Per le finalità della Segregation of Duties, le transazioni che hanno un impatto sono quelle in creazione o modifica, quelle in sola visualizzazione, invece, non sono SoD relevant. L’esclusione di quest’ultime, tuttavia, potrebbe non essere corretta in caso di altre normative come, ad esempio, il regolamento per la protezione dei dati personali (GDPR).

Una società che sfrutta SAP sui principali moduli, utilizza in media dalle 2.500 alle 3.000 transazioni. In base alla statistica presentata poco fa, le transazioni SoD relevant sono più o meno il 20%: non una percentuale bassa.

Ecco i settori delle 10 società italiane prese come riferimento:

• Manifatturiero
• Chimico
• Farmaceutico
• Automotive
• Energia
• Media

Ricordiamo che anche le transazioni custom devono essere inserite nella matrice SoD se hanno impatti sul bilancio. Se, invece, non hanno controlli autorizzativi, è necessario prevedere la modifica del codice ABAP affinché siano presenti.

Anche la tipologia dei rischi è importante:

• Rischi SoD: coppie (o ennuple) di azioni in conflitto tra loro
• Rischi di tipo critical action: parti di processo rischiose da sole
• Rischi di tipo critical permission: oggetti tecnici che sono critici per definizione, spesso dell’area IT

Nel caso in cui un processo sia suddiviso tra sistemi, è importante considerare un’analisi cross system.

Aglea può aiutarti a definire la matrice delle regole: abbiamo diversi template da cui partire. Inoltre, abbiamo sviluppato una soluzione che permette di capire in maniera semi automatica su quali processi SoD hanno un impatto (in scrittura ma anche in lettura) le transazioni custom.

Infine, se hai bisogno di effettuare una risk analysis dei tuoi sistemi, possiamo aiutarti con il nostro strumento Security Analyzer.