Release #6: German finance OpSec against Kim Jong-Un and Chinese Casinos (MaRisk and BAIT requirements)

 (Source: Wikipedia)

 

The Basel Committee on Banking Supervision has drawn up the requirements Basel I to III, which have been implemented at national level in Germany by the Banking Act[1] (KWG). The KWG serves market regulation and market organisation in the banking sector by considering various types of risks and by introducing a notification and information obligation. In the banking environment the so-called "44er audit" ("44er Prüfung") describes the general obligation of an institution to provide information to the auditor, as defined in section 44 (1). Operational risk (BTR 4) is of particular interest for the purposes of this book, as it has been specified – more precisely section 25a and 25b – by the minimum risk management requirements (MaRisk).

This all sounds very formal and like a lot of paperwork but it has a serious background. The ties between rogue nations, cybercrime and traditional crime are very close. Let's use North Korea as an example because they are very special. They need to get around sanctions to transfer money (mostly in USD), and to bribe people outside of the DRPK to sell them forbidden goods, like technology for building nuclear plants. To not make the money transfer suspicous in the world-wide banking system, they create "shell" companies, work together with other rogue nations or malicious banks, and so on. Beside hiding the involvement of North Korea in this money transactions there is also the need to do money laundering to "clean" money they "earned" from criminal activities. If you want to know more, read:

• https://www.justice.gov/opa/pr/three-north-korean-military-hackers-indicted-wide-ranging-scheme-commit-cyberattacks-and

• https://www.nbcnews.com/news/world/secret-documents-show-how-north-korea-launders-money-through-u-n1240329

• https://www.icij.org/investigations/fincen-files/

This means, cybercrime is just a "tool" to get (virtual) money (hack of bitcoin exchanges, SWIFT systems, etc) and then the DRPK needs to "clean" it, maybe with the help of chinese casinos, money mules in south america, and such, and then find ways to spend the "cleaned" money again for buying sanctioned goods.

For a bank this means two things:

1. Have a rigerous compliance management system to avoid and detect corruption of insiders, as well as check your customers, and validate money transfers. This is the traditional non-cyber world. Many organisational actions are required to stop being the "middle man".

2. And secondly, to stop all serious cyberattacks so your bank will not be the source of the money, means: get robbed. Are there still people out there stealing money from banks physically?
   

For you as a person responsible for cybersecurity this means to not focus on the cyberattack alone but to put everything in a bigger context. Cybersecurity is not about technology it is about risk and chances, or about someone losing money (risk) and another one is gaining the money (chance - or robbery in our case). So, let's come back to MaRisk...

 

The MaRisk is an administrative instruction of the Federal Financial Supervisory Authority (BaFin), which is published in a circular. The aim of the "MaRisk (BA)" is to minimize risk in credit and financial services. For this, trade transactions are considered which are concluded in their own name or for their own account.

• Money market business,

• Securities business,

• Foreign exchange business,

• Business in tradable receivables,

• Business in goods or

• Business in derivatives

The requirements are divided into a general part (module AT) and a special part (module BT).

For banking IT, there is another specificity, the "Supervisory Requirements for IT in Financial Institutions" (BAIT), which is also published by the BaFin[2]. It also includes a Critical Infrastructure module.
 

The blog post is based on MaRisk "Circular 09/2017 (BA)" and BAIT "Circular 10/2017 (BA)", the English version.

Let's take a closer look at a few selected sections of these requirements and connect them with the goals, responsibilities, and tasks of a CDC. It is assumed that an ISMS, risk management, corporate audit, and business continuity management (BCM) exists and is fully functional.

 

This table is NEITHER COMPLETE NOR FLAWLESS.

 

