Schlagwort: Test

Agilität-Regulatorik

„Agilität in Regulatorikprojekten – Widerspruch oder Chance?“

Anzahl und Kom­ple­xi­tät von Regu­la­to­rik­pro­jek­ten in Ban­ken stei­gen stän­dig. Immer mehr Res­sour­cen, per­so­nell und finan­zi­ell, wer­den mit der Sicher­stel­lung einer regu­la­to­rik­kon­for­men Gover­nan­ce gebun­den. Lei­der ist der Bei­trag zur unter­neh­me­ri­schen Wert­schöp­fung von Regu­la­to­rik­pro­jek­ten nahe­zu „Null“. Aus die­sem Grund kommt der effek­ti­ven Bear­bei­tung regu­la­to­ri­scher Anfor­de­run­gen sowie dem effi­zi­en­ten Manage­ment von Regu­la­to­rik­pro­jek­ten eine hohe Bedeu­tung zu. Kön­nen hier agi­le Metho­den oder gar Scrum helfen?

Zur Klä­rung einer Eig­nung von Scrum für die Durch­füh­rung regu­la­to­ri­scher Pro­jek­te in Ban­ken emp­fiehlt sich ein Blick auf die Cha­rak­te­ris­ti­ka von Pro­jek­ten, bei denen Scrum ide­al­ty­pisch ein­ge­setzt wird.

Kennzeichen von Projekten Scrum vs. Wasserfall

Auf­grund der gesetz­li­chen oder auf­sichts­recht­li­chen Vor­ga­ben, an denen Regu­la­to­rik­pro­jek­te aus­ge­rich­tet sind, wird auf den ers­ten Blick deut­lich, dass die­se Art von Pro­jek­ten nicht die Kenn­zei­chen auf­wei­sen, die ein Pro­jekt cha­rak­te­ri­sie­ren, das sich gut für die Anwen­dung von Scrum eig­net. Selbst­ver­ständ­lich lässt sich ein­wen­den, dass Metho­di­ken immer auch eine indi­vi­du­el­le Inter­pre­ta­ti­on oder Aus­prä­gung auf­wei­sen. Scrum lebt aber gera­de von der Ein­hal­tung des Metho­den­ka­nons, um sei­ne Wir­kung ent­fal­ten zu kön­nen. Metho­di­sche „Ein­grif­fe“ stel­len hier den Erfolg eines Scrum-Pro­jek­tes schnell in Fra­ge – die Anwen­dung von Scrum wird mit die­sen Ein­grif­fen abgebrochen.

Lösen wir uns vor die­sem Hin­ter­grund ein­mal von dem Begriff Scrum und rücken statt­des­sen Agi­li­tät in den Mit­tel­punkt der Betrach­tung. Unter der Fra­ge­stel­lung, ob und wenn ja wel­che agi­len Metho­den für Regu­la­to­rik­pro­jek­te geeig­net sind, ist eine Ent­kopp­lung von der Stren­ge der durch Scrum deter­mi­nier­ten Vor­ga­ben möglich.

Wel­che agi­len Metho­den gibt es, die in Scrum genutzt wer­den, und gibt es dar­über hin­aus geeig­ne­te Ergän­zun­gen die­ses agi­len Tool­sets – die­se Fra­ge soll im Fol­gen­den betrach­tet wer­den, um danach die Eig­nung für einen Ein­satz in Regu­la­to­rik­pro­jek­ten zu bewerten.

Die aus Scrum bekann­ten agi­len Metho­den las­sen sich aus mei­ner Erfah­rung grob in drei Schwer­punk­te auf­tei­len. Sie unter­stüt­zen eine inhalt­li­che Struk­tu­rie­rung, eine zeit­li­che Struk­tu­rie­rung oder stel­len die Inter­ak­ti­on der Betei­lig­ten in den Mit­tel­punkt. Nach­ste­hen­de Über­sicht ord­net die in Scrum genutz­ten Metho­den­bau­stei­ne die­sen drei Schwer­punk­ten zu.

Agile Methoden - Schwerpunkt Interaktion

