My recent conference presentation on open-source security revealed a common theme. Audience members didn’t realise how pervasive open-source is. Everyone in the audience knew that their organisation uses a fair number of open-source components, but they thought that it only makes up a small percentage of their applications, at around 30% or less.
The truth is that open-source makes up the bulk of your applications. Industry reports have estimated that 85% of modern applications are built from open-source components. The percentage is higher for modern JavaScript web applications, with 97% of the code coming from open-source components. My analysis has found those numbers to be a low estimate, with the percentage for Java applications at around 98%. What was surprising was around three quarters of those open-source components were not explicitly incorporated into their applications, they were transitive dependencies. And with organisations embracing generative AI for software development, that 2% of custom code might not even be written by their developers.
Total Open Source Request over 6 years (Source: 9th Annual State of Software Supply Chain Report)
Our use of open-source software is growing exponentially, with the number of download requests exceeding 4 trillion last year, almost doubling from two years ago. But a critical caveat exists, not all open-source offerings are created equal. Around 500 billion download requests made last year were for components with known risk. This is around 1 in 8 downloads of components that have one or more identified security vulnerabilities. Log4j is one such component. It had a critical vulnerability that was disclosed in December 2021 and resulted in most organisations enacting their incident response plans. Today, around 35% of download requests for log4j are for vulnerable versions. That’s 1 in 3 downloads. Why are we still downloading open-source components with known risk, especially components like log4j? I believe that for most organisations, they are unaware of their open-source consumption, especially for transitive dependencies.
Do you know your organisation’s open-source consumption? Do you have a software bill of materials? If you don’t then you’re probably using more open source than you realise.
By taking proactive steps to illuminate and manage open-source usage, organisations can harness the power of open source while mitigating associated security risks.
Since I started in Cybersecurity, I have observed that cybersecurity has become dominated by insincere vendors and practitioners driven solely by profit. As a cybersecurity leader, I have also noticed the increasing commoditisation of cybersecurity over the years, and it’s important for us to address this issue.
Going deeper into the motives, I realised the significance of my blog’s title. Initially, I chose the name to reflect the current state of cybersecurity, where my work felt repetitive and inconsequential, like an assembly line. However, regardless of the organisation, the same recurring non-technical issues persisted.
The primary challenge lies in the way security practitioners interact with the people they are meant to protect within these organisations. Those outside the security team are often victim-shamed and blamed for their perceived ignorance as if they are at fault for not prioritising cybersecurity in their daily work.
Security organisations sometimes oppress the very people they are meant to serve. This behaviour struck me as counterproductive and degrading, particularly as I familiarised myself with nonviolent communication and other conflict-resolution techniques. I wondered whether adopting peacebuilding methods could foster collaboration and alignment among stakeholders. While only a few security practitioners initially showed interest, the transition to DevOps and shift left strategy, emphasising these attributes, attracted like-minded individuals.
Additionally, the way users are treated is like the punitive and shaming approach commonly seen in the criminal justice system. However, this approach has not reduced crime or supported victims. On the other hand, restorative justice, which focuses on repairing the harm caused by crime and restoring the community while respecting the dignity of all involved parties, has shown promise.
Evidence suggests that traditional fear-based and shaming tactics have not effectively promoted user compliance in cybersecurity. Instead, creating a supportive workplace environment has been identified as a more practical approach to encouraging voluntary security behaviours.
In the rapidly evolving landscape of cybersecurity, organisations must adapt their approaches. Rather than relying on fear, uncertainty, and doubt (FUD)-based strategies, we must acknowledge the value of users as allies and reposition cybersecurity as a collaborative effort. This involves a fundamental shift in the industry, prioritising collaboration, understanding, and support to foster a culture of proactive cybersecurity measures. By moving away from fear-based tactics and embracing a more cooperative approach, organisations will be better equipped to mitigate threats and safeguard information.
On 10th Dec 2021, a zero-day vulnerability was announced in Apache’s Log4j library, which has made Log4shell one of the most severe vulnerabilities since Heartbleed. Exploiting this vulnerability is trivial, and therefore we have seen new exploits daily since the announcement. Some of us will be spending this holiday period mitigating this vulnerability.
Since the announcement last weekend, a lot has been written about Log4Shell. Researchers are finding new exploits in the wild and are adjusting the response. I am not trivialising the extent and impact of this vulnerability with the title of this post. Still, I would like to suggest taking a step back, bringing some calm and strategising the mitigation plan. We are in the early stages of the response, and if the past week is any indication, we are here for the long haul.
In this post, I will be focussing on the two aspects of this zero-day. Technical aspects, for sure, is paramount and requires immediate attention. However, the long-term governance is equally important and will ensure that we are not blindsided with that one insignificant application, which was ignored or seen as low-risk.
So, what is Log4Shell vulnerability?
Apache’s Log4j API1, an open-source Java-based logging audit framework, is commonly used by many apps and services. As a result, an attacker can use a well-crafted exploit to break into the target system, steal credentials and logins, infect networks, and steal data. Due to the extent of the use of this library, the impact is far-reaching. In addition, log4j is used worldwide across software applications and online services, and the vulnerability requires very little expertise to exploit. These far-reaching consequences make Log4shell potentially the most severe computer vulnerability in years.
The “Log4Shell” (CVE-2021–44228) is the name given to the vulnerability in the Log4J library. Apache Log4j2 2.14.1 and below are susceptible to a remote code execution vulnerability where a remote attacker can leverage this vulnerability to take full control of a vulnerable machine. The Log4Shell vulnerability is exploited by injecting a JNDI2 LDAP3 string into the logs, triggering Log4j to contact the specified LDAP server for more information.
In a malicious scenario, the attacker can use the LDAP server to serve the malicious code back to the victim’s machine, which will then be automatically executed in the memory. Data injected by an untrusted entity for merely logging into a file can take over the logging server. What this means for you is an instruction to log activity, but if exploited can soon become a data-leak scenario or run the malicious code for once scenario.
Simply, an event log intended and required for completeness could turn into a malware implantation event. This is nasty and requires taking all necessary steps to ensure that you don’t fall victim to this malicious scenario.
Am I affected?
Overwhelmingly “yes”, unless proven otherwise. Almost every software or service will have some sort of logging capability. Software’s behaviours are logged for development, operational and security purposes. Apache’s Log4j is a very common component used for this purpose.
For individuals, Log4jshell will most certainly impact you. Most devices and services you use online daily will be impacted. Keep an eye on the updates and instructions from the vendors of these devices and services for the next few days and weeks. As soon as the vendor releases a patch, update your devices and services to mitigate the risk associated with this vulnerability.
For businesses, it is going to be very tricky, and the true impact may not be clear immediately. In addition, even though Apache has already recommended upgrading to Version 2.17, there may be various implementations of the Log4J library. So again, keep an eye on the vendors releasing patches and installing as soon as possible.
How to find if your server is impacted or not?
The answer to this question is not straightforward. It is challenging to find if a given server is affected or not by the vulnerability in your network. You might assume that only the public-facing servers running code written in Java handle incoming requests handled by Java software and the Java runtime libraries. Then, for sure, you can consider yourself safe if the frontend is built products such as Apache’s-HTTPd web server, Microsoft IIS, or Nginx as all these servers are coded in C or C++.
As more information is coming on the breadth and depth of this vulnerability, it looks the Log4Shell is not limited to servers coded in Java. Since it is not the TCP-based socket handling code vulnerability, it can stay hidden in the network where user-supplied data is processed, and logs are kept even if the frontend is a non-java platform, you may get caught between what you know and all those third-party java libraries that might make part of the overall application code vulnerable to this vulnerability.
Ideally, every application on your network must be evaluated that is written in Java for the Log4j library. You can take the following two approaches:
Search for Vulnerable Code: Initiate a search for vulnerable code by scanning all servers and applications for vulnerable versions of Log4j libraries. Since Log4j code could be buried deep inside a Java class, a basic search for Log4j will not be good enough. To be certain, you may have to use additional tools and techniques. There are two (2) open-source scanning tools available that can list out code versions or vulnerable code: • Grype (https://github.com/anchore/grype) — Searches libraries installed on a system and displays vulnerabilities present • Syft (https://github.com/anchore/syft) — Searches for installed code and libraries and displays their versions
2. Active Scanning of Deployed Code: Nessus with updated plugins can be used for active vulnerability scanning to identify if the vulnerability exists or not. Some security vendors have also set up public websites to conduct minimal testing against your environment. Following are some of the open-source and commercial tools that can be used for the active scanning:
How can I mitigate Log4Shell and prevent an attack?
In principle, the prevention and prevention techniques are no different from a response to any zero-day, for that matter. The vulnerability is both complex and trivial to exploit, and therefore, it doesn’t necessarily mean that the vulnerability can be successfully exploited. Some of several pre- and postconditions are met for a successful attack. Some of these pre-conditions, such as the JVM being used, the server/app configuration, version of the library etc., will decide successful exploitation. On 17th Dec, Apache Foundation announced the original fix was incomplete and released the second fix in version 2.17.0.
At the time of writing, this post following is the current list of vulnerabilities and recommended fixes: • CVE-2021–44228 (CVSS score: 10.0) — A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0) • CVE-2021–45046 (CVSS score: 9.0) — An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0) • CVE-2021–45105 (CVSS score: 7.5) — A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0) • CVE-2021–4104 (CVSS score: 8.1) — An untrusted deserialization flaw affecting Log4j version 1.2 (No fix available; Upgrade to version 2.17.0)
The Swiss Government’s CERT provides quite a good visualisation of the attack sequence recommending mitigations for each of the vulnerable points in the sequence.
Where from here?
Keep Calm and Carry On……. We are here for the long haul, and there is no easy fix. You may find that you have fixed one app or server today; something else will pop-up next morning. If you have not done it yet, the best will be to set up a generic incident response playbook for zero-day vulnerabilities. This will help you respond to any such event in the future in a systematic way. The key to success here is keeping an eye on the tools and techniques and their effectiveness to respond to any new zero-day.
As far as Log4Shell is concerned, we are still in the early days and can’t be sure that once patched, and there will never be something else. This is evident from the fact that in the last week or so since the announcement of the original CVE, three more have been attributed to Log4J libraries. As a result, the Apache Foundation has recommended the following mitigations to prevent the exploitation of vulnerable code.
First, upgrade vulnerable versions of Log4j to version 2.17.0 or apply vendor-supplied patches. Although, for some reason, if it is not possible to upgrade, some workarounds can be used. However, there is always some risk of additional vulnerabilities (CVE-2021–45046) that will make the workarounds ineffective. Therefore, it will be best to upgrade to version 2.17. In addition to the above, some of the common mitigations must be considered and applied. • Isolate systems must be restricted into their security zones, i.e. DMZs or VLANs. • All outbound network connections from servers are blocked unless required for their functional role. Even then, restrict outbound network connections to only trusted hosts and network ports. • Depending on your endpoint protection strategy, update any signature or plugin to prevent Log4j exploitation. • Continuous monitoring of networks and servers for any indicators of compromise (IOC). • It has been seen that even after the patch is implemented, vulnerability may persist. Therefore, testing and retesting after the patch is implemented must be ensured as part of the mitigation plan. The time we are living in, such events have become a norm. Vulnerable code, unfortunately, is inevitable, and there will always be someone who would be keen to identify such code to exploit for vested interest. It is only time when we will be hacked, and that one incident may disrupt your business. Therefore, it is paramount to develop and implement business continuity plans that can minimise the impact of such an event. These plans must be updated and tested regularly to ensure changing threat scenarios. Security incident response plans must be practised regularly as a “way of life” and adjusted when a new vulnerability or a threat scenario is identified.
In situations like Log4j zero-day, one can get overwhelmed with the sheer volume of work that we need to do to protect ourselves. As Huntress Labs Senior Security Researcher John Hammond said, “All threat actors need to trigger an attack is one line of text,” but the responders need to spend hours, days and weeks on protecting themselves. In such overwhelming scenarios, I will recommend taking a long breath and keeping calm while doing what we need to do. Reach out to people, and don’t be shy to ask for help if you are stressed. I wish all the best to all of you who will be required to stay back during the holiday to keep your businesses protected.
In today’s interconnected world, where industrial systems and critical infrastructure underpin the backbone of society, operational technology (OT) security has never been more crucial. As industries evolve, particularly within critical sectors such as energy, healthcare, and manufacturing, they increasingly rely on OT systems to control physical processes. However, these systems are also vulnerable to cyber threats, placing essential services and national security at risk. Operational Technology (OT) security architecture provides the blueprint for safeguarding these systems, ensuring that critical infrastructure remains resilient and functional despite sophisticated attacks.
With the introduction of the SOCI Act (Security of Critical Infrastructure Act) in Australia and similar legislative measures globally, a growing demand for robust security frameworks that protect against cyber threats is growing. The Australian market, in particular, has seen a heightened focus on OT security as organisations seek to comply with government mandates and protect vital infrastructure. In this blog, we’ll explore OT security architecture, its importance, and the key elements that ensure its effectiveness.
What is OT Security Architecture?
At its core, OT security architecture refers to the structured design and implementation of security measures to protect OT systems. These systems often include industrial control systems (ICS), supervisory control and data acquisition (SCADA) systems, and other technologies for managing critical infrastructure such as power grids, water treatment plants, and transportation networks. Unlike traditional IT systems, which handle data and communications, OT systems directly impact physical processes. Any disruption to these systems can lead to catastrophic consequences, including power outages, water contamination, or worse—mass casualties.
The rise of digital transformation has introduced new challenges. As OT systems become more interconnected with IT systems via the Industrial Internet of Things (IIoT) and other advancements, the attack surface for cybercriminals expands. This integration has made it easier for hackers to infiltrate OT environments, putting vital assets at risk. As a result, a comprehensive security architecture is needed to address the legacy systems and the evolving technological landscape.
What constitutes an Effective OT Security Architecture
1. Segmentation and Network Zoning
One of the fundamental aspects of OT security architecture is network segmentation and zoning. This involves dividing the OT environment into distinct zones based on function and security needs, ensuring that sensitive or critical zones are isolated from less secure areas.
For example, OT systems often include safety-critical processes, such as controlling power generation, and less critical systems, such as office networks. These should be segregated to prevent an attack on a lower-priority system from impacting core operations. A common approach is implementing a demilitarised zone (DMZ) that acts as a buffer between the OT and IT environments. Firewalls, intrusion detection systems (IDS), and other security measures should be deployed to monitor traffic and control access between zones.
According to a 2023 report by the Australian Cyber Security Centre (ACSC), 74% of attacks on OT systems could have been mitigated or prevented through proper network segmentation. This underscores the importance of maintaining strict controls over how different systems communicate with each other.
2. Real-time Monitoring and Incident Response
Real-time monitoring is essential in identifying threats before they have the chance to disrupt OT operations. Given the critical nature of OT environments, even minor disruptions can lead to significant downtime or damage. By implementing tools such as Security Information and Event Management (SIEM) systems and other monitoring solutions, organisations can detect anomalies and respond to threats in real-time.
In the Australian market, companies increasingly invest in Security Operations Centres (SOCs) that provide round-the-clock surveillance and incident response for OT environments. SOCs are vital in ensuring that security teams can swiftly respond to cyber incidents. Per the SOCI Act’s guidelines, organisations involved in critical infrastructure must maintain incident response capabilities and report any breaches to the government within a designated timeframe.
Moreover, incident response plans tailored to OT systems should be in place. These plans should account for the unique characteristics of OT environments, including the need to minimise disruption to physical processes during an attack. A coordinated response effort involving both IT and OT teams is essential for mitigating the impact of security incidents on critical infrastructure.
3. Adapting to the Legislative Landscape
In recent years, governments worldwide have introduced regulations to protect critical infrastructure. In Australia, the SOCI Act mandates that organisations managing critical assets implement robust security measures and report any significant security incidents. The Act covers a broad range of sectors, including energy, healthcare, water, and telecommunications, all of which rely on OT systems for their core operations.
Compliance with the SOCI Act involves not only the implementation of technical safeguards but also ongoing risk management practices. Organisations must conduct regular security assessments, patch vulnerabilities, and ensure that security measures are current. Failure to comply with these mandates can result in significant penalties and reputational damage.
The global focus on securing critical infrastructure has led to a sharp increase in investment in OT security. The 2023 Global Critical Infrastructure Security Market Report indicates that the OT security market is projected to grow by 7.5% annually, driven largely by government regulations and the increasing complexity of cyber threats. In Australia, this trend is particularly pronounced, with organisations investing heavily in technology and personnel to meet the requirements of the SOCI Act.
Case Study: Securing the Australian Energy Sector
To illustrate the importance of OT security architecture, let’s consider the case of the Australian energy sector. Energy companies rely heavily on OT systems to manage the generation, distribution, and transmission of power across the country. In recent years, several energy companies have faced sophisticated cyberattacks aimed at disrupting these processes. For instance, a 2021 report from ACSC revealed that a ransomware attack on an energy provider could have caused widespread blackouts if it hadn’t been for robust OT security measures.
The company in question had implemented a segmented network that isolated critical systems from less important ones. Additionally, real-time monitoring tools detected the threat early on, allowing security teams to neutralise the attack before any physical processes were impacted. This case underscores the value of investing in comprehensive OT security architecture.
Conclusion
The security architecture of OT forms the basis for ensuring the safety of our critical infrastructure. In today’s environment of increasingly sophisticated cyber threats, it is imperative for industries to implement comprehensive OT security measures to protect their operations and uphold national security. Crucial components such as network segmentation, real-time monitoring, and adherence to legislative frameworks like the SOCI Act are essential for safeguarding OT environments.
Given that Australia and the world at large rely heavily on OT systems to drive industries and deliver vital services, the significance of securing these systems cannot be overstated. For organisations operating in the Australian market, particularly those involved in critical infrastructure, the message is clear: invest in OT security architecture to prevent potential catastrophic disruptions in the future. If you want to learn more about how to protect your organisation’s OT environment and ensure compliance with the SOCI Act, contact our team of experts or subscribe to our newsletter for the latest updates on OT security trends.
