Anforderungen an individuelle Datenverarbeitung aus aufsichtsrechtlicher Sicht

Transkript

1 Anforderungen an individuelle Datenverarbeitung aus aufsichtsrechtlicher Sicht Informationsveranstaltung: IT-Aufsicht bei Banken Bonn,

2 Ihr Referent: Jörg Bretz seit 1989 bei der Deutschen Bundesbank 1993 Abschluss der Fachhochschule der Deutschen Bundesbank in Hachenburg seit 1993 Hauptstelle Frankfurt der Deutschen Bundesbank - Kreditabteilung seit 1995 Hauptverwaltung Frankfurt - IT-Abteilung seit 2001 Hauptverwaltung Frankfurt - Bankgeschäftliche Prüfungen Schwerpunktthemen als Prüfer und Prüfungsleiter: IT bei MaRisk- und Zulassungsprüfungen (AMA, IRBA, MRM) Operational Risk Management, Information Risk Management, Business Continuity Management und Auslagerungs-Management Training Seite 2

3 Agenda Was sind IDV-Anwendungen? Risikomanagement zu IDV-Anwendungen Anforderungen an IDV-Anwendungen im Einzelnen Zusammenfassung Seite 3

4 Was sind IDV-Anwendungen? IDV = Individuelle Daten Verarbeitung, oft auch EUC = End User Computing oder EUDA = End-User Developed Applications Üblicherweise durch Fachbereiche selbst programmierte Anwendungen Was ist mit Fachbereich gemeint? Wo beginnt die Programmierung? Erstellen von Excel-Tabellen? Aufzeichnen von Makros? Erstellen von Visual Basic Code? Wird meist nur durch eine oder wenige Personen innerhalb einer Organisationseinheit genutzt Zur Lösung von ad-hoc Datenbedürfnissen verwendet, aber auch oft für regelmäßige Informationsbedürfnisse eingesetzt Ermöglicht flexible Auswertungen zu oft statisch und unflexibel vorliegenden Daten in Bestände führenden Anwendungen Kurze Kommunikationswege, weil die Abteilung Organisation oder IT nicht eingebunden ist Seite 4

5 Risikomanagement für IDV-Anwendungen - Sensibilisierung für die Risiken Verwendet die IDV-Anwendung die richtigen Daten? Ist die Quelle aktuell, qualitätsgesichert und gegen Veränderung geschützt? Rechnet die IDV-Anwendung richtig? Wie werden Formeln und Funktionen qualitätsgesichert? Wird die aktuelle und qualitätsgesicherte Version der Anwendung eingesetzt? Sind vertrauliche Daten angemessen geschützt? Sind Zugriffsrechte definiert und auf das nötige Maß eingeschränkt? Sind die Ergebnisse der Anwendung für die interne Revision und externe Prüfer nachvollziehbar? Seite 5

6 Risikomanagement für IDV-Anwendungen - Schutzbedarfsklassifizierung Grundsätzlich analog der für klassische Anwendungen etablierten Verfahren des Informationsrisikomanagements/ Managements operationeller Risiken Schutzbedarfsanalyse die geplante IDV-Anwendung bzw. nachträglich identifizierte IDV-Anwendung wird einer Schutzbedarfsklasse zugeordnet Eintrittswahrscheinlichkeit Schadenshöhe (welche Auswirkungen ergeben sich im Arbeitsablauf aus der fehlerhaften Verarbeitung von Daten?) Der Schutzbedarf kritischer Arbeitsabläufe übersteigt regelmäßig die technischen Schutzmöglichkeiten von IDV Kritisch klassifizierte IDV-Anwendungen werden oft nicht mittelfristig auf eine durch IT gesteuerte Anwendung migriert und auch nicht als Restrisiko genehmigt und dokumentiert Seite 6

