December 17
0 comments
As you know the Log4Shell/ Log4J event has been on the cybersecurity radar for the past 7 days. Overall, to the cyber landscape, this is a massive event. HOWEVER, networks in which no services are hosted for external (consumer, enterprise logins or large employee access), the risk is low.
If you are unfamiliar with this event Log4J is a Java library that takes text strings and stores them in log files or a database. The Log4J application uses logs to keep track of all sorts of data while using the application. Like websites visited, internal notes for code, and all other sorts of information that is required to use the device that Java is installed on. The data stored in those logs are used to help support teams triage problems with the applications running Java. It just so happens that those logs can also contain a line of code that allows an execution of lines of code within them. Meaning that a string of code could bypass the firewall, IDS/IP, and LDAP without you knowing and execute on the network allowing a bad actor to do what they want.
We are trying to identify what our strategy needs to be. After SolarWinds, regulators asked entities to reach out to critical vendors and get their stance/usage of the tool. This is different because Log4j is almost used by everyone.
Here is what we suggest from a vendor standpoint:
* Collect all these notifications from vendors.
* Identify any notifications not received from critical and high risk vendors.
* Reach out to the vendors that have not made outward facing statements for their official stance.
* Take suggested vendor actions, as it pertains to THEIR systems. In many instances, there won’t be any action.
Here is what we suggest from an internal operations standpoint:
* Run internal scans on your network.
* Identify and systems identified with Log4J on them.
* Apply the patches/updates from Windows and Apache.
* Re-run internal scans to prove up patches/updates. OR manually note approach to address identified systems.
This Log4J vulnerability is changing quickly. So the approach to patching may change quickly and often. For example, the first patch has a vulnerability in it as well. So what is better patching a vulnerability with another vulnerability??!?! Or waiting for the operational version?
Here is a link from CISA on how they suggest to move forward:
https://www.cisa.gov/emergency-directive-22-02
We have also attached a slide from a Rapid7 discussion of the event to show how the attack works.
Finally, our Vulnerability Management as a Service (VMaaS) has proven to be invaluable at this time. We are able to scan networks on demand and quicky identify which systems (if any) have Log4J and what action needs to be taken. Send a note to sales@itvoice.com if you’d like more info.
We can set you up with our VMaaS offering ASAP!
