Skip to main content
main-content

21.09.2016 | MaRisk | Im Fokus | Onlineartikel

Wie Banken mit regulatorischen Vorgaben in der IT umgehen sollten

Autor:
Dieter Koenen

Die gesetzlichen Mindestanforderungen an das Risikomanagement von Kreditinstituten erfordern eine Vielzahl von Maßnahmen in der Bank-IT. Gutes Testmanagement kann den Umsetzungsstress reduzieren.

Seit Veröffentlichung des Rundschreibens zu den Mindestanforderungen an das Risikomanagement (MaRisk) sowie den Erläuterungen in 12/2012 durch die Bundesanstalt für Finanzdienstleistungsaufsicht (Bafin) müssen Banken viele Schritte in Hinblick auf ihre IT-Prozesse beachten, um ein funktionierendes Sicherheitsmanagement sicherzustellen. Dabei müssen insbesondere die Anforderungen aus AT 7.2 und AT 7.3 der MaRisk erfüllt werden. Dazu gehören

  • die Gewährleistung der Datensicherheit,
  • die Etablierung eines Regelprozesses für das Testmanagement von Software oder
  • die Erstellung und den Test von Notfallkonzepten.

Angekündigte Sonderprüfungen nach § 44, Absatz 1, Kreditwesengesetz (KWG), führen zu Stress bei den IT-Verantwortlichen in Geldhäusern. Für die ausführende Ebene gilt es, Formalismen und administrative Hürden zusätzlich zur hohen Belastung im Tagesgeschäft zu bewältigen. Dabei muss ein angemessener Umsetzungspfad in allen involvierten Bereichen gefunden werden. Das Testmanagement bildet dabei die zentrale Klammer zwischen den diversen Fachbereichen, die Softwareänderungen anfordern und testen, der Software-Entwicklung und dem IT-Betrieb.

Empfehlung der Redaktion

2014 | OriginalPaper | Buchkapitel

Sicherheitsarchitektur

Wie wir bisher gesehen haben, gibt die Sicherheits-, Kontinuitäts- und Risikopolitik den Rahmen für das Management dieser Themenfelder vor. Die zweite Ebene der Sicherheitspyramide spezifiziert die Sicherheitsziele bzw. Sicherheitsanforderungen. Die

Einige pragmatische und praxiserprobte Hinweise können helfen, die regulatorischen Anforderungen in verschiedenen Phasen aus Sicht des Testmanagements zu erfüllen.

Konzeptionsphase von Software

Neue oder modifizierte Software muss getestet werden. Die fachliche Ausprägung der Testfälle, das heißt, in welchem Szenario die Software durch die Fachbereiche getestet werden soll, gestaltet sich jedoch unmittelbar vor der Testphase oft als zäher Prozess. Viel besser ist es, in der Konzeptionsphase für jede formulierte Anforderung der Fachabteilung auch gleich eine Beschreibung des Testszenarios einzufordern. Das Thema Rollen und Berechtigungen wird üblicherweise eher stiefmütterlich behandelt. Auch hier sollte die IT in der Konzeptionsphase auf die korrekte und vollständige Definition sowie auf eine Funktionstrennung achten. Außerdem sollten IT-Verantwortliche in Banken darauf drängen, dass entsprechende Testszenarien für Berechtigungstests entwickelt werden.

Software-Entwicklungsphase

Die verschärften regulatorischen Anforderungen für Kreditinstitute haben einen massiven Einfluss auf die Fachabteilungen für die Software-Entwicklung. Diese müssen zum Beispiel 

  • Entwicklungsrichtlinien definieren und deren Einhaltung überprüfen,
  • Entwickler-Tests durchführen und nachweisen sowie
  • ein geordnetes Verfahren für den Transport von Software-Komponenten einführen.

Risikobasiert testen

Zunächst empfiehlt es sich, die Testmanagement-Prozesse und die Rollen in den Test- und Abnahmeprozessen eindeutig zu definieren sowie Templates zur Verfügung zu stellen, beispielsweise für Testkonzepte oder Testfallbeschreibungen. Auch hier gilt der Grundsatz: "Weniger ist mehr". Lange Prosa-Passagen werden nicht gelesen. Besser sind Checklisten, Tabellen und Grafiken. Um die regulatorischen Vorgaben zu erfüllen, ist die strikte Rollentrennung zwischen Fachbereich, Entwicklung und Test wichtig. Excel-basierte Testmanagement-Verfahren sind überholt. Tests und Abweichungen sind nachvollziehbar und revisionssicher zu dokumentieren und aufzubewahren. Der Einsatz von integrierten Testmanagement-Tools, wie das HP ALM Quality Center, ist obligatorisch. Aus Sicherheitsgründen dürfen in nicht zentral gemanagten Testumgebungen keine sensiblen Daten verwendet werden. So müssen beispielsweise Geschäftspartnerdaten anonymisiert werden.

