In 2002, Defense Secretary Donald Rumsfeld gave a speech about a lack of evidence linking the government of Iraq with the supply of weapons of mass destruction to terrorist groups. This speech was remarkable for one thing only, that being the inclusion of the phase “known knowns, unknown knowns, and unknown unknowns.” These concepts finally entered common parlance. True, those in the security arena, both physical and logical, already knew and understood the terms, but now laypeople did as well.
Let me explain myself. In the IT security world, people concern themselves with known knowns, known unknowns, and unknown unknowns all the time, and each area has its security tool of choice. For example, known knowns—worms, viruses, Trojans, and other malware and vulnerabilities we are aware of—are dealt with by firewalls, IPSes, IDSes, and antivirus software. The rules of firewalls and IDS and IPS products, coupled with the signatures of antivirus tools, deal with those issues that are known. For example, firewall rules allow only the traffic that is allowed to travel to navigate the network, and antivirus rules look for particular code patterns and vaccinate and protect against them. Known unknowns are dealt with by heuristic scanning and education. It is the altogether more difficult unknown unknowns that give IT security professionals sleepless nights.
Unknown unknowns are those difficult-to-define situations: those vulnerabilities that are not yet known about, but also so far off the beaten track that they are almost unthinkable. How do we protect against those things we have no knowledge of?
There was a joke in the early to mid-1990s that the only secure Windows server was one that was not connected to the network and locked in a sealed box. Admittedly, things have improved recently. But the fact is, if something can not run on an environment, then that environment is effectively secure.
One very effective method is to create a whitelist of executables, DLLs, OCXes, and libraries. Now, it is true that this it is not a total panacea. However, the ability to blacklist every single unauthorized executable, script, and library and only run those that are needed to run the OS and relevant application sets is a powerful tool.
Why isn’t whitelisting a standard tool in the security tool set for day-to-day operations? Quite simply because historically, it has been very difficult to implement. The modern computing environment is an enormously complex beast. Add in differing versions of Java SE and DotNET, differing hardware and associated drivers—well, you get the picture.
Windows has had built-in whitelisting capability since 2008 R2 and Windows 7. This product is called AppLocker, and like a lot of things that have been finding their way out of Redmond recently, it is not a bad little product. And it does have an awesome price point: free. When the product was initially released into the wild, it suffered from the usual Microsoft malady of large portions of MS BS and small portions of functionality. This has changed with time: AppLocker is now a reasonable product and does a good job of locking down modern enterprise Windows operating systems. Application files can be opened up by vendor certificate, folder, or even file name. One possible issue with AppLocker is that it is purely computer object based, but that said, it is a valid paradigm. Many individual users can have access to a machine, and as policy is guided by Active Directory Group Policy objects, individual access can be finely tuned. Another large gap is with scripting. It is true that VBScript, JScript , *.bat, *.cmd and PowerShell scripts can be controlled. However, interpreted code that runs within a host process (Perl or macros) can only be controlled if the host process calls AppLocker before execution, the issue being that not all host processes call into AppLocker.
Also, and this is a major gap in the majority of whitelisting products, AppLocker only controls the execution of the application. It has no control over the child processes an authorised application subsequently launches.
This is why the CCleaner breach was so worrying. This application spoofed all whitelisting tools due to its having been digitally signed with a valid and trusted certificate.
Another weakness is that it cannot be used to protect 16-bit applications. Obviously, this is only a weakness on 32-bit operating systems and an issue of decreasing importance moving forward.
That said, is it worth it? Well, yes it is. And this is the important thing to understand: it can help, but it is not nirvana, to paraphrase the smiling adverts. It can only help as part of a holistic defense-in-depth protection.