Log Collection Best Practices
Important Considerations
- Ensure key log sources are collected.
Ensure all Domain Controllers (DCs) in the domain are being collected. List all DCs in the domain and ensure all are configured for security log collection. Missing DCs leaves gaps in visibility, and since you cannot predict which DC will be used for authentication for a set of hosts, or even for a region, it is variable by design in Active Directory.
Ensure appropriate Windows Audit Policies are configured for all DCs and servers. Ensure appropriate policies are configured for all DCs and servers that you are collecting from. This must include Kerberos ticket auditing for best fidelity (Audit Kerberos Authentication Service, and Audit Kerberos Service Ticket Operations). These should be configured for success and failure auditing on DCs.
- Ensure Entities are fully populated. This includes ensuring Entity Networks are created and geolocation information is added, and Entity Hosts are created with DNS, IP, and geolocation information added.
- Enable DNSIPTOName in MPE. DNSIPToName should be set to Resolve Internal. This depends on Reverse DNS Lookup being configured in your DNS. For more information, see the Modify Data Processor Advanced Properties topic in the NextGen SIEM Help.
Recommended UEBA Log Sources
The following describes the log sources that provide the best fidelity data to CloudAI and AIE analytics. This may be used to prioritize which log sources to initially onboard in a deployment in order to build a baseline.
UEBA Anomaly Detection:
The following are the top log source types that provide the best fidelity data to CloudAI:
- Windows Security Logs (AD)
- Windows Security Logs (Local Hosts)
- Any VPN Log Source
- Linux Host Logs (where accounts are AD integrated or otherwise imported into TrueIdentity)
- Any MFA/SSO Log Source
- API - Office 365 Management Activity (if applicable)
Many network device logs produce Common Events in the authentication classifications, but these are typically for authentications to the network device itself. Unless the network administration accounts are fully integrated with a centralized authentication authority, these devices are likely using a shared device account. In this case, the account will not have a TrueIdentity associated with it, and will not be passed to be analyzed. However, if the network devices are integrated to an authentication authority with individual user accounts for network device administration, and those accounts are associated with a TrueIdentity, these logs have high value to UEBA anomaly detection.
AIE Analytics
The following log sources may provide value by helping explain the reason behind what CloudAI reported, and may provide a view together with CloudAI of activity that has security relevance.
- Windows Security Logs (AD)
- Windows Security Logs (Local Hosts)
- Windows Endpoint
- Messaging (Email)
- Proxy
- Firewall (NGFW typically contains user information, others may not)
- Any VPN Log Source
- Linux Host Logs (where accounts are AD integrated or otherwise imported into TrueIdentity)
- Any MFA/SSO Log Source
- Network Devices (where accounts are AD integrated or otherwise imported into TrueIdentity)
Log metadata must contain either User (Origin) Identity or User (Impacted) Identity in order to correlate to a CloudAI log.