Whitelist Tutorial 1
- 1. A (Somewhat Biased) Whitelist Tutorial How Whitelisting Applies In An IT Environment Let's start with a definition of whitelisting: Whitelisting is a process for denying the ability to execute to all software not contained on a right to execute list. Or, Whitelisting is a process for permitting the execution of all software on a right to execute list and denying the ability to execute to all other software. Some whitelisting products demonstrate the ability to examine in great detail the particulars of an individual file, although in many cases the requestor must have internet access to the vendor's database, which may not always be available. Many of them also demonstrate the ability to determine with an unstated degree of accuracy the program files that are installed by a given application. They do not, however, indicate how a requesting user would specify the build number or patch level of the application for which the list of files is requested, and any change they might experience over time. Some vendors profess to know that the only way to combat threats is to understand the full breadth of the malware's capabilities, propagation, and Command-and-Control, including deep research and analysis into the unique networked, borderless nature of botnets – something very different from simple signatures or packet analysis. The “powerful insight” offered by these vendors attempts to identify both individually compromised machines and entire compromised networks operating globally across corporate boundaries, including live attack monitoring "within a safe, controlled environment" in order to learn more about the exact risk, intent and evolution of an attack. But, for a moment, refer back to the definition of whitelisting at the top of this page. A properly- functioning whitelisting application does not permit infections to occur. You may not even be aware that an attack is in progress unless it amounts to a denial of service of sufficient scale to actually interfere with your organization's ability to communicate with the outside world. And you don't need to know. What, exactly, would you do with the results of your “deep research and analysis” into unauthorized software that attempted to reside on or execute in one of your devices? Suppose you determine that it was developed in Eastern Europe by a well-known criminal organization which uses it for distributing fake anti-virus products; what do you do? You can't take any action against them. You can report your findings to the authorities, and they will probably take no action. You can post your findings on some web forum where, hopefully, you'll be the first to discover this particular strain of malware and can then experience your fifteen minutes of fame. But you've accomplished exactly nothing more than wasting your time. Unless you are one of the few specialists legitimately involved in researching malware, the only thing you need to know about the malware that attacks your organization is that it was caught and impounded. It doesn't matter who is responsible for it; it doesn't matter what its purpose is; it doesn't
- 2. matter how many nodes within your enterprise it tried to attack; it does matter that your anti-malware application caught it, prevented it from executing, and impounded (quarantined) it. Some vendors offer “centralized, real-time visibility of new and possibly unknown software as it appears on a desktop infrastructure, enabling IT to quickly identify and diagnose problems before they have business impact.” In an IT environment which utilizes whitelisting as defined above, there is no "new and possibly unknown software" appearing on any desktop, or any other computer. Whitelists exist specifically and only for the purpose of preventing the execution of software that is not on the white list. If it is on the white list, it is known; if it is not on the white list, it not only should not execute, it should not exist on the endpoint. And this: “It is surprising to realize how limited IT professionals are in their ability to find contextual and associative information about the thousands of software components running on the desktops they are trying to manage. . . . By gaining a full understanding of what all these components are, who made them, how they were deployed, and understanding what other users across the world know about them, IT professionals can make better decisions and greatly reduce the opportunity for error and damage.” Wow! While it may be true that such information is not always readily available, what is really surprising is that anyone would expect IT professionals to routinely need such information. When an Operating System or an application is installed, what is installed is what is installed. Whatever it is, usually comprising thousands of executables and shared libraries along with many thousands of other files, it is part of the platform and should become part of the whitelist for the device on which it was installed. The IT professional's challenge, from a security perspective, is to ensure that the OS or application being installed has not been corrupted; if it is in "pristine" condition, just as the vendor released it, there is little need to worry about "contextual and associative information" about what is being installed. Making that information available to IT staff introduces risk, because time spent pouring over irrelevant information is time not spent productively for the organization, and may result in other things going unnoticed and unattended to. Diverting attention from important tasks such as verifying the integrity of media and its contents before beginning the install, to the trivial, even if highly interesting and entertaining, risks great injury to the enterprise. IT professionals do not need to pursue tangential details that are irrelevant to the security and performance of the systems for which they are responsible. Decisions regarding the complement of software to be authorized within the organization as a whole or to individual computing devices properly belong to some level of management, not the IT professionals who are charged with day-to-day control and operation of the IT infrastructure. Once management has made and published their decisions, the operations IT professionals must ensure that legitimate, valid, licensed, and uncorrupted software is installed as required consistent with the directions of management. It is not clear how or to what extent contextual and associative information could be of legitimate use in that context, since mainstream vendors typically provide complete installation programs with dependencies (usually) clearly identified. Furthermore, none of the vendors mention audits of the devices to ensure that all software on the device can be accounted for. In an IT environment where whitelists are enforced, there should be no software
- 3. on any device that is not on the whitelist. But regardless of what should be there, periodic audits of the software residing on each device should be conducted to ensure that nothing has slipped through the cracks. This is in compliance with the Critical Security Controls, Critical Control #2 (from SANS; basically, know the software on each device and enforce a whitelist); this knowledge is required. On the other hand, one vendor claims that with its “application control” “you can audit, meter or ban the use of unauthorized applications.” Why would anyone want to audit or meter the use of unauthorized applications? If they are okay to use, they are not unauthorized. If they are unauthorized, they should not be permitted to execute. “Bans” (blacklists) should not be needed. This is precisely what whitelists are for. Detecting Unauthorized Software If a whitelist is worth having, it should be used. To be used, it should define the complete complement of software that is permitted to execute on the device for which it is intended, and each "software" file should be uniquely identified. Devices for which a whitelist is being enforced have no need for a blacklist, or a list of "banned" software; everything not on the whitelist is banned. In some vendors' implementation, unauthorized software is permitted to execute while the application checks with a database somewhere “in the cloud” to determine whether anything is known about the unauthorized software. It is unknown, therefore permitted to execute while other checks are being performed. After some indeterminate amount of time, a decision is made as to whether the unknown software should be permitted to continue to run. In the few seconds or more it runs unmolested, malware as sophisticated as that we see today could morph, propagate within the enterprise, and make cleansing of the systems extremely difficult and time-consuming. This “execute while checking” approach unnecessarily introduces risk, complexity and ambiguity. Enforcement of the whitelist requires no other list or lists. In order to enforce a whitelist, software must be detected before it can fully execute. One way is to watch write activity to hard disks and analyze what was written by referring back to the device's whitelist. Security Assistant needs no internet access, or access to any external device, in order to determine whether to permit execution. Since the whitelist resides on the device and is authenticated at each use, no external support is needed. And, Security Assistant cares nothing about the contextual and associative information about the file. If it is on the whitelist, it is permitted to execute. If it is not on the whitelist, it is immediately quarantined. Hard drive monitoring alone is not sufficient to trap all unauthorized software. Some malware, downloaded without user knowledge or consent, attempts to execute without first being written to the hard drive1. One method available to deal with this kind of threat is to monitor process starts. Processes which attempt to start can be intercepted and validated before being permitted to proceed. Processes not on the whitelist, including full path, can be blocked2. Some processes which appear on 1 Or before the downloader releases its handle on the file, making quarantine difficult, perhaps delaying long enough to permit execution before quarantine. 2 This is a complex process, as attested to by SolidCore's experience with malware which immediately attempts to execute again when it is blocked. Such immediate re-attempts can, as SolidCore learned, result in a race condition which consumes all available CPU and
- 4. the whitelist are used by other software when executing. Each process, then, must be examined to determine what software it is attempting to execute in addition to the process's own software in order to determine whether to permit continued processing even when the process is on the whitelist. Two examples of this kind of process are cmd.exe and svchost.exe, both used to execute other software. In addition to monitoring hard drives, removable media must also be monitored. This monitoring is not for detecting writes to the media, but for preventing execution of software on the media. Some vendors attempt to solve this problem by disabling all USB access, but that can cause problems with the legitimate uses of USB drives. Security Assistant immediately detects and logs the insertion of removable media, and prevents execution of all software on the media unless it is on the device's whitelist including path to the removable media. Disposition of Unauthorized Software Some vendors' products do not quarantine unauthorized software. Instead, they simply “enforce a whitelist” by blocking execution. Some malware takes exception to being blocked and will immediately restart, resulting in another blocked execution, resulting in another restart, and on and on. In the worst cases this results in CPU saturation, which is a DoS, and can be interrupted only by a hard reset of the device. Not good, especially on critical servers. Naknan's Security Assistant quarantines new or modified executables or shared libraries that appear on the hard drive if they are not on the device's whitelist. Note that the software may be on the whitelist and still not be able to execute if it is not at the correct path. If it is on the whitelist but on the wrong path it will not be quarantined, but cannot execute. If it is not on the whitelist at all it will be quarantined. If it is on the whitelist at the correct path, it will not be quarantined and will be allowed to execute. Complexity of Operations With the amount of information made available by some products, it will be easy to become distracted from the real job of managing the enterprise's IT systems. Using multiple lists when only one is needed is one example. Providing volumes of information about unknown and unauthorized files and their contextual relationships is another. Giving every IT person the capability to drill down to excruciating levels of detail ensures that some will drill down even though the details are irrelevant to the decision of whether to permit execution or not. Giving them the capability to read other users' comments about a particular file will ensure that some do, even though the comments are irrelevant at best and deceptive at worst. Giving them the capability to post their own comments about a particular file will ensure that some do, even though the posted information is unverified, perhaps based on an improper interpretation of the circumstances surrounding the file and its discovery, and generally accomplishes nothing more than boosting egos and wasting time. An IT department which is serious about IT security will have roles assigned to its various personnel. Some will be charged with determining whether recently-released patches are suitable for deployment within the enterprise and, if so, whether any individual devices should not receive the patch. Some will be charged with the actual deployment, and verification that the deployment was successful. Some will effectively results in a DoS condition, requiring hard reset of the device.
- 5. be charged with monitoring and control of the individual devices and the networks connecting them. Some will be charged with maintaining the security configuration of firewalls and other perimeter defenses. And the list goes on, and on. Many of the IT personnel will perform multiple functions at various times, and in smaller organizations everyone may do everything. But it is rare indeed for an enterprise to suggest that anyone should investigate contextual relationships of off-whitelist files, and functionality, where that organization utilizes whitelists to control software execution. The reason should be obvious, but we will devote a single paragraph to it. Whitelists define what is authorized to execute. Everything else is unauthorized. Organizations which enforce whitelists will not find unauthorized software appearing on desktops, servers, or laptops. There will occasionally be some few files quarantined, usually without the device user's knowledge, and they will be logged, eventually deleted, and quickly forgotten, because they are not authorized to execute. Some software will attempt to execute and be blocked, usually from removable media or a web interface; often, the device user will be unaware. Files are quarantined or blocked because they are not authorized to execute. We need know nothing else about them until a device user asks for permission to execute some software not on the whitelist. Then, and only then, we begin the process of determining whether to recommend adding the software to the whitelist, and it isn't done based on the comments of other users who are completely unknown to us and whose integrity and motivations are also unknown. It is counterproductive to spend scarce IT labor hours chasing down details of unknown provenance for files which are not intended to execute in the enterprise. Whitelist Maintenance On one vendor's website, the sponsored white papers contain comments related to use of hashes to verify the integrity of files. While conceding the extraordinary reliability of this method, it is easily dismissed because patches and updates cause the hashes to change so frequently. They are really on to something here, one of Naknan's key discriminators. The nice thing about a hash rule is that . . . hash rules are effective regardless of where the file is located on the system. Even if a user were to rename a restricted file, the hash rule would still be in effect. How true. If you use any other method to authorize software to execute, you don't know with certainty what you're authorizing to execute. If the objective of using whitelisting is to achieve greater endpoint security, then you must use hashes to verify the integrity of each executable and shared library each time it executes or you might as well stop whitelisting, and the quote above strongly suggests that this vendor does not check hashes of executing software. Naknan considers such a check critical. The reason is obvious: If malware can corrupt a dll or exe that is on your whitelist without changing the file's meta-information (it can), then you've just whitelisted malware. But this leads us to the maintenance problem they apparently don't want to deal with: If a change is made to the restricted file, then the file’s hash value also changes, which means that an existing hash rule would no longer apply to the file. A few years ago, this was no big deal. Most of the time the only way that file’s hash would change would be if a new version of the application
- 6. were released, or if a user used a hex editor to modify one of the bytes in the file. Today though, it is common practice for software publishers to frequently release patches for their products. Patches almost always overwrite the previous code, therefore rendering any existing hash rules against that code useless. Also true. In order to be effective, a whitelist must include every executable and shared library which is authorized to execute on a given device. That whitelist must include hashes and path information for all those files and no others, it must reside on its device so that it is constantly and immediately available, and it must be protected from corruption. This immediately highlights the problem noted in the quote above, namely how to keep the whitelist in sync with constant file changes. An average Windows desktop has 15,000 or more executables and shared libraries, many of which change each Patch Tuesday. Absent a high degree of automation in the whitelist maintenance process, the task would indeed become unmanageable. It looks even worse when Mac OS X and Solaris are included. It doesn't have to be a "big deal." Naknan's Security Assistant was designed to overcome this problem by automating the whitelist maintenance task. When patches, updates, and applications are deployed by Security Assistant, the target device's whitelist is automatically updated. If you use another system for deploying patches, updates, and applications, Security Assistant can make whitelist changes for them as well. There's no need to limit your whitelist to application names, which is known to be ineffective. There's no need to maintain a blacklist, which is also known to be ineffective. And, what can we say about graylists? Summary Whitelisting is the only truly effective way of preventing unauthorized software from executing on your computing devices. It is most effective when combined with quarantining, and integrated with patch management so that whitelists can be automatically updated as patches and applications are deployed and installed. Adding complexity by, for example, using other lists (such as blacklists and graylists) dilutes the effectiveness of whitlisting, adding rather than reducing risk. Attempting to provide details of unknown provenance about unauthorized software creates distractions for IT staff, adding more risk. The only effective way to control the software inventory of each node (including preventing malware and unauthorized applications) is to implement whitelisting, and the lowest-risk approach to implementing whitelisting is to use a full-featured product that automates as many tasks as practical so that IT staff can redirect their efforts to other productive activities while the whitelist product keeps the organization's endpoints safe. www.naknan.com