Daily IT Matters, this is the place where I post my daily findings on IT.

Tuesday, October 31, 2006

Microsoft Network Certified Expert

Today I got my first certification of experts-exchange.
I achieved the Master Level in the Microsoft Network topic area.


Monday, October 30, 2006

How ISA Server 2004 Provides SSL VPN Functionality for Outlook Web Access and RPC over HTTP


I found this great article because at our company we needed to implement just this! read and weep...


How ISA Server 2004 Provides SSL VPN Functionality for Outlook Web Access and RPC over HTTP
Published: April 13, 2005

Remote access to resources hosted on the corporate network has become a requirement for organizations seeking to successfully compete in today’s Internet-connected business landscape. Off-site employees, home workers, traveling executives, and sales people all require anytime, anywhere access to information hosted on the corporate network. Because of these information needs, Microsoft Exchange Server is one of the most critical information resources that companies maintain on their corporate networks.

The challenge for IT and security professionals is to enhance the competitive position of their companies by providing remote access to Exchange Server resources in a private, secure, and reliable fashion.

Corporate IT departments traditionally arranged for network level VPN access to the corporate network. The problem with network level VPNs (based on the PPTP or L2TP/IPSec VPN protocols) is that they provide a private connection, but they don’t necessarily ensure a secure connection. Network level VPN access uses the native Exchange Server Remote Procedure Call (RPC) protocols to enable access to the entire array of Exchanger Server information resources. Remote access network level VPN connections make VPN clients virtual nodes on the corporate network. These VPN clients can then access resources on any server on the corporate network, using any protocol, in the same fashion as hosts directly connected to the Ethernet network. Like most of the directly connected hosts, these VPN clients don’t aggressively filter those connections at the VPN gateway.

This can have potentially disastrous results. In contrast to devices that never leave the well-managed corporate network, VPN client computers, by definition, are devices used for remote access and have likely been connected to unmanaged or poorly managed networks. This exposes them to viruses, worms, and spyware. These infected devices can then spread the malicious payload to any other device on networks to which they connect, including the corporate network through a network level VPN link.

There are many approaches you can use to mitigate these risks. An increasingly popular remote access method is the Secure Sockets Layer (SSL) VPN. With its ability to provide remote access to users on a per application basis, the SSL VPN offers the privacy of the network level VPN and adds a level of security that is difficult to obtain with traditional network level VPNs.

Unlike network level VPNs, where the primary differences between them are the control channel and encryption methodologies, SSL VPNs represent a diverse collection of significantly different remote access methods sharing SSL (actually TLS) as their common encryption method. Variants of SSL VPNs include:•
Reverse Web proxy for Web-enabled applications
This type of SSL VPN takes advantage of server applications that have built-in support for Web access to server hosted data. Microsoft Office Outlook Web Access is the best example of this type of application. Microsoft Internet Security and Acceleration (ISA) Server 2004 provides the reverse Web proxy for the Outlook Web Access site.
• Reverse Web proxy with application gateways for non-Web–enabled applications
For server applications that do not have native Web integration, some SSL VPNs include application gateways that translate data returned from the server application and reformat the server data dynamically so that it can be rendered in a Web browser.
• Application proxy for HTTP encapsulated client/server protocols
Some SSL VPNs enable client applications on the SSL VPN client to encapsulate or “wrap” the native server application protocol in an encrypted HTTP header (SSL). The encapsulated communications are sent to an SSL VPN proxy that “unwraps” the HTTP header and exposes the native application protocol and forwards it to the server. Outlook 2003 RPC over HTTP is an example of this type of SSL VPN, and ISA Server 2004 can provide reverse proxy for the encapsulated connection.
• Network extension
SSL VPNs that act like network level VPNs are referred to as network extension SSL VPNs. These SSL VPN implementations can make the SSL VPN client a virtual node on the corporate network and provide functionality for all protocols, including complex multi-connection application protocols.

While there are significant differences in the technologies used to implement the SSL VPN connection, all SSL VPNs share the following advantages of traditional network level VPNs:•
SSL VPNs enable VPN clients to connect through firewalls and NAT devices that do not provide outbound access for PPTP, L2TP/IPSec or IPSec tunnel mode connections to remote VPN servers.
• SSL VPNs represent a heterogeneous collection of remote access technologies that enable you to limit server and application access to users based on user credentials. This significantly mitigates the risk of users accessing resources they do not need to accomplish their work.
• SSL VPNs greatly simplify the end-user experience. Users don’t have to understand the issues involved with virtual network connectivity. Users are presented with clear and intuitive landing pages containing links to permitted resources.
• SSL VPNs can pre-authenticate users before forwarding connections to the back-end service. This prevents potentially malicious unauthenticated connections from reaching the back-end server.

SSL VPN gateways can perform application layer inspection of incoming and outgoing HTTP communications to help prevent attacks against SSL VPN gateway and Web services hosted by the SSL VPN gateway.

You don’t need to purchase dedicated SSL VPN gear if your company requires SSL VPN type access to Exchange Server resources. Microsoft has included SSL VPN functionality for remote access to Microsoft Exchange Server-hosted data through two core technologies:•
Integrated Web support for Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync
• HTTP protocol encapsulation of native Exchange Server RPC communications using the Outlook 2003/Exchange Server 2003 RPC over HTTP protocol.

ISA Server 2004 provides reverse Web proxy support and HTTP application layer inspection for both the integrated Exchange Server services communications and RPC over HTTP protocols.

Outlook Web Access SSL VPN Connectivity

With Outlook Web Access (OWA), users can access Exchange Server hosted information through any Web browser. The Exchange Server 2003 version of OWA provides a very rich user experience that closely mirrors the interface seen with Microsoft Office Outlook 2003. OWA in Exchange Server 2003 provides access to almost all features and data that would be accessible using the full Outlook 2003 client.

ISA Server 2004 can be combined with OWA to provide the enhanced security seen with full- featured SSL VPN solutions:•
Clientless remote access to Exchange Server hosted resources.
• The ability to tunnel through firewalls that do not allow outbound access for traditional network level firewalls.
• Strict limitation over what corporate resources can be accessed through the SSL VPN. OWA allows access only to Exchange Server services.
• Application layer inspection of the encrypted HTTP commands and data moving through the ISA Server 2004 firewall to the Exchange Server. The SSL to SSL bridging feature of ISA Server 2004 enables application layer inspection of data that would otherwise be hidden inside the encrypted SSL tunnel.
• ISA Server 2004 provides an attractive and intuitive landing page that makes it clear to the user that they are entering the OWA Web site.
• ISA Server 2004 is able to pre-authenticate users before forwarding the connection to the connection to the OWA Web site.
• The forms-based authentication feature included with ISA Server 2004 can enforce connection timeouts, log the user out when the user leaves the OWA Web site, and prevent downloading of attachments.

All these features make connections to the OWA Web site through an ISA Server 2004 firewall virtually indistinguishable from what would be attained with a dedicated SSL VPN device.

Outlook 2003 RPC over HTTP to Microsoft Exchange Server 2003

Outlook 2003 has the ability to encapsulate the native Exchange Server RPC protocols that the full Outlook MAPI client normally uses to communicate with the Exchange Server. The native RPC communications are encapsulated in an encrypted HTTP header (SSL) and then forwarded to an RPC over HTTP proxy on the corporate network. The RPC over HTTP proxy removes the HTTP header and forwards the native RPC protocol communications to the Exchange Server. After the Exchange Server sends responses to the RPC over HTTP proxy, the proxy re-encapsulates the RPC communications in an encrypted HTTP (SSL) header and returns the response to the Outlook 2003 client.

Although the RPC over HTTP solution does not meet the clientless aspect of SSL VPN connectivity, it does provide many of the other features seen with dedicated SSL VPN connections:•
RPC over HTTP can tunnel through firewalls that do not support traditional network level VPN connections.
• Outlook 2003 users are allowed access only to Exchange Server services.
• ISA Server 2004 can perform reverse proxy for the RPC over HTTP communications.
• ISA Server 2004 can perform application layer inspection of the HTTP communications between the Outlook 2003 client and the HTTP over RPC proxy.
• Pre-authentication of the RPC over HTTP connection can take place at the ISA Server 2004 firewall. This can prevent possible attacks against the RPC over HTTP proxy from unauthenticated users.

Like remote access to the OWA Web site, the combination of Outlook 2003, Exchange Server 2003, and ISA Server 2004 provides SSL VPN connectivity without requiring dedicated SSL VPN servers.


Traditional network level VPN connections can provide remote access clients a private but not necessarily secure connection to the corporate network. SSL VPN technologies are becoming increasingly popular because they provide private connections for remote access clients using SSL encrypted communications, and they enable access only to resources that are required for users to accomplish their work. Outlook Web Access and Outlook 2003 RPC over HTTP client connections to Microsoft Exchange Server 2003 provide many of the privacy and security features seen in dedicated SSL VPN device implementations.

See other Security MVP Article of the Month columns.


RoboCopy GUI [for Admins!]

Robocopy is one of my top ten tools I have been using for years. I often recommend it to people asking how to migrate fileservers, copy files over the network, pretty much anytime you need to copy more than a few files. Now robocopy is pretty powerful but it is a command line tool and there are still a lot of people who prefer the point and click ease of the GUI. Well now Robocopy has a GUI! You can download Robocopy GUI



Sunday, October 15, 2006

Can I prevent my employees from installing Google Desktop?

Can I prevent my employees from installing Google Desktop?
Google Desktop supports a group-policy flag in the registry to limit or prevent installation. An administrator can control installation by configuring the "minimum_allowed_version" and "maximum_allowed_version" values under the "HKLM\Software\Policies\Google\Google Desktop\Enterprise" subkey.

These two values control which Google Desktop versions are allowed to install. Google Desktop versions are expressed with numbers corresponding to the build date, such as 2.2005.0401.0600. To see the version number, just click on the "About" link on the Google Desktop page for the given installation.

To limit the version, configure the minimum_allowed_version and maximum_allowed_version values (type:REG_SZ) using the version number.
To completely prevent installation, configure the maximum_allowed_version value to ""

After an administrator implements this group policy, a user attempting to install a non-approved version will see the following message: "Your Administrative Policy does not allow this version of Google Desktop Search."

If you see this message and would like to install Google Desktop, please contact your system administrator for assistance.


Active Directory Limits

below is taken from a technet blog!


I've been doing a bit of research around the theoretical limits in an AD environment as part of a project I'm working on. It's unlikely that many people will ever actually hit these limits (if you do, you probably need to take a fundamental look at your infrastructure architecture and how you support it!) but I thought I'd post them anyhow - they may be useful to someone somewhere :-)
- maximum number of GPOs that can apply to a user/computer: 999
- maximum number of DNS servers in an AD-integrated zone (without manually adding the details): 850 (Windows 2000), 1300 (Windows 2003)
- maximum number of supported DCs in a given domain: 1200
- maximum number of members of a group: 5000 (Windows 2000), unlimited in Windows 2003
- maximum number of DHCP servers in a forest: 850 (Windows 2000 SP1 or RTM), unlimited (Windows 2000 SP2 or later and Windows 2003)
- maximum number of UPN suffixes that can be set through the UI: 850 (you can set more if you need to via ADSI scripts)
- maximum number of objects that can be created over the lifetime of a given DIT (i.e. the AD database on a given DC): 2 billion


Saturday, October 14, 2006

How to use Windows Vista’s Boot Manager to boot Linux

The Web is full of explanations on how to dual boot Windows and Linux using a Linux boot manager like GRUB or LILO. If you want to dual boot Windows Vista and Linux using Windows Vista’s Boot Manager, please read on. I will assume that you already have installed Linux on your machine using GRUB as your boot loader.
Step 1 – Install GRUB on the Linux partition (outside of MBR)
As Windows Vista will replace the Master Boot Record (MBR) with its own, we need to relocate GRUB elsewhere by running grub-install with the Linux partition as a parameter.
• On Linux, launch a Terminal with root privileges
• Find the name of the partition Linux is installed on by running fdisk –l (the partition you’re looking for is the one whose system is Linux, can be something like /dev/sda1 or /dev/hda1. For the rest of this post, I’ll use /dev/sda1)
• Install GRUB on the Linux partition by running : grub-install /dev/sda1
Step 2 – Get a copy of Linux boot sector
We will need to instruct Windows Boot Manager how to boot correctly Linux using Linux boot sector, which we will extract using dd.
• On Linux, launch a Terminal with root privileges
• Take a copy of Linux boot sector : dd if=/dev/sda1 of=/tmp/linux.bin bs=512 count=1
• Copy linux.bin on a FAT formatted USB key or any storage accessible from Windows Vista
Step 3 – Install Windows Vista
Step 4 – Configure dual booting in Windows Vista
We will create an entry for GRUB in Windows Vista boot configuration data store using bcdedit.
• On Windows Vista, launch a command prompt with administrative privileges (by right clicking on cmd and choosing Run as Administrator)
• Copy Linux boot sector on the root of the Windows boot (active) partition, namely the one containing bootmgr. If you don’t know for sure you can use diskpart or diskmgmt.msc to find out which one it is.
• Create an entry for GRUB :
o bcdedit /create /d “GRUB” /application BOOTSECTOR
o Note: bcdedit will return an ID for this entry that we will call {LinuxID} below. You will need to replace {LinuxID} by the returned identifier in this step. An example of {LinuxID} is {81ed7925-47ee-11db-bd26-cbb4e160eb27}
• Specify which device hosts a copy of the Linux boot sector
o bcdedit /set {LinuxID} device boot
• Specify the path to a copy of the Linux boot sector
o bcdedit /set {LinuxID} PATH \linux.bin
• Add Linux entry to the displayed menu at boot time
o bcdedit /displayorder {LinuxID} /addlast
• Let the menu be displayed 10 seconds to allow for OS selection
o bcdedit /timeout 10
I want to thank Pascal Sauliere and Mathieu Malaise for help on Linux/GRUB and for helping research bcdedit options.

Thursday, October 12, 2006

Virtual PC 2007 Beta

The Virtual PC 2007 Beta is now available to download, with Windows Vista support! - sign up for it here

Some of the major changes include:
Support for hardware virtualisation (both Intel & AMD)
Support for Windows Vista as a host operating system
Support for Windows Vista as a guest operating system
Improved performance
There are bug fixes as well, some of the interesting ones are:
Lots of work to allow Virtual PC to play better with laptop power management
Fix for IntelPPM issue
Virtual PC now supports greater than 2.2GB ISO images

Tuesday, October 10, 2006

Fight Spam on Your Terms with Custom Weight Lists

Fight Spam on Your Terms with Custom Weight Lists
At A Glance:
Custom Weight Lists
The Intelligent Message Filter
How to filter messages to stop spam
How to search text appropriately

Spam, as we all know, is a huge problem. It clogs up your servers, aggravates your users, sucks up your bandwidth, and communicates unwanted and often inappropriate messages.

Can anything be done to stop it?

