Categories for Blogs & Articles

Lives at risk, medical pumps still vulnerable

March 25, 2022Published by Jeffrey Eaton
Medical infusion pumps are modern life-saving devices…… frequently harbour severe security vulnerabilities that, if exploited, could result in death or serious injury

Three-Quarters of Medical Infusion Pumps Still Vulnerable, Putting Lives at Risk

Medical infusion pumps are modern life-saving devices which deliver controlled doses of fluids, such as medications, directly into a patient’s body. Designed to be used for up to 10 years, these devices are widely used in hospitals, care facilities, and in the home. However, these devices frequently harbour severe security vulnerabilities that, if exploited, could result in death or serious injury.

A recent report from researchers at Palo Alto Networks’ Unit 42 revealed that three-quarters of 200,000 medical infusion pumps discovered using Palo Alto Networks’ IoT Security for Healthcare system were impacted to some extent by known vulnerabilities. Over 100,000 of the scanned pumps were found to have severe security flaws. Troublingly, these vulnerabilities are not unknown; they were disclosed in 2019 and dubbed the URGENT/11.

One of these vulnerabilities, labelled CVE-2019-12255 is related to the Wind River VxWorks operating system used by medical and other industrial devices, and is a Buffer Overflow flaw in the TCP component, earning it a Common Vulnerability Scoring System (CVSS) severity score of 9.8 out of 10.

A second serious vulnerability, CVE-2019-12264 (CVSS score of 7.1) also relates to the Wind River VxWorks OS, where in several versions, the Access Control in IPv4 assignment by the DHCP client component is flawed.

A History of Significant Vulnerabilities Has Effected Little Change

There have been several instances of serious security flaws being discovered in medical pump devices over the past several years. For example, in May 2015, ICS-CERT published an advisory detailing several critical vulnerabilities in the Hospira LifeCare patient-controlled analgesia (PCA) infusion systems. These systems deliver measured doses of analgesic medication. The vulnerabilities could allow a remote attacker could take complete control of affected devices.

In October 2016, Rapid 7 reported that OneTouch Ping insulin pumps have several vulnerabilities that could be remotely exploited. The vulnerability lies between the pump and its remote control, which communicate with each other via an unencrypted channel (CVE-2016-5084), potentially allowing man-in-the-middle (MitM) attacks. In addition, the device has an issue with weak pairing between the pump and the remote (CVE-2016-5085), leaving the device open to spoofing attacks where the remote and its commands are impersonated. Although the OneTouch Ping pump and its remote are not connected to the Internet, attacks could still be carried out remotely from up to a mile away.

The problem of remotely exploitable vulnerabilities in medical pumps persisted in 2017, when eight remotely exploitable vulnerabilities were reported in the Smiths Medical Medfusion 4000 wireless syringe infusion pumps. An ICS-CERT advisory indicated that several of the vulnerabilities were critical or high severity issues. The company quickly worked to issue patches for the security flaw.

Seeing a need for practical guidance in the safe deployment and use of medical pumps, the National Institute of Standards and Technology (NIST) published SP 1800-8: Securing Wireless Infusion Pumps in Healthcare Delivery Organizations in 2018, with the intention of providing practical and usable advice on the configuration and deployment of wireless infusion pumps.

Less than a year later in June of 2019, the U.S. Food and Drug Administration (FDA) and Medtronic informed the public of a recall of the MiniMed 508 and the Paradigm series insulin pumps, citing remotely exploitable vulnerabilities.

URGENT/11 Still an Issue After 3 Years

The following month, Armis announced the discovery of the URGENT/11, a group of 11 zero-day vulnerabilities in the VxWorks IPnet stack. Six of the vulnerabilities were critical Remote Code Execution (RCE) issues, which could allow complete remote takeover without any user action.

Alarmingly, medical infusion pumps are not the only devices impacted by the URGENT/11; SCADA devices, industrial controllers, patient monitors, MRI machines, firewalls, VOIP phones, and printers were also found to be vulnerable to the URGENT/11, due to their use of VxWorks software. And if all that was not bad enough, the URGENT/11 vulnerabilities allow an attacker to broadcast malicious packets throughout a network and simultaneously take control of all VxWorks devices receiving them.

In October 2019, researchers who had been worried that URGENT/11 may impact any device that used IPnet in their Real-Time Operating Systems (RTOS) had their worst fears confirmed. Armis identified six additional Real-Time Operating Systems (RTOS) that supported IPnet TCP/IP stack, including “OSE by ENEA, Integrity by Green Hills, ThreadX by Microsoft, Nucleus RTOS by Mentor, ITRON by TRON Forum, and ZebOS by IP Infusion”. The researchers warned that potentially millions of additional medical, industrial, and enterprise devices were at risk from the URGENT/11 vulnerabilities.

Amis researchers have continued to monitor the number of devices vulnerable to the URGENT/11. As of December 2020, they estimated that approximately 97% of all OT devices impacted by the URGENT/11 vulnerabilities had not been patched.

Even as millions of devices go unpatched to known critical vulnerabilities despite guidance on configuration and deployment from organisations like NIST, security researchers continue to find new vulnerabilities in medical pumps that could be remotely exploited to alter a patient’s dosage. In August 2021, severe vulnerabilities were identified in B. Braun’s Infusomat Space large volume infusion pump and SpaceStation system potentially leading to the manipulation of lethal doses of medication, and in October, the Medtronic recall was expanded to include the optional remote controllers, with the FDA ominously warning that use of the devices may cause serious injuries or death.

Patch and Monitor is Still the Best Advice

In addition to securing devices against known threats with the latest security updates, networks should also be monitored for suspicious activity. Specifically, defenders should be on the look out for the most common issues and indicators of malicious activity in infusion pump systems, including:
  • Large numbers of reset packets originating externally, potentially indicating continuous unsuccessful connection attempts to a device.
  • Garbage values in the User-Agent string of a HTTP request between the infusion system and the corresponding destination can indicate suspicious behaviour.
  • Unencrypted credentials in HTTP requests can be intercepted by a malicious actor.
  • Factory default credentials used in inbound HTTP or FTP logins.
  • Unusual port numbers and counts in incoming and outgoing traffic in the infusion system may indicate suspicious activity.
  • Unsecured outbound HTTP or FTP connections from infusion systems to the internet. These should be limited to local VLAN traffic.
  • Anonymous FTP login attempts without a specific username or password via the local network may indicate malicious activity.

The findings of Palo Alto researchers indicating that known vulnerabilities exist in three out of four infusion pumps reveals a lack of focus on patching and best practice in the healthcare industry, despite a history of significant security issues. Attacks on the healthcare sector are increasing every year, and it is likely only a matter of time before life-sustaining devices are targeted directly or impacted inadvertently. In a time when global instability is giving rise to increased offensive cyber activities from a range of actors, ensuring the security of medical devices, and protecting the lives of the patients they service, is more critical than ever.

Cybersecurity trends in 2022

February 1, 2022Published by Jeffrey Eaton
Supply chains, IoT devices and health care are in the sights of cyber criminals adopting ever more aggressive tactics and insurance will be harder to get, leaving organisations badly exposed

