One of the most common gripes I hear from people using the Windows Vista operating system is how annoying the User Account Control (UAC) security feature is. UAC, a security mechanism that Microsoft introduced to ensure that only trusted applications gain increased system privileges, is meant to prevent malware from compromising the operating system. Although a user account may have administrator privileges assigned to it, the applications the user runs do not automatically have those same privileges.
Complaints about UAC are mainly about the number of annoying notifications and consent dialog boxes the user is confronted with, particularly during the installation of software. Security is always a trade-off with performance and usability, and the workflow interruptions it causes are inevitable. Unfortunately, it's also inevitable that many users won't understand or appreciate the implications of clicking "Yes" or "No" in response to UAC's pop-up warnings.
Application whitelists: Better application control?
But better desktop security initiatives have to start somewhere, and the only way to win against malware is to prevent it from running on a system. An application whitelist -- what UAC is in many ways -- states which applications can run on a client machine. Whitelists are a powerful method for controlling what can and can't run on a system.
Yet managing enterprise-wide whitelists can pose a problem even in a managed environment where system administrators control what programs can and can't be installed and run by its users. Compiling the initial whitelist requires detailed reviews of users' tasks and the applications they need to complete them. The growing complexity of business processes and applications makes maintaining the list a lot of work. Plus there is the issue of enforcing segregation of duties -- ensuring employees are not assigned inappropriate combinations of application access rights. It can also be difficult to resist demands from a CEO with the latest smartphone who wants to run some new autosync program to support it.
Asking the user to manage his or her whitelist is an imperfect solution. Frustration, lack of knowledge and sophisticated malware attacks using social engineering will lead many to still allow the installation of inappropriate software. To make application whitelists a success in your organization, you need not only senior management buy-in, but also a way of letting users quickly and easily request permission to run a new application. This could mean delegating approval rights to the department level, possibly with the right to grant a one-time run without full whitelisting.
One option could be to let a trusted source maintain an approved application whitelist. This already happens to an extent with AV software. For example, antimalware vendor Symantec Corp. uses a "Trusted Application List" of non-harmful applications. This type of list is also used by registry cleaners and spyware removers to determine if a given application is safe to keep, or needs to be removed. A more draconian step would be to allow systems to only install software that is digitally signed and downloaded from a trusted repository.
The real value of whitelisting
Whitelists, however, cannot fix an allowed program that has a vulnerability. Even in a whitelist environment, a typical buffer-overflow attack, for example, can still run malicious executables, because the system thinks it's the whitelisted, but vulnerable program running the code. Another shortcoming of many whitelist products is they lack any granularity of control. A simple "Yes" or "No" decision either allows the program to run or not, whereas it may be appropriate for some users to use a certain program, but only access certain features.
The real value of whitelisting is to control the applications running on a system, but as you can see, whitelists need to be bolstered by other technologies. Cisco Systems Inc.'s desktop host intrusion prevention, Security Agent, for example, provides application whitelisting and can also control what specific system resources they access, such as files and networks.
Various vendors are working on software restriction policies in the OS. Microsoft, for one, is pushing Address Space Layout Randomization (ASLR), which randomly positions key data areas, and Data Execution Prevention (DEP), which prevents the execution of code from a non-executable memory region. Both mechanisms can limit the damage that application vulnerabilities may cause. Microsoft certainly feels that application whitelists are an important part of a security strategy. Its virus and spyware protection technology for businesses, Forefront Client Security, is rumored to have whitelisting features added soon.
As always with security, layering protection is good practice, and it's good to see application whitelist technologies being used more widely as a layer of defense. Despite the management burdens, more enterprises should consider whether application whitelists should play a role in their security strategies.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
This was first published in November 2008