Security

Answering the crucial questions about application whitelisting

Application whitelisting is our chance to be proactive. That alone has to mean something. Let's look at how three companies leverage that into real-world protection.

Application whitelisting is our chance to be proactive. That alone has to mean something. Let's look at how three companies leverage that into real-world protection.

-------------------------------------------------------------------------------------

Application whitelisting seems simple enough. Only allow approved applications to run. Not exactly, my last article about application whitelisting generated all sorts of "how do they do that" questions. Good questions that deserve answers.

So I got busy, asking experts at several security companies to explain their application-whitelisting product and answer your questions. Three of the four companies I asked; CoreTrace, Faronics, and Savant Protection were kind enough to respond. Here is what they had to say:

TechRepublic: Could you introduce your company and its application-whitelisting product? CoreTrace: CoreTrace is focused on creating high-security, easy-change application whitelisting solutions. The company was founded by Dan Teal. The directors and officers of CoreTrace have significant experience building enterprise software and security companies such as Check Point Systems and PGP.

Our whitelisting solution, Bouncer, automatically creates a whitelist from each computer, and updates that whitelist whenever new and trusted applications are added.

Faronics: Faronics is interested in computer power management and cost-reducing IT solutions. We have offices in the USA, Canada, and the UK. Our customer base exceeds 30,ooo customers in over 150 countries.

Our product is called Anti-Executable. What makes Anti-Executable unique is the inclusion of both blacklisting (any non-trusted program will be blocked from running) and whitelisting in a single application.

Savant Protection: Savant Protection is a private company focused on automated application-whitelisting. The product, with the same name as the company, is a business-driven application-whitelisting solution that protects the operating system and software running on desktops, servers, process control systems, and point-of-sale systems. TechRepublic: There are many definitions of application whitelisting. So we can be clear, what is your interpretation? CoreTrace: Application whitelisting is the ability to guarantee that only safe, approved applications--both originally approved and those added over time--are allowed to execute. Application whitelisting solutions should also prevent memory attacks within legitimate whitelisted applications. Faronics: Whitelisting is a practical and realistic approach to how files are controlled on a computer: Instead of worrying about the universe of existing files and the files that might be created, whitelisting focuses on the files already present and verified. Savant Protection: The primary objective of application whitelisting is to protect the functioning of the computer and its executing programs. This includes all executables of the operating system and the applications. If it is not on the list, it won't run. TechRepublic: How is the whitelist created and if needed, updated? What attributes are used to identify the application? CoreTrace: Once installed; Bouncer identifies all executable binaries, adding select information about each binary to the whitelist. Once the whitelist is completed, the system will be in a protected state. You can loosen up specificity if you wish. For example, you could configure Bouncer to allow Notepad to run from any location.

For the addition of new applications and upgrades, trust models (trusted applications, paths, digital signatures, users, and even ActiveX installations) are established using Bouncer's Trusted Change feature. Once set up, automated delivery mechanisms or specified users can add or update applications without requiring further IT approval.

Each binary is uniquely identified by file name, file size, file path, and SHA1 hash.

Faronics: A whitelist can be created by scanning folders or drives. When using this "scanning" function all the executable files in the folder or drive will be added to the whitelist. Anti-Executable also allows selecting a specific file and adding it to the whitelist. A third option is to add a whole folder to the whitelist. This folder is called a whitefolder. All the executable files in the whitefolder will be allowed to run.

There are several ways to maintain the whitelist. The first way is called Maintenance Mode. While in Maintenance Mode, Anti-Executable allows software to be installed or updated. When Maintenance Mode ends, Anti-Executable will add the new or updated files to the whitelist.

Another method is using Publisher entries. When a Publisher is added to the whitelist, new software can be installed and existing applications can be updated provided they are digitally signed by that Publisher.

To identify an application, we use the SHA-1 hash and publisher.

Savant Protection: The whitelist is created on each device when the agent is deployed to that device. The agent scans the specified disks and adds all executables to the whitelist. As described earlier, it maintains the list automatically. The hash is unique to both the file and the computer. For example, the hash for wordpad.exe would be different on different computers. This prevents malware from proliferating.

Savant Protection has a library of "filter sets" that allow you to configure which processes can upgrade, install, or patch software. New filter sets can be easily created if they are not in the library. For example, Savant Protection's library has filter sets for software delivery systems, which allow administrators to continue using the same tools they normally would to install and update software.

The SHA-1 hash, file size, and file name identify the executable.

TechRepublic: How does your product prevent non-listed applications from executing? CoreTrace: Bouncer is a kernel level service. This allows us to perform a check immediately prior to execution load and determine whether the binary is on the whitelist or not. If the binary is not on the whitelist (and not originating from a pre-authorized trusted source), Bouncer prevents the execution of the binary.  This is an important aspect of Bouncer. It checks the validity of the binary before it loads; not as it loads or immediately after. By then, the damage could have already been done. Faronics: When there is an attempt to execute a file, Anti-Executable checks if the file is digitally signed. If it is, Anti-Executable crosschecks the file's publisher against the whitelist. If the publisher is in the whitelist, the file is allowed to run.

If the file is not digitally signed, Anti-Executable calculates the file's hash (SHA-1) and crosschecks the whitelist. If the file's hash is found, the file is allowed to execute. Otherwise the file will be prevented from running.

Savant Protection: Savant Protection is implemented with a Kernel-level filter driver. It starts at boot time and it intercepts the start of an application and the loading of dll's from within the kernel. In this way we prevent any executable not on the whitelist from running. TechRepublicNot every user requires the same software applications. For example, engineers may need a CAD program where other users wouldn't. How does your product handle that? CoreTrace: Bouncer creates and enforces a different whitelist for each computer. If one engineer's workstation has a CAD program on it, there is no reason to have that same application pre-approved for the receptionist's computer.