Well, if you're running Microsoft® Exchange Server 2003 you may have noticed that new features and functionality released last October in Service Pack 2 (SP2) significantly improved its ability to withstand different vectors of spam attacks. With multiple layers of anti-spam defense, Exchange Server 2003 can provide strong protection against unwanted messages. One of the most important elements in the Exchange anti-spam framework is the Intelligent Message Filter (IMF), which enables content filtering during the last stage of server anti-spam processing. Inside IMF, a little-known module called the Custom Weight List (CWL) turbocharges the anti-spam efforts of SP2. Let's take a look at what it does and how to use it.

What is a Custom Weight List?

The CWL is an XML file that contains a number of words or phrases that, if found in the body or subject of the message, can trigger modification of the final spam confidence level (SCL) assigned by the IMF. They are called Custom Weight entries and they look like this:
<?xml version="1.0" encoding="utf-8"?>
<CustomWeightEntries xmlns="http://schemas.microsoft.com/2005/CustomWeight">
<CustomWeightEntry Type=" " Change=" " Text=" " />

As you can see, there are three attributes related to examining an e-mail message for a word or phrase match: Type attributes, Change attributes, and Text attributes.

The Text attribute comes last for each entry, but it is the content the IMF will be looking for in the e-mail. This attribute can be a single word or a phrase, and it can contain escaped characters, upper ASCII characters, or double-byte characters, and any Unicode word or phrase up to 1000 characters long. There can be multiple Text attributes in a CWL file. One of the most common uses of Text attributes is to block adult-oriented advertising based on keywords in the message subject and body.

Where the IMF will look is determined by the Type attribute, which can be SUBJECT, BODY, or BOTH (indicating the part of the e-mail your Text should be matched against). Use one of the following Type attributes to specify that a search for a match will be performed on the subject of a message, the body, or both:
Type = BODY
Type = BOTH

The Change attribute can be any integer value (positive or negative). This attribute defines how the SCL value of the message will be changed if the Text attribute is matched. If a match is found, the value of the Change attribute will be added to the original SCL value (or essentially subtracted, if the Change attribute value is negative). If the combined (original and CWL) values exceed the SCL range, the final SCL assignment will be normalized between 0–9. Change can also use the MIN and MAX keywords. Any time a phrase with the MIN keyword is matched, the message is given an SCL of 0 regardless of any other weights. Any time a phrase with the MAX keyword is matched, the message is given an SCL of 9 regardless of any other weights. If there's a match for both MIN and MAX, the message is given an SCL of 0. To ensure that a mail item with matching characteristics will be blocked, use the MAX keyword.

SCL values for mail items fall between 0 and 9, with 0 indicating the least likelihood that the message is spam and 9 indicating the most. There is an additional value of "-1" (reserved by Exchange Server), which implies that the mail came from a trusted, authenticated source (another authenticated Exchange Server) and as such it is exempt from the anti-spam processing. Use of this value is enabled by default; to disable it, please read the Intelligent Message Filter Operations Guide at go.microsoft.com/fwlink/?LinkId=71143. Figure 1 shows how to interpret the SCL values.

Custom Weighting

As noted earlier, the IMF comes into play during the last stage of anti-spam processing. After a mail item passes through the layers of the Exchange Server 2003 anti-spam framework (such as the Connection and Protocol Filtering layers), it becomes a subject for IMF verification. IMF processes the mail item and assigns the appropriate SCL. The mail is then examined by the CWL to see if there is a match with any Custom Weight entries. If a match is found, the Change attribute is applied to the SCL value of the message. Hence, the Final SCL assignment looks like this:
Final SCL == original IMF SCL + CWL Change attrib.

The Custom Weight entries are loaded into memory when the IMF is starting up; any changes to the CWL file require a restart of corresponding Exchange and SMTP services to get the new entries loaded into memory. The entries are stored as hashtables to allow fast look-up for both single word and phrase matches while only parsing messages a single time.

Using the Custom Weight List

If you're under a spam attack and the offending mail items have a consistent phrase in their subject line, you can add that part of the line to your CWL entries, as shown here:
<CustomWeightEntry Type="SUBJECT" Change="MAX" Text="Bad Subject" />
This would ensure that any time a message with the subject line "Bad Subject" is encountered, the message's SCL would be forced to 9 and the message would be blocked.

On the other hand, if IMF is incorrectly classifying a message as spam, you can rescue that message. Suppose, for example, an auto-generated build status mail with the subject line "Build System Daily Mail" is getting blocked. You can add the following CWL entry:
<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="Build System Daily Mail" />
This would ensure that such mail would get an SCL of 0 and would not be blocked.

If you have a list of key words or phrases that you want to use as modifiers to increase or decrease the SCL of a message, you can simply add them to the CWL entries. The following example illustrates that the word pear should be seen as a spam indicator in the subject; orange should be a spam indicator in the subject or body; banana should indicate good mail when in the body; and strawberry should indicate good mail when in either subject or body:
<CustomWeightEntry Type="SUBJECT" Change="3" Text="Pear" />
<CustomWeightEntry Type="BOTH" Change="5" Text="Orange" />
<CustomWeightEntry Type="BODY" Change="-2" Text="Banana" />
<CustomWeightEntry Type="BOTH" Change="-4" Text="Strawberry" />
After encountering the appropriate match, the IMF will adjust the final SCL value set on the message.
Order of Precedence

What happens when you have a mix of positive and negative weights, along with some MIN and MAX weights in your Custom Weight entries? If, by mistake, you assign the MIN and MAX keywords to the same Custom Weight entry, MIN takes precedence and the final SCL assignment is 0. This is done to prevent accidental message blocking due to CWL file misconfiguration. Precedence works as follows:
If an entry with MIN change is matched, the SCL of the message will be 0.
If an entry with MAX change is matched and there is no MIN token, the SCL of the message will be 9.
If no MIN or MAX entries are matched, then the SCL of the message will be the SCL determined by the IMF plus the change of any matched Custom Weight entries.

For example, suppose you have the following Custom Weight entries:
<CustomWeightEntry Type="BODY" Change="MIN" Text="hello" />
<CustomWeightEntry Type="BODY" Change="MAX" Text="world" />
<CustomWeightEntry Type="BODY" Change="1" Text="Internet" />
<CustomWeightEntry Type="BODY" Change="-3" Text="place" />
Let's see what happens if the incoming mail contains the following string in the message body: "Hello world and welcome to the Internet place". The IMF returns an SCL of 4 but the final SCL assignment would be 0. This is because the word "hello" has been matched and that entry has a MIN change keyword. None of the other entries are taken into consideration at this point.

Now let's see what happens if the message body contains the string "Welcome to the world and the Internet place." Regardless of the value originally produced by the IMF, the final SCL value would be set to 9 because the Text attribute value "world" was matched and the entry includes the MAX keyword. As there is no MIN entry to override, the message will be given an SCL 9 and blocked.

Here's another interesting example. Let's say the message body contains the "world Internet place" string and IMF returned an SCL of 6. What would be the final SCL assignment? It would be 4: the original SCL 6 from IMF plus 1 because of the "Internet" entry match and -3 because of the "place" entry match.

Substrings, Phrases, and URLs

CWLs will not match an entry to a substring of a word, but will match a shorter phrase to part of a longer phrase. Say you want to block mail with "Free Watches" in the subject line, so you put the following Custom Weight entry in your CWL file:
<CustomWeightEntry Type="SUBJECT" Change="MAX" Text="watch" />
This will not work as intended. You won't hit the CWL since "watch" is only a substring of "watches". You would need to explicitly include the word "watches" or the whole phrase "Free Watches".

Now suppose, based on this example, you've changed the Custom Weight entry from "watch" to "Free Watches" and your string looks like this:
<CustomWeightEntry Type="SUBJECT" Change="MAX" Text="Free Watches" />
If the subject of the e-mail is "Get your Free Watches Now!!!", you'd have a match. This is because the phrase in the CWL file will be matched against the part of the phrase found in the subject.

Now let's say you have the following URL in your custom weight entries:
<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="microsoft.com" />
This token would match against the following subjects:

This is due to the way custom weighting tokenizes the phrases it sees. In essence, the phrases are split into words any time there's a break in the character type from alphanumeric to anything else: spaces, tabs, commas, periods, slashes, and so on. (Whitespace, though, is different. It is thrown away, while any of the punctuation characters become a word in the phrase.)

In this example, www.microsoft.com gets translated into a five-token phrase—www, period, Microsoft, period, com. The Custom Weight entry gets translated into a three-token phrase—Microsoft, period, com. The Custom Weight entry is now a match to part of the phrase of the subject.

Special Cases

Since the Custom Weight entries are stored in an XML file, there are certain characters that can't be used in a search entry without encoding. For example, if you wanted to block e-mails that contained the phrase "<Hello>", then your Custom Weight XML would contain the following entry:
<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="&lt;Hello&gt;" />

CWL functionality supports Unicode characters in the CWL file. The actual custom weighting process is language agnostic—as long as the word or phrase in the entries matches a word or phrase in the e-mail being processed, then the Custom Weight will be used. So the Custom Weight entries in Figure 2 are perfectly legit.

There are, however, a few caveats to using high-ASCII and double-byte characters. First, you need to make sure you have the correct encoding in your Custom Weight XML header and that the file is saved as the correct encoding.

Second, the e-mail you are checking needs to be properly encoded. If the MIME type of the e-mail is incorrect or the wrong character-encoding is specified, the IMF might not be able to process the Custom Weight entries correctly.

Third, due to the way strings are tokenized in custom weighting, phrases with double-byte characters, especially East Asian languages, are tough to create for use with the CWL file. This is because the punctuation and whitespace characters used to tokenize many European languages don't match up well. If you are setting up your CWL to be used with double-byte characters, make sure to give it a round of testing to find a correctly matching Custom Weight entry.

Wrap Up

When you're ready to use the CWL file, remember that, by default, the Exchange Server 2003 SP2 installer does not create it for you. You'll need to do this manually (see the Intelligent Message Filter Operations Guide mentioned earlier for details). And don't forget that the CWL file, MSExchange.UceContentFilter.xml, should always be in the working path of IMF, as shown in Figure 3.

Figure 3 The Working Path of IMF (Click the image for a larger view)

If the CWL file is not located in the IMF's working directory, it will not work. If you have custom weighting deployed and are using IMF Updates, make sure that every time new spam definitions are installed, the CWL file is moved to the new IMF location. You'll have to do this manually. The Intelligent Message Filter Operations Guide provides detailed information how to enable IMF Updates and what you need to do to ensure that the Custom Weight List continues to operate successfully.

Cam Frenette is a Software Design Engineer in Test at Microsoft who focuses mainly on anti-spam technologies for the Technology Care & Safety team. He holds a B.Math from the University of Waterloo.
Alexander Nikolayev is the Program Manager at Microsoft in charge of server-side protocols, Transport Core, and anti-spam components for Exchange and Windows Servers. Alexander holds an MBA degree from the University of Mary. Read his posts on the Exchange team blog blog.
From the October 2006 issue of TechNet Magazine.

Windows Time and the W32TM service

Windows Time and the W32TM service

Nathan Winters

In the last few days this issue of time sync in Windows domains has come up a few times both at work and on the Minasi forum of which I am a member. Each time there has been confusion as to exactly how time sync occurs in a Windows domain.Therefore, I decided that I would put this article together in order to try to provide a decent answer as to what is going on and how to troubleshoot any issues that arise.

The first thing about Time Sync in Windows is to realise that it is a little different between Windows 2000 machines and Windows XP/2003 machines. This is because in Windows 2000 the Simple Network Time Protocol (SNTP) was used and was configured with the NET TIME command. Now, with XP and 2003, Network Time Protocol (NTP) is used which give benefits such as more reliable time due to better correction methods. This is configured using the new W32TM commands which we will look at later on.

To start with, however, I will look at the principles that remain the same for both Windows 2000, 2003 and XP computers/domains.
Time Sync Principles
Why time sync:
The first question that we need to ask ourselves is why do we need time synchronisation? Well, in an Active Directory domain, it is very important for all clocks to be within 5 minutes of each other (by default) due to the implementation of the Kerberos protocol for authentication which relies on time stamped packets to prevent amongst other things, man-in-the-middle attacks. Another reason time sync is important for is because now Active Directory uses multi-master domain controllers (DCs) it is important that changes made at a later actual time on one DC don’t get overwritten by similar changes on another DC whose time is set wrong thus making it look like the most recent change!

What is Network Time Protocol
Network Time Protocol (NTP) is the default time synchronization protocol used by the Windows Time Service (WTS) in Windows Server 2003 and Windows XP. It should be noted that this is different from Window 2000. As I will mention in the Windows 2000 specific section later on, Windows 2000 used the Simple Network Time Protocol (SNTP) to do time sync. However, for now we will talk about NTP as is contains all the functionality of SNTP and more!

NTP time synchronization takes place over a period of time and involves the transfer of NTP packets over a network. NTP packets contain time stamps that include a time sample from both the client and the server participating in time synchronization.
NTP relies on a reference clock to define the most accurate time to be used and synchronizes all clocks on a network to that reference clock. NTP uses Coordinated Universal Time (UTC) as the universal standard for current time. UTC is independent of time zones and enables NTP to be used anywhere in the world regardless of time zone settings.

What are we configuring within Windows
The Windows Time Service (WTS), that’s what! As you can tell from the name, this is a service that runs on Windows machines and understands and implements network time sync using NTP. To enable the WTS to be flexible, it works by using plug in time providers. This allows it to support both hardware and Internet based time sources.

The NTP provider is the standard time provider included with Windows Server 2003. The NTP provider follows the standards specified by NTP version 3 for a client and server, and can interact with SNTP clients and servers for backward compatibility with Windows 2000 and other SNTP clients.

The NTP provider in the Windows Time service consists of the following two parts:

NtpServer output provider. This is a time server that responds to client time requests on the network.

NtpClient input provider. This is a time client that obtains time information from another source, either a hardware device or an NTP server, and can return time samples that are useful for synchronizing the local clock.

The Windows Time service is implemented in a dynamic link library called W32Time.dll. W32Time.dll is installed by default in the Systemroot\System32 folder during Windows Server 2003 setup and installation.

Time Protocol Interoperability
As is often the case with developments in the Windows environment, the new technology can still talk to the old. In this case, this means that the Windows Time service can operate in a mixed environment of computers running Windows 2000, Windows XP, and Windows Server 2003, because the SNTP protocol used in Windows 2000 is interoperable with the NTP protocol in Windows XP and Windows Server 2003.

Time Sync Hierarchy and Stratum:
The degree to which a computer’s time is accurate is called a stratum. The most accurate time source on a network (such as a hardware clock) occupies the lowest stratum level, or stratum one. This accurate time source is called a reference clock. An NTP server that gets its time directly from a reference clock becomes part of a stratum that is one level higher than that of the reference clock. Resources that get time from the NTP server are two steps away from the reference clock, and therefore are part of a stratum that is two higher than the most accurate time source, and so on. As a computer’s stratum number increases, the time on its system clock may become less accurate. Therefore, the stratum level of any computer is an indicator of how closely that computer is synchronized with the most accurate time source.

