Security

Is whitelisting a practical final line of malware defense?


A significant number of articles are showing up on the Web advocating whitelisting as the only way to effectively protect enterprise networks from malware attacks.  While it is a good idea in principle, is it really practical?

In an article last week, Larry Greenemeier wrote that today’s antivirus model is broken (“Antivirus 2.0: The Bouncer Approach”, InformationWeek, January 20, 2007).  Supporting his assertions with a report by email security vendors Proofpoint and Commtouch Software, Greenemeier writes that the ability of today’s malware to continuous change their signatures results in a continuous flow of zero-day attacks—attacks that no antivirus program can keep up with.  The article describes whitelisting as a possible answer.

Whitelisting consists of preventing workstations from running anything but software approved by the business.  Implementing this approach requires conducting an exhaustive inventory of all applications used today.  Once the inventory is complete, each application must be reviewed to ensure it is required to perform day-to-day tasks.  This is usually a contentious process.

The open nature of PCs in most organizations has resulted in users installing a wide variety of applications that they use to get through the day.  Any IT manager who has attempted to prohibit the use of these “productivity” applications knows that this is a dangerous road to travel.  Unless she obtains strong support from all layers of management for this approach, the final destination will be unreachable.

Another option is blacklisting.   Blacklisting, as its name implies, is the opposite of whitelisting.  Workstations are prevented from running applications that are specifically prohibited by management.  While this may be a palatable solution for the business users, this is a weak defense if not supported by additional controls.  New malicious or highly vulnerable applications are created or identified faster than they can be placed on a blacklist.

Both blacklisting and whitelisting usually require the purchase and implementation of additional software.  However, there is a simple way to at least begin controlling what is installed on our networks without major disruption to IS or to the business—the least privilege approach. 

The least privilege approach in a Windows environment is simple; disallow local administrator and power user access on all workstations.  In a January 19th article, Kelly Jackson Higgins takes a look at a healthcare company that did just that (“Company Cuts Privileges to Cut Malware”).  The result in this case was a “huge drop in malware infections”.  Granted, third party software was used in this instance, but it isn’t always necessary.  Aside from this example, exploits related to a large number of the vulnerabilities patched by Microsoft each month require the user to have local administrator access. 

When least privilege is invoked, existing software continues to function normally, resulting in little impact on business users.  New installs require approval. 

Whitelisting might be the final answer to protecting our networks from criminal elements.  However, it’s probably an impossible leap for many organizations.  Simply following security best practice by limiting access rights may be a good first step.

About

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

28 comments
StillWaters
StillWaters

At home, I use Firefox and have configured it to allow scripts and cookies ONLY where I have specified (what you call whitelist). This works on a small scale, as I have few 'legitimate' sites that require Java or cookies (and then only session cookies thus far). For a typical business, this might not work as the list would be rather large and hard to maintain (unless each user can configure). The concept is really useful, I believe, for single (home) users only.

BALTHOR
BALTHOR

The main defense against criminals is always Law Enforcement.

aaron
aaron

I read your article and have a recommendation for you "Graylisting". There are a few problems with least privelage user...1) You cannot put every user in your environment in this mode ie. mobile workers, or users that have applications that require full user rights 2) The support overhead of having to load applications like printer drivers is a headache 3) It doesn't completely eliminate the threat of malware. There is a solution that can eliminate all of this...Bit9. Bit9 combines the use of whitelisting, blacklisting, and graylisting. That means you can approve software that you want, ban software that you don't want, and prevent the first execution of any new unknown software. Because Bit9 prevents the first execution and installation, and not the copying of new software, we give you real time visibility of what has been downloaded. Then you can centally manage the approval process in real time. On top of the you can automate the approval process by automatically approving any software that you push, or from any software publisher that you wish. The result is protection for all the users in your network, elimination of all malware, reduction in overhead and support. And the implementation and baselining is easy. I am a sales person for them, but I have never seen a more amazing solution. If anyone has any questions you can reach me at aaron@bit9.com.

Jaqui
Jaqui

it has it's own issues, specifically, and most importantly, the false positive, where an app or person is blacklisted by mistake. Thereby costing the company money in slaes as well as in time to fix the issue.

aaron
aaron