Bouncer also has role-based management capabilities, allowing administrators to group computers together. For example, you could pre-approve the same CAD program for all engineering workstations, without doing so for the entire enterprise.

Faronics: You can have a single whitelist to control your whole company, or have a different whitelist for every department, or have a whitelist for every individual computer. With Anti-Executable, you can have different whitelists apply depending on the time of the day. Savant Protection: The white list would be modified on only those machines without the administrator needing to do separate approvals. And the CAD software would only run on those endpoints. Since we have a full agent on each device, an administrator could install software from a CD and the white list would automatically be updated with all the executables. TechRepublic: There is some concern about what happens when an approved application is targeted by malware. Is that type of attack a problem? CoreTrace: This is a key question in our minds. Application ‘Foo' could be a valid application and needs to be on the whitelist. Unfortunately, Foo happens to have a known vulnerability. Without some form of memory protection in place, we believe you are still susceptible to malicious attacks.

CoreTrace is focused on reducing those attack surfaces. That's why Bouncer protects against several types of memory attacks, including dll injections and attempts to write to kernel memory.

Faronics: Imagine a file's hash as the file's DNA. Any change on a file will imply a complete change in the file's hash. If the hash is not in the whitelist, the file will not run. It is the same with Publisher entries; any change to the file will break the file's digital signature, preventing the file from being executed. Any malware attack to an approved application will be detected by Anti-Executable and the application will be prevented from running. Savant Protection: Many exploits will deposit an executable on the system in order to complete the attack. Since that executable won't be on the whitelist there will be no persistent threat. However, an in-memory exploit would not be stopped if it's part of an approved application. Since a successful compromise generally requires stages of exploitation, when an in-memory exploit attempts to deposit an executable, we will stop it.

In addition to preventing non-listed executables from running, Savant Protection has a secure mode that only allows trusted processes to create, modify, or delete executables.

One thing is clear

It became evident while researching this article that application whitelisting has one caveat. You have to make sure the computer is clean before installing any of the above programs. If malware is already entrenched, these applications will gladly whitelist it and allow it to run.

Final thoughts

Application whitelisting may not be the end-all answer, but it does allow us to be proactive in the fight against malware. That's its advantage over threat-centric anti-malware.

I am concerned about the complexity, application whitelisting definitely requires babysitting. A homeowner with only a few unmanaged computers will not want to go through all the effort to maintain the whitelist. That's where some work needs to be done.

I would like to thank Kelly Batke of Faronics, Paul Paget of Savant Protection, and Kristina Molfino of Kulesa Faul (represents CoreTrace) for helping me research application whitelisting.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

63 comments
LYCCH
LYCCH

Greetings, I wonder if you have ever taken a look at BluePoint Security? Their cloud-based application whitelisting technology is unique and very easy for even home users to install and live with. BluePoint makes this level of security available to home users and small businesses at a very reasonable cost. They also have a much more sophisticated Enterprise product. I have deployed this product for hundreds of customers now and they all are thrilled. Check it out at www.bluepointsecurity.com Thanks.

Mehseyrafi
Mehseyrafi

Hi I have an exe file that must be executed only by another software and it must not be executed as standalone by a user. I think the existing softwares only block the exe file and so it can not be run under any software too. Thanks

deepj
deepj

What about non file based executables such as the deluge coming at us from the internet? Isnt there potentially alot of code getting executed that is never file based? ActiveX, Java, html, scripts, etc etc that gets executed on the fly by other programs. How does whitelisting work on these?

tmurphy
tmurphy

Most vendors who deliver a form of Application whitelisting focus on how to deal with new, unknown applications ... and the typical answer is block the execution if it is not something you trust. What about the 15,000 executables that are on the computer when you install the application whitelisting software? How do you assess the trustworthiness of that software? By default, those apps are allowed to run because the vendor has no way to assess the trustiworthiness of those existing apps. Bit9 leverages a configuration baselining capability and a cloud-based software reputation service to ensure the target computers are clean. As Michael has noted, addressing the new software is only half of the equation. If a vendor can't address the software that resides on the computers then the approach is making a big assumption and is seriously flawed.

Ocie3
Ocie3

For what it's worth, I have been using Anti-Executable Standard Edition 3.50 for only three days (on a 30-day free trial evaluation basis), and I don't intend to offer a review of it on Michael's turf. :-) However, in answer to the question [i]"How is the whitelist created and if needed, updated? What attributes are used to identify the application?[/i] Faronics replied, in part: [i]".... Another method is using Publisher entries. When a Publisher is added to the whitelist, new software can be installed and existing applications can be updated provided they are digitally signed by that Publisher." (italicization added)[/i] That feature is not in the Standard Edition, for workstations, that I am using. I suppose that it is in the Enterprise Edition (for workstations and servers respectively). Why it is not available in the Standard Editions, I don't know. Be that as it may, there is neither mention of using the Publisher in the context of updating software, nor any mention of updating software at all, on the Faronics web site list and comparison of Anti-Executable features: http://www.faronics.com/en/Products/AntiExecutable/AntiExecutableKeyFeatures.aspx If you are curious as to how their software works in practice, it could be worthwhile to download and install the software for a free 30-day trial. The AE Standard Manual (not "User's Guide" as I originally wrote), though, is a bit reticent with regard to various aspects of implementing the fundamental concept (which it does explain).

ChewyBass1
ChewyBass1

This looks promising but I would like to hear more about real world experience from IT departments that have utilized these products. I don't want to be the captain of the Titanic as income is a vital commodity in this economy. My other concern is I don't see a path for home users. I would love to have this at home since my biggest threats are teenagers on downloadroids. Also what is the cost? No mention on the sites. I would like to have a clue rather than making a call and supplying DNA, email address, phone number and then being barraged with spam for the next decade.

