Is Log4Shell an OT or GRC Problem?

Mandiant Advantage indicates the most commonly exploited vulnerability of the last quarter is still Log4Shell. Veracode reports that 38% of applications are still vulnerable to Log4Shell.

Log4Shell remains a persistent problem because enterprise asset and supply chain management are difficult to sustain. This is hard to do well in businesses that deal in servers and workstations, it is even harder in businesses that deal in IIOT/IOT ([Industrial] Internet of Things) because they deal with a much greater volume of assets, and because those assets are often air-gapped.

The impact of exposure in the IOT world may at first seem trivial. If your fitbit is compromised, it might tell you you’re having a heart attack while you’re resting and listening to Chopin’s Nocturne No. 2. If the sensors provide data to control the flow of natural gas to all homes in your neighbourhood, you might be a little more worried if a criminal can unlock your front door, or prevent you from shutting down the blast furnace for the steel plant that drives the economy of your town. Given other articles about compromising thermostats and other sensors, it seems only a matter of time before the Mirai Botnet looks like child’s play.

Are Level 0 Compromises Really a Problem? It depends on the validity of the premise that level zero equipment is secure. If it is effectively air-gapped, then intrusion from external attackers will be challenging. If the supply chain is effectively controlled, then the base components both those in the initial build and those that comprise the evolving system as components are repaired, patched, updated, and replaced will be secure. Attention to detail is necessary to assure these premises. However, there are sparse details on compromises of these types. Instead, compromises of layers higher (1-5) in the Purdue Enterprise Reference Architecture are more commonly observed.

Given that Level 0 compromises are so severe, but that higher level compromises are more common, how should an OT enterprise approach security? Defence in-depth appears a good approach. So here are some tools to fill various gaps in the enterprise architecture.

  1. Do threat modelling by seeking evidence about contemporary attacks and extending from those to the border realm of possibilities.
  2. You can do extensive threat modelling, but if the threats haven’t materialized, you may wind up investing in mitigations that never provide benefit.
  3. Constrain your attack surface so that there is less to attack, but maintain awareness of the range of actors that might attack you and ensure that you have a clear understanding of what your true attack surface is.
  4. Implement an enterprise control framework like ISO 27001 or NIST CSF
  5. Replicate controls like RMM (Remote Monitoring and Management), XDR (Endpoint and Server Detection and Response) at the lower levels of the architecture. With tools like those provided by Nozomi or Dragos.
  6. Use Network tooling like NAT gateways (the Azure service has the same name) to ensure that devices call out for updates rather than having internet-accessible ports.
  7. Ensure that automated registration using certificates is used where possible on the OT network.
  8. Perform regular risk assessments to maintain the balance of availability, integrity, and confidentiality. This is particularly challenging in OT environments where performance (availability) can preclude the use of encryption – either one or two-way.
  9. Once you’ve developed an accurate asset registry, work on cleaning it up piece by piece: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/