IT-Archivierung: Mission erfüllt?

Quelle: Wikipedia

In diesem Blog-Beitrag verwende ich absichtlich den Begriff IT-Archivierung und nicht etwa elektronische Archivierung. Es geht mir nämlich um sämtliche Aspekte der Archivierung was die IT betrifft – und da geht es auch um physische Archivierung. Deshalb gefällt mir persönlich der Begriff elektronische Archivierung nicht besonders gut. Als erstes möchte ich kurz eine Übersicht geben, welche Objekte potentiell archiviert werden müssen. Dabei habe ich keinen Anspruch auf Vollständigkeit der Liste:

Entstehung in der IT ...
Anwendungsdaten (aus funktionalen Anforderungen)
System-/technische Daten (aus nicht funktionalen Anforderungen)
Software (ausführbarer Code inkl. benötigte Ressourcen)

Entstehung ausserhalb der IT, Archivierung mittels IT ...
Geschäftskorrespondenz
Geschäftsabschlüsse
Verträge

Hardware zum späteren Anzeigen ...
Rechner (Server/PC)
Anzeige- und Bedienperipherie (Tastatur, Maus, Bildschirm u.a.)
Laufwerke (CD-ROM, Festplatten etc.)


Herausforderungen im Detail

Anwendungsdaten
Anwendungsdaten können sehr vielseitig sein. Typische (Schul-) Beispiele sind etwa Kunde (Name, Vorname, Geburtsdatum etc.), Kundenadressen, Bestellungen, Rechnungen und Artikel etc. Oftmals werden solche Daten in Datenbanken gespeichert und die optimale Archivierung von Daten in Datenbanken ist alles andere als einfach. Welche Daten müssen per wann archiviert werden? Und vor allem, wie kann man diese später wieder in einem sinnvollen Kontext anzeigen? Projekte zur gesetzes konfromen Archivierung von Anwendungsdaten (insbesondere in Datenbanken) sind aufwändig in der Planung und sollten nicht unterschätzt werden. Vor allem Aspekte wie das Suchen und Wiederfinden sowie anzeigen von solchen Daten sind anspruchsvoll in der Umsetzung. Vor allem dann, wenn man aus Gründen des Datenvolumens nicht immer die ganze Datenbank archivieren kann oder auch wichtig aus Sicht Compliance, nicht die ganze Datenbanken archivieren darf.

System-/technische Daten
Zu diesen Daten zählen Informationen aus Log-Einträgen, Informationen zur Verfügbarkeit, Informationen zu Verbindungen (Protokolle etc.) sowie zur Security (Benutzeranmeldungen, Benutzen von Objekten etc.). Für diese Kategorie gibt es zwei Herausforderungen: 1) Identifikation der Daten, welche eine Software (ein Software-System) überhaupt speichert und 2) Automatische Erschliessung von allen relevanten Daten. Aber auch hier ist der Aspekt der späteren Lesbarkeit in sinnvollem Kontext nicht selten eine Herausforderung.

Software
Zu dieser Kategorie von Informationen die potenziell archiviert werden müssen, zählen zum einen die Software, welche Daten erstellt, erstellt hat und zum anderen Software, mit welche die archivierte Software wieder in sinnvollem Kontext angezeigt werden kann. Das kann dieselbe sein wie die Daten erstellende, es kann aber auch eine Software eigens für diesen Zweck sein. Die Herausforderung besteht darin, dass man eine Lauffähige Umgebung mit allen Ressourcen archiviert. Nur einfach die Installations-CD in ein Archivregal stellen reicht nicht. Zum einen hat man die Software nach der Installation parametrisiert und zum anderen braucht man auch ein Betriebssystem, um diese laufen zu lassen. Auch dieses muss archiviert sein, damit die Software Jahre später auch noch ausgeführt werden kann.

Entstehung ausserhalb der IT
Hier sind es vorwiegend digitalisierte Informationen (bspw. mittels Scanner) wie Briefe, Rechnungen, Unterzeichnete Geschäftsabschlüsse, Unterzeichnete Berichte und Meldungen etc. Die Herausforderung sind hier aus meiner Erfahrung am kleinsten und es gibt am meisten Standardlösungen für solche Aufgaben. Es werden einzelne Objekte (meist Dateien) mit ID in einem Format wie PDF/A oder Tiff erstellt. Diese werden zusammen mit einem Index mit Metadaten in einer Archvierungslösung archiviert.