Windows 2000/3/XP ensures time is synchronised correctly within a domain by setting up a time sync hierarchy which follows the model above. The Primary Domain Controller emulator (PDCe) of the forest root is the Master Time Server (effectively stratum 1 for the network, although you could see this as stratum 2 as the PDCe also syncs with a more accurate clock). Other DCs then sync with the PDCe and clients and member servers sync with their authenticating DC. Therefore you have one point of “Reliable Time” in the enterprise, the root PDCe. So you might now be asking; what should I sync the root PDCe to?

Well, there are several choices; you don’t have to sync the box at all! So long as all the machines within your network share the same time, it doesn’t matter what time it is (unless you use time for other purposes). However, since you are likely to want the correct time on all your machines the other options are, either to sync the root PDCe with a hardware clock or to sync it with a public time server on the Internet.
Once you have setup the PDCe to sync with an external time source then what happens? Well, it tries to sync every 45 minutes until it achieves its first sync. Then after that, it syncs again every 45 minutes until it has done three successful syncs in a row. After that it syncs once every 8 hours.
You should also note that if the time is more than 3 minutes out then the w32time service will use a process of gradual adjustment to bring things into line rather than simply changing the clock immediately.
Reliable Time Source Configuration
If a domain controller is configured to be a reliable time source, in other words, it syncs with an external time source, the NetLogon service announces that domain controller as a reliable time source when it logs on to the network. When other domain controllers look for a time source to synchronize with, they choose a reliable source first if one is available. When a DC is intended to be a reliable time source you should ensure that the following registry key has a value of 5 if not then the default value 10 should be left in place.



Windows 2000 Time Sync
I am now going to look at how you setup your Windows 2000 machine to sync over the Internet and what protocol Windows 2000 uses to do this. As mentioned briefly above, this is one of the differences between Windows 2003/XP and 2000. The protocol used for Windows 2000, is called Simple Network Time Protocol or SNTP. It is a “simple” version of NTP and lacks some of the more complex algorithms which provide more accurate and stable time for NTP clients. The way you set this up is to use the command line to enter the following:
NET TIME /SETSNTP:dnsnameofserver
For example, you could use the following:
NET TIME /SETSNTP:time.window.com
If you what to find out which server you setup a machine to sync to you can use the following command:

Windows 2003 uses W32TM not NET TIME
As I mentioned above, Windows Server 2003 and Windows XP now use NTP instead of SNTP. Alongside that they now have a new way of configuring the WTS. The command that now does everything regarding WTS is:


So how do we use it? Well, the first thing to look at is the “/config” parameter. This does a few things. It allows you to use “/computer” to specify which computer you are setting up. The default setting is the local machine but it is nice that you can administrate time on remote computers too! It also allows you to tell the WTS that its config has changed and that it should apply the changes by using the “/update” switch. However, the two most important parameters are:

These parameters tell the computer whether or not to look for a time server within an Active Directory hierarchy or whether it should sync from and external source and then, if so, what that source is! What these parameters actually do is control a registry entry called "Type" in:
This key is either set to "NT5DS" if you're in an AD, or "NTP" if you're either not an AD member, or if you're the root domain's PDCe. Actually, this key could also be set to “NoSync” to prevent any time sync taking place.
To tell a system's W32Time service to get its time from the Active Directory, type
w32tm /config /syncfromflags:domhier /update
This does two things. First, it sets that Type value to "NT5DS." Second, it notifies the w32time service that settings have changed.
If the system is not a member of and AD or is the root PDCe then change two things. First, the value of the “/syncfromflags” option changes from "domhier" to "manual" which changes the “Type” value from "NT5DS" to "NTP". Second, add the “/manualpeerlist:” option, to tell it where to sync from. Adding the “/manualpeerlist:” actually adds the entry specified to another key under the location above. The key is called “NTPServer”.
For example, to tell your system that it should do its own time sync from time.windows.com, type:
w32tm /configure /manualpeerlist:time.windows.com,0x1 /syncfromflags:manual /update
Note: if using a DNS name for the time server then it is important to add the 0x1 to the end. If using and IP address this can be omitted.
After making any changes to the w32time service configuration you should restart the W32TIME service. This can be done from a command prompt as follows:
net stop w32time && net start w23time
After issuing either of these commands, you should tell your system to update its time with the following command:
w32tm /resync /rediscover
So that gets you the basics setup for a Windows Server 2003 or Windows XP machines.
To see a list of all the commands you can use with w32tm, type:
W32tm /?
Locating Time Servers:
By the way, if you are wondering where to find time servers to sync with I would recommend that you look into the NTP pool project which in its own works does the following:
“The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers.”
For more info see http://www.pool.ntp.org
One tip that may be useful to someone during the search for a timeserver is this; if you think that a machine is running a time server then try the utility ntpquery.exe found at the following link:
Point it at either a DNS name or IP address and if it returns box like the one in the screenshot below, then you have found a time server!

Another way to verify whether a machine is a time server is to use the w32tm /monitor command. This can be used as follows:
W23tm /monitor /computers:uk.pool.ntp.org
w32tm /monitor /computers:uk.pool.ntp.org
uk.pool.ntp.org []:
ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
NTP: -4.9009063s offset from local clock
RefID: utserv.mcc.ac.uk []

You should get output similar to the above. In particular the NTP: line which shows that my clock is 4 seconds behind the online time server.

Best Practice:
Preventing Large Time Changes
As I have already stated, it is highly recommended to setup your root PDCe to sync with an external time source of some sort. However, having done this, you are then open to a possible problem caused by an error with the clock you sync to. If something were to go wrong and the time were to change dramatically on your external clock your root PDCe would by default follow this time change and apply it. This would then filter all through you domain which obviously would be a bad thing!

To prevent this you should configure the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. From Microsoft sources on the Internet, it would appear that the recommended value is 900 seconds (15 mins). I would suggest that having a 15 minute time change occur on your network is likely unacceptable. I would therefore recommend setting this interval for 300 seconds so that the time change internally is never greater than 5 minutes. This should help to prevent problems if a large change was received which then prevented Kerberos authentication working as some machines would have a time difference of greater than 5 minutes before full time sync could occur.

If you are particularly worried about this type of problem then you could also set the values for your internal systems as well as for your root PDCe. For a little more info about these keys, including where to find them, look in the table below:

Obviously the above also means that if your clock were to get a long way out then correction wouldn’t be automatic. In this case you should monitor the time of your network fairly regularly and also set the value of the MaxPollInterval registry entry to 10 or less, or that you set value of the SpecialPollInterval registry entry to 3600 (1 hour) or less to enable frequent time checks.

As with all these setting changes for more information have a browse of the Windows Time Service Technical Reference which can be found through the link below:


Troubleshooting Time Sync
The first thing to note about troubleshooting is that in Windows 2000, there is not much logged to the event log. However, this is changed with 2003 so your first step would be to check out the messages logged there.

In order to really see what is going on, you should then look to make use of w32tm and investigate the relevant registry keys mentioned above. Finally you can also enable debug logging for the w32time service. Whilst this can be useful, it does output a large amount of information of which lots may be unintelligible. It is for this reason that it is often useful only when working with MS PSS to solve your problem.

My Troubleshooting steps:
Here are the steps I take when troubleshooting Time Sync issues on a PDCe box.

1. First I will investigate the forest structure looking at how many domains and DCs exist. Then on one of the DCs I will install the Windows 2003 support tools and type

netdom query fsmo

2. This will locate the holders of the FSMO roles and allow me to find the server holder the PDCe role.

3. I will then verify with replmon that good replication is occurring within the forest.

4. I will next use the NTPQuery utility mentioned above to verify that the time.windows.com time server can be accessed from the machine. This will verify that the relevant ports are open. Another way of doing this would be to use portqry as shown below which should return a Listening or Filtered output

portqry –n time.windows.com –e 123 –p UDP

5. Next I will open up regedit and locate the registry key below. Once there I will check that the desired time server is configured and that if a DNS name is used the ,0x1 suffix is used:


6. I will next attempt to ping the server that is referred to. Although this is not always possible due to settings at either end, it does provide a clear indication that the server is available. Another way to get this verification would be to use the portqry command above.

7. Open Registry Editor (regedit.exe) and configure the following registry entries so that it is set to NTP not NT5DS:


8. Whilst in the registry ensure that the registry key below has a value of 5.


9. Now stop and restart the Windows Time service using the following command:

net stop w32time && net start w32time

10. Next re-sync the w32time service using the following command:

w32tm /resync /rediscover

11. Next check in the system event log to see if errors are still logged. If the above has fixed the problem then you should now receive an event ID of 35 logged by the w32time service.

12. If you still have errors then reboot the server.

13. Then in the registry point the time server to the same time source as above but use the 0x8 flag instead of the 0x1 flag to force W32time to send normal client requests.

14. Restart the w32time service as shown above and check the event log. If errors continue carry on as follows.

15. Check the Default Domain Controllers group policy and the Default Domain group policy and any others that could affect the PDCe or other DCs. Check the following areas:

Computer configuration/Administrative Templates /System/Windows Time service/Time Providers

Ensure that all three settings listed are set to “not configured”.

16. Now stop and restart the Windows Time service using the following commands:

net stop w32time && net start w32time

17. At this point check the system event logs and you should see event id 35
18. If you are still having problems then as a final attempt, you can un-register and re-register the w32time service. This will clear out all configurations and let you start again from scratch. The details of how to do this are in the next section titled “Other useful w32tm commands”.
Other useful w32tm commands:
A couple of other w32tm commands that may well be useful in your troubleshooting are as follows:

W32tm /unregister
W32tm /register
W23tm /dumpreg

The first command will remove all w32time service registry keys and settings and un-register the w32time service. This effectively wipes all configuration from the machine.

The second command will register the service and set it up with default settings ready for your configuration.

The third command is useful for both documentation and reporting to PSS as it enables you to export the contents of the w32time registry key. To be honest though, I find it easier to use regedit to do this.

A final tip is that after any changes you should restart the w32time service
How to turn on debug logging:
In order to turn on debug logging you must create a location for the log. I would use “c:\w32tmlog”. Next open up regedit and make the following changes:

Locate and then click the following registry key:
On the Edit menu, click New Value, and then add the following registry values:
• Value Name: FileLogSize
Data Type: DWORD
Value data: 10000000

This registry value specifies the size of the log file in bytes.

• Value name: FileLogName
Data Type: String
Value data: C:\w32tmlog\w32time.log

This registry value specifies the location of the log file. The path is not fixed. You can use a different path.

• Value name: FileLogEntries
Data Type: String
Value: 0-116

This registry value specifies the level of detail of the information in the debug log. If you must have more detailed logging information, contact a Microsoft Support Professional.

Note The Data Type value must be of type REG_SZ (String). You must type the value exactly as shown (that is, type 0-116). The highest possible value is 0-300 for most detailed logging. The meaning of this value is: Log all entries within the range of 0 and 116.

The information above has been taken from the following MS KB article:


Below are some links to pages I found useful when researching this article.


How to configure the Windows Time Service against a large time offset:

Registry entries for the W32Time Service:

How to configure Debug logging:

How to configure and authoritative time server in Windows Server 2003:



Monday, October 09, 2006

Security Monitoring and Attack Detection

Security Monitoring and Attack Detection
Published: August 29, 2006

Get the Security Monitoring and Attack Detection paper

On This Page Introduction
The Midsize Business Challenge
Appendix A: Excluding Unnecessary Events
Appendix B: Implementing Group Policy Settings


Welcome to this document from the Midsize Business Security Guidance collection. Microsoft hopes that the following information will help you create a more secure and productive computing environment.
Executive Summary

The number of high profile cases of malicious software threats and incidents that have dominated media reporting for years has served to raise awareness and spur most businesses to invest time and resources into defending against this prevalent security issue. However, the greatest threat to business infrastructure may not be in the form of an attack from the outside, such as from a virus, but may well reside within the internal network itself.

Attacks launched from inside a business network have a very high potential for damage, especially if performed by personnel who hold trusted positions and who have access to all the network resources within a company. When the risks posed by both external and internal threats are carefully examined, many businesses decide to research systems that can monitor networks and detect attacks wherever they may originate.

Security monitoring practices are not open to consideration for businesses that are governed by regulatory restrictions—they are a requirement. These same regulations may even control how long and in what way security monitoring records must be kept and archived. The ever-changing regulatory environment and continually increasing demands placed on regulated businesses to secure their networks, track the identification of people who access resources, and protect private information places greater demands on businesses around the world to institute effective security monitoring solutions.

There are several reasons why security monitoring and attack detection should also be an important issue to midsize businesses that do not need to comply with any regulatory requirements. These reasons include the consequences any business could face if an attack on that business’s infrastructure were to succeed. Not only could business operations be disrupted, resulting in productivity losses and even monetary loss. A business could even suffer from a loss of reputation, which often takes longer to recover from than any other loss incurred due to an attack.

The security log facilities available in Microsoft® Windows® can be the starting point for a security monitoring solution. However, security logs alone do not provide enough information to plan responses to incidents. These security logs can be combined with other technologies that collect and query that information to form the central part of a comprehensive security monitoring and attack detection solution.

The primary goal of a security monitoring and attack detection system is to help identify suspicious events on a network that may indicate malicious activity or procedural errors. This paper will describe how to develop a plan to help address the need for such a system on Windows–based networks. It will also provide instructions about how to implement, manage, and validate such a system.

This paper consists of four main sections that focus on essential concepts and issues required to design and implement an effective security monitoring and attack detection solution. The first section is the "Introduction," which you are currently reading. The remaining sections are:

This section provides information that is useful for understanding the processes involved with the generation and application of the solution presented in this paper.
The Midsize Business Challenge

This section describes many of the common challenges faced by midsize businesses in relation to a security monitoring and attack detection system.

This section provides detailed information about how to develop, implement, manage, and validate the solution presented in this paper, and is further divided into two subsections. "Developing the Solution" discusses prerequisite activities and creates planning steps. "Deploying and Managing the Solution" provides information that will assist efforts to deploy, manage, and validate a security monitoring and attack detection system.
Who Should Read This Paper

This paper addresses privacy and security concerns for midsize businesses, especially those that require identity protection and controls over data access because of regulatory constraints. Accordingly, the intended audience for this paper ranges from technical managers and decision makers to IT professionals and technology implementers who are responsible for the planning, deployment, operation, or especially the security of a company’s network.

Although portions of this paper should be useful to most technical decision makers, readers should have familiarity with the security and risk issues in their own network environment and have an understanding of Windows event logging services concepts to apply all of the subject matter presented within.
Top of page

This paper uses the Microsoft Operations Framework (MOF) Process Model in addition to the MOF Security Administration and Incident Management service management functions (SMFs).

In particular, the solution presented in this paper recommends use of a continual process approach instead of a linear deployment approach to security monitoring and attack detection. Specifically, this solution should involve the steps shown in the following figure:

Figure 1. Applying MOF