Bewährt hat sich der risikobasierte Testansatz, wie er im nachfolgenden Schaubild dargestellt ist. Dabei werden die Prozesse nach Kriterien wie Aufrufhäufigkeit oder Sicherheitsanforderungen sowie Änderungen und Anpassungen im laufenden Testvorhaben bewertet.


Daraus leitet sich die Priorität der involvierten Testobjekte oder Testfälle ab. Der Fokus verschiebt sich damit risikogetrieben auf die wirklich wichtigen Überprüfungen.

Implementierung und Betrieb

Bei der Implementierung der Software zählen definierte Übergabeverfahren bei strikter Rollentrennung zwischen Entwicklung und Betrieb. Für den Betrieb sollten Geldhäuser ein möglichst toolgestütztes Information-Security-Managementsystem etablieren. Aus Sicht des Testmanagements kann dann zum Beispiel auf regelmäßige Standverfahren für ein Disaster Recovery, also das Notfallmanagement, verwiesen werden.

Fazit

Die aufgeführten Maßnahmen zur Erfüllung der regulatorischen Anforderungen müssen Banken zwingend umsetzen. Dabei ist eine ganzheitliche Betrachtung und die Implementierung praxisbewährter Ansätze wichtig. Anhand der nachstehenden Checkliste können Geldinstitute überprüfen, welche Bausteine noch einzuführen sind.

Maßnahme Nicht erfüllt Teilweise erfüllt Vollständig erfüllt
Ist die Definition von Testszenarien für Anforderungen obligatorisch?


Werden Änderungen an Rollen und Berechtigungen beschrieben?


Gibt es aktuelle Entwicklungsrichtlinien?


Ist ein integriertes Auftrags- und Transportsystem implementiert?


Sind die Rollen beim Roll-out von Software strikt zwischen Entwicklung und Betrieb getrennt?


Werden Code-Reviews durchgeführt?


Gibt es unterstützende Werkzeuge zur Qualitätssicherung in der Entwicklung?


Werden Modultests durchgeführt und dokumentiert?


Sind die Testprozesse und die Rollen im Testmanagement beschrieben?


Gibt es im Test eine strikte Rollentrennung zwischen Fachbereich, Entwicklung und Test?


Steht ein integriertes Testmanagement-Werkzeug zur Verfügung?


Werden sensible Daten in Testsystemen geschützt und anonymisiert?


Gibt es Verfahren zur Vergabe von User- und Berechtigungen für Testsysteme?


Werden die Testrisiken dokumentiert, bewertet und verfolgt?


Wird die Durchführung von Testfällen priorisiert (Risk based Testing)?


Wird die Erstellung von Pflicht-Ergebnistypen sowie von obligatorischen Tests systematisch kontrolliert (IKS-Checkliste)?


Gibt es einen definierten Prozess für den Zugriff auf sensible Testdaten?


Ist der Übergabeprozess in die Produktion definiert?


Ist ein Information Security Management System (inklusive Notfall-Konzepte etc.) etabliert?


Werden Standards wie ITIL, BSI oder DIN ISO-Normen eingesetzt?



Weiterführende Themen

Die Hintergründe zu diesem Inhalt

01.09.2016 | Branchendiskussion | Ausgabe 9/2016

Wie sich Geldhäuser vor Risiken schützen

01.04.2015 | IT | Ausgabe 4/2015

Wie Systeme stabilisiert werden können

Das könnte Sie auch interessieren

19.02.2016 | Risikosteuerung | Im Fokus | Onlineartikel

Bankprozesse krisenfest machen

05.02.2016 | Finanzbranche | Im Fokus | Onlineartikel

Banken müssen sich gegen Datenraub wappnen

Premium Partner

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.

Whitepaper

- ANZEIGE -

Blockchain-Effekte im Banking und im Wealth Management

Es steht fest, dass Blockchain-Technologie die Welt verändern wird. Weit weniger klar ist, wie genau dies passiert. Ein englischsprachiges Whitepaper des Fintech-Unternehmens Avaloq untersucht, welche Einsatzszenarien es im Banking und in der Vermögensverwaltung geben könnte – „Blockchain: Plausibility within Banking and Wealth Management“. Einige dieser plausiblen Einsatzszenarien haben sogar das Potenzial für eine massive Disruption. Ein bereits existierendes Beispiel liefert der Initial Coin Offering-Markt: ICO statt IPO.
Jetzt gratis downloaden!

Bildnachweise