Am 1. Januar 2015 ist das Rundschreiben 21/08 Operationelle Risiken Banken, der Finma der schweizerische Aufsichtsbehörde über den Finanzsektor, in Kraft getreten.

Mir scheint es daher an der Zeit einige Problemfelder bei der Umsetzung des Rundschreibens, im Zusammenhang mit Anforderungen an das Risikomanagement im Umgang mit elektronischen Kundendaten zu thematisieren, nachdem bei den Banken unterschiedliche Vorbereitungs- und Umsetzungsaktivitäten durchgeführt wurden.

Grundsätzlich wurden mit dem Rundschreiben die internationalen, vom Basler Ausschuss für Bankenaufsicht, definierten Principles for the Sound Management of Operational Risk umgesetzt. Diese legen unter anderem die Verantwortung für das Management operationeller Risiken auf der höchsten Organisationsstufe fest. Weiter verlangen sie von den Banken ein Rahmenkonzept, ein Kontrollsystem und eine Technologieinfrastruktur, welche die Identifizierung, Begrenzung und Überwachung dieser Risiken angemessen ermöglichen. Wenn man so will also gar nichts Neues aus der Perspektive verantwortungsbewusster Risikomanager.

Daraus könnte man primär schliessen, dass die Finma mit dem Rundschreiben lediglich beabsichtigt, zentrale, internationale Standards zum Umgang mit operationellen Risiken in den Schweizer Regulierungsrahmen aufzunehmen.

Doch die Absicht ist weiter gespannt, denn unter dem Begriff operationelle Risiken fällt ein ganzes Spektrum von Ereignissen, die von Rechts- und Betrugsfällen bis hin zu IT-Vorfällen reichen.

Da sich in den vergangenen Jahren solche Vorfälle im Zusammenhang elektronischen Kundendaten auch in der Schweiz manifestiert haben und damit verstärkt in den Fokus gerückt sind, definiert die Finma im Anhang 3 des Rundschreibens weitere Vorgaben: Neun Grundsätze regeln das sachgerechte Management von Risiken im Zusammenhang mit der Vertraulichkeit elektronischer Kundendaten von natürlichen Personen (Privatkunden).

Damit versucht die Behörde, die Lehren aus einer breiten Platte an Vorfällen zu ziehen, die von von Datendiebstählen (zum Beispiel HSBC Private Bank in Genf, Credit Suisse, Bank Julius Bär, Hyposwiss, etc.) über Systemmanipulation innerhalb der Bank, bis hin zu Marktabsprachen beim Libor oder beim Devisen-Geschäften reichen.

Kundenidentifizierende Daten

In Bezug auf kundenidentifizierende Daten (CID) sind die Regelungen detaillierter als bei anderen Risikobereichen des Rundschreibens. Dieser relativ hohe Detaillierungsgrad war einer der wesentlichen Kritikpunkte im Zusammenhang der Vernehmlassung bei den interessierten Finanz-Akteuren. Die Finma hat zwar in Einzelpunkten dieser Kritik partiell Rechnung getragen, im Grundsatz aber an ihrem Regelungskonzept festgehalten.

Aber nebst dem Rundschreiben schränken das Bankkundengeheimnis und die Datenschutzvorschriften der Schweiz den Zugriff auf und die Übertragung von bestimmten Daten ein. Diese Gesetze sind auf Daten anwendbar – in jeglicher Form, ob schriftlich, mündlich, elektronisch oder andere -, die direkt oder indirekt identifizierende Informationen über bestehende, ehemalige oder potenzielle Kunden, Konten oder Bankbeziehungen beinhalten oder solche Informationen offenlegen.

Um nun auf unser Thema, den Anforderungen an das Risikomanagement beim Umgang mit elektronischen Kundendaten zurück zu kommen, wird also eine Auslegeordnung der Typen kundenidentifizierender Daten vorteilhaft sein.

Definition – kundenidentifizierende Daten

Kundenidentifizierende Daten, englisch Client Identifying Data, sind in unserem Kontext Informationen, anhand derer ein Kunde identifiziert werden kann oder Informationen, über die die Beziehung eines Kunden mit einem Finanzinstitut ermöglicht werden. Es handelt sich dabei also um Personendaten im Sinne des DSG Art3 Bestimmung (a).