Zu 1 – Inhalt­li­che Strukturierung

  • Mit­tels eines Back­logs kön­nen Anfor­de­run­gen in unter­schied­li­cher Aus­prä­gung und Doku­men­ta­ti­ons­form ver­wal­tet werden
  • Neben der Beschrei­bung erfolgt für die Inhal­te eines Back­logs eine Dar­stel­lung von Auf­wand und Nut­zen sowie eine Priorisierung
  • Ent­spre­chend der Prio­ri­sie­rung wird die Beschrei­bung detail­lier­ter spezifiziert
  • Das Kan­ban-Board visua­li­siert Arbeitsfortschritte
  • Auf­ga­ben durch­lau­fen nach Arbeits­fort­schritt geglie­der­te Rubri­ken, die je nach Ein­satz­zweck unter­schied­lich geglie­dert wer­den, z. B.:
    • Zu tun | In Arbeit | Erledigt
    • Back­log | Kon­zep­ti­on | Umset­zung | Test | Frei­ga­be | Erledigt

Eig­nung für Regulatorikprojekte:

Eine struk­tu­rier­te Samm­lung von Anfor­de­run­gen ist Inhalt jedes Pro­jek­tes und damit auch für Regu­la­to­rik­pro­jek­te essen­zi­ell. User Sto­ries wer­den sicher­lich nicht die domi­nie­ren­de Bedeu­tung in der Zusam­men­set­zung des Back­logs haben. Eben­so wenig wird die Sum­me der Anfor­de­run­gen mit­tels eines Fach­kon­zepts und eines DV-Kon­zepts beschrie­ben, um dann mit dem Label Back­log ver­se­hen zu werden.

Unter Berück­sich­ti­gung eines modu­la­ren Auf­baus der Grund­ge­samt­heit von Anfor­de­run­gen in Regu­la­to­rik­pro­jek­ten ist ein Back­log gut geeig­net, um die­se als Sum­me zu ver­wal­ten. Aus ihm las­sen sich dann zusam­men­hän­gen­de Ein­zel­an­for­de­run­gen her­aus­zie­hen und in einen Sprint-Back­log zusam­men­fas­sen. Denk­bar sind hier bei­spiels­wei­se Use-Cases zur Anbin­dung von Anwen­dungs­sys­te­men oder Infra­struk­tur­kom­po­nen­ten an ein SIEM (Secu­ri­ty Inci­dent and Event Management).

Zu 2 – Zeit­li­che Strukturierung

Sich für einen kur­zen Arbeits­zeit­raum defi­nier­te Arbeits­in­hal­te vor­zu­neh­men, die aus der Grund­ge­samt­heit aller Anfor­de­run­gen aus­ge­wählt wer­den, ist unab­hän­gig von Scrum ein sinn­vol­les Vor­ge­hen zur Hand­ha­bung eines kom­ple­xen Anfor­de­rungs­uni­ver­sums. Vor­aus­set­zung ist jedoch, dass die Inhal­te eines Sprints kei­ne zu fes­te Kopp­lung zu ande­ren Anfor­de­run­gen außer­halb des Sprits auf­wei­sen und damit eine unab­hän­gi­ge Bear­bei­tung ermöglichen.

Eig­nung für Regulatorikprojekte:

Fol­gen­de Bei­spie­le aus Regu­la­to­rik­pro­jek­ten sei­en zur Ver­deut­li­chung genannt:

  • Anbin­dung von Anwen­dun­gen an ein PAM-Tool (pri­vi­le­ged access manage­ment) zum Hand­ling pri­vi­le­gier­ter Berechtigungen
  • Durch­füh­rung einer Busi­ness-Impact-Ana­ly­se für einen Kernprozess
  • Umset­zung gemein­sa­mer Schwach­stel­len­scans mit einem IT-Provider

Gemein­sa­mes Cha­rak­te­ris­ti­kum obi­ger Tätig­kei­ten ist, dass sie nicht durch eine Per­son allein durch­ge­führt wer­den, son­dern nur personen‑, abteilungs‑, bereichs- oder fir­men­über­grei­fend bewäl­tigt wer­den kön­nen. Mit ihrer losen Kopp­lung zu ande­ren The­men sind sie jedoch gut für eine Bear­bei­tung in Form eines Sprints geeignet.

Deut­lich wird anhand die­ser Auf­ga­ben jedoch die Not­wen­dig­keit zur Inter­ak­ti­on in der Bear­bei­tung. Und genau hier liegt der drit­te Schwer­punkt agi­ler Methodiken.

Zu 3 – Interaktion

„Mit­ein­an­der reden“ hie­ßen nicht nur die vier Stan­dard­wer­ke von Frie­de­mann Schulz von Thun zur Kom­mu­ni­ka­ti­ons­psy­cho­lo­gie, son­dern auch in Pro­jek­ten gilt die­ser Leit­satz. Aus die­sem Grund wur­den in der Scrum-Metho­dik Vor­ga­ben zum struk­tu­rier­ten Aus­tausch umge­setzt, sei es der täg­li­che Stan­dup oder Sprint-Review und Sprint-Retro­spek­ti­ve. Struk­tu­rel­le und zeit­li­che Vor­ga­ben stel­len die Effi­zi­enz und Effek­ti­vi­tät die­ser Ter­mi­ne sicher.

