IT-Infrastrukturprojekte – Herausforderungen und Besonderheiten (Teil 2)

Für die Anwendungsentwicklung sind angemessene Prozesse festzulegen, die Vorgaben zur Anforderungsermittlung, zum Entwicklungsziel, zur (technischen) Umsetzung (einschließlich Programmierrichtlinien), zur Qualitätssicherung sowie zu Test, Abnahme und Freigabe enthalten.  

Anwendungen im Finanzsektor verarbeiten oft Daten, die eine besondere Relevanz für die Stabilität der deutschen Wirtschaft und das Vertrauen der Bürger in die öffentlichen Systeme haben. So ist zum Beispiel ein längerer Ausfall von Geldautomaten oder des Zahlungsverkehrs immer ein kritischer Zustand bzw. ein öffentliches Ärgernis, dass schnell zu einer Verunsicherung in der Bevölkerung führt. Deshalb bezeichnet man solche Anwendungen als KRITIS-Anwendungen, für die besondere Vorgaben gelten. Speziell bei der Entwicklung von bankfachlichen Anwendungen muss daher strukturiert und risikoorientiert festgelegt werden, warum und mit welchem Ziel die Veränderung erforderlich ist und mit welchen Maßnahmen eine geordnete Durchführung flankiert wird. Dazu wird ein geeignetes Projektmanagement Framework genutzt, das z.B. eine Beschreibung eines risikoorientierten Test- und Freigabeverfahrens umfasst. 

Anforderungen an die Funktionalität der Anwendung müssen ebenso erhoben, bewertet und dokumentiert werden wie nichtfunktionale Anforderungen. Die Verantwortung für die Erhebung und Bewertung der Anforderungen liegt in den Fachbereichen.  

Die Anforderungen an die Anwendung sind die Voraussetzung für die Initiierung, Durchführung und das spätere Testen derselben. Üblicherweise werden die Funktionalen Anforderungen in Fachkonzepten bzw. durch User-Stories bei agilen Projekten dokumentiert. Durch das Hinzufügen von technischen Informationen werden daraus ein DV-Konzept und Implementierungsvorgaben bzw. Product Backlogs im agilen Vorgehen erzeugt. Nichtfunktionale Anforderungen müssen ebenfalls berücksichtigt und dokumentiert werden. Hierzu sollte im ersten Schritt der Schutzbedarf der Daten im Vordergrund stehen (Schutzbedarffeststellung), um die notwendigen Maßnahmen und Vorgaben zum Schutz der betroffenen Daten ableiten zu können. Ebenso sollten Anforderungen zur Zugriffssteuerung, Ergonomie aber auch Antwortzeiten und Resilienz aufgenommen, dokumentiert und berücksichtigt werden. 

Im Rahmen der Anwendungsentwicklung sind nach Maßgabe des Schutzbedarfs angemessene Vorkehrungen im Hinblick darauf zu treffen, dass nach Produktivsetzung der Anwendung die Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität der zu verarbeitenden Daten nachvollziehbar sichergestellt werden.

Diese Anforderung ist weitestgehend selbsterklärend, dennoch wird sie trotzdem oftmals unterschätzt. Zudem ist manchmal gar nicht oder zumindest nicht exakt bekannt, welche Daten welche Anwendungen überhaupt verarbeiten. Die Antwort auf die Fragestellung, wie schützenswert meine Daten überhaupt sind, ermöglicht eine passende Antwort auf die notwendigen Maßnahmen und Aufwände, um meine Anwendung zu entwickeln. Mit der richtigen Herangehensweise im Rahmen einer Schutzbedarfsanalyse, den Schutzobjekten, Schadenpotential, Eintrittswahrscheinlichkeiten und den daraus erkannten Anforderungen und Maßnahmen können die effizientesten und passendsten Lösungen entwickelt und später auch betrieben werden. Mögliche Vorkehrungen zur Sicherstellung der Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität könnten z.B. sein: 

• Prüfung der Eingabedaten 
• Systemzugangskontrollen 
• Nutzer-Authentifizierung 
• Protokollierung 
• Benutzerrechtemanagement gemäß Minimalprinzip 
• Verschlüsselung 
• … 

