System Management

Monitoring Security Events with MOM

John Orefice

At a Glance:

• Rule Group creation
• Creating event rules
• Setting alerts and notifications
• Viewing and analyzing results

Monitoring your infrastructure for general health and uptime is a complex job in itself. But the typical IT administrator doesn't have such a focused work life. If you're like most administrators, you're

being pulled in a hundred different directions, planning upgrades, maintaining systems, responding to security issues, implementing new technologies—and the list keeps growing.

And then there are tasks related to matters such as ensuring compliance with Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act (HIPAA). These are not to be taken lightly and add yet another level of responsibility to your job. However, if you already rely on Microsoft® Operations Manager (MOM) 2005, you can use it to help simplify your compliance-related tasks.

MOM, a key building block in the System Center family of management products, is designed to simplify monitoring and management of large, heterogeneous IT infrastructures. I'll walk you through the process of creating a new MOM Management Pack that can be used to monitor certain security events in your domain controller (DC) Security event logs. In addition, I'll show you how to generate alerts, send notifications, and view the data needed for SOX- and HIPAA-related reporting.

By using MOM to monitor your Security event logs, you will be in a position to lower the total cost of ownership (TCO) of your infrastructure through trend analysis and compliance reporting, as well as ensuring that your extensive IT investment is secure.

Create Rules, Notifications, and Alerts

Using MOM 2005 to automate monitoring of your event logs is quite simple and can greatly improve the efficiency of how you gather and act upon events in your infrastructure. For the example here, I'll step you through creating the rules necessary to monitor for certain events and create notifications and alerts based on these events. After you've created your Management Pack, I'll discuss viewing and reporting on the data you've gathered.

Processing Rule Group

Whether you're a seasoned MOM user or you're thinking about deploying it for the first time, rule group creation is perhaps the most important task you can learn to do with MOM 2005. The first step in the creation of any fully functional Management Pack (not just those for security) is to create a new Processing Rule Group for the rules that will collect information from the services you will be monitoring. We'll begin our security monitoring the same way.

In the MOM Administrator Console (shown in Figure 1), you can create the event rules, set up alerts based on events in the event logs, specify to which computers this new set of rules will be applied, and set up notifications based on alerts for administrators. On the left-hand side, expand Management Packs, right-click on Rule Groups, and select "Create Rule Group..." from the dropdown menu. You are going to create a new rule group called "Security Monitoring." Type in the name, leaving all other fields set to the default, click Next, and then click Finish.

Figure 1** Administrator Console **

Once the wizard is completed, you are prompted to deploy the new rule group to a group of computers. This is where you specify which computers this set of rules will be applied to. In order to tie this new rule group to a computer group, click Yes. Since you want to monitor the Security event logs on the domain controllers, you need to tie the new Security Monitoring rule group to the DC computer group(s). If your organization is running Windows® 2000 DCs, this group is called Windows 2000 Domain Controllers. Similarly, if your organization is running Windows Server® 2003 DCs, this group is called Windows Server 2003 Domain Controllers. In some cases, you may have more than one type of DC; in such instances you deploy the new rules to both groups. In this example, I'll step you through deployment to a single group, the Windows Server 2003 Domain Controllers group (as shown in Figure 2).

Figure 2** Specifying a DC Group **

Event Processing Rule

Now you need to create the event rules that will be used to capture events as they occur in the DC Security event logs. MOM 2005 makes it easy to automatically deploy rules and Management Packs to systems without administrator intervention. Since you tied the Security Monitoring rule group to the appropriate computer group, the rules you create will be automatically deployed to those servers. In turn, as soon as events that match your rules are generated on your DCs, the events will be collected and the appropriate action taken.

There are five types of event rules that you can create for any given Management Pack: Alert on or Respond to Event (Event), Filter Event (Pre-Filter), Detect Missing Event (Missing), Consolidate Similar Events (Consolidation), and Collect Specific Events (Collection). For this project, I am only going to look at two of these types.

The first type is used to alert on or respond to events and is used when you want to take a specific action when a particular event occurs in the event log. For this example, you will be monitoring the membership of the Domain Administrator group. Due to the controlled state of the Domain Admins group, you want a security alert to be generated if the membership to this group changes unexpectedly.

The second type of rule you'll use here is one that collects specific events that occur, but doesn't take any action—perfect for collecting information for audit reports. I will show you how to configure MOM 2005 to collect events as they occur and then store the events in the MOM OnePoint database and then in the System Center Reporting (MOM Reporting) database for reporting and trend analysis.

