BAIT-Anforderungen bezüglich des IDV-Einsatzes in Banken Beobachtungen aus der Prüfungspraxis

Transkript

1 BAIT-Anforderungen bezüglich des IDV-Einsatzes in Banken Beobachtungen aus der Prüfungspraxis Rainer Englisch, Deutsche Bundesbank Hauptverwaltung in Bayern

2 Definition MaRisk-Definition Die Anforderungen aus AT 7.2 sind auch beim Einsatz von durch die Fachbereiche selbst entwickelten Anwendungen (Individuelle Datenverarbeitung IDV ) entsprechend der Kritikalität der unterstützten Geschäftsprozesse und der Bedeutung der Anwendungen für diese Prozesse zu beachten. (AT 7.2, Tz. 5) BAIT-Definition Ein angemessenes Verfahren für die Klassifizierung / Kategorisierung (Schutzbedarfsklasse) und den Umgang mit den von Endbenutzern des Fachbereichs entwickelten oder betriebenen Anwendungen ist festzulegen. (Tz. 43) Seite 2

3 IDV-Charakteristika Hohe Flexibilität damit Umsetzung kurzfristiger Anforderungen möglich Relativ einfache Nutzung der in den Trägersystemen vorhandenen zahlreichen Funktionalitäten Gegenseitige Abhängigkeiten zwischen IDV & ZDV Weiterverarbeitung von per Standardsystem produzierter (Zwischen-)Ergebnisse Datenvorverarbeitung für Standardsysteme Seite 3

4 IDV-Problemfelder Praxiserfahrung Höhere Fehlerquote und spätere Erkennung Unzureichende Entwicklungsdokumentation & Benutzerhandbücher Personelles Risiko bei Fehlen des verantwortlichen Mitarbeiters Fehlen von Zugriffsschutz & Berechtigungskonzept Ursachen Kein standardisierter Entwicklungsprozess (Spezifikation, Umsetzung, Test, Freigabe) Schwere Wartbarkeit durch Mischung von Daten, Verarbeitungslogik & Darstellung Kein adäquater, dokumentierter Change-Prozess zur Produktivsetzung Fehlendes Kontrollsystem, wenn ein einzelner Mitarbeiter sämtliche, für Einsatz einer IDV- Anwendung notwendigen Tätigkeiten durchführt Seite 4

5 Klassifizierung / Kategorisierung Kriterien (exemplarisch) Unterstützter Prozess & Anwendungszweck Verarbeitete Daten -> Schutzbedarf Nutzungshäufigkeit Einmalige Nutzung -> Keine IDV (aber Beachtung aller sonstigen Anforderungen!) Nutzerkreis Komplexität Einfache Tabellen (Daten in Listenform, Einsatz von Filtern und einfachen Funktionen, z. B. SUMME ) Fortgeschrittene Tabellen (Einsatz anspruchsvollerer Funktionen, z. B. SVERWEIS, Pivottabellen, bedingte Formatierung, strukturierter Einsatz mehrerer Tabellenblätter) Expertentabellen (VBA-Code, Datenim- & -export, eigene GUI-Anteile) Einsatz von speziellen Metriken zur Einstufung (-> Komplexitätsscore) Seite 5

6 Durch Vorgaben grundsätzlich abzudeckende Themenbereiche Identifikationsprozess Erstaufnahme Regelmäßiger Review Dokumentation Programmierrichtlinien Test & Abnahme (fachlich & technisch) Schutzbedarfsfeststellung Rezertifizierungsprozess Grundsätzlich alle Softwareentwicklungsanforderungen einschlägig, aber Abstufung in Abhängigkeit von der Kategorisierung möglich und üblich Zentral zuständige/r OE/MA erforderlich, die/der (unternehmensweit einheitliche) Vorgaben macht und die Federführung bei Erstaufnahme & Reviews haben/hat Seite 6