santeewelding
santeewelding

Like others you present, will take time, attention, thought, and mulling for me to absorb. I [i]can[/i] say at this stage that each of the three solutions looks good. I am also close to saying that I would be willing to pull the router plug, wipe, and reload my W7 Pro DVD from scratch, provided that I had a physical CD whitelist program in hand as the first application to load before anything, including my CD of MS Security Essentials (which may not be necessary). Mulling, and looking forward to reading more.

kristymadimike
kristymadimike

Application whitelisting seems to be a much better direction to move with security. I appreciate you brining this topic to light. It just seems silly to me that Microsoft hasn't built this feature into every version of the OS with an easy GUI configuration (though this lapse seems to be all too common with them). Do you know if linux has this option by default?

santeewelding
santeewelding

How, tell me, does this differ from advertising copy, which you post without cost?

Ocie3
Ocie3

will allow a program that [i]is not[/i] on the whitelist to run only [b]if[/b] a program that [i]is[/i] on the whitelist is also marked on the whitelist as a "trusted" program (when it launches the unlisted program). If a program is not on the whitelist, then it cannot be executed by any user, only by a trusted program. I happen to be using Faronics AE for a 30-day trial, and what I've told you is in the Manual. However, I have not specifically made any program "trusted" because of the restrictions that you describe. The "trusted" ones that I have enabled, so far, will run only one or more specific programs (not just any program). Usually, a detail like this one can only be learned either by reading the documentation for the whitelising program (such as the User Guide or User Manual), or by contacting the developer to describe the situation.

deepj
deepj

I believe that there is code of various types that get executed without necessarily residing in a file on your system. At least some of the whitelisting programs are file based. For instance we tried a java based web conf program from over the internet - it came right in and ran just fine without being blocked on a clean machine. Maybe in part due to the fact that java caught the code and executed it. This could happen with other types of code like html,scripts,etc. But, I am for sure no expert. I would like the vendors to give an in depth explanation of how this works etc. I have tried some and they seem to be good at deflecting the topic or the answer is our protection if just "file based." Is that really good enough?

Ocie3
Ocie3

http://blogs.techrepublic.com.com/security/?p=3666&tag=content;leftCol has a link to a chart which compares the features of the five whitelisting utilities which were reviewed by Infoworld: http://www.infoworld.com/node/98873?source=fssr All five include VBScript and JavaScript by default among the "executables" which they whitelist, as well as ActiveX (.OCX) controls. I am not sure as to which filename extension(s) identifies a Java executable. A filename extension that I don't see on the chart is .JAR, which is used for Firefox extensions, for example. As to how whitelisting is implemented specifically for these executables, the reviews do not offer details. We would have to consult the developers, or the documentation of their respective whitelisting systems.

rkamsler
rkamsler

If your systems have been running unprotected (no security software at all) then the answer is simple. Reimage the machine it is infected. Otherwise if you are running a reputable AV solution then the 15000 executables have been ?scanned? and are historically considered OK. Remember that application white listing is protecting you going forward and protecting against those targeted and zero day attacks. There are no perfect reputation based white lists and they suffer from the same historical perspective as the AV protected system. They only look backwards.

Michael Kassner
Michael Kassner

If the application is set up to scan the computer initially, it will allow them. There are all sorts of options for allowing new apps to be included. The real issue is determining if the application is what it says it is or a fake.

Michael Kassner
Michael Kassner

I have been learning that most AV app developers are working to incorporate whitelisting into their offerings. Some already do. Also, many firewall apps already do this, but require user input and that tends to complicate matters.

Michael Kassner
Michael Kassner

Please send me a list of your concerns. The vendors are chumping at the bit to help.

Ocie3
Ocie3

but Faronics Anti-Executable Standard Edition for Windows and 1-year Maintentance Package is $45: https://store2.esellerate.net/store/checkout/CustomLayout.aspx?s=STR1066199390&pc=&page=OnePageCatalog.htm It isn't clear to me whether they want $45 (per computer?); or $45 per year (per computer?). If you download the software for a 30-day free trial, then I suppose that, while installing it, you should copy the license agreement to the Windows Clipboard and paste it into a text file for future reference, because I don't find a copy of it anywhere on the web stie. You are right, though, that almost all of the whitelisting developers, that I've been reading about and finding recently, are enterprise-oriented. Given their pricing (per machine, [i]e.g.[/i],starting at 500), it is clear that they do not want to sell to and to support "home users" AKA "consumers". It is the support costs that only too readily render the enterprise unprofitable. For that matter, it seems to me that for every company that does sell [i]security software[/i] and or [i]security hardware[/i] to "home users", there are at least nine that do not. I've found that to be the case with respect to firewall software as well as for whitelisting software. Firms that sell a firewall for home-computer use typically "bundle" it with an AV and/or other security software which is sold as a "suite", or even incorporate the firewall into their AV software outright.

santeewelding
santeewelding

The part about income. The part about teenagers -- that is also promising.

NexS
NexS

Is a moment such as this, where an unexperienced Santeeton(A word I invented for those practiced in the art of the Santee-Code deciphering) can read a post by ours truly, and understand every sentence. If my camera wasn't broken.... (not to discourage you of course!)

Ocie3
Ocie3

has a whitelisting utility called AppLocker, which was reviewed by Infoworld: http://www.infoworld.com/d/security-central/application-whitelisting-in-windows-7-and-windows-server-2008-r2-845?page=0,0&source=fssr as cited by Michael in his first article in the set/series on this subject last week. As Microsoft has done before, AppLocker starts out simple and arguably under-featured (according to the review). However, the program(s) will probably evolve in terms of features and complexity in future releases -- assuming that MS will choose to continue developing it.

Michael Kassner
Michael Kassner

