When it comes to security, the more information we have, the more easily we can pinpoint malicious activities. Keeping track of all of this information requires security logging. A few years ago when I started in the world of Security Information and Event Management (SIEM), I found that I was missing data that I thought should be there. How naive I was at that point in my career. I believed that Windows systems would log all the necessary events right out of the box. I quickly realized I had my work cut out for me in ensuring all the relevant events in my clients’ systems were being logged, via audit settings.
Security Event Logging
That situation put me into “let’s log everything” mode! Needless to say, that didn’t work well. It was too much data. Yes, there is such a thing. So I started researching what needed to be logged and how to make it happen. Here are are some(not all) of the events that need to be logged:
- New user accounts created
- Security group changes
- Software being installed
- New services being created
- Event logs being cleared (many attackers will do this to hide their dirty deeds!)
- and so so so so much more !!!
So now that we can see those default logging parameters in Windows, simply aren’t enough for a security-centric organization, what do we do about it? The answer is simple. In a domain environment, create a group policy specifically for auditing and apply it to the server and domain controller organizational units (OU’s). For non-domain servers, you should edit the local security policy.
File Event Logging
We don’t want to stop there, do we? No, we don’t! Those logging options will help identify many of the events we care about pertaining to the systems themselves. We also want to know about our data and what’s happening with:
- Attempted access to files by users without permissions
- Attempts to delete files by users without permissions
- Successful deletion of files by users with access
Registry Event Logging
Lastly, we all know how important the registry hive is to Windows. Therefore it would probably be a good idea to audit changes and failed changes to registry keys. This would come in handy during incident response while trying to find out what activities an attacker did while on a target. It would also be good to know when registry key changes happen. We expect them to happen while performing patching and updates, but not during normal functions, so it may point out nefarious activities!
In order to help you set up this auditing, I’ve created a handy little “how-to” video showing how to create the group policies and how to enable directory (folder) level auditing as well as registry auditing. You can check it out here.
We now understand that in a Windows environment we must take extra steps to enable auditing features to ensure all the security-related events we need, are actually being logged. This puts June in the books so I’ll see you in July where we’ll discuss one of my favorite topics, threat hunting!