Use of this document and web site are governed by the Terms and Conditions of Use for InfoExpress's web site.SummaryThis Tech Note provides guidance on building CG policies, starting from some common-sense ideas about endpoint security configuration. This is meant to demonstrate the process of selecting test conditions that are appropriate for a particular organization, in particular its desktop/laptop configuration and security requirements. CyberGatekeeper administrators can use this as a starting point for their own organizations - I'll try to point out where customizing is likely to be necessary. I'll also try to explain the reasons for choosing a particular sort of test, in situations where there are multiple options.
This is definitely an evolving document - please don't hesitate to post comments or questions!
Security configuration requirementsPrior to joining InfoExpress, I worked at a well-known private university with a
lot of unmanaged end user machines, mostly Windows and Macs with a sprinkling of Linux. As one of the IT department's security officers, I investigated a number of compromised machines, and found that in nearly every case the attack was successful because the system was misconfigured or mismanaged in some way:
- A critical system component or user application with a known vulnerability was unpatched or patched incorrectly
- The system hosted insecure services, like telnet or peer-to-peer file sharing
- The system was configured incorrectly - for instance, it didn't use strong passwords, or it allowed anonymous file browsing, or it used HTML-based email which encouraged spyware infections
Although the numeric majority of exploited systems were Windows-based, the same management problems occurred on the UNIX-based operating systems, and led to similar types of intrusions. What I observed in this live-fire environment proves to be true in most organizations: the vast majority of computer security incidents
could have been prevented if there was a way to apply the knowledge and experience of a senior system administrator to all systems on the network.
The CyberGatekeeper policy enforcement system provides an infrastructure-based architecture for applying these sorts of common sense rules to the machines on your organization's network. CG policies can be nearly infinitely complex, incorporating
- requirements based on a variety of endpoint conditions
- heterogeneous network topologies including LAN-based, VPN and wireless
- granular remediation actions which may or may not be transparent to the end user
However in most organizations, it's advisable to begin your CG testing and integration with a less ambitious set of policies, while you learn the capabilities of the system and accustom both yourself and your users to the new security infrastructure.
To illustrate the process of building a manageable CG policy, let's translate the general observations about how machines get hacked into some specific requirements for Windows XP desktops. For the purposes of this example, I'm assuming no Microsoft-based management infrastructure, so no Active Directory or centrally-managed patch system or group policies.
Based on the above requirements, the endpoint must have:
1. Critical MS OS patches, as well as critical patches in common applications
2. Automatic Updates enabled, and configured to download and install patches automatically
3. Windows XP Internet Connection Firewall enabled, to limit the risk from insecure services
4. Actively running Norton AV 2005
5. Outlook configured for plain-text email only
These requirements may be all that's required in a relatively unmanaged environment. In most corporate settings, the configuration criteria may be much stricter, enforcing a broader range of specific applications and settings. And selling plain-text email is a struggle anywhere, but since this is only a sample policy, I can be as totalitarian as I like.
Notes on particular requirements:
Critical patches - Oddly enough, I frequently disagree with vendors' assessments of the severity of vulnerabilities in their own products. In a relatively open environment, the most time-critical patches are the ones that can be exploited remotely without end-user involvement. Critical vulnerabilities are those meeting the following criteria:
- The vulnerability is located in a core operating system component, is installed by default, or is in common use
- The vulnerable code cannot be disabled at all, or can't be disabled safely, or can't be disabled with predictable results
- The vulnerability allows an attacker to run arbitrary code on the target machine
- The vulnerable component is accessible from the network
- The vulnerability can be triggered without user authentication, or more broadly without valid credentials or privileges on the target machine
- The vulnerability can be triggered without user interaction
This is a "least common denominator" set of properties - it only describes vulnerabilities that can lead to fully automated, self-propagating attacks. On Windows desktops, spyware is an increasing threat to data integrity and confidentiality. Most spyware is introduced through vulnerabilities in Internet Explorer. IE vulnerabilities aren't "remote vulnerabilities" by the strict definition, since they don't involve the ability to accept unsolicited inbound network connection requests. And they can't be triggered without user
interaction, although they are frequently triggered without user
awareness. So in a Windows environment I would add IE patches to the critical list. Luckily for the simplicity of this policy, we only have to check for the most recent IE patch, because the latest one always includes all previous fixes.
Windows XP SP2 only has one critical patch at this point,
MS05-011: Vulnerability in Server Message Block Could Allow Remote Code Execution (885250).
MS05-014 is the most recent security update for Internet Explorer.
The CG Policy Manager includes several mechanisms which can be used to validate operating system and application patches. The two most commonly used tests are based on information in the Windows registry or on file versions. WindowsUpdate sets registry keys when it performs a patch installation, but those keys are not necessarily reliable indicators that the patch was installed correctly, so I prefer to check file versions to verify patching. The zip file attached to this Tech Note includes file version checks for MS05-011 and MS05-014.
In a UNIX environment, I would add local root exploits to the list of patches to check, at least on multi-user systems.
In an organization with multiple operating systems in use, you'll need to select which OS and application patches are critical, and either download tests from the InfoExpress technical forum, or create your own using the CG Policy Manager.
Automatic updates - Because my organization had no centralized patch management system, I insisted that Windows desktop systems be configured to download and install OS patches automatically, unless the user could make a credible argument for determining their own patch schedule.
If your organization has not explicitly created this registry key to manage Windows Update settings, the Windows Update configuration data is stored in this registry location:
HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
(the space between "Auto" and "Update" in the last part of the key is significant). This key exists on all installations of Windows 2000 SP3 and later, and all versions of Windows XP. Depending on the value of the key, Windows Update behaves as follows:
- 1 = automatic updates have been disabled
- 2 = notify use that patch is available; download and install patch only with user interaction & approval
- 3 = automatically download patches; prompt user for installation
- 4 = automatically download and install patches
In the attached zipfile, the test with "Default" in its name verifies the existence and value of this setting.
Microsoft's document
How to configure automatic updates by using Group Policy or registry settings explains that the registry value HKLM\Software\Policies\Microsoft\WindowsUpdate\AU\NoAutoUpdate controls whether or not Automatic Updates are enabled, in a managed desktop environment. In typical "double negative" fashion, this value must be equal to 0 to enable updates. The registry key HKLM\Software\Policies\Microsoft\WindowsUpdate\Au\AUOptions controls how the updates proceed, based on the values described above. Note that these keys only exist if you have explicitly created them, using manual registry editing or Group Policy.
The zipfile attached to this tech note includes registry key checks for the Automatic Updates setting - the test with "Explicit" in its name verifies its existence and value.
If your organization uses a different patch management architecture, you'll want to create tests that check for the correct version of your patch management client, guarantee that the PM client is running, and validate configuration options if necessary.
Windows XP Firewall enabled - For the uneducated end user who is not trying to run a Web server or a game server from her Windows desktop machine, the XP firewall is a useful mechanism for preventing unintended traffic.
The registry key HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\EnableFirewall controls the action of the XP firewall. If it's set to 1, the firewall is enabled. The zipfile attached to this tech note includes a registry check for this setting.
If your organization uses a different personal firewall to secure endpoint machines, you'll want to use tests tailored for those applications. The CG Policy Manager comes with tests for a number of popular PC firewalls, or you can create your own.
Actively running Norton 2005 AV - Most organizations and home users understand the importance of anti-virus software on their machines, and AV is considered a fundamental component of corporate desktop builds. But most of us have had to argue with people about running their AV software in real-time scanning mode, usually because the user feels that the cost in performance is too high. With this test I can take machines without active AV processes off-line, giving me a convenient way to detect people who are trying to detour around my security requirements.
But the test for an active AV process provides an additional benefit that may not be readily apparent. In any given month, over half the viruses and exploits released into the wild (and subsequently cataloged by the anti-virus firms) disrupt the performance of anti-virus software and personal firewalls. By requiring active AV for network access, you can remove newly-infected machines as soon as their behavior is disrupted,
even before your AV system has up-to-date signatures for the new attack. Unlike many competing policy enforcement systems, which depend on the output of AV systems to identify infected machines, the CG system gives you the ability to detect and isolate infected systems immediately, significanty reducing your organization's chances of leaking confidential data while an exploit goes undetected. At least as long as the exploit disrupts the AV process.
The zipfile attached to this tech note includes a basic test that checks several characteristics, including file versions for the AV engine and signatures, as well as process checks for real-time scanning. You can use these directly if you happen to be using Norton 2005, but you'll want to check the values for the file versions carefullly, because they frequently change. I prefer not to audit signature databases directly, precisely because keeping the file version of AV databases up to date is a significant task. But many organizations insist on specific AV signatures in order to guard against specific exploits.
Outlook configured for plain text email only - Forcing your end users to read their email in plain text format may be a difficult political sell, since so much email arrives with graphics and formatting. But HTML-based email is a significant source of spyware and viruses, especially if your organization depends on Microsoft Outlook as its mail client.
The Microsoft Knowledge Base article
Q307594 describes a registry setting that forces Outlook to remove HTML tags from all messages. Even if you can't force this sort of behavior on all your users, it might be appropriate for people with extremely sensitive data on their machines, or people with elevated system privileges on your corporate servers (system and database administrators, for instance).
The zipfile attached to this tech note contains a check for the registry key:
HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Options\Mail
The value must be set to "1" to require plain-text mail.
Other considerationsAs you design tests and policies for your organization, remember to test them on each of desktop configurations you support. Sometimes tests can have unexpected results.
For instance, one of the reasons we recommend using file version checks for Microsoft patches, rather than relying on registry keys, is that MS file version numbers strictly increase as operating systems evolve. For instance, consider the file %SYSTEMROOT%\rpcrt4.dll. As the observant reader will conclude, this file is a core component of the Windows Remote Procedure Call interface, one of the components involved in the widespread Blaster and Welchia epidemics of autumn 2003. Here are the file versions for the update included in
MS03-026: Buffer Overrun in RPC Interface Could Allow Remote Code Execution (823980):
Win2000 SP3 and SP4 - 5.0.2195.6753
WinXP no service pack - 5.1.2600.109
WinXP SP1 - 5.1.2600.1230
For each of these OS versions, the patch installer created a registry key for the update, as a quick mechanism to verify that the patch was installed. But that's a dangerous way to determine safety against the RPC vulnerability. On a clean install of XP Service Pack 2, the file version for rpcrt4.dll is 5.1.2600p.2180 - and the registry key associated with the patch is entirely gone. The registry key is not as reliable a check of "fixed that vulnerability" as the file version is, so if you depended on registry keys to check for patches, you would unintentially keep XP SP2 boxes off your production network, even though they are not vulnerable to the buffer overflow described in MS03-026.
The settings discussed in this note are "positive" configuration tests, implemented into a CG Policy using CG "REQUIRE" conditions. You can use CG "PROHIBIT" conditions to block inappropriate endpoint properties, ranging from USB storage devices to recreational applications (KaZaA or PC games) to registry settings and processes created by known attacks (like Blaster).
Once you've set up your security requirements, you also need to configure endpoint remediation actions. These can range from a very manual redirect of all traffic to a specified Web server, containing patches, signature updates, and the information required for the end user to fix their machine themselves; to the download and installation of files completely transparently to your end users. These mechanisms are described in more detail in the online CGPM documentation. In addition,
TNG-0047 describes the configuration necessary to use an Apache or IIS web server as a remediation server for non-compliant endpoints.
There are a number of mechanisms included in the CG infrastructure that alllow you to test conditions and policies, as well as to gradually introduce policy enforcement into your production environment. Please consult the rest of the CG documentation and tech notes for more information.
Additional InformationUse of this document and web site are governed by the Terms and Conditions of Use for InfoExpress's web site.
