Challenge

According to a study done by IBM, the cost of a data breach continues to climb in the U.S., and these breaches are predicted to worsen and become more frequent over the next decade.

Lack of timely response to the Log4j vulnerability and others makes companies more susceptible to breach. That lag time can also result in increased scope and impact of the breach to a company. According to IBM’s Data Breach Report, 2021 had the highest average total cost of data breaches in the 17-year history of the publication of the report.

One such data breach resulted from a coding script known as Log4j; a specific line in JavaScript applications that acts as a logging library. This specific line of code is used by the majority of JavaScript users, which is by far the most popular coding language, showing the widespread extent of the vulnerability. But that wasn’t the only reason for its threat.

The Log4j cybersecurity risk was a day-zero vulnerability, meaning that any provider using JavaScript with that line of code was immediately subject to the breach. If a company was attacked, the hacker took remote access of the targeted computer or application and controlled it from the attacker’s own device.

Many organizations weren’t prepared and experienced looming threats of data breaches, loss of personal information, and financial loss.

Not wanting to be the next name in the news regarding a poor response to the Log4j vulnerability, the leading logistics, tracking, and shipping company went to work to understand its risk impacts and what it could do to prevent Log4j from harming its business.

The only way to stop the breach was by patching internal and vendor environments to keep data loss from spreading across the company as well as externally. However, the company didn’t have a clear picture of how susceptible it was to the risk, particularly from its vendors, and needed to expedite a sound mitigation plan.

Solution

On a tight timeline to find a way forward, the VRM team made a quick decision to build a survey to assess its immediate risk threshold and looked to internal systems to solve the problem.

Excel wasn’t going to deliver the efficiency they needed, and there wasn’t time to hire a consultant. Instead, the team chose to use existing data in Onspring, the system of record for their current VRM and Information Security programs. They were already using Onspring to perform annual risk assessments on vendors, so they could use existing contact data for business owners and vendors housed in the platform to survey the current Log4j vulnerability situation, keeping all information in one solution.

The team took the following actions in their response to the Log4j vulnerability:

1 – Determine the vendor population

Within this first step, the team had to first establish the selection criteria by determining the risk parameters used to select vendors for the survey, by asking the following questions:

• Does the vendor run a SaaS environment or internet-facing website, making them more susceptible to the Log4j risk?
• How much risk does the vendor pose to the larger company? (This was measured on a 3-point scale of low to high risk.)

The second element was determining the information source, which meant that their single source of truth would be from the InfoSec and VRM assessment population within Onspring.

The population was determined by running a report in Onspring using existing risk data in its Third-party / Vendor Risk Management solution against these criteria and using a report filter that siphoned those SaaS/internet-facing website providers with a medium-high or high risk rating OR those vendors who had previously scored poorly on prior InfoSec surveys, which could indicate weak patching controls.

This filtering yielded the 82 highest-risk vendors.

2 – Draft Log4j vulnerability assessment questions

The goal was to configure the right questions without burdening the vendors with a long survey. The VRM team worked with the IT team to determine what information was most important to them, such as understanding how many vendors used JavaScript and if they used the Log4j script, and how long it would take each to mitigate the risk.

3 – Configure and launch survey

Leaning into their pre-existing vendor data already built, the VRM team configured their Log4j vulnerability survey—a repeatable flag vulnerability survey—as well as a vulnerability management application in Onspring within a week, before deploying it to vendors with business owners notified.

4 – Analyze responses to Log4j vulnerabilities

The company needed to decide how to display and report the findings to the company’s executive management team and other stakeholders. It was important for the company to show its current risk environment based on vendor responses and status, such as:

• Was the vendor impacted?
• What is the current remediation status?
• Is remediation complete? For how many impacted vendors?
• Have reports been sent to InfoSec? Legal?

In addition to a straightforward, easy-to-consume dashboard, Onspring’s reporting capabilities enabled the VRM team to filter and customize data to create reports for different stakeholders to view real-time visibility into the company’s response to the Log4j vulnerability.