Grundsätzlich kann man zwischen drei Arten von CID unterscheiden

1. Direkte Client Identifying Data
   • Charakteristika: Alle eineindeutige, einzigartige Merkmale, die eine Identifikation eines Kunden ermöglichen. Direkter Rückschluss auf die Identität eines Kunden.
   • Kategorien: Personal identification / Company identification / Electronic address data / Physical address data
   • Beispiele: Vorname, Nachname, Unterschrift, E-Mail, Social Network IDs, Private- Business- Postadresse / Firmenname etc.
2. Indirekte Client Identifying Data
   • Charakteristika: Informationen, die erst in Kombination mit einer anderen, einen Rückschluss auf die Identität des Kunden ermöglichen.
   • Kategorien: Personal IDs in Public Registries / Customer identifiers / Career details
   • Beispiele: Passport ID, ID Card, Social security number, Tax ID, Car number plates, customer number, IBAN/BIC, Account number, Safe deposit number, Contract numbers, User ID / Passwords, Card numbers (credit and debit cards), IP address (static, dynamic) / Career details
3. Potentially indirect Client Identifying Data
   • Charakteristika: Informationen, die erst in Kombination mit anderen und unter speziellen Bedingungen, einen Rückschluss auf die Identität des Kunden ermöglichen.
   • Kategorien: Details zu Geburt / Details zu Familie / Details zur Wohnsituation / Profesionelles Profil / Identifikatoren der Firma / Nicht-identifizierende Firmendetails / Details zu persönlichen Beziehungen
   • Beispiel: Geburtsdatum (Tag, Monat), Geburtsjahr (nur das Jahr), Nationalität, Alter, Geschlecht, diplomatischer Status, Hobbies, Mitgliedschaften sowohl geschäftlich, wie auch karitativ oder privat, Heimatland, Postleitzahl, professionelle Qualifikationen, Währung des Kontos, Credit Rating, Transaktionsdaten

Folgen für die Nutzung

Die folgende Übersicht zeigt, welche Folgen sich für die Nutzung von CID aufgrund deren Typs und Sensitivität ergeben.

CID, die Kunden direkt oder indirekt identifiziert

Kundenidentifizierende Daten sind immer strikt nach dem Need to Know / Need to Have Prinzip zu behandeln, egal ob sie eine Identifikation des Kunden direkt oder indirekt zulassen. Ferner sind die folgenden Punkte strikt einzuhalten:

• Kein Cross Border Datentransfer
• Kein Zugriff auf die Daten, es sei denn diese wurden sicher anonymisiert
• Die Daten werden verschlüsselt aufbewahrt
• Sie sind nur durch ein Token oder mit vorhergehendem Einverständnis des Kunden einsehbar

CID, die eine Identifikation potenziell indirekt zulassen

Die Senitivität der kundenidentifizierenden Daten, die eine Identifikation des Kunden möglicherweise nur indirekt ermöglichen kann in zwei Kategorien unterschieden werden:

1. Persönliche Identifikatoren
2. Unpersönliche Identifikatoren

Die Sensitivität dieser Daten variiert von Fall zu Fall. Je nach Umfang der Daten, der zur Verwaltung verwendeten Applikation, der Art der Information und der Anforderungen wie zum Beispiel das Outsourcing-Verhältnis, ändert sich die Kritikalität der Sensitivität. Hier eine allgemein gültige Regelung zu finden ist sehr schwierig, da diese sehr stark von der Umgebungscharakteristik wie auch der Art und Weise der Datenverarbeitung abhängt.

Dennoch können einige Regeln festgemacht werden:

• Unpersönliche Identifikatoren sollten nie im Kundenkontext ersichtlich sein
• Die Daten können Cross Border transferiert werden
• Achtung: Einzelne oder mehrere Datenpunkte in Kombination können zu einem Muster führen, das die Identifikation des Kunden ermöglicht. Das ist eine toxische Kombination!
  • Solche Kombinationen und deren Möglichkeit muss zwingend auf einer Fall-zu-Fall-Basis eruiert werden.