A security monitoring solution is actually a continual process of planning, implementing, managing, and testing, because that is the very nature of security monitoring. Because the threats to business networks are always changing, the system that monitors the security in a business network must also change.

Application of this process to security monitoring fits with the Security Management SMF, which seeks to accomplish the following:•
Assess business exposure and identify which assets to secure.

Identify ways to reduce risk to acceptable levels.

Design a plan to mitigate security risks.

Monitor the efficiency of security mechanisms.

Re-evaluate effectiveness and security requirements regularly.

To read more about MOF, refer to the Microsoft Operations Framework Web site at www.microsoft.com/mof. More information about the Security Management SMF is available at www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx.

Risk management is the process of determining an organization’s level of acceptable risk, assessing current risks, finding ways to reach that acceptable risk level, and managing risk. Although this paper deals with some risk management concepts and some steps that will assist with risk assessment, an in-depth discussion of risk management is a subject in its own right and deserves its own dedicated focus. For more information about risk analysis and assessments, see the Security Risk Management Guide at http://go.microsoft.com/fwlink/?linkid=30794.
Top of page
The Midsize Business Challenge

Midsize businesses contend with numerous challenges when attempting to construct an effective security monitoring system and institute policies that support that effort. These challenges include:•
Understanding the need and the benefits of securing the entire network environment from internal and external threats.

Designing an effective security monitoring and attack detection system that includes methods that detect and prevent efforts to work around established policies.

Implementing comprehensive and effective monitoring polices that not only detect attacks but also provide an overall picture of an environment’s security level for remediation efforts.

Maintaining policies and processes that efficiently correlate security reports with established policies to ease administrative efforts in detecting suspicious activities.

Implementing and enforcing efficient business practices and policies that support security monitoring efforts while balancing business needs.

Determining acceptable risk thresholds to balance usability and risk mitigation.

Top of page

As discussed earlier, a comprehensive security monitoring process not only assists with the need to perform forensic analysis but can also be a proactive security measure capable of supplying information prior to, during, and after an attack. By providing a centralized repository for security reports, an attack can be detected during the probing phase, as the attack occurs, or immediately following the attack to supply responders with the information they need to react to an attack effectively, which can reduce the impact of intrusion attempts.

Understanding the range of benefits that can be gained by implementing security monitoring is important during the conceptualization phase of development so that the design and policies can take advantage of all these benefits. Some of the advantages that security monitoring provides include:•
Identification and remediation of systems that do not comply with security or update policies to reduce the vulnerability profile of a midsize business.

Produce information that can alert staff to intrusion attempts before an actual attack occurs by identifying unusual activity.

Create security audit information and protect it to improve forensic analysis, which not only meets regulatory requirements but also reduces the impact of any attack that might occur.

Assist with security level analysis efforts to improve overall security.

Detect activities that occur outside of established business processes, whether intentional or accidental.

Assist with the identification of unmanaged systems on a network or the remediation of vulnerable devices.

Developing the Solution

Security is an important issue for many businesses. Although most companies put a reasonable degree of resources into physical security by using methods ranging from the common door lock to those as elaborate as card-based access controls, many still do not sufficiently address the security of the data that they have become increasingly reliant upon.

When data security and monitoring issues do get attention, companies commonly focus data security efforts at the perimeter with firewalls. However, reliance on this approach leaves other sources of attack quite vulnerable. According to the 2004 E-Crime Watch Survey, published by the United States Secret Service and the CERT Coordination Center at www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf, 29 percent of identified attackers were actually from internal sources, including current employees, contractors, and prior employees. When this information is considered, it becomes apparent that a multilayered security approach should be made to safeguard against internal threats in addition to threats that originate from the outside.

One method that is used to address both internal and external threats from a reactive security stance is to implement a security audit logging process. All versions of Microsoft Windows, from Microsoft Windows NT® 3.1 to present versions, use a built in security event log file to record security events. However, although this built-in functionality alone can be useful when performing a forensics investigation in response to an intrusion that has already occurred, it would be difficult to use this functionality by itself in a proactive manner to identify precursory attack activity or alert the proper personnel to intrusion attempts while they occur.

As mentioned, security logs are often used reactively during a forensic analysis of a security incident after it has occurred. However, in the 2005 Insider Threat Study, published by the US Secret Service and CERT at www.cert.org/archive/pdf/insidercross051105.pdf, an analysis of key findings found that security logging and monitoring can be used for proactive detection rather than solely for reactive forensics. Also, most attackers, internal and external, will attempt to cover their tracks by altering logs; therefore, steps should be taken to protect system logs. It turns out that security logs and other methods used to monitor and detect attacks can be a vital tool in the network security arsenal if used and secured correctly.

Although system security logs are the focus of this document, they only form the core of security monitoring and attack detection methodology. Other issues that should be considered include how to identify and remediate any systems that are not compliant with established security policies or have not implemented currently recommended vulnerability patches. Internal network infrastructure should also be monitored, including switch port security reporting (to prevent unmanaged systems from gaining access to the network) and wireless security monitoring (to prevent unauthorized connections or packet sniffing). Many of these monitoring topics are beyond the scope of this document, but they deserve attention in any well-rounded security monitoring solution.
Implementing Security Monitoring

The following subsections provide information about various implementation considerations with regard to a security monitoring system.
Windows Security Event Logging

All versions of Microsoft Windows, from Microsoft Windows NT version 3.1 and later, are able to record security events using built-in log file functionality. In a Microsoft Windows–based environment, this functionality provides the basis for security monitoring. However, without additional utilities or tools to correlate this information it becomes difficult to use proactively because it is dispersed.

Figure 2. Event Viewer Security log
See full-sized image

The Security event log (shown in the preceding figure) uses a custom file format to record security monitoring data. Although it is possible to read portions of these records with a text editor, a suitable program such as Event Viewer is necessary to see all of the information recorded in these logs. The Security event log file (SecEvent.evt) resides in the %systemroot%\System32\config directory. Access to event logs is always governed through the Event Log service, and the Event Log service enforces access controls to each log. The default permissions on the security log are very strict compared to other logs on the system; only Administrators have access to the security log by default.

There are two types of events that are recorded in the Security event log: success audits and failure audits. Success Audit events indicate an operation that a user, service, or program performed has completed successfully. Failure Audit events detail operations that have not completed successfully. For example, failed user logon attempts would be examples of Failure Audit events and would be recorded in the Security event log if logon audits were enabled.

The Audit Policy Group Policy settings, located under Computer Configuration\Windows Settings\Local Policies, control which events create entries in the security logs. Audit Policy settings can be configured either through the Local Security Settings console or at the site, domain, or organizational unit (OU) level through Group Policy with Active Directory.
Interpreting Audit Events

Audit events are discussed in much greater detail throughout this paper, so a basic understanding of audit event structure and the information contained in audit events is important.

Figure 3. Event Properties Window

Events are made up of three basic parts: the event header, the event description and a binary data section.

Event headers consist of the following fields:

Table 1. The Event HeaderField Definition

The date the event occurred

The local time when the event occurred

A classification of the event severity or type. For security audit events these are either of type Success Audit or Failure Audit.

The application that logged the event. This can either be an actual program, like SQL Server, a driver name, or a component of the system, like Security for instance.

The event source’s classification of the event. This is pertinent in security audit logs as it corresponds to an event type that can be configured in Group Policy.

Event ID
This code identifies the specific type of event. In the figure above the Event ID is listed as 680, this Event ID indicates that a set of credentials was passed to the authentication system by a local process, remote process, or user.

The username of the user on whose behalf the event occurred. This name is the client ID if it was caused by a process or the primary ID if impersonation s not taking place. In security events both the primary and impersonation information will be displayed if possible and applicable.

The name of the computer where the event occurred.

The event description field actually contains a variety of information that can vary from event to event. For example, in the Event 680 sample shown in the preceding figure, the Error Code: field specifies 0xC000006A, which means an incorrect password was supplied. Each event type will display event specific information in this field.

Windows Security Event Log events do not use the binary data section of the event record.
Technical Issues

To implement a security monitoring and attack detection system based on Windows security event logging, the following issues must be addressed:•
Manage high volumes of security events. To cope with the high volume of security events that will be generated careful attention will need to be given to which specific security audit events should be tracked. These considerations are particularly important when dealing with file and object access auditing, both of which can generate very large quantities of data.

Store and manage event information in a central repository. Storage of event information can involve terabytes of data depending on the configuration of a monitoring system. This is most important when considering forensic analysis needs and is covered in detail under that section.

Identify and respond to attack signatures. In order to identify patterns of activity which can signal an attack a reviewer or configured query must be able to pick out the events associated with such activity imbedded within the information provided. Once a suspicious activity is identified there should be a mechanism in place that prompts a timely and appropriate response.

Restrict staff from circumventing security audit controls. Personnel with elevated privileges on a network, especially administrators, should be compartmentalized in order to restrict access to audit information so that only security specialists are responsible for the administration of audit systems.

Solution Planning

The following activities should be completed before implementing a security monitoring and attack detection system:•
Review current security audit settings.

Assess administrator roles and normal user tasks.

Review business policies and procedures.

Identify vulnerable systems.

List high-value assets.

Identify sensitive or suspicious accounts.

List authorized programs.

For more information regarding storage requirements, see the "Implement Forensic Analysis" section later in this paper.
Review Current Security Audit Settings

Businesses should review their current security auditing and Security log file settings to provide a baseline for changes recommended in this paper. Such a review should be conducted regularly after implementing a solution and will need to obtain the following information:•
Current effective security audit settings.

Level to which these settings apply (local computer, site, domain, or OU).

Current log file settings (size limits and behavior when maximum size reached).

Additional security audit settings that may apply (for example, audit the use of backup and restore privileges).

Information in "Appendix B: Implementing Group Policy Settings” at the end of this paper can be used to assist with the identification of which settings to record. For more information regarding security audit settings, see the Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?LinkId=14845.
Assess Administrator Roles and Normal User Tasks

A key element to the implementation of an effective security monitoring solution is to ensure that administrator account holders are known and their roles and responsibilities are understood. For example, most businesses include administrators in the Domain Admins group so they can create new user accounts in the domain. However, business policies may specify that only an installed provisioning system is permitted to create new accounts. In such a situation, an account creation event initiated by an administrator account would prompt an immediate investigation.

An assessment of user account tasks is usually much simpler because such accounts typically have significantly less access to network resources than administrator accounts do. For example, since normal users usually have no need to access the file system on computers residing in the perimeter of a network, there is little need to monitor such servers for normal user activity.
Review Business Policies and Procedures

A review of business processes and procedures corresponds closely to, but is not limited to, an assessment of administrator roles and responsibilities. Important components of such a review would include an examination of the user creation process and the change control process, for example. Examination of the mechanisms that provide an approval process and audit trail for all events that occur on a network is vital to provide a correlation to what would be authorized audit events and what may be an intrusion attempt.
Identify Vulnerable Systems

Vulnerable systems are the computers and devices on a network that an external attacker is most likely to probe and launch access attempts against before they try any other approach. Typically, these computers reside in the perimeter of a network, but internal devices can also be vulnerable to attack and should not be completely ignored.

A comprehensive review of vulnerable systems should ensure the following:•
All relevant security updates and service packs have been applied.

Unnecessary services and user accounts have been disabled.

Services are configured to run under Local Service or Network Service accounts when possible.

Services that require user account credentials are checked to ensure they require that level of access, especially when such accounts have administrator privileges.

High-security policy templates have been applied.

Note This review process should not be limited to vulnerable computers residing on the perimeter. A good security practice would apply these checks to all computers on a network.

For more information about how to configure services to run securely, see The Services and Service Accounts Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41311.
List High Value Assets

Most businesses are likely to have already identified the high-value assets that reside in their networks, but they might not have formalized this information as a part of an organizational policy by documenting and detailing the protections in place for each asset. For example, a company might use access control lists (ACLs) and encryption to store sensitive financial records securely on NTFS file system partitions. However, an organizational policy should identify such records as protected files that unauthorized users and administrators should not attempt to access so that administrators and users are aware of this restriction.

Any changes to an ACL that is used to protect such files should be investigated, especially when ownership changes are involved because these events can indicate illicit attempts to access files without proper authorization. Because ownership changes of this nature should be very rare, they should be easy to detect after high-value assets are identified and documented.
Identify Sensitive or Suspicious Accounts

All sensitive accounts should be reviewed to identify which accounts require a higher auditing level. Such accounts will include the default Administrator account, any members of the Enterprise, Schema, or Domain Admins groups, and any accounts that are used by services.

Aside from sensitive accounts, it is also important to adjust security audit levels for accounts held by individuals who have been identified as risks or who may be suspected of participating in suspicious activity. For more information about how to adjust audit levels for individual user accounts, see the “Policy Violations and Thresholds” section later in this paper.
List Authorized Programs

To discover information about a network, an attacker must run programs on systems that reside within that network. By restricting what programs are permitted to run on a network, a business can significantly reduce the threat of external attack. To establish a list of authorized programs, an audit should be performed on all programs currently authorized or identified as necessary in a network environment. Any unknown programs discovered during such an audit should be considered suspect and investigated immediately. Microsoft Systems Management Server 2003 can assist with software audits but is not required.

Note Some exceptions may be required for certain computers, such as developer workstations where executables under development may not be on an approved programs list. However, a more secure approach would be to require that development and testing only occur in a virtual computer environment or only in an isolated development network domain.
Detect Policy Violations and Thresholds

Policy violations form the largest category of security issues for which businesses must plan. These types of incidents include:•
Creation of user accounts outside of the established process.

Improper or unauthorized usage of administrator privileges.

Use of service accounts for interactive log on.

File access attempts by unauthorized user accounts.

Deletion of files that user accounts have permission to access.

Installation and execution of unapproved software.

Although the most common type of policy violation is unintentional user access attempts, such as browsing to restricted directories, such violations are usually the least significant because access limitations and well-designed rights policies address this issue. Administrative policy violations are the most significant type of event, whether deliberate or accidental, because of the very nature of administrative rights.

Administrative account privileges grant a significant degree of systems access to the individuals who require that type authority to perform their duties. However, this authority does not imply the authorization to use those system rights outside of authorized scope or process. The ability of administrative accounts to enable user account creation, modify user accounts, view restricted data, and modify data access rights requires careful consideration of ways to mitigate the risks associated with such powerful capabilities.
Threat Modeling

As can be seen, some sets of threats can be mitigated with auditing, others may not, and some can be mitigated with auditing yet may not be worth the cost to do so. The main point to understand is that not every vulnerability presents a threat to a network. To make determinations as to which vulnerabilities can or should be mitigated, it may be useful to apply principles of threat modeling.

Threat modeling is an engineering technique that can be used to help identify threats and vulnerabilities to more efficiently create countermeasures in the context of a specific environment. This process generally involves three basic steps:•
Understanding the attacker’s perspective.

Identifying the security profile of the system.

Determining and ranking the relevant threats.

