You are currently viewing Cybersecurity and the Pareto Principle

Cybersecurity and the Pareto Principle

Jeremy Colvin* looks at the future of zero-day preparedness

It’s 40 years sequel to the reunion of the film “War Games”.

The scene begins as everyone prepares for the Christmas holidays and a community of mischievous Minecraft gamers make an incredible discovery: a systemic software exploit in the open-source Java logging library embedded as a core component of the most Internet workloads.

The vulnerability is easy to exploit and allows remote code execution, leaving IT and security teams around the world scrambling.

Instead of science fiction, it was reality as thousands of security teams around the world worked over the holidays to determine the extent of their reliance on Log4j and quickly patched patches for initial disclosure and permutations thereafter.

Log4Shell taught us the company’s security priorities and what “preparedness” in the security industry will mean in the future.

Log4Shell provides a lesson in the optimal tools for security teams to focus on as teams struggle in the key fundamental areas of security readiness and software asset management.

As attack surfaces continue to grow, organizations need to better prioritize tools for their ability to explore the entire asset fleet.

The priority of security teams should not be to detect zero-days.

Instead, a security team’s priority should be to put in place the necessary tools and governance to quickly understand its exposure to a new threat and organize a response.

The Pareto principle in cybersecurity

The Pareto principle states that approximately 80% of the consequences come from 20% of the causes (which is particularly different from the Pareto efficiency detailing the efficient allocation of preferences and resources).

This applies to enterprise cybersecurity: the unsung 20% ​​of our tools that deliver over 80% of the value.

This is of course software asset management.

Log4Shell has been a pervasive problem for years in one of the most widely used open source libraries, and it has still gone unnoticed by millions of hours spent poring over code checks and application security testing. traditional.

It’s a safe bet that there are other equally widespread vulnerabilities.

The priority for your team and resources should be to be best prepared to configure and react to these yet unknown threats.

Software asset management gives teams the strongest foundation on which to assess past, present, and future internal security risks.

The right software asset management tools give your team deep visibility into your IT ecosystem, allowing organizations to gain unique process insights and quickly assess the applicability of new risks as they emerge.

Finding zero days tends to be omitted from the security administrator job description, and for good reason.

The focus should be on preparing for new critical vulnerabilities – and yes, that means detection but, more importantly, remediation.

When assessing your team’s resources and expertise, you want to maximize speed and readiness to deal with these emerging CVEs.

Using Log4Shell as a case study, let’s further explore the gaps in security mindset and re-emphasize the core competency of a security team in an enterprise organization.

The Future of Readiness: Software Asset Management

Log4Shell was a wake-up call.

The vulnerability has gone unnoticed in a hugely popular open-source tool over the past decade.

For most teams, this was another lesson learned that the future of enterprise security should be about maximizing speed and visibility within your own fleet.

With a large-scale software asset management solution, an organization can move from the background to the forefront of emerging threats such as Log4Shell.

It’s a classic phrase: you can’t protect what you don’t know.

In the case of Log4Shell, the first few weeks revealed deep issues around simply navigating its own computing ecosystem.

The right tool gives your team the extent of the impact in minutes or hours rather than the days or weeks it took teams to inventory instances of Log4j in Java applications.

Sounds simple enough – getting a list of all instances of Log4j or Java processes running on your laptops, servers and containers – but we all know colleagues and organizations who have had trouble (and maybe still struggling) with this simple act of inventory.

Log4Shell exposed these flaws in the current approach to enterprise security and encouraged us to get back to basics.

A good organization recognizes its strengths and even better its limitations.

As organizations grow and expand their assets, the best way to keep your environment permanently secure after initial deployment is the speed at which you can implement released patches and upgrades.

This is the primary benefit of software asset management at scale, and why that 20% of our tools provide so many benefits to teams.

It removes the barrier to action and the barrier to understanding.

Map the castle park

There’s a good reason software asset inventory and management is the second most important security control, according to Critical Security Controls from the Centers for Internet Security (CIS).

It’s “essential cyber hygiene” to know what software is running and to be able to instantly access that up-to-date information.

It’s as if you were a new master-at-arms for a local baron in the Middle Ages.

Your first duty would be to map out the grounds of the castle you are tasked with protecting.

Simply put, don’t expect your organization to build unique, custom solutions to emerging security threats.

You are not expected to find zero days or spend your internal budget researching bugs for your licensed vendors.

Instead, good enterprise security readiness is tried, tested, and transparent (one of the key benefits of open source solutions), enabling security teams to act quickly in risk assessment and the implementation of fixes.

Software asset management becomes the first step, and if ignored, becomes the first obstacle to creating an agile and prepared security-focused organization.

In the first minutes and hours after the Log4Shell disclosure, think about how long it took you to fully map the extent of the impact on your infrastructure.

Going further, are you sure that no use cases were missed and that you really had a clear picture of your processes? Have you had trouble finding uber .jar files or shady .jar files?

The economics of good security

As we put Log4Shell behind us, let’s incorporate these lessons learned for a more prepared future.

Resource allocation by enterprise security teams needs to be more targeted as attackers become increasingly sophisticated and continue to have what appears to be unlimited resources.

The value added by clear visibility and real-time information on your entire ecosystem becomes all the more important.

Remember that the primary goal of the security team is to create a secure computing ecosystem, mitigate the exploitation of known vulnerabilities, and monitor suspicious activity.

With expanded software asset management, practitioners are amplified in their ability to monitor, remediate, and harden assets.

This extended visibility becomes the foundation upon which teams build comprehensive security solutions.

The application security market is expected to reach $12.9 billion by 2025, according to Forrester.

This is great overall for the security industry as we continue to dedicate resources to finding vulnerabilities and mitigating them before they are exploited.

However, from the perspective of an individual organization, it makes more sense to focus resources on the tools that will move the needle within their organization.

Think about the backlog of fixes that are still waiting to be implemented in production, or consider the potential for missed outside cases when mapping Log4j.

As attacks and attack surfaces continue to grow, organizations need to better prioritize their security tools to create measurable results.

It’s not the most illustrious topic, but the incredibly high value of software asset management strengthens security teams across all functions, especially as we look to future emerging threats.

* Jeremy Colvin is a Technical Product Marketer at Uptycs and enjoys learning the bits and bytes of what makes good security.

This article first appeared on

Leave a Reply