Systemic vulnerabilities, like Log4j, are reminders on the importance of basic cyber hygiene to every organization. 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.
In the wake of large, systemic vulnerabilities like Log4j, organizations need to be proactive and defend against similar internet-wide zero-day vulnerabilities. In addition to preparing for the inevitable
questions from the organization, security teams also should adhere to a series of key steps to address systemic vulnerabilities.
This piece explains why systemic vulnerabilities like Log4j are difficult to address and how the key three initiatives can help organizations be better prepared for similar future events.
Three Key Steps to Address Systemic Vulnerabilities
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.
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. This can be accomplished taking
projects in small bites one step 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.
READ: How to Improve Your Vulnerability Management Program
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 business leaders and 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 external-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.
Best Practices for Addressing Security Vulnerabilities
There is no magic behind the best approach to handling vulnerabilities like Log4j. Forward-thinking organizations should 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, as well software composition analysis tools.
- 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.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.