January 20, 2022
Your security response depends heavily on what data you log, and how you log it.
Your security information and event management (SIEM) solution uses logs to build an accurate picture of your organization’s security profile.
When a security event occurs, those logs are vital pieces to the puzzle your security team needs to put together. Audit logs can tell you what happened, where, and when the event began. They can tell you who was logged in when the event occurred and provide meaningful insight into each step taken along the way.
The “what” “where” and “when” questions are incredibly important for effective security event management. However, the modern enterprise security investigation often centers on the “who” questions.
What Data Should Audit Logs Contain?
When your organization has effective, compliant log auditing capabilities, you can quickly pinpoint users responsible for security events. This enables your security team to immediately answer valuable questions about the users associated with those events.
Comprehensive audit logs must not only capture data related to the event itself but offer enough background data to make correlations with users. It’s not enough to collect relevant error messages, event IDs, and user IP addresses. You’ll need to match these data with system log files that tell you:
- When new user credentials were created (and by whom),
- When user accounts are granted access to sensitive data (and by whom),
- When user accounts access sensitive data,
- When accounts change roles or permission levels,
- When database or server configurations change.
In a data breach or ransomware scenario, you may have related event logs that stretch back months before the event itself. The quality of your audit logs determines how successful your investigation can be, which directly impacts compliance reporting and remediation.
Find Out How to Configure Audit Logs Effectively
To get consistent detection results, you must establish good audit log policies. The more comprehensive your logging processes are, the more data your SIEM, UEBA, or SOAR platform has to work with. Castra offers useful resources for successfully configuring audit logs in Linux and Windows:
- Our Windows Audit Policy Basics offer an excellent starting point for improving audit log capture and analysis in Windows systems. It offers in-depth coverage that shows exactly what policies to edit, and which ones you can leave in the default configuration.
- Linux users can refer to our guide to using auditd, showing users how to leverage robust auditing capabilities in RHEL (CentOS) and Ubuntu. This configuration can potentially change existing rules, so it’s worth taking a careful look at how they may impact your system and improve security platform performance.
Collect Your Most Valuable Audit Logs
Since logs are such a vital part of information security event management and investigation, it makes sense to verify which logs your system collects. Your audit policy is automatically set to capture certain information, and you can manually set certain parameters to make better use of your UEBA-powered SIEM platform.
Some of the logs you should pay close attention to include:
- Account Logon. Modern UEBA platforms need logs of Audit Credential Validation as well as Kerberos Authentication Service and Service Ticket Operations logs. You should enable Other Account Logon Events as well.
- Account Management. Account management logs are critical for SIEM 1.0 and UEBA/SOAR platforms alike. These should always be enabled.
- Detailed Tracking. UEBA platforms work best with Audit PNP activity, Audit Process Creation and Termination, and Audit RPC Event logs configured. DPAPI and Audit Token Right Adjusted logs may be advisable in certain cases, but not all.
- DS Access. These are operational logs that may not be necessary for most scenarios and use cases.
- Logon/Logoff. Some of these logs, like Audit Account Lockout, Audit User/Device Claims, and Audit Group Membership are critical and should be enabled. Audit Logoff, Audit Logon, Audit Other Logon/Logoff Events, and Audit Special Logon should also be enabled.
- Object Access. We recommend excluding Audit Filtering Platform Connection, Audit Filtering Platform Packet Drop, and Audit Handle Manipulation. This way the end server administrator can enable these for troubleshooting later. Detailed File Share is an absolute must-have for UEBA systems, but it will significantly increase file server volume, so proceed with caution. Audit File System can also be verbose during patching.
- Policy Change. All of these logs, except for Audit Authorization Policy Change, should be enabled for Success and Failure. Audit Authorization Policy Change can be set to generate audit logs on Failure only.
- Privilege Use. Non-sensitive and Sensitive Privilege Use primarily focuses on Windows rights changing based on user permissions on an action-by-action basis. Most SIEM implementations will go just fine without Privilege Use audits enabled by default, but there may be a place for these audits on a server-by-server basis, particularly for monitoring driver load, and file restore scenarios.
- System. Auditing system events is incredibly important. Audit logs should reflect Success and Failure for Audit Other System Events, Audit Security State Change, Audit Security System Extension, and Audit System Integrity.
- Global Object Access Auditing. These are custom event policies that you can specify and configure with help from our consulting team. There may be good reasons to write custom policies for your organization, but those reasons will depend entirely on the specifics of your security setup, reporting requirements, and industry regulations.
Logging Requirements by Industry Compliance Standards
Every industry has unique logging requirements. These requirements are mandated by the regulatory framework that governs the industry in question. Some of the most common compliance regulations that we help organizations meet include:
The Cybersecurity Maturity Model Certification (CMMC) secures unclassified data stored by Department of Defense contractors. DoD contractors must meet CMMC mandates while holding third-party audited SOC II Type 2 and ISO 27001 certifications.
The Payment Card Industry Data Security Standard (PCI-DSS) protects cardholder data when making purchases from vendors. It includes 12 protocols designed to keep cardholder data safe. Managed detection and response services help organizations identify and prioritize cardholder data vulnerabilities based on severity, enabling fully-compliance threat response and remediation.
The Sarbanes Oxley Act (SOX) is a set of expanded regulatory requirements that public companies in the United States must adhere to. It is primarily designed to prevent public companies from defrauding investors with false financial reports. Public executives must dedicate resources to collecting, monitoring, and analyzing audit logs while performing regular risk assessments to maintain SOX compliance.
23 NYCRR Part 500
The 23 NYCRR 500 is a set of regulatory standards that apply to insurance and banking companies in the state of New York. These standards promote the protection of sensitive customer data and secure the systems that regulated organizations use to process that data. New York-based banks and insurers must develop incident response plans that fulfill 23 NYCRR Part 500 obligations.
The Federal Information Security Modernization Act of 2014 establishes information security policies for civilian agencies operating on behalf of the Federal Government’s Executive branch. This framework provides guidance for the Department of Homeland Security when developing and deploying security policies for these agencies.
All Department of Defense contractors and subcontractors must abide by Defense Federal Acquisition Regulation Supplement (DFARS) rules when storing or processing unclassified data. DoD contractors must develop operating procedures for detecting, analyzing, and responding to security incidents within the DFARS framework before processing data for the DoD.
CIS controls are additional to almost every other security framework. They form a pragmatic basis for developing and assessing security programs in a wide variety of industries. This basis consists of 24/7 monitoring and regular scanning of the entire enterprise IT environment, with real-time alerts that correspond to threats and vulnerabilities throughout the organization.
The Health Insurance Portability and Accountability Act (HIPAA) protects the integrity and confidentiality of patient data in the healthcare industry. It applies to hospitals, clinics, and medical application developers who use, store, and process sensitive patient data. Healthcare organizations implement these safeguards and use customized logging to gain real-time insight into unauthorized access, configuration changes, and privilege escalations.
The Federal Financial Institutions Examination Council (FFIEC) is an inter-agency regulation the US government uses to establish uniform standards for financial institution examinations. These help banks and lenders maintain a unified cybersecurity stance that protects customer data against breaches. Finance institutions must often implement advanced risk management solutions in preparation for these Federal examinations.
Gramm-Leach Bliley Act (GLBA)
The GLBA applies to financial institutions and organizations that provide financial products to consumers, like loans, insurance, and investment advice. It sets strict requirements on how these institutions must protect sensitive data. Financial institutions require broad visibility into threats targeting customer data on multiple fronts, including 24/7 detection and response on remote endpoints, corporate networks, and cloud applications.
This is a US government standard that establishes uniform practices for handling unclassified data, including personally identifiable information and sensitive government assets. Customized reporting solutions help government agencies simplify NIST 800-171 compliance and protect unclassified data more effectively.
The Stop Hacks and Improve Electronic Data Security (SHIELD) Act requires businesses that protect private data on New York residents to protect that data in specific ways. 24/7 monitoring and logging services enable organizations to meet SHIELD compliance requirements in a cost-efficient way. Third-party security service providers are key for effective system maintenance and risk management.
FERPA gives parents and legal guardians specific rights to access student records. These rights transfer to students once they reach the age of 18. FERPA rights include the ability to inspect student records maintained by K-12 institutions, request the correction of inaccurate records, and provide permissions for the disclosure of records.
Implement the Right Audit Logging Solution for Your Organization
Every industry must follow unique regulations to protect customer data and achieve compliance.
Make Castra your managed detection and response partner and gain industry-specific expertise that can help you guarantee your organization meets these stringent security requirements.