Hardware
Hier geht es darum, dass jene Hardware archiviert wird, welche zum späteren Anzeigen von archivierten Daten gebraucht wird. Die Herausforderungen besteht hier vor allem im Konzept, wann welche Hardware separat funktionsfähig beiseite gestellt (archiviert) werden muss. Es braucht natürlich nicht für jede Anwendung einen eigenen Server im Archiv. Sobald es aber einen Medienbruch gibt,oder andere Einflussfaktoren ändern, muss für die Legacy-Archive entsprechend Hardware „archiviert „ werden, damit die Daten eben auch Jahre später noch gelesen werden können.


Qualitätskontrollen / Lesetests
 
Es ist unerlässlich, dass in bestimmten zeitlichen Abständen getestet wird, ob definierte archivierte Objekte mit den archivierten Ressourcen noch gelesen werden können.


Geeignete Medien / Infrastruktur
 
Es sind längst nicht alle Speichermedien geeignet oder zulässig zum Archivieren von elektronischen Daten. Billige CD-R beispielsweise sind mit weniger als 10 Jahren nicht mehr (zuverlässig) lesbar. Nebst einmal beschreibbaren optischen Datenträgern (zum Beispiel CD-R) kommen zur konformen Archivierung vor allem WORM (True-/Soft- und Hardware WORM) zum Einsatz. Diese sind jedoch relativ kostspielig und ein gutes Archivierungskonzept zur Reduktion der Datenmenge lohnt sich nach wie vor (auch aus anderen Gründen als den Speicherkosten).


Erfahrungen und Konklusion
 
Meine Erfahrung aus verschiedenen Projekten zeigt, dass die Mission IT-Archivierung alles andere als erfüllt ist. Am besten umgesetzt sind elektronische Archivsysteme, welche meist externe Dokumente als zuweisbare Objekte archivieren. Grosse Lücken gibt es hingegen, bei den meisten anderen Arten von Informationen. Beispielsweise alte Adressen. Häufig sind diese noch im produktiven System, aber eben nicht korrekt archiviert. Noch grösser ist meines Erachtens die Lücke beim Archivieren von verwendeter Software, respektive Software, mit welcher Archivierte Informationen angezeigt werden kann. Ebenfalls dazu gehört die ganze Hardware, damit die Software und somit die Daten später verwendet werden können. Die ganze Datenaufbewahrung, zu welcher auch die Datenarchivierung gehört, ist organisatorisch ein Problem, welches in vielen Unternehmungen noch nicht genügend gelöst worden ist. Es versteht sich von selbst, dass ich hier kein Menetekel an die Wand schreiben will. Dennoch darf das Risiko nicht unterschätzt werden. Ich empfehle auf jeden Fall, diese Risikokategorie im Rahmen von ORM auf dem Radar zu behalten und allenfalls geeignete Massnahmen einzuleiten. Sonst läuft man Gefahr, dass Unternehmensdaten  verloren gehen.

Wie sieht das Archivierungskonzept für Anwendungsdaten und Software bei Ihnen aus? Wann führen Sie Lesetests aus? Dies sind Fragen, welche auch Compliance interessieren müssen.

Im Code liegt Wahrheit: Software(test)-Anforderungen & Testmöglichkeiten

Was ist ein Software-Test?
Es gibt verschiedene Definitionen davon, was ein Softwaretest ist. Ich persönlich finde jene von Denert gut, bei der ein Test der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen ist. Insbesondere der letzte Teil „[...] zu vorher festgelegten Anforderungen“ ist aus meiner Sicht existenziell wichtig und entscheidend. Ein Softwaretest ohne genaue Softwarespezifikation ist demnach nicht möglich.

Anforderungen von verschiedenen Anforderungsgruppen

Es gibt ganz verschiedene Anforderungen von unterschiedlichen Anforderungsgruppen. Ich unterteile die Anforderungsgruppen in vier Hauptgruppen: Business, Technik, IT-Compliance und Fach-Compliance. Klar, jemand der nicht in Compliance-Abteilungen arbeitet oder gearbeitet hat, würde wahrscheinlich IT-Compliance und Fach-Compliance einfach unter dem Begriff „Compliance“ führen. Ich erlaube mir aber, diese zu trennen.

Business
Hier geht es um die spezifischen Anforderungen des Fachbereichs. Die meisten können mit der Frage, welche Funktionen eine Software haben muss, gruppiert werden.

