Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Auditing Security Controls: Policy Compliance, Vulnerability Assessment, and Pen Testing

Determining security policy and implementing the technical controls that support it is not a trivial task. Keeping controls in place is harder. There are many reasons for this:

Security policy can change. Although this is not usually a rapid process, when a change is made, it can mean that a lot of configuration changes or procedural changes are needed. Security policy changes can result from legislative changes, internal or external audits, a better understanding of the technology or the risks inherent in its use for a specific purpose, or even management's acceptance of a proposed change from you.

Required changes to operating systems and applications (patches and upgrades) may reset configurations, return settings to their defaults, or require additional controls to be added.

New applications and OSs require additional controls or impact current systems. Controls may be weakened because these new implementations will not work with current controls in place. Replacement OSs and applications may not have the controls made available by others. New OSs and applications may also lack appropriate controls or may just be unfamiliar to staff and therefore require more work.

Tests and troubleshooting efforts may "temporarily" remove or change controls. (Someone may forget to change them back.)

Administrators authorized to make changes to technical controls make mistakes. Configuring security controls can be complicated, and sometimes vendor documentation and the language in the user interface can be confusing. For example, many security controls contain double negatives, such as when you "Enable" the "Disable …" setting in order to disable the setting. If you "Disable" the setting, you actually "Enable" what you may want to "Disable."

Many security controls rely on complex technologies to deploy, implement, or maintain them. The result is that a problem with these technologies, such as network communications, DNS, or Group Policy, means that the security control is not deployed or does not produce the desired result.

Keeping controls in place requires diligence, training, proper procedures, service, and application monitoring. To ensure that controls are in place, plan to periodically test for policy compliance, perform vulnerability assessment, and perform pen tests. Although all these things may come under the heading of proper network maintenance and appear to be part of your job description, be sure to acquire written authority, especially if you are scanning systems on your network or attempting to hack into systems. Also, be sure to thoroughly understand any tool that you use. Some vulnerability testing programs, scanners, and other tools may have adverse affects on systems simply by being used. For example, some control equipment for factory equipment or for use by utilities is now being managed over TCP/IP. Some simple scans of these products can cause them to fail, shutting down business-critical operations or interfering with critical infrastructure.

Auditing Security Configuration Using Security Configuration and Analysis

This book emphasizes the use of Group Policy to implement security settings across the Windows network. Optional ways of securing standalone systems using local Group Policy controls and/or Security Configuration and Analysis have also been discussed. To ensure that changes to these settings have not occurred, audit current settings against required settings. Manual inspection is possible, but a far easier way to audit policy settings is available: the "analyze" function of the Security Configuration and Analysis console.

To use the tool, you must have a security template prepared that matches the official security policy for the computer you are testing. Such templates may have been created if you used this method to define security when creating role-based security models. If this is not the case, you can still create a security template for use in analysis. It's not a good idea to use a template stored on a production server as this may be out of date or altered in some way. Instead, use a copy of the security template originally produced and stored in a safe place. In either case, make sure that the template used does match your policy by manually checking the template settings against your organization's current security policy. After you have the template, you can perform an analysis:

You can also use the secedit command to perform an analysis, but to review the report, you have to load the results in the Security Configuration and Analysis tool. To do an analysis, use this command:

secedit /analyze /db filenameofdatabaseforanalysis.sdb [/cfg securitytemplatename] [
/overwrite] [/log nameforlogfile] [/quiet]

In the command, the /overwrite switch will overwrite any existing file by the same name, and the /quiet switch will not echo any information to the screen. If you have already created a database file by importing a security template using Security Configuration and Analysis, and it includes the correct security template, you can leave off the /cfg switch.

TIP: Batch Analysis

Both Security Configuration and Analysis and the secedit command listed here will analyze only one computer at a time. You can create a script to use the secedit command on multiple computers and collect the results to a single location, such as a desktop PC, where it can later be analyzed and archived as proof of compliance or to create a list of systems that need to be updated.

Auditing Security Configuration for Specific Computers and Users

The use of Group Policy makes it possible to extend security configuration across the network to many Windows systems and to direct specific security settings for specific types of computers and users. You cannot assume that just because the settings are correctly defined, they are being correctly applied. Many things, such as network connectivity or Active Directory replication problems, can interfere. To audit these settings, you must inventory the applied settings on specific computers and for specific users. To do so, you can use RSoP in logging mode. This utility can reach out across the network and remotely examine the security settings for a specific user/computer combination.

To do RSoP logging, follow these steps:

Scanning for Known Vulnerabilities

In the correctly configured and properly patched network, scanning for known vulnerabilities is a waste of time. After all, correct configuration and patching implies an appreciation of known vulnerabilities and an effort to mitigate them. In reality, you cannot know with certainty that mitigation efforts have actually been implemented. Even if you perform each mitigation step yourself, you must use software to do so, and the software itself may have errors or may not work correctly in some circumstances. The very fact that you must apply patches to correct software bugs should prevent you from trusting any software-based effort to correct them.

Assessing Vulnerabilities with Microsoft Baseline Security Analyzer (MBSA)