More to the point, examining a network environment from an attacker’s perspective involves determining what targets would be most tempting to a person attempting to gain access to a network and what conditions must be met for an attack on such targets to succeed. When vulnerable targets of opportunity have been identified, the environment can be examined to determine how existing safeguards affect the attack conditions. This process reveals relevant threats, which can then be ranked according to the level of risk they present, which remediation activities can deliver the most valuable solution to that threat, and whether mitigation may affect other areas in beneficial or detrimental ways that may affect the value of that remediation.

Accordingly, there are actually a few specific steps to a successful network threat modeling process that are based on these requirements:
Identify Critical Assets. Part of determining where best to spend security resources is to list the assets that are critical to business operations. This process should involve the business process owners as well as the technology owners, because each will have important perspectives concerning which assets would cause harm to the business if compromised.

Identify Possible Attack Points. This identification phase actually involves two different perspectives as well. First, it is necessary to classify the types of boundaries that data on the network can reside within. These boundaries reside within either the critical, sensitive, and public realms based on the damage that could be done if said data was exposed. Second, a technology perspective examines the attack points by way of vectors and what possible points of vulnerability could grant exposure to critical and sensitive assets. This combination of information can help narrow the focus of security efforts to vulnerabilities at the points where critical information can be accessed.

Identify Actual Threats. When critical assets and the possible access points have been revealed, a list of what attackers could do to cause damage can be created. With such a list it is then possible to focus efforts on actual specific threats.

There are different methods that can be used to identify actual threats. STRIDE is one method that examines threats based on the types of attacks that can be used (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of Privilege). Other iterative measures exist as well, such as breaking threats down by logical layers (for example, network, host, and application). The approach is up to the organization based on what makes the most sense for a given environment.

Categorize and Rank Threats. This step brings common risk assessment and management principles into play by ranking threats based on the probability of their use and the potential impact those threats could have on a business. The standard formula used is as follows:

Risk = Probability of Exploitation x Potential Business Impact

There are actually a number of methods involved in such a process, as well as a number of tools available to help with such risk assessments that are well beyond the scope of this paper. For more information about risk management and these methods please refer to the Security Risk Management Guide at http://go.microsoft.com/fwlink/?linkid=30794.

Remediate and Re-evaluate. The product of the previous steps provides a list of actual threats that are capable of affecting the business, which are ranked in order of the risk the present to that business. This list enables a focused remediation effort that should also be evaluated for the cost-to-benefit ratio they present. After all, there may be several different ways to mitigate specific risks and some may address other vulnerabilities that then make such security efforts even more effective.

Even after a remediation plan is enacted, the threat modeling method is an iterative process that should be performed on a regular basis with constant re-evaluation efforts to ensure that security efforts are as effective and comprehensive as possible.
Background Investigations and Reviews

Most businesses already perform some sort of background check on prospective employees as a condition of employment, but do not perform checks afterwards. Businesses should consider performing background checks at regular intervals during employment, especially for critical positions with access to restricted information.
Computer Use Policy Agreements

Computer or network usage agreements are important not only to inform employees about how they may use company assets but also to inform them about policies to monitor network activity and computer use in addition to the possible consequences of any attempts to violate these policies.

Usage policy statements also act as legal documents when they define these issues in explicit terms and require employee signatures as an indication of agreement. Without proof that an employee was fully aware of internal security monitoring policies and the expectation of acceptable use of company assets, it is increasingly difficult to prosecute abusers in case of any wrongdoing.

It is also important to issue an access and unauthorized usage warning at any access point on a company’s network that informs any person who attempts access that it is a private network and that any unauthorized access is prohibited and will be prosecuted. For example, Windows operating systems have the capability to display a warning statement during an attempted logon event that can be used to inform users that they are about to attempt access to a protected company resource and that unauthorized access is prohibited.

Although it is outside the scope of this document to discuss the legal issues involved with the exact wording and use of such documents, it is important to mention that such documents and policies should exist. Many examples of such usage and access statements may exist on the Internet, but these materials should only be prepared with the support and consultation of qualified legal advisors because there are many unique local and international legal issues that require careful consideration.
Separation of Duties

Just as different functionalities for systems are segmented across a network for security, performance, and availability purposes, it is also important to provide for duplication and separation of duties when developing staffing requirements for an IT security department.

Important roles that involve access or control of sensitive data and systems should be redundant whenever possible and reasonable, not only to protect against issues surrounding the loss of knowledge if a staff member is lost but also to provide a security function in cases of internal sabotage. For example, it would be difficult to recover if only one staff member knew the administrator passwords and that staff member left without providing those passwords.

In addition to role redundancy, it is also important to separate critical roles, especially for security monitoring. The people who manage the network should not also be responsible for reviewing security audit information, and the security staff should not have administrative rights that are equal to the administrators. Sometimes it is also necessary to safeguard departmental information from administrative staff to further apply separation of duties. For example, some businesses have organizational units that have their own systems or administrative accounts to protect sensitive information such as finances or human resources.

Note Although it may not be possible to prevent administrator account holders from finding workarounds for such separations of duties, it is important to at least establish set guidelines for authorized usage for administrative authority that uses the principle of separation of duty.
Validate Security Monitoring Functionality

Regular testing of a security monitoring solution should be planned carefully before implementing such a program. Although initial testing is important to validate a security monitoring solution, it is important to have a schedule of tests that occur regularly due to the ever-changing security environment.

Testing can include intrusion attempts and testing use of administrative privileges to determine whether the solution is effective at finding such activities. However, it is also important to research the latest changes in security techniques and attack profiles to determine if changes need to be made. The threats to business networks are constantly changing as attackers adjust to security implementations, so the defenses and monitoring techniques should constantly evolve to remain effective.
Establish Processes

To separate authorized events from unauthorized security events it is necessary to create a plan for established mandatory change control and problem management processes. Such a plan can provide a detailed paper trail that can be cross-correlated with security log information. Although issue tracking is commonplace in most companies by way of help desk tickets or other problem tracking processes, change control is often neglected. Change control is a necessary mechanism, and may be used not only to track trends for spotting problematic systems or applications but also as a vital security mechanism.

Change control processes should occur as a proactive procedure, and reactive changes should be limited to use of a problem management process. A change control process should require submittal and approval prior to any change and include the following details: •
Approver name

Implementer name

Timeframe of the change

Reasons for the change

Changes to be made

Systems affected by the change

Business impact

Actual results of the change

Another process that should be established is a user provisioning process via an add/change/delete user procedure that also creates an audit trail to guard against unauthorized account changes. Prior to the establishment of such a process, it is important to perform a security audit of the current user accounts that exist to verify the validity of those accounts and periodically validate that list as it changes.

Use of automatic user provisioning and identity management solutions, such as Microsoft Identity Integration Server (MIIS) 2003, can be helpful as well by automating account changes and the processes behind such activities. When using such solutions it is important to remember that administrator accounts still retain the capability to create new accounts but that they would have no need to do so—because accounts would be created by established processes. Therefore, any events associated with account creation, such as event 624, should only correlate to the MIIS 2003 or other established service account that is used for automatic provisioning.

Although external threats to business networks are constantly aired in the media, experience shows that networks and company data are much more vulnerable to loss or compromise from incorrect configurations or procedural missteps. It is important to protect against all threats external and internal, and many vendors exist to help protect your company from external threats, but no one can sell a business a package that will prevent mistakes made by the people responsible for your network and security. The best way to mitigate such risks is by implementing and enforcing sound processes and procedures regarding changes performed on the network.
Define Security Responses

To limit the damage a security breach can cause, it is important to develop a defined suitable response plan and establish processes for responding to incidents. Incident reports, the formation of a rapid response team, and an emergency response protocol are good examples. The speed and effectiveness of incident responses will enhance an organization's security profile and limit the actual and perceived damage an intrusion attempt may cause.

The formation of an established security response process not only helps limit the damage an actual incident may cause, it also acts as a deterrent by notifying staff and other individuals that an incident will provoke a coordinated and immediate response to any security violations.
Human Resources

According to studies done by CERT and the U.S. Secret Service, many attacks from internal sources could be averted if businesses were more aware of and took actions in response to an employee’s behavioral changes or threats. Probably the most valuable security resources in a business are the employees themselves, because they are aware of when a staff member may become disgruntled or alert the proper personnel to when a visitor may be acting suspiciously. In fact, one of the first actions by an outside security auditing group will be to perform a “walk around” in an attempt to find password information on paper, spot unsecured devices, or to attempt intrusions by connecting directly to the internal network.

A business’s staff can serve as an important layer of protection against internal and external threats. Encouraging open door policies to discuss worrisome behavior from peers and training support personnel to take any reports of unusual computer activity from staff seriously can help mitigate intrusion attempts or malware incidents. Internal training is also important as a method of teaching employees how to spot types of computer behavior that should be reported. Training also serves as a preventative measure with regard to avoiding social engineering attacks.
Correlate Security Policy Violations with Audit Events

Correlating security event information involves the collection of security events from multiple systems and the placement of this data into a secure central location. When security information has been correlated, the appropriate personnel can analyze this central repository to identify violations or external attacks. This repository is not only important for forensic analysis, but also as a tool to detect attacks and address vulnerabilities. Although there are several third-party solutions that exist for this purpose, the following Microsoft products and tools can help address this need by correlating security event logs and other security monitoring information into a central repository.

EventCombMT (multi-threaded) is a component of the Windows Server 2003 Security Guide, which is available at http://go.microsoft.com/fwlink/?LinkId=14845. This tool can parse and collect events from the event logs on multiple computers. It runs as a multi-threaded application that enables the user to specify any number of parameters when scanning event logs, such as:•
Event IDs (individual or multiple)

Event ID ranges

Event sources

Specific event text

Event age in minutes, hours, or days

Figure 4. EventCombMT
See full-sized image

Certain specific search categories are built in to EventCombMT, such as account lockouts (shown in the preceding figure), which provide search functionality for the following events:•
529. Logon failure (bad user name or password)

644. A user account was auto locked

675. Pre-authentication failed on a domain controller (incorrect password)

676. Authentication ticket request failed

681. Logon failure

Another security-related event that does not reside in the Security log file is event 12294, which is from the System log file. It is important to add this event to any search, because it can be used to detect attack attempts against the Administrator account which does not have a lockout threshold and is therefore a vulnerable and tempting target for any would-be attacker.

Note Event 12294 appears as a Security Accounts Manager (SAM) event in the System log, not in the Security log.

EventCombMT can save events to a Microsoft SQL Server™ database table, which makes it useful for long-term storage and analysis. After it is stored in a SQL Server database, the information from the event logs can be accessed by an array of different programs, such as SQL Query Analyzer, Microsoft Visual Studio® .NET, or a number of third-party utilities.
Log Parser 2.2

Log Parser is a free tool available from Microsoft that can be used to search for data in a log, upload logs to a SQL database or CSV file, and generate reports from event logs, CSV files, or other log formats (including IIS logs, for which it was originally designed).

This command-line scripting tool can be used as a resource to correlate event log information into a central location, parse events that are of interest, and even generate reports. However, the scripting and command-line interface require a level of detail that is beyond the scope of this paper. More information about Log Parser, its uses, and scripting resources is available on the Log Parser 2.2 page at www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx and in the "How Log Parser 2.2 Works" article at www.microsoft.com/technet/community/columns/profwin/pw0505.mspx.

EventQuery.vbs is a tool that was released with Windows XP. It can be used to list events and event properties from one or more event logs. The command-based script host (CScript.exe) must be running to use this script. If the default Windows Script Host has not been set to CScript, you can accomplish this by running the following command:
Cscript //h:cscript //s //nologo

This command-line script utility is very flexible and can accept many different parameters to adjust the filtering and format applied to its output. For more information on this tool's usage and available parameters, refer to the Managing event logs from the Command Line topic in the Windows XP Professional Product Documentation at www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event_commandline.mspx?mfr=true.
Internet Information Services Logging

The additional logging functionality available with Internet Information Services (IIS) provides the ability to report on the identity of site visitors, what a visitor accessed, and when that visitor accessed it. IIS logs record successful and failed attempts to access sites, virtual folders, and files, and can be configured to selectively audit that information to minimize storage requirements and limit the recording of unnecessary information.

These logs can either be stored in native format as a file, which can then filtered by using one of the parsing and collation tools listed earlier, or directly to a centralized location by using ODBC database logging, which can be used to store the information to a SQL database or any other ODBC-compliant database.

Certain activities and sequences of events should be monitored closely, including the following:•
Multiple failed commands attempting to run executable files or scripts.

Excessive failed logon attempts from a single IP address or range of addresses, which can indicate either a DoS attempt or a privilege escalation attempt.

Failed attempts to access or modify .bat or .cmd files.

Unauthorized attempts to upload files to a folder that contains executable files.

Beginning with Windows Server 2003, new auditing capabilities are built-in with IIS and can either be used with the new logging capabilities of IIS, integrated directly into the Event Log, or accessed with ASP pages for custom solutions. For more information about these capabilities and how to implement them, refer to the IIS documentation.
Microsoft Internet Security and Acceleration Server

Microsoft Internet Security and Acceleration (ISA) Server is an advanced stateful packet and application layer firewall that also provides additional functionality, including VPN and proxy caching capabilities.

In addition to the active defense utility that ISA Server provides, it can also serve a security monitoring function by using its ability to act as a centralized logging tool that can monitor all activity flowing through the perimeter of a network. The logging capabilities in ISA Server include the ability to capture firewall traffic, Web proxy activity, and SMTP message screening logs. These logs can be filtered, queried, or monitored on a real-time basis by using the built-in real-time log viewer (shown in the following screen shot) or monitoring dashboard.

Figure 5. Microsoft ISA Server 2004 Real-Time Log Viewer
See full-sized image

In addition to the built-in logging functionality, ISA Server has an alerting feature that can issue alerts via e-mail and event log entries or even start or stop services. The ability to log suspect activity to event log entries is particularly useful in the scope of this paper. This capability allows for the recording and storage of possible attack information into a centralized location with other audit event log data.

In addition to this logging and alerting functionality, there are also built-in intrusion detection tools that can be enabled in ISA Server. These basic intrusion detection services (IDS) are licensed from Internet Security Systems and include several IP packet filters, DNS application filters, and a POP application filter. These services are capable of detecting many common exploits.

The intrusion detection functionality in ISA Server is capable of logging events and generating alerts when potential attacks are detected. It can also terminate services or suspicious connections. Some of the attack profiles that can be detected include:•
WinNuke (Windows out-of-band attacks)

Land attacks

IP half scan attacks

UDP bombs

Port scans

DNS hostname length overflow Attacks

DNS zone transfers from privileged or high TCP/IP ports

In any case, whether using ISA Server or some other firewall and IDS solution, it is important to consider the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) when designing a security monitoring and attack detection system.
Microsoft Operations Manager 2005

Microsoft Operations Manager (MOM) monitors multiple servers in an enterprise environment from a central location. The MOM agent collects events from event logs and forwards them to the MOM management server, which then places those events into the MOM database. MOM 2005 and later versions are capable of collecting events from computers that do not run the MOM agents.