Ein Verstoss gegen die Vertraulichkeit von kundenidentifizierenden Daten liegt vor, wenn kundenidentifizierende Daten gegenüber Unbefugten, seien dies externe Personen oder Mitarbeitende, offengelegt wurden.

Die meisten unbeabsichtigten Verstösse gegen die Vertraulichkeit von kundenidentifizierenden Daten geschehen, weil Mitarbeitende sich nicht über den korrekten Umgang mit kundenidentifizierenden Daten bewusst sind. Stichworte hier sind mangelndes Risikobewusstsein und fehlende Awareness, gegen die vorgegangen werden muss.

Ein Verstoss gegen die Vertraulichkeit von kundenidentifizierenden Daten kann, je nach Gerichtsstand, gravierende Risiken implizieren. Eine Auswahl:

• Reputationsschaden für das Finanzinstitut
• der Verlust von Kunden und Vermögenswerten
• behördliche Massnahmen das Finanzinstitut
• Gerichtskosten und Schadenersatzforderungen
• Disziplinarmassnahmen, Entlassung oder sogar Gefängnisstrafen für die Verantwortlichen

Herausforderungen in Zusammenhang mit toxischen Kombinationen

Unter toxischer Kombination versteht man unangemessene und sensitive Datenkombinationen, die durch ungenügende oder fehlende Zugriffskontrollen oder fehlerhafte Prozesse entstehen und somit das Risiko erhöhen, dass ausländische Nutzer, währen ihrer Tätigkeit, mit oder ohne vorsätzliche Absicht, Zugriff auf die Identität von Kunden in der Schweiz erhalten. Zugriff auf Kundenidentifikationsdaten aus dem Ausland aufgrund toxischer Kombinationen kann zu Verletzungen des schweizerischen Rechts wie auch regulatorischer Vorgaben führen.

Illustration einer toxischen Kombination

Eine strikte, angemessene Trennung von Kundenidentifikationsdaten voneinander ist wohl das probateste Mittel um sicherzustellen dass die Möglichkeit, Rückschlüsse auf die Identität von Kunden zu ziehen, für Benutzer weitestgehend unterbunden wird.

Es zeichnet sich ab, dass das Thema der toxischen Kombinationen in nächster Zukunft eine der regulatorischen Herausforderungen für Finanzinstitute sein wird und dies bei gleichzeitig steter Zunahme aller anderen regulatorischen Anforderungen.

Es sind bereits erste Konzepte für die Regelung von toxischen Kombinationen in Sichtweite, die Herausforderung aufgrund der Diversität, Komplexität der Systeme und Umgebungen – dazu noch mit Outsourcing und Offshoring – und der Prozesse macht aber eine pragmatische und risikobasierte Umsetzung schwierig. Andererseits dürfte man diese Herausforderungen auch dazu nutzen, um generell die organisatorischen und technischen Schutzmassnahmen in diesem Kontext zu revidieren und zu optimieren. Dies könnte eine solide Grundlage für die Anpassung der Geschäftsmodelle und der Prozesse bilden.

Generelle High Level Prinzipien beim Schutz von CID

Bei der konzeptionellen Planung der Umsetzung des eingangs erwähnten Finma-Rundschreibens, müssen Voraussetzungen geschaffen und Aspekte berücksichtigt werden.

1. Klarheit über die Anforderung bei Erstellung
   • Welche CID werden in welchen Applikationen gespeichert?
   • Wie und wo werden sie verarbeitet?
2. Need-to-Know
   • Engere Auslegung des Need-to-Know-Prinzips auf Rollen
   • Engere Auslegung des Need-to-Know-Prinzips auf Funktionen
   • Stete Beachtung möglicher toxischer Kombinationen
3. Andere Themenkreise beachten
   • Kundenmassendaten
   • Umgang mit Mitarbeitern
   • Umgang mit Partnern
   • Outsourcing
   • Service Provider
   • Aspekte der Cross Border Problematik

