Der Einsatz von Can- und Did-Do-Analysen im Rahmen von regelmäßigen Kontrollaktivitäten

| Autor/in:Johannes Schwarzenberger
Blog-Artikel

1 Einleitung

Die regelmäßige Überprüfung, welche Mitarbeiter auf welche Systeme und Daten Zugriffe haben ist für die Unternehmenssicherheit und auch aus Compliance-Gründen unverzichtbar. In unterschiedlichen gesetzlichen Vorgaben (u.a. DSGVO) werden verbindliche Anforderung für den Zugriff auf Daten vorgegeben. Die Zugriffsrechte sollten nicht nur bei Mitarbeitereintritt und -austritt vergeben und entzogen, sondern auch in regelmäßigen Abständen kontrolliert werden. Zusätzlich zur Analyse der Berechtigungen zu einem bestimmten Zeitpunkt (Can-Do Analyse) ist es auch empfehlenswert, die erfolgten Änderungen in einem System im Nachhinein für einen bestimmten Zeitraum zu überprüfen (Did-Do Analyse). Die beiden Analyseformen ergänzen sich gegenseitig und adressieren unterschiedliche Risiken.

1.1 Can-Do Analyse

In der Can-Do Analyse werden die Zugriffsrechte von Benutzern im jeweiligen IT-System analysiert. Dabei werden zu einem bestimmten Zeitpunkt die Lese- und Schreiberechte auf Daten ausgewertet.

Bei der Can-Do Analyse handelt es sich um eine präventive Kontrolle. D.h. die Kontrolle stellt im Vorhinein sicher (durch Berechtigungen), dass Benutzer nur die Daten sehen und verändern können, welche sie in ihrem Arbeitsalltag benötigen (Need-to-know Prinzip). Mit der Analyse können Schwächen bei der initialen Berechtigungsvergabe oder bei Berechtigungsänderungen (hinzufügen von Berechtigungen im laufenden Geschäft) aufgedeckt werden. Es kann nachgewiesen werden, welche Benutzer lesende und schreibende Rechte auf Daten besitzen.

Die Analyse sollte periodisch (zumindest einmal jährlich) durchgeführt werden und als Folgehandlungen sollten nicht benötigte Berechtigungen entzogen werden. Dies ist von den jeweiligen Data Owner („Dateneigner“) zu bestimmen. In einem idealen Prozess wird die Analyse dem Data Owner vorgelegt (in verständlicher Form) und dieser meldet zurück, welche Berechtigungen in seinem Bereich entzogen werden sollten. Hier ist es besonders wichtig die Verantwortung dem Data Owner zu geben und nicht der IT-Abteilung, welche nur für die Durchführung der Berechtigungsvergabe bzw. -veränderung zuständig ist. Um einen standardisierten Ablauf zu gewährleisten, sollte man auch ein Tool zur Unterstützung der Analysen verwenden. Der Aufbau eines eigenen Regelwerkes (Rulesets) erfordert sehr tiefes Know-How bzgl. System und Prozesse.

Im ERP-System SAP erfolgt der Großteil der Zugriffe über Transaktionen oder Fiori-Apps. Deshalb erfolgt die Prüfung der Zugriffsrechte nicht nur auf Tabellen, sondern auch auf die Transaktionen und Apps. Wenn bereits eine Umstellung auf die HANA-Datenbank erfolgt ist, müssen auch die Zugriffsrechte auf der Datenbank analysiert werden.

1.2 Did-Do Analyse

In der Did-Do Analyse wird ausgewertet welche Aktionen von Benutzern tatsächlich durchgeführt wurden. Dabei liegt der Fokus auf Veränderungen von Daten. Diese Veränderungen werden in den meisten ERP-Systemen mitprotokolliert. Im SAP wird in den meisten Stammdatentabellen der Ersteller der Daten inkl. Erstellungsdatum mitgeschrieben. Zusätzlich ist es möglich über Tabellenänderungsprotokolle und Änderungsprotokolle auszuwerten welche Tabellen in einem bestimmten Zeitraum geändert wurden. Die Did-Do Analyse ist eine detektive Kontrolle. D.h. es wird im Nachhinein überprüft, welche Benutzer in welchen Bereichen Daten verändert haben. Außerdem kann auch festgestellt werden, ob durch die Datenveränderungen Funktionstrennungskonflikte entstanden sind. Dies kann in einer groben Analyse über alle Geschäftsfälle oder in einer genaueren Analyse über einen Geschäftsfall ausgewertet werden. Die Did-Do Analyse ist eine ideale Ergänzung zur Can-Do Analyse. Es kann dadurch nachgewiesen werden, ob bestimmte vergebene Berechtigungen tatsächlich genutzt wurden. Dadurch können Risiken aus der zu weiten Vergabe von Berechtigungen mitigiert werden. Jedoch ist zu bedenken, dass die Analyse immer im Nachhinein stattfindet und somit ggfs. entstandener Schaden nicht mehr behoben, sondern nur aufgedeckt und zukünftig verhindert werden kann. Die Did-Do Analyse sollte deshalb periodisch (zumindest quartalsweise) durchgeführt werden. Für sehr kritische Aktionen wie z.B. die Vergabe von Super-User Rechten (z. B. im SAP-System SAP_ALL) sollte eine höhere Frequenz der Kontrolle durchgeführt werden. Dafür empfiehlt es sich ein SIEM-Tool (Security Information and Event Management; Monitoring in Echtzeit) zu verwenden, da ansonsten die Zeit zwischen Vergabe von kritischen Berechtigungen und Durchführung der Kontrolle zeitlich sehr weit getrennt sein können.

