Technical security teams often concentrate their event monitoring on network and security appliances, forgetting that the richest source of infrastructure intelligence is the operating system. Read this post to learn how to get the most of our your Windows auditing infrastructure.
No one disagrees that devices such as firewalls and intrusion prevention systems provide early indicators of attack, but the Windows operating system can be configured to proffer a rich audit trail of all user activity, exponentially boosting the security operations team’s visibility of potential security problems. Security operations teams should undertake work to tune their Windows operating system to ensure the information recorded in the security logs is valuable and contextualised to the organisation’s needs. This post looks at Windows Auditing and the basic configuration changes you need to make on your Windows systems to make them produce relevant and meaningful logs.
Windows Auditing: Understanding the Windows Security Logging Subsystem
Windows servers and desktops share several infrastructure services, such as the Active Directory, DNS, networking and file servers. Microsoft application servers share these common directory and networking services too, such as SharePoint, SQL Server and Exchange. By sharing these common services, it’s easy to correlate activity across the entire environment, since user accounts are easily traced as the log in, move to a file server, open email and start working with applications. By collecting the security logs from the audit subsystems on each of these infrastructure servers, it is possible to discover trends and anomalies that are indicative of an attack.
Microsoft’s core directory service, known as Active Directory, is used to store user information and provides the backbone for user authentication. It therefore serves as a valuable source of security auditing and can be configured to alert security managers when high-risk activities occur. By way of example, such an action might occur when a new administrator account is created, or a new user account is added to the Executives security group. If a hacker intended to steal resources that were only accessible by company executives, they would likely try to gain access to those resources by impersonating an executive. To do this, the attacker would look for a way to insert themselves into the appropriate security groups to inherit executive permissions. However, by default, Windows won’t report that a user account has been added to this group, since it doesn’t understand the significance of your “Executives” group. You need to explicitly instruct it to do so. By switching on this capability, the security operations team can then watch these activities and cross-check to see if there is an appropriately authorised change registered with the service desk. If not, the security team can open an investigation.
Windows Auditing: Increase the Event Log Size
Even the simplest of configuration changes, such as increasing the security log file size from 20MB to, for example, 500MB, will reap rewards. The reason is that once your logging system reaches its maximum size, new events overwrite old events and you then lose the history of what went on before. A small security log of 20MB may fill up very quickly, especially on a busy server, such as a domain controller, so you might only have a few days’ worth of information to search through if you need to investigate an incident. For this reason, you need to increase the size to ensure the timeframe you want to retain logs for is covered. If you need it for a month, see how it goes with 500MB and if you need to increase it further, set it to 1Gb. Disk space is cheap, but these security logs are invaluable, so don’t trade one off against the other.
Windows Auditing: Choose Which Events are Required
Now that your log file is big enough to last at least a few months, it’s time to tune the logging subsystem to collect the events that are most relevant to your business. Use threat modelling to determine what information or assets an attacker would be interested in stealing, then look at the path the attacker would use to get to those assets. What systems would that attacker need to connect to and move through to get to the target? When you look at the infrastructure from the point of view of an attacker (and you can always hire a penetration tester to help with this modelling if needs be) you’ll be able to determine which system need to throw up a red flag to let you know it’s happening.
For example, if you have a valuable customer database, the data will be of value on the black market. Ask yourself how an attacker might attack this database – would they use a compromised account or brute force attack to access the system directly? What reconnaissance would they undertake before determining which system to attack? Would they run network scans or attempt to inject commands into the server from another internal system? These scenarios can all be modelled, and you can run tests on the systems along each attack vector to see how each system reacts under attack conditions. If a system does not log something when you expect it should, that’s when it’s time to change its configuration to produce those security events. You’ll find in Windows you can log any activity you can conceive – it’s incredibly rich and granular, you just need to know it’s there and can be done.
Windows Auditing: Group Policy Settings
Group Policies are sets of permissions and attributes that define the behaviour of a group of Windows resources, such as users and computers. The most essential user activities you can log are account logons, lockouts and modifications since these assist your security team in investigating which users are accessing network resources, such as your customer database. You should change the default Group Policy Object (GPO) setting to look like this:
GPO Setting: Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationLogon/Logoff
| Audit Logon |
Success and Failure |
| Audit Logoff |
Success |
| Audit Group Membership |
Success |
| Audit Other Logon/Logoff Events |
Success and Failure |
| Audit Special Logon |
Success and Failure |
These are basic settings and may seem obvious when you look at what they do, but by default this is not how they are set up. So, take the time to switch these on and you’ll immediately get more valuable information about who is logging on and using resources.
Next, you can configure account lockout auditing to help your security operations team detect attacks that attempt to brute force an account. You can set accounts to lock out for a short period of time after three unsuccessful logins, so if an account gets locked, this is either a real user who has simply forgotten their password, or someone trying multiple attempts from a password file. Remember you can also set a timeout period for a lockout – so the account is only locked for five minutes (for example) but this serves to firstly slow down the brute force attack and warn you, while only inconveniencing real users for five minutes if they can remember their password after just mistakenly typing it in. Account lockout auditing is configured as follows:
GPO Setting: Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationLogon/Logoff
Audit Account Lockout Success.
Windows Auditing: More Information
This is just a taste of what you can do with the Windows auditing subsystem. To make the most of the logs you collect, it’s worthwhile researching the value a Security Information and Event Management (SIEM) will bring to your organisation. By configuring your Windows operating systems to report when certain thresholds are crossed, or actions are taken, the logs can then be ingested into your SIEM and the security operations team can orchestrate and automate the response to certain kinds of attacks. If you want more information on what you can do with the Windows auditing subsystem and how you can integrate this with your security operations centre, take a look at Microsoft’s Technet article: Planning and deploying advanced security audit policies
For more information about logging and the value of integrating a SIEM into your security operations capability, check out our case studies here:
https://www.huntsmansecurity.com/resources/#CaseStudies
Alternatively, have a look at the Huntsman Enterprise SIEM’s capabilities here.
Products
Solutions by Industry
Learning & Resources
About Huntsman