Die Anforderungen durchdringen alle Hierarchie-Stufen eines Finanzinstituts und sollten auf allen Ebenen Top-down adressiert werden:

1. Management: Attention & Awareness
   • Definition der CID Mission
   • Freigabe der nötigen Ressourcen
   • Kommunikation
   • Hervorhebung der Wichtigkeit des Themas
2. Mitarbeitende: Attention & Awareness
   • Information
   • Schulung besonders im Zusammenhang mit Schlüsselpersonen etc.
3. Internes Kontrollsystem
   • Aufnahme der Anforderungen des Rundschreibens
   • Aktualisierung von bestehenden CID-Prozessen
   • Design von neu benötigten CID-Prozessen
   • Anpassung Weisungen Kundendatenschutz
4. IT
   • Umsetzung engere Auslegung des Need-to-Know-Prinzips
   • Anpassung der Standards
   • Anpassung Zugriffsrechte
   • Anpassung Zugriffskonzepte

Die folgende Übersicht stellt eine mögliche vereinfachte Strukturierung der zu bearbeitenden Themen dar:

• Typen von relevanten Daten: Ein offizieller Kundendaten-Kategoriserungskatalog muss, wenn auch nicht erschöpfend, so doch eine Kategorisierung von verschiedenen Informationen über Kunden und deren Beziehungen, aufgegliedert nach dem Risikopotenzial dieser Informationen, die Identität des Kunden offenzulegen, beinhalten. Dies muss zusätzlich auch im Einklang mit bereits bestehenden anderen Datanklassierungsvorgaben geschehen.
• Relevante Formen von Datenoffenlegungen: Der Zugriff auf oder die Übermittlung von Kundendaten, die unter das Bankkundengeheimnis der Schweiz fallen, kann in unterschiedlichen Formen physisch oder elektronisch erfolgen:
  • E-Mail
  • Dateitransfer
  • Fax
  • tragbarer elektronischer Datenträger
  • mündlich
  • schriftlich
• Regelung: Diese Methoden müssen alle entsprechend geregelt werden.
  • Ansicht durch Remote Access wie Online-Zugriffe auf Datenbanken und Applikationen
  • Zugriff von IT-Administratoren
  • Zugriff von Nicht-IT-Administratoren
  • Cross-Border-Aspekte
  • Follow-the-Sun-Aspekte
  • Andere Aspekte
• Schutz von Kundendaten: Auch Kundendaten müssen über ihren gesamten Lebenszyklus hinweg mithilfe adäquater und nach wirtschaftlichen Gesichtspunkten angemessener organisatorischer und technischer Sicherheitsmassnahmen jederzeit vor unberechtigter Offenlegung und Verwendung geschützt werden:
  • Zugriffskonzept und -kontrollen entsprechend den Need to know_- und _Need to have_-Prinzipien und -Prozessen, um eine korrekte Vergabe und Verwendung von Zugriffsrechten sicherzustellen
  • Beschränkung des elektronischen Zugriffs auf Kundendaten
  • Beschränkung des physischen Zugriffs auf Kundendaten
  • Entsorgung von Kundendaten, die keinen gesetzlichen Vernichtungsverboten oder Aufbewahrungsvorschriften unterliegen
  • Durchsetzung der Vertraulichkeits- und Sicherheitsstandards gegenüber externen Dienstleistern, die Kundendaten abrufen, verwenden, verarbeiten oder halten, einschliesslich Anwendung einer angemessenen Due Diligence und Überwachung von externen Dienstleistern
