ERP-Security-Audit VAE: Was tatsächlich geprüft wird

TL;DR. Ein ERP-Security-Audit prüft fünf Dinge: Zugriff, Funktionstrennung, Änderungskontrolle über Eigenentwicklungen und Transporte, Schnittstellen zu anderen Systemen und den Weg der Daten. In den VAE kommen die UAE Information Assurance Standards für den Control-Satz und das PDPL für personenbezogene Daten hinzu, die das Land verlassen. Die Feststellung, die überall wiederkehrt, ist dieselbe: Eine kleine Zahl von Benutzern hält Berechtigungskombinationen, mit denen eine Person einen Zahlungszyklus allein abschließen kann, und niemand wusste davon, weil die Berechtigungen über verschachtelte Rollen und nicht direkt vergeben wurden.

Im ERP liegt das Geld, und deshalb unterscheidet sich dieses Audit von jedem anderen technischen Audit im Haus. Ein Schwachstellenscan fragt, ob ein Angreifer hineinkommt. Ein ERP-Security-Audit fragt, ob jemand, der bereits drin ist und legitime Zugangsdaten hat, Geld bewegen, einen Stammsatz ändern oder die Spur davon löschen kann. Das Bedrohungsmodell ist autorisierter Zugriff in einer nicht autorisierten Kombination.

Inhalt

Zugriff: wer hat was, und warum immer noch
Funktionstrennung: die Konflikte, die sich auszahlen
Änderungskontrolle: Eigenentwicklungen und Transporte
Schnittstellen: die Konten ohne Eigentümer
Daten: Speicherort und was das PDPL verlangt
Was das Audit liefert und was es kostet

                    ┌────────────────────────────────┐
                    │  ERP security audit scope      │
                    └───────────────┬────────────────┘
                                    │
        ┌───────────────┬───────────┼───────────┬───────────────┐
        ▼               ▼           ▼           ▼               ▼
  ┌───────────┐  ┌────────────┐ ┌────────┐ ┌──────────┐ ┌─────────────┐
  │ Access    │  │ Segregation│ │ Change │ │Interfaces│ │ Data and    │
  │ who has   │  │ of duties  │ │ custom │ │ what     │ │ residency   │
  │ what, why │  │ conflicts  │ │ code,  │ │ talks to │ │ what leaves │
  │ still     │  │ that pay   │ │ trans- │ │ it, with │ │ the country │
  │           │  │ out        │ │ ports  │ │ what     │ │ and why     │
  └───────────┘  └────────────┘ └────────┘ └──────────┘ └─────────────┘
        │               │           │           │               │
        └───────────────┴───────────┼───────────┴───────────────┘
                                    ▼
                       Evidence per finding, dated,
                    traceable to a control identifier

Die fünf Bereiche eines ERP-Security-Audits

1. Zugriff: wer hat was, und warum immer noch

Jedes ERP-Audit beginnt hier, und die meisten Feststellungen entstehen hier. Die Frage ist nicht, ob ein Berechtigungsmodell existiert, denn es existiert, jedes Produkt bringt eines mit. Die Frage ist, ob dieses Modell die Wirklichkeit noch beschreibt, nachdem ein Jahrzehnt aus Rollenänderungen, Zusammenschlüssen, Projekten und Notfallvergaben darüber hinweggegangen ist.

Vier Muster erklären das meiste, was ein erstes Audit findet. Dauerhaft privilegierter Zugriff, der für einen Go-Live 2019 vergeben und nie entzogen wurde. Verschachtelte Rollenvererbung, bei der eine harmlos aussehende Rolle drei Ebenen tiefer eine sensible Berechtigung mitbringt, weshalb ein Audit effektive Berechtigungen prüfen muss und nicht zugewiesene Rollen. Verwaiste Konten von Personen, die das Unternehmen verlassen haben und die überleben, weil der Austrittsprozess beim Identity Provider endet und das ERP seinen eigenen Benutzerstamm führt. Und geteilte Konten für ganze Teams, die den Nachweispfad genau dort beenden, wo er zählt, weil jede Handlung dem Konto und nicht einer Person zugerechnet wird.

Die Prüfung ist mechanisch: jeden Benutzer auf seine effektiven Berechtigungen auflösen und den fachlichen Eigentümer bitten, jede sensible davon zu begründen. Der Begründungsschritt bringt den Wert, denn ungefähr ein Drittel lässt sich von niemandem mehr begründen, der noch im Haus ist.

2. Funktionstrennung: die Konflikte, die sich auszahlen