Let me clarify what the graylist means to Bit9. It is any new and unknown application in your environment as recognized by it's hash. So, There aren't false positives with Bit9, and if you mistakenly blacklist something then it takes seconds to change. Also building the whitelist takes no longer than 30 minutes for your whole environment. You said, "The best way to protect the enterprise systems from illegal access / malware is to use a true multiuser operating system, which has multiple levels of permissions to allow or deny access. end users have zero permission to install any software. administrators [ The IT department ] has full permissions for the systems." You just described our solution, but our workflow for approvals is better than any other technology. We make it so IT can approve software in real time. So, picture a 1 minute approval process for software that IT hasn't pushed, and not including the software publishers that you have trusted, because all that software will be automatically approved. Leaving you with only graylisted software that IT hasn't approved.

aaron
aaron

missing the key point to our software. We have solved the first execution problem...meaning that anything new and unknown to your environment will not execute, not even once. (if that is your policy), including flash/javascript/activex/IE/googleearth/malware and anything else you can think of. Solving that problem allows for more flexibility, but much improved security. I can appreciate that you are a Linux shop, and we cannot help you, but I had to clear that up.

Jaqui
Jaqui

assuming that an end user will be allowed to pick software. sorry, tight security means end user cannot pick software to be used. the last thing I would want installed on my network is software picked by end users, they have no concern for security, or they wouldn't be using flash / javascript / activex / IE / html formatted email. sorry, but unless Bit9 runs native on linux it's not usefull in my network. the Black/Grey/White list is a non starter. it's not a security model for any real secure system. [ Note: MS based systems are never secure unless not powered up, *x systems are 90% secure by default configuration even when powered up. ]

Dumphrey
Dumphrey

on layers are what make up a good security policy. Least privelage for as many users as possible is a basic building block. Do it now, dont look back, smile smile smile. We havent had a virus/malware problem yet (knock on pressboard). But all this is easy for me, I have 2 networks, one with 35 users and one with 20 users. Gateway AV/Spam, end-point av/spam, gateway firewall, all of this is fine, but will have to work 3x harder if all users have local admin rights.

WSL91
WSL91

I added my post and hit "submit" and the page eventually timed out. Refreshed the article and checked the replies and still not there so I posted again with the same results. Now I see 2 posts. Sorry!

WSL91
WSL91

I think its time for the IT Industry to drop the "colors" on the lists. After all isn't IT about new and emerging technology? And by the way I'm caucasion, just think its time

michael.mulvihill
michael.mulvihill

That would be an extreme bit of political correctness if not. Especially since, I do not believe the origin of the word has anything to do with race.

WSL91
WSL91

I think its time for the IT industry to catch up to the civil rights movements of the 60's and drop the "colors" for the lists. And no I'm not of color, I'm caucasion and still think this is unacceptable.

skelta
skelta

Least privelege can be incompatable with some applications. Our practice management software requires all user to have administrator access.

WSL91
WSL91

Lock the pcs down, period. If you have a few users that need rights so be it. Work with the vendor etc . We work with approx 2000 desktops and laptops and have little fwe problems. Everytime we find a pc with problems we always find the user has been granted Admin rights.

Tom Olzak
Tom Olzak

I understand that in the past many, if not most, applications required admin access. However, in today's environment organizations should ensure they use applications that help minimize the network attack surface. Security assessments on potential purchases should identity and deal with elevated privilege issues before implementation. If you're using a legacy system, I recommend pushing the vendor to correct the issues that require elevated rights and permissions.

Schuylkill
Schuylkill

I agree that you should push your vendor to correct this issue. You can point to numerous references on Microsoft's developer web pages concerning least privilege as a best practice in software development. There are also tons of articles on the Internet that show the danger of running with full admin rights. I have raised the dreaded "liability" issue with my vendors, with good results. As a last resort, you could run that one application in a virtualization session (Virtual PC, VMWare, etc.). With careful planning, you could isolate that one application from the rest of the network in a VLAN or something similar. This would lower the attack profile of any compromised pc's.

Schuylkill
Schuylkill

I work for a mid-size (350+ employee) company with a rather complex network structure. We have used the least privilege model as one of our security practices for a couple of years now, and it works great. Administration is of course a bit more of a challenge - if I need to change an IP address on a machine, I can't just do is as the logged-in user. But the trade-off has been a near elimination of malware. Any admin who is not using least privilege should start doing so immediately. The security and support benefits are huge.

truthiness
truthiness

Lock those desktops down, and your malware/virus problems will go away. I've been 5 years on a 50 user network with zero virus or malware infections.

RosaNegra
RosaNegra

Our main business program (proprietary database software)requires the user to have administrative rights on on the local workstation -no way around it. I have registered my objection to the current setup, but must live with it for now.

jphoeke
jphoeke

