Log4j is a Java-based software library used for login purposes. It is widely used by businesses and websites from around the world as a language and this software is publicly accessible and used to collect and store records of activity on a server. On 9th December 2021, an error code was identified and immediately rated a 10 out of 10 on the Common Vulnerability Scoring System (CVSS) because of the potential impact it can have if leveraged by attackers.
This vulnerability could allow malicious attackers to execute code remotely on any targeted computer. Hackers could easily steal data or take control over anyone’s system and expose organisations to new cyber threats. However, this risk can allow malicious attackers to use the code remotely from any targeted computer. Criminals can easily steal data or take control of anyone's system and expose organizations to new cyber threats. Putting aside the madness, however, is the time to reflect on the lessons we have learned from this incident.
1. Update Log4j dependencies
CVE-2021-44228, also called Log4Shell or LogJam, is a Remote Code Execution (RCE) class vulnerability and is highly susceptible to exploitation. Almost all versions of Log4j are vulnerable – be it 2.0-beta9 to 2.14.1.
The best protection method identified is to keep updating the software and install the latest version of the library. Along with keeping an eye on probable threats, it is also advisable to install security solutions on servers — in many cases, it will help detect the launch of malicious code and stop the attack’s development.
2. Integrating Standard Security Practices for Software Developers
While ‘patch testing' has been a common practice in high-risk cases, the Log4j vulnerability, the attack vectors, and implications, however, were found to be different.
A good way of dealing with this is to integrate a standard security practice for software developers. And the developers are very lax about tracking what they use in their software. In scenarios like this, where it becomes critical to identify whether some library or component is used by our code, that lack of traceability becomes a major problem. Therefore, a simple security practice of checking inventories may come in handy in the long run.
3. Having a Defense in Depth or the Castle Approach
Defence in Depth or more commonly known as the “castle approach,” means that layers of defence systems are mirrored of a medieval castle. There are multiple walls, gates, and drawbridges that have to be surpassed to enter the secured portion of the castle. Organisations need to adopt this safety mechanism and create a provision of multiple approaches and tools to secure their castle.
Log4j gave a false sense of security related to commercial tool vendors repeatedly stating that the vulnerability had been resolved, or a foolproof detection method had been found. In practice, there were several discovered bypasses for detection and mitigation technologies. Proper security posture should comprise multiple layers of security controls.
4. Fix and Find
If organizational data is going to be compromised, it is best to fix the problem first and find out why later. Once you have fixed the issue with the best available solutions, then focus on understanding how the attacker entered the network and what level of access they have achieved and routing the attacker. To do this, follow your organization’s security playbooks and focus on what can be done in this situation.
Data ingestion with DNIF HYPERCLOUD SIEM
How will an organisation know if the exploitation attempt was successful? Given the large volume of data generated by application logs, ingesting it into SIEM can be costly. Furthermore, if the data fills up the storage, the search would take an eternity to complete. This is where DNIF HYPERCLOUD comes to the rescue.
When this vulnerability was known, DNIF HYPERCLOUD developed a workbook to aid in the hunt for potential exploits and pushed it to all DNIF HYPERCLOUD deployments via the platform's active threat content feature. This could confirm the presence of an attempt to exploit the vulnerability. With DNIF HYPERCLOUD SIEM, data ingestion is straightforward. Once the data is collected, a single query can scan through entire tables at a rate of 100 million records per second. One doesn’t need to worry about the volume of data being ingested or reducing the number of non-prioritized logging devices or worry about the impact on performance because the compression rate in DNIF HYPERCLOUD is greater than 90%.