Requirement MaRisk with the concretizations from BAIT[6]	Implementation in/with a CDC / 1LoD
AT 4.3.1 Organisational and operational structure	Basically this requirement asks for: process design roles separation of duties "need to know" principle regular review of roles, privileges, etc Depending on the tasks for an CDC, there will be different processes and associated roles, which should not only be implemented organizationally, but also technically using digital workflows, an IAM system, and regular review process. Certain administrative and monitoring roles should not be united into one person, e.g. an analyst should not be an administrator in the SIEM, because this would allow him to cover his own tracks if she is an internal offender. Or SIEM rules, should be developed, tested, and approved by thre different people. Furthermore, an analyst should not be able to view the documentation of a security incident if her/his user ID appears as part of the incident. The 1LoD CDC setup and the 2LoD policies need to be verified regularly by the corporate audit department to complete the internal control system.
AT 4.3.2 Risk management and risk control processes	The risk management process is often relatively theoretical and relies on expert knowledge. More advanced automated risk assessment systems can anylze KPIs from ERP or finance systems to see upcoming (business) threats before they happen. A CDC can play an important role here. If the security analysts see a change in the cyber threat landscape, or knowing of critical vulnerabilities in the IT infrastructure, it should be reported to the risk assessment or corporate audit people of the company.
AT 4.3.3 Stress tests	Do you know if your complex cyber defense machinery runs flawlessly or how it will behave under pressure? No you don't. You can only do sample test the obvious risk factors (classical stress test) on an organisational, technical and skill level. Areas of interest are: organizational interfaces between operational units (do table-top tests here) technical interfaces between different IT system (automated stress tests, load tests and logical tests) SIEM/EDR/AV rules, run automated attacks to see if the SIEM/EDR/AV catches what it should catch skill level of the CDC and other teams, can be tested with "war gaming" and red team tests team interaction, roles, and organization can also be with simulated atacks like "war gaming" business continuity tests  ... I like the idea to split the CDC team up randomly to create a red and a  blue team every month and that the red team tries to hack their CDC team mates. This way the red team gets more knowledge of their own infrastructure and the blue team has a chance to fix the holes in their defense before it gets exploited. A successful defense is only effectively possible if the defenders know the peculiarities of their own environment (e.g. which network connections exist and lead to critical systems, possibly even past existing protection systems, which systems are notoriously unpatched/obsolete, etc.), and it gives the CDC team the strategic and tactical advantage of knowing possible actions of attackers already and thus not being surprised, and in case of incident handling, an analyst can limit himself to the real hypotheses and exclude the attack vectors that are not possible. In addition to the technical and strategic aspects, the opportunity can be used to test reporting channels, possibly also public communication with the PR department and official reporting channels, which result from regulations and laws such as IT-SiG/Kritis, data protection, PSD2, PCI DSS, SWIFT, etc. MaRisk emphasis an "inverse stress test", which is like an attack tree where you start from the disaster/successful attack and work your way backward to the risk factors. In Germany the TIBER-DE purple team testing was successfully and practically started in 2020. This is definitely the "big thing" for banks and especially for their IT and CDC at the moment. If your CDC people know their adversaries and know how to detect a pen-test, they will be very likely able to detect the TIBER red-team in action.
AT 4.3.4 Data management, data quality and aggregation of risk data	This requirement might look a bit vain at the first glance but take care. The data they are talking here about is: log data, alarms, incident analysis process data, your ticketing system, your Playbooks and such. Make sure the event and it origin can be traced through all your systems uniquely, without holes, forth and back (a bijective relation). The same applies to threat intelligence data; if there is a new threat it must be clear what action resulted from it, like the implementation of a SIEM use-case.
AT 5 Policies	The organization should have a document pyramid or "house of policies" that, as a binding work of instructions, is the company's structure of business process guidelines ("Ablauforganisation", operational structure). An example is a top-level information security policy, which leads further down to various info-sec policies, e.g. in accordance with the ISO 27001 controls. This can be used as an instruction for central logging and evaluation at the organisational bottom and thus for the CDC. Another tree structure should be built underneath that bottom, which reflects all documents and processes generated in the CDC, like the basement. Policies are mostly written by the 2LoD and should cover all external and internal requirements, they need to be complete and a process should exist to regular update them and to feed them with new requirements.
AT 6 Documentation	All documentation in the CDC should written in a way that it is complete and comprehensive, even 5 years later. This also means that all related documentation has to be kept for 5 years or longer.
AT 7.1 Personal	As CDC manager you must always put emphasis on continuous training for your staff and take care of the work load. An analyst should only be at a 60% work load to give her the time to learn new stuff, be vigilant, and be available in case of an emergency. This is OFTEN NOT the case unfortunately because many managers think they have to get the max revenue out of these expensive personal without understanding that they are firefighters and not assembly line workers! This is especially true for MSSPs.
AT 7.2 Technical-organizational equipment	The equipment must be state of the art and able to handle the amount of workload as well as risk of the institution. Think about SIEM storage, EDR, automatic response, and such.
AT 7.3 Contingency plan	Especially in emergency and outage situations, IT is particularly unprotected for attacks (or failure is even the result of an attack), because security measures have failed in whole or in part and the organization's attention is focused on restoring availability. The CDC should also be able to carry out its tasks in such extreme situations, and monitoring by the SIEM is particularly important. The selection and construction of the SIEM infrastructure should be designed for high availability and should be part of the Business Continuity Management system. All support and downstream systems must also be included. It is advisable to print and keep up-to-date work instructions, playbooks, SOPs, the communication matrix and so on offsite. The CDC and all related systems used must become part of the regular emergency exercises. All this is EXPENSIVE!
...	... there is much more to take care of, especially for the 2LoD and the 3LoD ...

 

[1] http://www.gesetze-im-internet.de/kredwg/index.html 

[2]Circular 10/2017 (BA) - BAIT: https://www.bafin.de/SharedDocs/Downloads/EN/Rundschreiben/dl_rs_1710_ba_BAIT_en.html