Therefore, you must audit system configuration looking for known vulnerabilities. Microsoft Baseline Security Analyzer can perform basic vulnerability checking and is available for free at http://www.microsoft.com/technet/security/tools/mbsahome.mspx. This tool checks for major, well-known configuration vulnerabilities of Windows Server 2003, Windows 2000, Windows XP, and Windows NT 4.0. It also looks at IIS, SQL Server, Windows Media Player, and Exchange. Its primary purpose is to look for missing patches. Because patches are a response to vulnerability, a missing patch means the computer is vulnerable. Many fine third-party products go much further, providing extensive reporting capabilities that seek out evidence of the existence of known vulnerabilities. So, although MBSA's orientation is to provide information on which patches you need to add, many third-party products emphasize the specific vulnerability you need to protect the system against. To be fair, MBSA reports point to Microsoft documentation that describes what the patch protects you from, and many third-party products point to the Microsoft patch that will mitigate the vulnerability. By default, MBSA accesses an online database of patches that is kept up-to-date by Microsoft. If you use Microsoft Software Update Server (SUS) to provide patches tested and approved by your organization, you can point MBSA to the SUS server, and it will use its database of approved patches instead. If you do so, the audit will not report on missing patches that you have not yet approved for distribution to systems on your network. MBSA can be used to remotely scan multiple Windows systems, but there is a downside. MBSA is an agentless scannerthat is, no client-side software must be installed on clients in order to scan them. This means that MBSA requires that File and Printer Sharing be enabled on the client as well as the Remote Registry Service. Many security experts argue that these things should be disabled in order to protect the computer from possible compromise. Microsoft, however, has indicated that it believes having the ability to scan for missing patches far outweighs the risk posed by shutting down these remote access channels. You can mitigate your exposure by configuring IPSec to block access to these channels from all sources while allowing the computer used by MBSA to use them.

To use MBSA to scan computer(s), follow these steps:

MBSA reports are HTML-based files. It is not possible to examine a cross section of reports; they must be viewed one at a time. You can use a command-line version of the product to produce a text-based file. The text-based file will only include information on missing patches and not vulnerability assessment information. You can then import the files, one for each computer, into an Access or SQL Server database and use database queries to obtain information. For example, if you discover that patches are not being installed on some subset of computers, you can troubleshoot the patching problems by determining if the computers have anything in common, such as operating system and service pack level, computer role, location, and so on. You can also use a query to develop a list of computers that have not received specific patches and then use the list to get the job done.

To obtain a text file report on all the computers in the chicago.local domain and put it in the file scan1.txt, use this command:

Mbsacli /hf -d chicago.local -o tab -f scan1.txt

The /hf switch specifies that the HFNetChk syntax will be used. HFNetChk is the original tool developed by Shavlik (www.shavlik.com) for Microsoft. The /d indicates that a domain will be used for the search. The o specifies the output format, and the tab indicates a tab-delimited file. By asking for this type of format, the file will be easy to import into Access. The f specifies the file name. More information on command syntax and instructions on how to use mbsacli and Access to audit patch management are included in the article "Auditing Patch Management" published in Microsoft Certified Professional Magazine at http://mcpmag.com/columns/article.asp?EditorialsID=531.

Toward a More Comprehensive Vulnerability Scan

MBSA is not a full-featured vulnerability scanner. It is a useful tool for auditing patch management and for finding some of the more egregious errors in configurationthe errors that make Windows systems vulnerable to attack. A number of products perform a more comprehensive test. Some of these products, such as NMAP (http://www.insecure.org/), look for vulnerabilities on other operating systems and can provide you with an enterprise-wide picture. You should obtain a product that can be used to scan for vulnerabilities and that can be regularly updated. Keep the following points in mind when evaluating the results of a vulnerability scan:

Does the product offer advice on mitigation? In other words, does it tell you what to do to correct the error or reduce the chance that the vulnerability will be used to compromise your network?

Does the product do an in-depth analysis? For example, instead of reporting that a specific service (such as IIS) creates a vulnerability for your network, does the tool examine your implementation of IIS by looking at the mitigation you may have already put into place, such as IIS hardening?

Can you customize the product? You may want to add your own items that should be checked but that are not in the scanner's database.

Is the scanner updatable? New vulnerabilities are discovered all the time. Can the scanner's database be updated?

Is the scanner well known in the industry? Experienced scanner users may become important resources.

Can the scanner be configured to restrict it to scanning only specific computers? It's important to be able to focus the scan on a certain area of the network or to exclude specific computers, such as those that a scan might damage.

Penetration Testing

Hardening and non-invasive scanning can go a long way in protecting your network. Taking these steps can protect systems from attackers if the mitigation you apply really does perform as advertised. If you use the advice and information provided by known authorities, you can be reasonably sure that what you have done will mitigate vulnerability. However, you cannot be 100 percent sure that

In every case, on every machine, the "fix" is correctly applied.

Audits and scans are correctly reporting the status of systems.

Every system is properly evaluated.

Some new vulnerability or new way to attack your systems was not recently developed and thus mitigation is unknown.

You and your advisors know everything there is to know and everything there is to do.

These issues, of course, have no real solution. You will never be 100 percent secure, nor 100 percent sure that you have dealt with every issue. Still, you have to try every approach. Another way to detect flaws in your defenses is to perform (or have a third-party organization perform) a penetration test (pen test). Pen tests are active tests; they attack systems. Their goal is to compromise systems. Therefore, to get good results, make sure pen tests are performed by someone with no interest in proving that your organization's security is good. This is not to say that an authorized employee should not perform a pen test, but simply that she should not be the only one performing a test. Pen tests are now part of many audits performed by information security auditing firms. There are also many information security companies that also perform these tests. Carefully consider the experience and background of the organization and the individuals it uses to perform these tests.

WARNING: Do Not Perform Pen Tests without Written Authority

There is no way to determine "intent" when examining the results of an attack on a computer system. If you perform a penetration test, you are attacking a computer system. If you do not have written permission to test security in this way, you could easily find yourself accused of a crime.