Eig­nung für Regulatorikprojekte:

Die Eig­nung eines täg­li­chen Stan­dup für Regu­la­to­rik­pro­jek­te steht außer Zwei­fel, hat sich doch die­ses kur­ze Mee­ting inzwi­schen weit über Scrum hin­aus in den beruf­li­chen All­tag aus­ge­brei­tet. Wich­tig im Kon­text von Regu­la­to­rik­pro­jek­ten ist hier jedoch die Ein­hal­tung der struk­tu­rel­len und zeit­li­chen Vor­ga­ben aus Scrum, um einen dif­fu­sen Infor­ma­ti­ons­aus­tausch zu ver­mei­den. Das Ergeb­nis eines Sprints im Review zu betrach­ten und Ver­bes­se­run­gen dar­aus abzu­lei­ten (Retro­spek­ti­ve), ist grund­sätz­lich auch außer­halb von Scrum wich­tig. Die eng gefass­ten metho­di­schen Vor­ga­ben ver­lie­ren jedoch ein Stück weit an Bedeu­tung, wenn in Regu­la­to­rik­pro­jek­ten nicht wie bei Scrum das Ergeb­nis eines Sprints pro­duk­tiv gesetzt wird.

Zusam­men­fas­sung:

Zusam­men­fas­send lässt sich sagen, dass Scrum als geschlos­se­ne Metho­dik sicher­lich nicht geeig­net ist für die Durch­füh­rung von Regu­la­to­rik­pro­jek­ten. Aber eine Viel­zahl von Ele­men­ten aus dem agi­len Metho­den­bau­kas­ten, den Scrum nutzt, las­sen sich über­tra­gen. Sie zah­len ein auf die schnel­le Erzeu­gung ver­wert­ba­rer Ergeb­nis­se im Pro­jekt, die Sicher­stel­lung der Kom­mu­ni­ka­ti­on sowie die Umset­zung der ganz­heit­li­chen Ziel­set­zung des Projektes.

Hier haben Erfah­run­gen gezeigt, dass sich ein­zel­ne Ele­men­te auch sehr gut mit­ein­an­der kom­bi­nie­ren las­sen. Expli­zit sei hier auf die Metho­dik des Scrum­ban hin­ge­wie­sen, in der die Visua­li­sie­rung mit­tels Kan­ban-Board um pro­zes­sua­le Ele­men­te erwei­tert wird. So infor­miert es über die Anzahl der Objek­te, an denen das Team gera­de arbei­tet, sowie die Anzahl an Auf­ga­ben, wel­che schon abge­schos­sen sind. Ziel ist hier die Stär­kung von Ver­ant­wor­tungs­be­wusst­sein und Kom­mu­ni­ka­ti­on sowie die Visua­li­sie­rung der bereits erziel­ten Leistungsergebnisse.

In einer fort­ge­schrit­te­nen Aus­bau­stu­fe kann ein sol­ches Scrum­ban-Board durch die inkre­men­tel­le Arbeits­pla­nung Sprints obso­let machen. Jedoch hat sich im prak­ti­schen Ein­satz die Kom­bi­na­ti­on von Sprints und Scrum­ban-Boards bewährt. Das Prin­zip­bild eines Scrum­ban-Boards zeigt nach­ste­hen­de Abbildung.

Backlog

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als fünf­zehn Jah­ren Erfah­rung mit Pro­jek­ten im Kon­text IT-Regu­la­to­rik sichert pra­xis­er­prob­tes Wis­sen. Umfang­rei­che Kennt­nis von Orga­ni­sa­ti­ons­struk­tu­ren, Pro­zes­sen und IT-Sys­te­men deut­scher Ban­ken und Spar­kas­sen gewähr­leis­ten den erfor­der­li­chen fach­li­chen und tech­ni­schen Hintergrund.

Auf die­ser Grund­la­ge sowie mit­tels unse­res lang­jäh­ri­gen Erfah­rungs­schat­zes in der erfolg­rei­chen Anwen­dung tra­di­tio­nel­ler und agi­ler Metho­den im Pro­jekt wäh­len wir gemein­sam mit Ihnen den für Ihr Insti­tut geeig­ne­ten Metho­den­mix aus.

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de


Horizont

