zurück zur Übersicht

Standards überall: SOX und SOC – der Sarbanes-Oxley-Act

Welches Unternehmen kennt das nicht: Regulationen überall. Maximalgeschwindigkeiten von Rolltreppen, Krümmungsgrad der Gurke (diese Verordnung wurde 2009 übrigens wieder aufgehoben, Anm. d. Red), die Pizza, die mit der Bezeichnung „Napoletana“ maximal vier Zentimeter dünn sein und einen Durchmesser von höchstens 35 Zentimeter haben darf. Wer soll da denn noch den Überblick behalten?! Zusätzlich zu diesen handfesten Verordnungen kommen diejenigen, die durch ihre allgemeinen Formulierungen auch mit etwas Unsicherheit behaftet sind. Datenschutzgesetze wie GDPR, PCI DSS für die Kreditkartenindustrie – oder auch der Sarbanes-Oxley (SOX) Act von 2002. Dieser fokussiert sich auf Financial Data Security mit dem Ziel, die Finanzberichterstattung sowie die Kontrolle und Transparenz von börsennotierten Firmen zu verbessern:

„To protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes.“

Dies soll durch ein standardisiertes Bilanzkontrollsystem, eine größere Haftungspflicht für Manager sowie durch Unabhängigkeit der Wirtschaftsprüfer erreicht werden. Der SOX Act betrifft alle in den USA börsennotierten Unternehmen, ausländische Unternehmen mit einer Zweitnotierung an der amerikanischen Börse sind nicht ausgenommen. Ebenfalls müssen alle Töchter von US-Konzernen im Ausland SOX-Compliant sein. Dieses Gesetz wurde als Reaktion auf die Misswirtschaft der Skandalunternehmen Enron und Worldcom eingeführt und besteht aus 11 Titles:

  • Title I) PUBLIC COMPANY ACCOUNTING OVERSIGHT BOARD
  • Title II) AUDITOR INDEPENDENCE
  • Title III) CORPORATE RESPONSIBILITY
  • Title IV) ENHANCED FINANCIAL DISCLOSURES
  • Title V) ANALYST CONFLICTS OF INTEREST
  • Title  VI) COMMISSION RESOURCES AND AUTHORITY
  • Title VII) STUDIES AND REPORTS
  • Title VIII) CORPORATE AND CRIMINAL FRAUD ACCOUNTABILITY
  • Title IX) WHITE-COLLAR CRIME PENALTY ENHANCEMENTS
  • Title X) CORPORATE TAX RETURNS
  • Title XI) CORPORATE FRAUD AND ACCOUNTABILITY

Anforderungen an die IT-Security im Unternehmen

Doch was hat das eigentlich mit einem SOC (bzw. CDC) und IT (-Security) zu tun? Nur noch ein kleines bisschen Geduld. Ich kann Sie jedoch beruhigen, wir werden hier sicher NICHT jeden einzelnen Title mit Inhalt durchgehen. Sonst liest hier niemand mehr weiter sondern wird sich auf die vielen Ablenkungsmöglichkeiten im Web verleiten lassen. Die für uns relevanten Abschnitte sind die Sections 302 und 404. In Sections 302 verpflichten sich CEO und CFO zu bestätigen, dass die Finanzdaten fehlerfrei und vollständig sind. Sie versichern ebenfalls, dass die internen Kontrollen in Bezug auf das Financial Reporting effektiv umgesetzt wurden und reported werden. Jedoch wird nicht genannt, welche internen Kontrollen umgesetzt werden müssen. In Section 404 bestätigt das Unternehmen, dass die Effektivität der internen Kontrollmechanismen („Safeguards“) jährlich dem SEC (Securities and Exchange Commission) berichtet werden sowie ein externes Audit durchgeführt wird. Hier wird ebenfalls keine Empfehlung für Kontrollmechanismen angegeben.

Die Durchführung der erforderlichen Schritte zur Compliance erfordert einen hohen Aufwand und löst eine große Unsicherheit aus. Durch die bereits erwähnten allgemein gehaltenen Formulierungen werden vom Gesetzestext keine Hilfsmittel an die Hand gegeben, wie diese am besten zu implementieren ist. Auch nicht für den Bereich IT-Security. Daher wurden verschiedene Vorgehensweisen wie z.B. das COBIT (Control Objectives for Information and Related Technology), das COSO (Committee of Sponsoring Organizations) oder das ITGI (Information Technology Governance Institute) Framework entwickelt. ITGI hat die beiden anderen Frameworks speziell auf IT-Regulations für SOX abgewandelt und zugeschnitten.