7 Risikomanagement für IDV-Anwendungen - Prozessuale Vorgaben für IDV-Anwendungen Geschäftsleitung ist für das Risikomanagement und damit auch für das Management der operationalen Risiken aus IDV-Anwendungen verantwortlich Prozessuale Anforderungen an IDV-Anwendungen werden in der Regel durch die Abteilung Organisation oder IT in einer unternehmensweit gültigen Arbeitsanweisung geregelt. Hierbei sollten die Anforderungen dem Schutzbedarf entsprechend differenziert werden Meist ist eine Arbeitsanweisung zu IDV vorhanden, die insbesondere Prozess, Dokumentation und Programmierstandards regelt Oft differenziert die Arbeitsanweisung nicht nach dem Schutzbedarf und formuliert pauschale Anforderungen, die für hohen Schutzbedarf nicht ausreichen und für viele unkritische Anwendungen zu hoch sind Seite 7

8 Risikomanagement für IDV-Anwendungen - Operative Verantwortung Die operative Verantwortung für ein angemessenes Risikomanagement von IDV-Anwendungen in der Hand der Fachbereiche. Erfahrung aus der Prüfungspraxis: Das Informationsrisikomanagement der Fachbereiche wird oft den Anforderungen nicht gerecht und daher durch die Bankenaufsicht beanstandet. IT sieht sich berechtigt nicht zuständig, wenn die Fachbereiche eigenverantwortlich agieren Die Interne Revision prüft je nach Qualifikation IDV-Anwendungen oder lässt diese gänzlich außen vor. Seite 8

9 Anforderungen im Einzelnen Worauf sollte beim Einsatz von IDV-Anwendungen im Einzelnen geachtet werden? Seite 9

10 Nachvollziehbare Schutzbedarfsklassifizierung Oft ist nicht nachvollziehbar, warum eine IDV-Anwendung als unkritisch klassifiziert wurde, obwohl Ergebnisse in bestandsführende Anwendungen übernommen werden Auf deren Basis Entscheidungen mit Tragweite getroffen werden (z. B. Preisermittlung, Positionsmanagement, Controlling, Ergebnisermittlung) Diese die Qualität wesentlicher Anwendungen sicher stellt (z. B. Abstimm- Anwendungen) Fachbereiche sollten hinsichtlich der Gefahren aus dem Einsatz ungeeigneter Anwendungen sensibilisiert werden Die Interne Revision sollte bei Prüfungen des Fachbereich die Identifikation der wesentlichen IDV-Anwendungen prüfen Die Klassifizierung muss nachvollziehbar sein Seite 10

11 Prozess zur IDV im Fachbereich Der Leiter jedes Fachbereichs ist der Herr der Daten und hat somit auch die Verantwortung für den ordnungsgemäßen Einsatz von IDV-Anwendungen Anwendungsregister (elektronisch oder in Papier) Zuständigkeiten je Anwendung definieren Programmierung, Qualitätssicherung/ Test/ Abnahme, Produktiveinsatz Wichtig: Funktionstrennung gewährleisten Dokumentation zu jeder Anwendung (neben Architektur und Funktionalität auch Zuständigkeiten, Zweck, eingesetzte Version) erstellen Jährliche Überprüfung der Schutzbedarfsklassifizierung Schulung (Entwicklung von Anwendungen z. B. mit Excel oder Access aber auch zum Anwendungsentwicklungsprozess als solches) Seite 11

12 Versionierung von IDV-Anwendungen Die Nachvollziehbarkeit des Programmcodes und seiner Versionen ist regelmäßig nicht sicher gestellt Prüfungspraxis: Es gibt nur eine Anwendungsdatei, an der immer weiter gebastelt wird und die immer wieder überschrieben wird. Preiswerte Abhilfe: Nutzung eines Versionierungstools (z. B. CVS) für die Programmdateien und die zugehörige Dokumentation. Prüfungspraxis: separate Dateiverzeichnisse, mit denen ein Versionierungstool nachzubilden versucht wird, sind meist mangels geeigneter Benutzerberechtigungsvergabe ungeeignet. Oft können ältere Versionen abgeändert werden. Seite 12

