Vulnerability and threat assessments are fundamental parts of EU’s Digital Operational Resilience Act (DORA) that aims to ensure financial firms, and the whole sector, resilience ability. In this article, we examine the critical components and define what makes vulnerability and threat management successful.
Know your weaknesses
An analogy to vulnerability and threat management could be the swift emergence of chaos in the sky in the absence of air traffic control towers.
A definition of vulnerability is a weakness, susceptibility or flaw of ICT products or ICT services that can be exploited by a cyber threat or attack. This means that vulnerability management is the process in which threats and vulnerabilities in ICT assets are identified, the risks of these vulnerabilities are evaluated, and mitigation of relevant threats and vulnerabilities are performed according to risk level and appetite. Coming back to the above analogy, if we do not know our weaknesses of threats to the financial firm (or the sector as a whole) how can we ensure the relevant level of protection of the firm and what actions do we need to take?
Responsibilities and timing
The first line of defence needs to perform continuous scans of vulnerabilities. These scans need to be performed on the full technology stack, from networks, operating systems, software libraries, applications, and integrations (application gateways), with an added focus on internet facing/exposed services.
In order to manage the vulnerability and threat scans, a management process needs to be established, preferably based on the NIST cyber security framework, that encompass the following steps:
- Identifies vulnerabilities and threats
- Protects exposed and vulnerable systems and services
- Detects potential exploitation attempts
- Rapid responds to successful exploitations, and recovers after the exploitation has been successfully diverted (part of incident and business continuity management which feeds back into vulnerability and threat management)
Consequently, the vulnerability and threat management ability need to transcend the detection phase and be managed by process with adequate resources (financial and personnel). Furthermore, the vulnerability and threat management process ought to be monitored by the second line of defence where efficiency and effectiveness are evaluated. In this process metrics are collected to analyse trends in the risk exposure of the firm and to measure the vulnerability ability compared to the risk appetite as defined by the Board of Directors. It is advantageous to automate, within reason, as much of the vulnerability and threat management process as possible.
Vulnerability and threat management is an essential component of the firms overall operational resilience strategy where the information should lead to old or unsecure ICT components being exchanged to more modern and secure versions. This, in turn has the potential to lead to efficiency gains as old services are transformed to new and more secure services.
“Shift left” leads the way
Where does the vulnerability and threat management process come into operations of the financial firms? In the Continuous Integration/Continuous Delivery process (CI/CD) there is a trend in the SecDevOps teams to “shift left”. This means that vulnerability and threat management deliver the best value as early in the process as possible. To elaborate, vulnerability and threat management should be part of the Brainstorm and Design phase (as part of a risk or security engineering principle) and scans performed during development, QA and deploy phase. The fundamental shift is to perform vulnerability and threat assessments at an early stage in the development process, and not only when services are in operations.
Outsourcing?
Things are however a little more complex in the modern ICT environments of today, where dependability of third-party providers come into the equation. Financial firms need to very clearly and consistent define requirements on the third-party provider’s vulnerability and threat management process to ensure a successful interoperability. Preferably the integration should be automated (thereby not requiring the same underlaying systems for the vulnerability assessments) and the results of the scans should be integrated based on a common taxonomy and risk scales. This requires work and clear requirements from the financial firm on the third-party provider. Further, proactive monitoring of the third-party providers continuous delivery of vulnerability data is required. Otherwise, the “air traffic control tower” is rendered pointless.
The vulnerability and threat management process mentioned above ought to be automated as far as conceivable. This hold true for most of the phases of the process, however the analysis of vulnerabilities and threats need in some parts be qualitative as some threats are more serious than other and the need for additional resources to manage serious and novel risks could be needed. Therefore, an escalation routine could be utilized to elevate serious and novel risks to incidents if the vulnerabilities or threats cannot be managed by the ordinary process. Further to the automation discussion, virtual patching and other techniques is recommended to be used in order to quickly manage identified vulnerabilities. This leads to a risk of “Sword of Damocles” as virtual patching could lead to limitations of services, which further strengthens the argument for qualitative assessments by the SecDevOps team. The internal change and incident management processes should also provide information directly to the SecDevOps to continuous change the vulnerability and threat management ability to best suit the firm.
Conclusion
The goals of this article are to introduce threat and vulnerability management, present the process governing threat and vulnerability management, and from a high level present the shifts in the market regarding proactive management (i.e., Shift-left) and towards third-party providers. In conclusion, a firm’s threat and vulnerability management is a vital part of achieving digital operational resilience and should hence be thoroughly incorporated in firms’ ICT operational resilience strategies.
Advisense help you navigate
We are committed to delivering in-depth expertise and pro-active advice to our clients. Our teams have assisted numerous financial service entities adhering to the EBA, EIOPA ICT and security risk management regulations and prepared for the introduction of DORA. Furthermore, we have assisted third-party providers with DORA adoptions. We believe that if the financial institutions adhere to the EBA or EIOPA regulation, a lot of work towards DORA adherence has already been made, but adjustments will be needed once the final DORA text will be made public. However, for the firms that are not under the EBA or EIOPA regulation, significant efforts will have to be made to comply with DORA.
Read more about DORA here.
Want to find out how Advisense can help you?