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 introduced. We'll unpack some of the ambiguities that exist and remain to be clarified in this specific area of the reforms as one example of the challenges that come with critical infrastructure regulation – a hot topic across the globe.
Regulation of Critical Infrastructure Security – an Increasing Area of Global Focus
Facilitating the protection of critical infrastructure through regulation is not an entirely new concept. For example, the European Union (EU), U.S., and Australia have all had laws 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 the 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. The directive will potentially be complemented by the Directive for Resilience of Critical Entities, which will cover additional obligations for EU member states to enhance the resilience of critical infrastructure entities.
Similarly, in the U.S., the Cyber Incident Reporting for Critical Infrastructure Act was signed 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 U.S. Cybersecurity and Infrastructure Security Agency (CISA).
Australia has also had reforms planned for quite some time for its Security of Critical Infrastructure Act (SOCI Act), which have been enacted over the last year.
The Australian SOCI Act reforms
At the outset, we recognize that there has already been significant discussion and coverage in the public domain summarising 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 introduced a limited set of obligations for a narrow subset of critical infrastructure entities in the gas, electricity, 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.
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 set of amendments was introduced in December 2021, and the second set came into effect in April 2022.
Content of the SOCI reforms
In summary, the reforms:
- Broaden the scope of critical infrastructure sectors covered by the act in recognition that – in the view of policy makers – more sectors needed to be effectively secured against a possible breach. 11 sectors are now covered, including 22 different asset classes within those sectors. This is accompanied by expanded register reporting obligations, which need to be ‘switched on’ to apply to any of these asset classes;
- Introduce a mandatory security incident reporting obligation for certain asset classes for which the obligation has been switched on – in such cases, security incidents need to be reported to the Australian Cyber Security Centre (ACSC);
- A new set of ‘Government assistance measures’ that provides information gathering powers for the Department of Home Affairs where an incident has occurred affecting a critical infrastructure asset - these enable government to provide directions governing the response process, or to directly intervene in some instances. These measures apply to all assets within the scope of the act.
- A set of ‘enhanced’ obligations that apply to assets designated by the Government as “Systems of National Significance” – including requiring the development of incident response plans, undertaking cyber security exercises and vulnerability assessments.
The Cyber and Infrastructure Security Centre (part of the Department of Home Affairs) has provided more detail on each aspect of the these reforms in a range of fact sheets, available here.
The Risk Management Program Obligations
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 whom the obligations are switched on) to implement and follow a written risk management program. Responsible entities to whom the obligations apply must:
- identify hazards that create ‘material risks’ to critical infrastructure assets;
- Take steps to minimise or eliminate those risks, where they could have a relevant impact on the asset; and
- Take steps to mitigate a relevant impact, should the risk eventuate.
These obligations are to be provided with additional specificity via a set of Risk Management Program Rules. A draft of these rules – including the assets they would initially govern – has been provided on the Department of Home Affairs website, although it appears 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. The risk management program obligations will include a grace period – at this stage at least six months – from the rules commencing till compliance being 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 rules as they currently stand provide some indication of the current thinking of policy makers and provide a useful framework for discussion.
The rules are largely principles-based and centred around four key areas of potential hazards for critical infrastructure assets:
- Physical and natural hazards
- Cyber and information hazards
- Personnel hazards
- Supply chain hazards
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.
Cyber and information hazards - security framework compliance requirement
Minimising or eliminating material risks that relate to cyber hazards is a key 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):
- AS ISO 27001:2015
- Essential Eight Maturity Model - (at maturity level one)
- NIST Cybersecurity Framework
- Cybersecurity Capability Maturity Model (C2M2) - (Maturity Indicator Level 1)
- Australian Energy Sector Cyber Security Framework - (Security Profile 1)
Alternatively, entities can choose to comply with a framework that is ‘equivalent’ to one of those listed above. 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 in place 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 organisation.
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 favouring a more holistic framework 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 organisation 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 organisations starting from a relatively low baseline when it comes to security.
Conversely, frameworks such as the NIST CSF, Essential 8 and C2M2 are not certification frameworks, so how can an organisation 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 on-going 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. While in the longer term - and if and when more security frameworks that are industry-specific emerge – this provision may be relied upon more, we expect very few organisations 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 be targeted for those going down the Essential 8 path?
For organisations that choose to go down the path of Essential 8 compliance, it is interesting to note that the draft rules currently set a target of achieving maturity level one. Conversely, the Australian Cyber Security Centre’s own materials indicate that maturity level three may be a more appropriate target for critical infrastructure providers. 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.
For organisations 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). 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.
Supply chain hazards
Within six months of the risk management program obligations commencing, entities for whom the obligations are switched on will need to have a process in place to minimise 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 sometime, 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.
The unofficial scope of this rule may be much broader than the official scope
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:
- Any critical infrastructure entities to whom the rules apply will naturally need to gain assurance over the security of their supply chains by vetting the security controls and risk management processes of key vendors. As a result, the rule may have significant flow-on effects for a range of vendors who are not directly caught by the risk management program obligations, but need to be able to demonstrate a robust approach to their own security programs in order to provide relevant critical infrastructure entities with sufficient comfort about their compliance with their legal obligations. Verifying supply chain risk – particularly where multiple high risk / critical vendors are involved – is specialised work that may require the input and assistance of external experts;
- The newly introduced government assistance powers are somewhat of a ‘dangling knife’ that hover over every critical infrastructure entity - even if the risk management program obligations have not been directly switched on for some, the assistance powers apply to all. So, it may be in the best interest of entities who are not immediately caught by the obligations to still consider the security of their supply chain and take steps to remediate any deficiencies as a priority. In this respect, we expect that many suppliers to critical infrastructure entities – whether those entities are subject to the risk management obligations or not – are likely to be asked to provide more assurance about their own security practices.
Overlap of the supply chain and cyber hazards rules
While supply chain hazards and cyber hazards are called out as two 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 organisation 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 a number of 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.
 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
 The exercise of the government assistance measures are subject to Ministerial approval and legislative thresholds.
 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. The Cyber and Infrastructure Security centre has already released guidance for the communications sector on implementing effective risk management practices - https://www.cisc.gov.au/critical-infrastructure-centre-subsite/Files/raa-communications.pdf
 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
 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.
 In February 2022, the Home Affairs minister at the time indicated the following assets would initially be subject to the risk management program obligations:
· Critical broadcasting assets
· Critical domain name systems
· Critical data storage or processing assets
· Critical hospitals
· Critical energy market operator assets
· Critical water and sewerage assets
· Critical electricity assets
· Critical gas assets
· Critical liquid fuel assets; and
· Critical financial market infrastructure assets that are specified payment systems operator assets
 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/