Oct 27, 2022

Battling the Next Log4j: How to Prepare Your Security Team While Avoiding Burnout

With the anniversary of Log4j looming, it is a good time to reflect on the wider significance of the vulnerability that had security teams scrambling in December 2021. What can the response to the flaw in a widely used Apache Software Foundation logging tool tell us about the state of global IT security? Most importantly, how should we respond to similar vulnerabilities that are bound to emerge in the future? The reason for the heightened concern surrounding Log4j stemmed not only from the scale of the exposure, but also the difficulty in quantifying that exposure. People knew or suspected they were using Log4j but did not necessarily know to what extent and on which devices. It’s like a fire alarm going off: You suddenly know you may have a problem, but you don’t know exactly how big a problem or where in the house it might be. Log4j also speaks to the well-documented challenge of relying on open source software. We cannot live without it, but in doing so we introduce dependency and risk in ways we had not always anticipated or prepared for. Events like Log4j won’t deter organizations from using open source software. The cost and pain of building tech stacks from scratch is simply too great for the vast majority of organizations. Much of the media coverage of Log4j highlighted the panicked response. Security teams reacted swiftly and decisively as they sought to contain the risk, with much of the work happening over the festive holiday period to the chagrin of those affected. That was the right course of action, but it is unsustainable to react in crisis mode all the time. This will burn out your hard-working security team, not least the experts on your networks and systems—key people you don’t want to lose. Vulnerabilities like Log4j are a fact of life, so a different pattern of response is needed. One that allows business operations to continue and risk to be continuously managed. That calls for first understanding the information security risks you are trying to manage. It sounds obvious, but can you articulate this for your organization? Does your leadership fully understand? Is this something you review with your board periodically? Your security response should flow from a set of priorities articulated by your experts and endorsed by your leadership, or else you are destined for infosec busywork rather than purposeful risk management. It follows closely that you also need to understand your assets. What data, information and systems do you have? How do you rely on them and what happens if they go away? With these foundations in place, you can start to build what you need to take all sorts of security challenges in stride, including the next Log4j, whatever that may be. Training is a key aspect of a measured response. Your whole organization should be trained on the basics of cybersecurity and how to improve cyber hygiene. The security, engineering and infrastructure teams need a plan of action to manage your organization’s response to a new, major vulnerability. Plan your incident response and consider simulating how you would respond as part of a table-top exercise. Revisit this plan from time to time—don’t let it gather dust in a ring-binder in an office no one goes to any more! These suggestions aren’t easy to implement, but they’re an investment in the longevity of your organization and your security teams. Synack can help augment your security team’s efforts by leading one-off missions to assess assets, going through security checklists or performing continuous pentesting on your entire organization. Contact us to learn more.