But, I am not by any means an expert when it comes to Linux. That is an interesting thought of having the OS control that aspect.

Ocie3
Ocie3

as if he is quoting the text on the BluePoint Security website. Long on hype and buzzwords, short on features and technical details. Apparently they offer a "Cloud AntiVirus with Application Whitelisting" system, but that is all that they reveal beyond a simple description of whitelisting. They also are not consistent about the price, and it is unclear as to why the difference in numbers. On the home page the "Personal" edition was advertised at $34.99 for "1 PC/ 12 mo. subscription" when I looked at it. But on the Personal page, a 1 PC - 1 Mo. subscription is $5.99 per month. They do offer a 30-day free trial, though. The "support" options look good, but it isn't clear whether "support" means "tech support" for all of the options. It might be limited to using the "forum". Given my experience with Panda Cloud AV, I am once bit and twice shy. Funny thing about that, BluePoint Security also offers the system with the Spanish language instead of English, if you prefer.

deepj
deepj

How do we know that we are protected from every flying piece of code coming at us? I think it would be nice for the vendors to really really spell that out ie 1 what are all the catagories of non file based code (in addition to the file based code) and 2 are we protected and how are we protected by their whitelisting program?

Ocie3
Ocie3

for which a program can compute a [i]cryptographic hash[/i] as a unique identifier for that object. That is essential to every whitelisting system. It computes a hash(es) so that it can identify the object, then either allow it to be executed when it is on the whitelist, or block its execution when the object is not on the whitelist. In most instances, the object [i]is a file[/i] which contains binary instructions for the computer to execute, [i]i.e.[/i], in the format for a computer program which the OS will run. The OS loads an image of that executable file into memory and starts it running. Another type of object is a "script", such as one that is in a TCP/IP packet (which can itself be considered as a file). A script is a series of instructions which are carried-out by a script interpreter. The interpreter can be a standalone computer program that is usually launched from a command-line, or it might be launched by another program, such as a browser. Or a browser might internally incorporate a script interpreter (which may be loaded as a .DLL file in that case). The instructions in a script can perform all manner of tasks and certainly be quite useful, which also means that they can be used for malicious purposes as well as for beneficial ones. A JavaScript or VBScript script can be recognized and defined, from beginning to end, as a specific object for which it is possible to compute a cryptographic hash. So, it can also be whitelisted before it ever arrives in a packet, and when it does arrive in one, a cryptographic hash can be made and used just as if the script was [i]in a file[/i]. Note that before a script was ever sent in a packet it was probably stored in a file, just not one on every recipient's computer system. ;-) A TCP/IP packet usually also contains data such as text and images which have HTML "tags" that instruct the web browser how to [i]render[/i] the web page. That does not comprise an executable object, though. But such will probably not be true for pages which are composed with HTML 5. TCP/IP packets can also contain one or more Java executables. Java is a programming language, and its instructions must be effected by the Java Runtime Engine (JRE), AKA the Java Runtime Environment. The JRE itself is a computer program that can be whitelisted to ensure that its own authentic executable(s) are loaded and executed. Each Java executable in a TCP/IP packet is an object for which a cryptographic hash can be computed, thus it can be whitelisted just like any other computer program's executable file(s). An ActiveX control is usually stored on a user's computer as a file (.OCX), so it is an object for which a cryptographic hash can be computed in order to whitelist it. However, an ActiveX control can also be downloaded from a web site by a program that chooses to use it (such as I.E.), but in that context, a cryptographic hash can be computed for it to determine whether it is on the whitelist (and whether to add it to the whitelist). When a program such as Internet Explorer [i]activates[/i] an ActiveX control, a hash is computed for it to determine whether it is on the whitelist, thus whether to block the control or to allow it to be used. .JAR files are "archives" which contain Java binaries (see http://en.wikipedia.org/wiki/JAR_%28file_format%29) and are similar to Windows .DLL files. A Dynamic Linked Library (.DLL) file usually contains binary instructions which are executable by the computer, but they are not loaded and executed by the OS as independent processes (see: http://vlaurie.com/computers2/Articles/dll.htm). A .DLL must be [i]linked[/i] to an executable process which is already loaded and running in memory, for its instructions to be executed. However, the MS Windows rundll32.exe program can be used to run some .DLL files as if they were an ordinary computer program. Both .JAR and .DLL files are objects that can contain [i]malcode[/i], so they should be included in any whitelisting system, to eliminate the possibility that a program which uses them will cause malcode to be executed. There has been at least one malware program that is composed of one or more .DLLs which are executed by using rundll32.exe.

Michael Kassner
Michael Kassner

What application-whitelisting program are you using?

Ocie3
Ocie3