„Handlungsdruck für Banken – BAIT-Neuerungen 2021“

Als 2017 die Bank­auf­sicht­li­chen Anfor­de­run­gen an die IT, kurz BAIT, als Kon­kre­ti­sie­rung der in den MaRisk gere­gel­ten regu­la­to­ri­schen Anfor­de­run­gen an die Infor­ma­ti­ons­tech­nik von Ban­ken ein­ge­führt wur­den, ging ein Rau­nen durch die Com­mu­ni­ty. In der BAIT wur­de erst­mals kon­kret vor­ge­ge­ben, wie die Auf­sicht sich die regu­la­to­rik­kon­for­me Aus­ge­stal­tung der Ban­ken IT vor­stellt. Zwar galt für die BAIT das Pro­por­tio­na­li­täts­prin­zip, das eine Aus­ge­stal­tung anhand der kon­kre­ten Situa­ti­on des jewei­li­gen Insti­tuts zuließ. Prü­fungs­er­fah­run­gen von EZB, Bun­des­bank, BaFin, aber auch der haus­ei­ge­nen Revi­si­ons­ab­tei­lun­gen haben jedoch gezeigt, dass die BAIT nicht als gestal­tungs­frei­er „Papier­ti­ger“ ver­stan­den, son­dern als „umzu­set­zen“ vor­ge­ge­ben wer­den. Die spe­zi­fi­schen Anfor­de­run­gen für kri­ti­sche IT-Struk­tu­ren in dem im Jahr 2018 ergänz­ten KRITS-Modul mach­ten deut­lich, dass der mit der BAIT ein­ge­schla­ge­ne Weg sei­tens der BaFin kon­se­quent fort­ge­führt wird.

Zwei Jah­re sind seit­dem ver­gan­gen. Vie­le Insti­tu­te sind auch heu­te noch damit beschäf­tigt, die auf Grund­la­ge der BAIT erfolg­ten Fest­stel­lun­gen aus inter­nen und exter­nen Prü­fun­gen zu bear­bei­ten und ihre IT com­pli­ant zu gestal­ten. Da steht auch bereits eine signi­fi­kan­te Erwei­te­rung der Anfor­de­run­gen aus der BAIT in den Start­blö­cken. 2020 erfolg­te die Kon­sul­ta­ti­ons­pha­se mit den Insti­tu­ten. Für das kom­men­de Jahr 2021 ist vom Go-live der neu­en Ansprü­che auszugehen.

Drei neue Kapi­tel ergän­zen die bestehen­den Anfor­de­run­gen, von denen die ope­ra­ti­ve IT-Sicher­heit und das IT-Not­fall­ma­nage­ment die bei­den bedeut­sa­me­ren sind im Ver­gleich zum Kapi­tel Kun­den­be­zie­hun­gen zu Zahlungsdienstleistern.

Mit dem neu­en Kapi­tel „ope­ra­ti­ve IT-Sicher­heit“ wer­den die bis­he­ri­gen Anfor­de­run­gen an Netz­werk­si­cher­heit, Sys­tem­här­tung, Pene­tra­ti­ons- und Schwach­stel­len­test geschärft und in einem eige­nen Kapi­tel gebündelt.

Das neue Kapi­tel IT-Not­fall­ma­nage­ment trägt der Tat­sa­che Rech­nung, dass sich die EBA-Gui­de­li­nes expli­zit mit die­sem Hand­lungs­feld befas­sen und ergänzt die BAIT um Inhal­te des IT-Not­fall­ma­nage­ments sowie des Busi­ness-Con­ti­nui­ty-Manage­ments. Neben der Identifi­kation der für Not­fäl­le rele­van­ten Res­sour­cen und Pro­zes­se ste­hen Maß­nah­men zur Gewähr­leis­tung der Fort­füh­rung des Geschäfts­be­triebs im Fal­le von Not­fäl­len im Fokus die­ses Kapi­tels. Hin­zu kom­men Anfor­de­run­gen an die Durch­fü­gung von Tests und Übun­gen zur Sicher­stel­lung der Wirk­sam­keit der defi­nier­ten Vorkehrungen.

Über die neu­en Kapi­tel hin­aus wur­den auch bestehen­de Stel­len kon­kre­ti­siert oder erwei­tert. Eine wesent­li­che Ver­än­de­rung im Ver­gleich zu der bestehen­den BAIT liegt im pro­zes­sua­len Betrachtungsgegenstand.