1.3 Unterschiede zwischen Can-Do- und Did-Do-Analyse

Zusammenfassend bestehen folgende Unterschiede zwischen Can-Do und Did-Do Analysen:

 

Can-Do-Analyse

Did-Do-Analyse

Ziel

Verhindern von kritischen Aktionen (präventiv)

Aufdecken von kritischen Aktionen (detektiv)

Zeit

Zeitpunkt

Zeitraum

Frequenz

Min. jährlich

Min. quartalsweise

Folgetätigkeit

Veränderung von Berechtigungen

Mitigieren der Risiken (z.B. Did-Do-Analyse)

Impact-Analyse der kritischen Aktivitäten

Veränderung von Berechtigungen

1.4 Did-Do High-Level Analyse

In einer High Level Analyse kann ausgewertet werden, ob bestimmte Benutzer mehrere Aktivitäten eines Geschäftsfall durchgeführt haben. Im folgenden Beispiel wird ausgewertet, ob Benutzer in einem bestimmten Zeitraum im ERP-System SAP eine Bestellung, einen Materialbeleg (Wareneingang) und eine Rechnung angelegt haben. Dadurch kann festgestellt werden, ob Benutzer aller drei Aktionen durchgeführt haben, jedoch kann keine Aussage darüber getroffen werden, ob es sich dabei um den gleichen Geschäftsfall gehandelt hat.

Im folgenden Beispiel wird der genannte Funktionstrennungskonflikt (Bestellung, Wareneingang und Rechnung) im ERP-System SAP nachgestellt. Für die Tabellenauswertungen wird die Transaktion SE16H verwendet, da in dieser Transaktion die Gruppierung nach Benutzername möglich ist. Nach Auswertung der einzelnen Tabellen werden diese im Excel gesichert.

1. Auswertung der Bestellungen (inkl. Lieferpläne und Kontrakte) je User

Tabelle EKKO – Einkaufsbelegkopf
Abbildung 1: Tabelle EKKO – Einkaufsbelegkopf
Tabelle EKKO - Ausgabe der Bestellungen je User
Abbildung 2: Tabelle EKKO - Ausgabe der Bestellungen je User

2. Auswertung der angelegten Wareneingänge je User

Tabelle MKPF – Belegkopf Materialbeleg
Abbildung 3: Tabelle MKPF – Belegkopf Materialbeleg
Tabelle MKPF - Ausgabe der Wareneingänge je User
Abbildung 4: Tabelle MKPF - Ausgabe der Wareneingänge je User

3. Auswertung der angelegten Rechnungen je Benutzer

Tabelle RBKP - Belegkopf Eingangsrechnungen
Abbildung 5: Tabelle RBKP - Belegkopf Eingangsrechnungen
Ausgabe der angelegten Rechnungen je Benutzer
Abbildung 6: Ausgabe der angelegten Rechnungen je Benutzer

4. Zusammenfügen der einzelnen Ergebnisse im Excel

Danach können die Ergebnisse je Tabelle im Excel ausgewertet werden. Dazu werden alle drei Tabellen in ein eigenes Tabellenblatt eingefügt. In einem neuen Tabellenblatt werden alle User ausgegeben und über die Funktion SVerweis die Anzahl je Aktion (Bestellungen, Wareneingänge und Rechnungen) hinzugefügt. Sollten bei einem Benutzer alle drei Spalten befüllt sein, handelt es sich um einen Benutzer, der alle drei Vorgänge im ausgewerteten Zeitraum ausgeführt hat.

bild7
Abbildung 7: Auswertung der Benutzer nach Vorgängen (Bestellung, Wareneingang, Rechnung)

Im vorliegenden Fall waren zwölf Benutzer vorhanden, die innerhalb eines Kalenderjahres zumindest eine Bestellung, einen Wareneingang und eine Eingangsrechnung in der Materialwirtschaft angelegt haben. Dabei handelt es sich bereits um einen Funktionstrennungskonflikt, da kein User die Berechtigung für alle drei Aktivitäten haben sollte. Jedoch kann daraus nicht geschlossen werden, dass es sich dabei um den jeweils gleichen Geschäftsfall gehandelt hat.

