Compliance für die IBM System i

Compliance mit weniger Ressourcen: Ein Framework für "IBM System i" - Implementierung von Third-Party-Tools, die Systeme um Compliance-Funktionalitäten ergänzen
Bis vor kurzem haben sich viele IBM System-i-Abteilungen nicht als Ziel von nennenswerten Compliance-Anforderungen gesehen: Das hat sich rasch geändert

Von Amit Ben-Zvi*

(14.08.07) - Ihr "IBM System i" ist die stabile und sichere Basis für Ihre unternehmenskritischen Aktivitäten. Hier liegen Dokumente und Reports, die Ihre Mitarbeiter für die Erledigung ihrer täglichen Aufgaben benötigen. Wenn Ihre System-i-Abteilung arbeitet wie die meisten anderen, dann ist Ihre Entwicklungs- und Wartungsmannschaft zwischen 25 (mindestens) und 100 Prozent der Arbeitszeit damit beschäftigt, die IT in Compliance, d. h. im Einklang mit den Gesetzen, Vorschriften und Regeln zu halten, die von außen an Ihr Unternehmen herangetragen werden. In den USA, aber auch in Deutschland, gehen die Compliance-Anforderungen von verschiedenen Institutionen und Quellen aus: Sarbanes Oxley (SOX), Landes- und Bundesregierung, Finanzbehörden, Bilanzierungsregeln, Industriestandards, wie sie die Healthcare-Branche (HIPAA), die Kreditkartenanbieter (PCI-Datenverschlüssellungsregeln) oder die Finanzwirtschaft (Gramm-Leach-Bliley) formulieren, Umweltgesetze, Vorschriften aus dem Verteidigungsministerium oder Kunden wie Wal-Mart, die eine RFID-Implementierung fordern. International gelten für alle Unternehmen ähnliche Archivierungsstandards und europäische Unternehmen laufen Gefahr, ebenso viele Ressourcen für die Herstellung von Compliance zu investieren wie ihre amerikanischen Counterparts. Sie müssen europäischen Vorschriften wie Basel II folgen. Die Capital Requirements Directive (CRD), die Basel II als EU-Recht formuliert, ist für alle Finanz- und Investmentfirmen in der EU verpflichtend. Eines der Ziele der CRD ist es, die nationalen Barrieren zwischen den EU-Staaten abzubauen, sodass die Unternehmen und Institutionen europaweit besser zusammenarbeiten können. CRD gehört zu den großen Herausforderungen für die kleineren Unternehmen der europäischen Finanzwirtschaft – und davon gibt es viele.

Ungeachtet, auf welcher Seite des Atlantiks Sie zu Hause sind, Compliance ist ein reales und präsentes Thema, das droht, signifikante Ressourcen Ihres Unternehmens zu fressen und Ihre Aufmerksamkeit von den Projekten abzulenken, die Ihnen Wettbewerbsvorteile verschaffen. Compliance droht, signifikante Ressourcen Ihres Unternehmens zu fressen und Ihre Aufmerksamkeit von den Projekten abzulenken, die Ihnen Wettbewerbsvorteile verschaffen.

Bis vor kurzem haben sich viele System-i-Abteilungen nicht als Ziel von nennenswerten Compliance-Anforderungen gesehen. Auch, weil sich kleinere und inhabergeführte Unternehmen nicht von der Flut neuer Gesetze und Vorschriften bedroht sehen. Aber die Zeiten, in den sich Unternehmen, egal welcher Größe und welcher Art, den Compliance-Forderungen entziehen konnten, sind vorüber. Die Kreditkartenindustrie macht dies offensichtlich: Wie Carol Woodbury, Gründerin und CEO von SkyViewPartners erläutert, überträgt sie die Verantwortung für die Transaktionssicherheit auf Banken und die Kreditkarten ausgebenden Institute. Diese Unternehmen wiederum reichen die Verantwortung weiter an die Händler, die Kreditkartenzahlungen akzeptieren. Wenn Sie Kreditkartentransaktionen akzeptieren und Kreditkartendaten speichern, sind Sie der nächste in der Verantwortungskette – ganz gleich, wie groß Ihr Unternehmen ist. "TJX", sagt Woodbury, "ist das Paradebeispiel für eine Sicherheitslücke. Das Unternehmen hat 2007 45 Millionen Kreditkartendaten nicht sauber verschlüsselt und abgespeichert und sie so öffentlich zugänglich gemacht."

