By Arun Raghu, Senior Manager, Strategy Implementation Consulting and Professional Services, Trustwave
This blog examines some interesting aspects of the recent reforms to Australia's Security of Critical Infrastructure Act - specifically related to the new risk management obligations that have been introduced. We'll unpack some of the ambiguities that exist and remain to be clarified in this specific area of the reforms.
For some time, protecting critical infrastructure assets from cyber threats has been an area of significant focus across a range of jurisdictions. Helping to facilitate that protection via regulations is not an entirely new concept. The European Union (EU), US and Australia, for example, have all had laws in place covering critical infrastructure security at some level for several years.
However, policymakers continue to grapple with the appropriate role and scope of laws in facilitating critical infrastructure security, particularly in the context of growing concerns about increased targeting of critical infrastructure by cyber attackers. To this end, there have been a number of recent roll-outs – or proposed roll-outs – of new laws in this area across different jurisdictions.
For example, the EU's existing directive on the security of network and information systems (the NIS Directive) – which covers critical infrastructure security - is being reviewed and is subject to a proposal to be replaced by a new version which will include a broader and strengthened set of security requirements. This ruling will potentially be complemented by the Directive for Resilience of Critical Entities[1], which will cover additional obligations for EU member states to enhance the resilience of critical infrastructure entities.
Similarly, the United States signed the Cyber Incident Reporting for Critical Infrastructure Act into law in March 2022. The act requires a range of critical infrastructure entities to report cyber security incidents, such as ransomware attacks, to the US Cybersecurity and Infrastructure Security Agency (CISA).
Australia has also had reforms planned for its Security of Critical Infrastructure Act (SOCI Act), which the country enacted over the last year.
At the outset, we recognize that there has already been significant discussion and coverage in the public domain summarizing the changes to the SOCI Act. It is far from our intent to merely rehash this - so we won't be drilling down into detail on every aspect of the reforms. However, let's briefly set the scene for those who may be visiting this topic for the first time.
The SOCI Act has been in place since July 2018 and it introduced a limited set of obligations for a narrow subset of critical infrastructure entities in the gas, electrical, water and port sectors. These obligations principally covered the reporting of ownership and operational information for inclusion in a central register, governmental information gathering powers, and a ministerial directions power.
Since the passing of the original SOCI Act, concerns around the security of critical infrastructure assets have continued to grow with little sign of abatement. For example, a report by the Australian Cyber Security Centre (ACSC) revealed that approximately a quarter of reported incidents in the 2020-21 financial year were associated with Australian critical infrastructure or essential services[2].
In response to these concerns, the SOCI Act has recently – and after much debate - been amended in two tranches to create a more robust and expanded set of obligations. The first amendments were introduced in December 2021[3], and the second set came into effect in April 2022[4].
In summary, the reforms:
The Cyber and Infrastructure Security Centre (part of the Department of Home Affairs) has provided more detail on each aspect of these reforms in various fact sheets available here.
Part 2A of the amended SOCI Act introduces a range of risk management program obligations and it is these we'll drill into a bit more. At a high level, these obligations require critical infrastructure assets (for which the obligations are switched on) to implement and follow a written risk management program. Responsible entities to whom the obligations apply must:
These obligations will be provided with additional specificity via a set of Risk Management Program Rules[9]. A draft of these rules – including the assets they would initially govern[10] – has been provided on the Department of Home Affairs website. However, it seems the latest version is actually contained in a submission by the Department to a parliamentary committee created to review the reforms before they came into effect. In addition, the risk management program obligations will include a grace period – at this stage, at least six months – from the rules commencing till compliance is required.
A 28-day industry consultation process will need to occur before the rules become official, so there is a good chance some changes will occur. Nevertheless, the contents of the regulations as they currently stand provide some indication of the current thinking of policymakers and provide a useful framework for discussion.
The rules are largely principles-based and centered around four key areas of potential hazards for critical infrastructure assets:
Looking closely at the rules as they currently stand, it is apparent a range of areas will need to be clarified as part of the consultation process – particularly with respect to the cyber and supply chain aspects of the rules and their potential ramifications for businesses across the economy.
In the remainder of this article, we'll note our observations about these aspects of the current draft of the rules. That is not to say there are not also issues with the physical and personnel hazards aspects of the rules, which might need clarification too – we may revisit these in a future article.
Minimizing or eliminating material risks related to cyber hazards is a critical element of the rules. As part of this, entities to whom the rules apply would separately have an 18-month grace period to comply with one of the following security standards/frameworks (separate from the grace period of six months that applies to the risk management program obligations overall):
Alternatively, entities can choose to comply with a framework that is 'equivalent' to one of those listed above. First, let's consider some implications of the framework compliance requirement.
Taking the inch-wide, mile-deep approach, or going for the well-rounded security program?
Some entities to whom the obligations apply may already have a security program that complies with a listed framework. For others starting from a lower base, however, the choice of framework to meet this requirement may prove challenging.
Frameworks such as the NIST CSF and ISO 27001 are comprehensive in terms of security domain coverage but limited in terms of implementation details for the controls they contain. Conversely, the Essential 8 Maturity Model is focused on the eight most fundamental strategies to provide the most effective baseline in protecting against a security compromise – and provides detailed implementation guidance via a series of maturity levels - but is not intended to provide the basis for creating a comprehensive and holistic security program within an organization.
Given there is an 18-month period to comply, critical infrastructure entities will need to carefully consider whether they are best adopting the 'inch wide, mile deep' approach of a framework like the Essential 8, or favoring a more holistic one like the NIST CSF or ISO 27001. In this context, it's also important to remember that an effective risk management program will not just be about identifying cyber risks – but also implementing controls to address them. Undertaking all of this within 18 months across a wide range of security domains for entities commencing from a standing start is likely to be a significant challenge.
What does 'compliance' mean?
The concept of 'compliance' does not appear to be currently defined in the rules. If an organization subject to the obligations chooses ISO 27001 as their preferred framework (for example), does this mean they need to achieve certification of relevant assets – or their entire business operation – within 18 months? Naturally, this would be a challenging task for those organizations starting from a relatively low baseline regarding security.
Conversely, frameworks such as the NIST CSF, Essential 8 and C2M2 are not certification frameworks, so how can an organization appropriately demonstrate compliance? We expect that a self-assessment would raise questions – a review/audit by an external, independent expert is likely to be more well received by the government. Further, the rules do not specify whether compliance will need to be demonstrated on a periodic ongoing basis or as a one-off – though we expect the former would make more sense.
What constitutes an 'equivalent' framework?
As mentioned, entities can choose to adopt a framework that is 'equivalent' to one of those explicitly listed in the rules. However, there is no clarity provided about what constitutes 'equivalence' in this context – and as has already been mentioned, the frameworks listed vary in their breadth, granularity, industry-specificity, and whether they are certification or self-assessment based.
In the longer term - if and when more security frameworks that are industry-specific emerge – this provision may be relied upon more. If so, we expect very few organizations subject to the risk management program obligations will initially go down this route given the relative lack of certainty around the concept of equivalence.
What maturity level should those going down the Essential 8 path target?
For organizations that choose to go down the path of Essential 8 compliance, it is interesting to note that the draft rules currently target achieving maturity level one. Conversely, the Australian Cyber Security Centre's materials indicate that maturity level three may be a more appropriate target for critical infrastructure providers[11]. There is a significant difference between the two – maturity level one (ML 1) embodies around 39 discrete requirements supporting the achievement of the overarching eight mitigation strategies, whereas maturity level three (ML 3) has 69 requirements[12].
For organizations starting from a low baseline, getting to ML 1 may be challenging enough - and this may be why the rules set this as a target (rather than ML 3). Further, this approach is consistent with the ACSC's suggestion to implement the strategies as a package (i.e., focusing first on achieving a single maturity level of ML 1 across all strategies as opposed to achieving higher maturity levels in a few mitigation strategies to the detriment of others[13]). Nevertheless, if the long-term objectives of the rules are ultimately about achieving effective management of cyber risks in the context of critical infrastructure environments, it will be important to ensure entities subject to the rules are not being encouraged to merely adopt a compliance mindset for the sake of meeting a tight timeframe in order to meet their legal obligations. The operation of the risk management rules will need to be reviewed over time to ensure critical infrastructure entities are ultimately working towards implementing a security program that is robust enough to effectively manage each entity's specific set of cyber risks.
Within six months of the risk management program obligations commencing, entities that switch on the obligations will need to have a process in place to minimize or eliminate (or mitigate the impact of) material risks related to supply chain breaches.
This aspect of the rules is unsurprising – as has been clear for some time, managing supply chain security risk is a massive area of focus for the security industry and has formed a central component of security-related regulations such as the Australian Prudential Regulatory Authority's CPS 234.
While the obligation to implement a process to manage supply chain risks will be on specific critical infrastructure entities, it is worth noting the following:
While supply chain and cyber hazards are called out as separate areas of the rules, the two are inextricably linked and naturally overlap. Effectively managing cyber hazards, by necessity, also means managing supply chain risks that may introduce the potential for a cyber breach. In this context, it's important to consider that the security framework compliance requirement has an 18-month grace period, whereas – as has been mentioned – the supply chain aspect of the rules only has a 6-month grace period.
So, where an organization is looking to demonstrate compliance with the supply chain aspect of the rules by implementing a framework in accordance with the cyber hazards rule (e.g., ISO 27001 or the NIST CSF both include supply chain risk management activities) – they will need to take into account that this aspect of their compliance would potentially need to be implemented sooner than other parts of the relevant framework.
As is evident from this analysis, there are still many areas of the risk management program obligations of the SOCI Act that will need to be clarified as part of the planned industry consultation process. Further, the Australian Government has committed in the rules to creating guidance material to support their implementation, and hopefully, this will also help to clarify some of the ambiguities identified in this article.
[1] The contents of the directive will be subject to approval by the European Council and the European Parliament before formal adoption.
[2] ACSC Annual Cyber Threat Report (2020-21)
[3] Security Legislation Amendment (Critical Infrastructure) Act 2021 (Cth) (SLACI Act)
[4] Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (Cth) (SLACIP Act)
[5] Asset classes currently subject to the reporting obligations are listed here https://www.homeaffairs.gov.au/reports-and-publications/submissions-and-discussion-papers/protecting-our-critical-infrastructure-reforms-engagement
[6] The exercise of the government assistance measures are subject to Ministerial approval and legislative thresholds.
[7] Responsible entities for critical infrastructure assets are responsible for determining if something constitutes a risk that is 'material'. In so doing, a range of factors are provided for consideration in the draft rules – for example, whether the risk, if it eventuated, would cause impairment of an asset that may prejudice social or economic stability. The government may also make sector-specific rules that prescribe certain material risks applicable to that sector.
[8] A relevant impact is defined as one that affects the confidentiality, integrity, availability and/or the reliability of an asset – see section 8G of the Security of Critical Infrastructure Act 2018
[9] Commentary by the Department of Home Affairs indicates that the obligations are not designed to supplant regulatory obligations already covering risk management for specific industries. There is also recognition that some entities will already have in place effective risk management programs. However, these obligations are designed to create a minimum baseline to capture those entities that do not yet have in place basic risk management measures.
[10] In February 2022, the Home Affairs minister at the time indicated the following assets would initially be subject to the risk management program obligations:
[11] https://www.cyber.gov.au/acsc/view-all-content/publications/essential-eight-maturity-model-faq
[12] Trustwave released a blog about recent changes to the Essential 8 (including the new maturity levels) in 2021 - https://www.trustwave.com/en-us/resources/blogs/trustwave-blog/what-you-need-to-know-about-the-new-essential-8-mitigation-strategies/
[13] https://www.cyber.gov.au/acsc/view-all-content/publications/essential-eight-maturity-model-faq