In my previous blog article on collecting logs from Windows Servers, I missed a control point which can be very important while getting results from your SEM installation.
Let me make it more clear for you. While trying to write a correlation rule for an event, in which Windows Server Log Configuration is changed, we first found the event id for such action. After finding the event id, we noticed that although the main audit categories are configured correctly to log both successful and failed attempts, the source system actually did not generate any logs. You will find the reason why below.
The way auditing rules are defined has drastically changed from Windows Server 2003 to Windows Server 2008 and later. In Windows Server 2008, you have the 8 main audit policy categories, each with success and failure options as the scheme below shows.
In addition to main categories, in the same screen at the bottom of the menu, another setting called "Advanced Audit Policy Configuration" exists. Under that option the 8 main categories are detailed under 53 subcategories which provides advanced granularity (not comparing with Linux of course).
The important thing is to know which policy items have precedence over the other, the general policy or the more detailed policy? By default, the main categories have precedence over subcategories, even if you configured both. The way how the default behavior is changed and how it should be configured to avoid complications can be found here. The operation is different for domain computers and non-domain computers.
The best and safe approach to deal with this is to configure the audit policy using the detailed options and force the priority on it over the general policy.
Once it is decided that subcategories are going to be used for auditing, it is important to know what subcategories should be chosen with what actions in order to get the right amount of events. Audit categories concerning object access may generate too many logs to be stored and processed and they can produce important numbers when you have a considerable number of servers to monitor. Once again, the top down approach in design of SEM systems show the correct way, only generate the logs that you are going to need or use for correlation rules or compliance.
After a careful analysis of events and documentation, I ended up creating the policy below for my installations. I believe that this policy covers most of the needs but if you consider using it you'd better spend some time to adjust it according to your own needs.
Finally, the policy slightly differs for Active Directory Domain Controllers and the other servers as DS Access category only concerns Domain Controllers. For a non-DC server all the subcategories under DS Access category should be set to "No auditing".
Let me make it more clear for you. While trying to write a correlation rule for an event, in which Windows Server Log Configuration is changed, we first found the event id for such action. After finding the event id, we noticed that although the main audit categories are configured correctly to log both successful and failed attempts, the source system actually did not generate any logs. You will find the reason why below.
The way auditing rules are defined has drastically changed from Windows Server 2003 to Windows Server 2008 and later. In Windows Server 2008, you have the 8 main audit policy categories, each with success and failure options as the scheme below shows.
In addition to main categories, in the same screen at the bottom of the menu, another setting called "Advanced Audit Policy Configuration" exists. Under that option the 8 main categories are detailed under 53 subcategories which provides advanced granularity (not comparing with Linux of course).
The important thing is to know which policy items have precedence over the other, the general policy or the more detailed policy? By default, the main categories have precedence over subcategories, even if you configured both. The way how the default behavior is changed and how it should be configured to avoid complications can be found here. The operation is different for domain computers and non-domain computers.
The best and safe approach to deal with this is to configure the audit policy using the detailed options and force the priority on it over the general policy.
Once it is decided that subcategories are going to be used for auditing, it is important to know what subcategories should be chosen with what actions in order to get the right amount of events. Audit categories concerning object access may generate too many logs to be stored and processed and they can produce important numbers when you have a considerable number of servers to monitor. Once again, the top down approach in design of SEM systems show the correct way, only generate the logs that you are going to need or use for correlation rules or compliance.
After a careful analysis of events and documentation, I ended up creating the policy below for my installations. I believe that this policy covers most of the needs but if you consider using it you'd better spend some time to adjust it according to your own needs.
Finally, the policy slightly differs for Active Directory Domain Controllers and the other servers as DS Access category only concerns Domain Controllers. For a non-DC server all the subcategories under DS Access category should be set to "No auditing".
SYSTEM AUDIT POLICY SETTINGS | |
Category/Subcategory | Suggested Settings |
System | |
Security System Extension | Success and Failure |
System Integrity | Success and Failure |
IPsec Driver | No Auditing |
Other System Events | Failure |
Security State Change | Success and Failure |
Logon/Logoff | |
Logon | Success and Failure |
Logoff | Success and Failure |
Account Lockout | Success and Failure |
IPsec Main Mode | No Auditing |
IPsec Quick Mode | No Auditing |
IPsec Extended Mode | No Auditing |
Special Logon | Success and Failure |
Other Logon/Logoff Events | Success and Failure |
Network Policy Server | Success and Failure |
Object Access | |
File System | Success and Failure |
Registry | Success and Failure |
Kernel Object | Success and Failure |
SAM | No Auditing |
Certification Services | Success and Failure |
Application Generated | Success and Failure |
Handle Manipulation | No Auditing |
File Share | Success and Failure |
Filtering Platform Packet Drop | No Auditing |
Filtering Platform Connection | No Auditing |
Other Object Access Events | No Auditing |
Detailed File Share | No Auditing |
Privilege Use | |
Sensitive Privilege Use | No Auditing |
Non Sensitive Privilege Use | No Auditing |
Other Privilege Use Events | No Auditing |
Detailed Tracking | |
Process Termination | Success and Failure |
DPAPI Activity | No Auditing |
RPC Events | Success and Failure |
Process Creation | Success and Failure |
Policy Change | |
Audit Policy Change | Success and Failure |
Authentication Policy Change | Success and Failure |
Authorization Policy Change | Success and Failure |
MPSSVC Rule-Level Policy Change | No Auditing |
Filtering Platform Policy Change | No Auditing |
Other Policy Change Events | Failure |
Account Management | |
User Account Management | Success and Failure |
Computer Account Management | Success and Failure |
Security Group Management | Success and Failure |
Distribution Group Management | Success and Failure |
Application Group Management | Success and Failure |
Other Account Management Events | Success and Failure |
DS Access | |
Directory Service Changes | Success and Failure |
Directory Service Replication | No Auditing |
Detailed Directory Service Replication | No Auditing |
Directory Service Access | Success and Failure |
Account Logon | |
Kerberos Service Ticket Operations | Success and Failure |
Other Account Logon Events | Success and Failure |
Kerberos Authentication Service | Success and Failure |
Credential Validation | Success and Failure |
No comments:
Post a Comment