• Need to know (und Need to have) für legitime Geschäftszwecke: Um das Need to know-Prinzip umzusetzen, müssen alle Zugriffsberechtigungen ausschliesslich rollen- und funktions-spezifisch vergeben werden. Die Herausforderung liegt hier bei einem übereinstimmenden Verständnis des _Need-to-Know-Grundsatzes und in der konsistenten Anwendung dieses Prinzips. Das Finanzinstitut muss per se evaluieren, was _Need to Know intern bedeutet hat und welche Mitarbeitenden Zugriff auf welche bestimmten CID benötigen. Als eine sehr grosse Aufgabe gilt der Umgang mit Listen, die Kundenidentifikationsdaten enthalten. Denn Listen sind typischerweise auch ausserhalb der systematisch verwaltbaren Applikationen und Systemlandschaften. Die Zugriffsberechtigungen und die Vertraulichkeit dieser Listen sicherzustellen und dabei die eigene Effektivität zu gewährleisten, ist eine grosse und heikle Aufgabe und stellt eine regulatorische Herausforderungen dar, auf die in Zukunft sicher noch genauer geschaut wird.
• Vergabe von Outsourcing-Lösungen/Aufträgen: Der Schutz der Privatsphäre der Kunden und die Beachtung des Bankkundengeheimnisses und der Datenschutzvorschriften der Schweiz müssen jederzeit gewährleistet sein. Outsourcing-Lösungen und Aufträge, die Kundendaten involvieren, sollten unter keinen Umständen vergeben werden, wenn die internen Kompetenzen oder Ressourcen nicht ausreichend sind und wenn die Sicherheit der Kundendaten nicht kategorisch gewährleistet werden kann. In diesem Zusammenhang sind folgende Aspekte zu berücksichtigen:
  • Datenoffenlegungen gegenüber Dritten und in Ländern ausserhalb der Schweiz: Outsourcing-Lösungen und Beauftragungen von Drittparteien
  • Vertraulichkeit: Pflichten der Parteien
  • Grenzüberschreitende Outsourcing-Lösungen: Mitteilung an den Kunden und auch Möglichkeit, die Kundenbeziehung zu beenden
• Einholen von Genehmigungen: Notwendige Vorabgenehmigung durch grenzüberschreitenden oder externen Zugriffen auf Kundendaten und von Übermittlungen von Kundendaten in Länder ausserhalb der Schweiz oder an Drittparteien.
• Umsetzung der Anforderungen an Kundenmassendaten: Kundenmassendaten ist diejenige Menge an CID, die bezogen auf die Gesamtpopulation relevant ist. Was nun im Einzelnen als Kundenmassendaten zu definieren ist, muss jedes Finanzinstitut für sich selbst definieren und den Auditoren der Revisionsgesellschaft nachvollziehbar, argumentativ plausibel erklären können. Das Vorgehen, die Menge von zwei CID zweier unterschiedlicher Kunden bereits als Masse zu definiert, steht laut der Finma im Widerspruch mit dem intendierten Geiste des Rundschreibens. Es besteht also zwischen den Zeilen die Aufforderung, die eigene Definition konsistent auf die einzelnen Anforderungen anzuwenden.
• Kontrolle: Selektion und Überwachung von Mitarbeitenden, Liste von Schlüsselmitarbeitenden. Finanzinstitute müssen eine fortlaufend aktualisierte Liste mit allen Schlüsselmitarbeitenden führen. Besonders hebt die Finma die erhöhte Sicherheitsanforderungen für privilegierte IT-Benutzer und Anwender mit funktionalem Zugriff auf Massen-CID Schlüsselmitarbeitenden hervor. Ihnen ist besondere Aufmerksamkeit zu widmen. Dazu muss ausformuliert werden, was unter Schlüsselmitarbeitenden verstanden wird und wie für diese Mitarbeitenden eine laufend aktualisierte Liste geführt werden soll. Dies sinnvoll in der Praxis umzusetzen birgt auch eine delikate Herausforderung Mitarbeitende nicht pauschal und vermeintlich des Tatverdachts zu bezichtigen.

Fazit

Das Rundschreiben demonstriert unter anderem, dass das Bankgeheimnis gegen Datenklau durch internen und externen Diebstahl besser geschützt werden kann, wenn die im Rundschreiben dargelegten Grundsätze eingehalten werden. Das Rundschreiben ist jedoch nur eine Empfehlung und kein Gesetz. Finanzinstitute sollten dennoch konsequent ein erhöhtes Augenmerk auf diese Anforderungen richten. Obwohl ein Finma-Rundschreiben nicht den Charakter eines Rechtserlasses hat, sind bankgesetzliche Prüfer verpflichtet, deren Einhaltung zu verifizieren. Daher kommen den Rundschreiben grosse praktische Bedeutung zu. Darunter fällt das Enforcement, die Rechtsdurchsetzung in der Finanzbranche, die eine entscheidende Mitwirkung bei der Beurteilung von Gerichtsfällen innehat.

