Mitigation strategies against cyber threats

NVISO, Application Whitelisting, Cyber Threat Mitigation, Patch Management, Cyber Threats 6 Minutes

So it’s been a good 2 months since we have been in business! We thought we’d to take some time to reflect on these two months, in which we’ve seen quite some interesting security news including the well-known Mandiant report on APT1 and the widespread Java chaos.


Last week, ENISA published a “Flash Note” on Cyber Attacks, urging organizations to take precautions to prevent cyber attacks. In order to protect against cyber threats, they provide the following recommendations:

  • Protect targets to avoid weaknesses being exploited by adversaries: prevention should be the primary defence against attacks.
  • Consider the use of more secure communication channels than e-mail in order to protect users from spoofing and phishing attacks.
  • Proactively reduce your attack surface by reducing the complexity of software installed on user devices and reducing the permissions of users to access other devices, services and applications by applying the principle of least privilege.
While we believe these are good recommendations, we are also convinced that it is often not easy for organizations to practically implement this type of recommendations. 

An interesting, more practical perspective on defending against cyber threats is provided by Australia’s DSD (Defence Signals Directorate). In the same spirit of the “SANS Top 20 Critical Controls“, the DSD has summarized a top 35 of mitigation strategies to protect against cyber threats – a ranking based on DSD’s analysis of reported security incidents and vulnerabilities discovered on Australia’s government networks.

That top 35 is of course just another large list of security controls that should be implemented. Interestingly enough however, the DSD noticed that 85% of all cyber threats can be mitigated by only implementing the top 4 of these 35 strategies. This top 4 boils down to the following controls:

Let’s face it: with malware developing at the pace it currently does, it is unrealistic to expect that antivirus solutions will offer in-depth protection against every single malware infection. They are a good and necessary first step, detecting older and known malware, but the most effective method is not trying to detect malware: it is to allow only known, valid programs to run.

While application whitelisting clearly is the “way to go” with regards to security, it’s often not an easy choice for various reasons (“Damn you IT, this is not workable!”, “We are a company with an open culture, we don’t lock down our desktops”, “We trust our employees”,…). If you ever manage to convince your organization to consider application whitelisting, another daunting challenge awaits the IT administrator: creating and managing the application white list.

Now, establishing what ‘valid’ applications are for your environment is no easy task. Next to the usual client-side applications such as PDF readers and other office software, the list of approved software will also include applications specific to your environment. So how do you about creating / managing this type of whitelist? Here’s a couple of ideas:

  • To create your initial white list, a good idea would be to use a normal employee workstation and list all of the installed applications. In a reasonably static environment, this could be a good approach, seeing as normal employees wouldn’t be able to install new applications themselves anyhow.
  • A less “strict” approach would be the use of “software signing”. You could protect your environment by only allowing software signed by trusted developers / vendors to be installed.

If you cannot implement application whitelisting in a “blocking” mode, consider configuring it to only monitor (not block) applications that are not on the white list. This will provide you with additional insights on the software running in your environment, without further restricting your employee workstations.


When it comes down to tooling, there’s several commercial solutions available. For typical large Windows environments, a good solution is AppLocker which further builds on the older “Software Restriction Policies”.

This is where it all starts. We are still seeing too many organizations that lag behind when it comes to the roll-out of security patches for operating systems and server software. 

During the majority of our security assessments and penetration tests, we are frightened by the number of hosts that are missing 6-months old critical security patches. Unfortunately, any one of these critical risks is usually enough to compromise an entire Windows domain.

In order to keep abreast of new security vulnerabilities, organizations should set up an effective patch management process. I’m sure most of you have this type of process, so let’s take a closer look and see whether your process includes:

  • A security patch assessment that verifies to what extent security patches are applicable to the organization and what the actual impact is;
  • A release cycle for security patches that includes proper testing and a controlled release;
  • An emergency process for urgent and critical patches (based on the criticality of the patch, you should consider what the biggest risk is: following the process and increasing your exposure window or immediately applying the patch and risking availability issues?);
  • An overview of all systems and their configuration to ensure all concerned systems are patched;
  • A process for temporary workarounds;
  • A system that provides metrics and monitors the effectiveness of the process itself.
Server-side vulnerabilities usually receive the most attention from organizations, even though patching client applications deserves just as much focus. Using security’s weakest link (humans), attackers often use a combination of trickery (e.g. spear phishing) to exploit vulnerabilities in client applications.

Just consider the following vulnerabilities for JRE (the Java Runtime Environment):


Java Runtime Environment (JRE) vulnerability overview

These vulnerabilities often remain “hidden”, as your typical network vulnerability scanners (e.g. Qualys, NeXpose, Nessus,…) will not pick them up by default.

There’s a couple of ways of identifying what software is running on your client machines:

Network scanners can usually be configured to actually authenticate to hosts in your environment and detect vulnerabilities in the installed client software. Although this type of configuration works well and provides you with the required information, it is something that should be implemented and monitored very carefully. After all, you are providing an automated vulnerability scanner with (administrative) credentials to your client machines. I’m sure most of you had some incidents in the past where a vulnerability scanner did some things you didn’t expect (e.g. use an “unsafe check” that takes down a vulnerable server). Now imagine the havoc a scanner could cause when he has administrative privileges to 90% of your network.

Install “application monitoring” software on your client machines. An alternative to the above approach is to install a small monitoring tool on your client machines that sends information on installed software to a central server. You can then centrally track the different software versions in your network. A possible pitfall here could be privacy issues that would prevent you from installing this type of “monitoring software” on your employee machines, so it’s something to first check with your legal department.

Once a system has been compromised (in any way possible), an attacker will attempt to further escalate his privileges both on the system and inside the victim network. To minimize and to track administrative privileges will help you contain malware infections and compromises (which will eventually occur in any environment).

As a good example of this, many IT organizations have an abundance of administrative privileges attributed to IT staff (e.g. the majority of IT staff has domain administrator privileges). It is understandable that “the business needs to keep running”, but there’s a couple of ways to improve the situation without “crippling” system administrators:

  • Provide system administrators with two accounts: one for normal daily usage and one that can be used for administrative tasks.
  • Review administrative accounts and apply the least privilege principle, i.e. system administrators often require elevated privileges, but not “Domain Administrator”. 
  • Review application accounts and apply the least privilege principle, i.e. do not let your applications run with SYSTEM privileges.
  • Implement and enforce a proper IAM process for administrative accounts that will monitor the spread and usage of administrative accounts.

Conclusion?
Over the years, a number of organizations invested time in creating “security control lists” to assist organization’s in minimizing their exposure to cyber threats. While most of these are good, we believe Australia’s DSD does a very good job in defining 4 concrete and clear mitigation strategies that can be applied to most organizations.

It’s clear that all of these controls deserve a dedicated blog post that provides additional insights in how they could be implemented. We do hope that this post has given you some food for thought and we’ll make sure to regularly provide you with more insights. 

If you’re interested in more NVISO updates and info on how we can help you, please visit www.nviso.be.

References:
–Mandiant APT1 report

Published by Daan Raman

Published

Leave a Reply