MOM uses its management pack rules to identify issues that affect the operational effectiveness of servers. Additional rules can be created to monitor for specific events and, when these events occur, send alert notifications via e-mail, pop-up messages, or directly to pager devices.

Although MOM provides many useful features that can be used for security monitoring and attack detection, it was not designed for this functionality. Future releases of MOM will provide greater security log collection functionality.
Microsoft Systems Management Server 2003

Microsoft Systems Management Server (SMS) 2003 can monitor and manage servers and workstations in a network from a central location. Although it is geared to management tasks, it can also help serve vital security-related functions in a security monitoring solution by managing security updates distribution and reporting or by reporting on any unauthorized software installations.

The SMS inventory functionality can help serve a vital need in a security monitoring solution by serving as a real-time centralized inventory management solution, which is vital to any security audit and monitoring process.
Implement Forensic Analysis

Forensic analysis is a large subject in its own right and this paper cannot explain this topic in entirety. In particular, this paper does not discuss the evidence handling requirements of forensic analysis or describe forensic data other than information supplied by security event logs.

Determining the timing, severity, and results of security breaches and identifying systems affected by attackers can be accomplished with forensic analysis. To be effective, the information gathered for forensic analysis must contain the following information:•
Time of an attack

Duration of an attack

Systems affected by an attack

Changes made during an attack

Again, because of the myriad number of details involved with understanding the laws that govern evidential procedure, key data types in regard to forensics, the tools required for analysis, evidence collection, evidence preservation, and forensic methodologies, it is impossible to address this subject in detail in this paper. However, there are some excellent resources, such as the First Responders Guide to Computer Forensics from CERT at www.cert.org/archive/pdf/FRGCF_v1.3.pdf, which are available at sites devoted to security studies.
Business Issues

Planning for the use of forensic analysis differs from approaches to other solutions, because it involves the investigation of incidents after they have occurred instead of a real-time analysis of incidents. Therefore, a detailed history of events from multiple systems must be maintained for a longer period of time. Because of this additional need, an effective forensic analysis system should be centralized and have a significant amount of storage capability to store a large number of records in a suitable database structure.

One of the mitigating business decisions regards the length of time that such records should be kept for forensic analysis, and also what type of retention cycle should be used. Such factors can greatly affect storage and equipment requirements for a forensic analysis plan. The following table illustrates the typical retention times that are often found at businesses that have established forensic analysis plans.

Table 2. Storage Limits for Forensic AnalysisStorage factors Storage limits Comments

Online storage (database)
21 days
Provides for rapid access to event details

Offline storage (backup)
180 days
Reasonable archival limit for most organizations

Regulated environment
7 years
Archival requirement for regulated businesses

Intelligence agencies
Intelligence and defense organizational requirements

Note Some regulated industry practices (such as those in businesses that handle medical records, for example), use time limit specifications in terms of “do not retain longer than” instead of a set retention time.

One option for consideration is to use online databases to retain the online forensic analysis data and then archive older events into a more compressible format, such as comma-delimited (also known as comma-separated values or CSV) text for offline storage. If necessary, CSV files can be imported back into the online database for analysis if needed.

Ensure that whatever solution is selected serves the business requirements for the rapid investigation of recent events with the added ability to recover older events when necessary. A history of security incidents within a business along with a list of available resources should guide the development of a plan that provides the best combination of data retention times for online and offline storage. If possible, test the event collection system in a reasonably large database with the reports that you wish to run, and verify that the reports run in a reasonable amount of time and deliver actionable information.

Security for forensic analysis data must also be considered, because access to this information should rarely be necessary. If access is needed, it should only be provided to a select few trusted security personnel. Administrator access to this information should be strictly regulated within an established change control process that has additional security oversight. No one else should have the capability to access this information, disrupt its collection, or modify it.
Technical Issues

Planning a security monitoring solution for forensic analysis requires careful provisioning for the secure and reliable collection of, and storage for, a very large number of events. Security monitoring requirements are similar to those detailed in other solution scenarios, but require far greater resources for database storage and highly efficient data management.

Some technical challenges that should be considered include:•
Reliable and secure storage for online data.

Provisioning for large amounts of high performance disk space for online storage.

Reliable backup systems to store older events to archival media.

Secure archive storage management processes.

Tested restoration processes to retrieve information from backup storage.

These challenges should not be specific to security monitoring, because database administrators have similar concerns for other applications such as online transaction processing (OLTP) databases. However, unlike other traditional database applications such as OLTP, a forensic analysis database must cope with a far greater volume of writes rather than reads.

To plan for an effective forensic analysis program, the following requirements must be addressed:•
Proper configuration of security logging settings.

Secure log entry checking processes are established.

A secure and centralized collection point and process created for security logs.

Reliable storage of security monitoring information.

Effective archival plans and schedules developed.

The requirements, capabilities, and regulatory restrictions of a business environment should be factored into any forensic analysis solution because each organization varies in these regards.
Deploying and Managing the Solution

The ability to identify, profile, and respond to an attack is the basic goal of any security monitoring and attack detection solution. Therefore, the bulk of this section will be a detailed discussion of pertinent events that may indicate attacks in progress when found in an event log. With this in mind, a security monitoring and attack detection plan should address the following requirements:•
Detect internal policy violations

Identify attacks from external sources

Enable efficient and precise forensic analysis

The solution detailed in this paper uses similar components for each of these three requirements. The implementation of forensic analysis capabilities has additional requirements that will be discussed later.
Security Monitoring and Attack Detection

The solution concept for security monitoring and attack detection requires planning the appropriate levels of security audits for the following areas:•
Account management

Protected file access

Security policy changes

Trust creation and deletion

User rights usage

System restarts and time changes

Registry modifications

Unknown program execution

The security monitoring and attack detection system collects information from the security event logs and collates this information in a central location. Security auditors can then analyze this data for suspicious activity. In addition, this information can also be stored and archived for later forensic analysis should the need arise.

A major component to this solution is the ability to configure a feature of Microsoft Windows 2003 with Service Pack 1 (SP1) and Microsoft Windows XP with Service Pack 2 (SP2) called per-user auditing. Per-user audits allow for a specification of different audit levels for specific user accounts, thereby permitting a higher level of audit detail for sensitive or suspicious accounts.
Solution Prerequisites

Configuring this security monitoring and attack detection solution has the following prerequisites:•
Servers must run Windows Server 2003 SP1 or later and reside in an Active Directory domain.

Client computers must run Windows XP SP2 or later as members of an Active Directory domain.

Note If the computers in a company’s perimeter do not reside within a domain, they cannot be configured with Active Directory Group Policy settings. However, local policies and templates can be used to configure such systems.

This paper concentrates on identifying the characteristic signatures of attacks and does not make any recommendations for any specific technology to be used for the collation of security events, even though it lists some possible solutions. After a decision is made regarding a suitable collection mechanism, the events and event sequences listed in this paper can be used to design queries and alerts to identify suspicious behavior.
Policy Violations and Thresholds

New features available in Microsoft Windows Server 2003 and Microsoft Windows XP with SP2 allow for selective audit levels on individual user accounts. For example, audit levels can be set to report only logon and logoff activity for all users while auditing all activity for a specific user. Per-user selective audit can also be used to reduce the volume of events in the Security log by allowing certain accounts to be excluded from audit generation for certain activities. Only user accounts can be audited using this functionality; security and distribution groups cannot be so audited. Accounts that belong to the Administrators local group cannot be excluded from audit using the per-user selective audit mechanism.

The command-line utility used to set per-user auditing policy for selective auditing on Windows Server 2003 and Windows XP SP2 is Auditusr.exe. Valid selective auditing categories are:•
System Event


Object Access

Privilege Use

Detailed Tracking

Policy Change

Account Management

Directory Service Access

Account Logon

When Aauditusr.exe is run from the command-line without any parameters, it will display the current selective auditing settings, which will be blank at first. There are two ways to populate the selective auditing parameters; input one per-user manually as command-line parameters, or multiple parameters by importing a per-user auditing settings file.

Usage of Audituser.exe is as follows:
Audituser.exe /parameter useraccount:”category”

(or a comma-delimited list of categories).

For example, to enable failure auditing of System Events and Logon/Logoff events on an account named LocalUser, the following command-line entry would be used:
Audituser /if LocalUser:”System Event”,”Logon/Logoff”

The following parameters can be used at the command line:•
/is – adds or changes an include-success entry

/if – adds or changes an include-failure entry

/es – adds or changes an exclude-success entry

/ef – adds or changes an exclude-failure entry

/r – removes all per-user auditing entries for a specific user account

/ra – removes all per-user auditing entries for all user accounts

/e – exports settings into the specified filename

/i – imports settings from a specified filename

A per-user auditing settings file is a plain text file, and uses the format shown in the following figure.

Figure 6. Sample Auditusr.exe import file

Note The import file must start with the line “Auditusr 1.0” as shown to import successfully.

So to import the audit settings file shown in the preceding figure, the following command would be used:
Audituser /i path\audit.txt

You can use this utility to help establish thresholds for audit logging information, which can reduce storage requirements and increase the likelihood that intrusion attempts will be noticed.
Security Policy Violations and Audit Event Correlation

Although this section makes no distinction between policy violations caused by external or internal sources it is important to note that internal policy breaches can be just as devastating to a business as attacks that originate from the outside. As noted previously in this paper, a significant percentage of malicious attacks are carried out by internal sources, and this percentage does not include the accidental damage caused by inappropriate use of elevated privileges outside of established procedural scope.

Because of the risk involved with accidental or intentional abuse of elevated privileges by internal sources, it is important to establish policies and procedures regarding the appropriate use of those privileges and to establish audit trails for cross-correlation. After the institution of a change management process and documentation policy, a correlation can be developed to match audit information with approved and unapproved events, thereby easing the ability to detect unusual behavior within a business. This section will assist with that correlation by describing the different types of events that can be tracked and how they might apply to policies and processes.
Accessing Unauthorized Computers

Administrative and support staff increasingly use remote management facilities, such as Terminal Services, to connect with and manage remote systems. These systems should be monitored for interactive logon attempts and each connection attempt should be checked for validity. Such checks should perform the following actions:•
Identify service account logons.

Record access attempts by unauthorized accounts.

Investigate attempts from unusual geographic areas.

List attempts from external IP address ranges.

Particular attention should be paid to monitoring high-value assets. Such critical resources should reside on specific servers configured with strict audit monitoring and access control settings.

The following table lists Logon audit events, which should be compared to lists of authorized accounts when seen on high-value asset systems.

Table 3. Unauthorized Computer Usage EventsEvent ID Occurrence Comments

Successful Logon
Check Workstation Name and User Account Name. Ensure Source Network Address resides within a network.

Logon Failure – Unknown User Name or Bad Password
Check for attempts where Target Account Name equals Administrator or the renamed default administrator account. Also check for multiple logon failures that are below the account lockout threshold.

Logon Failure – Time Restrictions
Indicates an attempt to log on outside permitted time range. Check User Account Name and Workstation Name.

Logon Failure – Account Currently Disabled
Check for Target Account Name and Workstation Name. This event can signal attempted intrusions from former users and should provoke an investigation.

Logon Failure – The Specified User Account Has Expired
Check Target Account Name and Workstation Name. This event can signal abuse attempts from contract or temporary employees and should provoke an investigation.

Logon Failure – User Not Allowed to Logon at This Computer
Indicates that a user may be attempting to logon to restricted workstations.

Logon Failure – Logon Type Not Allowed
Check Target Account Name, Workstation Name, and Logon Type. This event indicates a failed attempt to log on interactively with service account credentials when Group Policy settings prevent interactive logons with such accounts.

Logon Failure – The Specified Account’s Password Has Expired
Indicates that a user is attempting to logon with an account that has an expired password. May prompt investigation if repeated without a corresponding password change or support call.

Logon Failure – The NetLogon Component Is Not Active
Check to ensure that the NetLogon service is operational. Otherwise, this event may prompt investigation.

Successful Logon
This event is the network equivalent of Event 528.

Trojans, Rootkits, and Malware

Event ID 592 is particularly useful for detecting occurrences of Trojans, rootkits, and other malware, because it is created whenever a new process starts. Any occurrence of this event should prompt immediate investigation whenever the Image File Name does not correspond with a process listed in an approved programs list.

Although Trojans and keyloggers are relatively easy to identify, rootkits are particularly stealthy. They can be detected by locating unknown programs that start and stop in quick succession. However, when a rootkit is started the operating system has no way to detect it and therefore does not generate any further events.

Other malware attempts can take the form of e-mail attachments or infected Web sites, and may attempt to escalate privileges when the executing account does not have the rights to launch new programs. In such cases, the unauthorized software should create a failure event that should be investigated, especially when the following events occur:•
Processes spawning as LocalSystem. Processes that run as LocalSystem should be well defined in a list of approved programs, and can include such processes as Services.exe.

Processes spawned at unexpected times. If the monitored system does not use any scheduled batch processes, certain activities (such as backups, CGI, or scripts) should be investigated when they occur. In other cases, an investigation should occur when such events occur outside of the regularly scheduled batch times.

Table 4. Event 592Event ID Occurrence Comments

Creating a New Process
Check the Image File Name and User Name entries for unapproved process, unexpected launch times, or when unknown programs start and then stop in quick succession.

Access Resources by Changing File Permissions

It is possible to use administrative privileges to access files to which access would normally be denied by changing ownership of the data and then adding the accounts to the read permissions list to that data. It is also possible to disguise such activity in Windows Server 2003 by changing ownership and permissions back to the original settings.

Identification of high-value assets and data is important in this regard, because it would be counterproductive to implement object access auditing for every file on an average midsize business network because of the sheer volume of access events that occur normally each day. Object access auditing should be enabled for sensitive files and folders; ACL entries are insufficient as a suitable defense against unauthorized access attempts.

To detect illicit activity efficiently, the following factors should be easily identifiable for all high-value files:•
Which object was targeted by an access attempt?

Which account was used to request access?

Which account authorized access?

What type of access was attempted?

Was the event a success or failure?

Which system was used to launch the attempt?

The built-in event viewer does not have sufficient filter settings to identify this information. Therefore, EventCombMT or some other mechanism must be used to perform this analysis.

The Object Access audit events in the following table deal with attempts of this nature.

Table 5. File Permission Change EventsEvent ID Occurrence Comments

Access Granted to Existing Object
Indicates a successfully granted access request to an object. Check Primary Logon ID, Client User Name, and Primary User Name to detect unauthorized access. Check Accesses field to determine operation type. This event only detects access requests, not whether an actual access occurred.

A Permission Associated with a Handle Used
Indicates the first instance of an access type to an object and that permissions were changed if the Access field includes “WRITE_DAC.” Correlate with event 560 by comparing Handle ID fields.

Access Resources by Resetting Passwords

Password changes should only occur within an approved framework of established procedures. Properly configured audit levels should record the Account Management events shown in the following table and correlate those events against recorded procedures to identify activity that does not follow that procedure.

Table 6. Password Reset EventsEvent ID Occurrence Comments

Change Password Attempt
Indicates a password change request in which the requester supplied the original password. Compare Primary Account Name to Target Account Name to determine if the requesting account is the changed account.