Threats and trends in cybersecurity

Supply chains, IoT devices and health care are in the sights of cyber criminals adopting ever more aggressive tactics and insurance will be harder to get, leaving organisations badly exposed, says Sapien Cyber CEO Glenn Murray.

Smart cities and the Internet of Things have created a hyperconnected society but cybercriminals are exploiting these networks because there is no focus on security.

Cybercriminal activity is now taking advantage of the highly connected world we live in and the vulnerability of IoT devices are going to come under scrutiny in 2022.

IoT devices are rarely well protected and proving to be the weak link to exploit networks. Health care will be the number one target for cyber-attacks and ransomware, with medical IoT devices targeted in the coming year.

Cyber security attacks are growing in frequency and audacity in Australia during 2021, with multiple high-profile threats to steal data and shut down systems.

Criminals came within minutes of shutting down Queensland power stations capable of lighting three million homes and one of Tasmania’s biggest employers was attacked for the second time this year. Even in December, the details of up to 80,000 workers were accessed in a cyber attack on a payroll software provider in South Australia.

In the coming 12 months, companies and organisations need to understand the threats to their business and networks, and be prepared the fallout from not taking preventative action.

Businesses may be uninsurable

Businesses that are not locking the metaphorical doors on their networks risk facing higher insurance premiums, or worse – finding themselves uninsurable.

The directive is coming from the top. This year, the Australian Prudential Regulatory Authority (APRA) started directing Australian insurers to review their cyber risk profile and reconsider whether insurers are themselves underplaying risk.

Global ransomware attacks doubled in 2021 after a 170% spike in the previous year, and the size of ransom demanded also continues to climb.

With attacks higher in yield and sophistication, insurance firms have been paying out in a big way on existing policies, and there is also a trend to attacking companies with good insurance coverage.

This has inevitably led to a crackdown on businesses not taking responsibility and underwriters are transferring some of that risk back to the insured party.

It will become increasingly necessary for businesses to demonstrate appropriate cyber security risk management for insurers to have their back.

Get a clear picture of the problems

Weakness in networks comes not just from ever increasing ‘zero-day attacks’ but also from older vulnerabilities due to poor patching programs, and this patch gap in operational technology environments will be exploited in 2022.

Businesses need to get across the weaknesses and threats present in their network and that come from threat monitoring.

But when you have all that data, what do you do with it? As the saying goes, value is drawn not from how much information is in a presentation but how much of the information is retained.

Visualisation gives meaning to data – it’s the key delivery mechanism. By seeing the threats and weaknesses in networks, and partnering with experts, organisations can better manage and measure cyber security risk.

Think about a gas wellhead control panel – all the information about pressure, flow and other key metrics is available whenever access is needed, and changes in patterns that could lead to problems can be addressed.

It’s no different to cyber security threat monitoring. Business leaders don’t need to know how security is tracking every moment of the day, but there will be processes to alert them if there is a problem or emergency.

Shore up your supply chains

2021 was another tumultuous year for supply chains, with sea and air freight prices soaring thanks to COVID-19, port closures and container shortages, not to mention the Suez Canal delays.

The world’s eyes were on the United States in May over the havoc caused by the Colonial Pipeline attack, which opened eyes to critical infrastructure operational technology vulnerabilities.

The ransomware attack crippled the computer system that controlled supplies of oil, petrol, and jet fuel to the south-eastern United States, forcing authorities to pay a ransom. Some of the ransom was later recovered but companies would be unwise to bank on this outcome in an attack.

An extortion model will be the next level of escalation, where cybercriminals would seek access to targets through the company’s own supply chain and hold critical data to ransom, then leak the attack to media for maximum visibility.

Critical infrastructure will become a focal point in Australia in the coming year, with many businesses discovering they are deemed critical by new legislation which was passed in November.

Under the Critical Infrastructure Bill, companies will be forced to disclose cyber attacks and company directors could potentially be held liable if they cannot demonstrate that sufficient action was taken to defend the organisation.

That will not be an easy scenario to deal with. Supply chain layers and complexity can accumulate like a babushka doll, presenting a greater surface area for cracks to appear and be exploited by cyber criminals.

Secure renewable energy networks

Australia has one of the highest uptakes of solar energy in the world, with data from the Clean Energy Regulator showing more than 2.68 million systems have been installed.

Renewable energy is scaling up as well. Microgrids – small scale electricity systems driven by solar panels, battery storage and other infrastructure – provide reliable electricity and optimise energy generation and usage.

But these types of systems can be vulnerable to cyber threats if they are not properly secured and while many are closed systems, some also provide services back to a major grid as a final backup.

An attack that leaked into a major grid would be a disaster, lowering energy production or overloading batteries connected to solar-plus-storage systems, placing health and lives at risk.

Demand for security by design in such systems needs to increase, to build resilience into devices and technology, and this is best done by bringing together technology engineers and cyber security experts.

Cryptocurrency and ransomware

Cryptocurrency will continue to be an enabler of cyber crime, incubating a network of invisible people who make attacks that can’t been seen and seek currency that is not visible or easily traceable.

A trend is emerging in steal and sell ransomware, which means that criminals are not only seeking a ransom but extorting the target organisation by selling the data to competitors.

Cybercriminal are now stealing data before organisations are even aware they are in the network, then executing the ransomware – a technique so successful it is expected to escalate in 2022.

Ransomware attacks can be defended against. A client recently faced an extortion threat where for every day that a ransom was not paid, the price rose by 0.2 bitcoins. But when the attackers returned to up the ante, they found nothing. The infected network was fixed and moved to a new location and business went on as usual.

But the successful defence above only worked because the client was prepared. Their system was properly monitored, they had servers backed up in separate locations.

Law enforcement agencies are making some progressing in tracking down cyber crooks but while crypto remains unregulated and difficult to trace, there will always be people ready to exploit it and make quick money.


Whispergate Malware Targets Ukrainian Government Sites as Diplomatic Talks Falter

January 18, 2022Published by Jeffrey Eaton
Can cyber-attacks shape battlefield events and be used as a coercive tactic in prelude to, or in support of, physical conflict?’

Approximately 70 Ukrainian Government websites have recently been brought down by a destructive malware masquerading as ransomware. The cyber-attack coincides with the breakdown of diplomatic talks between the NATO alliance and Russia over Russia’s deployment of over 100,000 troops on its border with Ukraine.

