IT Update – Windows Event Monitoring: Configuring Your Program

If you have combed through Windows event logs looking for suspicious activity, you know this needle in a haystack approach is not a very effective use of your time. Depending on the size of your environment, Windows can be recording gigabytes of log entries daily. So, how do you implement an effective, efficient network monitoring program that is also cost effective? Fortunately, there are many available tools and services that can help focus your efforts on high-risk areas. But before you consider a third-party tool for monitoring network events, let’s first make sure the important network events are being logged and retained for initial monitoring, as well as for forensics purposes if a potential breach is suspected.

Every event in your Windows network can be captured in the event log depending on the audit settings defined within your environment. By default, Windows does not log most events, so you must specify which event categories to record. Event audit settings can be defined within group policy by main categories (basic settings) or by more detailed event subcategories (advanced settings). It is important to understand that once you define even one advanced event setting, any defined basic settings are no longer in effect. Also, any categories or subcategories of events that are not specifically defined in your group policies will be assigned the Windows default setting, which is typically “no auditing.” To ensure the events you intend to record are in fact recorded in the logs, Snodgrass recommends using the advanced audit settings and defining every event subcategory. Even if you do not want to record certain categories of events, set those categories to “no auditing,” so your intentions are clearly documented. There is a balance to be struck to record the events that have value for monitoring or forensic investigation purposes and those that just use unnecessary disk space without providing much value. Microsoft provides some configuration suggestions (https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations) depending on the security requirements of your organization, but even some of these recommendations may fall short in areas, such as Policy Change and Object Access, and/or forensically if a breach were to occur.

We recommend visiting UltimateWindowsSecurity.com, where you can view logging and monitoring resources and a security log encyclopedia that explains each event and its potential usefulness (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/). Your event audit policies should be set based upon the security needs of you network. It is also good governance to vet your planned event settings through your IT oversight committee. The following chart shows recommendations that can be used as a good starting point when configuring your event policy.

Once you have defined the audit policies within your environment, you should periodically check to make sure events are recording in accordance with your intentions. From a command prompt, you can run the Auditpol command to list the effective policy for that computer. Since settings can differ among domain controllers, member servers, and workstations, the command should be run on a sample of these machines. The syntax is: auditpol /get /category:* >> C:\\auditpol.txt (or specify the output file and path of your choosing). For more information on the Auditpol command syntax, see the following technet.microfoft.com article: https://technet.microsoft.com/en-us/library/cc731451(v=ws.11).aspx.

Another aspect of event monitoring to consider is log retention. You can retain the native logs from Windows or rely on a third-party security information and event management (SIEM) tool to pull and retain events from the native logs. If you do not have a SIEM tool, we recommend archiving the native logs and retaining the logs based upon your forensic and regulatory requirements for your organization.  For example, while GLBA does not specifically dictate a requirement for audit logs, it has a general six-year retention requirement. PCI DSS explicitly requires the retention of audit trail history for at least one year with at least three months of history being immediately available for analysis. Through Administrative Tools, you can set the Event Viewer retention properties for your logs. If you have a SIEM product that pulls events from the native logs, your settings should ensure events are not being overwritten before they are captured. Fortunately, most SIEM products pull events in real-time from the logs, but if you are unsure of the process, consult your SIEM tool vendor. If you are retaining the native logs, we recommend setting the log to archive rather than to overwrite, as seen in the setting below.

Now that you are recording the right events and retaining them per your retention requirements, you will need to determine which events are important for ongoing monitoring purposes. In addition to login and logout events, there are events that record changes to your security environment that should be monitored. Unexpected administrator level events, such as changes to accounts, groups, or policies should be included in your monitoring. There are numerous resources that provide guidance in this area. So, depending on your own monitoring requirements, these recommendations are a good starting point to use in defining your own event reporting requirements.

Microsoft provides the following guidance in this area: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor.

Also, UltimateWindowsSecurity.com recommends including the following events in your reviews:

4624/4625 – Logon locally where user is “Administrator”

4697 – A service was installed in the system

4704 – Authorization Policy Change assigned

4705 – Authorization Policy Change removed

4717 – System security access was granted to an account

4718 – System security access was removed from an account

4719 – Audit Policy change

4720 – A user account was created

4722 – A user account was enabled

4724 – An attempt was made to reset an account’s password

4725 – A user account was disabled

4726 – A user account was deleted

4731 – A security-enabled local group was created

4732 – A member was added to a security-enabled local group

4733 – A member was removed from a security-enabled local group

4734 – A security-enabled local group was deleted

4735 – A security-enabled local group was changed

4738 – A user account was changed

4739 – Other account management events

4740 – A user account was locked out

4767 – A user account was unlocked

4781 – The name of an account was changed

4798 – A user’s local group membership was enumerated

4799 – A security-enabled local group membership was enumerated

4946 – A change has been made to Windows Firewall exception list. A rule was added

4947 – A change has been made to Windows Firewall exception list. A rule was modified

4948 – A change has been made to Windows Firewall exception list. A rule was deleted

6416 – A new external device was recognized by the system

Once you have defined the events to review, you should establish a monitoring procedure that establishes the responsibility, frequency, and the method for the review. Depending on the volume of events you plan to review, you will need to decide on whether event reports or alerts will be used for the review. For a timely and consistent monitoring process, event alerts are the preferred approach. Since the recommended events include various administrator-level activities, the review should be performed by someone who does not have administrator responsibilities on the network. If this is not possible, a dual review should be established. If follow-up is needed on the events being reported, there should be a documented process for investigating and clearing possible unauthorized events. If unauthorized activities are identified through the review, you should have a documented incident response plan to follow.

A properly planned and configured security monitoring process is a critical component of your security program. The goal is to streamline the process to focus on the critical network events for early detection of suspicious activities. There are many other important security functions to perform without spending time hunting through event logs looking for that needle in the haystack.