It’s now been more than a year since the Log4j Shell vulnerability became, at least theoretically, a wake call for organizations that are dependent on software components built by others to revisit the security of their software supply chains. However, there has been less focus on modernizing the incident response processes that organizations rely on to remediate vulnerabilities. The trouble is it’s only a matter of time before the next great zero-day vulnerability crisis unfolds.
As more research on application security is conducted the greater the likelihood vulnerabilities will be discovered. The issue that many IT teams wrestle with is it can take a long time to discover every instance of vulnerable piece of code that might have been embedded within an application. Some organizations a year later have not discovered where every instance of a widely employed Log4j tool for collecting log data from Java applications might be running.
Ideally, IT teams should be applying best DevOps practices to incident management processes that focus on symptoms that are indicative of a brewing service disruption. The overall goal is to remediate issues long before an actual problem occurs. As part of that effort, patches to application once created are automatically applied. A modern approach to incident management makes it simpler for IT teams to essentially expect the unexpected. In fact, the more organizations become accustomed to responding to a sudden incident the more routine the whole process becomes. No two IT incidents are precisely alike but it is possible to identify and automate repeatable tasks as classes of incidents become more apparent.
The memory muscle the organization develops over time also allows it to become more resilient in a way that reduces overall stress levels. That approach provides the added benefit of reducing the level of burnout that members of the IT incident management team are likely to experience which, in turn, reduces turnover rates.
Of course, no is paying more attention to vulnerability disclosures than cybercriminals. Every time a new vulnerability is disclosed it becomes a race against time as means to exploit it are created. Some contend the best approach is to automatically apply patches as they become available, but many organizations are hesitant for fear the patch will break an application so weeks, even months, can go by before a patch is applied. Even then, organizations should never assume the latest version of any package is secure so it’s critical they be scanned before being installed.
In the absence of any standard set of incident management processes it requires the heroic actions of a few to respond to any crisis. The problem is that heroes are not always available when needed. Murphy’s Law dictates they will be on vacation when the next major issue suddenly erupts. The goal instead should be to implement a set of processes that don’t require anyone to go above and beyond the call of duty to manage any incident that will inevitably arise at the most inconvenient time possible.
Hopefully as more organizations improve the security of their software supply chains there will be fewer incidents to manage in the years ahead. Unfortunately, the amount of security debt in terms of unpatched vulnerabilities that currently exists in application environments is enormous. Not all those vulnerabilities are as equally severe, but cybercriminals are adept at combining multiple vulnerabilities to create a single lethal update so determining with certainty the level of threat represented is difficult. As such, with the limits of the resources available the better part of valor is to patch as often as possible. After all, the best incident to manage is the one that never happened.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