Stan­den bis­her die IT-Pro­zes­se sowie die IT-Sys­te­me als Infor­ma­ti­ons­ver­bund im Mit­tel­punkt der Betrach­tung, sind jetzt sämt­li­che Geschäfts­pro­zes­se im Fokus, und zwar hin­sicht­lich ihrer Unter­stüt­zung mit­tels IT-Anwen­dun­gen, Infra­struk­tu­ren und Daten. Die­ses ist neu und erwei­tert den Scope nach­hal­tig. Vor allem auch des­halb, weil die Ein­bin­dung von exter­nen Dienst­leis­tungs­part­nern nicht mehr pri­mär auf das Hand­lungs­feld Sourcing/Dienstleister­steuerung beschränkt ist. Viel­mehr sind die IT-rele­van­ten Ele­men­te ihrer Leistungsunter­stützung im Pro­zess rele­van­te Scopes. Der Infor­ma­ti­ons­ver­bund als Betrach­tungs­ge­gen­stand erhält so eine ande­re Kom­ple­xi­tät, die es in der Bank regu­la­to­risch zu mana­gen gilt.

Eben­so eine Aus­wei­tung erfah­ren die Anfor­de­run­gen an IT-Ser­vice­pro­zes­se. So sind mit der Erwei­te­rung der BAIT die bei­den ITIL-Pro­zes­se Capa­ci­ty-Manage­ment und Avai­la­bi­li­ty-Manage­ment in den Insti­tu­ten zu etablieren.

Das Capa­ci­ty-Manage­ment sichert die Kapa­zi­tät der IT-Ser­vices sowie der IT-Infra­struk­tur. Ziel ist, dass alle Kom­po­nen­ten der IT-Ser­vices die ver­ein­bar­ten Kapa­zi­täts- und Per­for­mance­zie­le errei­chen, auch unter Berück­sich­ti­gung zukünf­ti­ger Anforderungen.

Das Avai­la­bi­li­ty-Manage­ment stellt die Ver­füg­bar­keit der IT-Ser­vices sicher, in dem alle Kom­po­nen­ten der IT-Ser­vices die ver­ein­bar­ten Ver­füg­bar­keits­zie­le erreichen.

Wich­tig ist hier­bei der Bezug zu den oben beschrie­be­nen Aus­wei­tun­gen in der Defi­ni­ti­on des Infor­ma­ti­ons­ver­bun­des. Dadurch wird deut­lich, dass eine bank­in­ter­ne Betrach­tung der bei­den neu­en Pro­zes­se zu kurz greift und die betei­lig­ten Dienst­leis­tungs­part­ner ein­zu­bin­den sind.

Nach­ste­hen­de Abbil­dung fasst die­se neu­en, respek­ti­ve ver­schärf­ten Ansprü­che der BAIT-Anfor­de­rung zusam­men und zeigt, wel­che Effek­te die­se auf die Insti­tu­te erwar­ten lassen.

Schon auf den ers­ten Blick wird deut­lich, dass die neu­en eben­so wie die erwei­ter­ten Anfor­de­run­gen der BAIT nicht mit­tels eines „Quick Hit“ zu bewäl­ti­gen sind. Zu umfang­reich waren und sind die Her­aus­for­de­run­gen aus den 2017 und 2018 for­mu­lier­ten Anfor­de­run­gen der BAIT für die Banken.

Ent­spre­chend der indi­vi­du­el­len Aus­gangs­si­tua­ti­on des Insti­tuts und dem Grad der für die eige­ne IT gewähl­ten Stan­dar­di­sie­rung gibt es hin­sicht­lich des Umset­zungs­ho­ri­zonts kurz­fris­ti­ge Aspek­te, grund­sätz­lich aber eher eine lang­fris­ti­ge Per­spek­ti­ve. Durch die Aus­wei­tung des Infor­ma­ti­ons­ver­bun­des sind die BAIT kein aus­schließ­li­ches IT-The­ma mehr, son­dern ein Pro­zess­the­ma, das die IT-Unter­stüt­zung des jewei­li­gen Pro­zes­ses im Fokus hat. Damit sind neben den Spe­zia­lis­ten des eige­nen IT-Bereichs zuneh­mend sol­che der rele­van­ten Dienst­leis­tungs­part­ner ein­zu­bin­den. Dar­über hin­aus sind auch Exper­ten aus den Fach­be­rei­chen der Bank zu involvieren.

Damit wird deut­lich, dass ins­ge­samt ein hoher Auf­wand für die Insti­tu­te mit der Umset­zung der Neue­run­gen in der BAIT ver­bun­den ist.