First, to quote the AE Standard Manual: [i]" .... The executable files managed by Anti-Executable have the extension .scr, .jar, .bat, .com, or .exe."[/i] That list omits .DLL files. However, some malware has been known to replace one or more existing .DLL files with files that have the same name and size but different, malicious, content. When such a .DLL file is loaded and linked to an executing program, that can lead to execution of the malcode. However, .JAR files are whitelisted by AE, although they are essentially the Java equivalent of a MS Windows .DLL file. Faronics tech support has stated that [i]"*Antiexecutable should detect and block any executable, regardless of where it comes from."[/i] That declaration apparently includes any "executable" (as defined in the Manual) which is attached to an e-mail message, whether also to one that arrives in, or perhaps as, a TCP/IP packet -- other than a .DLL file or an ActiveX control (.OCX). Are all worms .EXE or .COM files? IIRC, I instructed AE to compose an Active Whitelist during its installation. Afterward, I reviewed it but did not edit it much. Instead, I soon realized that it would probably be better to compose another whitelist from scratch, then instruct AE to use it as the Active Whitelist. The crucial feature of the AE Whitelist Editor is its "Scan" function. "Scan" searches drives or directories and their subdirectories, which are selected from a file tree that AE displays, for executable files and adds them to the whitelist that is being composed. However, I subsequently discovered that many "executables" which were in the directories -- or in their subdirectories, such as C:\Windows\system32 -- that I selected for scans were [b]omitted[/b] from the whitelist. About this Faronics tech support has commented: [i]"*In general, files that may be omitted during the initial scan could be in use, protected, or the user has insufficient priviledges for access. In some cases, files are missed during the initial scan. If the program protection is enabled, then you should be able to add the programs to the whitelist."[/i]* However, as far as I know, none of those three conditions applied to very many, if any at all, of the omitted "executables" that I discovered. Again, the whitelist which I was composing, and from which the files were omitted by the editor's Scan process, was not created by the "initial scan" that was done during AE installation. Which is to say, I have found apparent flaws in some AE features and functions, and the response from Faronics tech support can be summarized as "There is nothing wrong with our software. (Period)." Use it at your own risk! Warts and all. __________ * Note: none of the remarks by AE tech support were [i]italicized[/i] in their written comments. I have italicized their statements only to distinguish the text from my own remarks in this post. My intention has been solely to describe some of my experiences while using AE, and to fairly relate the gist of what I received in reply to the message that I sent in regard to that experience. My remarks are entirely my own and have not been solicited by TechRepublic or any of its editors, blog hosts, writers, agents, or other personnel.

Ocie3
Ocie3

I am still learning the features and operation of Faronics Anti-Executable Standard Edition (AE). Before I installed it, I read the software Manual and I contacted their tech support [i]via[/i] telephone for answers to a few questions that I had. Currently, I'm awaiting their reply to the first e-mail that I've sent about various matters. Suffice it to say that no useful software that I've ever used has been perfect and without one or more evident bugs. The AE whitelisting implementation is straightforward, and it clearly implements the basic aspects. The "administrator interface" is relatively simple and easy to use, too. The features for creating whitelists are versatile, [i]i.e.[/i], they make it easy to create customized lists for just about any circumstances. AE has a similar "blacklist" feature, too, with which the admin can specify executables that are prohibited from running. It is probably most significant in the context of managing a large number of workstations and servers which are also protected with AE whitelists (using the respective Enterprise Editions for servers and for workstations). Anti-Executable (AE) creates its own log of "events" that the whitelist admin can read and examine [i]via[/i] the Microsoft Management Console (MMC) Event Viewer -- version 3 for Windows XP. Access to the log is directly from AE, which launches MMC. Using MMC offers interesting logs pertaining to the operation of Windows XP itself, as well as the one that AE creates for its own operation. One new thing that I have learned is that Windows XP will open a command prompt window if I use Start > Run and enter command.com as the file to launch, and there are other "MS-DOS applications" in C:\Windows\system32 as well. No doubt that they have been adapted to be compatible with Windows XP, but I have to wonder why MS bothered (format.com looks dangerous). My present impression is that AE 3.50 is a basic whitelisting utility with some very useful features. So, it offers the security that a basic whitelisting system can offer, which is significant. Nonetheless, there are some circumstances under which malware [i]could[/i] be introduced in a way that would add it to the whitelist, and/or in which it currently appears that AE would not stop malware from being executed. Which is to say that AE also appears to be a good foundation for further development, especially with regard to keeping the whitelist updated, and for software authentication and auditing features that I have discussed in other posts here. However, I do not know whether Faronics is currently developing AE further. or plans to do so in the future.

Ocie3
Ocie3

The Sunbelt Personal Firewall (created by and bought from Kerio) had an Application Behavior Blocking feature which essentially functioned as a whitelist for any executable file that Windows XP would launch or which could be launched as an independent process by another program. It was quite valuable in bringing to my attention alterations of the installed software, which I eventually concluded were made by an undetectable rootkit. The SPF logging features were a work of genius that I've never found in another product. However, last year, Sunbelt decided to incorporate the firewall into the interface for, and operation of, their anti-malware program. Now they sell the combination as VIPRE Premium 4.0. Ironically, they chose to omit the Application Behavior Blocking feature when they merged the firewall into the AV. They also removed the features for controlling the content of the logs. :-( Then again, Sunbelt has consistently tended to market their "home user" products to the folks who don't know much of anything about computers and don't have the time to make the effort to learn even if they wanted to. So what's a "whitelist" (or a "sandbox") to them?

santeewelding
santeewelding

Has already fixed your azimuth. Keep it up. Windage, next, Nexus.

boxfiddler
boxfiddler

Easy, breezy print screen. Free, too.

Michael Kassner
Michael Kassner

I was excited about this as users would not have to do anything. Yet it seems to have a bunch of issues. Let me know if I am mistaken.

CG IT
CG IT

but not with a single software application. inherently domain users are denied the ability to install software. In a domain environment, IT can advertise applications or publish them to users through group policy. This controls what users have. To monitor what users have, MS came up with Systems Management server which passively queries clients for software and reports results. But there wasn't a MS program that would stop unauthorized applications from running at the .exe level. MS simply created a way to find out what is running. Often Microsoft left that up to security firms such as Symantec, McAfeee and the AV software which was to detect, isolate "bad" stuff. I see benefits but also drawbacks with whitelisting. As you mention, malware that's already on a machine, undetected would end up on the whitelist. Not good. What really is needed is a 3rd party [neither a security firm or a software developer] that reviews applications looking for hidden code that would compromise a system, then whitelists it. For consumers, it's simply telling them the application is ok or not and give them a choice. Businesses typically buy from reputable firms. It's the users who install risky stuff. Controlled environments in the workplace have been in place for a long time. Just visit an Insurance company. Their user environment is completely controlled.

Ocie3
Ocie3