Die Bank of America und andere multinationale Häuser können finanzielle Mammutschläge, die von solchen Fehlern ausgehen, aushalten und überleben – aber kann es auch Ihr Unternehmen? Compliance mit Standards und Regeln, die dauernd erweitert und geändert werden, herzustellen und beizubehalten, ist zu einem der größten Kostenfaktoren geworden. Unternehmen widmen den Großteil ihrer teuren IT-Mannschaft nicht mehr den Aktivitäten, die dem Unternehmen selbst einen Mehrwert bringen. Stattdessen geraten die IT-Abteilungen schon bei dem Versuch unter Wasser, die IT an die Forderungen anzupassen, die externe Stellen an sie richten.

Die meisten System-i-Abteilungen geraten schon bei dem Versuch unter Wasser, die IT an die Forderungen anzupassen, die externe Stellen an sie richten.

Wachsender Druck

Der Druck auf Unternehmen jeder Größe und Art wächst unaufhaltsam. Neue Bedrohungen und Gefahren erscheinen. Firmen sehen allerdings auch den Wert der Compliance-Methoden als "gute Geschäftspraktiken", deren Anwendung dem eigenen Unternehmen Vorteile und Wertzuwächse bringen. System-i-Abteilungen waren nicht besonders schnell darin, den Gesetzen, Vorschriften und Regelungen mehr Aufmerksamkeit zu schenken als für das Bestehen von Audits notwendig ist. Clay Ryder, Chef der Sageza Group, bemerkt: "Zurzeit sind die meisten System-i-Anwender auch nur Schaumschläger, um im Rennen zu bleiben. Sie haben nichts Neues eingebracht, um das Ruder zu übernehmen. Sie halten einfach ihren Kopf über Wasser und bewegen sich nicht vorwärts."

Woodbury stimmt zu. "Der Druck wachsender Regulierungen und Compliance-Anforderungen wird nicht so bald aufhören. Haben die Firmen erst einmal die Sicherheitsaspekte der Compliance im Griff, benötigen sie vermutlich weniger Ressourcen, um diesen Status aufrecht zu erhalten. Die großen Investments sind nur in der Anfangsphase notwendig. Aus Sicht der Kunden und Partner sieht es aber anders aus: Technologie ist ein sich bewegendes Ziel. Wal-Mart verlangt heute jenes und im nächsten Jahr etwas ganz anderes. Deshalb sind hier ständige Investitionen nötig. Im Bereich der Applikationsentwicklung ändert sich die Technologie ständig, sodass die Investments wahrscheinlich hoch bleiben"

Im Entwicklungsbereich wird sich die Technologie ständig ändern. Die Investments bleiben hier deshalb potenziell hoch – Carol Woodbury.

Ein Framework für System i zur Realisierung von Compliance mit weniger Ressourcen

Es gibt also einen zwingenden Bedarf für System-i-Abteilungen, ein Framework zu entwickeln, mit dem sie Compliance herstellen und aufrechterhalten können. Dabei sollten Best Practices und so wenig Ressourcen wie möglich eingesetzt werden. Es sollte im Kern aus einer Entwicklungsumgebung bestehen, die Flexibilität unterstützt und maximiert und gleichzeitig den Personalbedarf reduziert. Um zu verstehen, wie ein solches Framework realisiert werden kann, werfen wir einen Blick auf die drei grundlegenden Komponenten einer vollständigen Compliance-Strategie.

