Log4j and Omicron: Brothers in harm, mothers of invention
That which does not kill us can still ruin our Christmas
Opinion Infosec takes many cues from the human immune system. The analogies and metaphors are useful and apt: viruses, vectors, evolving a defence where learning is part of the response...
It's not unreasonable to suggest that immunology and cybersecurity could learn a lot if they talked more. Sometimes, though, the parallels are far too close for comfort.
At the same time as Omicron is confounding our plans for pandemic management, Log4j has set the infosec world on fire. Both come after a year when – surely – we'd already seen the worst, whether it was Delta or SolarWinds. Both have followed the same cycle of early reports provoking "it can't be as bad as it looks" followed by "it's worse than that, how can we cope?" and thence into the long grim period of answering that question.
Fortunately, both the immune system and infosec have a lot of intelligence to adapt; and IT has the advantage of being far, far simpler than human and pathogen biologies.
Since Log4j hit less than a fortnight ago, the lists of affected products have appeared, the first sets of mitigations have been compiled, tested and published, and the attackers identified and categorised. The word "community" is hugely abused, but in cases like this it fits. Common interest is a given, common effort is freely joined, and common purpose is found.
Beyond the immediate technical and practical response, though, there are harder problems. How did the Log4j vulnerability escape testing? Why didn't we immediately know where it was being used? Who's responsible for each occurrence, and if they can't patch it, what then? When Sun Microsystems described Java as "Write once, run anywhere," was this really what they meant?
Excepting that last, the answers to all of those questions come in two parts: the answer for Log4j, and the answer in general. We have to fix the immediate mess, and that'll take months or years to sort out. Previous widely spread and easily exploitable vulnerabilities such as Heartbleed and Shellshock persist for a very long time after fixes are found and patches made available – one blended threat, Sea Turtle, was still using Shellshock five years after discovery. Not everyone patches assiduously, some not at all.
How did Log4j escape testing, and how might we know to test other components with the potential for planet-wide destruction? It's not like Pokémon, you can't catch them all, but if we dissect the factors that made Log4j such a risk, we may yet find the retrospectoscope useful. It processed arbitrary information from outside the systems it was used in. It had access mechanisms for a variety of external services that could deliver arbitrary information. It had a huge number of downloads and deployments.
We can look for these characteristics in components of any antiquity, and use them to signal the need for testing to 2021 standards with 2021 tools, not relying on whatever regime the component was originally built in. Like the human immune system, once you recognise the key characteristics of a threat you can identify new ones without needing to know all about them.
- Intel's mystery Linux muckabout is a dangerous ploy at a dangerous time
- The dark equation of harm versus good means blockchain’s had its day
- Smart things are so dumb because they take after their makers. Let's fix that
- Calendars have gone backwards since the Bronze Age. It's time to evolve
- Google's 'Be Evil' business transformation is complete: Time for the end game
As for not immediately knowing when and where Log4j was deployed, that's because IT doesn't take itself as seriously as a responsible production engineering discipline.
As occurs so often, looking to life-critical sectors such as aviation and automobiles, the problem has long been solved by maintaining decent bills of material and supply chain documentation. If a common aircraft part is found to fail in use, the regulators can issue clear and comprehensive messages of remediation. In IT, that's a stochastic process: we know exactly how to do it better, so let's grow up a little and accept we need to.
Which leads to the final big question: who's in charge? If you take a common component and build it into your system, how much responsibility do you take on for what happens next? In many cases, fortunately, that's clear – if you pay a vendor for a service or product, then you have a contract where such things can be explicit. If you're the President of the United States, you can tell all federal agencies that it has to be fixed by Christmas Eve – and if you're a federal agency and don't want your holidays ruined, you'll have mechanisms in place to make that happen.
If you're not Joe Biden, or you don't have a red button to push to send a shock to your vendors' fleshy underparts, either change that or take responsibility. If you can do either, change the product. Switch services. Make sure you can.
The takeaway from Log4j, as it is from Omicron, isn't that we are powerless in the face of the unexpected. It's that we are painfully slow to learn from even recent, radical events. Is there going to be a variant virus? Of course, no virologist would say anything else. Are there widely used components with hidden hideous vulnerabilities? Find an infosec expert who'll say anything else. Are there going to be people denying the bleeding obvious in every organisation? Look at the news.
If you have any flesh in your organisation's cybersecurity game, use Log4j to make the point that there are better ways to be prepared. Write a simple manifesto for everything your data touches: is this tested, do we know where it is, do we know who fixes it? It's not much to ask: don't take no for an answer.
Like the human immune system, every cell has a part to play, everyone has the responsibility and opportunity to make a better path for the next time the balloon goes up. ®