I recently wrote about how anomaly detection appears to be the holy grail in the fight against malware and bad-actor attacks. It is one of the few technologies capable of defeating zero-day exploits and undisclosed malware.
That said, anomaly-detection platforms are expensive and not within the reach of smaller organizations. Something I learned from business owners who voiced their frustration and challenged me to find a solution that fit their budget.
Often, while researching anomaly-detection, the technology would be referred to as a “self-configuring whitelist.” Could whitelisting be the answer for companies that cannot afford anomaly detection? Possibly. The dark cloud of inconvenience overshadowing application whitelisting needs dealing with first. That dark cloud: application whitelisting equates to “default deny.” Users lose the “personal” in PC and IT-staff members are forever adding to or subtracting from the whitelist.
Finding the answers
That said, it’s been a while since I looked at whitelisting, maybe developers have improved the platform. After some false starts, I found answers at the InfoSec Institute website, in particular, Top 10 Common Misconceptions About Application Whitelisting. This paper was written by John Fox, a 20-year veteran in software development and director of engineering at Savant Protection, a company specializing in application-whitelisting solutions.
Fox starts out by echoing a question asked by the business owners: If whitelisting is so good, why isn’t it used more? His response: “If whitelisting does a poor job, it may keep you secure, but it will interfere with your ability to use the system the way you intend by blocking non-malicious code. So most people have traded proper security for ease of use.”
Fox then mentions current application whitelisting systems are much improved. As proof, Fox addresses ten popular misconceptions associated with application whitelisting. Rather than run through all ten, here are those of interest to business owners:
First concern: App WhiteListing (AWL) is not needed, because Windows and UNIX have the technology built-in for free.
Fox agrees that most operating systems have “deny-by-default” technology, such as AppLocker by Microsoft. However, these tools are difficult to setup and use. Fox mentions, “The management interfaces for most of these tools requires the IT admin to identify specific files that should or should not be allowed. On an operating system that is in use for any purpose, there are thousands of files involved, many of which have legitimate needs to change on the fly. Manually managing the list of specific files that need to be approved or denied can be a burden that far outweighs the security gains.”
The business owners agree with Fox. In fact, if AWL platforms are anything like AppLocker they want nothing to do with them.
Second concern: Application whitelisting is difficult to manage.
Fox agrees that managing whitelists is difficult. However, unlike whitelists built into the operating systems, third-party AWL software only requires high-level approval. After that, the software takes over. Fox explains, “Modern AWL systems are adept at tracking what is happening on a system when approved changes are made and manage the whitelist database accordingly.”
Third concern: Only administrators can make changes and add new applications.
Fox addresses this by saying good AWL software will use multiple ways to configure AWL software. Which method depends on what the company wants. Some businesses may want to trust users, allowing them to install and use applications. This is important for remote workers, and those traveling. The alternative is that only AWL administrators can make changes or additions.
Fox mentions an interesting middle road. He says, “If I want to reserve all approval for the admins and not give any explicit trust to end users, I should still be able to do that without making end users wait for approval. I should be able to have an admin configure the AWL solution to pre-approve certain applications that are okay to install on user’s systems, and when the end user tries to install those, they should proceed immediately.”
Fourth concern: AWL does not work alongside existing security solutions like antivirus.
According to Fox, there is no reason security software and AWL will not play nice together. In fact, Fox, for optimal security, suggests using both:
● AWL will protect against zero-day attacks that AV would otherwise let slip through.
● Antivirus applications will flag malicious programs that were accidently added to the whitelist database.
Fifth concern: AWL can be breached while changes are being made to system endpoints.
Fox blames prior versions of AWL for this misperception. Earlier AWL systems would shut off protection when changes, such as adding new software, occurred: leaving the system open for attack.
Current systems are different. Fox explains, “Modern AWL solutions should no longer rely on such an open window and instead should follow and learn only those changes made by the approved process being learned, while still protecting and rejecting unauthorized changes made by any other process on the system.”
Sixth concern: Application whitelisting can introduce performance overhead.
Fox first explains how AWL works. He says, “With AWL, the entire contents of a file must be read, but only once to create a hashed signature of that file’s contents. That signature is then compared to the signature stored for that file in the whitelist database.”
According to Fox, this adds little if any overhead, and only when a signature is created. He adds, “For AWL solutions where the whitelist database is stored locally on the endpoint, the need for reaching across the network to consult the database at any point is eliminated.”
If interested or maybe curious, here are some application-whitelisting platforms: