Resilience in cryptocurrencies; or why DORA should be applied to centralised exchanges
TL;DR A new technology which advances resiliency through its decentralised structure and written in modern memory safe languages should have no problem meeting new regulations aimed at protecting consumers from cyber attacks and unavailability of services, right? Recent attacks in the cryptocurrency ecosystem have shown this is not the case at centralised exchanges which are an unhappy compromise between AML obligations and networks of decentralised, tradeable, digital assets. Customers have seen locked accounts, an inability to move funds to safety and little communication about the return of services even when the attack hasnt been a rugpull. This is the first of a series of articles that looks at what DORA is and how centralised exchanges can implement it.
A Breakdown Of The DORA Regulation
The European Commissions Digital Operational Resilience for the financial sector (DORA) regulation is aimed at improving the resilience of financial market infrastructure including those based on distributed ledger technologies (DLT’s). Given the rapid uptake of digitalisation in other industries, there is special focus within the EC on digital assets and DLT market infrastructure as they are seen as the future of the financial industry. Country by country throughout the EU there are differing standards of resiliency and DORA is an initiative to have one standard to address all systemic risk within the industry.
So what is resiliency? The regulation defines operational resiliency as being the ability to “ build, assure, and review operational integrity.” The NIST definition is broader in scope, and more importantly, includes in it the ability to “anticipate, withstand, recover from and adapt to adverse conditions, stresses, attacks or compromises…”
The reason for its importance is the emphasis on anticipating attacks; in the analogy of boxing, it means accepting getting hit as a foregone conclusion, knowing how to properly defend the important assets (defend your head with your hands, elbows cover the core) and developing strategies to get yourself off the ropes and out of trouble (especially if you’ve fallen for a sucker punch to the stomach and left your head exposed). However, the key principles underpinning DORA resonate with NIST’s definition and are similar to those for incident response, particularly as anticipating an attack starts with understanding what needs protected in the cycle of:
- identification,
- prevention and protection,
- detection,
- response and recovery,
- learning,
- evolving and communication.
The regulation gives an idea of scope and applicability. Crypto asset service providers, issuers and issuers of asset referenced tokens are expressly specified in the regulation. Interestingly, so are data reporting service providers and ICT third party service providers. Given the growing importance of making on-chain data accessible off-chain, this does not seem to be an unreasonable demand. However, staking costs and now increased regulation may push up transaction processing fees and lead to further centralisation in the market.
The theme that appears in nearly every other security standard but that most organisations get wrong is repeated — it is the management board who are responsible for resilience and not the IT department. Only the board can make budgets, training and people available, define strategies and set priorities. Once again this emphasises that the management board is expected to take an active role in risk management and ICT security strategy; assign clear roles and responsibilities for ICT related functions and there should be continuous engagement in monitoring risk management. Such is the importance of resilience that it is suggested that there be a dedicated management function responsible for it. This function would lead and govern:
- the establishment of complex governance arrangements for resiliency,
- the performance of indepth assessments after major changes in network, information system infrastructure etc,
- the organisation of regular risk assessments against legacy IT,
- the expansion of business continuity testing, the development of response and recovery plans to capture switchover plans from primary ICT to redundant facilities,
- the testing of digital resilience and advanced threat-led pentests. The requirement is for periodic testing of preparedness, identification of weaknesses, deficiencies or gaps, and prompt implementation of corrective measures. Testing should also include legacy ICT tools and systems.
As a part of active risk management, the board should drive the minimisation of ICT risk; continuously identifying sources of ICT risk, promptly detecting anomalies, and develop and put in place business continuity policies and recovery plans. These measures will limit the damage caused by an attack and prioritise the safe resumption of activities.
In previous regulatory technical standards, the EBA has described the importance of managing third party providers. TPP management is also important for resilience. Organisations need to understand how TPP ICT risk affects them and the impact from any incident is the responsibility of the outsourcing organisation and not the third party. TPP management is of the whole engagement lifecycle; from contract conclusion, performance assessment, termination and post-contractual stages.
The following articles will look at how to adopt resiliency practices from a technical and governance level.