Technik
Wie der Begriff sagt, geht es hier um technische Anforderungen. Beispiele sind: Plattformen, Protokolle, technische Standards, Deployment, Wartbarkeit etc.

IT-Compliance
Hier stehen häufig die gleichen Standardanforderungen im Raum: Sicherstellung von Vertraulichkeit, Verfügbarkeit, Integrität, Datenaufbewahrung und Datenschutz.

Fach-Compliance
Hier geht es um Compliance-Anforderungen, welche das spezifische Business betreffen. Wird beispielsweise eine Software für den Börsenhandel entwickelt, sind es spezifische regulatorische Anforderungen aus dem Börsenrecht (u.a.).

Testarten und -möglichkeiten

Für möglichst alle Anforderungen sollten spezielle Tests durchgeführt werden. Dazu gibt es unterschiedliche Ansätze und Methoden. Diese kann man je nach Gesichtspunkt in verschiedene Gruppen einteilen:

Nach Testkriterium: Funktionale Tests, Stresstests, Lasttest, Schnittstellentests, Sicherheitstests, GUI-Tests etc.

Nach Informationsstand: Blackbox-Tests, White-Box-Tests (auch Code-Reviews genannt)

Nach Test-Technik: Statische und dynamische Tests.

Sobald eine Software durch einen Kunden oder gar Dritten getestet und abgenommen wird, werden in der Regel Blackbox-Tests gemacht. Das heisst, dass die Tests damit gemacht werden, dass die Software gebraucht wird. Entweder fährt das Auto, oder es fährt nicht. Weshalb es genau fährt, bleibt dem Tester vorenthalten.

Wer muss Software testen? Welche Software muss man testen?
Diese Frage ist so allgemein nicht zu beantworten. Sicher gilt für Finanzintermediäre, dass sie jene Software testen müssen, welche sie für das Kerngeschäft einsetzen. Irgend eine Software für Marketingkampagnen muss nicht, oder nicht im gleichen Umfang wie beispielsweise eine E-Banking-Software, getestet werden. Eine Firma muss im IT-Reglement oder der IT-Weisung definieren, welche Software getestet werden muss und wie. Wer in einer Firma Softwaretests definiert und durchführt, hängt von der Software und den durchzuführenden Tests ab. Meist braucht es dazu Mitarbeiter aus mehreren Abteilungen (Fachbereich, Compliance und IT).

Erfahrungen und Konklusion
Nach meinen Erfahrungen ist es sehr schwierig, gute Softwaretests zu beschreiben, welche tatsächlich dafür nützlich sind, die Umsetzung der gemachten oder geforderten Anforderungen zu prüfen. Meist werden zudem nur Anforderungen aus dem Bereich Business geprüft. Es liegt aber nicht nur an den Test-Verantwortlichen, dass Software häufig nicht ausreichend und nicht effizient geprüft wird. Es liegt auch daran, dass mit Blackbox-Tests allein einfach zu wenig gut geprüft werden kann: Im Code liegt Wahrheit. Hat eine Software beispielsweise interne Limiten (die von verwendeten Datenstrukturen herrühren) ab einem bestimmten Datenvolumen, so bräuchte es schon ein Lasttest, um dies zu merken. Oder ein bestimmter Datenwert führt zu einem Fehler. Ist es da nicht Zufall, wenn Sie Tests haben, welche diese Datenwerte brauchen? Oder die Software macht Fehler, wenn parallel mehrere Benutzer gleichzeitig auf ein Objekt zugreifen wollen? Führen Sie die Tests wirklich so durch, dass Sie dies merken würden? Oder die Software führt gewisse Log-Aufträge nicht aus, wenn man sich mit einem bestimmten Benutzer anmeldet? Prüfen Sie wirklich mit allen möglichen  Benutzern alle Testfälle? Die Liste könnte beliebig erweitert werden. Es gibt so viele mögliche Fehler, die mit Blackbox-Tests in der Praxis fast nicht zu erkennen sind und schon gar nicht mit wirtschaftlich vernünftigem Aufwand. Meine Meinung ist deshalb klar: Bei Geschäftskritischer Software braucht es vermehrt Code-Reviews. Der Source-Code wird angeschaut und geprüft. Diese Code-Reviews ersetzen dabei auf keinen Fall die üblichen Anwendungstests, welche in Form von Blackbox-Tests durchgeführt werden, sondern ergänzen diese. Denn auch der Aufwand von Code-Reviews darf nicht unterschätzt werden – solche Reviews müssen von Personen mit entsprechenden Know-how gemacht werden, was mit entsprechenden Kosten verbunden ist.

