Guilty Pleasures, Social Networks, and Event ID's

So, one of my guilty pleasures is I like to read and answer the Information Security questions people ask on LinkedIn. It's like infosec Jeopardy without having to go to Vegas. Sometimes I even know the answer and have time to post it. The other day was one, and I'll share it here in a little more detail.

Venkatesh asks: "What are you monitoring on Active Directory/SQL Server as part of IT compliance?"

The cool thing about Microsoft EventLog format is the Event ID field, which for the most part tells you what is happening, and the details are things like who or what is doing that thing to who- or what-else. An example is Event ID Security:628. Any time you see that code, you know that A changed the password of B, and it is possible that A == B or A != B.

So get your left pinky finger ready for Ctrl-C & Ctrl-V action. Here's my big list of Security EventLog ID's that you should monitor as part of your log review processes.

• EventID == Security:535
• EventID == Security:624
• EventID == Security:628
• EventID == Security:629
• EventID == Security:630
• EventID == Security:631
• EventID == Security:632
• EventID == Security:634
• EventID == Security:636
• EventID == Security:637
• EventID == Security:639
• EventID == Security:641
• EventID == Security:642
• EventID == Security:644
• EventID == Security:647
• EventID == Security:659
• EventID == Security:660
• EventID == Security:671
• EventID == Security:685
• Target Account Name == Administrator
• Target Account Name == [real admin user name] (you renamed Administrator, right?)

Here's how it looks in the ArcSight filter editor:


























In our environment (200+ Windows servers, another 80-100 UNIX servers that authenticate against AD, and 1200+ Windows workstations), this represents about 70-100 events per day out of roughly a half million EventLog entries that we collect per day. That's so totally manageable. The rest of it you can subject to trending, thresholds, and so on to find weirdness worth investigating.

It's also a good idea to go through your EventLog data every couple of months and look for new Event ID's that you haven't seen before. I use a filter that matches all of the Event ID's that I've already identified and excludes them. Then it's just a matter of researching the new Event ID's and determining their cause and relevance.

If you've got other ideas of good EventLog content that you focus on, post it up here. I'd love to hear about it!