Taking Log4j as an example, how to assess and classify security risks

Author | Owen Garrett

Translated by | Knowing the mountain

Planning | Ding Xiaoyun

Open source software underpins the vast majority of Internet-facing applications. The availability, accessibility and quality of such projects enhance the ability of companies to innovate and help them succeed. They are good public goods and should be praised and protected.

The ubiquity of open source means that any vulnerability that has already been discovered has far-reaching implications. Attackers see a huge opportunity for a large number of businesses and users to respond quickly to identify vulnerable instances of software in the applications they develop and the third-party applications and components they use.

In fact, software vulnerabilities are common. So how do security professionals assess the risks that vulnerabilities can pose and focus their organization's efforts on fixing the most important vulnerabilities?

1

Establish full visibility – you can't protect what you can't see

The security team is responsible for the integrity of the entire application, including all open source components and third-party dependencies that are not developed by enterprise developers. A lot has been done to improve the security of the software development process and track dependencies through "shift left" programs and SBOMs (Software Bill of Materials) to make code deployed into production highly secure. But whenever a new vulnerability is released, how can you quickly identify where code that has already been deployed to production will have those vulnerabilities? The first step in a security program is typically to gain full visibility into application code security across the entire CI/CD pipeline, from the build phase to the deployment phase, and across all applications and infrastructure, including running containers, Kubernetes, cloud vendors, virtual machines, and/or bare metal. Eliminate your blind spots so that early detection and reducing the destructiveness of attacks.

2

Focus on what matters most: availability and vulnerability

After gaining full visibility, organizations often see tens of thousands of vulnerabilities in large infrastructures. However, the theoretical list of vulnerabilities has little practical use. Of all the vulnerabilities that an enterprise can spend time fixing, the most important thing is to find out which ones have the greatest impact on the security of your application, so you must fix them first.

In order to identify these vulnerabilities, it is crucial to understand the difference between vulnerability (vulnerability, a weakness in deployed software that can be exploited by an attacker to produce a specific result) and exploitability (an attack path that can be used by an attacker to gain an advantage).

Vulnerabilities that require high-level and local access are generally less concerned because it is difficult for remote attackers to obtain an attack path (unless the attacker has been given advanced access to the local host, they have a chance to gain further control). Of concern are vulnerabilities that can be triggered by factors such as remote network traffic that is not filtered by firewall devices, and hosts that receive traffic directly from untrusted network sources.

3

Evaluate and segment potential exploits

When prioritizing remediation based on exploitability of a vulnerability, you need to consider some or all of the following criteria:

Severity of vulnerabilities: CVSS (Common Vulnerability Scoring System) Scores provide a baseline for the severity of vulnerabilities that can be used to compare vulnerabilities. However, CVSS scores do not take into account the context of the actual application and infrastructure, so there is a gap between accurate information and obtaining it.

Attack Vector – Network and Local System Access: A network access vulnerability is often the first step in an attack, and a local system access vulnerability does not function until an attacker enters the application. This means that you need to immediately block any cyber attack path that could cause the service to be attacked, while locating potential attacks on the service nodes and taking corrective action.

Proximity to the attack surface: Is there an attack path through which an attacker can reach and exploit the vulnerability? When considering the attack path, consider that an attacker might bypass firewalls, load balancers, proxies, and other jump points, and address any of these attack points while allowing developers to update, test, and redeploy vulnerable applications.

Presence of network connections: While all vulnerabilities that can be reached from the outside are worthy of attention, those of applications with universal network connections are the most noteworthy. Attackers often use reconnaissance (Recon) techniques to discover these vulnerabilities.

The key here is to add runtime context to the vulnerability data so that the vulnerabilities that are most exploitable can be identified and which vulnerabilities to patch first, as they pose the greatest risk to the security of the application.

Consider using tools like the open source ThreatMapper to help you identify the vulnerabilities that are most likely to be exploited. As conditions change, you need to run such tools continuously to keep safety work where it is most needed.

4

Restrict reconnaissance activities

Attackers often carry out attacks based on a prepared script, using tactics and techniques documented in MITRE ATT&CK. These tactics follow models such as the network kill chain, starting with reconnaissance activities before the initial attack. Initial attacks are usually aimed at gaining limited local control, and then attackers have plenty of options to explore, upgrade privileges, install persistent control systems, and scout neighboring systems in order to spread horizontally and find larger loot.

To limit the effectiveness of reconnaissance activities, first determine the attack path that an attacker might take. To achieve double insurance, ensure that each attack path is protected by filtration technology:

Capture and drop known reconnaissance traffic through the WAF;

Use protocol- and source-based filtering techniques to restrict clients who can access these paths;

Use additional application-level filtering:

Ensure that transactions are authenticated;

For API traffic, ensure that the transaction is coming from a trusted client.

ThreatMapper visualizes the attack paths of the most exploitable vulnerabilities so you can determine how to close them.

5

Collect "Attack Metrics" and "Damage Metrics"

While every effort has been made to protect the attack surface and limit visibility, attacks can still occur for a variety of reasons—zero-day attacks, deliberate disruption of supply chains, lack of visibility into shadow IT and other unmanaged assets, and so on. The CVEs released through NVD are about 50 per day, so the likelihood of new vulnerabilities in the product is very high.

Therefore, another critical line of defense is to monitor attack metrics (IoA) and damage metrics (IoC) for internal networks, hosts, and workloads.

IoA can include probes from unusual sources, reconnaissance traffic, or network traffic that may indicate the presence of c2C (container-to-container) networks, remote telemetry, or leak attempts. The IoC indicates that there is a problem with the host and that the attacker has entered, including unusual process behavior, file system access, or file system modification.

It is recommended to build a "red team" feature that periodically scans the application for attack signals and their impact on the organization. Look for tools that can help you automate and manage a large number of IoA and IoC events, including minimizing false positives, storing events for subsequent analysis, and most importantly correlating events to understand the characteristics of attacks and how they penetrate your application. With this knowledge, you can deploy targeted countermeasures that block reconnaissance or attack traffic from inside or outside, and isolate compromised workloads.

6

conclusion

Log4j tells us that vulnerabilities are inevitable, but that shouldn't be an obstacle to organizations using open source code as an obstacle to innovation and other valuable goals. As guiding organizations in their security efforts, security leaders gain full visibility into application traffic across all infrastructures, combined with strategies for exploitability assessment and prioritization, to remain vigilant as they look for traces of attacks and reduce the risks associated with Log4j and the next major breach.

About the Author

Owen Garrett is Deepfence's Head of Product and Community, developing an open source strategy for Deepfence's security technology. Building on his 20 years of software engineering and product leadership experience at Companies such as Riverbed, NGINX, and F5, he directed the company's roadmap to creating an open-source "secure and observable" platform for cloud-native applications at Deepfence. Prior to joining Deepfence, Owen led the product development of NGINX, which has grown NGINX to become one of the most widely deployed open source projects, protecting more than 500 million websites and becoming the heart of countless ecosystem projects. Owen holds several patents in networking technology, is a frequent speaker at technology conferences, and is a thought leader in industry events.

https://www.infoq.com/articles/assessing-security-risks/?