Skip to content

Responding to Novel Security Vulnerabilities

By Randy Shoup, Michael Nygard, Chris Hill, Dominica Degrandis

Learning from Log4Shell/Log4J

EBook Available Now On:

In early December 2021, rumors about a remote code execution vulnerability in Log4j began circulating on social media, and it was quickly dubbed Log4Shell. Over the next three days, those rumors were confirmed, an additional vector was found, and the immense scope of the vulnerability became clear. Log4j, a logging library used in Java development since 2001, could be provoked into loading code from an attacker’s host.

The vulnerability was found in on-premises software, software as a service (SaaS), and internally developed applications. Vulnerable versions of Log4j were in organizations’ applications’ direct dependencies and in their transitive dependencies. It was embedded in vendor products, including monitoring, visualization, and security tools. Mitigating this vulnerability required companies to change application configurations in anything Java-based. Remediating it required dependency updates, testing and deployment cycles, and redeployment of vendor software.

In the aftermath of this vulnerability, some organizations responded quickly and with relative efficiency. Others lost days before even beginning their response. In spring of 2022, some organizations were still struggling to fully complete their remediation. There is much we can learn from these differences among organizations, and this paper attempts to capture and synthesize some of those learnings.

  • Publication Date September 27, 2022
  • Pages 22

Features

  • Clear Guidance

    This paper provides clear guidance on how to respond and prepare for novel security vulnerabilities.

  • Expert Authors

    This paper was written by experts in information security who have real-life experience addressing security vulnerabilities.

  • Timely Topic

    This paper uses a real-life security incident to help show organizations differing levels of response.

  • Learnings

    This paper takes learnings from all over the industry and synthesizes them into an easy-to-digest set of tactics.

About the Resource

In early December 2021, rumors about a remote code execution vulnerability in Log4j began circulating on social media, and it was quickly dubbed Log4Shell. Over the next three days, those rumors were confirmed, an additional vector was found, and the immense scope of the vulnerability became clear. Log4j, a logging library used in Java development since 2001, could be provoked into loading code from an attacker’s host.

The vulnerability was found in on-premises software, software as a service (SaaS), and internally developed applications. Vulnerable versions of Log4j were in organizations’ applications’ direct dependencies and in their transitive dependencies. It was embedded in vendor products, including monitoring, visualization, and security tools. Mitigating this vulnerability required companies to change application configurations in anything Java-based. Remediating it required dependency updates, testing and deployment cycles, and redeployment of vendor software.

In the aftermath of this vulnerability, some organizations responded quickly and with relative efficiency. Others lost days before even beginning their response. In spring of 2022, some organizations were still struggling to fully complete their remediation. There is much we can learn from these differences among organizations, and this paper attempts to capture and synthesize some of those learnings.

Randy Shoup
Michael Nygard
Chris Hill
Dominica Degrandis
Randy Shoup

Randy Shoup

VP Engineering and Chief Architect at eBay

To Author Archive
Michael Nygard

Michael Nygard

Innovative technology leader

To Author Archive
Chris Hill

Chris Hill

Speaker, author, leader, evangelist, engineer, researcher, and disruptor in developer relations and experience

To Author Archive
Dominica Degrandis

Dominica Degrandis

Author of Making Work Visible

To Author Archive

Similar Resources