On January 15 2022, the Microsoft Threat Intelligence Center (MSTIC) detailed evidence of the destructive wiper malware impacting several government, non-profit, and information technology organisations based in Ukraine. The activity, tracked by the MSTIC as DEV-0586 and dubbed Whispergate (the MSTIC uses DEV-#### designations for unknown and emerging threats), has not been officially associated with any known Advanced Persistent Threats (ATPs). However, Kyiv believes a group associated with Belarusian intelligence, UNC1151, may be involved and working with Russia, a close ally of Belarus.

Supply Chains Again Exploited as an Attack Vector

As a supply chain attack, the activity appears to have originated with the breach of Ukrainian company Kitsoft, which “develops and implements digital technologies for state authorities and commercial organisations”. Sapien Cyber has found that the Kitsoft website is also offline at the time of writing (January 17, 2022). The MSTIC has asserted that the known impacted assets are unlikely to represent the full scale of the attack.

The malware is being described as a “Master Boot Records (MBR) Wiper” with unique capabilities, but similar to malware used by groups tied to Russian intelligence, according to Serhiy Demedyuk, the Ukrainian deputy secretary of the national security and defence council. Ukraine officials have also asserted that recent attacks defacing Ukrainian government websites and attributed to UNC1151 were likely a diversionary tactic designed to draw attention away from the much more destructive DEV-0586 (or Whispergate) activity.

Ransom as a Ruse

According to the Microsoft Threat Intelligence Center, the malware utilises two stages, initially overwriting the Master Boot Record (MBR) with a ransom note before downloading file corruptor malware from a Discord channel and overwriting files with common extensions. The initial malware “resides in various working directories, including C:\PerfLogs, C:\ProgramData, C:\, and C:\temp, and is often named stage1.exe”, while stage2.exe is the downloader for the malicious file corrupter malware. Typically, a ransomware-infected machine is immediately shut down to prevent further file encryption; however, in this instance, this appears to be the course of action that the threat actors are anticipating and is the trigger to activate the malware in full.

The MBR is a section of a computer’s hard drive providing instructions that enables the loading of an operating system. Corruption of the MBR is commonly known as “bricking”, resulting in the affected machine being unable to power on or function normally. In the case of the DEV-0586 (or Whispergate) malware, the ransom note appears to be a ruse, as the MBR is overwritten rather than files being encrypted, as is seen in traditional ransomware.

Coercive Tactic or Disruptive Attack as a Prelude to Physical Conflict?

In a 2017 research paper titled Invisible Digital Front: Can Cyber Attacks Shape Battlefield Events?, the authors discussed the impact of the December 2015 cyber-attack on the Ukrainian power grid, attributed to a Russian hacking group known as “Sandworm”, on physical conflict. Although the authors argued that cyber-attacks fail “to compel discernible changes in battlefield behaviour”, it appears that cyber-attacks on critical infrastructure and essential services are increasingly being employed by some nation-states as a coercive tactic in prelude to, or in support of, physical conflict.


A Significant Threat Starts the New Year – Log4J Explainer

January 12, 2022Published by Jeffrey Eaton
As news of the Apache Log4j logging library bug has spread, it has quickly become known as one of the most significant recent global cybersecurity vulnerabilities

You have likely heard the news of the Apache Log4j (also known as Log4Shell) vulnerability that emerged in early December 2021 and was almost immediately exploited in the wild, sending security operations centres and administrators into a panic across the globe.

As news of the Apache Log4j logging library bug has spread, it has quickly become known as one of the most significant recent cybersecurity vulnerabilities, due to the ease of exploitation and the widespread use of Apache Log4j. This Java library logs error messages in applications and services used by enterprise applications and cloud services.

It has been estimated that more than 89 percent of all environments across organisations and cloud providers have vulnerable log4j libraries.

Log4j – What Happened?

On November 24th, 2021, Alibaba Cloud’s security team reported to Apache a critical remote code execution vulnerability (RCE) impacting at least Apache Log4j 2 (versions 2.0 to 2.14.1).

A remote code execution (RCE) vulnerability in such a widely used piece of code is significant as attacks against RCE vulnerabilities often are designed to give an attacker administrative access to a vulnerable system.

On December 9th 2021, Apache issued a patch for the vulnerability, with the Common Vulnerabilities and Exposures designation of CVE-2021-44228 and the highest severity rating of 10.0 at the time.

Also, on December 9th, 2021, hot on the heels of Apache’s announcement of the vulnerability, the first proof-of-concept exploit was published on GitHub.

By December 10th, threat intelligence sources began to report mass scanning activity from multiple hosts checking for servers using Apache Log4j. Attacks attempting to exploit RCE vulnerabilities are typically prefaced with automated reconnaissance scans used to identify the vulnerable version of software on the target.

Once a target is identified via a scan, the Apache Log4j vulnerability can be exploited by a specially crafted string parsed and processed by the vulnerable Log4j component, permitting unauthenticated remote code execution, potentially resulting in full access to the target system by the attacker.

However, Apache’s initial patch did not address the risk entirely, resulting in a new CVE-2021-45046 and a second patch on December 13th, 2021.

Apache addressed related vulnerabilities with a third patch on December 17th (CVE-2021-45105) and a fourth patch on December 28th (CVE-2021-44832).

How is Log4j Being Exploited?

There is no requirement for attackers to have prior access to impacted systems. Remote exploitation of the vulnerability executes the logging event using commands like curl. Processing of the log results in the vulnerable system running the string. In the attacks seen thus far, the string has been used to execute code from malicious domains.

Initial reports suggested disabling message lookup functionality by adjusting the log4j2.formatMsgNoLookups environment variable to true or deleting the JndiLookup.class from impacted JAR files would mitigate the vulnerability. However, Log4j is often present in other files as a bundle or within a shared library, making these workarounds cumbersome, difficult to verify, and not always possible due to impacts on systems that rely on Lookups for message formatting.

These initially suggested workarounds were found not to mitigate the risks completely; however, they may provide greater defence-in-depth when combined with the latest patches.

There is also a significant challenge in detecting and mitigating all instances of the Log4j on any given network. According to Yotam Perkal, vulnerability research lead at Rezilion, “Java files (such as Log4j) can be nested a few layers deep into other files and may be packaged in many different formats which creates a real challenge in digging them inside other Java packages.”

After testing nine Log4j vulnerability scanners, Rezilion found that none could detect all formats, illustrating that no single tool can detect every edge case in a scenario where there are a great many edge cases.

Expect an Increase in Ransomware Activity that Utilises Log4j Exploits

The Australian Cyber Security Centre (ACSC) has indicated that ransomware groups known to have previously attacked Australian organisations are now leveraging the Log4j vulnerability. ACSC expects this will increase ransomware activity that utilises Log4j exploits as a vector.

For example, the Conti ransomware is a ransomware-as-a-service (RaaS) affiliate program that has been successfully deployed to target networks worldwide, including Australia.

Multiple Australian organisations have been impacted by Conti ransomware in November and December 2021.

Threat actors who utilise ransomware such as Conti typically take advantage of any newly disclosed vulnerabilities, such as Log4j, as quickly as possible after disclosure, before the window of opportunity closes and network owners apply patches and mitigations.

Critical Infrastructure Vulnerability Exacerbated by Pandemic Impacts

Worryingly, Conti affiliates have been observed targeting critical sectors, most notably healthcare organisations. Part of Australia’s National Critical Infrastructure, the Healthcare and Medical sector is currently experiencing the extreme burden of the Covid-19 Omicron variant wave. Ransomware attacks on this sector could not come at a worse time.

The pandemic’s impacts are also rippling through other Australian Critical Infrastructure sectors, including Food and Grocery and Transport. Australian supply chains are currently vulnerable as the Omicron variant surge exacerbates existing stressors, such as pallet and transport capacity shortages. Limits are being introduced to certain Grocery items in Australian supermarkets, while the demand for online Grocery orders are surging as people isolate themselves to prevent the further spread of Covid-19.

Ransomware attacks against these and other sectors are now more likely, thanks to the Log4j vulnerability. This highlights the urgency for all organisations to implement protective measures against this severe vulnerability, as the current confluence of circumstances threatens Australia in ways that were unimaginable a few years ago.


Two-thirds of organizations are at a ‘significant risk’ of cyber attacks caused by the pandemic

December 23, 2021Published by Jeffrey Eaton


Threat Intelligence Fundamentals

December 1, 2021Published by Jeffrey Eaton

Threat Intelligence Fundamentals

Author: David Balaban – PrivacyPC.Com

Information security professionals may have different perspectives about what exactly threat intelligence is, what tasks it should solve, and how a company can benefit from deploying solutions of this sort. This term is often interpreted as a set of techniques for collecting and analyzing indicators of compromise (IOCs) to form an extra layer of protection mechanisms. However, the functionality of the resulting security systems is somewhat opaque. Let’s add some clarity to this subject and figure out who gets the most mileage out of such practices.

What is threat intelligence and who needs it?

Threat intelligence is an entirety of data that allows IT experts to understand a threat and make informed security decisions. This can be both low-level data (e.g. file hashes and IP addresses), and information about a specific attacker seeking to infiltrate a target system. Many professionals prefer using the broader concept of security intelligence that includes threat intelligence, vulnerability intelligence, brand intelligence, and other components of the defense equation.

A few years ago, when this term debuted in the cybersecurity arena, it could mean just about anything. The situation is now more structured and there are standards that make the concept more distinct, and yet it is still debatable whether this technique is part of the overarching security intelligence domain.

In essence, threat intelligence boils down to data as well as the ways it is collected and evaluated. The context of threat information is hugely important. Analysts need to understand if specific data is appropriate for decision-making and link IOCs with specific reports and vulnerabilities.

The layer of technical data plays a big role in threat intelligence, but the right approach should also involve the strategic layer. A security expert must stay on top of operational and tactical layer information and be able to grasp the applicability of certain vulnerabilities and reports.

Threat intelligence can be integrated into different enterprise workflows. In particular, the InfoSec department typically combines it with the general context of the current cybercrime landscape that goes beyond specific attack vectors that pose risk to the organization. On the other hand, investigating an incident requires figuring out who is behind the malicious activity and what techniques were used. Depending on where threat intelligence is leveraged in the company and for what purpose, there are different requirements for its content as well.

Why does an organization need threat intelligence when it has other security and data collection mechanisms in place, such as an intrusion detection system (IDS), a next-generation firewall (NGFW), and a security information and event management (SIEM) solution? It helps piece the whole security picture together and step away from the reliance on individual tools or vendors. This is especially important for businesses whose security postures involve threat response.

With cyber threat intelligence techniques in its toolkit, a company can also gain insights into threats outside of the security perimeter that have not yet been detected by its security solutions. Another noteworthy point is that many defensive solutions have blind spots that attackers might exploit. Threat intelligence closes these gaps. The need for this tactic stems from the rapid evolution of cyber perils – as they become more complex, security tools have to match this sophistication.

At the technical level, threat intelligence is used to facilitate the following activities:
  • Incident response
  • Proactive threat hunting
  • Security monitoring
  • Malicious code analysis
  • Intrusion detection.

At the strategic level, threat intelligence can help senior management make important decisions. For instance, when planning to enter new markets, company executives need to know what security risks are inherent to these regions. The information gathered through threat intelligence allows estimating the costs that may be incurred and correlating them with the expected profits.

A hands-on approach to threat intelligence

Let’s move on to the practical implementation of threat intelligence techniques – in particular, to explain where the required data comes from and whether a company can obtain it independently without being tied up to a specific service provider. First things first, there are plenty of open sources that can be used to obtain this kind of information. In addition, security professionals can analyze instances of threat detection by the existing security solutions to understand and predict possible future attack paths.

It takes a good deal of effort and expense to process all this data. According to a popular viewpoint, the optimal approach should cover data from three sources: internal information, information from public databases, and commercial feeds purchased from a vendor. The criteria for selecting the sources of threat intelligence data may be as follows:
  • Automation options
  • Integration and interoperability
  • Update frequency
  • Enrichment with metadata
  • Complexity rating
  • Darknet visibility
  • Geolocation accuracy
  • The number and range of sources
  • Quality
A common question comes down to the whys and wherefores of using a specialized threat intelligence platform. Why can’t indicators of compromise and other security information be uploaded to a SIEM system or NGFW? How effective is a specialized solution?

The thing is that such tools aggregate information from multiple sources and process it according to a well-trodden methodology. The task of collecting, analyzing, and ranking data on your own is feasible but very resource-intensive and costly. Importantly, the average SIEM service cannot deal with the multitude of feeds a threat intelligence platform easily handles. Millions of IOCs may slow down or even paralyze it.

Buying as many threat intelligence feeds as possible does not significantly improve the quality of protection. It is important to use the data that correlates with potential threats aligned with the customer profile. Otherwise, the level of “noise” will be too high, which will affect the productivity and efficiency of the system.

When it comes to the feasibility of automating threat intelligence processes, experts’ opinions vary. A system like that can capitalize on analyzing adversaries’ known tactics, techniques, and procedures (TTP), ranking them, and building a threat matrix. However, many professionals argue that the key role of threat intelligence is to provide an analyst with relevant information, enrich it with context, and identify the current cybercrime trends.

How to choose a threat intelligence system worth its salt

To begin with, an organization must understand why it needs such a system. A good idea is to create a list of metrics that clearly show how the implementation of the new tool could strengthen the company’s defenses. It is also recommended to start small by testing the system with a limited number of feeds without hiring a group of analysts from the get-go. A few real-world cases will point the customer in the right direction.

Since the deployment of a threat intelligence system is a lengthy process that requires significant funding, the company’s top executives should consistently provide their support to the security team. Also, customers should maintain a dialog with vendors that have accumulated considerable experience in this area and are usually willing to help. Running a pilot project is not a problem. Most vendors don’t mind providing temporary access to their feeds and platforms.

Being guided by marketing materials alone is a half-baked strategy. It is better to come to the provider and talk to their sales managers and technical specialists. This will allow the client to form an accurate opinion about the developer and specify all the requirements. Communication with the developers will also help understand what is going on beyond the security perimeter, what types of attacks are most likely, and what threat intelligence information will be necessary in the first place.

Conclusion

Vendors and system integrators should work harder to explain the benefits of threat intelligence platforms to potential customers. It is worth pointing out that the full-fledged implementation of such solutions requires a certain degree of maturity and a high level of managerial involvement in enterprise security workflows. Meanwhile, some threat intelligence techniques, such as in-house analysis of feed data and the evaluation of malicious actors’ TTP details, are available even to small companies and can step up their protection against the ever-changing scourge of cybercrime.


IT & OT Convergence

October 17, 2021Published by Jeffrey Eaton
How to confidently protect your converged OT & IT environment.

The integration of Operational IT (OT) and Information Technology (IT) accelerates across industrial sectors as organisations digitally transform. OT and IT convergence, digitised architectures and machine learnings offer improvements, efficiencies and valuable insights into better ways of doing things. However, they also introduce new cybersecurity concerns. There are important cybersecurity challenges to overcome when integrating different and distributed Internet of Things (IoT) devices and technologies.

The cybersecurity challenge in OT and IT environments

Bringing together OT and IT enables agility and new business processes and opportunities. Rapid deployment and scalability are more manageable when using new systems and platforms. OT assets are typically legacy operating systems that don’t have built-in security capabilities in the software. OT assets are vulnerable to cybersecurity breaches because of their inherently complex topologies, lack of visibility and understanding of how and when assets are used.

Introducing intelligent devices and platforms, cloud connectivity, IoT and networks add to the complexity of the OT cybersecurity environment. Digitisation increases the volume of security data, visibility gaps and highlights a need for more automated cybersecurity measures.

In industrial settings, production downtime is measured by cost per minute and relates to lost revenue. An industrial style outage means wasted resources, damaged equipment or worse. Teams need to be able to quickly identify which device is breached and evaluate whether it impacts a critical system that could put people, production or facilities at risk. Organisations require defined processes to quarantine breached devices until they are cleared to return to the operating environment.

A chain is only as strong as its weakest link.

Connected and interconnected devices represent entry points for the bad guys. OT assets on public networks and the internet may be vulnerable to bypassing authentication and provide unauthorised access. Third-party providers installing unsecured assets may expose network access points open to a breach.

Programmable controls, cameras, sensors and equipment often come with embedded software that needs careful integration with existing programs or hackers can expose stack-based vulnerabilities and take control of the assets. For example, a simple flaw in the integration code could result in a breach could disable the safety systems designed to prevent an accident.

OT and IT systems cover both digital and physical spaces that demand continued uptime. Organisations must balance availability, privacy and integrity while protecting their environment from imminent cybersecurity threats.

Gaining better visibility of your OT environment.

Mitigate cybersecurity risks by considering the following:
  • Improving the visibility of your OT assets means gaining insights and information to prevent an unwanted breach.
  • Identify and understand your OT asset software and hardware inventory, including reviewing legacy processes for vulnerabilities.
  • Plan for regular OT network assessments and audits across operating systems and application software.
  • Document the processes across your OT environment and understand those that may impact your organisation’s safety, operation, and environment. Prioritise and protect these areas by securing connections, monitoring for intrusions and logging incident responses for ongoing learning.
  • Enabling automated threat detection is a must.
  • Create an incident response plan, so if a security breach occurs, you have to take immediate and automated action.

Critical Infrastructure 6 of 6

October 12, 2021Published by Jeffrey Eaton
Critical Infrastructure – Part 6

Author: Mel Griffiths

Preparing For a Cyber Pearl Harbour

“What I’m worried about is a ‘cyber Pearl Harbor’ — an online attack that cripples our critical infrastructure and catches us all by surprise… That’s why we’re seeking to pass legislation that safeguards those critical assets that make up our digital economy and sovereignty.”

Andrew Hastie, Assistant Minister for Defence

The Australian Government continues to reiterate the urgency of their plan to pass legislation intended to safeguard Critical Infrastructure in an increasingly hostile threat landscape. Industry sectors impacted by the Security Legislation Amendment (Critical Infrastructure) Bill 2020 have called on the government for further consultation, offering a plethora of sector-specific recommendations designed to clarify responsibilities, leverage existing frameworks, and reduce the regulatory burden.

In an effort to balance the urgent requirement to pass the legislation with industry concerns, the Parliamentary Joint Committee on Intelligence and Security (PJCIS) has suggested that the government urgently pass the portions of the Bill that focus on government assistance mechanisms and mandatory notification requirements, while introducing the remaining aspects under a separate Bill following further consultation.

This move may raise further concerns from industry given the number of objections regarding the extent of the proposed government powers, as well as the lack of any avenue for appeal. For example, the Australian Information Industry Association (AIIA) has questioned the appropriateness of the powers inherent in the legislation for the data storage or processing sector, given its complexity, interconnectedness, overlapping regulatory regimes, and the potential global implications. Palo Alto Networks has gone so far as to recommend that the data storage and processing sector be removed from the Bill altogether, citing other governments who have avoided defining this sector as Critical Infrastructure due to its complex and interdependent nature. There are also many aspects of mandatory notification requirements that have been challenged by industry, such as who should report, to whom, how often, under what circumstances, and in what timeframe.

The defence industry sector, the data storage and processing sector, and the space and technology sector are three areas targeted in the Security Legislation Amendment (Critical Infrastructure) Bill 2020, although it appears the Bill is likely to impact businesses in these areas in very different ways. The government has stated that the current DISP defence security mechanisms are sufficient to manage obligations for the majority of the defence industry, and the infant space industry has no assets to regulate yet, aside from those already covered in other sectors. Conversely, the data storage and processing sector has warned that, given the degree of overlap in regulations and the number of cross-sector customers that use data storage and processing services, there is a high likelihood that the data storage and processing sector could be “subject to the regulations and responsibilities of all regulated sectors simultaneously”.

DISP Sufficient for Defence Industry

Little has been made available in relation to Defence Industry responses to the Bill, which may be among the 30 submissions to government that remain confidential. The Bill defines the defence industry sector as supplying or producing goods, technology and services that (a) maintain Defence’s capability advantage, or (b) are limited by Defence due to their potential impact on Defence interests. This definition is intended to exclude industry entities captured under other sectors, such as electricity or water, while including organisations which provide or support a critical defence capability. The Exposure Draft Explanatory document defines critical defence capability as including material, technology, platforms, networks, systems, and services that are required in connection with the defence or national security of Australia.

Under the Draft Asset Definition Rules, any organisation providing or enabling a critical defence capability under a contract to the Department of Defence or the Australian Defence Force may be a critical defence industry asset. The government has noted that, while critical defence industry assets may be subject to each of the Positive Security Obligations, the Department of Defence may continue to manage obligations under its current Defence Industry Security Program (DISP) framework. The DISP framework manages the security and resilience of critical defence industry assets via a non-regulatory risk management program run by the Department of Defence.

Defence industry stakeholders, including peak bodies and federal, state and territory representatives have been invited to work with government in co-designing the rules to shape the requirements for a risk management program that may be ‘switched on’, if required, under the Bill. However, the government has stated that the existing defence security mechanisms under the DISP are considered sufficient for the majority of the defence industry. As a result, it is unlikely that the risk management program will be ‘switched on’ for the majority of businesses that fall within the defence industry asset class.

Can You Hear Me, Major Tom?

The addition of the Space and Technology sector to the list of Critical Infrastructure is a move intended to future-proof the security of an industry that is expected to become increasingly critical. The Trusted Information Sharing Network Space Cross-Sectoral Interest Group have asserted that the legislation needs to cater for significant growth and transformation in the sector.

The explanatory document accompanying the exposure draft of the Bill states that the space technology sector “involves the commercial provision of space-related services, and reflects those functions that are critical to maintaining the supply and availability of space-related services”. However, in sharing their views on the relevant aspects of the Exposure Draft of the Bill, the Philippines Space Agency suggested that the definition of the sector may not encompass critical non-commercial aspects, such as government owned satellites and other space technologies.

It is anticipated that the types of space and technology assets that may be designated as critical will include assets relating to position, navigation, and timing of space objects, space situational awareness services, space weather, space communications, tracking and control, earth observation, and facilitating access to space. However, the Bill does not include a specific definition of a critical space technology asset, because the only existing critical space technology sector assets identified are communications assets which are already covered under the proposed definition of critical telecommunications assets. Further assets may be prescribed under subsection 9(2) of the current SOCI Act as the space sector evolves and more critical assets are identified.

When Criticality Met Privacy

The data storage and processing sector is defined as the sector providing data storage or processing services on a commercial basis. Data storage or processing services may include enterprise data centres, managed services data centres, colocation data centres, cloud data centres, infrastructure as a service (IaaS), software as a service (SaaS), or platform as a service (PaaS).

To be classed as a critical data storage or processing asset, the asset must be owned by a data storage or processing provider and provide services either to government, a body corporate established by law, or a critical infrastructure asset which uses the service for business-critical data. AWS has suggested an amendment to the definition of critical data storage or processing asset in the Bill to include a simpler threshold, such as power usage or number of server racks, and that the definition of asset be limited only to physical infrastructure.

Regardless of the threshold, organisations may not be aware whether they meet this definition or that they have Critical Infrastructure clients, as they often do not have visibility over client data due to privacy requirements. Subsection 12F(3) of the Bill requires entities responsible for Critical Infrastructure to inform their data storage or processing service provider if they meet the definition of a commercial service provider to Critical Infrastructure for business-critical data. However, CISCO has suggested that a more thorough approach would be for government and industry work together to map supply chains to enable the relevant regulators to notify cloud service providers that they are providing services to Critical Infrastructure.

Critical Mass

Every sector has raised concerns about broad and vague definitions within the Bill, and the data storage and processing sector is no different. According to AWS and the AIIA, there are a number of other definitions which, as drafted, are ambiguous, too easily triggered, confusing, and will lead to over-notification and increased compliance costs. For example, the government has stated that the intention of the definition for business-critical data is to capture a critical infrastructure asset’s crucial operational information which, if compromised, would affect the availability or reliability of the asset, or have national security implications. However, Amazon Web Services (AWS) asserts that the government’s intentions are not carried by the definition of business critical data as (a) personal information that relates to at least 20,000 individuals, (b) sensitive information, or (c) critical infrastructure information relating to research and development, operations, or risk management. It is anticipated that the proposed thresholds will capture a minimum of 100 data centres and at least 30 cloud service providers.

The Australian Information Industry Association (AIIA) has asked the government to clarify the definition of ‘activities relating to business-critical data’, while AWS has labelled the definitions of critical data storage or processing asset and business-critical data as vague and unnecessarily broad. They argue that assets would fall into this category even if they are processing or storing business-critical data that is “only ancillary in nature”. In addition, AWS has recommended that the definition of cyber security incident should apply only if the incident has a systemic or broad impact to the relevant critical infrastructure asset and is a direct result of a third party’s malicious actions.

 That’s Not My Cloud

Data storage and processing is a cross-cutting sector, a feature that appears to have been overlooked by government. In cloud environments, for example, responsibility for security is frequently shared between the provider and customer, where the cloud services provider is responsible for “security of the cloud,” and the customer is responsible for “security in the cloud”. Such sharing of security responsibility is not clearly reflected in the Bill.

It has been recommended that an amendment be made to clarify that a cyber security incident only occurs in respect of a data storage or processing services provider or its customer when the incident occurs in their respective areas of responsibility. CISCO has further suggested that cyber security incidents for cloud and data processing entities continue to be reported to customers, who would then report to the Australian Cyber Security Centre (ACSC) as part of their own Positive Security Obligations. CISCO argue that this will maintain the confidentiality of customers while still providing the ACSC with appropriate visibility.

Let’s Split the Bill

The government continues to use strong language to emphasise the urgency with which it feels the Security Legislation Amendment (Critical Infrastructure) Bill must be passed in order to avoid a potential “cyber Pearl Harbor”. The task government originally set itself was to achieve sufficient security uplift across a disparate group of sectors and industries, using broad legislation, within a limited timeframe. Across the sectors, organisations have raised a chorus of objections to the lack of specificity, the degree of overlap with existing regimes, and the lack of guardrails on broad powers proposed in the Bill. Upon review of the situation, the Parliamentary Joint Committee on Intelligence and Security (PJCIS) has suggested splitting the Bill in order to satisfy the urgent requirement for intervention powers to counter any significant impending threat, while also addressing the legitimate concerns from current, and soon-to-be, Critical Infrastructure owners and operators.

Whilst this compromise may be viewed more favourably than the alternative, it remains to be seen whether the numerous concerns about the government powers will be addressed to the satisfaction of the impacted sectors, if a splitting of the Bill occurs. Despite the benefits of splitting the Bill, there still remains a lack of clarity on reporting mechanisms and which existing regulatory regimes might be leveraged to avoid duplication of effort. Many sectors are also still very concerned about the prospect of government software and interference in systems and the associated business and risk impacts.

Even with a splitting of the Bill, there is still the risk of a one-size-fits-all approach to the government assistance mechanisms and mandatory notification requirements that will have different implications for different sectors. Although still subject to the Positive Security Obligations, critical defence industry assets will likely continue to manage their obligations under the DISP framework, with the risk management program remaining switched off for the majority of defence industry businesses. Meanwhile, the application of government assistance mechanisms and mandatory notification requirements to the data storage and processing industry is fraught with difficulties due to its complex and globally distributed nature, existing privacy requirements, and the shared control and responsibility models used between providers and customers.

The defence industry remains publicly mute on the Bill, while cloud and data storage providers are strongly calling out the shortcomings of the legislation as it applies to their business, some even calling for an elimination of the sector from the Bill entirely. If the PJCIS recommendation to split the Bill is undertaken, it remains unclear if and how this feedback will be managed by the government.


Critical Infrastructure 5 of 6

September 25, 2021Published by Jeffrey Eaton
Critical Infrastructure – Part 5

Author: Mel Griffiths

Dams and Dollars: The Impact of the Critical Infrastructure Bill on the Finance and Water Sectors

The overall objective of the Government’s Security Legislation Amendment (Critical Infrastructure) Bill is to ensure that Australia’s Critical Infrastructure is secure; however, the expansion of critical sectors in the Bill has underscored not only the complex interconnections between industries and sectors, but also the number of existing regulatory frameworks that need to be leveraged, or at least considered, to make the amendments work as efficiently as possible. The co-design consultation for sector-specific obligations that will underpin the risk management program is currently underway for the Financial Services and Markets (payment systems) sector and has been completed for the Water and Sewage sector. However, some aspects of the Bill may be passed before others if the compromise suggested by the Parliamentary Joint Committee on Intelligence and Security (PJCIS) is implemented. The PJCIS has recommended that the Government urgently pass the portions of the Bill that focus on Government assistance mechanisms and mandatory notification requirements, while introducing the remaining aspects under a separate Bill following further consultation.

The thinking appears to be that this would enable the swift passage of laws to counter current threats, while also providing additional time for co-design with industry. However, many of the concerns of the Water, Finance, and other sectors, centre around the Government’s proposed intervention powers (assistance mechanisms) which essentially allow the Government to shut down, change, analyse, remove, and control a piece of infrastructure and its component parts if an attack on that asset is perceived to put national security at risk. When discussing the Government’s proposed intervention powers in the Security Legislation Amendment (Critical Infrastructure) Bill, it is important to be aware of the counterbalances in place.

I’ve Got the Power

Most of the intervention actions cannot be undertaken without ministerial authorisation approved by the Prime Minister and the Minister of Defence, and only in the event of an attack on critical infrastructure impacting national security. Affected organisations can be ordered to perform internal or external audit of the security of their systems, and to report on systems either regularly or based on an event. Interestingly, if the information in the reports is potentially incriminating to the company or an individual, it cannot be used for criminal or civil proceedings unless they relate to the Act. The Government can also require that an organisation install, maintain and, wherever possible, keep online software for collecting and recording computer operation information to determine if further powers under the act should be exercised. Personal information is still protected by the Privacy Act 1988 in these circumstances.

The proposed powers also allow Government to intervene in systems for analysis including adding, removing, or modifying installed programs, and connecting computers to the organisation’s systems. Under some circumstances, the Government may order an organisation to take or refrain from taking certain actions, request access to premises, or take equipment for analysis. If access to premises is refused, the Government may engage the police, but cannot engage in force against an individual.

Is All This Really Necessary?

Most sectors have voiced their concern regarding the extent of the powers provided to Government in the Bill and the lack of conventional rights of appeal and oversight. The Water sector have stated that this “erodes natural justice and provides significant concerns in relation to potential regulatory over-reach and poor community outcomes”. For example, the Bill allows for Governmental intervention based on Ministerial authorisation, which would potentially allow an intervention order to be made prior to an event without the involvement or knowledge of the impacted organisation.

The Water sector have argued that there needs to be provision for notification and cooperation prior to an intervention, which should only be implemented in the event of non-cooperation or lack of response capability on the part of the Critical Infrastructure owners and operators.

The Australian Banking Association (ABA) have also voiced concern regarding the Step In powers, stating that the potential for implementing software and/or running scripts in intricate banking technology environments and networks is extremely high risk. Given the complexity and time-sensitive nature of banking systems and networks, there are fears that the potential impacts of interventions may not be easily defined and could unintentionally degrade system security or operate beyond the authorised scope. The Water sector have pointed out that Section 30DJ the legislation allows the Government to install software without any liability for potential damage that may be caused to systems, and has argued for a right of appeal or ability to recover costs.

The powers of physical entry have also raised some questions for the Australian Banking Association (ABA). The Government has indicated that such powers of entry would only be enforced on Australian soil, however, as the ABA has noted that “entry and action on Australian premises could create a connection to… overseas data centres and raise questions about liability under foreign law including regulatory obligations and contractual liability”. Consider a hypothetical scenario in which an Australian financial sector entity is using Amazon to host both their critical systems and their main corporate portal for customers to access. The entities systems and data in the cloud are replicated across different regional availability zones and they use a Security as a Service (SaaS) product provided by a company located in India. If an attack were to occur within the Amazon infrastructure or against the SaaS in India in such a scenario, it is not clear whether the Government would seek to gain access to Amazon or the SaaS infrastructure and premises, where and how access might occur, and which entity would have obligations to ensure this would be possible.

The Australian Financial Markets Association (AFMA) have called for robust checks and balances against these powers, particularly in regard to what clear evidential grounds would be sufficient to satisfy the Government that ministerial action would be warranted. The AFMA have made it clear that in their view, APRA regulated entities have the maturity and sophistication to warrant the ministerial ‘on switch’ for activating the Positive Security Obligations for a critical infrastructure to be kept ‘off’ for these entities. The AFMA have also warned that justified use of intervention powers should not promote distrust in industry cyber capabilities.

Burn After Reading

The Australian Banking Association (ABA) has noted that the information the Bill will require to be provided to government may be sensitive. They have raised questions over how such information will be protected throughout its lifecycle, arguing that legislation should detail its classification, handling, storage, retention and destruction. There is also concern from industry that the provision of the Bill to collect information may be broader than the stated intention of Government policy. Industry understands that the intention of the Government is to ask for data logs, excluding information or documents that may be under third party Intellectual Property. Given this understanding, the ABA has requested that an amendment be made to Section 30DB so that it expressly applies to data logs only, with third party IP exempted, and that entities may refuse to comply with some or all of a request for information that goes beyond this.

The Critical Infrastructure legislation makes it an offence to disclose some protected information, such as when as asset has been declared by the Government to be a System of National Significance (SoNS). However, the ABA has asserted that not all scenarios where an entity has a legitimate reason for disclosing information have been addressed. They have proposed that section 46 be amended “to permit an entity to disclose protected information, if the entity reasonably believes that doing so would assist the entity to comply with its obligations under the SOCI Act, other Australian and overseas law, or if the entity reasonably believes doing so is required under contract.”

The Financial Services Council (FSC) has rather gloomily predicted that, based on the exposure draft, the Bill will result in “another regulatory agency being imposed on financial services without a requirement for a streamlined approach with other agencies that already operate in financial services”. The FSC is not the first to note the degree of overlap and duplication of the Bill with existing frameworks.

One Size Fits None

The ABA has highlighted the need to eliminate differences between proposed requirements and existing regulatory regimes, particularly under prudential regulation. Financial Services Prudential regulations are the current benchmark in the Financial Sector. The Australian Prudential Regulation Authority (APRA) is an independent statutory authority that supervises institutions across banking, insurance, and superannuation, and is accountable to the Australian Parliament. Fundamentally, the Financial Services sector feels that the new regime under the Bill should defer to APRA’s existing financial sector regulatory obligations. These include CPS 220 Risk Management, CPS 234 Information Security, CPS 232 Business Continuity, and CPS 231 Outsourcing. Under the APRA prudential standard CPS 220, the Board of an APRA-regulated institution is required to provide APRA with a risk management declaration within three months of its annual balance date.

As it currently stands, the Bill would require an additional annual risk management program report to be submitted within 30 days. There is concern that Prudential Standard overlap with the requirements of the Bill will result in organisations having to prepare two reports with substantially the same information and adopt two distinct procedures for approval and sign off for the reports. The Australian Institute of Superannuation Trustees (AIST) has stated that the requirement to produce an annual report in this timeframe will put significant pressure on superannuation fund staff during an already demanding period.

Not only does the Financial Services sector feel that this would result in a substantial increase of the compliance burden without any meaningful difference in personal accountability of Board members, but that it is also inconsistent with the requirements under CPS 220 by requiring each Board member to sign the risk management program annual report. AIST has argued that such a requirement may be impractical, particularly if superannuation funds are required to do so 30 days after the end of the financial year. As a result, the Financial Services Sector has urged the Government to consider leveraging existing sector regulations covering similar board approval requirements.

Another imposed timeframe raising concerns is the proposed six-month period which organisations have to comply with the provisions of the Bill. The Water Services Sector Group (WSSG) has suggested that the six-month timeframe for compliance with reporting obligations may be insufficient and has suggested that this be amended to provide organisations with six months to provide an agreed implementation timeline.

We’ve Already Got One and it’s Very Nice

In their responses to the Draft of the Bill, many industries have pointed out to Government that they already have existing regulatory regimes and standards that adequately manage the risks to their assets. For example, the New Payments Platform (NPP Australia) have suggested that an asset should only be identified as critical to a critical payment system if the asset is already identified as a SIPS (Systemically Important Payment System). A SIPS is a payment system which, if attacked, could potentially endanger the operation of the whole economy, and are expected to observe the Principles for Financial Market Infrastructures issued by the CPMI and IOSCO. The Reserve Bank Information and Transfer System (RITS), used by banks to settle payment obligations, is the only system that has been determined to be a SIPS. This is not the only example where industry feels that the Bill may disrupt current best practice.

APRA Prudential Standard CPS 234 has been adopted as the cyber security benchmark for the Australian banking sector and is seen as driving appropriate levels of visibility, funding, and support to cyber security in the Financial Sector. As many organisations have undertaken significant work to respond to the APRA CPS 234 requirements, the Australian Banking Association (ABA) has asked Government to consider modifying the reporting requirements for cyber-security incidents in the Bill to match APRA CPS 234 for APRA regulated entities. However, there are several significant misalignments that need to be addressed.

For example, APRA CPS 234 requires an entity to notify APRA as soon as possible and, in any case, no later than 72 hours of a cyber incident, whereas the Critical Infrastructure Bill will require critical cyber incidents to be reported within 12 hours. The Water Sector has noted that the 12-hour reporting timeframe is also inconsistent with international good practice, such as the US National Institute for Standards and Technology (NIST) 800-53 Standard. Both NIST and APRA standards require reporting within 72 hours and the Water and Finance sectors are agreed that this requirement in the Bill should be aligned accordingly.

Apart from critical incidents, all other cybersecurity incidents are required by the Bill to be reported within 24 hours. The Water sector has argued that this obligation places additional regulatory burden on entities, particularly over weekends and holiday periods, and has recommended that the Government restrict reporting to significant risks only. Financial Services Council (FSC) has also urged the Government to revise these timeframes from 24 to 72 hours from the time of becoming aware of a confirmed incident.

In addition to incident reporting timeframes, there have also been calls from both the Financial Services Council (FSC) and the Australian Banking Association (ABA) for Government to clarify the types of incidents that would be covered by sections 30BC and 30BD of the Bill, and to align them with the incidents covered by the term information security incident in CPS 234. Another suggestion aimed at reducing the burden on industry whilst maintaining the integrity of the regime, is that Government agencies share incident reports to avoid imposing duplicate reporting obligations under different regimes. For example, where information on serious cyber security incidents has already been reported to a government agency (such as reporting to APRA under CPS 234), other agencies should seek to obtain the information intra-governmentally.

It Does Not Mean What You Think it Means

As with other areas of industry, there has been much discussion in the Finance and Water sectors of the appropriateness of the definitions in the proposed legislation. The Water Services Sector Group (WSSG) summarised this issue, stating that the uncertainty created by the vague terminology of the Bill undermines industry’s capacity to assess potential compliance costs. This is particularly concerning given the provision for penalties for noncompliance. The consensus from industry indicates that the Government has some work to do to ensure that terms are clear, precise, and that sectors fully understand the activities and costs associated with compliance.

For example, the definition of direct interest holder is expected to capture financiers, including banks, according to the Australian Financial Markets Association (AFMA). This is because banks may have a security position in assets that fall within the scope of the Bill, which means they would be subject to both the reporting requirements with respect to the Register of Critical Infrastructure, and the civil penalties for non-compliance. As a result, the Australian Financial Markets Association (AFMA) has suggested that banks and other lenders should be excluded from the definition of direct interest holder.

The Australian Institute of Superannuation Trustees (AIST) has taken issue with the definition of a critical superannuation asset, which is intended to capture funds with Funds Under Management (FUM) of $20 billion or more. However, the AIST notes that a fund’s FUM can increase or decrease over time, where a fund may have FUM of $19 billion in one year and experience an increase the following year, putting the fund over the $20 billion threshold.

The Australian Banking Association (ABA) has emphasised that the Bill’s definition of business critical data is overly broad and there are fears that, as it stands, the definition will capture a significant proportion of an organisation’s supply chain. In their submission in response to the exposure draft of the Bill, the ABA have also sought clarification as to whether or not the definition of the Data Storage and Processing Sector is intended to capture banks or other organisations that may hold data or provide data storage as an adjunct part of its business.

 

The Writing on the Wall

The consultation phase of the Security Legislation Amendment (Critical Infrastructure) Bill has underscored the complex interconnections between industries and sectors. It has also revealed that there are a number of existing regulatory frameworks that need to be leveraged, or at least considered, if the amendments are to work as efficiently as possible.

It is unclear whether the Government will manage the differences between the Bill and existing regulatory regimes and standards through consultation and integration, or by imposing requirements regardless of existing benchmarks, overshadowed by the threat of penalties for non-compliance. Sectors have also raised a great deal of concern regarding the extent of the powers provided to Government and the lack of conventional rights of appeal and oversight. There has been no indication from Government that any amendment to rights of appeal is being considered.

Many submissions in response to the Bill’s draft from across the impacted sectors have commented on the adversarial tone of the legislation, indicating that it lacks the spirit of cooperative engagement that Government and Critical Infrastructure owners and operators have a strong history of. The feedback from industry is that the Government needs to ensure that terms are clear and precise, that sectors fully understand the activities and costs associated with compliance, and that existing frameworks should be accommodated by, and integrated into, the legislation.

If the Government is not able to achieve this, it may not only result in increased cost and regulatory burden, bureaucratic overlap, jurisdictional disputes, and unintentional non-compliance, but may also require the Government to use Step In powers to defend Critical Infrastructure whose security has suffered from these inefficiencies.

However, the Government also needs to balance the potential of that outcome with the increasingly frequent and sophisticated cyber threats levelled against Critical Infrastructure. A compromise has been suggested by the Parliamentary Joint Committee on Intelligence and Security (PJCIS), recommending that the portions of the Bill that focus on Government assistance mechanisms and mandatory notification requirements should be passed with urgency, while the remaining aspects of the Bill should be introduced under a separate Bill following further consultation. It remains to be seen whether this recommendation will be implemented by Government or welcomed by industry.