Release #5: Regulatory Requirements and Cyber Defense
Basics
The financial sector is extensively regulated at international and national level. Industry standards such as PCI-DSS and SWIFT CSCF (Customer Security Controls Framework) play just as much a role as ISO 27001, EU-GDPR (General Data Protection Regulation), or national laws such as IT-SiG (IT-Sicherheitsgesetz), KWG (Kreditwesengesetz) in Germany (which is based on Basel I and Basel II and is specified with the MaRisk (Mindestanforderung an das Risikomanagement) and BAIT (Bankenaufsichtliche Anforderungen an die IT) requirements).
No news so far and I risk that you my reader will fall asleep. But wake up, the point is, that this different requirements need to be put under one hat and they have to be useful on an operational level in a easy manner. This is the big task for the 2nd Line-of-Defense (2LoD) in this game.
Therefore I will briefly present a methodology to tame all the major and well-known regulations and the minimum measurements that should be implemented at the 1st Line-of-Defense (1LoD) or 2nd Line-of-Defenes (2LoD). This part can only serve as a guide and is neither complete nor free from errors. Standards change over time and the tasks and goals of a CDC can be quite different, as well as your infrastrucuture. There is no way around reading the papers yourselve and define an individual implementation for your organisation.
| Info Box | The Three Lines of Defense Model |
|---|---|
| ! | A common control concept is the "Three Lines of Defense" (TLoF, 3LoD). Simplified, the responsibilities in the TLoD model are divided as follows
|
Today, companies are increasingly called upon to strengthen transparency to create trust in their activities. The fulcrum is adequate risk management and reporting, which is also required by the German legislator and regulated by the KonTrag act.
In order to be able to comply with all regulations, it is important that the Information Security Management (ISM) selects a Security Program Framework as the basis for its Information Security Management System (ISMS), that is internationally recognized and that many other standards can be mapped to. For example ISO 27001 or the NIST Cybersecurity Framework (CSF, with the phases Identify, Protect, Detect, Respond, Recover) is considered as a program framework. In my opinion ISO 27001 together with the NIST Special Publications (SP) 800-53 as a control framework is a good combination for companies doing international business, or optionally ISO with the BSI IT basic protection catalogues if your main business and organisational focus is in Germany. Don't make it overly complicated, it should make your life easier. The matrix of security controls, mapped to an ISMS porgram framework can then be used as input to the enterprise risk management system. Please don't mix it up with Information (or IT) Risk Management (IRM) which is just a tool for a part of information security and risk management.
As soon as all requirements from SWIFT CSCF, PCI-DSS, BAIT, and GDPR have been mapped to the corresponding NIST (or whatever you like) controls and to ISO 27001, the ISMS can be set up and implemented. Regular testing (vulnerability scans, security compliance scans, penetration testing and such) should make sure you know the gap between ISMS policies and the real IT world, and that this gap is handled correctly and in time.
A mapping many (if not all) all common control frameworks to the CIS controls can be found here: https://www.auditscripts.com/free-resources/critical-security-controls/
Even if these tasks have been well implemented by the 2LoD, a CDC will still recognize in detail the gaps in the operational implementation (1LoD) of the ISMS, and that is exactly what a CDC is there for. Psst, communication and a good relationship between the 1st and the 2nd line is the key for success here.
Ok, know we know our external and internal requirements, know how they fit to a security program framework and how to feet the ERM, this is reat to avoid issues during an audit but how do we make things happen in an organization? Correct! Policies! Let's dive deeper into the "house of policies" every decent organisation should have.
Written policies, operating procedures, and processes
During an audit attention is always paid to whether a department and its tasks fit into the “written order” (wO) and policies of a company. It makes sense to set up the wO as a pyramid or "house of policies" , from the top of an abstract regulation from the management to the detailed procedure at the operational level. (The topic of procedures and processes will be examined in more detail in a dedicated blog on the CDC architecture.)
Example:
|
Document |
Author |
Legitimization |
|
Structure, roles, responsibility of the ISMS organisation. And a high-level security policy with a business alignment |
CISO |
Signed and approved by the CEO and other members of the C-Level leadership team. |
|
General requirements for state-of-the-art handling of security topics like logging, system hardening, and so on. Maybe based on ISO 27k or BSI IT base protection. |
ISM department/team or the CISO together with the accountable owners of the corresonding business processes. |
ligitimized by the high-level secrurity policy |
|
Operational implementation of the security requirements from a level above. |
Department which ownes the operational process, maybe with support of a security architect, the ISM team or the CISO. |
required by the organisational security ploicies for general security requirements. |
At the operational level you should be free to define further levels down to processes, roles and such.
Risk management
What needs to be monitored?
In a CDC, one question always arises at the beginning: What needs to be monitored?
At most companies, a "best practice" approach is enough to get started and get the first experiences. However, in a highly regulated environment with internal and external audits, this approach is doomed to failure because it is decoupled from risk management. If an auditer notices that you have implemented a right measure, out of the belly, he will not accept it and instead assume it was by luck.
The question about what to monitor can be answered by approaching the problem on two levels.
- What are the assets with the highest protection requirements? Risk management can help with the response. When asked why the limit was drawn at a certain level of protection and not elsewhere, one should have a plausible answer. For example, a company could have 4 levels of protection requirements and they only want to look at the systems and data of level 4 (very high) and 3 (high), then you should be sure that only here are the "crown jewels" (bank data, personal data, databases for access and monitoring systems, etc.) of the company. The basis for this is a clean, consistent and up-to-date information security and risk management and an IT infrastructure that reflects this through identity and access management as well as network separation, etc.
- If you know what attack pattern to monitor, you need to clearly define why you want to detect certain attacks with your SIEM and why others not. This part is quite interesting, because here the seed (inital process) is sown for many - if not all - further processes in the CDC, but more on that later. You should make sure that you do not limit yourself unintentionally here. The following sources can serve as a basis for the development and use of SIEM use cases:
- Mitre ATT&CK Matrix (https://attack.mitre.org/), here you can use the "Navigator" (https://mitre-attack.github.io/attack-navigator/enterprise/) to limit the TTPs (Tactics, Techniques and Procedures) to attacker groups in the financial world.
- Insights from Threat Intelligence. If there are any particular threats to your business, they should also be included in the monitoring process.
- Controls, e.g. from NIST SP 800-53 or BSI IT basic protection
Open flanks (incomplete preventive measures) in the network infrastructure, system architecture or application landscape. For example, if it is not possible to block certain TCP ports at the firewall, then detection by intrusion detection systems or web application firewalls should be implemented and the alarms should be sent to the CDC.
For the sake of completeness I want to shortly describe the three different ways to collect data which are a less distinctive than the method described above, but still helpful.
- Input-driven: Collect everything you can get and see what can be made out of it. Contra: Collect too much, waste storage space and money. (SIEM solutions often have a license model based on GB of log data. Pro: Have many data for additional and manual investigations.
- Output-driven:
Know what alarms you want to generate and collect the needed data.
Contra: Data may be missing for e-forensic. Pro: Safe storage and money.
- Hybrid: Collect the data you need for detecting specific attacks (like the output-driven approach) and all log-data from critical or exposed systems. Contra: See decision process above for monitoring.
Regulations and their implementation in the CDC
In the upcoming blogs will describe the individual regulations and their significance for a CDC (shown as an example).
For the IT of the banks, BaFin published the so-called BAIT with release 10/2017 (BA) in order to offer further details to MaRisk and the finance sector.
For the insurance industry, a complementary release (VAIT) was published exactly 1 year later.
In the case of a special
audit (44er Sonderprüfung) by the BaFin (supervisor) and the Deutsche Bundesbank (part of the European System of Central Banks), at least the requirements of
MaRisk and the common set of best practices are examined.
Now an institution can try to transfer the problem to a service provider and outsource critical processes. In this case the institution is still accountable for the correct execution of the outsourced process and has to establish the proper contracts with audit rights and has to proof an adequate service provider management. Service providers and their clients (i.e. a bank) should define their responsibilities and the instruments of service provider management precisely, so as not to experience an unpleasant surprise during an audit.
Beside regular onsite audits, the processes need to be connected and harmonized. Let's assume the outsourcer already has an internal incident response process in department A and another department B which is responsible for collecting logs and for the administration of the computer system but the detection process is outsourced to a Cyber Defense MSSP. In this case the outsourcer has to connect the internal and external processes and train them.
Other important
standards that should be adhered to are certainly ISO 27001, some NIST
Special Publications (SPs) or the IT basic protection catalogues of the BSI. No matter what, but internationally respected or well-known standards are the way to go, and the auditor should see the storyline of your management system and IT architecture .
Ok, that's it basically. :-)
Best,
Thomas