Diese drei Elemente muss sie umfassen, wenn sie dem Unternehmen ein Maximum an Wertschöpfung bringen soll:
1. Sicherung von Anwendungen und Daten,
2. Implementierung von Third-Party-Tools, die Systeme um Compliance-Funktionalitäten ergänzen, ohne dass dazu substanzielles Personal benötigt wird und
3. Implementierung eines Entwicklungs- und Wartungsansatzes, der die Vorteile einer Service orientierten Architektur (SOA) oder von plattformunabhängigem, wiederverwendbarem Code zur Umsetzung von Standardgeschäftsprozessen im gesamten Unternehmen nutzt – ohne dass diese Komponenten für jede Plattform, Datenbank und Anwendung einzeln gewartet werden müssen.

Sicherheit kommt zuerst — aber das ist noch nicht alles

Für einige Zeit haben große Teile der System-i-Welt die Begriffe "sicheres System" und Compliance synonym verwendet. Das Bestehen des Sicherheits-Audits stand an erster Stelle, wenn die Prüfer anrückten, um die IT-Prozesse unter die Lupe zu nehmen. Und es stimmt: Wenn Ihre Computer und Daten nicht sicher sind, nutzen alle weiteren Compliance-Maßnahmen nichts.

Die erste Komponente ist Sicherheit. Aber Sicherheit ist eine notwendige, keine hinreichende Bedingung für Compliance. Sicherheit ist nicht gleich Compliance. Sicherheit ist eine entscheidende und zwingende Komponente für Compliance. Aber Sicherheit ist nicht gleich Compliance. Unternehmen, die sich nur um sichere Systeme, Daten und Netzwerke kümmern, bestehen zwar Sicherheitsaudits, aber ihnen entgehen die zusätzlichen Vorteile und Best Practices, die eine ganzheitliche Sicherheitsinitiative bringt. Die neue Regelungslandschaft erhält endlich die Aufmerksamkeit der System-i-Abteilungen, die bis dato behauptet haben, dass sie keine externe Sicherheit benötigten, weil OS/400 das sicherste Betriebssystem überhaupt sei — was es auch tatsächlich ist. So kam der Hochverfügbarkeitsmarkt in Schwung – genauso wie der für Datensicherungs- und Datenrettungsdienstleistungen. Die Selbstgefälligkeit der System-i-Anwender wurde erschüttert, als einige Unternehmen aufwachten und sich bewusst wurden, dass sie noch nicht einmal die grundlegendsten Anforderungen erfüllten. Wie Woodbury bemerkt: "Es gab Zeiten, da hatten Unternehmen sogar Schwierigkeiten, einige der rudimentärsten Dinge, wie regelmäßiges Ändern von Passwörtern, durchzuführen. In vielen Fällen haben die Unternehmen einfach nicht realisiert, dass Sicherheit und Compliance ein Teil der Geschäftsprozesse sein müssen."

"Gerade weil System i in der Tat die am besten zu sichernde Plattform auf dem Markt ist", sagt Woodbury, "müssen die Funktionen, die das Betriebssystem für die Sicherheit bietet, korrekt implementiert werden, um eine Compliance-Auditierung zu bestehen. In vielen System-i-Abteilungen bedeuten ‘sicherbar’ und ‘sicher sein’ absolut nicht das Gleiche."

Hinzu kommt, dass das Sichern der "Kiste" weit davon entfernt ist, das Netzwerk sicher zu machen, in dem heute die meisten Server arbeiten. System i residiert nicht mehr auf einer Insel, mit dem bequemen Bewusstsein, dass der Server sicher ist: Externe und sogar interne Angriffe richten sich heutzutage als permanente Bedrohung gegen alle gängigen Anwendungen und Datenbanken.

Eile ist jetzt angesagt (oder sollte es sein), um System i, die Anwendungen und Daten wirklich sicher zu machen. Wegen des ständig wachsenden Drucks seitens der Kreditkartenindustrie steht die Datenverschlüsselung an erster Stelle auf der Sicherheitsagenda. Es gibt inzwischen viele Tools und Techniken, die Unternehmen helfen, die komplizierten Verschlüsselungsverfahren erfolgreich anzuwenden.

Lösungserweiterung mit Third-Party-Werkzeugen