User Account Password Set or Reset
Indicates a password reset from an administrative interface rather than a password change process. The requester should be an authorized account, such as a help desk account or self-service password reset account.

Change Directory Services Restore Mode Password
Indicates an attempt to change the Directory Services Restore Mode password on a domain controller. Check Workstation IP and Account name. This event warrants an immediate investigation.

User Account Modification

Any account modification, whether adding, deleting, or changing an account, should correspond to an established process that involves a multiple-step business logic process initiated by an official request from a management level employee. All of the events in the following table should correspond to an official account modification request or prompt an immediate investigation.

Table 7. User Account Change EventsEvent ID Occurrence Comments

Creating a User Account
Indicates a network account creation occurrence.

Deleting a User Account
Indicates a network account deletion occurrence.

Changing a User Account
Indicates security related user account changes not covered by events 627-630.

Changing a User Account Name
Indicates a user account name change.

To effectively identify Account Management issues, queries should be configured to accomplish the following:•
Find irregular or unusual account activities.

Identify administrator level accounts that abuse privileges to create or modify accounts.

Detect patterns of account activities that occur outside of organizational security policy.

It is also important to confirm the interval between account creation and initial logon and password change. If a new account is not used within a predetermined timeframe, (usually an account creation process will record the expected start date of a new user), the account should be disabled and an investigation initiated to determine the reason for delay.
Group Membership Changes

A good security practice involves the principle of least privilege, which means granting accounts the minimum level of access required to perform their functions adequately. When this practice is applied, most accounts will be members of the default Domain Users group with additional membership to business-specific security groups.

Security group membership changes should only occur within established policy guidelines, especially when accounts with elevated privileges are involved. Such group membership changes should only be performed by established accounts used for account management, and such events should correlate to an established process for said changes. Any changes outside of this process should provoke an immediate investigation.

The account management audit events in the following table detail group membership changes.

Table 8. Group Membership Change EventsEvent ID Occurrence Comments

631, 632,
633, 634
Security Enabled Global Group Change
Examine the Target Account Name field to determine if the group changed was global or had broad access privileges.

635, 636,
637, 638
Security Enabled Local Group Change
Examine the Target Account Name field to determine if the group changed was Administrators, Server Operators, or Backup Operators.

639, 641,
Security Enabled Group Change
Indicates a change to a group other than deletion, creation, or membership changes. Examine the Target Account name to ensure that a high privilege group was not altered.

659, 660, 661, 662
Security Enabled Universal Group Change
Examine the Target Account Name field to ensure that a high privilege group, such as Enterprise Admins, was not altered.

Note Distribution group membership does not provide access to network resources, because distribution groups are not security principles. However, membership of certain distribution groups can create security issues, depending on the group. For example, placement of user accounts into a management or executive distribution group could result in a user receiving e-mail messages inappropriate to their position.
Unauthorized Account Usage Attempts

Promotion of the first Active Directory domain controller in a forest creates an administrator account that is a member of both the Domain Admin and Enterprise Admin groups. This account requires particular protection, because it is the only account that is not affected by account lockout settings. Therefore, even when an account lockout policy is in place, this account is especially vulnerable to dictionary attacks.

Effective security monitoring should be able to identify all attempts to log on with this administrator account, even if it has been renamed. For more information about elevating security on administrative accounts, see The Administrator Accounts Security Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41315.

In addition, attempts to log on with disabled or expired accounts can indicate that a former employee, temporary worker, or contractor has tried to gain access to the network without current credentials. Such events should prompt immediate investigations.

The following table lists events that identify unauthorized account usage and belong to the Account Logon and Logon audit categories.

Table 9. Unauthorized Logon EventsEvent ID Occurrence Comments


Logon Success
528 is a common event. However, event 540 should provoke an examination of the Target Account Name to determine if it was caused by the default administrator account.

Logon Failure – Unknown User Name or Password
Always investigate when Target Account Name is the Administrator or renamed default administrator account. Also investigate if logon failures are just below the lockout threshold. Also check for attempts where Target Account Name is administrator or root and when Domain Name is unknown.

Logon Failure – Disabled Account
Examine the Target Account Name and Workstation Name to determine source. This event should prompt an investigation as a possible intrusion attempt by former account users.

Logon Failure – Expired Account
Examine the Target Account Name and Workstation Name to determine source. This event should prompt an investigation as a possible intrusion attempt by former account users.

Special Privileges Assigned to New Logon
Indicates a privilege assignment that can grant a new account administrative privilege or the ability to alter the audit trail. Compare Logon ID field with events 528 or 540 to easily determine if an account obtained administrator equivalence.

Another security issue that involves unauthorized use of account credentials stems from use of effective password policies, such as strong password policies and shorter password expiration times; sometimes users write down or otherwise record their passwords so that they can remember them. This issue is particularly noticeable in environments that have multiple identity stores without identity management services, which demand use of multiple passwords and accounts.

Note For information about password management in heterogeneous environments, see the Microsoft Identity and Access Management Series at http://go.Microsoft.com/fwlink/?LinkId=14841.

Organizations must guard against users recording their passwords, especially in plain sight, because unauthorized individuals could discover and use this information to launch an attack. Monitoring this type of intrusion is possible using the information from the preceding table, but involves a cross-correlation of this information with a history of logon successes for the user account in question so that a list of workstations common for that account to access can be created for comparison.

Note It is possible to restrict user accounts to specific workstations using built-in Active Directory functionality. However, to use this functionality the network must support network basic input/output system (NetBIOS) naming, as supplied by Windows Internet Naming Service (WINS), for example.
Interactive Logon with Service Account Credentials

When services start they must present logon credentials. Sometimes, certain services may require the use of a domain account to run services or connect to remote computers. Some services may even require administrator credentials, or must interact with the desktop as well.

In Windows Server 2003 and later, some service accounts (such as the Alerter service) can be started with the –LocalService switch. In addition, services that require network connectivity can use the Network Service account NT AUTHORITY\Network Service. All services that require user accounts should be checked to ensure that the accounts used are protected with strong passwords. Security monitoring should confirm that logon events for such accounts occur only when associated services start. For more information about elevated security for service accounts, see The Services and Service Account Security Planning Guide at http://go.Microsoft.com/fwlink/?LinkId=41311.

The primary security concern with service accounts develops when such accounts log on interactively instead of as a service. Such events only occur when a service account has been compromised by an intruder and logs on with that account. If the compromised service account has administrator privileges, the intruder has gained access to substantial capability and can disrupt normal network services.

All resources that service accounts can access should be identified and should not have any unexplained permissions that involve access to high-value data. For example, a service account may occasionally require write access to a log file directory, but this is generally not the case. Service accounts that can interact with the desktop also deserve special scrutiny because such accounts provide greater opportunities for attackers to exploit.

The following table lists Account Logon and Login audit events that identify unauthorized use of service account credentials.

Table 10. Logon with Service Account Credentials EventsEvent ID Occurrence Comments

Logon Success – Console Attack or Terminal Services
Indicates an attack in progress if a Logon Type 10, a service account, or the local system account is associated with this event. This event should prompt an immediate investigation.

Logon Failure – Logon Type Not Allowed
Indicates a failed attempt to log on interactively with service account credentials when forbidden by group policy settings. Check the Target Account Name, Workstation Name, and Logon Type when this event occurs.

Process Was Assigned a Primary Token
Indicates a service is using a named account to log on to a system running Windows XP or later. Correlate with information in events 672, 673, 528, and 592 to investigate.

User Attempt to Install a Service
This event should not occur often in a business environment with a clearly defined acceptable applications policy and system standardization process. This event should prompt an investigation when change control processes do not correlate in such environments.

Unauthorized Program Execution

Administrator level accounts are capable of installing and executing programs, and are therefore typically only delegated to trusted personnel who require such elevated capabilities. Because of the risks associated with untested software, it is important to design a list of approved and licensed software along with a process for requesting, testing, and approving new applications. Unapproved applications should be limited to an isolated test environment, and should not be installed in a production network environment outside of an established change control process. Even then, they should only be allowed after being added to an approved software list.

The following table lists process tracking events that can identify the use of unauthorized programs.

Table 11. Run Unauthorized Program EventsEvent ID Occurrence Comments

Creating a new Process
Indicates a new process was created. Examine the Image File Name and User Name fields and compare with an authorized programs list when there is an established permissible program policy in a business. Also look for instances where LocalSystem is used to launch a command prompt, because this is a common method for evading an audit trail.

Creating a Scheduled Job
Examine the Target Name and Task Time when such events occur at unexpected times.

Note Process tracking security audits are capable of identifying unauthorized programs. However, process tracking generates multiple Security log entries, so care must be taken that the number of events does not overwhelm security detection mechanisms.
Access Unauthorized Resources

The following table of object access audit events involve attempts to access resources that a user is not authorized to use.

Table 12. Access Attempts to Unauthorized Resources EventsEvent ID Occurrence Comments

Access Refused to Existing Object
Examine the Object Name field to determine the accessed resource and correlate the Primary User Name and Primary Domain fields or the Client User Name and Client Domain Fields to determine the source.

Attempt Made to Create a Hard Link to an Audited File
Indicates a user or program attempted to create a hard link to a file or object. An established hard link allows an account to manipulate a file without creating an audit trail if the account has rights to the object.

Use of Unauthorized Operating Systems

The use of unauthorized operating systems can cause significant issues, ranging from reduced protection from vulnerability exploits to the increased likelihood of data corruption on file systems. Administrators and users can introduce unauthorized operating systems into a network through the following mechanisms:•
Personal computers connected to the network locally or remotely.

Use of CD-bootable operating systems.

Reinstallation of a Windows operating system.

Use of Virtual PC images.

Organizational policies can specify how users may connect to the network from remote locations via a virtual private network or remote access service, and include requirements for connecting systems such as operating system type, update level, and installation of protective measures such as personal firewalls and antivirus software. For more information about how to ensure remote systems comply with business security policies, see the Implementing Quarantine Services with Microsoft Virtual Private Network Planning Guide at http://go.microsoft.com/fwlink/?LinkId=41307.

It is also possible for users to use Windows XP installation CDs and restart their computers to install an unmanaged operating system. In such cases it may be possible to detect this type of activity by locating logon attempts from an Administrator user account from an unidentified workgroup name or the default Workgroup name.

Note Some open source distributions are available in CD-bootable form, which enables use of the operating system without installing in on a local system. Because the operating system is not actually installed on the local computer, it is difficult to spot such activity. However, logon attempts from user accounts named “root” in a homogenous network environment or from unexpected computer names can indicate the presence of an unauthorized operating system in use. It is possible to prevent this type of activity by disabling the ability to boot from CD in a computer’s BIOS settings and then password protecting the BIOS configuration, but this approach might not be practical in some environments.

Virtual PC images provide a complete emulation of a computer environment on a host computer. This emulation runs its own operating system with its own computer name, user accounts, directory services structure, and programs in a virtual environment. A virtual PC instance is also capable of starting, running, and stopping independently from a host system and so will not likely create any audit events on that host computer. This capability, along with the ability of a virtual computer to connect to the host’s network, obtain IP addresses, and even map to shared drives, presents a number of security risks ranging from weak password protection to increased vulnerability to exploits, because it would not likely be governed by any established update process in place on the network. Given these risks presented by virtual PCs, it is important to restrict the usage of virtual PC software to authorized personnel and establish documented processes regarding the creation and usage of virtual PC instances.

To detect unauthorized operating system usage, a security monitoring solution needs to be able to detect the following:•
Unrecognized user accounts, computer names, workgroups, or domain names.

Duplicate or out-of-range IP addresses.

Attempts to log on with the default Administrator account.

The Process Tracking events listed in the following table can be used to detect the use of unauthorized operating systems.

Table 13. Unauthorized Platform Usage EventsEvent ID Occurrence Comments

Logon Failure – Unknown User Name or Password
Check for attempts in which the Target Account Name field equals Administrator or root or where the Domain Name is unknown.

Logon Failure-User Not Allowed to Logon at This Computer
Indicates that a user may be attempting to log on to restricted workstations.

Creating a New Process
Check the Image File Name and User Name fields to ensure that the program is authorized for that use by that account.

Create or Break Trust Relationships

Trust relationships enable accounts in one domain to access resources residing in another domain. The creation of trust relationships is clearly not a routine operation and should only occur within the scope of an established change control process. Breaking trust relationships is also an activity that should only be performed after being approved in a change control process and after careful consideration with regard to this action’s effects on the network.

The Policy Change audit events in the following table identify trust relationship activities.

Table 14. Changing Trust Relationships EventsEvent ID Occurrence Comments

Trust Relationship with Another Domain Was Created, Deleted, or Modified
These events will be generated on the domain controller that established the trust relationship. This event should prompt an immediate investigation when not correlated with an established change control request process. Examine the User Name field to determine the requesting account.

Unauthorized Security Policy Changes

Changes to approved security policy settings should only occur within the framework of an established change control process. Any changes occurring outside of this approval process should lead to an immediate investigation.

This type of security policy changes include:•
Group Policy settings•
User account password policy

User account lockout policy

Audit policy

Event log settings applying to the security event log

IPsec policy

Wireless network (IEEE 802.1x) policies

Public key and Encrypting File System (EFS) policies

Software restriction policies

Security settings•
User rights settings

User account password policy

Security options

The preceding list only represents minimum requirements, because most businesses will likely add more Group Policy settings in their environment. Security audits will need to identify both successful and failed attempts to change these settings, because successful attempts should correspond to accounts with the authority to make these changes within an established process to do so.

The following table lists Policy Change audit events that identify Group Policy and local system policy changes.

Table 15. Policy Change EventsEvent ID Occurrence Comments

Changing Audit Policy
Indicates a change to an audit policy. These events should be correlated with an established change control policy to determine if they were authorized.

Changing IPsec Policy
Indicates a change to the IPsec policy. Should be investigated when they occur outside of a system startup.

Encrypted Data Recovery Policy
These events occur when an encrypted data recovery policy is in use. Any occurrence outside of specified policies should prompt an investigation.

Note For more information about Group Policy settings, see the "Security Policy Settings" section at http://technet2.microsoft.com/WindowsServer/en/library/bcd7ea4c-f989-4cee-969a-920f62f555111033.mspx?mfr=true.
Attempt to Compromise Credentials

Attackers can use several approaches, ranging from dictionary attacks to social engineering efforts, to obtain user account credentials. Although the most well-known approach involves dictionary attacks against a single account, another common approach is the use of a set of passwords on all accounts in a directory services database. In the second case it is likely that the attacker either has access to the organization’s directory database or has guessed at the user name nomenclature and has a list of employees. To detect this type of attack it is necessary to have the ability to detect multiple logon failures on multiple accounts, even if account lockout thresholds are not triggered.

Password resets are another way to gain control of account credential information. Because password reset or change operations generate the same event for both success and failure, an attacker can avoid detection by circumventing the account lockout policy. To thwart these attempts, a security monitoring solution must be able to identify multiple password change or reset attempts, especially those that occur outside of established policies and business process frameworks.