Im Rahmen der Anwendungsentwicklung müssen Vorkehrungen getroffen werden, die erkennen lassen, ob eine Anwendung versehentlich geändert oder absichtlich manipuliert wurde. 

Auch hier ist wieder der ermittelte Schutzbedarf die Basis für die anzuwendenden Vorgehen. So können beispielsweise Zahlungsverkehrsanwendungen Kontodaten verändern. Integritätsverletzungen (also zum Beispiel verfälschte Kontostände) können das Vertrauen der Kunden sehr schnell und stark erschüttern. Dies ist unbedingt zu verhindern. Die Ergebnisse der Anwendungsentwicklung (Quellcode, Build-Prozeduren, Konfigurationsdateien, ausführbare Dateien, …) werden typischerweise in Konfigurationsmanagement-Systemen abgelegt, die vielfältige Möglichkeiten zur Zugriffsberechtigung und zum Schutz von Ergebnissen bereitstellen. Freigabe-Mechanismen sorgen dafür, dass Anwendungen kontrolliert in die Produktion überführt und geschützt werden können. Weiterhin sind technische Maßnahmen zur Härtung von Systemen sinnvoll. Mit diesen Maßnahmen sollten Manipulationen unterbunden bzw. erkannt werden können.  

Die Anwendung sowie deren Entwicklung sind übersichtlich und für sachkundige Dritte nachvollziehbar zu dokumentieren.  

Die Erstellung von Dokumentation ist ein wesentlicher Bestandteil der Umsetzung von Projekten im regulierten Umfeld. Ein Ziel dabei ist, dass Veränderungen jederzeit nachvollziehbar sind.  Daher ist es auch wenig verwunderlich, dass Anwendungen entsprechend zu dokumentieren (fortlaufend und mit einer Historie) sind. Natürlich muss auch sichergestellt sein, dass diese Dokumentationen entsprechend auffindbar und entsprechend Ihrer Schutzklasse (s.o.) abgelegt und gesichert sind. Der Zugriff auf die Dokumentation ist für den Besitzer und seine Nutzer im Rahmen des Berechtigungsmanagements gemäß Minimalprinzip zu definieren und umzusetzen. Auch IDV-Anwendungen, die der Fachbereich in Eigenregie erstellt hat, sind zu dokumentieren.

Es ist eine Methodik für das Testen von Anwendungen vor ihrem erstmaligen Einsatz und nach wesentlichen Änderungen zu definieren und einzuführen. Die Tests haben in ihrem Umfang die Funktionalität der Anwendung, die Sicherheitskontrollen und die Systemleistung unter verschiedenen Stressbelastungsszenarien einzubeziehen. Die Durchführung von fachlichen Abnahmetests verantwortet der für die Anwendung zuständige Fachbereich. Testumgebungen zur Durchführung der Abnahmetests haben in für den Test wesentlichen Aspekten der Produktionsumgebung zu entsprechen. Testaktivitäten und Testergebnisse sind zu dokumentieren.  

Das Testmanagement nimmt in den Anforderungen für regulierte Unternehmen einen wesentlichen Punkt ein. Im Testkonzept sind die wesentlichen Regelungen zu Test festgehalten. Die Testverfahren sind risikoorientiert ausgestaltet. Die Schutzbedarfskriterien geben hierzu die Testkriterien vor. Im Rahmen der Tests werden vor allem Verfügbarkeit, Vertraulichkeit, Integrität, Authentizität und die Übereinstimmung mit der fachlichen Spezifikation der Anwendung geprüft. Es muss hier mit einer entsprechend nachweislichen Professionalität agiert werden, um diese zu erfüllen. So müssen entsprechende Testumgebungen mit den notwendigen Testdaten bereitgestellt werden. Sollten dabei Produktivdaten benötigt werden, muss auf die entsprechende Schutzklasse geachtet werden und entsprechende abgeleitete Maßnahmen, z.B. Daten-Anonymisierung müssen angewendet werden.   

Auch die Dokumentation der Tests ist in diesem Kontext nachweislich durchzuführen. Dazu gehören beispielsweise 

• Testfallbeschreibung 
• Parametrisierung des Testfalls 
• Testdaten 
• Erwartetes Testergebnis 
• … 

