Guest Contribution : Kristian Alsing
The next NIS-D directive is live in a second iteration and regulators of Critical National Infrastructure (CNI) across Europe are working to evaluate and adapt the directive to country specific regulations. Thus, the UK (through the Department of Culture Media & Sport) have issued their consultation outcome for regulation of managed service providers and updates to the NIS regulation. The original NIS-D went a long way to uplifting EU nations’ focus on cyber resilience in CNI. Not only did NIS-D introduce the threat of fines of up to 2% of revenue, it also went a big step towards defining CNI organizations (i.e. Operators of Essential Services or OES’ for short) and industries in the EU. Lastly, it attempted to standardize mandatory reporting of cyber incidents through the definition of certain key measures around reporting, a national CSIRT and more.
The regulation (as based on the EU Directive) came into force in the UK in 2018. The Ministry of Energy and Industrial Strategy (BEIS), jointly with OFGEM, was deemed a Competent Authority (CA) for downstream energy and gas. BEIS was likewise the CA for upstream and downstream oil and gas storage/processing. In these cases HSE was responsible for compliance functions.
This article will not attempt to cover the whole new Directive (referred to as NIS2), but rather bring out specific areas for OES’ to focus on.
Why a new directive?
Unfortunately for NIS-D there were some challenges. For instance, the definitions of industries in scope was not particularly specific, leading to broad variations across member states. A number of new industries have been included as part of NIS2, including for instance postal services, cloud providers and more as well as certain micro entities such as top level domain providers. Also, reporting guidelines were interpreted with great differences across member states. In the UK, reporting was only mandatory if an actual disruption happened to an “essential service”, meaning that attacks that didn’t impact provisioning of the end utilities, such as water or electricity, went unreported. For instance, the reporting threshold for electricity distribution required 50,000 customers to be without electricity for more than three minutes. Due to the high thresholds in NIS-D it would be expected that a vast majority of attacks would go unreported, meaning a major gap in visibility of a variety of attacks.
Reporting of high impact attacks and near misses
NIS2 puts more responsibility on the corporate C-Level and increases the pace at which incidents need to be reported. Having said that, potentially the biggest change suggested by NIS2 is moving away from voluntary reporting in cases of potential or risk of adverse effects to essential services. This is a very significant change as it will:
a. Make it very clear to the regulators and thus government, the malicious activity from often very advanced threat actors, which stops shorts of having a “a significant adverse impact on the essential service”provided by the OES.
b. Invariably elevate the C-level focus on cyber security and resilience due to the profile of regulator engagement (and thus breach notifications).
In Critical National Infrastructure (CNI) you are fundamentally protecting against nation state attacks, which means you need to be prepared for “sleeper attacks”. If you’re only reporting on attacks that have taken out 1000s of households on a specific utility, you’ll never need to report to the authorities such a “destructive attack-in-waiting”, even if you do happen to discover it.
The same goes for more opportunistic attacks by organized crime groups or even “script kiddies”. The new reporting guidelines are a big step towards addressing the visibility/reporting gap of the qualified near-miss or sleeper attacks, but it is still unclear how these “high risk attacks” would be defined.
Checkov’s gun
Checkov once said “once a gun is introduced into a play, it has to be fired”. Once you start reporting your near misses, there’s no avoiding analyzing your causes and potential effects. Because it’s regulatory, there’s no way of hiding this discussion at the mid-management level either. The one factor that is often missed around such reporting, is the sheer complexity of our CNI organizations. Some can have thousands of sites, extensive legacy challenges, unpatched and badly documented technology and a general lack of investment in security.
Basically, having to report on potentially devastating attacks will bring such challenges to the attention of the executives responsible. I have long advocated for hands-on assurance as part of regulation. Where you have a requirement to do stringent testing, such as red teaming, self-reporting is reduced as a source of error. Stringent testing will expose any kind of “optimism bias”. Reporting of near misses for CNI should have a similar effect, albeit only for the organizations that indeed do experience such attacks.
Third party risk
One of the main initiatives in NIS2 is for regulated industries to identify, not only their core essential services, but also their suppliers who could have a major (adverse) impact on the ability to deliver these. For me, this makes a lot of sense. Some organizations are very dependent on suppliers, such as cloud mega scalers, application development and business/it operations. Also, we’ve seen a significant uplift in the supply chain as an entry point for attackers. You hack one cloud, legal or service provider and you can have direct access to 100s or thousands of customers or indeed their data.
The broadening of NIS-D to include critical suppliers, thus, is welcome, and it will have at least two major implications:
1. Oftentimes, security requirements in critical services would have been less stringent under the existing NID-D regime as the regulations didn’t stipulate parity on the security capabilities of these suppliers. Contracts (and supporting controls) will require an uplift.
2. There will be some obvious commercial implications. If your suppliers are expected to alert you, in near real-time, on a potential attack that could impact an essential service (or their own service, should it be classed as such), they won’t be able to rely on your SOC to do so. They’ll likely need to build a service-focused monitoring and response capability (not to mention all the relevant underlying cyber capabilities such as identity and access management, data security, that may be missing). This could cost a significant amount of money.
3. The challenges around supply chain risk is also one of assurance. How do you actually assure, at the right level, shared services and cloud providers, where the assurance can impact other clients than the regulated entity?
Conclusion and practical steps to get ready
The introduction of NIS2 has significant impacts on a number of OES organizations (as well as expanding the scope to include many new organizations in scope. The member states will be required to include the new directive into local regulations by September 2024 but frankly for many organizations this is far reaching in impact, so I would recommend they start preparing for key elements already now. The main areas of focus, from my point of view, should be; third party risk management and ensuring visibility, ability to detect and capability to respond in the case of a breach.
Recommendations include:
1. Get your response ready by introducing hands-on assurance, such as red teaming (to identify weaknesses in your defenses and test your ability to identify any malicious activity) and at a later stage blue teaming, to exercise your response capability.
2. Get your business response ready. You want your senior leadership, the board, your press office and your operational leaders all ready to act in unison in the case of a breach or high-profile near miss.
3. Review your third party risk management capabilities. For now, make sure you have one and that it follows a meaningful standard, but frankly start evaluating your providers from the actual impact they can have if compromised, but also understand what specific threats they may open you up to. NIST gives a good starting point.
4. Start thinking about your commercial approach. If you’re a service provider, you’ll need to assess any control gaps and also plan how to recover some of the costs. If you’re new in scope of the NIS Directive you need an approach for how to assess and uplift relevant capabilities in line with the relevant assessment framework for NIS (such as the NCSC’s CAF) and likely required controls from NIS2.
About the Author
For more than 20 years Kristian has worked in cyber security and business resilience. He is a business-driven leader, with experience in end-to-end consultative solutioning, delivery & operations. He has worked with security in a variety of highly regulated industry sectors such as public sector, utilities, banking, pharmaceuticals and financial market infrastructures. His experience covers a variety of cyber security domains, such as identity and access management, security operations, infrastructure, cloud and data security. He holds a number of security certifications; a Master’s and Bachelors in Business Studies and a Diploma in BCM. Kristian blogs and speaks on a variety of cyber topics, and he wrote freelance for a Danish Music magazine for 12 years.