Although password cycling is not an attack (it occurs when users attempt to circumvent password reuse policies by using scripts to cycle through numerous passwords to use the original password), they still present a threat to security efforts. During such efforts, the number of password resets will roughly equal the password reuse threshold and therefore will appear as a rapid series of 627 events. Implementation of password minimum age policies can cause such attempts to fail.

The following table lists events that can result from attack attempts on authentication credentials, but these events can also occur as part of normal network operations—such as when legitimate users forget passwords.

Table 16. Attack Authentication Credentials EventsEvent ID Occurrence Comments

Logon Failure – Unknown User Name or Password
Check for attempts in which Target Account Name equals Administrator or some other administrative level account that may not be authorized to change passwords. Check for multiple logon failures that are below the lockout threshold. Correlate with Event 529 with Event 539 to identify patterns of continuous account lockouts.

Logon Failure – Logon Type Not Allowed
Indicates that a user attempted to log on with an account type that is not permitted, such as network, interactive, batch, or service. Check Target Account Name, Workstation Name, and Logon Type fields.

Account Locked Out
Indicates an attempt to log on with an account that has been locked out. Correlate with Event 529 to detect patterns of continued lockouts.

Replay Attack Detected
Indicates that an authentication package, usually Kerberos, detected an attempt to log on by replay of a user’s credentials. Although this event could be a sign of incorrect network configuration, it should still prompt an immediate investigation.

Change Password Attempt
Indicates that someone other than the account holder attempted to change a password when the Primary Account Name field does not match the Target Account Name field.

User Account Password Set or Reset
This activity should be restricted to authorized accounts, such as a help desk account or a user self-service password reset account.

User Account Automatically Locked
Indicates an account lockout due to the number of sequential failed logon attempts being greater than the account lockout limit. Correlate with events 529, 675, 681, and 676 (Windows 2000 Server only). Also refer to the entry for event 12294 in this table.

Pre-authentication Failed
Indicates a possible time synchronization issue or computer accounts that are not correctly joined to the domain. Correlate with event 529 to determine the exact reason for logon failure.

Account Lockout Attempt
Indicates a possible brute force attack against the default administrator account. Because account lockout policies are not enforced on this account, it is recorded as SAM Event 12294 in the System event log. Any occurrence of this event should prompt an investigation because it can indicate the use of an unauthorized operating system. Check the Domain Name field for unknown domains.

Vulnerability Exploits

Vulnerabilities are a prime target for an attacker to exploit in an intrusion attempt, because they can exist on any computer and require time and effort to remediate. The period of time between the discovery of vulnerabilities and the development of exploits for those vulnerabilities, typically called the vulnerability to exploit window, has grown shorter over time, which means there is less time to develop, test, and distribute patches for those vulnerabilities.

The best defense against vulnerability exploits is still an effective patch management process that quickly tests and deploys security updates within an environment. Some services that can assist with this process are Microsoft Systems Management Server (SMS) 2003 or Windows Software Update Service (WSUS).

Security monitoring on the perimeter network is also particularly important in this regard, because computers residing there are most readily available to an attacker. Without mechanisms in place to detect attacks as they occur, an organization my not realize that anything is amiss until the network has already been compromised. Therefore it is vitally important that computers residing in the perimeter network are carefully monitored for a wide range of audit events.

In addition to events already discussed, most notable events detailed in the “Attempt to Compromise Credentials" section include unauthorized access attempts and privilege identity usage. The following table lists some events that can identify such attacks.

Table 17. Vulnerability Events Cause by Vulnerability Exploit Escalation of PrivilegesEvent ID Occurrence Comments


Local Logon and Logoff
Correlate the Logon ID field when such events occur on perimeter computers. Should prompt investigation when User Account Name, Time, or Workstation Name fields contain unexpected values.

User Initiates Logoff
This event can be considered as equivalent to Event 538, because a token leak can cause a failure to audit Event 538 but will cause Event 551 to occur instead.

Privileged Logon
Indicates an administrator account logon, an account logon with sufficient privileges to tamper with the Trusted Computing Base (TCP), or sufficient privileges to take over a computer on a Windows Server 2003 with SP1 or later. On earlier versions of Windows, this event is only of interest when associated with sensitive privileges such as SeSecurityPrivilege or SeDebugPrivelege.

Note In Windows versions prior to Windows Server 2003, event 576 will list in the Privileged Use category. In Windows Server 2003 and later, the Logon category will also list this event. Therefore configuration of audit settings for either category will cause this event to appear.
Attempts to Circumvent Auditing

Just as there are multiple methods available to attack a business’s network, there are also various techniques available to hide those attempts and elude discovery. For example, an attacker can change the security policy on a compromised system or domain to prevent event logs from recording suspicious activity, or a Security log can be deliberately erased so that any audited information is lost.

It is possible to detect attempts to elude a security monitoring solution with such techniques, but it is challenging to do so because many of the same events that can occur during an attempt to cover the tracks of intrusive activity are events that occur regularly on any typical business network.

The following table of multiple event types can help identify auditing circumvention attempts by attackers who are trying to hide evidence of a security breach.

Table 18. Circumvent Event Auditing EventsEvent ID Occurrence Comments

Windows Start Up
Usually occurs after Event 513. Unexpected restarts should be investigated.

Windows Shut Down
Usually occurs before Event 512. High-value computers should only be restarted by authorized personnel, and even then only in accordance with an established change control or other procedure. Occurrence of this event on any server should prompt an immediate investigation.

Audit Failure
This event can occur either when too many events overwhelm the event log buffer or when the security log is not set to overwrite. Although these issues can be prevented by limiting the types of events monitored on most computers, high-value or vulnerable computers require more detailed monitoring to secure and therefore need to be carefully monitored.

Clearing Security Event Log
Security event logs should never be cleared without authorization. Check the Client User Name and Client Domain fields to cross-correlate with authorized personnel and procedural approval records.

Changing the System Time
This activity can be used to mislead forensic investigations or provide attackers with false alibis. Check the Client User Name and Client Domain fields for cross-correlation with authorized personnel in addition to checking the Process Name to ensure it is listed as %windir%\system32\svchost.exe.

Unable to Log Events
Occurs when Windows is unable to write events to the event log. This event should be investigated whenever it occurs on any high-value systems.

A User Account Privilege Was Assigned
Occurs when a new privilege is assigned to a user account. The event log records this action along with the user account Security Identifier (SID), not the user account name.

A User Account Privilege Was Removed
Occurs when a privilege was removed from a user account. The event log records this action along with the user account’s SID, not the user account name.

Changing Audit Policy
Although this event does not necessarily indicate that there is a problem, an attacker can modify audit policies as part of an attack. This event should be monitored on high-value computers and domain controllers.

System Access Was Granted to an Account
Occurs when a user was granted access to a system. The User Name and Account Modified fields should be checked when the access permission is listed as interactive.

System Access Was Removed from a System
This event may signal that an attacker has attempted to remove evidence involving Event 621 or is attempting to deny service to some other account(s).

Changing the Domain Security Policy
Occurs when there is an attempt to modify password policy or other domain security policy settings. Check the User Name and correlate with any authorization records.

Forensic Analysis

Although forensic analysis relies on many elements discussed in this paper, it is still fundamentally different from the other monitoring and attack detection solutions discussed because it focuses on storage and analysis of security information and is used in response to an attack after it has occurred. Most forensic investigations begin as a list of events associated with a specific user or system.

Security monitoring for forensic analysis requires:•
Archival of selected event types.

An estimate of the expected number of events each day.

Set time limits for online, offline, and archive storage.

Databases scaled to cope with the expected number of events.

Backup system capable of coping with the expected daily event load.

Set policies regarding management of the archival system.

There are three main factors that determine storage requirements for a forensic analysis program:•
The number of events that must be recorded.

The rate these events are generated by target computers.

Online storage duration for availability.

An understanding of business needs along with the information provided in previous sections should help make determinations with regard to these three factors so that a reasonable storage requirement can be obtained.
Top of page

It is clear in today’s network environment that an effective and comprehensive security monitoring and attack detection solution is not an option but a necessity for any midsize business. The threats and risks facing business networks are numerous and not only originate from outside the perimeter but also include internal threats both intentional and accidental. Well-reasoned security monitoring systems take all risks into account and require a thorough understanding of those risks in addition to the current architecture of a business network and the hallmarks of potential threats and activities that could endanger the data residing on that network’s systems.

Microsoft clearly takes security very seriously, and has accordingly provided many tools that can be used to help build an effective security monitoring and attack detection system. Windows Server 2003 and other versions of the Windows operating system help supply the basis for this security monitoring solution with their built-in security audit logging functionality. When combined with other components such as Microsoft Operations Manager and EventCombMT and the necessary business policies and processes, a comprehensive monitoring system can be developed.
Top of page
Appendix A: Excluding Unnecessary Events

The events listed in the following table are typically excluded from security monitoring queries because of their frequency and because they do not usually provide any useful results when included in a security monitoring solution.

Table A1. Unnecessary EventsEvent ID Occurrence Comments

User Logoff
This event does not necessarily indicate the time that a user has stopped using a system. For example, if the computer is shut down or loses network connectivity it may not record a logoff event at all.

A Handle to an Object Closed
Always records as a success.

Client Context Deleted by Authorization Manager
Expected occurrence when Authorization Manager is in use.

Process Generates Nonsystem Audit Event with Authorization Application Programming Interface (AuthZ API)
Expected activity.

Privilege Service Called, Privileged Object Operation
These are high volume events, which typically do not contain sufficient information to act upon since they do not describe what operation occurred.

A Handle to an Object was Duplicated
Expected activity.

Indirect Access to an Object was Obtained
Expected activity.

Backup of Data Protection Master Key
Expected activity. Occurs every 90 days under default settings.

Recovery of Data Protection Master Key
Expected activity.

Kerberos AS Ticket Request
Does not contain any additional information if audit details from logon events 528 and 540 are already being collected. This event records that a Kerberos TGT was granted, actual access will not occur until a service ticket is granted, which is audited by Event 673. If the PATYPE is PKINIT, the logon was a smart card logon.

Account Logon
Activity already recorded by other events.

Password Policy Checking API Called
Expected activity.

Forest Namespace Collision
This event is not security related.

Trusted Forest Information Added, Deleted, or Modified
Expected activity. These events should not be confused with the addition, modification, or deletion of the trust itself.

Various Active Directory Replication Events
These events are not security related.

Note There are some risks associated with the exclusion of any information from an audit, but this level of risk should be compared to the benefits involved with reducing the load on an analysis agent.
Top of page
Appendix B: Implementing Group Policy Settings

This appendix should be used to check the current settings in an environment, and includes additional settings that affect security monitoring and attack detection. To configure Group Policy security audit events properly, the settings in the following table need to be applied.

Table B1. Group Policy Security Audit SettingsPolicy path Policy Policy setting and comments

Local Policies/ Audit Policy
Audit Account Logon Events
Enable audit success for all computers because this event records who accessed the computer. Enable audit failures with caution because an attacker with network access but no credentials could launch a Denial of Service attack (DoS) by forcing a computer to consume resources while recording these events. Enable audit success with caution as well because this setting can result in DoS attacks if computers are set to shut down when audit logs are full. Correlate any administrator logons with any other suspicious entries.

Local Policies/ Audit Policy
Audit Account Management
Enable both success and failure events. Correlate all successful audit entries with administrator authorizations. All failures should be regarded as suspicious.

Local Policies/ Audit Policy
Audit Directory Service Access
The Default Domain Controllers Group Policy enables this setting by default. Configure audit settings on sensitive directory objects by use of system access control lists (SACLs) in Active Directory Users and Computers or Active Directory Services Interface Editor (ADSI Edit). You should plan your SACL implementation, and you should test your SACLs in a realistic lab environment before deploying them to a production environment. This approach prevents overload of the security logs from too much data.

Local Policies/ Audit Policy
Audit Logon Events
Enable audit success for all computers because this event records who accessed the computer. Enable audit failure with caution because an attacker with network access but without credentials could create a DoS situation by generating excess failures.

Local Policies/ Audit Policy
Audit Object Access
Use caution when enabling this setting because it can result in very high audit volume. Configure audit settings only for high-value folders via SACLs, and only audit the specific types of access that are of interest. If possible, only audit write events and not read access events.

Local Policies/ Audit Policy
Audit Policy Change
Enable both success and failure auditing. Cross-correlate any success events with administrative authorizations.

Local Policies/ Audit Policy
Audit Privilege Use
Do not enable auditing for privilege use because of the high volume of events that this configuration would generate.

Local Policies/ Audit Policy
Audit Process Tracking
Enable this setting on vulnerable computers and immediately investigate unexpected application activity, by isolation of the system if necessary. Do not enable this setting on Common Gateway Interface (CGI) Web servers, test systems, servers that run batch processes, or developer workstations because this setting can cause event logs to fill up.

Local Policies/ Audit Policy
Audit System Events
Enable both success and failure auditing.

Local Policies/ User Rights Assignment
Generate Security Audits
This setting is assigned by default to Local System, Local Server, and Network Service. This right should not apply to any accounts other than service accounts. An attacker can use this setting to generate spurious or inaccurate events in the security log.

Local Policies/ User Rights Assignment
Manage Auditing and Security Log
Use this setting to restrict administrators from making changes to audit settings on files, folders, and the registry. Consider creating a security group for administrators who are permitted to change audit settings and remove the administrators group from the Local Security Policy settings. Only members of a security group should be able to configure auditing.

Local Policies/ Security Options
Audit: Audit the Access of Global System Objects
This setting adds SACLs to named system objects such as mutexes, semaphores, and MS-DOS devices. Default settings on Windows Server 2003 do not enable this option. Do not enable this setting because it results in a high volume of events.

Local Policies/ Security Options
Audit: Audit the use of Backup and Restore Privilege
Backup and restore operations provide an opportunity to steal data by circumventing ACLs. Do not enable this setting because it results in a very high volume of events.

Local Policies/ Security Options
Audit: Shut Down System Immediately if Unable to Log Security Events
Only enable this setting after careful consideration and only on high-value computers, because attackers can use this setting to launch DoS attacks.

Event Log
Maximum Security Log Size
Recommended settings depend on projected event volumes and the settings for retention of security logs. This setting can only use increments of 64 KB and the average event size is 0.5 KB. In high volume environments this setting can be configured as high as 250 MB, but the total size of all event logs combined cannot exceed 300 MB.

Event Log
Prevent Local Guest Groups from Accessing Security Log
Windows Server 2003 enables this setting by default, do not change.

Event Log
Retain Security Log
Only enable this setting if the selected retention method is “Overwrite events by days.” If an event correlation system that polls for events is used, then ensure that the number of days is at least three times the poll frequency to allow for poll cycle failures.

Event Log
Retention Method for Security Log
Enable the Do Not Overwrite Events setting in high security environments. If this is the case, then establish procedures to empty and archive logs regularly, particularly if Shut Down System Immediately if Unable to Log Security Audits is enabled.