Wenn man nun bedenkt, dass die Bankenbranche wohl generell an einem Wendepunkt steht, scheint es umso angebrachter, dass Banken auch im Zusammenhang mit dem im Rundschreiben präzisierten Schutzanforderungen von Kundendaten einen entsprechenden Paradigmenwechsel zu vollziehen und der Umsetzung des Rundschreibens, welches wohlbekannt ressourcenintensiv ist, konsequent Rechnung zu tragen. Hier macht man bei Banken leider oft die Erfahrung, dass sich die Verantwortlichen trotz der Komplexität der Aufgabe, dennoch gern massiv überschätzen und leichtfertig die Auffassung vertreten, sie seien auf der Zielgeraden, dabei stehen sie erst am Start einer langen Strecke.

Hier nochmals die besonderen Herausforderungen:

• Klassifizierung und komplette Erfassung: direkte, indirekte und potentielle CID inklusive Applikationen und Systeme
• Erhöhte Sicherheitsanforderungen für privilegierte Benutzer
• Umgang mit indirekten CID und potentiellen CID ergeben toxische Kombinationen, die in der Regel ausserhalb der systematischen Verwaltbarkeit liegen
• Unklare und individuelle Definition der Anforderungen, zum Beispiel Massen-CID (Verantwortung für sinnvolle Interpretation, Definition und Argumentation gegenüber den Auditoren und des Revisors liegt beim Finanzinstitut selbst)
• Kosten/Nutzen-Verhältnis einiger Massnahmen ist in der Praxis fraglich, was stets hohe Kosten für Administration, Verwaltung und sonstige Bürokratie impliziert und das Risiko der Ineffizienz birgt
• Umdenken und Paradigmenwechsel auch bei Partnern für Outsourcing, Clouddienste und andere nötig, um zum Beispiel die verschärften Need-to-know-Anforderungen umsetzen zu können
• Data Growth und Data-Ownership
• Cross-Border
• Weitere, individuelle Aspekte

Generell stecken aber auch einige Chancen in der Umsetzung des Rundschreibens, von denen auch der Finanzplatz insgesamt profitieren könnte.

• Inhaltlicher Mindeststandard, abgestimmt und vereinbart, mit geklärten Spielregeln im Umgang mit elektronischen Kundendaten
• Risikobasiertes Vorgehen: Fokussierung und Ressourcen auf besonders wirksame Schutz-Massnahmen ausrichten
• Möglichkeit Zugriffsberechtigungen und so eine engere Auslegung des Need-to-knows Prinzips zu verifizieren und zu bereinigen und damit Altlasten zu eliminieren
• Grundlegende Auseinandersetzung, soziopolitischer Diskurs und Awareness im Zusammenhang mit den wertvollsten Daten/Assets
• Verbindliche Einbindung des Kontrollframeworks der Outsourcing Dienstleister Verhinderung von regulatory arbitrage
• Generelle Stärkung des Datenschutzes im Verhältnis mit Partnern und Dritten

Über den Autor

Flavio Gerbino ist seit Ende der 1990er Jahre im Bereich der Informationssicherheit tätig. Seine Schwerpunkte liegen im Bereich der strategischen Ausrichtung und des Managements der Sicherheit eines Unternehmens.

Links

• http://news.bbc.co.uk/2/hi/business/8562381.stm
• http://news.yahoo.com/swiss-arrest-man-suspicion-bank-data-theft-130616618.html
• http://www.reuters.com/article/2012/08/26/us-juliusbaer-idUSBRE87P02720120826
• http://www.thelocal.ch/20111216/2056
• https://www.Finma.ch/de/~/media/Finma/dokumente/dokumentencenter/myFinma/rundschreiben/Finma-rs-2008-21.pdf?la=de
• https://www.admin.ch/opc/de/classified-compilation/19920153/index.html#a3