At a previous company that I worked for, a piece of software that we were looking at not only required local admin rights, but also required the user account to be a local one. We laughed them out the door and told them not to come back until that had rewritten their program to run/install as a domain account with only power user rights on the local machine. They told us it would never happen. 3 weeks later, they were back with their application rewritten to match our requirements.

Schuylkill
Schuylkill

bmagurn has excellent suggestions for dealing with apps that require admin rights. I would add that you need to keep pressuring the vendor. You can mention that their app does not meet "industry best practices" and that their recommended configuration puts the client computer in a "insecure security profile" which is a "legal liability". See what kind of results you get with those buzzwords.

bmagurn
bmagurn

Have you looked at granting access to the directory that the program is installed in? Registry permissions? What about loading the app up on a terminal server and connecting to it that way? Or use something like virtual PC, and allowing the app to run with admin rights in a virtual PC, rather than admin rights on the real pc. I'm not saying that it's always possible to get things to run, but it is well worth the extra effort. You might look into some TCO estimates to make a business case to the superiors, at least to get the app redesigned to run under the common principle of least privilege.

Tom Olzak
Tom Olzak

How practical is it for an organization to begin an application whitelisting process to protect the enterprise? What's the impact on the business? What's the impact on IS?

percolator5591
percolator5591

Tough to maintain at enterprise level, prone to hacking itself.

bmagurn
bmagurn

I have seen a number of LAN admins break common programs by attempting to whitelist .exe 's. Your average LAN admin doesn't know enough about the intracacies of software to find all the .exe's to whitelist them. There will always be some subcomponent of office that is not in the whitelist that causes some rarely used feature to break. From a time and effort standpoint, your will trade the time spent cleaning up spyware, to more time spent troubleshooting apps that should work. And you get very limited (read: no) support from vendors when you tell them that you've setup a whitelist for allowed applications. Even microsoft doesn't have documentation of all the exe's that need to be whitelisted for Office to work properly. You're better off taking advantage of: A) least privilege - stick to it and fail software that doesn't work with it. (Or ask the CEO if they can give you a 50%-100% increase in staff to support virus and malware issues) B) take advantage of experts - use anti virus / anti-malware software and their blacklists. They have the staff to manage software compatibility issues with thousands of vendors. You don't (presumably) have that kind of staff / time. It depends of course upon your business. You can manage more machines with the same / less people with these restrictions in place. If you're running DOD, or a bank, or something highly secure and you can say "no way, period" maybe you can whitelist. If you have a small number of users / machines to support and you're a small or flexible business that neds to be highly nimble, you might need more IT staff and less restrictions. Microsoft has an ITIL calculator that can help you judge the staff to machines ratio that these and other IT best practices can gain: http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx (I'm sure there are many other such calculators as well.) Implementing restrictions like that of least privilege can not only prevent spyware, but reduce support of applications that mysteriously get corrupted / misconfigured. You can utimately provide better support and services to your users if you can get to that point. You can get to things on your to-do lists when you stop spending your time putting out fires.

oz_ollie
oz_ollie

Whitelists are implemented easily - just not on Microsoft Windows. This feature is built into Mac OS X and is easily implemented on standalone systems (via Parental Control) or workstations from Mac OS X Server. You can also do this on Linux systems. Adobe CS is one of the many poorly written applications that need administrator privileges to run on Windows. This "favour" is returned by Microsoft breaking the Adobe help system when pop-up blocking is enabled in Internet Explorer. Microsoft has lead this charge of commercial software vendors of beta testers paying for the privilege of troubleshooting initial releases of software. It just brings the whole industry into disrepute when buggy software gives false impressions that computers crash all the time. At least open source developers acknowledge the alpha and beta software phases - although developers pride often means that beta software is the equivalent of commercial software after two or three updates.

Jaqui
Jaqui

whitelisting is always allowing something, so it is a way to bypass protections and restrictions, not to enable them. blacklisting is denyng it. very good for protection, but not good for productivity. greylisting is a conditional blacklist, and has a high risk of false positives, blacklisting someone by mistake. The best way to protect the enterprise systems from illegal access / malware is to use a true multiuser operating system, which has multiple levels of permissions to allow or deny access. end users have zero permission to install any software. administrators [ The IT department ] has full permissions for the systems. end users can use all software installed. The MS multiuser model is not a true multiuser system, it has not the full permissions sets required to be one. The Unix and Unix-like operating systems are true multiuser systems, designed for multiple users and security from the ground up. [ not to mention the additional 20 years of code development of them, making critical / zero day exploits far less common or likely*. ] * yes, critical exploits do happen, just nowhere near as often as with MS products. Zero Day exploits don't happen with the Unix and Unix-like operating systems.