Glücklicherweise bieten viele Hersteller Third-Party-Tools für Sicherheit und andere Compliance-Aspekte an. Diese sollten auf ihre Eignung für das Compliance-Tool-Portfolio eines Unternehmens geprüft werden.

Nach Arjon Cohen, Vizepräsident von Bsafe Information Systems, ist die Einführung der TCP/IP-Vernetzung für OS/400 einer der Gründe für den wachsenden Bedarf an solchen Tools. Viele der Geschäftsanwendungen, die auf System i laufen – Warenwirtschaftssysteme, Bank- und Finanzierungspakete – wurden entwickelt, bevor es TCP/IP gab. Während diese Pakete ihren Nutzern Datenzugriffe ursprünglich nur über Menüs erlaubten, kann man inzwischen mit PCs über das Netzwerk direkt auf die System-i-Datenbank zugreifen.

Dabei, erläutert Cohen, umgehen die Nutzer die Menüsicherheit des Pakets und hinterlassen wenige oder gar keine Auditspuren. Dies kann große Probleme für Unternehmen verursachen, die Compliance-Anforderungen umsetzen müssen. Basel II Abschnitt 819 z. B. verpflichtet Banken dazu, durchgreifende Maßnahmen zum Schutz von Eigentum und vertraulicher Informationen zu implementieren. Solche Anforderungen treiben Unternehmen dazu, Softwarepakete zur Sicherung von System i zu erwerben.

Neben den vielen Tools von Drittanbietern, die zur Realisierung von Compliance erhältlich sind, bieten viele ISVs im System-i-Markt eine Fülle weiterer Toolarten an. Sie helfen Unternehmen, Compliance herzustellen und zu halten sowie die notwendigen Compliance-Berichte zu generieren. Diese Werkzeuge decken alle wesentlichen Compliance-Aufgaben ab: z. B. Schwachstellenbeurteilung, interne Audits, Nutzerführungsaudits, Dokumentenarchivierung, Berichtswesen, Schulung und mehr. Es ist in der Tat schwierig, ein System-i-ISV zu finden, der nicht in irgendeiner Weise behauptet, das Erfüllen von Compliance-Auflagen zu erleichtern. Dies macht es zwar schwierig, das richtige Werkzeug zu finden, es ist aber ermutigend zu wissen, dass sich so viele System-i-ISVs den Compliance- Anforderungen widmen. Dies ist weiterer Grund, an System i festzuhalten und die Investition in den Server und seine Applikationen zu schützen.

Die zweite Komponente sind Third-Party-Tools. Sie adressieren viele der herausfordernden Compliance-Aufgaben, inclusive Schwachstellenbeurteilung, interne Audits, Nutzerführungsaudits, Dokumentenarchivierung, Berichtswesen, Schulung und mehr.

Die meisten der Third-Party-Tools sind einen Blick wert, besonders wenn sie der Umsetzung spezifischer Branchenstandards dienen. Und Endnutzer sind gut beraten, ihre Sicherheitslösungen mit einem für ihre Situation und ihre Umgebung angemessenen Toolportfolio zu erweitern. Schließlich werden diese Tools von ISVs getestet und gewartet, zu deren Kernkompetenzen es gehört, ihre Ressourcen in die Entwicklung solcher Werkzeuge zu stecken. Ressourcen, die Sie sich sparen und in ihr Kerngeschäft einfließen lassen können. Die Investitionen in diese Tools sind nützlich. Sie sollten (nach der Sicherheit) die zweite Säule Ihrer Compliance-Lösung sein.

Die steigende Bedeutung der Entwicklungsumgebung
Alle, die sich in irgendeiner Weise mit Compliance befassen, haben schnell gelernt, dass die erste Herausforderung darin besteht, zu verstehen, womit denn das Unternehmen in Compliance sein sollte. Das ist durchaus nicht trivial. Fachexperten aus den verschiedenen Branchen und Bereichen (Steuer, SOX, Basel II etc.) sind oft die besten Ansprechpartner, die bei dieser Aufgabe helfen können.