Die Funktionstrennung ist der Kern der Disziplin und der Teil, der am häufigsten zum Formalismus schrumpft. Das Control besagt nicht, dass Aufgaben im Organigramm getrennt sind. Es besagt, dass keine einzelne Person einen vollständigen Werttransfer allein ausführen kann und dass das System dies erzwingt und nicht die Unternehmenskultur.

Drei Konflikte wiegen schwerer als alle anderen, weil sie sich unmittelbar in Verlust übersetzen. Lieferant anlegen und Zahlung freigeben. Bankverbindung eines Lieferanten ändern und einen Zahllauf genehmigen. Eine Buchung erfassen und dieselbe Buchung genehmigen. Alles Weitere auf einer üblichen Konfliktmatrix ist real und nachrangig.

Die Abfrage unten zeigt, wie die Prüfung praktisch aussieht. Rollen- und Berechtigungsnamen unterscheiden sich je Produkt, die Form nicht: effektive Vergaben auflösen, über den Benutzer selbst verbinden und nach dem Paar suchen.

sql

-- The conflict that actually matters: one person who can both create a
-- vendor and release a payment to it. Roles differ per ERP; the shape
-- of the query does not.

WITH grants AS (
    SELECT u.user_id, u.display_name, r.role_id, p.permission
    FROM   user_role  u
    JOIN   role_perm  r ON r.role_id = u.role_id
    JOIN   permission p ON p.permission_id = r.permission_id
    WHERE  u.valid_to IS NULL          -- current grants only
)
SELECT   g1.user_id, g1.display_name,
         g1.permission AS creates_vendor,
         g2.permission AS releases_payment
FROM     grants g1
JOIN     grants g2 ON g2.user_id = g1.user_id
WHERE    g1.permission IN ('VENDOR_CREATE', 'VENDOR_BANK_EDIT')
  AND    g2.permission IN ('PAYMENT_RELEASE', 'PAYMENT_RUN_EXECUTE')
ORDER BY g1.display_name;

Der Konflikt, der sich unmittelbar in Verlust übersetzt

Zwei Verfeinerungen trennen ein brauchbares Ergebnis von einer langen Liste, auf die niemand reagiert. Erstens danach filtern, ob der Benutzer die Berechtigung im Zeitraum tatsächlich genutzt hat, denn ein theoretischer Konflikt bei jemandem, der keine der beiden Hälften je verwendet hat, hat geringere Priorität als ein aktiver. Zweitens den Konflikt über die Genehmigungskette hinweg prüfen und nicht nur innerhalb einer Person, denn eine Führungskraft, die die Arbeit der eigenen Vertretung genehmigen darf, stellt den Konflikt über eine Ecke wieder her.

Wo ein Konflikt nicht auflösbar ist, und in einem Finanzteam aus sechs Personen ist er das häufig nicht, lautet die Antwort: ausgleichendes Control mit Nachweis. Also ein Bericht über jede Zahlung, die von einem Benutzer freigegeben wurde, der auch Lieferanten anlegen kann, geprüft und gezeichnet von jemandem außerhalb der Kette. Ein nicht behandelter Konflikt ist eine Feststellung; ein behandelter ohne Nachweis der Prüfung ist dieselbe Feststellung mit Zwischenschritten.

3. Änderungskontrolle: Eigenentwicklungen und Transporte

Kein ERP läuft im Auslieferungszustand. Eigenentwicklungen, Konfiguration und Berichte wandern über einen Transportmechanismus von der Entwicklung in die Produktion, und dieser Mechanismus ist eine Kontrollfläche, die die meisten Audits unterbewerten.

Geprüft wird: ob ein Entwickler einen Transport allein in die Produktion bringen kann, ob die Produktion für direkte Änderungen offen steht, ob Eigenentwicklungen mit Berechtigungsprüfungen von jemand anderem als dem Autor geprüft wurden und ob Notfalländerungen einen nachgelagerten Genehmigungspfad haben, der auch benutzt wird und nicht nur beschrieben ist.

Die wiederkehrende Feststellung ist keine Böswilligkeit, sondern Bequemlichkeit. Die Produktion wird für ein Projekt geöffnet, für ein Support Package, für eine Jahresabschlusskorrektur, und nie wieder geschlossen. Die Nachweisfrage folgt sofort: Steht die Produktion offen, ruht jede weitere Control-Aussage über das System auf der Annahme, dass niemand davon Gebrauch gemacht hat, und diese Annahme lässt sich nicht belegen.

