Jonathan Trull
SolarWinds, Colonial Pipeline, MSFT Exchange — these names have become synonymous with infamous cybersecurity events. We keep calling every new zero-day exploit a “wake-up call,” but all we have been doing is collectively hitting the snooze button.
But the discovery of the newest widespread critical vulnerability, Log4Shell, ruined the industry’s holiday season. It’s the biggest cybersecurity threat to emerge in years, thanks to the near ubiquity of Java in web applications and the popularity of the Log4j library. Due to its unprecedented scale, compounded by the fact that it is not easy to find, getting rid of this bug from your IT environment isn’t a “one-and-done” activity.
Security teams across the globe are once again racing to remediate a software flaw, even as attackers have begun targeting the low-hanging fruit — public web servers — at a recently reported rate of 100 attempts per minute. A mere seven days after its discovery, more than 1.8 million attacks had been detected against half of all corporate networks.
Are you awake now?
I’ve participated in many urgent Log4Shell briefings with Qualys customers (who include 19,000+ enterprises worldwide, 64% of Forbes Global 100), and it’s clear that dealing with a constant barrage of zero-day vulnerabilities is one of the greatest challenges faced by today’s security teams.
It can be overwhelming to prioritize fixes and patches when responding to a zero-day exploit like Log4Shell. Here are a few steps to respond to security threats that we have learned and cataloged over the years:
Establish a standard operating procedure
Create a detailed standard operating procedure that includes step-by-step activities tailored to the vulnerability type.
For a zero-day response, the following information must be included:
- Process flow for responses. If you need help, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) has created an excellent guide.
- Categorize the vulnerability by the type, severity and required response times. There should be a specific category for critical zero-day vulnerabilities.
- Pre-determined service-level agreements for each response team.
- Procedure for declaring and communicating an incident (this could be a reference to the incident response standard operating procedure).
- Steps for tracking, reporting, and concluding the incident and returning to normal operations.
Successful organizations spend time updating and testing their standard operating procedure yearly to ensure it is accurate and contains the specific steps needed to be effective. Testing is highly recommended, and a tabletop exercise or simulation should be held every six months.
Inventory, inventory, inventory
The recent uptick in migration of assets to the cloud has given attackers the opportunity to exploit organizations at alarming rates. Attackers are taking advantage of the complexity and lack of asset visibility that this migration has introduced, with attack surface management tools discovering more cloud assets than security and IT teams even knew they had. Simply put, you cannot secure what you cannot see – risk to the organization lies in unknown assets.
The most mature organizations maintain a comprehensive and up-to-date inventory of all technologies and third-party vendor relationships, as this is often where vulnerabilities exist. Mature organizations have developed processes to automatically identify IT assets, whether they are on-prem, mobile, cloud, containerized, or in a non-traditional format such as OT or IoT.
It is imperative that the following asset information be always available and searchable by information security teams:
- Asset name and MAC address.
- Operating system with version/build/kernel details.
- Software with version/release details and lifecycle information (end of support/extended support).
- Hardware platform information for each asset.
- Business and IT owner for each asset.
- Asset tags to help the organization make risk-based decisions (internet-facing, PCI, executive-workstation, etc.).
Every new procured asset or software build must be inventoried immediately, and asset information must automatically be updated as changes to the environment occur. This ensures that the organization has the most relevant and contextualized information when a zero-day is disclosed.
Information gathering, sharing and analysis
Organizations with the swiftest and most effective response to zero-days usually have a team dedicated to gathering and analyzing threat intelligence from multiple sources. These teams typically receive intelligence from vendors, government entities, and information sharing and analysis centers. The information collected and processed should then be used to identify the existence of zero-days and kick-off the company’s overall response.
Just like inventorying, gathering and analyzing threat intelligence is crucial to provide the necessary foundation for security teams to take calculated and intentional steps.
A well-oiled machine
Sophisticated organizations will ensure that they have experienced staff and tools to determine whether the vulnerability exists within their environment. As we learned with Log4Shell, this often requires multiple detection methods to ensure a complete response.
It is not enough to simply identify that a vulnerability exists. The company’s incident response team must also assess if there are signs of exploitation for each susceptible asset. For example, attackers could have already exploited the vulnerability before it was disclosed to the security community. If this is the case, putting mitigation in place without proper investigation could lead you to missing an already entrenched attacker.
Unfortunately, there is no way to ensure that an organization can completely stop harmful attacks tied to zero-days. However, with a commitment to detailing standard operating procedures, inventorying assets, gathering threat intelligence, and building an efficient team, organizations have an extremely solid foundation for responding to threats in real time.
Comment