Beta Man

Microsoft Delivers on Centralized Security

Audit Collection Services provides a scalable means of consolidating security event logs across your enterprise.

• By Don Jones
• 09/01/2004

Security auditors working in Windows environments have been taking a bit of a beating lately. Windows is, after all, a reasonably tough operating system to audit in an enterprise environment. Yes, Windows has a great security event log, and can be configured to log just about everything that happens on the system. But each server's log is a separate entity; there's no built-in way to consolidate logs and provide a single view of the organization's events. Third-party vendors are all over this situation, offering tools that merge event logs into a single database—but until recently a solution from Microsoft hasn't been forthcoming.

Well, it's almost here: Audit Collection Services (ACS), formerly known as Microsoft Audit Collection Services (MACS). The original plan was to offer ACS as a free Feature Pack download from the Windows Server Web site. That decision is being reviewed, and ACS may still be released for free. But having seen it, I can tell you that it's a pretty robust product and there's some justification for charging a small licensing fee.

How it Works
The first step toward centralized security auditing is to install the ACS agent on each server that you want to include in event consolidation. The agent collects security events in real time and forwards them to a collector. The agent runs on Windows Server 2000 and later, so Microsoft isn't leaving you out in the cold if you haven't bought the very latest version of Windows.

The collector, which also runs on Windows 2000 or later, gathers events sent from agents and transfers them into a SQL Server database. Each collector can handle about 1,000 agents and multiple collectors can dump events into the same SQL Server database, keeping everything nice and central.

The database, then, is the central repository for the system, and requires SQL Server 2000. For small environments, the free SQL Server Desktop Engine (MSDE) is fine, but if you have more than a handful of servers you're going to want a full SQL Server license. You can run the database on the same server as the collector but, again, for scalability in larger environments you'll want SQL Server on its own machine. That can place a price on ACS, even if it ends up released as a free download, because a SQL Server license for a dedicated machine costs thousands of dollars.

The load placed on SQL Server is, however, entirely dependent upon the level of auditing: One thousand servers with practically no auditing turned on won't, obviously, generate much overhead for SQL Server. Enable every auditing option on 1,000 servers, however, and expect to see SQL Server get pretty busy dealing with the incoming events from the collectors.

No Avoiding Audits
Because agents work in real time, forwarding events as they occur, it's tough for administrators to fake out the system. Even if an administrator clears the security log after performing some dubious activity, the events will have already been sent to the collector by the time the log is cleared, thus preserving an audit trail—which is increasingly important for companies under regulatory scrutiny for their auditing practices. The agent runs as a service, and can be configured to run as "unstoppable," meaning the service will not respond to requests to pause or stop the service—thus helping ensure that an administrator can't bypass the auditing.

Beta Details Product: Audit Collection Services (ACS) Version reviewed: Release Candidate Current status: Putting in final touches Expected release: TBD; Likely late 2004

One thing an administrator can do is kill the agent's process, thus preventing any further events from being forwarded to the collector in real time. My understanding is that Microsoft is considering placing a discretionary access control list (DACL) on the process, making it impossible for an administrator to kill the process (or at least offering the restrictive DACL as a configuration option). Personally, I wouldn't mind seeing a configuration option that somehow blue-screens the server if the agent process is killed. In some organizations, on some servers, it might be better to have a crashed server—which someone will definitely take note of—than a server that isn't logging security events reliably.

Secure By Design
It's gratifying to see so much detail in Microsoft's implementation of ACS, including features designed to make ACS more robust and foolproof. For example, communications between agents and collectors are always encrypted, preventing data from being changed in transit. Those communications are also mutually authenticated using the Kerberos protocol, ensuring that agents only forward events to designated collectors, and that events appearing to come from, say, Server1, are in fact coming from that server and not being spoofed.

In addition, the collector will only accept connections from authorized agents, meaning it'll be tough for someone to perform a Denial of Service (DoS) attack against a server by using fake agents to overwhelm the collector with bogus events. By only dealing with authorized agents, the collector helps prevent this type of attack against the auditing infrastructure.

The developers and designers of ACS were clearly in paranoid mode, trying to prevent most attacks and circumventions. For example, an administrator might try to reconfigure an ACS agent to stop sending events, or to send events to a bogus collector, thus losing those events in the ether. That trick won't fly, because ACS agents will only accept their configuration information from the collector, ensuring the centralized configuration remains effective.

Watch Your Databases and DNS
The security of the SQL Server database is a potential weak link in the ACS security arsenal, particularly because many companies provide insufficient or overly broad database-level security on their SQL Server computers. That means it's up to you to complete the security circle. The database that stores security events needs to be secured so that Joe Administrator can't just log on with SQL Query Analyze and delete incriminating events. To prevent such actions, you need to ensure that only a particular user account has that capability. That user account should have no other use in your environment, and you should carefully audit the use of that account. Microsoft will likely release other security configuration recommendations along with the ACS documentation.

Wanted: Betas for Review Beta Man is always on the lookout for quality products to review. If you know of a software product that is currently or soon to be in beta, contact Beta Man at [email protected]. Vendors are welcome, but please act early–the meticulous Beta Man needs plenty of lead time.

Your DNS infrastructure represents another potential ACS circumvention point. Agents identify collectors through the use of DNS SRV records; these records contain the collectors' fully-qualified domain name (FQDN) and TCP/IP port (TCP 514, by default). Collectors register these SRV records automatically, just as domain controllers do. If false collector SRV records can be placed into your DNS servers, agents might be tricked into trying to connect to nonexistent collectors. While agents are smart enough not to send any sensitive data to bogus servers, such a trick might prevent an agent from forwarding events to a real collector, thus preventing or delaying the collection of critical events and potentially masking some underhanded activity.

On a brighter note, the SRV records can also contain load-balancing information, such as weight and priority. This allows environments with multiple collectors to set them up in a load-balanced configuration, helping to improve the scalability of the product.

Reporting
Expect ACS to release with a fairly robust set of reports. This is really the heart of the ACS value proposition: While it's nice to have all security events in one database, that won't do you much good without some canned reports to turn all that raw data into useful information. You should be able to build your own reports, as well, using any SQL Server-compatible reporting tool, such as the popular Crystal Reports.

The Bottom Line
Should you look at ACS? Absolutely. As a free product, it's a no-brainer, providing a well-designed, scalable means of consolidating security event logs across your enterprise and a solid auditing tool. Even if Microsoft decides to charge for it, I don't expect it'll charge much, so ACS will still be a worthwhile security tool. Its underlying architecture should serve as a model to other companies developing similar server-agent style products, and it provides a useful function, especially within large Windows environments.