Die zweite große Hürde ist es, zu erkennen, welche Applikationen und Prozesse von den Compliance-Anforderungen betroffen sind. Es ist klar, dass ein Geschäftsprozess wie "kalkuliere die Verkehrssteuer” hunderte von Malen in hunderten Applikationen wiederholt wird. Unabhängig von der initialen Implementierung kann der Aufwand, diese Funktion ständig an neue Steuerregeln und Gesetze anzupassen, atemberaubend sein. Schaut man sich diese Herausforderungen an, werden die Vorteile und die Notwendigkeit einer plattform- und datenbankneutralen, Service-orientierten Plattform klar. Die Einführung eines solchen Systems, mit dem Geschäftsprozesse in ihre Bestandteile – in Services – unterteilt werden können, um sie plattformunabhängig extern und intern wiederzuverwenden, löst dieses Problem.

Mit einem Metadaten-gesteuerten, Regel-basierten Entwicklungsframework können viele Services, die von Compliance-Anforderungen betroffen sind, einmal programmiert und in all den Applikationen implementiert werden, die den jeweiligen Service benötigen; ganz unabhängig davon, auf welcher Plattform oder unter welchem Betriebssystem die Anwendung läuft. Eine Komponente zu entwickeln und sie dann mehrere Male zu implementieren, spart natürlich enorme Ressourcen. Das Verfahren zäumt Compliance eher von einem an den Unternehmensprozessen orientierten Standpunkt auf. Prozesse statt einzelne Applikationen werden "in Compliance gehalten" und überall dort verwendet, wo Compliance eine Rolle spielt.

Komponenten und Geschäftsaktivitäten zu definieren, die logisch miteinander verknüpft sind, macht Herstellung und Erhaltung von Compliance wesentlich einfacher als die Implementierung des gleichen Prozesses in vielen verschiedenen, isolierten Applikationen. Darüber hinaus können neue, Technologie getriebene Compliance-Anforderungen, etwa RFID, in kürzerer Zeit umgesetzt werden. Die Applikationen lassen sich zumindest teilweise aus existierenden und bewährten Komponenten zusammenbauen. So nutzen Unternehmen die bereits getätigten Investitionen und verkürzen dramatisch die Produktionszeit für die Applikationen.

Die dritte Komponente ist die Entwicklungsumgebung. Mit einem Metadatengesteuerten, Regel-basierten Entwicklungsframework können viele Services, die von Compliance-Anforderungen betroffen sind, einmal programmiert und in all den Applikationen implementiert werden, die den jeweiligen Service benötigen; ganz unabhängig davon, auf welcher Plattform oder unter welchem Betriebssystem die Anwendung läuft. Eine Komponente zu entwickeln und sie dann mehrere Male zu implementieren, spart enorme Ressourcen.

Compliance outsourcen

Eine plattformneutrale Entwicklungsumgebung erlaubt Unternehmen, von einem neuen Compliance-Trend zu profitieren: Dem Outsourcing bzw. der Nutzung von "Software-as-a-Service" für Compliance-Prozesse und -Reporting, wie es in vielen Branchen möglich ist.

Branchen wie Banken und Finanzen, Sicherheit, Gesundheit, Wirtschaftsprüfung, Pharma oder Logistik sind stark reguliert. Allein die Anpassung an die ständigen Regeländerungen kann potenziell sehr viele Ressourcen beanspruchen. Viele der betroffenen Services können heute deshalb von externen Quellen bezogen werden – und die Qualität und die Zahl dieser Services steigen täglich.

Die Transaction Audit Group (TAG), New York, bietet beispielsweise Reports und Analysen für die Finanzwirtschaft an. Sie managt den Datenverkehr mit den Börsen und wendet dabei sowohl die gesetzlichen als auch die internen Regeln ihrer Kunden für den Aktienhandel an. So ist sichergestellt, dass alle Transaktionen regelgerecht abgewickelt werden. Über die Transaktionen erstellt TAG Compliance-Reports, die Kunden dann der Börsenaufsichtsbehörde SEC als Compliance-Beleg vorlegen können.