7 Risikomindernde Maßnahmen (exemplarisch) Gering - Kategorisierung des Tools - Jährliches Review - Zellenschutz Mittel - Vollständige Dokumentation - Zweite Person zur Pflege - Versionierung & Backups Hoch - Formales Change Management mit Test & Abnahmeverfahren im Vier-Augen-Prinzip - Komplexeres Berechtigungskonzept Kritisch - Ablösung durch ZDV-Anwendung Risikogehalt Seite 7

8 Weitere BAIT-Anforderungen IT-Strategie & IT-Governance IT-Strategie Zuordnung gängiger Standards Strategische Entwicklung der IT-Architektur (-> Anwendungslandschaft-Zielbild) Aussagen zu in den Fachbereichen selbst betriebenen / entwickelten IT-Systemen (Hard- & Software-Komponenten) IT-Governance Vermeidung von Interessenskonflikten und unvereinbaren Tätigkeiten in der IT-Aufbau- und -ablauforganisation Seite 8

9 Weitere BAIT-Anforderungen Informationsrisikomanagement & Informationssicherheitsmanagement Sämtliche Informationsrisikomanagement-Anforderungen Kompetenzgerechtigkeit & Interessenkonfliktfreiheit Informationsverbundüberblick Schutzbedarfsermittlungs-Methodik Festlegung & Dokumentation der Schutzziel-Umsetzungsanforderungen Risikoanalyse Management risikoreduzierender Maßnahmen Genehmigung der Risikoanalyse-Ergebnisse & Überführung ins OpRisk-Management IT-Risikoberichterstattung Informationssicherheit Informationssicherheitsrichtlinien & -prozesse Seite 9

10 Weitere BAIT-Anforderungen Benutzerberechtigungsmanagement Sämtliche Benutzerberechtigungsmanagement-Anforderungen Berechtigungskonzepte Zuordnung nicht-personalisierter Berechtigungen Sicherstellung der Einhaltung der Berechtigungskonzept-Vorgaben Rezertifizierung Nachvollziehbarkeit & Auswertbarkeit der Benutzerberechtigungsmanagement- & Rezertifizierungs-Dokumentation Protokollierungs- & Überwachungsprozesse bezüglich des Berechtigungseinsatzes Technisch-organisatorische Maßnahmen zur Verhinderung der Umgehung der Berechtigungskonzept-Vorgaben Seite 10

11 Weitere BAIT-Anforderungen IT-Betrieb & Sonstiger Fremdbezug von IT-Dienstleistungen IT-Betrieb (inklusive Datensicherung) Prozesse zur Änderung von IT-Systemen Datensicherungskonzept Datensicherungstests Anforderungen an Auslagerungen und den sonstigen Fremdbezug von IT-Dienstleistungen Einsatz externer Dienstleister im Rahmen des IDV-Einsatzes Auswahl & Betrieb der Trägersysteme Seite 11

12 Häufige Probleme Unvollständigkeit des IDV-Registers Ungenügende Klassifizierungskriterien Ungenügende Kontrollen beim Erstaufnahme- bzw. Reviewprozess Keine Berücksichtigung von IDV im IT-Bereich (Batch-/Shell- oder SQL-Skripte, etc.) Unangemessene Kategorisierung aufgrund mangelnder Trennschärfe von Kategorisierungskriterien, Schwächen im Kategorisierungskriterien-System oder nicht angemessen geregeltem Downgrading Keine (ausreichenden) Vorgaben für den IDV-Einsatz (Dokumentation(svorlagen), Programmierrichtlinien, Nachvollziehbarkeit von Änderungen, Benutzerhandbücher, etc.) Kontrollprozessschwächen bezüglich Einhaltung der Vorgaben Unvollständige Umsetzung der IDV-Richtlinien für Legacy-Anwendungen und von Richtlinienanpassungen Ungenügendes Management nichtmitigierter Risiken (u. a. auch bei Legacy-Anwendungen) Mangelnde Trennschärfe bei der Trägersystem-Def. / Einsatz ungenehmigter Trägersysteme Seite 12

13 Kontakt Rainer Englisch Prüfungsleiter Tel. +49 (0)89 / rainer.englisch@bundesbank.de Deutsche Bundesbank Hauptverwaltung in Bayern Referat Bankgeschäftliche Prüfungen 2 Seite 13