Information security space observers may have encountered a phrase born out of both frustration and levity in 2023: “Hot Zero Day Summer.” While nearly two months remain as of this writing for Summer 2023, anecdotal evidence suggests that adversaries increasingly leverage vulnerabilities in external-facing applications and appliances to drive intrusions. Certainly, other intrusion vectors remain relevant and popular, such as phishing and related activities. But the list of vulnerable applications and services leading to widespread breaches, whether related to criminal activity such as in MOVEit exploitation or state-sponsored operations as observed with Citrix appliances, appears to be large and increasing.
Yet in looking at the landscape, network owners and operators must be cautious to avoid overreacting to the latest vulnerability news and bulletins. In an industry already facing burnout and resource shortages, spinning up emergency response and patching operations with each new disclosure will be a recipe for disaster. Instead of treating all disclosed items as emergencies, decision makers and defenders must adopt a consistent, impact-focused approach to evaluating the severity of disclosed flaws to direct efforts and justify responses. By coming up with such workflows in advance and socializing these items with leadership, organizations can place themselves on much firmer, predictable footing when the next bug with a silly name or logo gets disclosed by offensive security researchers, or responders identify a threat actor leveraging a previously unknown flaw in intrusions.
First and foremost, determining the relevance and applicability of new vulnerabilities is critical, but often left to ad hoc processes and rushed research. Quite simply determining “do we even run X?” is a critical question that often is not answered until circumstances demand it, applying to entities ranging from relatively small business networks to major enterprises. Developing and maintaining an accurate asset and software inventory can avoid significant pain (and unpleasant surprises) when determining the relevance of the latest nasty bug to hit the internet. While seemingly simple and obvious advice, the number of organizations failing to meet this minimal standard is worryingly large, resulting in significant cycles determining if certain products or software are deployed within the network. Getting ahead of this issue not only saves significant time, but can allow for measured, controlled responses to the latest security news, even if such responses to leadership are simply, “We do not run any instances of this product within our environment.”
After satisfying the question of applicability, network owners must address the question of exposure. Some vulnerabilities can be quite nasty or easily exploited, but if the relevant product or service sits multiple layers deep within the network, its relevance is significantly circumscribed. Meanwhile, a vulnerability in an externally-facing system or service will likely be very significant – and require quick action – as it can serve as an initial access vector for threat actors. In looking at “Hot Zero Day Summer,” we see a commonality in that identified, critical items align with services or appliances that are, by nature, externally accessible to some degree. Understanding how easily an adversary can orient themselves to take advantage of a vulnerability can thus inform subsequent patching decisions – whether something can be addressed through compensating controls, or if emergency patching procedures are necessary.
Finally, applicability and exposure lead to an assessment of severity. In this case, accurate understanding of a given vulnerability, how it is targeted and how it is successfully exploited, become critical pieces of information to determine response. Situations involving complex memory corruption or taking advantage of race conditions may require significant research and development to deploy a reliable exploit, while other items may be relatively trivial to trigger. In the latter case, proof of concept (POC) development and successful exploitation can be expected in short order, necessitating quicker action in terms of patching or compensating controls to minimize potential impact.
Overall, network owners and defenders must look beyond the headlines and even criteria such as common vulnerability scoring system (CVSS) numbers to understand just what a given software or application bug entails. Applying a nuanced understanding of just what a flaw allows an attacker to do, and how easily this situation can be attained will enable sound, risk-based decision making with respect to IT operations and patching. While each organization will have its own specific risk criteria and tolerances, developing a decision framework for evaluating software flaws as they are disclosed can ensure consistent, repeatable responses instead of constant movement into emergency action.
The following flow chart represents, at an abstract level, the minimum necessary steps for organizations to consider as part of the vulnerability response process:
Through measured, consistent decision criteria, organizations can develop plans in advance for how to manage their security posture in the face of software application flaws. Such an approach enables better planning, resource allocation, and predictability in network operations, while hopefully avoiding knee-jerk reactions and personnel burn-out. Each organization may have different criteria for the above phases, and these criteria can shift depending on the criticality of the application or system involved. But failure to adopt some reasonable, consistent approach to the vulnerability issue will effectively cripple organizations beyond “Hot Zero Day Summer” as ad hoc responses inefficiently and meaninglessly burn through resources and personnel.
