The Takeaway

The Log4j vulnerability is only the most recent example of a security incident that reminds every organization of the importance of basic cyber hygiene. To be ready for the next zero day, every organization should have three main programs in place: a detailed inventory of assets, tooling to scan all hardware and software assets, and a solid incident response (IR) plan. This report explains why Log4j is difficult to address and how those three initiatives can help organizations be better prepared for similar future events.

The Challenge

In the wake of Log4j, the small security team for a state government is asking how to be proactive and defend against similar internet-wide zero-day vulnerabilities. The team wants to prepare for the inevitable questions from the organization, as well as continue to stay on the forefront of security. Specifically, the team asks:

• Is the best that can be done simply good asset inventory, vulnerability scanning and patch programs? Is there anything new to help with these old security programs?
• What did the organizations that handled Log4j best have in place that allowed them to do so?
• How can we learn from Log4j to become more proactive in our future defense?

Step 1: Know Your Assets

While a low percentage of vulnerabilities are actually exploited in the wild, unpatched vulnerabilities are still the source of a significant number of cyber incidents and breaches. Some companies report that one in three breaches start with an unpatched vulnerability, while others believe the number is closer to two in three. Palo Alto reported that 80% of exploits are published faster than the Common Vulnerabilities and Exposures (CVEs), which means the adversary has information on how to perform an attack before an organization is even aware it is vulnerable. Without a solid asset inventory, organizations are further disadvantaged by the need to hunt for hardware and software that may contain a vulnerability.

The need for a comprehensive asset inventory is not limited to a particular sector or size of company. Doing even a basic Google search on “cyber hygiene” shows an asset inventory is the first step in building and running a solid cybersecurity program; yet, many companies still struggle with creating and maintaining one. The key to handling both focused and widespread vulnerabilities, such as Log4j, is to be able to quickly identify where the vulnerabilities exist in your environment and having detailed incident response procedures to address them.

Tips for Overcoming Asset Inventory Hurdles

The best asset inventories include all of an organization’s hardware, software, web apps, APIs, and open source code and tooling, as well as the interconnections between assets. Ideally, a software bill of material is part of the inventory, but even a simple list of applications and where they are stored is a great start.

However, building such a detailed inventory and then maintaining it is not an easy task and, depending on the size of the organization, it can take months or even years. It also requires a level of automation (for asset discovery and validation) to have confidence the inventory is accurate and up to date. This can be a daunting task, and it is easy for an organization to get overwhelmed quickly with the sheer amount of data that needs to be captured for each asset. As the Desmond Tutu adage goes, you eat an elephant one bite at a time.

The good news is that even though asset inventory and management are not easy, there is a lot of material already available to assist organizations in doing this work. ISO 55000 provides guidance on building an asset management capability, and the Center for Internet Security provides implementation guidance on asset inventories in its Top 18 controls.

Technical strategies are only one factor, however. True success requires leadership commitment stressing three main points:

• Communication of the need for asset management so the entire organization knows the importance of the effort and prioritizes accordingly. An asset inventory program is going to touch nearly every single person in the organization, and hearing this is a priority from leadership will increase success of the program.
• Assignment of asset ownership is a critical aspect of an asset inventory. Every single asset will have a program owner and, perhaps, a technical custodian who is responsible for the upkeep. An asset that does not have an owner is considered an “orphaned asset” and runs the risk of not being managed. Orphaned assets, such as unmanaged servers or accounts, have led to several major data breaches.
• The need for ongoing asset inventory. Leaders must understand and communicate that asset management is a program and not a one-time activity. Assets will change daily, or even hourly, depending on your organization’s operations, infrastructure and workforce. While automation can assist in removing manual steps, asset management requires a named program lead and the understanding the program will last as long as the organization exists.

  All are required to have a current, comprehensive understanding of the organization’s assets and their interconnections.

Step 2: Tool Up for Scanning

In addition to an inventory, organizations must have tools in place that can scan the assets to identify vulnerabilities. It can be eye-opening to look at the list of assets and then realize a majority of them are not covered by any sort of vulnerability scanning. Many companies confronted this when they needed to search for the impact of the Log4j CVE across a variety of assets, including servers, applications, cloud resources, code repositories, IT tools and much more.

A comprehensive asset inventory can be used to track what currently is and is not scanned so the team can work with business unit leads to identify immediate ways to look for a specific vulnerability and determine a long-term plan for more automated vulnerability scanning.

Step 3: Document and Practice Your IR Plan

Finally, every organization must document and practice (via tabletop exercises, ideally) its IR plan. The best IR plans include all types of incidents, but a systemic vulnerability like Log4j really amplifies the need for vulnerability IR, which requires (at a minimum):

• Identifying an incident leader: This should be someone who can work with both the business leaders and the technical teams to address the situation. This person will need to be relieved of other work to do this role effectively.
• Establishing the incident team: This team will be very cross-functional and, in cases like Log4j, will include technical teams, procurement, legal, supply chain and management.
• Prioritizing the work at hand: The IR team should focus on the areas of highest risk first. In the case of Log4j, this would be externally facing assets that can be exploited by adversaries outside the company.
• Communicating both internally and externally: The incident leader and/or the assigned communications lead on the incident team will need to communicate status and priorities across the organization. There are also communications that may need to go out to vendors, partners and customers. It is important the communication of the incident and the organization’s response is coordinated with the appropriate internal resources before being released.
• Dispositioning or remediating and validating the solutions: Incidents are not over when the patch is applied. There is a lot of work to do in validating the patch works and in setting up monitoring to ensure no other anomalous activity is occurring. In the case of Log4j, we’ve seen multiple patches released to address new issues. The incident team must remain in place until:
  
  • Everything is verified as being fixed or remediated within the organization’s risk appetite.
  • The root cause analysis and lessons learned are documented.
  • Other criteria for incident closure are met.

Why Log4j (And Others Like It) Are So Difficult

The entire cyber world has been abuzz with the Log4j remediation, and we have seen multiple patches released to address the problem. Unfortunately, many organizations are in a position of waiting for third-party vendors and partners to identify and address their system/service vulnerability to Log4j.

This event highlights the importance of ensuring your asset inventory includes third-party assets and dependencies. In many cases, the team will need to address a compensating control as part of the incident response plan if a third-party vendor is unable to identify or address a vulnerability right away.

Back to Basics Is Our Best Approach

There is no magic behind the best approach to handling vulnerabilities like Log4j. Forward-thinking organizations must focus on:

• Creating and maintaining an asset inventory. Be sure to include third-party vendors, tools and services as well.
• Deploying tooling to scan all assets for comprehensive visibility and quick vulnerability identification. These tools should include regular vulnerability scanners like Tenable Nessus and Rapid7 Nexpose, as well software composition analysis tools like WhiteSource and Snyk.
• Documenting and practicing incident response plans. Hold regular tabletop exercises (including with executive management) and be sure to include injects that cover issues with third-party dependencies.

Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.