Segregation of Duties in SAP

A seguito degli scandali finanziari (ad esempio Enron, Parmalat) degli anni duemila e della sfiducia nel mercato che hanno generato, i governi hanno deciso di definire delle regole per tutelare gli investitori.

Ogni stato, a partire dagli Stati Uniti, ha definito una propria normativa a riguardo. Gli obiettivi principali sono i seguenti:

• Responsabilizzare le società sulle tematiche di accountability e relazioni finanziarie
• Aumentare le pene dovute a crimini o illeciti contabili

La normativa apripista, quella degli Stati Uniti, è la Sarbanes and Oxley act proposta dal deputato Oxley e dal senatore Sarbanes, appunto, e comunemente conosciuta come SOX. In Italia le normative di riferimento sono la legge 262/2005 (Disposizioni per la tutela del risparmio e la disciplina dei mercati finanziari) ed il decreto legislativo 231/2001 (Disciplina della responsabilità amministrativa delle persone giuridiche, delle società e delle associazioni anche prive di personalità giuridica, a norma dell’articolo 11 della legge 29 settembre 2000, n. 300).

Normative specifiche della stessa natura esistono anche in altri Paesi, ad esempio per l’area Giapponese FIEA o J-SOX (Financial Instruments and Exchange Act: Financial Services Agency), C-SOX per il Canada. Anche l’Europa ha deciso di regolamentare questi aspetti con una specifica direttiva (8th Directive – The Eighth Council Directive 84/253/EEC of 10 April 1984). Non ultimi i framework di riferimento come l’IFRS Internal Controls/Financial Reporting. Diversi sono i requisiti che le normative appena elencate richiedono di ottemperare. Tra questi vi è anche la tutela della separazione dei compiti, conosciuta anche come Segregation of Duties (SoD) o Separation of Duties.

Lo scopo della SoD (Segregation of Duties) è assicurare che solo le persone ritenute idonee possano eseguire delle transazioni “sensibili”; è quindi necessario spezzare il processo in modo che un utente non rappresenti un rischio di frode.

Un modello tecnico per affrontare la Segregation of Duties prevede l’impiego dei due insiemi seguenti:

• La libreria delle duties, ovvero le famiglie di transazioni (azioni di business in SAP. Ad esempio: creare una richiesta di acquisto, effettuare una modifica all’anagrafica materiali etc..).
• La libreria dei rischi, ovvero le duties in conflitto tra di loro

Una DUTY (o function) rappresenta un certo insieme di transazioni che compongono una parte di un processo. In altre parole, la duty rappresenta, come già detto, una certa attività di business eseguita in SAP (creazione anagrafica fornitori, rilascio fatture bloccate, creazione ordini di vendita etc.)

La libreria dei rischi definisce le parti di processo che sono in conflitto tra loro. L’immagine seguente mostra un esempio di rischi sul processo acquisiti. Nel caso di SAP, oltre alle attività standard previste, devono essere considerate anche tutte le personalizzazioni del cliente, ovvero tutte le transazioni custom che hanno un impatto sui processi dichiarati come SoD relevant.

Vediamo quindi che nella tabella Elenco conflitti (rischi) troviamo il rischio chiamato RISK01 che è formato da due parti del processo degli acquisiti: Creazione RDA e Rilascio RDA.

Queste due duty contengono a loro volta l’insieme delle attività (transazioni tecniche in SAP) che permetto di svolgere all’interno dell’applicativo quella certa funzionalità. Quali sono i termini utilizzati nella gestione della Segregation of Duties?

• Ruleset o matrice
  • Rappresenta l’insieme dei rischi o delle regole (nel caso dello strumento SAP Governance Risk and Compliance, Access Control di SAP la matrice viene chiamata ruleset).
• Processo
  • Identifica un insieme di attività
• Rischio
  • È un insieme formato da coppie o più di function in conflitto tra loro
• Function/duties
  • Rappresenta un insieme di attività che formano un processo aziendale
