Avi Shua, CEO of Orca Security with tips for companies on how to discover and update all vulnerabilities, as well as mitigate them for the future.
“Due to the fact that Log4j is used in an immense variety of applications, end users are often unaware of which applications are resorting to it. In addition, it is more difficult to understand how much they are really at risk. This highlights a problem as old as IT security itself – the need for visibility to discover and update all vulnerable instances before attackers do.
To accomplish this feat, defenders must have a 100 percent accurate inventory of their cloud environment and all vulnerable resources. They must also have the ability to prioritize those who are exposed to the Internet and pose the greatest risk. This can be achieved through the use of a CNAPP (Cloud-Native Application Protection Platform), which provides a real deep inventory of the cloud environment and prioritizes the externally facing vulnerable assets. Patching and mitigating vulnerabilities such as Log4j can be a real challenge, but it is far better than groping blindly in the dark and not knowing which part of the environment is at risk.“
Among the measures that companies can now take to mitigate the downstream impact are:
- Identification of the enterprise applications with vulnerable libraries (with the help of a continuous scanning tool).
- Assessment of asset exposure and taking appropriate measures. Is the vulnerability facing outward or inward or completely blocked (this can be done manually or through CNAPP-like tools)?
- We recommend blocking externally facing applications that use the vulnerable library, unless there is a certainty that this vulnerability cannot be exploited or an updated version will be released. For internal applications, more discretion can be applied depending on the effect of blocking and the attack surface.
- Another approach is to implement mitigation. In this case, the risk of an impact is low, and the measure will work even if the provider does not provide a fix. The system property “log4j2.To set formatMsgNoLookups” to “true”, as a result of which the vulnerability cannot be exploited and no change by the manufacturer is required.