Log4J

A vulnerability for the holidays.

Adam Bailey

1/20/2022 2 min read

The Security Apocalypse

The Information Security Apocalypse arrived in December 2021. A devastating vulnerability has been unleashed on us just in time for the holidays. This vulnerability is far worse than anything we’ve experienced. I’ve been in information security for a long time and seen all sorts of issues including SQL Slammer, Code Red, WannaCry, Heartbleed to name a few. This Log4J vulnerability is on a whole new level. Log4J is everywhere, integrated into third party software, Open Source, and corporate apps. The easy of which this issue can be exploited coupled with the fact it is a remote code exploit vulnerability have blown away what we’ve seen before. This issue is trivial to exploit, and I mean trivial. No coding experience required. Everyone can be a hacker. It’s now a mad race to patch the vulnerable systems. Ironically, while we rush to patch, we still are working to find out where Log4J is used. Several weeks after this vulnerability was announcement there were major software/appliance vendors that were still ‘researching’ if they are vulnerable or not. How can we contain this if we don’t understand our attack surface? This means we really won’t know the damage that will result from this issue for a while yet.

The painful truth

This vulnerability is teaching us some painful truths. Vulnerabilities like this remind us just how tenuous our position is and how quickly things can go from bad to worse. We must be darn near perfect otherwise we end up with something bad happening. That is our reality and what we fight every day. This makes it seem like sometimes like we are fighting a losing battle. I often feel we as an industry are one step behind and constantly playing catch up. It’s hard not to feel defeated sometimes. The number of breaches is growing and we’re patching the leaks in the dam with duct tape and gum.

However bad things get we must remain vigilant. Attackers’ methods are evolving, and we must meet the threat with equal vigor. This mean implementing defense in depth. Practices such as implementing principals of least privilege, making sure we are running the latest patches, avoid using end of life software and properly configuring our tools to defend against this threat. To many breaches are the result of poor or sloppy security.

We must also work with our developers to make sure they integrate security into DevOps. A developer who uses good security practices is worth more than a thousand security tools. Oh, don’t get me wrong, security tools are critical to our defense, it’s just if we can address root cause and avoid bad coding, we are going to vastly reduce our attack surface. Security and developers must partner together and become quite literally best friends. They should be meeting regularly, and developers must be afforded the opportunity to become security champions. Build security principals into everything we do. Empower developers to run security scans in the IDE’s. Automate security into the build pipeline. Shift security left and implement a DevSecOps model. Security should support developers and not become an impediment to an accelerated development process.

Our last line of defense is our people. They are the ones that are going to make a difference at the end of the day. We need to do a much better job of investing in our people. They are the ones that ultimately are going to make a difference. I cannot stress this enough we need to train, train, train, our security staff. Give them everything they need to do their job. Threat actors are well funded, trained and highly motivated (money does that). We as an industry must do the same. This is a call to arms. We must evolve and keep ourselves one step ahead of the threat actors. I know we can do this, and I believe we have the right people.