Ähnliche Services entstehen zurzeit in vielen Branchen und für viele Anwendungen, etwa für gesetzlich vorgeschriebene Berichte von Personalabteilungen, Bilanzierung und Buchhaltung, externe und interne Berichte, das Management von Datenbanken oder das Angebot, externe Daten direkt in die Unternehmenssysteme einzuspielen.

Der Einsatz einer zentralen, neutralen Entwicklungs- und Betriebsplattform vereinfacht die Nutzung dieser Services erheblich. Jede Applikation ruft den gleichen Service in exakt der gleichen Weise auf. Der Service des Compliance-Anbieters muss nicht fest mit einer speziellen Datenbank verbunden oder in einer bestimmten Programmiersprache entwickelt sein.

Die Verfügbarkeit von Outsourcing-Angeboten oder Software-as-a-Serivce von Compliance-Prozessen und -Reports in vielen Branchen kann Unternehmen erhebliche Entwicklungs- und Wartungsarbeiten ersparen.

Schlussfolgerungen
Compliance ist eine gewaltige und potenziell komplexe Aufgabe, die heute Teil des Geschäfts ist. Wir kommen nicht darum herum. Und wir dürfen auch nicht passiv werden, wenn wir Sicherheitsfunktionen implementiert oder Audits bestanden haben. Die Probleme sind damit noch nicht gelöst. Die Sicherheitsfunktionen von System i erlauben eine nahtlose Integration, um Netzwerke zu sichern, Eindringlinge abzuwehren oder angemessene Verschlüsselungswerkzeuge auszuwählen.

Viele in der System-i-Community beginnen gerade ihre Strategie zu überdenken, um ihr Investment in System i unternehmensweit und über die Geschäftsprozesse hinweg zu nutzen. Die Zeit ist reif für diese zwei Themen: Die Identifizierung einer flexiblen und modernen Entwicklungsumgebung und die Herstellung von Compliance. Sie sollten zusammen betrachtet werden, um das Synergiepotenzial zwischen beiden Aufgaben zu ermitteln.

Wie können System-i-Abteilungen auf diese Herausforderungen reagieren? Clay Ryder von der Sageza Group prophezeit, dass der Weg zunächst ein wenig holprig werden wird. "Es gibt einige gute Gründe, warum System-i- Abteilungen sich ihre Entwicklungsumgebung genau daraufhin anschauen sollten, was sie im Compliance-Kontext leisten kann. Zunächst wird es Widerstand geben. Wenn System-i-Abteilungen weiterhin in ihrer Burg mit Graben drumherum arbeiten und an veralteten Architekturen festhalten, werden sie es schwer haben, von den Vorteilen von lose gekoppelten, dynamischen Umgebungen wie Service-orientierte Architekturen zu profitieren".

Die Vorteile, die eine Service-orientierte Architektur bietet – Wiederverwendbarkeit, Flexibilität, Produktivitätsgewinne – rechtfertigen ihren Einsatz im Compliance-Kontext. Die Entwicklung und das Management auf Geschäftsprozessebene, fernab von einzelnen Datenbanken, Betriebssystemen oder Hardwareplattformen, macht das dauernde Neupogrammieren von Prozessen für verschiedene Umgebungen überflüssig und spart enorm viel Geld und Zeit.

Das letztendliche Ziel ist ein sicheres System, das die Auditoren zufrieden stellt, das die besten Geschäftsmethoden zur Verfügung stellt und dabei so wenig Ressourcen benötigt wie möglich. Nur so können sich Ihre IT-Mitarbeiter auf die Aktivitäten konzentrieren, mit denen Sie Ihre Unternehmensziele erreichen. Wenn Sie 25, 50 oder gar 90 Prozent Ihrer Ressourcen, die heute mit Compliance-Angelegenheiten beschäftigt sind, von diesen Aufgaben befreien können, fließen die eingesparten Stunden direkt in Projekte, die Sie selbst bestimmen und ihr Unternehmen nach vorne bringen.
(Magic Software Enterprises: ra)

*Amit Ben-Zvi ist VP Corporate Marketing & Products bei Magic Software Enterprises.

Meldungen: Entscheidungshilfen