By: 1337Mark – Information Security Manager at A Company
Dear CISOs
If by now you have not yet already implemented application whitelisting or decided to do so within the foreseeable future, I hope to change your minds.
Application whitelisting has become or should at least be regarded as a norm by now for most verticals and sizes of business.
A blogger wrote this in 2016 regarding Application Whitelisting (AW) being named a “quick win” by the critical security controls:
…but calling things like Application Whitelisting a “Quick Win” is a bit troubling. Application Whitelisting is something that only really dedicated or advanced organizations are capable of, and that dovetails into the rest of the categories… Not all environments are the same and so planning for the controls based on categories potentially led to an over investment in areas such as detection
But I do not agree with this, for most companies and in most cases.
Deploy application whitelisting that allows systems to run software only if it is included on the whitelist and prevents execution of all other software on the system. The whitelist may be very extensive (as is available from commercial whitelist vendors), so that users are not inconvenienced when using common software. Or, for some special-purpose systems (which require only a small number of programs to achieve their needed business functionality), the whitelist may be quite narrow.
Let’s look at what AW is a good idea.
Reason 1: It gives red teams problems
Well first of all, talk to a few pentesters or red teamers. Ask them the question: “What gives you problems on a pentest/engagement?”. Smart money will be on either “Application Whitelisting” or something along the lines of “companies that patch everything”/”..that have an efficient SOC”/”….that have a locked down attack surface”.
I am not saying that your friendly pentester will say they failed. Most likely they will not have failed to find significant vulnerabilities, but AW will have caused them considerable pain.
Reason 2: Blacklists are unmaintainable
Another good reason: We all know that blacklisting is a bound to fail, sooner or later. Blacklists simply cannot keep up with everything. Whitelisting has a much narrower focus and is often easily doable, running out of the box as AppLocker or rather simple to implement at scale such as Bit9. Blacklists and whitelists together makes even more sense to me.
How about using the kill chain to look at AW?
Reconnaissance: Ok, no effect on this step. Same for Weaponization, Delivery, and Exploitation.
Installation:
Yes, AW can block payload delivery from an email vector. It cannot block an unpatched vulnerability in software that is allowed to run, obviously. But if it’s not allowed to run, it shouldn’t be there, and if it is allowed to run, it should be patched.
AW can also interfere with an adversaries attempt to install a C2 channel plus. AW can block attempts to install and run or run software used for lateral movement and internal enumeration. If we look at Sean Malone’s expanded cyber kill chain it makes even more sense to use AW.
(picture here)
From this slide, note how AW can interfere with the operations of an adversary at MULTIPLE steps of the kill chain model.
Reason 3: You can instrument AW to build threat detection capability
Once you’ve implemented AW, you can instrument your devices to alert on failed attempts to run non-whitelisted software. This could give small headaches in the beginning, if you switch too quickly from a monitor-mode implementation to a blocking mode, but in the long run this is sure to benefit you. Added on top of instrumented blacklistalerting, this gives you extra detection capability you did not have before.
Reason 4: You can use it to reduce scope of a forensics investigation
If you’ve added AW, then whitelisted executeables can be used to reduce the amount of logs a forensics investigationhas to go through. Be aware though, that depending on how you’ve implemented you AW, this can also lead into a black hole. If, for example, you’re using the method of whitelisting applications based on the providers signing certificate, then you cannot simply eliminate Microsoft binaries from your forensics investigation, because attackers like to “live off the land” and re-use tools that already exist in your environment.
Reason 5: It forces you to enumerate which software your company uses
If you decide to implement AW, you will be forced to find out which software exactly is used where in your company. You will benefit greatly by creating specific profiles for different types of employees, rather than a gold image for the whole company. To each profile you should assign only the whitelisted application relevant for this profile and nothing else. So you will end up knowing exactly what is used where and for what. This is an important piece of data to have, as important as knowing exactly which devices you have.
Implementing application whitelisting
Survey the market of different vendors of application security and compare them up against your requirements and Microsoft applocker. Choose something that suits your organization. Decide on a method of implementation – certificate based, gold image based, binary based per employee segment. If you go with the gold image, you can always block specific application for specific groups of employees via GPO, although that’s extra unnecessary complexity in my opinion.
My recommended way of doing the implementation is to install application whitelisting in monitor mode for an extended period and use this to build up the above mentioned employee profiles.
Then move into block-mode. Then profit from seeing frustrated pentesters!
Originally posted at Peerlyst
By: 1337Mark – Information Security Manager at A Company