Six Audit Mistakes Everyone Seems To Make With Windows Server

___________________________________________________________________________________________________________________________

IMPORTANT ANNOUNCEMENT FOR OUR READERS!

AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

__________________________________________________________________________________________________________________________

Hi, this is Richard Sasser 'Rick', MCM, Red shirted dude (security guy). This might seem like old data, but you’d be surprised how many people looked at Security Auditing in Windows Server 2008 and 2008R2, saw that the old policies applied, and subsequently just checked the box and moved forward.

Auditing changed. Auditing changed a LOT. If your security team did not redesign your audit policy in 2008, then you absolutely must address this problem. And before you look at me and say, but “surely since 2008 they have…” close thy mouth, blasphemer. They haven’t. There’s a reason I’m writing this in 2014, and that’s because this has started to become a pattern I’m seeing EVERYWHERE. The state of security in the IT World is “We have a whole lot of work to do.” I won’t editorialize on the reasons here, but you might find some editorializing later.

So you might have security auditing problem if:

You have configured your audit policies with Windows 2003’s original 9 policies and let them roll forward

Windows 2003 has nine Auditing categories. Windows 2008 and later have subcategories. There are nine, arguably ten, subcategories. (See HERE). Those subcategories have 53+ settings (more were added later). If you left the nine categories enabled, all you really did was enable every subcategory. Congratulations. If “Object Access” was enabled, you just enabled Filtering Platform Connection. And your server might now be a candidate for EXCESSIVE logging.

You have configured everything (or even just the wrong things) for success and failure

Excessive logging is the equivalent of not logging. I’ve seen windows servers log 3,000 events per second. Yep. Not a typo. While initially the performance of the queue in 2008 and later is asynchronous, under heavy logging the queue becomes synchronous and your performance is gated on the ability to audit. So in the instance above of Filtering Platform Connection, success, you just made your ultrafast SQL, webserver, whatever, as fast as C:\ drive. Not the bottleneck you were looking for? To get an idea of performance you need to measure disk performance on C:\ drive before and after. Transfers/sec, Sec/Transfer and pages/sec counters on the drive that stores the evtx files will generally get you there, but realistically you need before and after trending to validate improvements (Or degradations). This is about RATE. Not Size. Which brings us to:

You have configured your security log to be 4 GB in size because you don’t want to miss anything

Remember that sixteen GB server you bought? Congratulations, you took 4 GB out of it. Security Event logs are memory mapped files (download RAM MAP and see). That’s why pages/sec can be a useful counter. Virtualizing thousands of hosts? Want to save RAM? Might want to set this just a bit lower. Some more, albeit older data is in Recommended settings for event log sizes in Windows Server 2003, Windows XP, Windows Server 2008 and Windows Vista

You configured the audit policy and checked it with GPRESULT /h

More of Mr. Pyle’s wisdom can be found here. The ONLY, and I mean ONLY way to get the actual effective audit policy is to use auditpol /get /category:*. Mr. Pyle also references another important setting in that blog, which is

You have set Audit: Force audit policy subcategory settings to disabled

Information from the same blog, above. You’re looking at never applying the new policies. Everything will be the old policies, which pretty much MEANS all of the subcategories. Try not to do this Smile 

You have configured your log scraping/monitoring/software to catch the three digit id’s you’re looking for

And those droids just slipped right on by. I'm pretty sure getting a "Below Expectations" review in the Empire is a one time event. Security event ID’s were three digits in Windows Server 2003. They’re four digits in Windows 2008 and later. “Testify”, I literally helped a customer years ago, and we notified the monitoring team that the event id’s changed, gave them a spreadsheet of the new event id’s and discussed what we were auditing. Three months later we get a frantic email. “We’re not collecting any audit data from the new servers. What’s the problem?” Well, the answer to that one was “You don’t have a technical issue we can solve, but thanks for contacting us”.

You have given me much think on, Master, where may I find additional wisdom

Excellent, grasshopper. You have snatched the pebble from my hand. Now, additional wisdom may be found in the Security Compliance Manager. This is the official guidance for audit and all security settings from Microsoft. You can also look at Planning and Deploying Advanced Security Audit Polices. And finally, you can download the spreadsheets with all the event ids in:

Security Audit Events for Windows 7 and Windows Server 2008 R2

Windows 8 and Windows Server 2012 Security Event Details

Richard ‘Rick’ Sasser. Sho’nuff.