• Action/Permission
  • Sono il dettaglio tecnico delle attività (transazioni) ed oggetti autorizzativi (permission) usati in ambiente SAP per poter svolgere una attività di business all’interno del sistema
• Controlli compensativi
  • Definiscono una sequenza di azioni usata per verificare e controllare le evidenze reali di rischio

Quali sono le fasi di gestione della Segregation of Duties?

Il processo di gestione della SoD non termina con l’introduzione e la verifica a sistema della matrice, questo rappresenta solamente l’inizio di un percorso.
I passaggi per la gestione della SoD sono infatti i seguenti:

• Definizione della matrice Risk analysis del sistema
• Attività di Remediation
• Attività di Mitigation
• Definizione di procedure di Continuous compliance

Di fondamentale importanza vi è la fase di scoping dei processi. In questo momento è necessario Individuare i processi a rilevanza SoD coinvolti, ovvero quelli che hanno un diretto impatto sul bilancio.

Per ogni processo definito nella fase di scoping è necessario individuare quali siano i rischi di frode al suo interno. Uno degli esempi classici è il seguente: un utente non può allo stesso tempo creare o modificare dei fornitori ed iniziare un pagamento nei loro confronti. In questo caso, si potrebbe definire un fornitore fittizio spostando a seguito del denaro in maniera illecita.
È importante non esagerare nella definizione iniziale dei rischi all’interno dei vari processi. Inoltre, anche se può sembrare prematuro, la definizione degli owner dei rischi può rappresentare un punto di forza per i passaggi successivi.

La costruzione dei rischi, inoltre, può prevedere coppie (o ennuple) di function o duty tra loro in conflitto. Attenzione, anche in questo caso, a non esagerare: meglio usare coppie o al massimo triplette di function tra loro in conflitto per descrivere una situazione di rischio.

Il concetto di rischio può essere declinato in diverse tipologie:

• Rischio di business o Rischio SoD: quando prevede che per realizzare una frode o un danno vi sia l’unione di più parti di processo
• Rischio IT (Information Technology) o Attività critica (critical actions): quando prevede che per realizzare una frode o un danno sia sufficiente solo una parte specifica di processo
• Rischio tecnico o critical permission: quando prevede che per realizzare una frode o un danno sia sufficiente solamente una specifica autorizzazione tecnica Conclusa la fase di definizione della matrice, è necessario analizzare il sistema o i sistemi coinvolti.

Risk Analysis dei sistemi

In caso di volumi (utenti e ruoli definiti a sistema) molto ridotti, la risk analysis potrebbe essere eseguita, seppur senza poche difficoltà, manualmente. Nella maggior parte delle situazioni, tuttavia, è necessario dotarsi di uno strumento ad hoc. Quali sono i principali strumenti?

• SAP Governance Risks and Compliance – Access Control (SAP)
• SAP Identity Access Governance
• SecurityWeaver
• Security Analyzer (Talia Security)
• IBM IGI (Identity Governance & Intelligence)

È importante sottolineare che le scelte fatte durante la definizione della matrice influiranno sugli output prodotti dagli strumenti. Può capitare che risultati non desiderati o inaspettati siano causati da errori tecnici della matrice. In questo caso deve essere corretta la matrice stessa. Alcuni degli strumenti sopra indicati hanno al loro interno una matrice “standard” di partenza, da utilizzare come riferimento. Le personalizzazioni del cliente devono essere analizzate ed integrate nella matrice se hanno impatti SoD.

Il risultato dell’analisi dei rischi SoD può essere di due tipi:

• Nessun rischio rilevato (situazione molto rara)
• Rischi da dover gestire (situazione più probabile)

Il soggetto analizzato deve essere sia l’utente sia il ruolo tecnico SAP. Nel caso in cui ci siano rischi da dover gestire, deve essere definito un piano di remediation.

Come effettuare la remediation dei rischi?

Questa fase può essere affrontata in due passaggi:

