Whitelisting has been a buzzword used in the industry for the past 18 months or so, and is seen by some as a Panacea to beat Malware spreading within organisations and control threats inside your environment. Indeed, some of Symantec’s products use Whitelisting as an additional method of controlling software behaviour and limiting the applications that employees can or cannot use.
Whitelisting generally involves a process of learning exactly which applications, operating system components and hardware drivers are installed on a server or workstation, collating that information centrally, and then allowing an administrator to approve or deny the use of these tools.
Once this process has initially completed, enforcement of this list of applications is then applied to the target machines. Theoretically, this has given control back to the organisation in relation to what software is allowed to run on the corporate computers.
The flaw here comes from a few factors. Firstly, who exactly is approving these applications to run? Is it an administrator? Is it a member of IT security? Frequently it is neither of those roles, but given to someone in a support function who may not be au fait with every threat, vulnerability and exploit that companies are facing every day. Whomever this person is, your security posture now relies on this person to approve and deny applications to run on corporate computers. Will this person stand up to the MD or VP who wants his new Tablet software synchronising with his laptop NOW? What scans do they run or checks to they perform on the applications requested to be approved? Little or none in my experience, I have even seen this role given to a junior IT intern because it was seen as a thankless task to approve and deny application requests all day long. In fact beyond a quick Google search and maybe a virus scan, applications are rarely fully tested or verified. Some of the Whitelisting tools associate a reputational score to the application, giving an indication if this is a known good or bad application. This process has failed many times before and even been utilised in 2013 by Malware writers to spread their own “trusted” code within organisations.
The next flaw in this process comes down to the fact that Operating System components are trusted by default. I cannot stress highly enough that this is a bad idea. If a desktop PC was compromised by a Java attack, or an internet Browser vulnerability, such as found in vulnerability testing tools like Metasploit, the first thing an attacker will do is try and access operating system components such as the command prompt (cmd.exe) to do their nefarious business. If cmd.exe is trusted to execute without restriction, say goodbye to any chance of preventing an attack. We have recently seen malware such as Shamoon, Stuxnet and Korplug manipulate existing files that live on every Windows operating system to devastating effect as part of their attack. Nothing can be trusted in my opinion.
However, Whitelisting or Application Whitelisting as it is sometimes described is in no way a substitute for products that place zero reliance on trust when it comes to server security. Policy based security has been around for over 10 years now, and uses the principle of Least Privilege Access Control (LPAC). LPAC works intelligently to only allow an application, service, daemon or Kernel process exactly the right access to relevant resources on a server. Those resources might be the file system, network access, host memory, device or critical configuration file of the operating system itself.
Now this is the important part; there is often a large “gap” between the resources and privileges requested by an application, and those resources and privileges it actually needs to execute correctly and safely. This “gap” is what hackers and cyber criminals look to exploit. LPAC products, such as Symantec’s Critical System Protection, close these gaps to ensure that the system is safe and reliable. Unfortunately not all software developers code with security in the forefront of their minds, hence why these gaps appear. If we substituted the word “gap” for “vulnerability” in that last sentence, would we get your attention more?
The LPAC approach is almost the direct opposite to Whitelisting. It says “we do not trust any user, application, service or operating system component, if that element starts to behave suspiciously”. In this way, policies can be simply applied to a server to make it impenetrable to insider or external attack without having to intently look at which application is running, profile the server or learn what applications are in use day to day.
This approach is looked upon favourably by Compliance and Risk analysts and Auditors alike. The LPAC approach even allows you to remove full administrator or root privileges from your staff, thereby reducing the threats from insider attack or from well-meaning “misconfiguration” of servers.
Symantec Critical System Protection (SCSP) has been tested at Black Hat for the past two years and has defeated dozens of skilled industry professionals and Hackers alike in their attempts to locate hidden “flags” and critical documents on a server due to the capability of locking down a server and preventing malware from exploiting vulnerabilities in operating systems and applications.
In summary I would say that Whitelisting as a feature is powerful only when used in conjunction with other complimentary security technologies such as Sandboxing, Policy based Security, network Firewalls and Advanced Memory Protection tools. Symantec Critical System Protection uses Application whitelisting features when protecting retail EPOS systems, cash machines (a.k.a ATM’s) and Industrial control systems in SCADA environments where security of the highest level is required. SCSP trusts no-one, and that is a good thing.