4. Schnittstellen: die Konten ohne Eigentümer

Das ERP steht nicht allein. Es tauscht Daten mit Bankplattformen, Lohnabrechnung, Lagersystemen, E-Commerce, Business Intelligence und zunehmend mit einem KI-Assistenten, den jemand während eines Pilotprojekts angebunden hat. Jede Schnittstelle authentifiziert sich als irgendetwas, und dieses Etwas ist in der Regel ein technisches Konto mit weiten Rechten, einem Passwort, das seit dem Bau der Integration unverändert ist, und ohne benannten Eigentümer.

Das Audit inventarisiert jede Schnittstelle, löst auf, was jedes Konto tatsächlich darf, und fragt, wer es besitzt. Es fragt außerdem, was die Schnittstelle überträgt, denn eine Integration, die für drei Felder gebaut wurde, liest nach einer späteren Änderung häufig eine ganze Tabelle, und niemand hat die Berechtigung nachgezogen.

Erreicht eine Schnittstelle ein System außerhalb des Landes, wird aus der technischen Frage eine regulatorische, und das ist der nächste Abschnitt.

5. Daten: Speicherort und was das PDPL verlangt

Ein ERP hält Personaldaten, Kundendaten und in vielen Häusern Gesundheits- oder Finanzdaten identifizierbarer Personen. Damit liegt es mitten im Anwendungsbereich des Personal Data Protection Law der VAE, und damit wird die Schnittstelleninventur zugleich eine Übermittlungsinventur.

Daraus ergeben sich zuverlässig drei Fragen. Welche Verarbeitungstätigkeiten im ERP betreffen personenbezogene Daten, und ist jede im Verzeichnis der Verarbeitungstätigkeiten erfasst. Wohin gehen diese Daten physisch, einschließlich Sicherungen, Notfallwiederherstellung, Supportzugriff eines Offshore-Teams und der Auswertungsschicht, denn ein Berichtswarehouse in einer anderen Region ist eine Übermittlung, ob es jemand so genannt hat oder nicht. Und welche Rechtsgrundlage und welche Übermittlungsbedingung gilt jeweils, dokumentiert vor der Übermittlung und nicht nach der Nachfrage.

Für Einheiten im DIFC oder ADGM gilt ein anderes Recht, und für Einheiten in kritischen Sektoren kommen die UAE IA (NESA) Standards hinzu, unter denen das ERP in die technischen Control-Familien für Zugriffskontrolle, Protokollierung und Kryptographie fällt. Ein einziges Audit kann für alle drei antworten, sofern der Control-Satz einmal zugeordnet und nicht dreimal geprüft wird.

6. Was das Audit liefert und was es kostet

Ein brauchbares ERP-Security-Audit liefert vier Artefakte: eine Karte der effektiven Berechtigungen je Benutzer, eine Konfliktmatrix mit markierten tatsächlich ausgeübten Konflikten, ein Feststellungsregister, in dem jede Feststellung den geprüften Nachweis und das zugeordnete Control benennt, und einen Maßnahmenplan, sortiert nach Risiko und nicht nach Aufwand.

Die Dauer hängt fast ausschließlich an einer Variablen: ob sich die Berechtigungsdaten programmatisch extrahieren lassen oder aus Bildschirmmasken zusammengetragen werden müssen. Mit Extrakten läuft ein Audit einer Instanz drei bis fünf Wochen. Landschaften mit mehreren Instanzen, oder solche, in denen ein Systemintegrator den Zugang hält, dauern länger und beginnen mit einer Verhandlung über den Datenzugriff statt mit dem Audit.

Was es nicht liefern sollte, ist ein Bericht darüber, dass das ERP unsicher sei. Jedes ERP mit zehn Jahren Geschichte hat diese Feststellungen; die Frage, die der Vorstand tatsächlich stellt, lautet, welche davon in diesem Quartal geschlossen werden können und welche eine Prozessänderung über ein Jahr brauchen. Wir machen diese Arbeit im Rahmen von Information-Security-Audits in Dubai, und wo sich eine Feststellung als strukturell statt technisch erweist, wandert sie in die IT-Security-Governance in den VAE.

Weiterlesen

UAE Information Assurance Regulation v1.1, TDRA, technische Familien T1 bis T9
Federal Decree-Law No. 45 of 2021 zum Schutz personenbezogener Daten
ISACA, Segregation of Duties Control Matrix, für die Konflikttaxonomie
ISO/IEC 27001:2022, Anhang A.5.15, A.8.2 und A.8.32