Patrolling the Configuration

After you have gone through a server and locked it down to your satisfaction, it is important to audit those settings against third-party tools to ensure that nothing was missed. It's also valuable to know that your network meets the standards of a well-recognized security entity such as the NSA or NIST.

With requirements like the Health Insurance Portability and Accountability Act (HIPAA) or Graham Leach Bliley Act (GLBA), many companies are now required to provide documentation to prove that they have taken the necessary steps to secure the sensitive information on their networks. Third-party analysis tools provide an objective and impartial assessment of network security. Although some assessment technologies are very thorough, they are no replacement for an audit by a reputable company that specializes in security audits .

Auditing the System Security

The event log is an excellent way to track activity on a server. The local security policy allows you to enable or disable various auditing events, which are explained in the following list:

• Audit account logon events. This setting audits each instance of a user logging on to or off of another computer in which this computer was used to validate the account. Account logon events are generated when a domain controller authenticates a domain user. The event is logged in the domain controller's security log. Similarly, logon events are generated when a local computer authenticates on a local user . In this case, the event is logged in the local security log.

• Audit account management. This setting audits each instance that a user account or group is created, changed, or deleted. It also generates events when a user account is renamed , disabled, or enabled. Password setting or changing is audited as well.

• Audit directory service access. This security setting audits each event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.

• Audit object access. This security setting audits the event of a user accessing an object, such as a file, folder, Registry key, or printer that has its own system access control list (SACL) specified.

• Audit policy change. This setting audits incidences of a change to user rights assignment policies, audit policies, or trust policies.

• Audit privilege use. This setting audits each instance of a user exercising a user right.

• Audit process tracking. This setting audits detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

• Audit system events. This setting audits when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.

Using the Microsoft Baseline Security Analyzer

The Microsoft Baseline Security Analyzer is a tool designed to determine which critical security updates are currently applied to a system. MBSA performs this task by referring to an XML (Extensible Markup Language) file called mssecure.xml. This file is continuously updated by Microsoft to account for all current critical fixes. By leveraging the HFNetChk tool technology MBSA is able to audit the target system against the current list of fixes. This XML file holds information about which security updates are available for particular Microsoft products beyond just the operating system. This file holds the names and titles of security bulletins as well as detailed information about product-specific security updates, including the following:

• Files in each update package

• Versions and checksums

• Registry keys that were applied by applications

• Information about which updates supersede others

• Related Microsoft Knowledge Base article numbers

MBSA and the Latest Copy of the mssecure.xml File

MBSA attaches to the Microsoft Web site to pull the latest copy of the mssecure.xml file. If a machine that will run MBSA does not have Internet access, you can download the XML file and place it on the machine running MBSA. Remember to update this file regularly to be aware of critical updates on the target systems.

Using Vulnerability Scanners

One of the most valuable methods for checking the security of a server is through the use of a vulnerability scanner. Vulnerability scanners are based on a constantly updated database of known security flaws in operating systems and applications. The scanner attaches to the target system on various ports and sends requests to the system. Based on the responses, the scanner checks its database to determine whether the conditions for an exploit exist on the system. These potential exploits are then compiled into a report and are presented to the administrator. Most vulnerability scanners have the option to do intrusive testing as well. Great care should be taken when performing intrusive testing. Intrusive testing is the only way to truly validate the results of the vulnerability testing. For example, a report item might list that a particular script is marked as executable via the Web services and that it could be exploited to cause the Web server to crash if it is passed a parameter containing a nonstandard character. You might believe that this is a false positive because you have assigned NTFS permissions to the script to only allow a single account to access the script; that account is one that you control and it can never send a nonstandard character. The only way to be sure would be to have the scanner attempt to exploit that apparent flaw. This would need to be done during a maintenance window in case the exploit succeeded. Only after performing this validation could you be certain that the vulnerability was not actually present.

Some popular vulnerability scanners are as follows :

• Microsoft Security Baseline Analyzer

• Internet Security Systems: RealSecure

• Nessus

• GFI LANguard Network Security Scanner

• Cerberus Internet Scanner (CIS)

Auditing the File System

Windows 2003 possesses built-in mechanisms to audit file system access. This enables you to see who is accessing or attempting to access specific files and when the access occurs. This type of auditing is only supported on NTFS drives . To audit this type of access, you must first enable the Object Access Auditing. This feature can be enabled via the Default Domain Security Settings, under Local Policies/Audit Policy/ Audit Object Access. As shown in Figure 1.5, set this to audit both Success and Failure in order to track both types of events. Follow these steps to audit access of a particular file or folder:

Figure 1.5. Setting the security auditing function.

1. Navigate via Explorer to the file or folder in question.

2. Right-click the item to be audited, click Properties, and then Security.

3. Click Advanced, and then click the Auditing button. Click Add. Enter the name of the group or user of which you would like to track the actions and click OK.

4. In the Apply Onto drop-down box, choose the location where you want the auditing to take place.

5. In the Access box, indicate what successes and failures you want to audit by selecting the appropriate check boxes.

6. Click OK, OK, and OK to exit when done.

Managing the Auditing on a Server

The role of managing the auditing on a server can be delegated to a nonadministrator account by granting the Manage Auditing and Security Log rights via Group Policy. This enables you to delegate this role without giving full administrator rights. This can be especially useful for remote site administrators who only manage a subset of servers and users.