For this Management Pack, you are going to use this type of rule to audit for when the password is reset on any account in the domain. You could go a step further and set up a rule to alert you when a password is changed on a high privilege account (such as a Domain Administrator account). Other collection rules that are commonly created are for the deletion and creation of accounts and for failed logon attempts.

At this point, I want to outline the rules that we'll be looking for in the Security event logs of our DCs (see Figure 3). These events, as well as all audit events, are listed and well documented in the Windows 2000 Security Event Descriptions support article. In order for these events to be inserted into the Windows Security event log, the proper auditing needs to be turned on. The directions for doing this are available at "How to enable and apply security auditing in Windows 2000". Figure 4 shows the appropriate level of auditing needed for this example.

Figure 3 Rules Used in Sample Management Pack

Figure 4** Setting Audit Policy **

Now let's create the appropriate event rules in your Security Monitoring rule group. You'll start with a rule for monitoring event ID 641 in the Security event log. Make sure that Rule Groups is expanded in the left-hand side of the MOM Administrator Console, expand the newly created rule group called Security Monitoring, and right-click on the Event Rules section of the tree. Select Create Event Rule... from the dropdown menu, choose Alert on or Respond to Event (Event) from the list, and click Next. In the Data Provider window, make sure to change the Provider name to Security (notice that the Provider type automatically changes to Windows NT® Event Log). After selecting Security, click Next to continue.

The Criteria window is where you define exactly what event in the event log you want to look for. Figure 5 shows the configuration settings for this window. Note that you need to enter some detailed information into the Criteria description. Since you want to look specifically for changes to the Domain Admins group, you need to define the rule to look for this. To do this, click on the Advanced... button and enter the information as shown in Figure 6.

Figure 5** Defining What to Look For **

Figure 6** Entering Advanced Criteria **

When finished, click Close and then click Next until you reach the Alert window. This is where you define the type of Alert that will be generated in response to the event being discovered. Since this is a security-related issue, pick Security Issue from the dropdown box. Figure 7 shows this window with the appropriate information. Click Next, choosing all the defaults until you reach the last screen where you will find the Rule Name box. Here, type Domain Admins Global Group Member Changed, and click Finish.

Figure 7** Setting Alerts **

In addition to this rule, you need to create two more event rules that provide more detail about the change to the Domain Admins group. To do this, you'll create similar rules for event IDs 632 (which will tell you who was added) and 633 (which will tell you who was removed). The processes are identical to the process that we just completed, simply substituting the new event ID numbers in place of event ID 641. Be sure to add the detailed Criteria Description for Domain Admins as before.

As mentioned earlier, the second type of event rule you are going to use will collect information from the event logs, but will not generate an alert. For this example, you will be collecting all events that occur when a user account password is changed. To do this, right-click on the Event Rules section of the Security Monitoring Management Pack, just like you did for the previous event rules. Click on Create Event Rule..., and choose Collect Specific Events (Collection) from the list of rule types. Click Next and pick Security from the Provider name list. On the Parameter Storage screen, make sure to choose Store all event parameters—this ensures that all of the information available in each event is brought over to the MOM database for audit reporting purposes. Click Next, leaving all of the defaults until the last screen where you can specify the Name field. Type User Account Password Set and click Finish.

Once you've finished creating all of the event rules, make sure to read this next step carefully. When you make any change under the Management Packs node in the Administrator Console, you must right-click on Management Packs and choose Commit Configuration Change. This will ensure that the changes are propagated down to the servers for which the rules apply. Without doing this, the new rules you created may never be applied to your domain controllers and, in turn, will never begin monitoring the Security event logs.

Notification Group

The next step is to set up a notification group that contains the users to receive the alerts—this can really benefit the security of your infrastructure. Imagine getting a page after business hours because someone gained control of your DC and added a user to the Domain Admins group. You could immediately take corrective action.

Using the MOM Administrator Con-sole, create a notification group called Security Administrators. Since this is an optional step, I won't go into all the details. You may already know how to do this; if not, you may be able to use one of the built-in notification groups that ship with MOM 2005.

Alert Rule

The last step in building your Management Pack is the creation of an alert rule that responds to the security alert that is generated by the Domain Admins Global Group Member Changed rule. When generated, the alert will show up in the MOM 2005 Operator Console. But due to the severity of an unauthorized change to the Domain Admins group, you should also have the notification sent to the Security Administrators Notification Group. This is where the Alert Rule comes into play.

