When considering monitoring network security, most IT Pros may think in terms of IDS/IPS systems (Intrusion Detection/Intrusion Prevention). There are hundreds of hardware and software based solutions that operate on the concept of catching a bad process in the act (IDS) or making it more difficult to do harm on the network (IPS). Microsoft customers that are licensed for System Center have a great tool available to augment any IDS or IPS system, which is the Audit Collection Services (ACS) distributed with System Center Operations Manager.

ACS is complementary to the functions of an IDS or IPS. ACS provides reporting on the compliance of Windows and Linux computers with specific security policies. For example, a common security policy is that the membership of privileged groups, such as Domain Admins, will be kept to a minimum and tightly controlled. ACS reports can validate that membership in privileged groups such as Domain Admins remains as expected over time. ACS also provides some forensic capability to create reports of security events for audit trail investigations.

Deploying ACS

If you have deployed System Center Operations Manager (SCOM) in your organization, you are ready to deploy ACS. For those familiar with ACS in SCOM 2007 R2, there is no functional difference between the ACS in SCOM 2007 R2 and SCOM 2012 regarding auditing of Windows computers. SCOM 2012 does add security event auditing of Linux/UNIX systems out of the box, which is available as an add-on to SCOM 2007 R2. So whichever release of SCOM you have, you are ready to deploy ACS to report on Windows and Linux/UNIX systems.

Management of the ACS feature rides the basic SCOM management server and agent framework. You designate an existing SCOM management server to also be an ACS collector, which creates a dedicated SQL database for that ACS collector. Then you upload the ACS reports to your SCOM management group’s reporting server. Finally you use a task in the SCOM console to activate the auditing agent component (called a forwarder) on SCOM-managed computers and point the ACS forwarders to the ACS collector.

ACS audit data is saved in a database and accessed via reports. The right side of Figure A shows the default auditing reports available for Windows systems. For Linux/UNIX systems, the default reports include the forensic as well as unsuccessful logon attempts, account management, administrator activity, and privileged logon reports.

Figure A

Audit Reports integrated with the System Center Operations Manager console. (Click to enlarge images.)

Getting data into ACS

By default, not much gets audited on a Windows computer; that is not so many events will appear in the Security log of the computer. The way you “dial up” the auditing on a computer is with security policy. In an Active Directory domain environment, this is done with group policy. For workgroup computers, there is a local security policy that can be manually exported and imported to other workgroup computers. Domain and local security policy in Windows have nine categories of audit policy that can be set, as seen in Figure B, a screen shot of a recommended “secure” security policy.

Figure B

Audit policy categories in Windows domain and/or local security policy.

In the Policy Settings column in Figure B, the Success, Failure, or Not Defined settings are those recommended for a default “secure” workstation or server. Applying these settings to the domain and the domain controller group policy in your Active Directory is usually a good idea and safe in terms of not generating too much auditing activity. Consider also using group policy to set a higher maximum size for the Security Log on domain controllers and member servers. A recommended minimum security log size for domain controllers is 160-MB, and for member servers 16-MB.

Run ACS Reports to view audit data

The default setting for ACS is to retain all security audit data for 14 days. Every night at 2 AM, data 15 days old is groomed from the database. You run reports in the SCOM console to view audit data. You can also schedule SCOM to automatically publish the audit reports to network file shares for permanent off-line archiving, or for access by auditors without having to log into any console. Figure C shows what it’s all about: a security audit report, in this case logon counts of privileged users for the last two days.

Figure C

Many of the reports provided by ACS out of the box will contain meaningful data to network security administrators after deploying security policy similar to that shown in Figure B. Other reports, such as the forensic reports, are useful to reconstruct user logon activity across servers. In addition to the logon count of privileged users report seen in Figure C, the following default ACS reports are of obvious value:

  • Access Violation: Unsuccessful logon attempts
  • Account Management: Domain and Built-in Administrators Changes
  • System Integrity: Audit Log Cleared (usually a suspicious sign!)
  • Usage: Sensitive Security Group Changes