Hier wiederum fokussieren wir uns auf die IT-Security relevanten Themen, beispielsweise (ohne Anspruch auf Vollständigkeit!):

  • Security Policy + Security Standards

Das Implementieren von entsprechenden Security Policies und entsprechenden Security Standards kann vom Cyber Defense Center (CDC) innerhalb des Unternehmens vorangetrieben und deren Einhaltung überprüft werden.

  • Access und Authentication

Ebenfalls muss bei den Financial Reporting Systems sichergestellt werden, dass nur autorisierte Personen Zugriff auf dieses System haben und die Zugriffe auditiert werden (Wer? Wann? Von Wo?). Dies setzt natürlich voraus, dass Account Sharing durch eine Policy untersagt ist und die IPs eindeutig einem Hostnamen zugeordnet werden können. Insbesondere sollten Aktivitäten von Super Usern auditiert und überwacht werden. Das Access und Authentication Monitoring kann über eine SIEM/Logmanagement Lösung im CDC und den entsprechenden Use Cases umgesetzt werden. Zusätzlich sollten die Passwörter einer entsprechenden Richtlinie bezüglich Länge und Komplexität unterworfen sein.

  • Account Management

Die Prozesse für die Erstellung, die Anpassung und das Löschen von User Accounts sollten klar dokumentiert sein. Die Privilegien werden nach dem ‘Principle of Least Privilege‘ an die User verteilt, um Manipulationen an Finanzdaten vorzubeugen. Versuche, unbefugt Rechte auszuweiten können effektiv vom CDC überwacht werden.

  • Network Security

Dieser Bereich beinhaltet die typischen Anforderungen an Network Security wie Perimeter Security durch Firewalls, Network Monitoring durch IDS/IPS sowie generelle Netzwerksegmentierung. ZU empfehlen ist, dass eine Trennung des Finanzsystemnetzwerkes mit dem restlichen Intranet durch eine Firewall vorhanden ist. Die Datenübertragung erfolgt verschlüsselt.

  • Endpoint Protection

Ebenfalls ist es ratsam, die Finanzdaten-Server sowie die Systeme der sich verbindenden User mit einer Next Generation Endpoint Detection and Response  (NGEDR) Lösung auszustatten. Dies erschwert den Datenabfluss/die Datenmanipulation durch schadhafte Dateien oder Angreifern.

  • Monitoring

Die Auswertung der Log-Dateien der betroffenen Systeme sowie die darin enthaltenden Security Events und das Entwickeln von Use Cases zur Alarmierung sind ein unumgänglicher Vorgang, um eine entsprechende Transparenz zu potentiellen Sicherheitsvorfällen zu erhalten. Zusätzlich müssen entsprechende Workflows/Prozesse definiert werden, um eine standardisierte, wiederholbare Handlungsanweisung mit immer derselben Qualität gewährleisten zu können. Das Security Event/Incident Handling kann durch State of the Art-Technologien wie eine Security Orchestration and Automation (SOAR)-Plattform unterstützt werden. Eine der Herausforderung bei der Bearbeitung eines erzeugten Alarms ist die Einordnung ob ein False Positive/True Positive vorliegt. Das CDC-Team besitze normalerweise kein dediziertes Wissen über die Finanzdaten sowie deren Systeme und wer dazu berechtigt ist, welche Aktionen auszuführen. Somit fehlen Informationen zur Klassifizierung des Events. Daher stellen sich die Fragen:

  1. Können dieselben Alarme und Prozesse verwendet werden wie bei denselben Alarmen, die nicht zur SOX Compliance betroffen sind? Beispielsweise können Alarme, welche ein SOX System betreffen höher priorisiert oder mit einer höheren Kritikalität eingestuft werden. Ebenfalls ist ein deutlich höherer Dokumentationsaufwand notwendig.
  2. Wer bearbeitet diese Alarme?
  3. Falls die Bearbeitung durch das CDC Team erfolgen soll – woher können die benötigten Informationen gewonnen werden und wer sind die Ansprechpartner für auftretende Rückfragen?
  4. Wie sehen die internen Service Level Agreements aus (CDC, Informationsanfragen bei Ansprechpartner, etc.?)
  • Segregation of Duties

Dies umfasst die Aufteilung von Rechten, Privilegien und die damit verbundenen Tasks zwischen verschiedenen Personen, Institutionen, etc. Beispielsweise werden bei der Implementierung von Service Usern deren Privilegien auf unterschiedlichste Aufgaben zugeschnitten. Ein Service User ist z.B. berechtigt, User anzulegen und zu löschen, der andere wiederum weißt den Benutzern die entsprechenden Berechtigungsgruppen zu. Somit wird verhindert, mit nur einem dieser Accounts unberechtigten Zugriff erlangen zu können.

  • Physical Security