13 Trennung von Programm und Daten IDV-Anwendungen vermischen regelmäßig Code und Daten. Damit sind die Programmversionen fix an Datenversionen gekoppelt und erschweren Kontrolltätigkeiten. Preiswerte Abhilfe: separate Tabellen bzw. Datenbanken für Datenhaltung, Parametrisierung sowie die Funktionalität und Rechenlogik Seite 13

14 Wartbarkeit von IDV-Anwendungen Oft sind IDV-Anwendungen hochindividuell programmiert und damit nicht wartbar (Spaghetti-Code-Risiko) Dies verhindert Entwicklung im Team Nachvollziehbarkeit durch Dritte (Interne Revision und externe Prüfer) Unterstützung durch Spezialisten Wirtschaftliche Weiterentwicklung der Anwendung (statt Neuentwicklung) Ursache ist meist die unzureichende Qualifikation des Programmierers Lösung: Definieren von Standards zu Anwendungsarchitektur, Variablen, Objekten, Makros, Dokumentation, Qualitätssicherung, Anwendungstests Prüfung der Einhaltung dieser Standards durch die Interne Revision Seite 14

15 Wartbarkeit von IDV-Anwendungen Vielfach werden IDV-Anwendungen nur durch den Programmierer selbst getestet bzw. plausibilisiert. Selbstkontrolle führt oft zu zweifelhafter Anwendungsqualität Abhilfe: Kontrolle durch weitere Person, die nicht in die Programmierung eingebunden war Programmierer und Qualitätssicherer müssen ihre Tätigkeit nachvollziehbar dokumentieren (nachvollziehbar Verantwortung übernehmen) Zum Ende der Tests ist die fachlich-funktionale Abnahme der IDV-Anwendung zu dokumentieren Die Interne Revision sollte in inhaltliche Fragen nicht eingebunden sein, um die Anwendung unabhängig prüfen zu können Der Programmierer darf die Qualitätssicherung technisch nicht beeinflussen können (technische Funktionstrennung) Seite 15

16 Sicherer Produktivbetrieb von IDV-Anwendungen Oft gelangen Fehlerkorrekturen und Updates des Programmierers unkontrolliert in den Produktivbetrieb. Oft haben sämtliche Fachbereichsmitarbeiter schreibenden Zugriff auf IDV- Anwendungen. Dies gefährdet die Qualität der IDV-Anwendung und auch die Sicherheit der verarbeiteten Daten durch Vertuschung und Manipulation (Stichwort: Programmsiegelung) Preiswerte Abhilfe: Einschränkung der Benutzerrechte auf die produktive Programmversion Wichtig: Produktivnahme der qualitätsgesicherten Version nicht durch den Programmierer Seite 16

17 Zugriffsrechte innerhalb von IDV-Anwendungen Meist ist keine Benutzerberechtigungssteuerung in IDV-Anwendungen implementiert. Obwohl entsprechende Mechanismen in IDV-Plattformen nicht immer gegen Hacker tauglich sind, reduzieren sie immerhin das Risiko versehentlicher Veränderungen. Zellschutz in Excel für sämtliche berechnete Werte, Schreibschutz für Makros Access-Datenbanksicherheit Ist insbesondere die Rechenlogik gegen Veränderungen durch Anwender geschützt? Wird ein fachlich gebotenes Vier-Augen-Prinzip auch technisch implementiert? Seite 17

18 Nachvollziehbarkeit von Datenänderungen Meist keine Dokumentation von Datenänderungen in den IDV-Anwendungen implementiert. Der erfassende Anwender ist meist nicht nachvollziehbar. Problemlösung: Anwender erfasst nicht direkt in der Tabelle sondern ausschließlich über eine Erfassungsmaske, die den erfassenden Anwender dokumentiert. Seite 18

