Russian Ukrainian Conflict, Wiper Malware, and SBOM
Written by Jane Lo, Singapore Correspondent.
OT-ISAC (Operational Technology Information Sharing and Analysis Centre), established under Pillar 2 of Singapore’s Operational Technology Cybersecurity Masterplan, and launched at the Singapore International Cyber Week 2019, saw the first physical annual summit after 2 years of virtual gatherings.
Under the theme of “Breaking Barriers: Collaborative Defence in Protecting Critical Infrastructure,” it brought together more than 200 Operational Technology/ Information Technology (OT/IT) experts and practitioners to share best practices and lessons learned.
Here are a couple of highlights from the 2-day summit (7th Sept – 8th Sept 2022).
2022 Russian-Ukraine conflict
With the Russia-Ukraine conflict still on-going, conversations on securing critical infrastructure inevitably touched on use of cyberspace by nation states to achieve strategic advantages to support traditional military goals.
Looking at the cyber-attacks from the conflict, many would immediately draw comparisons to past cyber incidents that targeted Ukraine.
Frequently mentioned are the 2015 Black Energy and 2016 “Industroyer” attacks which caused black-outs in parts of Ukraine for hours.
The tool-sets behind these attacks, commonly linked to the Russian threat actor group “Sandworm”, evolved and re-surfaced in the 2022 Russia-Ukraine conflict as “Industroyer 2”.
“Surveillance and audio recording”, “data exfiltration”, “propaganda”, “SATCOM & communications” disruptions are other reported cases of Russian cyber-attacks against Ukraine critical infrastructure in 2022, said Bill Nelson (Chairman, Global Resilience Federation; Director, OT-ISAC), at his keynote presentation, “Cyber Attacks Resulting from the Russian Ukrainian Conflict: CI Impact and Response”.
More seriously, four variants of destructive wiper malware that “destroy data files, devices, networks, systems, applications” were also detected, he noted.
In fact, Russian threat actors had previously deployed wiperware to disrupt operations, in the 2017 NotPetya incident, which shut down several Ukrainian government ministries, metro systems and banks.
Notably, spreading beyond the geographical borders of Ukraine and across industry sectors, it hit multinational organisations such as the shipping giant Maersk Line, the global pharmaceutical Merck, and an international law firm DLP Piper.
Supply chains and the importance of software asset discovery
NotPetya highlighted how malicious actors can target a supplier integral to the digital infrastructure and trigger a chain reaction that compromise multiple organisations and cause wide-spread disruption.
Recent high-profile incidents such as SolarWind and Log4Shell further exemplified the multiplier effect of these so-called “supply chain” attacks.
They also underscored the importance of software asset discovery. In other words, does the organisation have an inventory of software code in their applications? When a zero-day exploit or a vulnerability on a piece of software code is disclosed, does the organisation have a complete view of its software assets so as to assess its risks and act quickly?
Clearly, answering these questions requires having the visibility into the components, libraries, and modules in the software.
For example, in the wake of Log4Shell, SingCert (the Singapore Computer Emergency Response Team, part of the Cyber Security Agency of Singapore) pointed to “the importance for organisations to review their application portfolios and maintain accurate software bill of materials, so that affected products or services can be swiftly identified and fixed.” [1]
The importance of software bill of materials was also highlighted at the summit.
“Software bill of materials” (SBOM)
Similar with the ingredients that we see on a food label, “software bill of materials” (or “SBOM”) “is a nested inventory, a list of ingredients that make up software components,” according to CSIA (United States Cybersecurity & infrastructure Security Agency) [2].
This process of identifying these components – whether they are in-house, open source, off-the-shelf or contracted third party – is a well-recognised challenge for a typical software.
But “this problem is magnified significantly when it comes to the Operational Technology (OT) space,” said Tom Pace (CEO and co-founder, NetRise) at his presentation “Uncloaking the mysteries of SBOM creation”.
Firmware that power devices providing key functionalities in critical infrastructure “are often treated as a black box”, he said. In many cases, there is no bill of materials.
Compounding the problem, is that the device manufacturer often uses third parties for specific components, and thus also faces the challenge in confidently cataloguing the artifacts in its own devices.
Without such knowledge or SBOM, devices that run firmware with disclosed vulnerabilities may not be easily identified.
In fact, “many of these devices have no information logged in the National Vulnerability Database or other common sources of vulnerability intelligence,” he said.
“This problem has created a situation where certain organizations happen to be sitting on a treasure trove of vulnerabilities that exist within millions of devices globally unbeknownst to the end users,” he added.
For example, Pipedream was noted by Dragos [3] to have the capability to “impact a wide variety of Programmable Logic Controllers (PLC) and industrial software,” including “poorly configured Open Platform Communications Unified Architecture (OPC-UA) servers.”
This means potential impacts to devices operating the OPC-UA standards – ranging from field devices (e.g. sensors, actuators), to equipment such as the Supervisory Control and Data Acquisition (SCADA).
Takeaways
The Russian-Ukrainian conflict epitomises the fusion of cyber and kinetic operations by nation states, and how ICS infrastructure continues to be an attractive target to cause wide-spread disruption and chaos.
As NotPetya, and incidents such as SolarWind and Log4j demonstrate how quickly impacts can spread beyond primary targets, OT/IT security professionals in the critical infrastructure sectors are no doubt constantly assessing their organisation’s cyber risk posture.
Increasingly, this necessitates not only forming a complete picture of the diverse devices running the organisation’s operations, but also addressing the organisation’s blind spots when it comes to the firmware of these devices.
With the attention paid to SBOM given the United States Presidential Executive Order 14028, there is arguably no better time for the organisation to seize on the momentum gained and start securing its firmware inventory with SBOM.
Listen here to the interview with Bill Nelson (Chairman, Global Resilience Federation; Director, OT-ISAC) on
“Cyber-attacks resulting from the Russian – Ukraine conflict, critical infrastructure impact and response in Asia”
[1] SingCert, “The Log4Shell Vulnerability”, 05 January 2022, https://www.csa.gov.sg/singcert/Publications/the-log4shell-vulnerability
[2] Cybersecurity & infrastructure Security Agency, “Software Bill of Materials”, https://www.cisa.gov/sbom
[3] Dragos, 2022, https://www.dragos.com/blog/industry-news/chernovite-pipedream-malware-targeting-industrial-control-systems/
[4] The White House, 12 May 2021, https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
