This chapter covers audit logging and review, a critical security control for detecting and investigating incidents. On the CompTIA A+ 220-1102 exam, this topic falls under Domain 2.0 (Security) and specifically Objective 2.2, which requires you to explain common security threats and vulnerabilities, as well as the importance of auditing and logging. Approximately 5-10% of exam questions touch on logging concepts, including log types, retention policies, and review procedures. Understanding audit logging is essential for any IT support professional, as it enables you to trace user actions, identify security breaches, and maintain system integrity.
Jump to a section
Imagine a bank vault with a high-security camera system. Every time someone enters the vault area, the camera records a timestamp, their face, and which door they used. If the vault is ever breached, security reviews the footage to see who entered, when, and whether they had authorization. The camera system doesn't prevent the breach, but it provides the evidence needed to identify the culprit and understand what happened. Similarly, audit logs in IT systems record user actions, system events, and access attempts. They don't block attacks, but they are essential for detecting unauthorized activity, troubleshooting issues, and proving compliance. Just as a bank might keep footage for 90 days, audit logs are retained for a specific period based on policy. And like a camera that can be tampered with, logs must be protected from alteration or deletion. The log review process is like a security guard watching the footage—looking for anomalies, such as a person entering at 3 AM when the vault should be locked. In IT, this is done by security analysts or automated tools that flag suspicious log entries for investigation.
What is Audit Logging and Why Does It Exist?
Audit logging is the process of recording events and actions that occur on a computer system or network. These logs serve as a chronological record of activities, providing evidence for security investigations, troubleshooting, and compliance audits. The primary purpose of audit logging is accountability—if something goes wrong, you can determine who did what and when. Without logs, detecting and understanding security incidents would be nearly impossible.
How Audit Logging Works Internally
Audit logging operates at multiple levels within an operating system. On Windows, the Security log is the primary audit log, managed by the Local Security Authority Subsystem Service (LSASS). When an audited event occurs—such as a user logon, file access, or privilege use—the operating system generates an event that includes: - Event ID: A numeric identifier for the event type (e.g., 4624 for successful logon) - Timestamp: Date and time of the event - User Account: The security principal (user or system account) performing the action - Source: The system or application that generated the event - Details: Specific data about the event, such as the object accessed or the type of access
The event is written to the Security log file (typically %SystemRoot%\System32\winevt\Logs\Security.evtx) in a binary format. On Linux, audit logs are handled by the auditd daemon, which writes events to /var/log/audit/audit.log in a text-based format. The audit subsystem uses rules to define what to log, such as:
-w /etc/passwd -p wa -k passwd_changesThis rule watches the /etc/passwd file for write or attribute changes and tags the events with the key 'passwd_changes'.
Key Components, Values, Defaults, and Timers
Log Types: The three main log types on Windows are Application, Security, and System. The Security log is the most relevant for auditing. On Linux, common logs include /var/log/auth.log (authentication), /var/log/syslog (system events), and /var/log/audit/audit.log (audit events).
Audit Policies: On Windows, audit policies are configured via Group Policy or secpol.msc. Common policy settings include:
- Audit account logon events (success/failure) - Audit logon events (success/failure) - Audit object access (success/failure) - Audit privilege use (success/failure) - Audit process tracking (success/failure) - Audit system events (success/failure) - Event IDs: Key Event IDs for security monitoring include: - 4624: Successful logon - 4625: Failed logon - 4634: Logoff - 4648: Logon with explicit credentials - 4672: Special privileges assigned to new logon - 4688: Process creation - 4719: System audit policy changed - Log Retention: Logs are typically retained for a specific period based on organizational policy and regulatory requirements. Common retention periods range from 30 days to 1 year. The default log size in Windows Event Viewer is 20 MB, with automatic overwrite of older events when full. For compliance, logs should be archived to a secure, centralized log server (e.g., SIEM) and retained for the required duration. - Timestamps: Logs use the system's local time or UTC. It's best practice to use UTC to avoid ambiguity during daylight saving time changes.
Configuration and Verification Commands
Windows:
- View audit policy: auditpol /get /category:*
- Set audit policy: auditpol /set /subcategory:"Logon" /success:enable /failure:enable
- View Security log: Event Viewer (eventvwr.msc) or wevtutil qe Security /c:10 /rd:true /f:text
- Export logs: wevtutil epl Security C:\backup\Security.evtx
Linux:
- Start/stop auditd: systemctl start auditd or service auditd start
- View audit rules: auditctl -l
- Add audit rule: auditctl -w /etc/shadow -p wa -k shadow_changes
- Search audit log: ausearch -k shadow_changes or grep on /var/log/audit/audit.log
- Generate audit report: aureport -l
Interaction with Related Technologies
Audit logging integrates with: - Active Directory: Domain controllers log authentication events (Event ID 4624, 4625) for network logons. These logs are critical for detecting brute-force attacks. - Group Policy: Audit policies can be deployed via Group Policy Objects (GPOs) to enforce consistent logging across all domain-joined systems. - SIEM: Security Information and Event Management systems collect logs from multiple sources, correlate events, and generate alerts. Common SIEMs include Splunk, ELK Stack, and Azure Sentinel. - Windows Event Forwarding (WEF): Allows you to forward events from multiple machines to a central collector for analysis. - Sysmon: A Windows system service that logs detailed process creation, network connections, and file changes to the Windows event log. It is commonly used for advanced threat detection.
Common Pitfalls and Best Practices
Logging too much: Excessive logging can fill disk space and make it hard to find important events. Focus on auditing high-value events like logon attempts, privilege usage, and changes to critical files.
Not protecting logs: Logs must be stored in a secure location with restricted access. If an attacker gains admin access, they may delete or modify logs to cover their tracks. Use write-once media or forward logs to a remote server.
Ignoring logs: Logs are only useful if someone reviews them. Implement automated monitoring and alerting for suspicious events.
Incorrect time synchronization: All systems should use NTP to ensure log timestamps are accurate. Inconsistent times make correlation difficult.
Retention policy violations: Ensure logs are retained for the required period. Automate archiving and deletion to avoid storage issues and compliance failures.
1. Enable Audit Policies
First, determine what events need to be logged based on security requirements and compliance standards. On Windows, use Local Security Policy (secpol.msc) or Group Policy to enable auditing for categories like account logon, logon events, object access, privilege use, and system events. For each category, you can audit successes, failures, or both. For example, to detect brute-force attacks, enable auditing of logon failures. On Linux, install the auditd package and define rules using auditctl. Common rules include monitoring /etc/passwd, /etc/shadow, and /etc/ssh/sshd_config for changes. The audit subsystem will then log any access that matches the rules.
2. Configure Log Storage and Retention
Set the maximum log size and retention behavior. On Windows, open Event Viewer, right-click Security log, and select Properties. Set the maximum log size (default 20 MB) and choose one of three retention actions: overwrite events as needed (default), archive the log when full (do not overwrite events), or do not overwrite events (clear log manually). For compliance, set a larger size (e.g., 1 GB) and configure automatic archiving. On Linux, configure auditd.conf to set max_log_file (e.g., 50 MB) and max_log_file_action (rotate, keep_logs). Also, set space_left_action to email or syslog when disk space is low. Ensure logs are stored on a separate partition from the OS to avoid filling the system disk.
3. Forward Logs to a Central Server
To protect logs from tampering and enable centralized analysis, forward logs to a remote log server. On Windows, configure Windows Event Forwarding (WEF) using a collector-initiated subscription. Create a subscription in Event Viewer on the collector machine, specifying the source computers and events to collect. On Linux, use syslog-ng or rsyslog to forward logs to a remote syslog server. For example, in rsyslog.conf, add: `*.* @logserver.example.com:514`. For audit logs, configure auditd to forward events using audispd plugins like audisp-remote. Centralized logs are essential for SIEM integration and forensic analysis.
4. Monitor and Review Logs Regularly
Periodically review logs for suspicious events. For Windows, look for Event ID 4625 (failed logon) spikes indicating brute-force attacks, Event ID 4672 (special privileges assigned) for privilege escalation, and Event ID 4688 (process creation) for unauthorized software execution. Use tools like Event Viewer filters, PowerShell (Get-WinEvent), or third-party SIEM. On Linux, use ausearch to query audit logs for specific keys or events. For example, `ausearch -k passwd_changes -i` shows human-readable results. Automate monitoring by setting up alerts for critical events, such as multiple failed logons within a short time. A common threshold is 5 failed logons in 5 minutes.
5. Respond to Incidents Using Log Evidence
When an incident is detected, use logs to determine the scope and impact. For example, if a user account is compromised, check Event ID 4624 to see all logon times and from which IP addresses. Correlate with Event ID 4648 to see if explicit credentials were used. Examine process creation events (4688) to see what executables were run. On Linux, check auth.log for SSH login attempts and audit.log for file access. Preserve original logs by making a forensic copy. Document findings and steps taken. Logs are admissible in court if properly handled, so maintain chain of custody. After the incident, adjust audit policies to capture any missed events.
In a large enterprise with 10,000 employees, audit logging is essential for detecting insider threats and meeting regulatory requirements like PCI-DSS or HIPAA. For example, a healthcare organization must log all access to electronic protected health information (ePHI). They enable object access auditing on file servers containing patient records. When a nurse accesses a patient's chart, an event is generated. The logs are forwarded to a SIEM (e.g., Splunk) that correlates access patterns. If a user accesses 100 records in one hour, an alert is triggered. The security team investigates and finds the nurse was browsing records of celebrities—a violation of policy. Without logging, this would go unnoticed.
Another scenario is a financial institution that must comply with SOX. They audit all administrative actions, such as changes to user permissions or system configurations. They use Group Policy to enforce audit settings on all domain controllers. Logs are forwarded to a central Windows Event Collector. The compliance team runs weekly reports using PowerShell to extract events like 4732 (user added to security group) and 4719 (audit policy changed). Any unauthorized changes are flagged. They also retain logs for one year, with automated archiving to a secure file share.
A common issue is log overload. In a large environment, the Security log can fill up quickly if too many events are audited. For instance, enabling 'Audit process tracking' on all systems generates thousands of events per minute. This can cause performance degradation and fill disk space. The solution is to be selective—audit only high-value events and use SIEM to filter noise. Another problem is time skew. If systems don't use NTP, log timestamps from different machines may not align, making correlation difficult. Always configure NTP on all systems and use UTC for logs.
When misconfigured, logs can be lost. For example, if the log size is too small and overwrite is enabled, critical events may be overwritten before they are reviewed. Or if log forwarding fails (e.g., network outage), events are lost. To mitigate, use redundant log servers and monitor log health. Also, ensure that log files are not deleted by attackers. Use file integrity monitoring to detect changes to log files. In production, I've seen attackers delete logs after gaining admin access. To prevent this, store logs on a write-once medium or forward them to a remote server that the attacker cannot access.
For the 220-1102 exam, Objective 2.2 requires you to explain common security threats and vulnerabilities, and the importance of audit logging and review. The exam tests your ability to identify appropriate log types, understand what events to audit, and know how to review logs. Expect scenario-based questions where you must choose the correct action to take when a security event is suspected.
Common wrong answers include: 1. 'Disable auditing to improve performance' – This is wrong because auditing is essential for security. The correct action is to enable auditing on relevant events, not disable it. 2. 'Store logs in the default location without protection' – This is wrong because logs must be secured to prevent tampering. The correct answer involves forwarding logs to a remote server or restricting access. 3. 'Review logs only after an incident' – This is wrong because logs should be reviewed regularly to detect incidents early. The exam emphasizes proactive monitoring. 4. 'Set the log size to maximum without overwriting' – This is wrong because if the log fills up, new events are lost. The correct approach is to archive logs or use a larger size with appropriate retention.
Specific numbers and terms to know: - Event ID 4624: Successful logon - Event ID 4625: Failed logon - Event ID 4634: Logoff - Event ID 4648: Logon with explicit credentials - Event ID 4672: Special privileges assigned - Event ID 4688: Process creation - Event ID 4719: Audit policy change - Default log size: 20 MB on Windows Security log - Retention policy: Overwrite events as needed (default) - Audit categories: Account logon, Account management, Detailed tracking, Directory service access, Logon/Logoff, Object access, Policy change, Privilege use, System events
Edge cases the exam loves:
What if a system runs out of disk space for logs? The system may crash or stop logging. The correct answer is to configure disk quotas or use a separate partition.
What if an attacker clears the Security log? The exam expects you to know that Event ID 1102 (Security log cleared) is generated. You should have a remote log server to preserve evidence.
What if you need to track file access? Enable object access auditing on the file and configure the SACL.
To eliminate wrong answers, focus on the mechanism: audit logging is about recording events for later analysis. Any answer that suggests ignoring logs, disabling auditing, or not protecting logs is incorrect. Always choose the option that increases visibility and security.
Audit logging records events for security, troubleshooting, and compliance.
Windows Security log uses Event IDs like 4624 (successful logon) and 4625 (failed logon).
Default log size is 20 MB; retention default is overwrite when full.
Enable auditing only for relevant categories to avoid log overload.
Protect logs by forwarding to a remote server and restricting local access.
Regularly review logs for anomalies; use SIEM for automation.
Event ID 1102 indicates the Security log was cleared – investigate immediately.
Linux auditd uses rules to monitor files and system calls; logs in /var/log/audit/audit.log.
Retention period must meet regulatory requirements (e.g., PCI-DSS requires 1 year).
Use NTP to synchronize timestamps across systems for accurate log correlation.
These come up on the exam all the time. Here's how to tell them apart.
Windows Event Logging
Uses Event Viewer (eventvwr.msc) and wevtutil for management
Logs stored in .evtx files in %SystemRoot%\System32\winevt\Logs
Audit policies configured via Group Policy or secpol.msc
Key Event IDs: 4624, 4625, 4688, 4672
Supports Windows Event Forwarding (WEF) for centralization
Linux Auditd
Uses auditd daemon and tools like auditctl, ausearch, aureport
Logs stored in /var/log/audit/audit.log (text format)
Audit rules defined via auditctl commands or /etc/audit/rules.d/
Events are identified by type (e.g., SYSCALL, PATH) and keys
Supports remote logging via audisp-remote plugin
Mistake
Audit logging is only needed for compliance, not security.
Correct
Audit logging is a critical security control for detecting and investigating incidents. While compliance often mandates logging, the primary purpose is to provide visibility into system activity, enabling detection of unauthorized access, malware, and insider threats.
Mistake
Enabling all audit categories is best for maximum security.
Correct
Enabling all audit categories generates excessive logs, causing performance degradation and making it hard to find important events. Best practice is to audit only high-value events based on risk assessment, such as logon failures, privilege use, and changes to critical files.
Mistake
Logs are automatically protected from tampering by the operating system.
Correct
By default, logs are stored locally and can be deleted or modified by users with administrative privileges. To protect logs, you must restrict access, forward them to a remote server, or use write-once media. Windows Event Logs can be cleared by admins, generating Event ID 1102.
Mistake
Failed logon events (4625) are not important because they are just users mistyping passwords.
Correct
While some failed logons are benign, a high volume of failed logons from a single source indicates a brute-force attack. Monitoring 4625 events is essential for detecting password guessing attacks. A threshold of 5 failures in 5 minutes is a common alert trigger.
Mistake
Once logs are reviewed, they can be deleted to save space.
Correct
Logs must be retained for the period specified by organizational policy and regulatory requirements (e.g., 90 days, 1 year). Deleting logs prematurely can lead to non-compliance and loss of evidence. Always archive logs before deletion if necessary.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Auditing is the process of configuring what events to record, while logging is the actual recording of those events. In Windows, you enable audit policies to specify which security events (e.g., logon attempts) are written to the Security log. Logging is the output. Think of auditing as the rule and logging as the result.
Open Event Viewer (eventvwr.msc), navigate to Windows Logs > Security, and filter by Event ID 4625. You can also use PowerShell: `Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625}`. Each event shows the account name, source IP, and time of failure.
A Security Information and Event Management (SIEM) system collects logs from multiple sources (servers, firewalls, etc.), normalizes them, and correlates events to detect threats. It provides centralized storage, real-time alerts, and reporting. Examples include Splunk, ELK Stack, and Azure Sentinel. SIEMs are essential for managing logs in large environments.
Retention depends on regulatory requirements and organizational policy. Common periods: 30 days for basic troubleshooting, 90 days for standard security, 1 year for compliance (e.g., PCI-DSS, HIPAA). Always check specific regulations. Logs should be archived to secure storage and deleted only after the retention period expires.
By default, Windows overwrites the oldest events when the log reaches its maximum size. If you choose 'Do not overwrite events', the log stops recording new events until it is cleared or archived. This can cause loss of critical events. Best practice is to increase the log size and configure automatic archiving.
Yes, if they have administrative privileges, they can clear the Security log (Event ID 1102) or delete .evtx files. To prevent this, restrict admin access, forward logs to a remote server, or use file integrity monitoring. A cleared log itself is an alert that an incident may have occurred.
Success auditing logs events where the action was successful (e.g., successful logon). Failure auditing logs events where the action failed (e.g., wrong password). For security, enable failure auditing for logon attempts to detect brute-force attacks. Success auditing is useful for tracking authorized access.
You've just covered Audit Logging and Review — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?