• Senza interazione con il business
• Con interazione con il business

Spesso, nel primo caso, la sola rimozione di tutto ciò che non è mai stato utilizzato può abbattere di molto il numero di rischi emerso in fase di analisi. Mentre nel secondo caso, dove è prevista una interazione con il business normalmente svolta a seguito del primo passaggio, si interviene andando a modificare degli aspetti organizzativi. Ricordiamo che modificare gli aspetti organizzativi non è mai immediato e spesso difficile da realizzare.

Nel caso in cui non sia possibile procedere a livello tecnico o organizzativo è necessario mantenere la situazione di rischio ma controllarla. Questo può avvenire tramite la definizione di un processo di controllo.

Come gestire la fase di mitigation?

Terminata la fase di «pulizia» potrebbero rimanere dei casi di rischio non eliminabili, né tramite tecnicismi né organizzativamente. È il caso, ad esempio, di una piccola filiale con un numero limitato di persone operative su tutti i processi.

In questi casi è necessario definire un controllo compensativo o mitigation control il quale rappresenta una verifica da porre in essere per governare l’insorgenza di uno o più rischi. I controlli possono essere principalmente di due tipi:

• Preventive – Ovvero effettuati in anticipo
• Detective – Ovvero effettuati a posteriori

I controlli preventive sono più difficili da realizzare rispetto a quelli detective che generalmente rappresentano la maggior parte dei controlli compensativi adottati. In contesti molto complessi anche la naming dei controlli compensativi può essere molto importante. Spesso esistono già dei software aziendali come repository dei controlli compensativi.

Se la fase di analisi e remediation non è stata condotta adeguatamente, la definizione dei controlli compensativi può rappresentare un ostacolo troppo grande da poter superare. È importante sottolineare che la definizione delle mitigazioni rappresenta un costo in termini di monitoraggio e manutenzione: spesso devono essere create ex-novo e riguardano anche processi personalizzati. Questi ultimi sono normalmente più complicati da gestire.

Al termine della fase di remediation e mitigation, ogni rischio è stato rimosso o posto sotto controllo. È fondamentale ricordare che la gestione della SoD non termina con la definizione dei controlli compensativi.

Ogni giorno, ad esempio, vengono create o modificate transazioni, se sono SoD relevant è importante gestirle nella matrice. Nuovi utenti possono entrare a far parte dell’organico oppure essere rimossi o spostati. La ri-validazione periodica degli accessi e dei rischi riveste un ruolo importante.

Diventa quindi essenziale istituire una serie di procedure che permettano di tenere sotto controllo che le modifiche apportate al sistema siano conformi ai requisiti della Segregation of Duties.

Come ti può aiutare Aglea nel semplificare la gestione della Segregation of Duties?

Abbiamo definito molte matrici di Segregation of Duties nel corso degli anni. Queste possono essere utilizzate come base di partenza per adattarle alla realtà aziendale.

Possiamo aiutarti a verificare che la matrice sia conforme ai processi di business, limitando il numero di falsi positivi. Spesso il risultato della risk analysis, essendo molto tecnico, è di difficile lettura. Siamo in grado di realizzare dei report che permettono di capire chi deve fare cosa ed in che ordine, dando una visione chiara e precisa del risultato della risk analysis.

Nella fase di remediation spesso non è chiaro da dove e come partire. Aglea ha definito un modello di gestione della remediation che può essere applicato a piccole società (dove la Segregation of Duties è più complicata da dover gestire), ma anche per i gruppi industriali molto strutturati.

La definizione dei controlli compensativi è sempre un punto critico del progetto, spesso non affrontato. La definizione delle mitigazioni prevede la conoscenza dei processi di business (non solo standard ma anche custom) e l’implementazione funzionale e tecnica del controllo mitigativo. Per questo motivo Aglea ha definito una libreria di controlli compensativi da adattare alla realtà dei clienti, senza dover partire da un foglio bianco.