Operational Resilience now mandated for EU Financial Institutions
The safety and resilience of financial and credit institutions will soon be enforced by the Digital Operational Resilience Act and applicable to any of the relevant institutions doing business in the European Union.
With the deadline less than a year away (enforcement begins on 17th January 2025), enterprises need a clear path to compliance that they can implement and maintain.
DORA outlines five critical areas where organizations must adhere to technical specifications:
The overarching goal is to maintain the resilience of the financial system as a whole, minimizing disruption, and downtime, and ensuring business continuity.
What does this mean for the IT network, in the context of large enterprises? Here's three things to keep in mind as you prepare for DORA.
This regulation will bring renewed focus to identifying and classifying your critical business functions. In DORA, with respect to the financial industry, these are defined as areas where "the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity." (DORA Article 3).
Ultimately, a key goal of DORA is business continuity. While it may seem very clear to network operators how critical continued network services are to the health and success of the business, in the context of a large organization, business leaders may not understand just how reliant their business is on the operational resilience of the network. A network compliance issue can be the first domino in costly, reputation-damaging business interruptions.
They don't know the scale of change (planned, and unplanned) network operators are managing day to day; they don't understand the complexity of dealing with different technologies and vendors, to satisfy ever-changing business operations; they don't understand that securing a network against a growing threat landscape is a continuous activity.
That said, as DORA compliance escalates to top priority - there are, after all, criminal penalties for non-compliance (DORA Article 52) - the network will take the spotlight as key to understand, visualize, and report on.
This fresh attention to what might have been previously relegated to "plumbing" or a cost center in the minds of leadership will unlock resources network engineers have been desperately needing for years, but also scrutiny. And let's be clear, the first question will be "Where's your network documentation?"
This leads us to point 2...
The regulations put forth in DORA make it clear that it's not enough to assume compliance - financial entities have a burden of proof, and must (both internally, and externally) continuously validate their compliance.
Exactly what this proof will look like might differ by organization (there is also a proportionality principle to note within DORA), but it includes, for example:
All this proof must be reported in the manner, and through the mechanisms specific in Pillar 2 - ICT-related incident management, classification, and reporting - and the Regulatory Technical Standards that will specify the harmonization and centralization of DORA compliance reporting.
That said, the appointed overseers and responsible parties might not be networking experts, so raw network data won't be of much use. Which brings us to point 3...
A lot of DORA is principles-based; not necessarily specifying exact policies or technologies to implement, but more so about having the right people, planning, and frameworks in place to provide continuous oversight.
It's key to note that there's a lot that must be communicated to business leaders, clients, and stakeholders in the event of an ICT-related incident, for example "to relevant senior management and inform the management body of at least major ICT-related incidents, explaining the impact, response and additional controls to be established as a result" and to "clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident" (Article 17).
It's easy to imagine, then, in the event of a network-based ICT-related incident, that there is specific and complicated network information that must be made available and consumable for the above-mentioned parties.
These are just three threads to pull at as DORA crystallizes into clear specifications for financial entities and the IT networks that underpin them. As the scramble to assure and prove compliance starts, we'll keep an eye on the challenges and themes emerging for network teams.
For now, the best way to prepare is to ensure that your team has a comprehensive and accurate network understanding; an accurate inventory; clear and complete documentation; a mechanism to visualize the network and its interconnections and dependencies; and a realistic and feasible way to keep this all up-to-date and therefore, useful.
For more information on IP Fabric's network assurance platform, reach out to the team or try our self-guided online demo.
Open Telemetry (OTel) is a networking protocol that has been under development for four years and recently received a boost from F5 Inc. and Service Now. Cited as a protocol that will help advance the cause of observability, it's interesting to see where and how this protocol will develop over the coming months and years.
In the meantime, it got us thinking about network telemetry in general. What exactly is it? Is it related to network monitoring? Most importantly, how does it relate to Network Assurance?
Network telemetry concerns the collection, measurement and analysis of data related to the behavior and performance of the network. Telemetry gathers information on routers, switches, servers and applications to gain insights into how they function, and how data moves through them. To provide an analogy, network telemetry checks the network's pulse to track health and performance.
Hang on a second... This sounds an awful lot like network monitoring. Well, kind of yes.
Both monitoring and telemetry platforms provide information on network health and performance in real- (or near real-) time.
Monitoring is a broader term that encompasses the overall observation of a network's performance, health and activity through pre-defined parameters, whereas telemetry refers to a more automated and continuous data collection process on more granular data like packet loss and latency.
The data collected by both monitoring and telemetry platforms is essentially the same, with the main distinction being that telemetry focuses on more granular details and data. Another difference is in how the data is presented in their respective platforms.
Network monitoring relies on a process called "polling" - a process where monitoring tools request data from network devices. This can unfortunately lead to visibility blind spots, specifically when issues occur during polling phases, as such issues can go undetected during this process.
Furthermore, polling can potentially disrupt activity in the resource being monitored. For example, a router passing traffic along an end-to-end path. When running a query asking for 1000 data points from said router, each request and data point is queried and extracted INDIVIDUALLY, with 1000 responses being sent from the router in return. This is clearly an inefficient process.
Inefficient, especially when you add in the fact that querying a resource creates additional traffic within the network path, with the monitoring queries capable of impacting the behavior of the device that data is being gathered from. Back to our example - querying the router requires it to stop it's current activity of passing traffic to respond to the monitoring queries. They can't multi-task as well as some of us.
Network telemetry, conversely, does not suffer from this issue. Telemetry focuses on the continuous and real-time collection of network data through streaming, not polling. An engineer simply needs to tell the network device what data they're interested in, and then as the device operates, data is streamed to the telemetry platform. This means there's less chance of impacting the performance of the queried device, as it doesn't have to stop passing traffic to handle management requests - ultimately leading to quicker detection of issues and their resolution.
How does telemetry fit into the concept of network assurance?
When running a monitoring or telemetry platform without network assurance, you need a knowledgeable and experienced engineer to sit down and understand the information presented by these platforms. They have to manually determine what data is important and what to do when it goes over a threshold or boundary that they have set. Without this engineer spending a considerable amount of time setting up these thresholds, a monitoring or telemetry platform will just collect data and send alerts without context - creating alert fatigue for the rest of the engineering team.
Assurance perfectly fits this gap by providing the necessary context that teams need when an alert is sent from a telemetry platform.
Take the example of packet loss or latency. Network telemetry platforms will collect this information and make it available to engineers. Now they know there's an issue. What they don't know, however, is how this packet loss may affect the path or the wider network. With network assurance, teams can develop topologies of their network and data-flow diagrams to identify the end-to-end path that contains the packet loss. Based on this, they can understand the severity of the issue, where it stems from, where it can lead, and most importantly, how they can address it before it develops into a wider issue and begins to affect performance in other devices.
To adapt the phrase we used in our previous article on IP Fabric and Centreon - telemetry goes wide, and assurance goes deep.
