The unofficial, unauthorized retrospective, 9 months later.
If it was not clear before, after Log4j, it certainly is now! Everybody uses open-source software in their applications. There are no exceptions, and as a result, we are all at risk of being breached by vulnerabilities in open-source software. The Log4J bug was a wake-up call.
The Apache Log4j vulnerability was one of the most significant breaches in recent history. Its impact was felt worldwide, and the repercussions are still being felt today.
In this live event, Lunasec founder and CEO Free Wortley, AppSec Expert Jim Manico, and vulnerability scanning implementor (and Apache committer) Julius Musseau come together to discuss the 2021 Log4J debacle.
It’s been nine months since the Log4j vulnerability was disclosed! Aside from Minecraft, have any serious breaches dropped in the last 9 months? Or did everyone fix it in time? And what was so special about this bug?
To understand the issue and prepare for the future, we need to analyze the root causes of the breach and come up with a set of recommendations that can help prevent similar issues.
- What did library developers learn from the incident?
- What have common app developers learned?
- How should the software industry prepare for future incidents of this scale?
Learn from the past and prepare for the future.
Live Event Highlight
Log4J Timeline
1999 – Log4J 1. x is born
2014 – Log4J 2. x is born (includes: JNDILookup.class)
2015 – General purpose JNDI exploit technique demonstrated at BlackHat
2021 – November 24th – Vulnerability shared (privately) with Apache
2021 – December 4th – An interesting commit lands
2021 – December 9th – First Annual Log4J Global Day of Celebration
2021 – December 10th – Version 2.15.0 Published
MergeBase’s Log4J Detector
With Mergebase’s Log4J Detector tool, you can accurately find the log4j vulnerabilities in any cloud system, situation, and context.
CSRB’s Report
A new report from the Cybersecurity and Infrastructure Security Agency’s (CISA) Cybersecurity and Infrastructure Resilience Bureau (CSRB) addresses the continued risk posed by vulnerabilities discovered in late 2021 in the widely used Log4j open-source software library, one of the most serious vulnerabilities discovered in recent years.
The report contains 19 recommendations for government and industry, focusing on driving better security in software products and enhancing public and private sector organizations’ ability to respond to severe vulnerabilities. The goal is to identify and share lessons learned to enable advances in national cybersecurity.
“Our nation’s cybersecurity depends on the security of the software we all use every day,” said Tonya Ugoretz, Director of the CSRB. “
Advice for library Developers
- Be more careful when preparing the fix.
- GitHub has the capability to make the pull requests and the issues private even though you’re running on a public repo.
- Security audit code audit needs to be happening regularly with libraries that are used everywhere.
Advice for library consumers (a.k.a. Software engineers)
- Know the libraries that you have (SBOM)
- Keep your libraries updated and patched.
- Keep tabs on your SCA tool – for example: How quickly was your team able to become aware of the path and how quickly they are able to apply the patch?
Advice for CISO’S & Executives
- Don’t let your developers pick any third-party library enrolled in production; you need a stronger vetting process and understand the business risk of choosing a third party.
- Running an SCA tool, like MergeBase, several times a day.
- Have the willingness to update your libraries. Suggestion: keep all your libraries updated but keep one month behind an update unless you need to be at the bleeding edge because there’s a security vulnerability. Otherwise, keep a month behind the top level and then update it to avoid supply chain issues.