As you may recall, I've been running Faronics Anti-Executable (A.E.) on a 30-day trial -- 9 days remain. Aside from what are probably some of its own characteristics (read: maybe a few bugs), it seems that running any whitelisting system without prior experience with another one is likely to be significantly different for many users, especially with regard to installing and uninstalling software as often as I do. Of course, each of the variety of programs that I use is updated with a method that is the same as used by some others, but also wholly unlike that of most of the other programs. The methods used by Firefox and Thunderbird are not the approach used for Wireshark. A.E. has a "Maintenance Mode" (MM), which I must remember to use, especially when I update Windows XP on Patch Tuesday. While in MM, apparently A.E. allows all programs to run, regardless of whether they are on the whitelist -- although following is the entire documentation for MM that is in the AE Standard User Guide: [i]"Select Maintenance Mode and click Apply to run Anti-Executable in Maintenance Mode. When in Maintenance Mode, new executable files added or modified are automatically added to the Active White List. To exit Maintenance Mode, select Enable or Disable. If Enable is selected, the changes are recorded by Anti-Executable. If Disable is selected, the changes are not recorded by Anti-Executable."[/i] Faronics has confirmed that A.E. allows (all -?-) programs to run unchallenged while it is in MM, but the only way to obtain any details is to ask simple, specific questions which they may evade or ignore. From observation, I suspect that A.E. simply allows everything that is launched to run, then it scans the entire HDD for new executables to add to the whitelist, after the admin uses the "Enable" option to exit MM (there is a long pause with a "Please wait" message after I do that). While it scans, A.E. will detect an existing executable that has been changed, presumably during an update or upgrade, as a "new" executable file, because A.E. calculates a cryptographic hash for it but doesn't find a file that has the same hash on the whitelist. But, if there is a file that has the same name which has been stored in the same location, and it is already whitelisted, then A.E. just updates the cryptographic hash for the file. I am not sure whether A.E. removes files from the whitelist that it cannot find in the location recorded on it. It is worth noting that the admin can choose to whitelist any folder, which allows any executable stored in that folder to run (including malware). This feature is probably more useful for blacklisting folders from which you do not want any executable, if one is present, to run. Note, though, that in my experience with MM, executables which are stored in a blacklisted folder are allowed to run unchallenged. [b]All of which means:[/b] if the admin activates MM and there is a malware executable present, then it will be added to the whitelist if A.E. happens to find it unless -- [i]perhaps[/i] -- the malware file is in a blacklisted folder. Faronics has admitted that adding a malware executable to the whitelist during MM is a risk. So the admin had best run CCleaner (to delete everything from the system "temp" directory, among other things), empty the Recycle Bin, and scan the HDD with an AV (or two) before they put A.E. into MM. That said, using Maintenance Mode is not required for installing, updating, or uninstalling software. But your A.E. password had best be quick and easy to enter. You're likely to be bombed with a series of notifications that an executable that explorer wants to launch is not allowed to run -- starting with the respective installation program(s) and, sooner or later, followed by a notification for each executable of the software that you have installed or updated. While a program isn't on the whitelist, you can [i](1)[/i] allow it to run this time only, [i](2)[/i] stop it from running now, or [i](3)[/i] allow it to run now and add it to the whitelist, too. A.E. will display that notification for any file that is not on the whitelist and not launched from a whitelisted folder, and for any file that is not on the blacklist and not launched from a blacklisted folder. That is, the notification is displayed for any executable whose cryptographic hash does not match the hash of any file that is on the respective lists, and is also not stored in a whitelisted or a blacklisted folder. Perhaps a better alternative to using MM is to run the installer and respond to the A.E. notification query, allowing it to run, but don't run the installed program immediately afterward. Instead, after the installation is finished, use the A.E. Whitelist Editor to edit the Active Whitelist. Use the editor's Scan feature just for the directory into which the program was installed, to add all of the executables [i](except .DLL files)[/i] to the whitelist. For many installers, though, any delay in launching it will simply terminate the process. Whether that happens seems to be determined by the program though, not by the OS. Unless and until the admin adds the installer to the whitelist, A.E. will continue to delay the installer's launch. This alternative to MM would probably be feasible for most installations, updates, or upgrades -- except for Windows XP. The Windows XP patching utility can stumble if there is interference in its execution. [b]Further,[/b] the user must take into account whatever the AV and/or the firewall might do about A.E. Maintenance Mode activity, too. For example, Sunbelt VIPRE uses, in effect, an evidently quite short whitelist that the user cannot access or modify. Every time an [i]"unknown to VIPRE program"[/i] is loaded, VIPRE pops up a Block or Allow query dialog. So, it may be best to temporarily disable AV "active protection" while A.E. runs in MM. After A.E. has been installed, configured, and the whitelist is reasonably complete and stable, it rarely intervenes in the ordinary course of using the computer. But it does take a while to get every executable on the whitelist that belongs there. Unfortunately, though, [b]there is another risk[/b], namely A.E. does not whitelist .DLL files. That is particularly worrisome because, since it also does not whitelist JavaScript routines, a web site can use one to "drop" a malware .DLL on the computer. The .DLL can be one that has the same name as an existing .DLL, and it might be a modification of an existing .DLL. Regardless, when a program that loads the .DLL also executes the malware within it, the consequences can be be disastrous.

santeewelding
santeewelding

I don't think he will be back to address our concerns.

Ocie3
Ocie3

from "every flying piece of code coming at us" unless, of course, you disconnect your computer from the Internet and all other networks, then remove any means of connecting it to external storage media or to another computer. But to be really safe, you also must prevent anyone from connecting any device that would allow a bit stream into the computer, such as a keyboard. Even using a mouse could be a potential threat. Of course, then you must prevent anyone from accessing the computer -- except you.

deepj
deepj

