The ANAO's application whitelisting audit is murky

Government departments are fairly good at implementing application whitelisting, according to Australia's national auditor, but details on how it measures this apparent success are hazy.

Last week, the ANAO published its findings after reviewing the security postures of the Australian Federal Police (AFP), the Department of Industry, Innovation and Science, AUSTRAC and the Department of Agriculture and Water Resources.

It found the departments were underwhelming in their ability to meet the requirements of the ASD’s mandatory top 4 strategies to mitigate targeted cyber intrusions [pdf].

The report focused on patching being one of the biggest problem areas, while application whitelisting (number one on the ASD’s top 4 list) had been implemented fairly well.

Ignoring the fact that patching isn’t too good - an issue most organisations struggle with - the report said all entities had implemented application whitelisting on their desktop systems.

Sounds good, right? If they are all great at application whitelisting then who cares if the software is a little out of date, malware simply won’t run.

This, unfortunately, is where I waiver.

Application whitelisting is a way of preventing unauthorised applications from running on your computer, which in theory should stop all that nasty malware from executing, including where viruses modify existing applications.

Whitelisting is implemented by a shim in the file system that halts execution until it decides if the executable is ‘on the list.’ If it’s authorised, it allows execution to proceed, otherwise it halts execution and reports the exception to the user or administrator.

It really sounds like the panacea of security control, however, I’ve seen just how hard it is to properly implement, and it’s one of the most difficult controls to retrofit to an organisation, especially if you’re planning to do it holistically.

To do this right, every single execution environment in your business will need to be locked down and controlled under the same application policy.

The technical implementation method used in the whitelisting process is also a really important consideration. If we take the example of Microsoft’s built-in whitelisting service, known as AppLocker, it uses a kernel-mode minifilter driver that intercepts execution requests, with three different methods of decisions making on what can execute:

1. Path rules: where the path of the application executable is checked and only files in whitelisted paths can run
2. Publisher rules: where applications need to be signed with a permitted certificate
3. Hash rules: where a valid cryptographic hash of every single permitted applications has been preloaded into the environment and each execution is tested against the hash list.

The easiest and quickest way to get application whitelisting running is to use path rules. However, the default rule for executing files in C:\Windows and C:\Windows\System32\ means that all malware needs to do is write itself into C:\Windows\Temp, C:\Windows\Tasks or any other directory that sits within the path rules defined in AppLocker.

If you want to prevent this, you need to have a really well locked down PC with a flawless implementation of access control lists across the entire file system, something that very few enterprises have.

If you opt for publisher rules you might find that some of your older applications don’t work since they're not signed, and it gets really messy. You’ll find that the exceptions you need to build into this implementation leave your systems wide open.

Hash rules are by far the best approach for whitelisting as they are the most comprehensive protection mechanism. They should check every single application, no matter where it is, prior to execution against the pre-authorised list. You can integrate this with software deployment technology so anything updated from a ‘trusted’ service (such as Microsoft’s SCCM) will be allowed and the hash list will be updated.

Sounds great, however, it does come with its own overhead. You still need to preload your standard operating environment (SOE) with hashes, and there is an overhead on managing this additional step in updating systems – you need to make sure your software update testing process includes checking that AppLocker doesn’t break something. I’ve seen vital operating system functions be blocked after Windows OS patches are deployed, leading to a complete denial of service.

You’ll also have other operating systems running in your enterprise – what about all those network devices, all-in-one MFDs with UNIX operating systems, Apple OS X systems and UNIX servers?

A consistent approach to whitelisting is needed so you don’t simply kid yourself you are safe while a whole portion of your network is wide open. Your corporate policy should extend the requirement for whitelisting to all environments, not just your Windows systems.

With adequate planning and thorough testing, whitelisting can be an amazing uplift to your organisation’s security posture.

However, I’d expected a much more in-depth report from the ANAO on specifically how whitelisting has been implemented across these government departments.

If we're auditing departments for their use of whitelisting, don't pull the wool over our eyes - we need to see detailed architecture and penetration testing to give us confidence they were looking at the right controls.