Physikalischer Zugriff zu den Servern/Systemen, auf denen diese Finanzdaten abgelegt sind, muss reguliert und überwacht werden.

  • Dokumentation, Dokumentation sowie…ach ja: Dokumentation!

Durch die regelmäßigen Audits sind definitiv hohe Anforderungen an die Dokumentation bezüglich Detaillierungsgrad und Qualität gesetzt. Wie sehen die implementierten Sicherheitsmaßnahmen und Kontrollmechanismen aus? Wie werden die Finanzdatenbanken und Finanzapplikationen geschützt? Welche Prozesse stecken dahinter? Wie ist die Incident Response organisiert und strukturiert? Dieser Punkt umfasst jedoch nicht nur die bereits genannten Bereiche in der IT Security sondern geht weit darüber hinaus, beispielsweise: Auf welchen Systemen werden Finanzdaten gespeichert oder treten mit diesen während ablaufenden Prozessen in Kontakt? Wie viele und welche Mitarbeiter haben Zugriff darauf? Wie werden die Transaktionen innerhalb der Finanzapplikation durchgeführt? Eine ausführliche Dokumentation ist ein gutes Mittel um die geforderte Transparenz im Audit sicherzustellen.

 

Fazit: Alle vorherig genannten Punkte können in einem CDC gebündelt werden und einen wertvollen Beitrag als Kontrollmechanismus zur Einhaltung der SOX-Anforderungen leisten.

Excessive Ressourcenbindung und Audit-Anforderungen

Wie man deutlich erkennen kann, müssen verschiedenste Themengebiete abgearbeitet werden, um die Anforderungen des SOX Acts zu erfüllen. Dabei werden etliche Ressourcen gebunden, die vielleicht am Ende an anderen Stellen zur direkten Wertschöpfung fehlen könnten. Eine intensive Zusammenarbeit zwischen verschiedensten Abteilungen ist dabei erforderlich. Nicht nur währen der Umsetzungen der Anforderungen, sondern zusätzlich während den jährlichen Audits müssen diese Ressourcen reserviert werden. Die Auditoren benötigen während des Audits Zugriff zu den Safeguards (Section 404.A.1.1). Dabei ist darauf zu achten, dass entsprechende Rollen und Privilegien gegeben werden. Der Auditor benötigt  Zugriff zu allen wichtigen Informationen, ohne jedoch aktiv Änderungen daran vornehmen zu können. Ebenfalls müssen alle Security Incidents und weitere Vorfälle (z.B: Ausfälle bei den internen Kontrollmechanismen) an die Auditoren weitergegeben werden (404.A.2 sowie 404.B). Fakt ist, dass eventuelle Mängel die durch die regelmäßigen Audits aufgedeckt werden, so schnell wie möglich behoben werden müssen, um keine Sanktionen fürchten zu müssen. Daher meine Empfehlung:

Falls Sie im Privatleben jedoch ein einfaches Audit einer Konformität durchführen wollen um sich auf SOX schon einmal einzustimmen – Nehmen Sie das nächste Mal doch einfach zum Lieblingsitaliener ein Maßband mit!

 


Links/Quellen:

https://www.blackstratus.com/sox-compliance-requirements/

SANS Institute – An Overview of Sarbanes-Oxley for the Information Security Professional

http://www.sarbanes-oxley-101.com/sarbanes-oxley-checklist.htm

Schreibe einen Kommentar

Wir nehmen Datenschutz ernst! Deshalb informieren wir Sie, was mit Ihren Daten geschieht:

  • Daten aus Formularen und Webseiten-Tracking können von uns zur Analyse gespeichert werden
  • Die Daten können zur Optimierung der Webseite ausgewertet werden. Das ermöglicht es uns, besser zu verstehen, wo das Interesse unserer Besucher liegt. Wir benutzen primär Hubspot für dieses Tracking (mehr dazu finden Sie in der Erklärung auf unserer Datenschutzseite, siehe unten)
  • Wir geben Ihre Daten nicht an Dritte weiter. Im Rahmen von Veranstaltungen, an denen Sie teilnehmen möchten, kann es nötig sein, dass Ihre Daten an Vertragspartner übermittelt werden.
  • Sie haben jederzeit ein Recht auf die Herausgabe, Berichtigung oder Löschung persönlicher Daten.
  • Sie können Ihre Einwilligung, mit uns in Kontakt zu treten, jederzeit mit sofortiger Wirkung widerrufen.

Weitere Details dazu, was wir mit den Daten tun und nicht tun finden Sie auf unserer Datenschutzseite, oder schreiben Sie mich bei Fragen direkt an!

Felix Möckel
Data Protection Officer