Log4j: Not the Vulnerability We Want, and Not the Vulnerability We Need

Log4j is the reminder we didn’t need: the reminder that vulnerabilities in software are not going away. These vulnerabilities are both new and old, and they can and will continue to be discovered and exploited.  As Kevin Beaumont wrote on Twitter: “Basically the perfect ending to cybersecurity in 2021 is a 90s style Java vulnerability in an open source module, written by two volunteers with no funding, used by large cybersecurity vendors, undetected until Minecraft chat got pwned, where nobody knows how to respond properly.” 

You can, should, and probably already do test the software that you outsource or borrow from the open-source community and commercial vendors. But knowing you have the vuln is not enough, do you know how to respond?  And perhaps the larger question, what about the software that you create yourself and give to either your employees or your customers? Each of those apps has, by definition, a working example showing how to access your back office. You can and should test those apps for vulnerabilities, but is there more that you can do?  Can you actively build security into your applications in order to prevent them from being tampered with or even reverse engineered?  One of the best kept secrets in the InfoSec community is that you CAN do more than test for vulnerabilities. Analysts call this technique of building security into apps as part of CICD, DevOps, or Value Stream Management a variety of things: App Shielding, In-App Protection, or simply App Security. Building these techniques into your CICD pipeline won’t help mitigate the Log4j or future open-source vuln fallout but it can bring you closer to preventing exploitation of risks in the apps you create.  

App Shielding/Protection/Security is the practice of building protections into code at compile time. The protections vary and can include obfuscation of code, encryption of data, and integrity checks. Collectively, these protections help prevent credential harvesting, application cloning, or application tampering – all of which can cause damage on their own or can be used as the first step in an APT-style attack. Protections can also be built in to alert you as to when and where your apps are being run in compromised or dangerous environments such as debuggers, rooted devices, or emulators.

App Shielding (aka in-app Protection or sometimes simply “App Security”) vendors exist to help security practitioners go the extra mile, beyond proactively looking for vulns in borrowed or outsourced software, to building security into applications themselves. Those in the security industry have long known that the next vuln is out there waiting to be discovered. Step 1 is to secure your perimeter with network and web app firewalls. Step 2 is to introduce SAST and DAST solutions to test software for vulns.  Step 3 is to build security controls into your software so that your software is less vulnerable to begin with. Plan for vulns. Find the ones you have. And implement App Sec best practices to ensure you are not building software that is, by its very nature, vulnerable to attack. 

For more information about building security into your apps, contact us at Digital.ai/support.