griffe Risikosteuerungs-
griffe Risikosteuerungs- und Risikocontrollingprozesse (AT 4.3.2) durch Überwachungs- und Steuerungsprozesse ersetzt und gleichzeitig auf AT 7.2 Tz 4 Bezug genommen wurde. Die Aufsicht erwartet daher nicht nur Kontrolle, sondern Steuerung der Risiken und damit eine regelmäßige Überwachung von Parametern (insbesondere Messung und Bewertung von IT-Risiken sowie Risikoanalyse), Entscheidungen bei Abweichungen sowie Kontrolle der erzielten Wirksamkeit und Überwachung durch das Risikomanagement. Tz. 9 schreibt vor, dass die Bestandteile eines Systems zum Management der Informationsrisiken unter Mitwirkung aller maßgeblichen Stellen und Funktionen kompetenzgerecht und frei von Interessenkonflikten umzusetzen sind. Vonseiten der Aufsicht wurde bereits seit längerem die Bedeutung und Funktion der „Eigentümer der Informationen“ (Datenowners) hervorgehoben und verdeutlicht, dass Daten nicht das Eigentum der IT-Abteilungen, sondern der jeweiligen Fachabteilungen sind. In den Erläuterungen zu Tz. 9 wird daher klargestellt, dass die Fachabteilungen in das Informationsrisikomanagement einzubinden sind. Es sei auch hervorgehoben, dass diese Thematik mindestens seit BCBS 239 verstärkt in den Fokus der Aufsicht gerückt ist. In Tz. 10 ist mit der Bezeichnung „Informationsverbund“ ein neuer Begriff eingeführt worden, der neben geschäftsrelevanten Informationen auch die Geschäftsprozesse, IT-Systeme sowie Netz- und Gebäudeinfrastrukturen eines Instituts umfasst. Ein Institut benötigt stets einen aktuellen Überblick über die Bestandteile eines Informationsverbunds sowie deren Abhängigkeiten und Schnittstellen. Der Informationsverbund ist die Grundlage zur Schutzbedarfsfeststellung und der Ableitung von Sollmaßnahmen in den Schutzbedarfskategorien (Tzn. 11 und 12). Das Institut muss darauf achten, dass die Methodik zur Ermittlung des Schutzbedarfs (insbesondere im Hinblick auf die Schutzziele „Integrität“, „Verfügbarkeit“, „Vertraulichkeit“ und „Authentizität“) die Konsistenz der resultierenden Schutzbedarfe nachvollziehbar gewährleistet. Es 22 RISIKO MANAGER 04|2018 muss daher die Ausprägungen der einzelnen Schutzbedarfskategorien mit „Leben füllen“ und vor allem die Anforderungen zur Umsetzung der Schutzziele in den Schutzbedarfskategorien exakt voneinander abgrenzen und dokumentieren (Sollmaßnahmenkatalog, im BAIT-Entwurf noch Referenzmaßnahmenkatalog genannt). Der Sollmaßnahmenkatalog enthält nur die Anforderung, nicht jedoch bereits deren konkrete Umsetzung. Es ist zu erwarten, dass die Institute die Abgrenzung dieser Vorgaben in der Praxis wohl nicht immer sehr einfach umsetzen können. Im nächsten Schritt müssen die Institute auf der Grundlage eines Vergleichs der Sollmaßnahmen mit den jeweils wirksam umgesetzten Maßnahmen eine Risikoanalyse durchführen (Tz. 13). Risikokriterien enthalten mögliche Bedrohungen, das Schadenspotenzial, die Schadenshäufigkeit sowie den Risikoappetit eines Instituts. Die Institute müssen diese Soll-Abweichungen identifizieren und als operationelle Risiken in den Risikosteuerungsund Risikoüberwachungsprozessen auf Gesamtbankebene berücksichtigen. Es sei verdeutlicht, dass diese Überwachung und Steuerung von Sollmaßnahmen auch an die Festlegung der Verantwortlichkeiten (Genehmigung) geknüpft ist. Die aus diesen Anforderungen abgeleitete Transparenz der jeweiligen Risikosituation eines Instituts und die Akzeptanz des festgestellten Restrisikos durch die Geschäftsleitung ist aus Sicht der Aufsicht entscheidend für eine Erhöhung des IT-Risikobewusstseins innerhalb des Instituts und gegenüber IT-Dienstleistern. Hervorzuheben ist, dass über die operationellen Risiken als wesentliche Risikoart mindestens vierteljährlich nach AT 4.3.2 Tz. 3 der MaRisk zu berichten ist. Daher verlangt Tz. 14 der BAIT analog, dass die Geschäftsleitung regelmäßig, mindestens jedoch vierteljährlich, insbesondere über die Ergebnisse der Risikoanalyse sowie über Veränderungen der Risikosituation informiert wird. In den BAIT wird zusätzlich in Tz. 22 die mindestens vierteljährliche Berichtspflicht des IT-Sicherheitsbeauftragten aufgeführt. Grundsätzlich kann festgestellt werden, dass die BAIT der bisherigen Prüfungspraxis der Aufsicht folgen. Informationssicherheitsmanagement Das Modul „Informationssicherheitsmanagement“ greift die übergeordneten strategischen Vorgaben aus den vorangegangenen Abschnitten auf und verlangt die Implementierung von Richtlinien und Konzepten, um eine Konkretisierung der Ablauforganisation im IT-Bereich und die Überwachung der Einhaltung der Vorgaben zu gewährleisten. Dies ist mit der klassischen IKS-Tätigkeit der MaRisk gleichzusetzen. Tz. 15 verlangt, dass das Informationssicherheitsmanagement – analog zu AT 7.2 Tz. 2 MaRisk – Vorgaben zur Informationssicherheit macht, Prozesse definiert und deren Umsetzung steuert. Das Informationssicherheitsmanagement basiert auf einem fortlaufenden Prozess, der die Phasen Planung, Umsetzung, Erfolgskontrolle sowie Optimierung und Verbesserung beinhaltet. Die Berichtspflichten des Informationssicherheitsbeauftragten an die Geschäftsleitung sowie der Turnus der Berichterstattung entsprechen den Anforderungen der BT 3.2 Tz. 1 MaRisk. Aufgabe der Geschäftsleitung ist es gemäß Tz. 16, eine Informationssicherheitsleitlinie zu beschließen, die im Einklang mit den Strategien des Instituts stehen muss und dementsprechend auch die festgestellte Risikosituation des Instituts berücksichtigen muss. Diese Leitlinie muss die Geschäftsleitung intern veröffentlichen und angemessen kommunizieren. Auf Basis dieser beschlossenen Informationssicherheitsleitlinie muss das Institut konkretisierende, den Stand der Technik berücksichtigende Informationssicherheitsrichtlinien und Informationssicherheitsprozesse bezüglich der Dimensionen Identifizierung, Schutz, Entdeckung, Reaktion und Wiederherstellung bestimmen (Tz. 17). Das Institut hat die Funktion eines Informationssicherheitsbeauftragten mit einem in Tzn. 18 ff. definierten Aufgabenprofil einzurichten. Der IT-Sicherheitsbeauftragte ist nunmehr erstmals in einer aufsichtlichen Vorschrift erwähnt und ist das zentrale Element für die Einhaltung und Überwachung der Informationssicherheit innerhalb des Instituts und gegenüber
Regulierung 23 Dritten. Obwohl diese Stelle schon seit längerer Zeit von der Prüfungspraxis gefordert wurde, konnte sie bislang nur über die Heranziehung von Standards (z. B. BSI-Grundschutzkataloge) begründet werden. Die Stelle eines Informationssicherheitsbeauftragten ist organisatorisch und prozessual so zu gestalten, dass mögliche Interessenskonflikte vermieden werden. Die Erläuterungen zu Tz. 19 führen insbesondere aus, dass die Funktion des Informationssicherheitsbeauftragten aufbauorganisatorisch von den Bereichen zu trennen ist, die für den Betrieb und die Weiterentwicklung der IT-Systeme zuständig sind. Dem Informationssicherheitsbeauftragten ist nicht erlaubt, Aufgaben der Internen Revision wahrzunehmen. Generell hat jedes Institut die Funktion des Informationssicherheitsbeauftragten im eigenen Haus einzurichten (Tz. 20). Allerdings ist regional tätigen, insbesondere verbundangehörigen Instituten sowie kleinen und gruppenangehörigen Instituten ohne wesentliche eigenbetriebene IT mit einem gleichgerichteten Geschäftsmodell und gemeinsamen IT-Dienstleistern erlaubt, einen gemeinsamen Informationssicherheitsbeauftragten zu bestellen. Den Instituten ist außerdem eingeräumt worden, die Funktion des Informationssicherheitsbeauftragten mit anderen Funktionen im Institut zu kombinieren. Bereits im Entwurf der BAIT vom 14. Juni 2017 wurde auf die Einschränkung der Kombinationsmöglichkeit auf kleine Institute verzichtet. Somit handelt es sich bei der finalen Regelung um eine Erleichterung für alle Institute. Weiterhin besteht für die Institute die Möglichkeit, sich externer Unterstützung per Servicevertrag zu bedienen. Ein Institut muss sicherstellen, dass nach einem Informationssicherheitsvorfall die Auswirkungen auf die Informationssicherheit analysiert und angemessene Nachsorgemaßnahmen veranlasst werden (Tz. 21). Dabei muss das Institut auch dokumentieren, wie die Wirksamkeit dieser Maßnahmen überwacht wird und wie diese Ergebnisse in das Risikomanagement überführt werden. Die Geschäftsleitung muss vom Informationssicherheitsbeauftragten regelmäßig, mindestens vierteljährlich, sowie an- lassbezogen über den Status der Informationssicherheit informiert werden (Tz. 22). Der Bericht soll insbesondere eine Bewertung der Informationssicherheitslage im Vergleich zum Vorbericht, Informationen zu Projekten zur Informationssicherheit, Informationssicherheitsvorfälle sowie Penetrationstest-Ergebnisse enthalten. Die Funktion des Informationssicherheitsbeauftragten soll das IT-Risikobewusstsein der Geschäftsleitung und der Mitarbeiter eines Instituts verbessern. Benutzerberechtigungsmanagement Ein Benutzerberechtigungsmanagement hat nach Tz. 23 zu gewährleisten, dass die den Benutzern eingeräumten Berechtigungen gemäß den organisatorischen und fachlichen Vorgaben des Instituts ausgestaltet sind und genutzt werden. Der Detailierungsgrad der Anforderungen an Benutzerberechtigungen ist in den BAIT erheblich umfangreicher und geht deutlich über die Funktionstrennung, das Prinzip der minimalen Rechtevergabe und die Rezertifizierung nach AT 4.3.1 MaRisk hinaus. Vom Benutzerberechtigungsmanagement sind zusätzlich die Anforderungen gemäß AT 4.3.1 Tz. 2, AT 7.2 Tz. 2 sowie BTO Tz. 9 MaRisk zu erfüllen. In Tz. 24 werden explizit (Soll-)Berechtigungskonzepte gefordert, die sich am vorab festgelegten Schutzbedarf zu orientieren haben. Der Umfang und die Nutzungsbedingungen der Berechtigungen für die IT-Systeme sind konsistent zum ermittelten Schutzbedarf in den Berechtigungskonzepten festzulegen. Schon im BAIT-Entwurf wurde auf die Abgrenzung „IT-Berechtigung“ verzichtet und mit dem Begriff „Berechtigungen“ der Sachverhalt weiter gefasst, sodass damit u. a. auch Zugangsberechtigungen in Räumlichkeiten berücksichtigt werden können. In den Berechtigungskonzepten sollen – vollständig und nachvollziehbar ableitbar – alle von einem IT-System bereitgestellten Berechtigungen bestimmt werden. Berechtigungskonzepte sollen das Prinzip der minimalen Rechtevergabe und die Funktionstrennung berücksichtigen. Das Prinzip der minimalen Rechtevergabe (Sparsamkeitsgrundsatz) oder Need-toknow-Prinzip besagt, dass nur die Berechtigungen für die Nutzer einzurichten sind, die diese für die Bearbeitung der jeweiligen Aufgabe benötigen. Dies soll – aus Sicht der Aufsicht – das IT-Risikobewusstsein aller Beschäftigten des Instituts erhöhen. Die Einhaltung der Vorgaben des Berechtigungskonzepts zur Einrichtung, Änderung, Deaktivierung oder Löschung von Berechtigungen für Benutzer ist unter angemessener Einbindung der fachlich verantwortlichen Stelle durch Genehmigungs- und Kontrollprozesse und ein Rezertifizierungsverfahren sicherzustellen (Tzn. 26 und 28). Die Institute müssen auch prüfen, ob die eingeräumten Berechtigungen weiterhin benötigt werden und ob diese den Vorgaben des Berechtigungskonzepts entsprechen (Rezertifizierung). Dabei müssen sie die für die Einrichtung, Änderung, Deaktivierung oder Löschung von Berechtigungen zuständigen Kontrollinstanzen mit einbeziehen und diese Vorgänge entsprechend dokumentieren (Tzn. 27 und 28). Weiterhin hat das Institut Prozesse zur Protokollierung und Überwachung einzurichten, die unter Berücksichtigung des Schutzbedarfs und der Soll-Anforderungen überprüfen können, dass die Berechtigungen ordnungsgemäß genutzt werden. In den Erläuterungen zu Tz. 30 sind technisch-organisatorische Maßnahmen (Authentifizierung, sichere Passwörter und Verschlüsselung) beispielhaft aufgelistet, die einer Umgehung der Vorgaben der Berechtigungskonzepte vorbeugen sollen. Festzuhalten bleibt, dass die Anforderungen an ein angemessenes Internes Kontrollsystem (IKS) im IT-Bereich durch die Einführung der BAIT für die Institute deutlich transparenter als vorher sind. IT-Projekte und Anwendungsentwicklung Im sechsten Abschnitt der BAIT werden Vorgaben zu einer risikoadäquaten, angemessenen Steuerung von IT-Projekten und für die Anwendungsentwicklung (inklusive durch Endbenutzer in den Fachbereichen) definiert. Die Aufsicht fordert in Tz. 31, dass die Institute wesentliche Ver-
