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.
- 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 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”.
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.
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.
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.