Expand the Security Monitoring Rule Group, right-click on the section titled Alert Rules, and select Create Alert Rule.... In the Alert Criteria window, set the options as shown in Figure 8. These settings specify that any time a security issue alert is generated from the Security Monitoring rule group, a specific action should take place. In this case, you want to send a notification to the Security Administrators notification group.

Figure 8** Setting Alert Criteria **

To continue, click Next on the Schedule screen. In the Response screen, add the response to be sent. Click Add and choose Send a notification to a Notification Group.... From the dropdown menu, choose Security Administrators and leave all other fields on the other tabs at their default settings. Click OK and then click Next on the Knowledge Base screen. On the General screen, type a name for the new Alert Rule and click Finish. Again, you must right-click on Management Packs in the Administrator Console and choose Commit Configuration Changes.

Now, you can avoid getting alerts about planned changes to your Domain Admins group. MOM 2005 has a feature called Maintenance Mode, which can be turned on by right-clicking on any computer in the Operators Console. By placing a computer into Maintenance Mode, you will suppress alerts from being generated for that computer. (The events will still be collected, though.) Most organizations find this feature extremely helpful during scheduled maintenance windows.

Viewing and Reporting

Now that you've configured MOM to collect and respond to events, you need a way to look at the information both in real-time and for trending purposes. The real-time data is excellent for looking at information as it occurs on a day-to-day basis whereas the trending data is good for running reports that can be used for your own analysis or for SOX and HIPAA compliance.

Operator Console

To look at the alerts in real-time, you need to use the Alerts view inside the MOM 2005 Operator Console. Open the Operator Console and go to the Alerts button in the bottom-left quadrant of the screen (see Figure 9). This brings up a view of all the alerts that MOM has generated based on the events occurring in your environment.

Figure 9 shows MOM-generated alerts, each containing a lot of detailed information. This information was captured by MOM when the event was collected and then inserted into the alert that was generated. It offers a great way to get all the information you need immediately, shortening your time-to-resolution and lowering your TCO.

Figure 9** Alerts Generated by MOM **

You're not creating alerts for all the events being generated. When you're doing event collection, you may want to look at your specific events in real-time. You can look at these in the Events view in Operator Console. With the Operator Console open, click on the Events button to bring up a view of all the events that MOM is collecting in your environment. Figure 10 shows what the events look like; all the information that exists in the event log is copied over to MOM.

Figure 10** Viewing Events **

Reporting Console

MOM 2005 provides an extremely intuitive reporting tool based on SQL Server™ Reporting Services. With it, you can customize reports and schedule automatic offline report generation for delivery via e-mail or shared disk space. If you're interested in finding out more about the capabilities in the MOM 2005 Reporting solution, review the MOM 2005 Conceptual Guide.

I've found that most people are unaware of one of the most versatile reports that MOM 2005 offers right out of the box. This report, called Event Analysis, allows you to view the information on any event that MOM is collecting. In a default MOM Reporting installation, the Event Analysis report can be found within the reporting tool by going to Home | Microsoft Operations Manager Reporting | Operational Health Analysis. Using event 641 as an example, navigate to MOM Reporting, which is available from the Go menu in the Operator Console. After you've filled out all the fields, as shown in Figure 11, scroll to the right and select View Report. You'll see all of the events that occurred matching the criteria you've specified. Many people use reports almost identical to this for audit reporting purposes.

Figure 11** Event Analysis **

In addition, since MOM Reporting is built on SQL Server Reporting Services, you can create your own reports using Visual Studio® (if you're running the MOM Data Warehouse on SQL Server 2000) or using the new Report Builder tool (if you're running the MOM Data Warehouse on SQL Server 2005). For help authoring reports using Visual Studio, see Chapter 8 of the MOM 2005 Management Pack Development Guide.

Wrap Up

MOM 2005 is a robust tool that can be used to monitor many business functions in an IT environment. The Management Pack I've discussed here will monitor the Security event logs on your domain controllers, providing an easy way to meet many of the auditing requirements associated with SOX and HIPAA. However, the techniques outlined here can be applied more broadly. You can create rules to monitor the overall health of your infrastructure and identify potential security threats.

Using these events as a base, you can see how flexible MOM can be to proactively monitor other apps that you always rely on. By creating other Management Packs you'll be able to dramatically increase uptime and meet your Service Level Agreements.

John Orefice is a Technology Solution Professional in the Microsoft Mid-Atlantic States district. He has worked with Microsoft management solutions for several years. He can be reached at john.orefice@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.