And Microsoft knows it, too. That's why they've created the Microsoft Audit Collection System (MACS), an almost SMS-like system that rolls all of your servers' security event logs into a single, centralized SQL Server database, where you can query for events, check statistics and more. While MACS is still in beta as of this writing, my understanding is that the final, released product will be considered a part of the base Windows Server 2003 operating system, and will be made available as a freely downloadable feature pack from the Windows Server 2003 Web site.

MACS will prove invaluable to organizations that conduct regular audits of their security logs, as it pulls all of those logs into a central location and makes the events easier to query. While there are third-party products, such as those from NetIQ, capable of performing similar functions, it's always nice to see Microsoft giving us the tools we need to actually use their products effectively.

Architecture
MACS consists of three main pieces:

• An agent, which is Windows service that can run on Windows 2000 and later servers. The agent's job is to collect event log entries and forward them to a collector.
• The collector, then, is a service that runs on a particular Windows 2000 or later computer, designated the Audit Server. The collector gathers the events forwarded from multiple agents, and transfers them to the database. Microsoft is suggesting about one Audit Server per one thousand agents.
• The database is the central repository for collected event data. The database runs on Windows Server 2000 or later, and requires SQL Server 2000. You can put the database on the Audit Server, but if you're running more than a few dozen agents, you should dedicate a separate server to hold the database.

Agents don't work on a batch schedule; they establish a connection with a collector and send new events to it in real time. That means your central events database is never more than a few seconds out of date, and it also underscores the need to have a dedicated Audit Server and database server for large environments. If you're performing a high level of auditing, such as auditing all successful logon events in the domain, you'll be generating tons of events throughout the day, and your Audit Server and database server will need to be up to the challenge.

I suspect that you'll need the full Standard or Enterprise edition of SQL Server 2000 to support MACS in a large environment. While the freely-available SQL Server Desktop Engine, or MSDE, seems to work fine when you've only got a few servers, it probably won't hold up for more than a handful. The MSDE is specifically designed for a low number of connections, and it deliberately throttles itself under high volumes of traffic. It's kind of a way for Microsoft to ensure that you can't run your whole company on the free version of SQL Server, and MACS has the potential to generate enough SQL Server workload to require the full version of SQL Server. That alone puts a price tag on MACS; SQL Server costs a few thousand dollars per processor. If you've already got a SQL Server in your environment with enough spare bandwidth to support MACS, then you can certainly use it. It's also possible that MACS will be tuned to work with the MSDE when it comes out of beta; we'll have to wait and see.

Cool Security Features
One issue with auditing security events has always been the administrator. If the administrator does something bad, he or she can clear the event log before an auditor would notice. MACS kills that ploy, though, because the administrator doesn't necessarily need to have permissions to the central database. Since events are sent to the database in real-time, there's no way for an administrator to get rid of the evidence before it's logged into the database. Once it's in the database, an event is protected from deletion by anyone but an authorized auditor. Essentially, MACS finally splits the administrator and auditor role into two distinct, separate roles.

Agents receive real-time notification of new events by registered with the Event Viewer service, and requesting notification of all new events. One potential thing an administrator could do to conceal his or her actions is to stop the Event Viewer service; doing so will prevent events from being logged to the agent. However, that would be a highly unusual action for an administrator to take, and the Event Viewer service will log events indicating that it's stopped and started. Those events should be considered suspicious and the administrator should be questioned.

MACS has some internal security checks, too. Connections between agents and collectors, for example, are mutually authenticated. This ensures that agents don't send sensitive event log information to a service that's masquerading as a legitimate collector, and it ensures that the collector only accepts events from legitimate agents-preventing potential pollution of the event log database. The actual information exchanged between agents and collectors is encrypted and signed, ensuring that it can't be eavesdropped from the network or altered in transit. The agent and collector also look for unusual gaps in transmitted data, which might indicate that the data was tampered with in transit. MACS clearly shows evidence of Microsoft's new paranoia about security; if MACS had been written two years ago, all of this information would have been transmitted in the clear without a thought given to its security.

To further protect the MACS infrastructure, agent configurations can only be delivered through the collector. In other words, there's no way to configure an agent directly from the server's console; you have to modify agent configuration through MACS' central management interface.

Communications Details
Agents use a DNS SRV record to locate collectors on the network. The SRV record for a collector contains its fully-qualified name, and the port on which it listens for agent connections (TCP 514, by default). Load balancing information is also listed in the SRV record, including weighting and priority information. That's a critical clue to MACS' scalability: It has load balancing built right in, allowing you to run multiple collectors, and allowing agents to automatically switch between them as the workload changes throughout the day. Collectors register their SRV records dynamically, just as domain controllers do.

Agents query for a collector SRV record when they start. If they don't find one, they try again after 15 seconds, then 20 seconds, then a minute, and so on, with the interval doubling each time up to the maximum of 60 minutes. If an agent located multiple potential collectors, it tries them in order based on the priority listed in the SRV records. This process is similar to the way SMTP clients use DNS MX records, trying lower-numbered priorities first. Just like with MX records, collector SRV records can be given the same priorities. In this case, the agent will randomize their weights to select a collector. The agents have a basic algorithm for weighting the collectors and selecting one. Here's how it works:

Suppose two collectors -- A and B -- exist, with equal priorities in their SRV records. A is configured with a weight of 100, while B has a weight of 50. The agent assigns a sequence number to each collector: 1 to 100 for collector A, with the weight of 100, and 101-150 for collector B, with the weight of 50. Each collector then has the same number of sequence numbers as its weight. The agent them selects a random number from within the maximum range of 1 to 150, and uses the collector with the matching sequence number. If the agent randomly selected 52, for example, it would use collector A.

Want to Know More?
MACS isn't production-ready yet, although I suspect it's getting close. In the meantime, MACS is only available to registered beta testers. Keep an eye on the Windows Web site for more release information.