Vor die­sem Hin­ter­grund sind zwei Tätig­kei­ten von her­aus­ge­ho­be­ner Bedeu­tung. Ers­tens die Iden­ti­fi­ka­ti­on des Infor­ma­ti­ons­ver­bunds für die betrof­fe­nen Geschäfts­pro­zes­se, um den Hand­lungs­rah­men und die ein­zu­bin­den­den Par­tei­en trans­pa­rent und voll­stän­dig zu iden­ti­fi­zie­ren. Zwei­tens die dar­auf auf­bau­en­de Ablei­tung einer Umset­zungs­road­map, die auch den aktu­el­len Sta­tus quo des Insti­tuts berücksichtigt.

Um die­ses so ziel­ge­rich­tet wie mög­lich zu tun, ist nicht nur die Kennt­nis der regu­la­to­ri­schen Anfor­de­run­gen ent­schei­dend. Wesent­lich bedeut­sa­mer ist die umfang­rei­che Pra­xis­ex­per­ti­se zu Bank­pro­zes­sen sowie der in den Pro­zes­sen ein­ge­setz­ten IT-Sys­te­me und ihrer Schnitt­stel­len unter­ein­an­der. In Kom­bi­na­ti­on mit Erfah­run­gen aus Audit- und Umset­zungs­pro­jek­ten im Kon­text Ban­ken­re­gu­la­to­rik stel­len sie die kri­ti­schen Erfolgs­fak­to­ren dar, eine effi­zi­en­te Umset­zung der BAIT-Neue­run­gen zu pla­nen und durchzuführen.

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als fünf­zehn Jah­ren Erfah­rung mit Pro­jek­ten im Kon­text IT-Regu­la­to­rik sichert pra­xis­er­prob­tes Wis­sen. Umfang­rei­che Kennt­nis von Orga­ni­sa­ti­ons­struk­tu­ren, Pro­zes­sen und IT-Sys­te­men deut­scher Ban­ken und Spar­kas­sen gewähr­leis­ten den erfor­der­li­chen fach­li­chen und tech­ni­schen Hintergrund.

Auf die­ser Grund­la­ge unter­stützt ban­kon effi­zi­ent und ziel­ge­rich­tet in der Iden­ti­fi­ka­ti­on aller betei­lig­ten Assets am Infor­ma­ti­ons­ver­bund, der effi­zi­en­ten Erstel­lung einer Umsetzungs­roadmap für die BAIT-Neue­run­gen sowie der Umset­zung selbst.

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de


Cybersecurity

„Tiber-EU und Tiber-DE“ – Die europäische Antwort auf Cyberkriminalität in Banken?

Angrif­fe von Hackern auf Kre­dit­in­sti­tu­te sind kein loka­les oder natio­na­les Phä­no­men. Viel­mehr ist es ein welt­wei­tes The­ma, des­sen Auf­tre­ten nicht mehr nur „hin­ter vor­ge­hal­te­ner Hand“ dis­ku­tiert wird, son­dern bei­na­he im Wochen­tur­nus Schlag­zei­len in der Pres­se erzeugt.

In Deutsch­land waren bis­her im Jahr 2020 vie­le rele­van­te Ban­ken und Insti­tuts­grup­pen betrof­fen. Sei es mit­tel­bar, weil Kre­dit­kar­ten­in­for­ma­tio­nen unbe­rech­tig­ten Per­so­nen zugäng­lich wur­den oder unmit­tel­bar, weil Bank­funk­tio­na­li­tä­ten für Kun­den nicht mehr zugäng­lich waren. Der Glau­be, dass vor allem Fin­Techs oder Ban­ken mit Inter­net- oder Mobil­ge­rät-Schwer­punkt Ziel von Cyber­kri­mi­na­li­tät sind, hat sich als Irr­glau­be herausgestellt.

Neben wirt­schaft­li­chen Schä­den ist es vor allem der Repu­ta­ti­ons­scha­den in Form von Ver­trau­ens­ver­lust, der für die betrof­fe­nen Insti­tu­te rele­van­te Aus­wir­kun­gen haben kann.

Begriff­lich wer­den ganz all­ge­mein Straf­ta­ten, bei denen die Täter moder­ne Infor­ma­ti­ons­tech­nik nut­zen, als Cyber­kri­mi­na­li­tät bezeich­net. Fasst man die­sen Begriff etwas enger, so wer­den dar­un­ter Straf­ta­ten ver­stan­den, die auf Com­pu­ter­sys­te­me und Netz­wer­ke zie­len. Hier­un­ter wer­den auch Akti­vi­tä­ten der Cyber­spio­na­ge sub­sum­miert. Die bekann­tes­te Form von Cyber­kri­mi­na­li­tät ist das Phis­hing. Ziel­set­zung ist hier, z. B. Pass­wör­ter, Zugangs­in­for­ma­tio­nen oder per­sön­li­che Daten mit­tels gefälsch­ter E‑Mails oder Web­sites in Erfah­rung zu bringen.

