top of page

IDEA SEEDS

Search
  • yobie14

The Rise of Software Bill of Materials (SBOM) Charlatans | Y2K 2.0 But A Thousand Times Harder

by: Yobie Benjamin


Software supply chain attacks are an increasingly significant concern in the world of cybersecurity. They can lead to devastating consequences that extend far beyond mere inconvenience. Among the potential repercussions are immense financial losses, damage to a company's reputation, and even potential legal ramifications at the hands of regulatory bodies such as the Securities and Exchange Commission (SEC).


These consequences aren't just theoretical; they have played out in real-world scenarios, such as the now-infamous 2020 SolarWinds attack. The incident's lingering aftermath serves as a stark reminder of the severity and longevity of such attacks. The SEC has recently communicated to both current and former SolarWinds executives its intention to recommend "civil enforcement action," asserting that the company violated federal securities laws by issuing misleading public disclosures and falling short of maintaining adequate "internal controls."


The evolving threat landscape has led to a robust response from the federal government. President Joe Biden issued Executive Order 14028, titled "Improving the Nation's Cybersecurity," on May 12, 2021. The order, a comprehensive set of policies and guidelines, seeks to strengthen the United States' capacity to prevent, detect, and respond to cyber threats. This is a crucial step forward, given that both state-sponsored and independent cyber actors have shown their willingness and ability to exploit vulnerabilities in our digital infrastructure.


The executive order covers several key points and requirements:


1. Removing Barriers to Sharing Threat Information: The order mandates that IT and Operational Technology (OT) service providers must share specific breach information with the government. It further instructs the federal government to amend contracts with these providers to remove any contractual barriers to such disclosures. This provision is similar to how the healthcare industry shares information about infectious disease outbreaks, helping to contain and mitigate the impact.


2. Modernizing Federal Government Cybersecurity: The order calls on federal agencies to adopt secure cloud services, zero-trust architecture, and multifactor authentication. It also necessitates the use of encryption for data at rest and in transit. This requirement mirrors best practices in the private sector and places the government on the same footing as many tech-forward companies.


3. Enhancing Software Supply Chain Security: The order emphasizes the need to develop stringent standards for software sold to the government, including requirements for developers to maintain greater visibility into their software and ensure the public availability of security data.


4. Establishing a Cybersecurity Safety Review Board: This board, co-chaired by government and private sector leads, is tasked with reviewing and assessing significant cyber incidents. The objective here is to learn from each incident and improve future cybersecurity practices.


5. Creating a Standard Playbook for Responding to Cyber Incidents: The executive order directs the development of a standardized playbook and set of definitions for cyber incident response by federal departments and agencies. This standardized approach will help ensure a more coordinated response to cyber incidents.


6. Improving Detection of Cybersecurity Incidents on Federal Networks: It encourages enhancements in the detection of cybersecurity vulnerabilities and incidents on federal networks. This is akin to strengthening the radar system that detects incoming attacks, ensuring that the government can respond swiftly and decisively when incidents occur.


7. Improving Investigative and Remediation Capabilities: The order underscores the need for the development and implementation of a comprehensive federal government-wide Endpoint Detection and Response (EDR) initiative, and improved remediation capabilities.


The executive order also calls on government agencies to foster collaborations with the private sector. It encourages these partnerships to protect critical infrastructure, develop a more secure cyber environment, and cultivate a robust cyber workforce.


The landscape of software and services is in a constant state of evolution. This continuous progression encompasses an increasingly intricate supply chain, comprising diverse components, partners, and dependencies. As our applications grow more dependent on elements like open-source software, software development kits, and various third-party entities, we inadvertently widen our vulnerability to potential threats. This evolving situation is similar to an ever-expanding city with increasingly complex infrastructure and correspondingly more points of failure.


Point number 3 from EO 14028 notably highlights and calls for solutions to the grave and imminent danger of weak, insecure software used by millions of developers worldwide. The sheer complexity and interdependency of the modern software ecosystem have led to an increase in consulting firms offering Software Bill of Materials (SBOM) services. These firms often position themselves as the ultimate solution to the pressing crisis plaguing the Internet software ecosystem.


The Executive Order defines SBOM as a “formal record containing the details and supply chain relationships of various components used in building software” similar to food ingredient labels on packaging. SBOMs hold the potential to provide increased transparency, provenance, and speed at which vulnerabilities can be identified and remediated by federal departments and agencies. SBOMs can also be indicative of a developer or suppliers’ application of secure software development practices across the SDLC.”


Now that we have defined an SBOM, the real question is what to do about it. More succinctly, what do you do about the SBOM in existing in-production critical software?


However, the situation is far from simple. Consider the typical software purchasing process. Whether it's an iPhone app, enterprise-level software, or anything in between, the product is unlikely to be a stand-alone entity. Instead, it's often a complex amalgamation of proprietary code and countless other software components assembled into a unified product.


