Abstract
With the rise of cybersecurity incidents, proactive processes in addressing cybersecurity are needed now more than ever. While it is not always possible to stop vulnerabilities from making their way into your production systems, following the practices outlined in a secure software development life cycle and supply chain is an extremely effective way to ease response and remediation. Through the automation of basic requirements for most regulatory standards, eruditeMETA can make this a reality. This can be demonstrated using the recent Log4j vulnerability as an example.
Introduction
eruditeMETA is a platform aimed at providing complete visibility into an organization's secure software supply chain. While it accomplishes this goal through a combination of features and integrations, arguably the most important features are the ones which can assist in responding to an incident once a vulnerability has been identified.
Background
While the full feature list is increasing, eruditeMETA offers two (2) particular features that greatly impact the effort in responding to cybersecurity incidents:
Software Composition Analysis (SCA), and
CVE Vulnerability Analysis.
In the case of the massive vulnerability associated with Log4j in late 2021, remediation could be reduced to a fraction of the time —and eruditeMETA's platform can pay for itself with less than a single instance.
What are these features?
Software Composition Analysis (SCA) is not a new concept, and many products exist in the marketplace focusing solely on this segment of application security. SCA tools perform automated scans of an application's code base, including related artifacts such as containers and registries, to identify all open-source components.
Most SCA tools were a response to the revolution around the use of open-source code, components, and libraries. The premise is that software now includes software developed "in the wild" by developers who are not internal employees or consultants. Because of the lack of control and oversight in that process and the outcome being used, it is necessary to identify each component in use. That is an absolutely valid use case.
While other products focus on identifying open-source components, they fail to look as deeply at the other components in use, either internal and bespoke or commercially available. They largely neglect to consider that the commercially available packages are created by other organizations, i.e., other organizations just like themselves... potentially using open-source components as well.
What differentiates eruditeMETA's features is a matter of scope. We do not only mistrust open-source developers and providers; we do not trust anyone —including our internal employees. (We are using the word "mistrust" in a somewhat "tongue-in-cheek" way.)
We take zero trust to a whole new level. Our SCA feature not only identifies open-source components; it identifies all components. The feature continues in a recursive fashion to follow the digital thread until it reaches a point through which it can no longer be traversed. We consider anything else to be a less than comprehensive list.
CVE (Common Vulnerabilities and Exposures) Analysis picks up where our SCA feature left off. With the complete list of components, we integrate with the National Vulnerability Database (NVD) to find any vulnerability related to each component, as well as relevant version information. We use ML/AI to follow those results recursively while adding to the model's decision trees.
Use Case: Log4j
As alluded to above, on December 10, 2021, a very serious vulnerability in the Log4j software was published with the identifier CVE-2021-44228. This vulnerability allowed attackers to send malicious messages into a log server that could be used to execute commands on that server, steal data, or even take control of the server. This was the result of overly provisioned features that were enabled by default, an insecure configuration, and the implicit trust of messages on the network.
What is Log4j?
Log4j is a widely used Java software library from the Apache Foundation. Its job is to collect and record events --a totally normal, necessary, and required task in software systems. Rather than reinvent the wheel and create their own logging system, professional developers across the world chose to use and include Log4j. In fact, software companies of all sizes have been using the vulnerable version of this library since 2014. (Yes, more than 7 years.)
Scope
Through the Framework for Analysis and Coordinated Trust (FACT) platform, analysts accessed a database of approximately 45 million software packages used in the operational technology (OT) space. Ninety percent (90%) of OT vendors have at least one affected product; some have hundreds.
Exploitation
During CISA's Briefing to Critical Infrastructure Partners, Eric Goldstein said, "This vulnerability could be used for an extraordinary broad range of attacks." Indeed, lots of attacks occurred. Government agencies like CISA and private ones alike were all reporting active exploitation of the vulnerability.
(We are not including a list of private agencies as the list is too extensive and to only name a few seems prejudicial.)
Detect and Response
The first step in every playbook is to determine if any software in your system contains the vulnerability; in this case, Log4j. One such example is the Log4j Detection and Response Playbook, published by the information security consulting group, TrustedSec.
The playbook recommends the following actions be performed:
Actively scan systems or use software inventories to identify vulnerable versions of Log4j;
Update vulnerable versions of Log4j or apply mitigations; and
Search for exploitation and post-exploitation activities.
Without eruditeMETA
It continues to decompose those steps into the following tasks:
Affected versions
Affected software
Vulnerable software detection - searching for vulnerable code
Vulnerable software detection - vendor notifications
Active scanning of deployed code
Prevention and mitigation
Exploitation detection
Log analysis
Endpoint analysis
Network analysis
With eruditeMETA
Using the same breakdown of tasks above, if a company used the eruditeMETA platform, the playbook would be addressed somewhat differently:
Affected versions
Affected software
Vulnerable software detection - searching for vulnerable code
Vulnerable software detection - vendor notifications
Actively scanning of deployed code
Prevention and mitigation
Exploitation detection
Log analysis
Endpoint analysis
Network analysis
Conclusion
Steps in detecting an attack in progress are still best handled by existing systems. In a proactive effort, though, eruditeMETA can reduce the chance of vulnerabilities being delivered to production.
While eruditeMETA furthers the effort to prevent vulnerabilities from entering your system, the fact remains that there will be occasions where a vulnerability is announced later, as was the case with Log4j. In situations such as this, the cost of delay in finding and quarantining or remediating the vulnerability cannot be measured. With eruditeMETA, the effort to identify software that has been impacted would be a non-event.
Our ongoing growth and pruning of the software supply chain and components included make this lag time negligible. eruditeMETA systems stay up-to-date, continuously learning through integration and traversing of each company's software supply chain, as well as the information publicly available.
Companies can feel confident that they know where vulnerabilities lie and can take steps to prioritize remediation, accept the risk, or create contingencies, especially if the unthinkable occurs.
References
Republished with permission from eruditeMETA, ©2022. All rights reserved.
Comments