Geeignete Testwerkzeuge unterstützen bei der Definition der Testfälle und bei der Dokumentation der Testfall-Ausführung und -Ergebnisse. 

Nach Produktivsetzung der Anwendung sind mögliche Abweichungen vom Regelbetrieb zu überwachen, deren Ursachen zu untersuchen und ggf. Maßnahmen zur Nachbesserung zu veranlassen.  

Auch bei erfolgreich abgeschlossenem Test muss der Regelbetrieb der Anwendung überwacht werden. Dies kann durch entsprechende Tools oder regelmäßig wiederkehrende Testfäll-Durchführungen umgesetzt werden. Die Ergebnisse der Überwachung müssen dokumentiert und Abweichungen untersucht werden. Zum Einsatz kommen hierbei gängige ITIL-Verfahren wie Monitoring, Incident-, Problem- und Changemanagement. 

Ein angemessenes Verfahren für die Klassifizierung / Kategorisierung (Schutzbedarfsklasse) und den Umgang mit den von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen ist festzulegen.  

• Die Schutzbedarfsklasse einer Anwendung leitet sich aus dem Schutzbedarf der Daten ab, welche die Anwendung verarbeitet. Die Fachbereiche eines Unternehmens verantworten die Anwendungen, die für ein Unternehmen und deren Kunden zum Einsatz kommen.  
• Grundvoraussetzung ist eine eindeutige Zuordnung der Verantwortung und die Festlegung von Anwendungsklassen, die sich am Schutzbedarf der verarbeiteten Daten orientieren. Zunächst muss also sichergestellt sein, dass jede Anwendung auch einen Anwendungsverantwortlichen hat, dass diese Zuordnung dokumentiert und auch aktuell ist. Des Weiteren muss jede Anwendung kategorisiert sein. Mögliche Kategorien sind kritische Kundensysteme, Produktionsanwendungen, produktionsnahe Eigenentwicklungen, Supportersysteme. 
• Für jede Kategorie muss beschrieben sein, wie diese Anwendungen zu behandeln sind. So kann zum Beispiel die Anzahl der Stages im Deployment (Entwicklung, Test, Pre-Prod, Prod) definiert sein. Die Einhaltung der Vorgaben ist wiederum zu prüfen.  

Die Vorgaben zur Identifizierung aller von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen, zur Dokumentation, zu den Programmierrichtlinien und zur Methodik des Testens, zur Schutzbedarfsfeststellung und zum Rezertifizierungsprozess der Berechtigungen sind zu regeln (z. B. in einer IDV-Richtlinie). 

• Typischerweise stehen nicht alle Anwendungen eines Unternehmens im Kundenkontext oder unter zentraler Kontrolle. Oft haben Fachbereiche eigene Anwendungen entwickelt, um sich die tägliche Arbeit zu erleichtern. Handelt es sich um reine Supportersysteme, ist dies kein signifikantes Risiko. Sind diese Eigenentwicklungen aber zur Voraussetzung für den geregelten Betrieb von Kundensystemen oder die wirtschaftliche Existenz von Unternehmen geworden (zum Beispiel spezielle Bestellschnittstelle eines Kunden), müssen sie identifiziert und angemessen gehandhabt werden. Man spricht dann von produktionsnahen Eigenentwicklungen, die zum Beispiel ein Staging im Deployment erfordern.  
• Im Rahmen einer Richtlinie kann das korrekte Vorgehen zur Entwicklung und Bereitstellung solcher Anwendungen geregelt werden. Zusätzlich wird ein entsprechendes Register für den Überblick erstellt. Folgende Informationen sollten z.B. im Register enthalten sein: 
• Name und Zweck der Anwendung 
• Versionierung, Datumsangabe 
• Fremd- oder Eigenentwicklung 
• Ergebnis der Risikoklassifizierung / Schutzbedarfseinstufung und ggf. die daraus abgeleiteten Schutzmaßnahmen 
• Technologie 
• … 

Es sollten regelmäßige Abfragen bei den Fachbereichs-Verantwortlichen stattfinden, um versehentlich nicht gemeldete IDV-Anwendungen zu inventarisieren.