Yet another zero-day vulnerability has been disclosed that required many cybersecurity teams to once again scramble to patch software before cybercriminals exploit a new known weakness.
A remote code execution (RCE) exploit found in log4j (CVE-2021-44228) affects the most widely employed logging framework used to manage Java applications. Used by almost every Java application, the effort required to immediately patch log4j has been significant.
The trouble is the number of zero-day vulnerabilities being disclosed continues to steadily increase. Unfortunately, cybercriminals are paying a lot more attention to these disclosures than many of the organizations affected. In many cases, no one is tracking zero-day vulnerabilities at all. After all, the percentage of their applications that have been impacted by a zero-day vulnerability may be relatively small.
However, it’s also clear that the rate at which zero-day vulnerabilities are being disclosed will increase as more cybersecurity research is conducted. The issue cybersecurity teams now need to come to terms with is setting up a process that enables them to consistently remediate zero-day vulnerabilities without a lot of drama that ultimately only serves to increase the already high level of stress most IT teams operate under.
Cybersecurity teams would be well-advised to crib some of the best practices that have been defined for modern IT incident management platforms to minimize the level of disruption that the need to suddenly apply a patch can create. Based on processes that are rooted in the workflows that DevOps teams have created to automate the deployment of applications, a modern incident management platform enables IT teams to essentially expect the unexpected. The more organizations become accustomed to responding to a sudden event the more routine it becomes. The more memory muscle the organization has the more resilient it becomes. That resilience not only reduces the overall stress level of the team it also substantially reduces the level of burnout that members of the IT team experience. Just as importantly, the less stress there is the less likely it becomes there will be high levels of turnover.
Of course, no two IT incidents are precisely the same. However, the more an organization practices the more apparent it becomes how similar the response to certain classes of events becomes.
Security incident management is essentially a subset of IT incident management. Organizations that invest in it are going to see benefits that go well beyond simply applying a patch. Disaster recovery, for example, is a lot easier when everyone involved knows exactly what they are supposed to do when. These days, however, it’s more likely to be a security issue that makes everyone in the organization more aware of the need for a platform that makes it simpler to implement a set of best practices for responding to any unexpected event.
Today, unfortunately, too many organizations rely on the heroic actions of a few to respond to any crisis. The issue 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 institute a set of processes that don’t require anyone to go above and beyond the call of duty to deal with any issue larger or small that will almost inevitably arise at the most inconvenient time possible.
Mike Vizard berichtet seit mehr als 25 Jahren über Themen aus dem IT-Bereich und hat eine Reihe von Publikationen im Bereich Technologie herausgegeben oder zu diesen beigetragen – darunter InfoWorld, eWeek, CRN, Baseline, ComputerWorld, TMCNet und Digital Review. Derzeit bloggt er für IT Business Edge und wirkt bei CIOinsight, The Channel Insider, Programmableweb und Slashdot mit. Mike bloggt außerdem über aufkommende Cloud-Technologie für SmarterMSP.