Sicherlich ist diese Forderung für die meisten Softwarefirmen nicht opportun. Denn niemand, der Software unter einer proprietären Lizenz verkauft, will seinen Software-Code, oder Teile davon, zwecks Review einem Kunden offen legen. Aber genau das wäre aus meiner Sicht ein wirkungsvolles Mittel, um die Softwarequalität zu erhöhen. Dabei soll Softwarequalität an dieser Stelle vor allem als konnotierter Begriff im Anforderungskontext verstanden werden.

Aber nicht nur die Softwarehersteller sind gefordert. Auch die Kunden und insbesondere die Compliance Officer sind hier gefordert. Und zwar gleich doppelt:

1. Müssen sie sich aktiv in den Prozess der Softwarespezifikation einbringen. Denn wie Eingangs geschrieben, braucht es für einen Softwaretest eine Anforderung und diese muss gestellt werden.
2. Die Compliance Officer müssen aktiv dafür sorgen, dass ihre gestellten Anforderungen mit einem geeigneten Testverfahren auch geprüft werden.

Für einige Leser mag mein Wunsch zum Schluss vielleicht schon fast wie ein Mantra klingen. Aber Mantras haben bekanntlich eine positive Wirkung auf den Geist. Hier ist er: Es wäre wünschenswert, wenn Compliance vermehrt am gesamten Entwicklungsprozess von Software beteiligt wäre – denn nur so kann sichergestellt werden, dass neue Software Compliance konform umgesetzt wird.

Das Compliance-IT-Synergien-Paradoxon

Ich bin mir bewusst, dass dieser Beitrag in gewissem Masse als Widerspruch zu meinem ersten Beitrag empfunden werden kann. Aber es ist so, dass der erste Beitrag die Theorie, so wie es sein sollte, wiedergibt. Und in diesem vorliegenden Text widme ich mich Erfahrungen aus der Praxis.

Feststellung
Wo es theoretisch zwischen Compliance und der IT starke Synergien gibt, stellen sich diese in der Praxis doch nicht selten als Paradoxa heraus. Irgendwie wird da bei Projekten nicht immer alles so ganzheitlich und adäquat betrachtet. Doch alles der Reihe nach.

Von IT-Security zu IT-Compliance
Der Begriff IT-Compliance ist ein eher jüngerer Begriff und so scheint mir, im Deutschsprachigen Raum mehr vertreten zu sein als im Englischen. So gibt auf Deutsch mehr Treffer bei Google und bei Wikipedia gibt es im Englischen dafür (noch) keine eigene Seite. Auf der Deutschsprachigen schon. IT-Security ist hingegen ein „gestandener“ Begriff und umfasst im Wesentlichen die Attribute: Sicherstellung von Vertraulichkeit, Verfügbarkeit und Integrität. IT-Security war für die IT schon immer ein zentrales Element. Und aus dieser IT-Security wuchs auch mein Verdacht, dass es da Synergien zur rein fachlichen Compliance gibt. IT-Security ist eine Untermenge von IT-Compliance. Vereinfacht gesagt ist IT-Compliance IT-Security, erweitert um die Aspekte:  Datenaufbewahrungsrichtlinien und Datenschutz, gemeint nach Datenschutzgesetz DSG. Während in der IT-Security der Administrator noch weitgehend alles machen kann, geht dies bei IT-Compliance nicht mehr, da es Datenschutzgesetze gibt, die auch für den Administrator ihre Gültigkeit haben. Soweit zu den Begriffen.

Fach- oder Business-Compliance versus IT-Compliance?
Als Fach- oder Business-Compliance verstehe ich die klassische Compliance, wo es um die Regulatorien geht, welche das Business selber betreffen. Bei Banken sind dies Themen wie Geldwäscherei und Sorgfaltspflicht, Börsenrecht (Meldepflichten, Insiderhandel, Marktmanipulation u.a.), Vertragsrecht, Risikokontrolle etc. etc.