19 Integrität der Daten von IDV-Anwendungen Meist werden die Quelldaten der IDV-Anwendung auf unsicheren Wegen aus den bestandsführenden Anwendungen exportiert. Risiko: Manipulation der Quelldaten Preiswerte Abhilfe: automatisierte Extraktion der Quelldaten und Speicherung auf schreibgeschütztem Dateiverzeichnis Wichtig: Qualitätssicherung der Extraktionsprozedur und regelmäßige Abstimmung, ob der Datenextrakt auch alle Daten enthält Wie wird der Fachbereich zu Änderungen der bestandsführenden Anwendung informiert, die Auswirkungen auf die IDV-Anwendung haben? (z. B. Migration von Feldinhalten, Umwidmung von Werten) Seite 19

20 Dokumentation von IDV-Anwendungen Oft verzichtet der Programmierer auf die Dokumentation der Anwendung, weil er sie selbst verwendet. Aber was ist mit den Aspekten Wartbarkeit, Prüfbarkeit, Nachvollziehbarkeit, Urlaubsvertretung? Praktische Lösung: Einhaltung von Programmierstandards reduziert den Dokumentationsaufwand Architekturdokumentation: enthält Datenquellen, Überblick zur Logik und Ergebnisse der Anwendung Programmdokumentation: kann auch im Quellcode durch ausführliche Kommentare stattfinden, mit den jeweiligen Anwendungsversionen ablegen Anwenderhandbuch: kann auch in eine Arbeitsablaufbeschreibung eingebunden sein, bei größeren Anwendungen meist separates Benutzerhandbuch, mit den jeweiligen Anwendungsversionen ablegen Seite 20

21 Revision von IDV-Anwendungen Manchmal werden die IDV-Anwendungen von der Internen Revision stiefmütterlich behandelt. IT-Revision nicht zuständig, Fachrevision nicht kompetent. Problemlösung: Zuständigkeit klar regeln, Qualifikation sicher stellen. Seite 21

22 Erfahrungen aus der Prüfungspraxis IDV-Anwendungen werden im Fachbereich oft eher nebenbei entwickelt Professionelle Kenntnisse zu Prozessen, Methoden und Werkzeugen der Anwendungsentwicklung liegen selten vor Mangelnde Erfahrung führt zu kurzfristig tauglichen IDV-Anwendungen, die auf längere Sicht vielfach sehr teuer werden / Ineffizienter Ressourceneinsatz durch unprofessionelle Entwicklung Seite 22

23 Zusammenfassung der Anforderungen Schutzbedarf für IDV-Anwendungen identifizieren Prozess zu IDV-Anwendungen im Fachbereich leben Zuständigkeit und Verantwortung Versionierung Wartbarkeit, Trennung von Programm und Daten Qualitätssicherung Sicherer Produktivbetrieb und Zugriffsrechte in der Anwendung Nachvollziehbarkeit von Datenänderungen Integrität der verarbeiteten Daten Dokumentation Revision Seite 23

24 Technische Unterstützung des IDV-Prozesses Die besten Regeln werden nicht befolgt, wenn der Arbeitsablauf unbequem und umständlich organisiert ist. Prozessunterstützung durch geeignete Werkzeuge Risikobeurteilung Lebenszyklus und Release-Zyklus von IDV-Anwendungen Elektronische Prozesse oft effektiver als Papierprozesse Nutzung von für Fachbereiche verständlicher Sprache Regelmäßige Überprüfung des IDV-Portfolios Design des Arbeitsablaufs aus Sicht des späteren Anwenders im Fachbereich Seite 24

25 Kontakt Jörg Bretz Deutsche Bundesbank Hauptverwaltung Frankfurt Referat Bankgeschäftliche Prüfungen Taunusanlage Frankfurt +49 (0) joerg.bretz@bundesbank.de Seite 25