Aufgrund des Ergebnisses sollten noch weiterführende Prüfungshandlungen vorgenommen werden. Dies können u.a. folgende sein:

    • Nähere Prüfung von Aktivitäten auffälliger Benutzer (z.B. von anderen Abteilungen)
    • Impact Analyse bzw. Prüfung, ob es sich bei den Aktivitäten um Fraud handeln könnte
    • Prüfung, ob die Prozessschritte auch in einem Geschäftsfall vorgenommen wurden (Detailanalyse).
    • Prüfung, ob den Benutzern die Rechte für zumindest einen der Prozessschritte entzogen werden können.

1.5 Did-Do Detailanalyse

In einer Detailanalyse kann festgestellt werden, ob Benutzer in einem Geschäftsfall mehrere Aktivitäten genutzt haben. Dazu müssen mehrere Tabellen analysiert werden, die eine Vielzahl an Datensätzen enthalten können. Daher kann die Detailanalyse an der Performance im ERP-System scheitern.

Im Folgenden wurde der gleiche Funktionstrennungskonflikt wie in der High-Level-Analyse (Kapitel 1.4) betrachtet. D.h. es wurde die Fragestellung, ob Benutzer in einem bestimmten Zeitraum eine Bestellung angelegt, den dazugehörenden Materialbeleg (Wareneingang) angelegt und die dazugehörende Rechnung angelegt haben, behandelt. Im Ergebnis finden sich Funktionstrennungskonflikte über einen einzelnen Geschäftsfall. Die Detailanalyse erfordert jedoch die Auswertung von sehr großen Datenmengen und hat dadurch Performance-Nachteile (sofern sie überhaupt möglich ist) zur groben Analyse.

Die Analyse wurde im SAP mit der Transaktion SQVI vorgenommen. Dafür wurden zusätzlich zu den drei Kopftabellen (EKKO, MKPF und RBKP) auch die drei Positionstabellen (EKPO, MSEG und RSEG) benötigt.

  1. Anlage einer neuen Auswertung mit der Transaktion SQVI (Quickview)

Um die Auswertung durchführen zu können sind im Quickviewer folgende Verlinkungen (Inner Joins) einzurichten:

Nr.

Tabellenfeld1

Tabellenfeld2

1

RBKP-BELNR

RSEG-BELNR

1

RBKP-GJAHR

RSEG-GJAHR

2

MKPF-MBLNR

MSEG-MBLNR

2

MKPF-MJAHR

MSEG-MJAHR

3

EKKO-EBELN

EKPO-EBELN

4

RSEG-EBELN

EKPO-EBELN

4

RSEG-EBELP

EKPO-EBELP

5

RSEG-EBELN

MSEG-EBELN

5

RSEG-EBELP

MSEG-EBELP

6

EKKO-ERNAM

RBKP-USNAM

7

RBKP-USNAM

MKPF-USNAM

Abbildung 8: Verlinkungen Detailanalyse

Grafische Darstellung der Verlinkungen in der Transaktion SQVI
Abbildung 9: Grafische Darstellung der Verlinkungen in der Transaktion SQVI

2. Auswahl der Selektions- und Ausgabefelder

Nach Erstellung der Verlinkungen werden die Selektions- und Ausgabefelder ausgewählt. Hier sollten in den jeweiligen Header-Tabellen (EKKO, MKPF und RBKP) jeweils die Belegnummer, der Username, ggfs. der Buchungskreis und das Ausführungsdatum der Transaktion (nicht das Beleg- oder Buchungsdatum) ausgewählt werden.

3. Ausführen der Auswertung

Danach kann die Auswertung ausgeführt werden und in einem der Datumsfelder der zu untersuchende Zeitraum eingegeben werden (je nachdem, von welchem Vorgang man ausgehen möchte).

2 Zusammenfassung

Die Durchführung von Can-Do und Did-Do Analysen ergänzen sich gegenseitig. Mit der Can-Do Analyse kann der Ist-Stand des Berechtigungskonzeptes ausgewertet und es können präventiv unautorisierte Datenzugriffe (lesend oder schreibend) verhindert werden. In der Did-Do Analyse kann aufgedeckt werden, ob in einem bestimmten Zeitraum unberechtigte Datenzugriffe vorgenommen worden sind. Aus Compliance Sicht ist es zu empfehlen beide Analysen durchzuführen, die Can-Do Analyse, um die Zugriffsrechte an die Tätigkeiten anzupassen und die Did-Do Analyse, um unberechtigte Datenzugriffe im Nachhinein aufzudecken und genauer zu untersuchen.

Ausführen der Auswertung
Abbildung 10: Ausführen der Auswertung
Auswertung Detailanalyse
Abbildung 11: Auswertung Detailanalyse

Im Ergebnis werden alle Geschäftsvorfälle aufgelistet in welchen derselbe Benutzer die Bestellung, den dazugehörigen Wareneingang und die dazugehörige Rechnung angelegt hat. Dabei handelt es sich um einen Funktionstrennungskonflikt und es sollte jedem einzelnen Fall nachgegangen werden. In manchen Fällen lassen sich Funktionstrennungskonflikte nicht vermeiden, dafür sollte jedoch eine zusätzliche mitigierende Kontrolle eingerichtet sein, in welcher z.B. stichprobenartig die einzelnen Belege und deren Buchungen eingesehen werden.