Meine These, dass die Synergie zwischen Fach- und IT-Compliance in der Praxis ein Paradoxon ist, kommt von der Feststellung, dass gerade auch bei der technischen Umsetzung von Anforderungen aus der Fach-Compliance, Grundsätze und Regeln der IT-Compliance, genauer der IT-Security, übersehen, ignoriert oder missachtet werden.

Lieber eine einfache Reportingschnittstelle für ein Management-Reproting-Tool, ohne Authentifizierung und Autorisierung, als eine optimale Datensicherheit und Gewährleistung der Integrität.

Fallbeispiel 1: Verbesserte Risikoaufklärung zu Lasten der Datensicherheit
Die Risikoaufklärung der Kunden soll im Zuge der negativen Erfahrungen aus der jüngsten Finanzkrise verbessert werden. Insbesondere bei der Beratung ausserhalb der Bank, soll diese verbessert werden. Dazu werden die betroffenen  Kundenberater mit neuen mobilen Geräten mit grossem Display ausgestattet. Über diese (unsicheren) Geräte haben diese Mitarbeiter nun die Möglichkeit, interne Dokumente und Informationen über Finanzprodukte zu beziehen und dem Kunden zu präsentieren. Dieser kann auch gleich sein Einverständnis „schriftlich“ über diese mobilen Geräte geben. Aus Sicht Fach-Compliance ist diese Umsetzung zu begrüssen, wird der Kunde doch besser und vor allem aktueller über Risiken informiert und gibt auch gleich schriftlich zu Protokoll, dass er darüber aufgeklärt worden ist. Leider aber sind gerade solche mobile Geräte alles andere als sicher. Sowohl für den Kunden wie auch für die Bank treten durch diese Umsetzung neue operationelle Risiken (ORM) auf. Kein IT-Security-Officer würde wohl sein Wort geben, dass diese Lösung als sicher und ohne Risiken einzustufen ist.

Fallbeispiel 2: Verbesserte Datenqualität zu Lasten der Datenintegrität
Ein neuer Fach-Compliance-Prozess soll die Datenqualität von Kundeneingaben erhöhen. Adressänderungen und Versandinstruktionen, welche über das E-Banking vom Kunden erfasst werden, sollen nicht mehr mit einem STP-Prozess (Straight Through Processing) direkt ins System übernommen werden, sondern vorerst von einem Mitarbeiter geprüft und allenfalls korrigiert werden. Dieser Schritt kann richtig implementiert durchaus sinnvoll sein. Wird die Eingabe des  Kunden als solche aber nicht unverändert ins System übernommen und die Änderung eines Mitarbeiters als Änderung eingetragen, so ist die Datenintegrität nicht mehr gewährleistet, wenn aus dem System der Eindruck entsteht, der Kunde habe die Adresse oder Versandinstruktionen so erfasst. Was nach einer Änderungen durch einen Mitarbeiter nicht mehr der Fall ist.

Lösungsansätze
Um diesem Paradoxon zu entgehen, braucht es auf verschiedenen Stufen Mitarbeiter die mitdenken und Compliance ganzheitlich betrachten. Eine ungenügende IT-Security schlägt früher oder später zurück. Fach-Compliance-Anforderungen müssen im Einklang mit IT-Compliance umgesetzt werden. Eine Bevorzugung von Fach-Compliance gegenüber IT-Compliance kann verheerend sein. Umgekehrt ist es natürlich auch an den IT-Verantwortlichen, nicht alle fachlichen Anforderungen unter dem Mantel von IT-Security zu blockieren. Nur mit gegenseitigem Respekt und Beachtung lassen sich die theoretischen Synergien erreichen.

In diesem Spannungsfeld kann ein weit- und umsichtiger Compliance Officer eine wichtige Rolle einnehmen und zu ganzheitlich korrekt umgesetzten Lösungen beitragen.

Erneuerungen

An dieser Stelle möchte ich mich für die zahlreichen Kenntnisnahmen und Rückmeldungen zu diesem Blog bedanken. Auf Grund von Anregungen gibt es bereits drei Verbesserungen:


1) Neu gibt es auf der rechten Seite eine Vorschau auf den nächsten Blog-Beitrag mit Titel und dem voraussichtlichen Publikationstermin.


2) Ebenfalls neu auf der rechten Seite gibt es eine einfache Möglichkeit, dem Blog zu folgen (Abonnieren von).


3) Ab sofort gibt es keine Werbung mehr zwischen den einzelnen Blog-Beiträgen.


Beste Grüsse,
Ronny Fuchs