How do you discern that you are not thinking of something that you are not thinking of? By asking someone more discerning than I. And keep asking... thanks again

Ocie3
Ocie3

Since I'm a bit tired tonight I should limit my remarks to less than tome length. :-) [i]"Do the whitelisting programs(wlp) have access to code objects(co) before they get executed by interpreter type programs such as Java, HTML, FLASH, and others ?"[/i] First, we need to recognize the distinction between what it might be possible to do, and what is actually being done by whitelisting systems that are available. Also realize that what it is possible to do is not always feasible to do. I am not an expert as to what many existing whitelisting systems are doing, and their documentation is often lacking or sketchy with regard to technical details. Please examine the chart that the Infoworld reviewer created to compare the features of 5 enterprise whitelisting systems (and Windows 7 Ultimate AppLocker): http://www.infoworld.com/node/98873?source=fssr It could be misleading. For example, it shows that each of the 5 enterprise systems whitelist JavaScript. It is not clear whether each of the 5 systems will [i]examine[/i], and whitelist as appropriate: [b](1)[/b] files that contain JavaScript that are stored on the computer which is running the whitelisting system; [b](2)[/b] files that contain JavaScript, [i]e.g.,[/i] in an HTML document, when they are downloaded to that computer, and [b](3)[/b] JavaScript scripts that are on an HTML web page fetched by the browser, which is running on the same computer on which the whitelisting system runs. The first is almost certainly included, and the second does not appear difficult to do, although it might not be done by any (or it could be done by some or all) of the 5 reviewed systems. With regard to the third, in theory, a JavaScript script that is embedded in a web page which has been fetched by a browser (from another computer) can be identified as an object, and a cryptographic hash can be computed for it. So any such script could be whitelisted. In practice, that might not be [i]feasible[/i] to do without the participation of the browser. For example, the browser must identify the Javascript script as such, if only to render the page as it is designed to be rendered. It could compute a cryptographic hash(es) of the script, and make that data available to a whitelisting system. Of course, the whitelisting system would have to anticipate and/or look for any script hash(es) that it could receive from the browser. However, it could be feasible to perform the third function without participation of the browser, by scanning incoming TCP/IP packets for Javascript scripts, as well as for other "executable objects". It would not matter whether the script is embedded in a web page or is in a .PDF document that is being transferred to the computer. So, I cannot offer a definitive reply to your question, unless "I don't know." would be acceptable. :-) [i]"And is it possible for the wlp to stop the interpreter from executing the co or do the wlp just see the interpreter as an approved co so whatever it does is ok ie does wlp see the truth or just the masquerade?"[/i] If the "interpreter" is participating in the whitelisting system, as I've described in my example for JavaScript scripts and browsers, then it would not make sense for the "interpreter" to compute the hash(es) and make them available to the whitelisting system if the whitelisting system could not forbid the "interpreter" to execute an unauthorized executable object. If the whitelisting system is intercepting and scanning incoming TCP/IP packets and/or other "traffic" for executable objects, then it can preempt any "interpreter" from acting on an executable object(s) by removing them from the packet before it forwards the packet to its destination port. However, as to what is currently implemented in the 5 reviewed whitelisting systems, I would say that all whitelist each of the "interpreters" (since they are stored as executable files), and [i]probably[/i] whitelist other executable objects according to the three contexts that I've discussed above. [i]"Are there other co we are not thinking of?"[/i] How do you discern that you are not thinking of something that you are not thinking of? :-) Does "firmware" matter? I do not see [i]BIOS[/i] listed on the comparison chart to which I referred, but it is technically possible for malware to be incorporated into "flash memory" which is used to store a BIOS or other firmware. In order for the malware to be incorporated, though, its installer must be executed on the same computer as the one on which the whitelisting system is running, without the installer being recognized as unauthorized and prevented from running. Enough said, IMHO. There are probably more "executable objects" in the innovation pipeline which eventually will be deployed, with corresponding malware soon to follow. The only constant is change. (Although I have thought of ways for malware to evade a whitelisting system, I decline to discuss them in public.)

deepj
deepj

Ocie3: Thanks for the tutorial. Do the whitelisting programs(wlp) have access to code objects(co) before they get executed by interpreter type programs such as Java, HTML, FLASH, and others ? And is it possible for the wlp to stop the interpreter from executing the co or do the wlp just see the interpreter as an approved co so whatever it does is ok ie does wlp see the truth or just the masquerade? Are there other co we are not thinking of?

santeewelding
santeewelding

I'm outta here, until this is thrashed out to my country-boy, one-eye-in-the-middle-of-my-forehead, satisfaction. Thank you, Ocie.

santeewelding
santeewelding

I didn't tell him that, often, the point is allowed through the ambush, and the attack commences upon rear elements, progressing into the main body. By which time I would be speeding ahead to call for help, if that occurred to me.

Michael Kassner
Michael Kassner

But, I can remember from history where some successful attacks were from the rear.

Ocie3
Ocie3

;-) :-) :-) :-)

santeewelding
santeewelding

Go off-road to secret places in order to train, one our group always takes up the rear. He hangs back. I asked him about it, once. "Simple," he said. "You draw fire first. I turn tail. I make a call for help, if I think of it." Eminently practical and cold-blooded, I told and congratulated him. You, Ocie: you take the lead. I'll hang back. If I think about it, I'll try to make a call, that is, if there is coverage. If not, I'll maybe notify your next of kin. Keep everybody posted.

Ocie3
Ocie3