Der Gegen­part zur Cyber­kri­mi­na­li­tät ist für die Ban­ken die Cyber­se­cu­ri­ty. Ziel ist der Schutz vor tech­ni­schen und orga­ni­sa­to­ri­schen Bedro­hun­gen, die die Sicher­heit von IT-Infra­struk­tu­ren und die Daten­si­cher­heit gefähr­den. Unter die­sem Begriff wer­den alle Kon­zep­te und Maß­nah­men zusam­men­ge­fasst, mit denen Ban­ken Gefähr­dun­gen erken­nen, bewer­ten, ver­fol­gen und vor­beu­gen mit der Ziel­set­zung, die Hand­lungs- und Funk­ti­ons­fä­hig­keit schnellst­mög­lich wiederherzustellen.

Das in die­sem Kon­text zu gestal­ten­de Maß­nah­men­bün­del setzt sich aus einer Viel­zahl unter­schied­li­cher Kom­po­nen­ten zusam­men, wie nach­ste­hen­des Prin­zip­bild zeigt.

Tiber; Regulatorik Grafik 1
Prin­zip­bild mit Maßnahmenbündel

Für die Ban­ken stellt sich in die­sem Zusam­men­hang die Fra­ge einer regu­la­to­ri­schen Ori­en­tie­rung, für gro­ße, sys­tem­re­le­van­te oder inter­na­tio­nal agie­ren­de Insti­tu­te auch die eines euro­päi­schen Rah­mens für Cybersecurity.

Das Tiber-EU-Frame­work ist hier ein ers­ter Schritt. Es ist ein Euro­päi­sches Rah­men­werk für ein kon­trol­lier­tes und insti­tuts­in­di­vi­du­el­les Tes­ten in Bezug auf Cyber­an­grif­fe auf den Finanz­markt. Die Anwen­dung ist frei­wil­lig und liegt in der Ent­schei­dungs­ver­ant­wor­tung des ein­zel­nen Kreditinstitutes.

Sechs Ziel­set­zun­gen wer­den durch das Tiber-EU-Frame­work angestrebt:

  • Euro­pa­wei­te Stär­kung der Fähig­keit zur Abwehr von Cyber­an­grif­fen bei Finanzdienstleistungsunternehmen
  • Stan­dar­di­sie­rung und Har­mo­ni­sie­rung im Vor­ge­hen mit der Mög­lich­keit für natio­na­le Anpassungen
  • Leit­fa­den für Behör­den zur natio­na­len Eta­blie­rung und Ori­en­tie­rung zur länderüber­greifenden Vergleichbarkeit
  • Unter­stüt­zung eines län­der­über­grei­fen­den Vor­ge­hens für inter­na­tio­na­le Institute
  • Regu­la­to­ri­sche Ent­las­tung ein­zel­ner EU-Mitgliedsstaaten
  • Gemein­sa­me Doku­men­ta­ti­ons­richt­li­ni­en zum inter­na­tio­na­len Ergebnisaustausch

Unter dem Fokus Infor­ma­ti­ons- und Erkennt­nis­ge­win­nung wer­den kri­ti­sche Bank­sys­te­me mit rea­len Angriffs­sze­na­ri­en (Tak­ti­ken, Tech­ni­ken und Pro­zes­sen) kon­fron­tiert. Simu­liert wer­den in Form eines ethi­schen Hackings pra­xis­na­he Angrif­fe auf bank­fach­li­che Funk­tio­nen und die zugrun­de­lie­gen­den IT-Sys­te­me und IT-Infrastrukturen.

Die­se Ziel­set­zung spie­gelt sich in der Namens­ge­bung Tiber (Thre­at Intel­li­gence-based Ehti­cal Red Tea­ming) wie­der. Wobei unter Thre­at Intel­li­gence die auf­be­rei­te­te Bereit­stel­lung aktu­el­ler Infor­ma­tio­nen zur Bedro­hungs­la­ge der IT-Sicher­heit durch Cyber­an­grif­fe und ande­re Gefah­ren aus unter­schied­li­chen Quel­len ver­stan­den wird.

