With all the hoopla around Log4j over the last while, I have been thinking of the top strategies a company can implement to prepare for and deal with critical vulnerabilities that inevitably impact the IT world from time to time.

To do this, I had a look at Log4j and other top vulnerabilities including eternalblue, heartbleed, and the SQL slammer worm to consider how organisations can enable themselves to deal with these in future. These are some ideas:

Incident response capability: The first suggestion is to develop a very effective incident response process. Key to this is to have a written down incident response plan with clearly defined roles and responsibilities, or who is going to do what. Another important part of the plan is to establish how the team will deal with the incident. Ie. Where will they meet, how often, even down to the finer details of who is taking notes during the incident, and where will the actions be logged. Setting up this capability upfront will allow organisations to effectively respond to incidents when they occur.

Inventories: A consistent issue I have noted is that companies often do not understand their IT estate. Remediating vulnerabilities is very difficult for the incident response team if they must first find the affected software. Dealing with Log4J is a case in point as this vulnerability is impacting multiple applications and other software, whether they are in-house developed or purchased. It is thus suggested that an inventory of all hardware, operating systems, databases, and application software in operation be retained and kept up to date.

Anti-malware software: Anti-malware software may not have detected the initial attacks to exploit the Log4j vulnerability, but anti-malware software vendors are usually very fast in updating their systems to detect attacks focused on the latest vulnerabilities.  Having an industry-leading brand of anti-malware software installed on all systems, including servers is a great preventative control.

Port level firewalling: A vulnerability cannot be exploited if the vulnerable system is not accessible from elsewhere on the company’s network or internet. So, making systems inaccessible unless required for business purposes is an effective preventative control against any serious attack. Systems available on the internet should only run TCP services absolutely required. Internal systems should be segregated where possible from the rest of the network, accessible only via jump boxes to stop them from being accessible by malware traversing the internal network and preventing other lateral movement.

Web application firewalling (WAF): Implementing a WAF can protect systems from exploits even if the systems are vulnerable. This is because WAF systems stop the specially crafted requests required to exploit vulnerabilities such as Log4J from reaching systems.

Monitoring: It is nearly impossible to recommend pervasive monitoring that will pick up every attempt to exploit systems. I think the key thing here is to have a security monitoring or SIEM capability. These can be proactively configured by the incident response team at the time of the incident to detect attempts to exploit the vulnerability.

Updating software and patching: A number of new vulnerabilities affect older versions or unpatched software. Generally patching is done quite well on an operating system and sometimes database level. Log4j has now given us a reason to constantly patch/update other application software too.

So that’s it, some ideas for preparing for and dealing with critical vulnerabilities. A number are best practices recommended in our other blog posts.

There is absolutely no silver bullet, but implementing these should help companies prevent, detect, and effectively respond to security incidents caused by significant vulnerabilities.