building robust whitelisting into the OS should be advantageous. But the Infoworld review presented Windows 7 Ultimate AppLocker as a "free" application like BitLocker. In the interests of free competition, it would be a good idea to have efficient API features to support whitelisting, though. I am not an expert and I might be seriously mistaken about the following example[b]:[/b] in the course of reading developer descriptions of their whitelisting software and how it works (to the extent that they disclose such information), I have the impression that a whitelisting utility must install a kernel-mode driver in order to ascertain when a .DLL is being loaded by a program, in order to check whether the .DLL has the same hash that is recorded on the whitelist and prevent it from being linked, if it is not on the whitelist or the hash differs. If there are any existing APIs that disclose whether a .DLL is being loaded, then maybe they do not allow the monitor to prevent the .DLL from being linked into the application, or maybe they're simply too slow to be useful. [i](For once, I hope that I am wrong and anyone who knows what they are talking about is welcome to set me straight. :-) )[/i] In contrast, apparently, monitoring the launch of independently executable files (usually, but not only, .EXE) is not particularly difficult and does not require a kernel-mode driver. And we both know that Microsoft's Patchguard will not allow a kernel-mode driver to be installed on a 64-bit Intel Vista/7 computer. BTW, If I didn't buy the computer because I needed and/or wanted to run it, then it's a utility program, not an application. :-)

Michael Kassner
Michael Kassner

Unless I am mistaken, AppLocker does not accept all applications. I am looking into that. A member said that the OS would be the ideal device to control this and I tend to agree.

Ocie3
Ocie3

that operates without any human participation [i]qua[/i] intervention at all, then that is quite likely a significant fault in its design and implementation. AI systems are not yet so advanced that they never need us to do anything. Although, I've heard rumors. .... That said, it would not surprise me if Windows 7 Ultimate AppLocker has "a bunch of issues". As I wrote, it is Microsoft's first iteration in developing such software.

Michael Kassner
Michael Kassner

You have to get all the software developers to agree to method. Then you have to agree to a repository. Not that easier, I fear.

Ocie3
Ocie3

is to persuade the developers to create and issue hashes for each of the executables in the release versions of each product. It is not all that hard to do, actually. Some people just have issues about the decision as to whether a program is [b]ready[/b] to be used by others, regardless of whether the software is sold, given away or released as open source. Everyone knows that any software that is likely to be truly useful almost certainly has a "bug" in it, and maybe many, but hopefully no flaw or vulnerability that will prove to be important. Some programmers prefer to ignore the bugs, and seem to think that users should accept unreliable, or simply difficult to use, software as long as it produces correct output "enough" of the time. In contrast, the perfectionists among us want to examine it just one more time and remedy some of the remaining known issues. Of course, sooner or later, the software must be released to its users, at which point the cryptographic hashes can be computed and published, too, if knowing that data is the custom and expectation of the people who obtain it and install the software. Once a developer does agree to participate in a program, such as the one run by the NIST, "timely delivery" of the authentication data is usually not a problem. Doing that becomes integrated into the developer's normal routine for creating release packages when the decision is made to release the software. However, it does become a problem when a developer does not have a "normal routine" for creating releases of their software and delivering them. (I will refrain from naming names and giving examples.) The whitelisting systems such as the ones that Core Trace, Faronics, and Savant Protection implement do not attempt to authenticate the software which is installed on the system, neither at the time that the whitelisting software is installed nor subsequently. Whether an executable is added to the whitelist is usually either by default, or by a decision of the admin or an admin's assistant to add it to the whitelist. If the whitelist administrator wants to avoid inadvertently adding malware, then they must adopt some channel for authenticating the software prior to its installation and inclusion in the whitelist, and for detecting software that is present but which cannot be authenticated. They also should adopt a process to audit the installed software regularly to determine whether it has been corrupted before the whitelisting system refuses to allow it to run. Those two aspects of software security [i]and[/i] the need to keep the whitelist data current and valid -- [i]i.e.[/i], because it changes when software is updated or upgraded, and when software is uninstalled -- are the biggest challenges for a whitelisting system to overcome, IMHO. It is a significant weakness when those issues are not addressed properly. Unfortunately, these issues are ignored in some systems and given scant consideration in others.

Michael Kassner
Michael Kassner

If you can get the proponents to agree to a timely delivery of any changes.

santeewelding
santeewelding

Does not mean that I do not pay strict attention to it. I am paying strict attention to every word you offer. Thank you.

Ocie3
Ocie3

such as the one included in Bit9 Parity are: (1) you can verify whether the software that you've obtained has been altered since the file(s) was released by the developer; and, (2) you can verify whether software which is already installed on the computer has become corrupted since, without attempting to run it. In the first case, if I download and install software that has been hacked, then I don't have any way to ascertain whether it is the same file(s) that the developer released, unless someone (usually the site from which I obtained the software) has published hashes for it. In that case, I can run a hashing utility that produces one or more hashes using the same algorithms and compare them to the ones that have been published. A centralized database should make that easier to do, and it could even be an automated process. In the second case, in the context of most whitelisting systems that I've seen so far, you only know that software has become corrupted if you, or a computer program, attempt to launch it. Then any whitelisting system running on your computer should detect that its current hash is not the same as the hash which it recorded when the file was installed (or, instead, when the whitelisting system was installed). So it will stop the file from being executed. The program is stopped from doing any damage, but it would be better to know that it had become corrupted before it is needed to execute, if possible.

Michael Kassner
Michael Kassner

I am not sure a central whitelist database is the correct way to go though. Most apps are using the approach where each system has a whitelist. That eliminates many problems associated with updates and version changes and having to react quickly.

Ocie3
Ocie3

[i]"blacklist it"[/i] when you wrote: Quote: [i]"What really is needed is a 3rd party (neither a security firm or a software developer) that reviews applications looking for hidden code that would compromise a system, then whitelists it."[/i] ;-) Otherwise, interesting comments.

Michael Kassner
Michael Kassner

The whitelisting applications do work with WSUS and AD for the most part. It seems that AD is not granular enough though and there are ways to elevate privileges that do not affect application whitelisting.

Editor's Picks