This intricate blend is comparable to a jigsaw puzzle, where each piece contributes to the overall picture, and a problem with any piece could potentially affect the entire assembly.

In the world of software development, each of these assembled components is likely a derivative of other pre-existing software.


This interdependency creates a software dependency tree, a network of connections among some of the most popular open-source software used by developers worldwide. The complexity of this network is akin to a vast ecosystem, with numerous species (software components) depending on each other for survival.


The influx of cybersecurity consultants offering SBOM solutions is, in itself, a reason for concern. While these solutions often aim to improve the software development process and ensure developers exercise due diligence in verifying the security of the software libraries they use, they often fall short of solving the underlying problems. Just because you can define an SBOM for your current software project, it does not mean you know all the SBOMs for all your existing production software. Further, companies and developers do not even have the tools to go back and inspect and verify the integrity of all the software they are running. If someone comes and says they can scan and verify all your software for SBOM integrity and security... think hard.


A significant challenge lies in tracing and verifying the origin of each software component or library. If we were to ask experienced developers about the specifics of the software libraries they've used, we'd likely find that even the most detail-oriented professionals don't have complete visibility into every component of their software.


Consider the illustration below which is the top 100 pieces of open-source software used. These represent millions if not hundreds of millions lines of code with dependencies built up on a series of cascading dependencies.





It may come as a shock, but even the most pioneering and innovative software behemoths are not immune to security challenges. Take, for instance, the intriguing case of Microsoft's notorious 'Patch Tuesday.' This monthly event, where Microsoft releases its latest security updates, illustrates the persistent security risks and vulnerabilities even for the largest technology companies. These regular updates aren't simply a matter of routine maintenance or feature enhancements; rather, they're necessitated by ongoing threats, vulnerabilities, and exploits that demand urgent attention.


We can delve deeper into this concern by examining log4j, a Java-based logging utility developed under the Apache Logging Services Project by the Apache Software Foundation. Since its inception in 2001, log4j has been a favored tool among Java developers, thanks to its versatile configuration options and its capability to deliver output to a multitude of targets.


Logging utilities like log4j are ubiquitous across the software development industry, being particularly prevalent in enterprise environments. These libraries function to generate log files, an essential tool for developers and system administrators to troubleshoot software issues and comprehend the behavior of their applications.


Given its extensive adoption, vulnerabilities in log4j, or indeed, in any similar logging utility, could have a significant and far-reaching impact on a multitude of applications and services. This can manifest in various ways. One such potential risk associated with a compromised logging utility is unauthorized access to sensitive information, as logs can occasionally contain critical data. In addition, a vulnerability might also provide an attacker with the capability to manipulate the logs, obscuring their activities and thereby complicating the process of incident response and forensic investigation.


The stakes rise even higher if a vulnerability permits remote code execution. The consequences of this are considerably more severe, as it might provide an attacker with control over the system or the ability to inject malicious code.


To illustrate this, let's take a look at some specific instances of attacks or vulnerabilities associated with the log4j library:


• CVE-2021-44228: This vulnerability gave attackers the ability to execute arbitrary code on vulnerable systems by transmitting specially constructed messages to the log4j logging utility. This issue was resolved in log4j version 2.15.0.

• CVE-2021-45046: This vulnerability gave attackers a workaround to bypass the mitigation measures for CVE-2021-44228 by sending specially crafted messages to the log4j logging utility. This issue was rectified in log4j version 2.15.1.

• CVE-2021-45105: This vulnerability allowed attackers to execute arbitrary code on vulnerable systems by dispatching specially constructed messages to the log4j logging utility. This issue was remedied in log4j version 2.16.0.


Bear in mind that these instances are merely a selection of the numerous vulnerabilities that have been identified in log4j.


Despite their renowned security measures, tech giants like Google aren't exempt from these issues. A striking example occurred when a flaw in a third-party JavaScript engine allowed hackers to penetrate their Chrome browser. Adobe's Acrobat Reader has also fallen victim to such threats when a vulnerability in a third-party font parsing library led to system compromise. These incidents underscore the inherent risks involved when relying on third-party software libraries and components.


Start-ups and smaller businesses are also prone to these threats, as exemplified by Contoso Ltd., a fictional company used by Microsoft as an example company and domain that, despite its robust security practices, suffered from an attack exploiting a vulnerability in a logging library used by their main application. This highlights that irrespective of the size of an organization, the threat landscape is universal; all are potential targets for cybercriminals. It's crucial to remember that in this interconnected digital world, an issue affecting one can quickly ripple out to affect many.


If you have concerns about your enterprise software, mobile application, and even IoT devices, beware. You are not only worried about rogue hackers but adversarial nation-states that have legions of security researchers looking for the next Log4j.


And there are many.


Trust but verify.


If you have concerns about the SBOM of your enterprise be it your ERP, HR, desktop, cloud, on-premise, or mobile phone apps. DM me for a discussion. We may have a solution.


In the next article, I will tackle the world of IoT and SBOM.
















0 comments

Comments


bottom of page