Die Test­durch­füh­rung glie­dert sich in drei Phasen:

Testdurchführung
Drei Pha­sen der Testdurchführung
  1. Vor­be­rei­tung mit der Skiz­zie­rung der Bedro­hungs­si­tua­ti­on und Ris­ken im natio­na­len Finanz­sek­tor sowie dem for­ma­len Start des Tests mit Fest­le­gung der kon­kre­ten Ziel­set­zung, dem Staf­fing des eige­nen Teams und der Beauf­tra­gung der Dienst­leis­tungs­part­ner für Thre­at Intel­li­gence (TI) und Red-Team (RT)
  2. Test­durch­füh­rung durch die Dienst­leis­tungs­part­ner für TI und RT. Der TI-Part­ner erstellt Ziel­set­zung und Bedro­hungs­sze­na­rio für den „Angriff“ durch das RT
  3. In der Abschluss­pha­se erstel­len Angrei­fer (RT) und auch die Ver­tei­di­ger einen Abschluss­re­port, der in gemein­sa­men 360°-Workshops zusam­men­ge­fasst wird und in einen Maß­nah­men­plan mündet

Für das Insti­tut, das einen Tiber-EU-Test durch­führt, ste­hen sechs Zie­le im Vordergrund.

  • Rea­li­täts­na­he Prü­fung der eige­nen Sicherheit
  • Gewin­nung von Erkennt­nis­sen und Infor­ma­tio­nen zu Schwachstellen
  • Pra­xis­ba­sier­te Ver­an­schau­li­chung der Trag­wei­te von Cyberrisiken
  • Sen­si­bi­li­sie­rung der Geschäftsleitung
  • Erkennt­nis über die Not­wen­dig­keit von Schutzmaßnahmen
  • Ein „Durch­fal­len“ oder Nicht­be­stehen ist nicht möglich

Die Durch­füh­rung eines sol­chen ethi­schen Hacker­an­griffs erfor­dert durch das „ange­grif­fe­ne“ Insti­tut, auch wenn die­ser Angriff expli­zit beauf­tragt wird, vor­be­rei­ten­de und beglei­ten­de Maß­nah­men. Die gewünsch­te Rea­li­täts­nä­he kann zu Beein­träch­ti­gun­gen des rea­len Geschäfts­ab­laufs kom­men, denen sich das Insti­tut bewusst sein muss.

Aus die­sem Grund sind fol­gen­de Aspek­te expli­zit in der Vor­be­rei­tung und Durch­füh­rung zu berücksichtigen:

  • Sorg­fäl­ti­ge Aus­wahl der Dienst­leis­tungs­part­ner für Thre­at Intel­li­gence und Red Team
  • Begren­zung des Scopes und Abstim­mung inner­halb des Insti­tuts sowie mit der Aufsicht.
  • Vor­ab­re­ge­lung des Umgangs mit Daten und deren Auf­be­wah­rung im Fal­le eines erfolg­rei­chen Hackerangriffs
  • Die ver­trag­li­che Situa­ti­on zwi­schen Bank und bestehen­den IT-Dienst­leis­tungs­part­nern ist zu prü­fen, ob sie die Durch­füh­rung eines Tiber-EU-Tests ermöglichen
  • Pro­zes­sua­le Abschät­zung der Risi­ken des Angriffsszenarios
  • Aus­ge­stal­tung der Test­durch­füh­rung in der Form, dass Aus­wir­kun­gen auf­tre­ten­der Ser­vice­be­ein­träch­ti­gun­gen gering blei­ben und durch vor­be­rei­te­te Maß­nah­men zügig beho­ben wer­den können
  • Umgang mit den doku­men­tier­ten Ergeb­nis­sen des Tests im Span­nungs­feld zwi­schen Offen­le­gung und Vertraulichkeit

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als zehn Jah­ren Erfah­rung mit Pro­jek­ten im Kon­text IT-Regu­la­to­rik sichert pra­xis­er­prob­tes Wis­sen. Umfang­rei­che Kennt­nis von Orga­ni­sa­ti­ons­struk­tu­ren, Pro­zes­sen und IT-Sys­te­men deut­scher Ban­ken und Spar­kas­sen gewähr­leis­ten den erfor­der­li­chen fach­li­chen und tech­ni­schen Hintergrund.

Auf die­ser Grund­la­ge unter­stützt ban­kon effi­zi­ent und ziel­ge­rich­tet die Vor­be­rei­tung und Durch­füh­rung von Tiber-EU-Tests von der Ziel­set­zung bis zur Maßnahmenplanung.

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de