Part 2: Key Take-aways from the Government Cyber Security Strategy 2023-2030: A Conversation with Cyber Lawyer Annie Haggar.
In this second instalment of our three-part interview series with Annie Haggar, Principal at CyberGC, we delve into Annie's thoughts on the recently unveiled Government Cybersecurity Strategy.
Vaughan: Ok, shifting gears a little here, let’s dive into the recent government cybersecurity strategy up to 2030 and the accompanying two-year action plan. I assume you've had a chance to give it a quick skim read. What are your initial thoughts on the legal implications?
Annie: Absolutely, Vaughan. I had to present on the legal cybersecurity implications at a conference just two hours after its release.
Vaughan: That's quite a turnaround!
Annie: Indeed, it was. After a quick speed read and subsequent reviews over the past 24 hours, from a legal standpoint, a couple of key points emerge. The government is signaling regulatory change, and it's crucial to note that this isn't an overnight process. Emergency changes to legislation are rare, often with unintended consequences.
One significant change is the proposed mandatory no-fault reporting requirement for ransomware attacks. It's somewhat like a safe harbor, but the details are still unknown. The government's objective is clear – they want everyone facing a ransomware attack to report it and engage with the government. The idea is to stamp out ransomware as a business model, and that requires a comprehensive understanding of the landscape.
Then, there's the introduction of a single reporting portal, necessitating changes across legislation. Instead of reporting to various bodies like OAIC, ASIC, or APRA, the legislation will mandate reporting to the Central Commonwealth Government Reporting portal. This will entail several changes across different pieces of legislation.
Additionally, there will be legislated limited use for ASD and the National Cybersecurity Coordinator to access and use incident information, a right that didn't exist before. The government aims to enshrine this to ensure effective use for threat intelligence reporting and other purposes.
Further changes to the Security of Critical Infrastructure (SOCI) act are on the horizon. Although it's only a couple of years old and has already undergone two amendments, the recent DP World attack uncovered gaps and overlaps. This complexity and confusion prompted a reevaluation, with a focus on simplifying these overlaps and potentially relocating legislative pieces for clarity.
Vaughan: That's a lot to unpack. The reorganization of the Telco sector seems noteworthy. What are your thoughts?
Annie: Absolutely, Vaughan. The move to shift security requirements for telecommunications providers from the Telecommunications Act to the SOCI Act is a significant reorganization, aimed at streamlining regulation and making it clearer. There's a bunch of other things, but that's probably enough detail for now.
Vaughan: Yes, I'm sure we've got weeks and weeks to read and unpack the 20 or so different initiatives that are kicking off. If we can shift focus specifically to DP World, how does the situation change when a major critical infrastructure provider is compromised and is entirely foreign-owned? What are the legal ramifications there?
Annie: Great question, Vaughan. Companies operating in Australia, regardless of being foreign-owned, must comply with our laws if they want to do business here. While enforcing on foreign-owned firms can pose challenges, the physical presence on our shores means falling under our legislation.
In the case of DP World, the National Cybersecurity Coordinator played a crucial role in facilitating their response. They were required to comply with the obligations under the Security Critical Infrastructure Act. Admittedly, extracting funds from a company with offshore finances can be more complex, but continued cooperation is essential, given the volume of business they process in Australia.
Also, I'm not sure if it's been confirmed yet, but it is alleged they were compromised due to a citrix NetScaler endpoint that hadn't been kept up to date with patching. For context there was a patch released, I think in maybe the second week of October, and a wave of organizations jumped on that patch and got it done, as it was quite high severity. DP World did not.
Vaughan: Ok so if indeed it was that patch that got them infected with a LockBit ransomware (I'm not even sure if it's been confirmed it was LockBit yet) what kind of legal liability are they exposed to as a critical infrastructure provider, or even just as an entity doing business in Australia and not maintaining their vulnerability updates?
Annie: The alleged compromise due to a Citrix NetScaler endpoint raises questions about their patching practices and the absence of a legislated minimum standard for cybersecurity in Australia adds a layer of complexity. Currently the applicable standards are based on a reasonableness test, not demanding perfection but reasonable steps based on the business type, available resources, and associated risks. It means that for the type of business you operate, the resources available to you, the risks that you face, given the type of business that you operate, and maybe the data you hold, et cetera, you have to take reasonable steps to defend the organization against attacks.
So if we apply that reasonableness test to what happened with DPWorld, we'll be asking the question - was there a good reason why the patch wasn't deployed? Had they even looked at it? If they hadn't looked at it, then probably, given that had been announced as a serious patch, a serious critical vulnerability, and that it should be patched as a priority, and they hadn't done anything about it, then they're probably in some hot water over whether or not they had taken reasonable steps.
But if they had looked at it, and they said, we can't deploy that patch because XYZ, (we've got these system changes happening, we've got these resource constraints, and if we deployed that patch it would cause this other critical part of our system to fall over or be vulnerable etc) and then they had done a risk assessment, and had a plan for how they were going to patch it or otherwise address that vulnerability, then they'd probably have a reasonableness answer to that test.
So while we don't know enough about whether or not they had even considered it, if this ends up in litigation or investigations with potential fines, it'll circle back to the reasonableness test. Was the failure to deploy the patch due to negligence or valid constraints? We don't have all the details now, but it'll be interesting to see how it plays out.
Vaughan: Absolutely, Annie. It's a complex landscape and it will be very interesting to see how it all unfolds.