The recent Log4j vulnerability, which Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly called “the most serious vulnerability I have seen in my decades-long career,” forced many Security and Development teams to work through the holidays to protect their organizations. Open source software is everywhere now, and this particular vulnerability is a reminder of what can go wrong in the complicated modern software supply chain. Not only do administrators need to patch the flaw, but it has been difficult for Sec/Dev teams to discover what products or systems are affected. With the Federal Trade Commission (FTC) issuing a warning of potential penalties for those that fail to take action, organizations need to find a way to prioritize remediation efforts.

Wabbi customers had the ability to integrate with a number of helpful tools when this first came to light, and teams were able to push out requirements that scanned important systems. More importantly, they knew which projects were impacted for those that have a categorization and were able to assign security requirements by profile. By deploying policies based on project attributes, our customers were able to roll out new policies that would immediately stop this flaw, pausing the software development pipeline until all scans came back and the true impact of the vulnerability was clear. 

As Sec/Dev teams scrambled to protect themselves and remediate the damage from Log4j, it became apparent that even the best of DevSecOps automation efforts could not meet the demands of such a severe zero-day vulnerability. While it will continue to be everybody’s problem for quite a while, we’ve already learned three things from this incident

You can’t fix everything at once

You know the phrase: You can’t boil the ocean. While it may be possible for massive organizations to assign teams to address multiple issues simultaneously, it just isn’t possible for a small organization to fix every flaw at once. First, you have to identify what needs to be fixed. Then you have to designate what has been fixed. Log4j is bad for everybody, but organizations need to prioritize the worst places of impact and concentrate remediation efforts through a ticketing system that builds security profiles by application. When scans come back and identify vulnerabilities, each ticket should be ordered and addressed by priority – with everything else on the production line on hold until it has been pushed through the system.

 Crisis management must be dynamic

Organizations need to be able to manage vulnerabilities like this without having to send out a bunch of emails. By managing the crisis within one system, they can have the confidence to know that once new security policies are rolled out, the necessary patches are in place. At one point with Log4j, we saw three patches rolled out within five days because new vulnerabilities continued to be found. Without automation and orchestration, this becomes infeasible. Organizations need a master of record that contains security project profiles so they are able to confidently and dynamically adapt as they see how policies impact the pipeline.

Good hygiene is crucial

Ideally, organizations will have some form of proactive security in place ahead of an incident like this. Proactive security is ensuring you have the right processes in place to do the right thing according to accepted risk. Now that organizations have implemented response mechanisms, they have a record, and hopefully confirmation, of actions that show they responded correctly. This provides a compliance factor that can give organizations confidence when connecting with their customers about an incident. 

We will continue to learn from Log4j as organizations grapple with the widespread repercussions of this vulnerability. Zero-days are inherently unpredictable – but you can plan for uncertainty. When Sec and Dev teams come up for air after this incident, it will be critical for them to look at where they can leverage today’s technology to prepare for the next zero-day.

Wabbi’s centralized policy engine correctly assigns the right policies to the right projects every time. With an ever changing threat landscape, organizations can clearly determine which projects are impacted by policy changes, and automatically push out notifications to stakeholders to ensure code is always meeting the current security standards. Reach out to learn more!