What Is Log source? Security Definition
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
A log source is like a camera that records events happening in a computer system. It creates a list of actions, such as who logged in, what files were accessed, or when an error occurred. Security teams look at these logs to find problems or attacks. Every device on a network can be a log source.
Commonly Confused With
A log aggregator is a system that collects logs from multiple log sources into a central repository. The log source is the origin of the log data, while the aggregator is the destination. For example, a firewall is a log source; a syslog server is an aggregator.
If you think of a library, the log sources are the authors writing books, and the log aggregator is the library that collects them. You need both, but they are different.
An event log is the actual file or record that contains the log entries. The log source is the device or software that generates the event log. For instance, the Windows Security log file (SecEvent.evt) is an event log, while the Windows operating system is the log source that writes to it.
A notebook is the event log (the file), but the person writing in it is the log source. Knowing the difference helps in questions about where to enable logging.
A SIEM is a platform that collects, normalizes, analyzes, and alerts on log data from many log sources. SIEM is not a log source; it is a consumer of logs. Log sources feed data into the SIEM. For example, a web server is a log source; Splunk or ArcSight is a SIEM.
In a factory, the log sources are the machines that produce data, and the SIEM is the control room operator who monitors the data and alarms. Confusing them can lead to wrong answers in architecture questions.
Syslog is a protocol and message format used to transport log data from network devices to a log server. The log source is the device that sends syslog messages, not the protocol itself. For example, a Cisco router uses syslog to send logs, but the router itself is the log source.
Syslog is like the postal service, and the log source is the person sending a letter. The letter is the log message. Understanding this helps in configuration questions.
Must Know for Exams
Log sources appear in a wide variety of IT certification exams, including CompTIA Security+, CompTIA Network+, Cisco CCNA, CISSP, CEH, and AWS Security Specialty. In each exam, the concept is tested at different depths, but the core understanding of what a log source is, how to interpret logs, and how to use them in security operations is consistently important.
For CompTIA Security+ (exam SY0-601 or SY0-701), log sources are explicitly listed under Domain 3.0 (Implementation) and Domain 4.0 (Operations and Incident Response). Exam objectives include identifying different log types (security, application, system, network) and understanding how they are used in monitoring and incident response. You may see questions that ask you to match a log entry to its source (e.g., a Windows Event ID 4625 is from the Security log on a domain controller). You may also be asked to interpret log data to identify an attack, such as recognizing multiple failed login attempts in a short time as a brute-force attack. Scenario-based questions often present a log snippet and ask what action the analyst should take next.
For CompTIA Network+ (exam N10-008), log sources are covered under network operations and troubleshooting. Questions might ask about syslog configuration, log severity levels (emergency, alert, critical, etc.), or how to use logs to diagnose network issues like packet loss or unauthorized access. You need to know how to configure a device to send syslog to a central server and how to read a syslog message to identify the source IP and timestamp.
For CISSP, log sources fall under the Security Operations domain (Domain 7). The exam focuses on audit trails, monitoring strategies, and compliance. You may be asked about the importance of log retention policies, how to protect log integrity (e.g., using write-once media or digital signatures), and how to correlate logs from multiple sources to detect complex attacks. Questions are often scenario-based, requiring you to determine which log sources are most relevant for a given investigation.
For the CEH exam, log sources are part of the footprinting and reconnaissance phase, as well as post-exploitation analysis. You might see questions about analyzing web server logs to find attacker footprints or using Windows Event Logs to identify privileged escalation. CEH emphasizes understanding how attackers clear their tracks (e.g., deleting logs), so you need to know how logs are stored and how to detect tampering.
For AWS Security Specialty, log sources include CloudTrail, VPC Flow Logs, and Amazon GuardDuty. You need to know which service provides which type of log (e.g., CloudTrail records API calls, Flow Logs capture network traffic metadata) and how to configure them for security monitoring. Questions often involve interpreting CloudTrail logs to identify unauthorized API calls or using VPC Flow Logs to troubleshoot connectivity issues.
Common question types across exams include: multiple-choice identifying the log source from a description, matching log entries to attacks, scenario questions asking for the best log source to investigate a specific incident, and performance-based questions where you must configure log forwarding. For example, a Security+ question might say: 'A security analyst sees Event ID 4648 on a server. What does this indicate?' (Answer: A logon attempt using explicit credentials). Or a Network+ question: 'Which syslog severity level indicates a system is unusable?' (Answer: Emergency, level 0). Knowing these details helps you answer accurately and quickly.
Simple Meaning
Think of a log source like a security camera in a store. The camera records everything that happens: when someone enters, when they leave, what aisle they walk down, and if they take something. The camera itself is the log source, and the video footage is the log data. In computers, a log source is any device or program that keeps a record of events. For example, when you log into your email, the email server writes a log entry saying 'User X logged in at 3:15 PM.' That server is the log source. Other common log sources include firewalls, which record every website you visit; routers, which track data flowing through the network; and even your laptop, which logs when programs crash or start up. Security professionals collect logs from many sources to build a complete picture of what is happening on a network. Without log sources, it would be like trying to solve a crime without any witnesses or footage. You would have no idea who did what or when it happened. Each log source provides a unique piece of the puzzle. A web server log tells you about website visitors, while a database log tells you who changed customer records. By combining logs from multiple sources, you can trace an attack from the initial email to the stolen data. Log sources are the foundation of security monitoring, incident response, and compliance audits. They help organizations detect threats, prove who accessed sensitive information, and understand what went wrong after a system failure.
In everyday life, you already understand log sources without realizing it. Your phone logs every call you make and every text you send. Your car's computer logs engine performance and trouble codes. Even your smart thermostat logs temperature changes and when you adjust settings. All of these are log sources. In IT, the concept is exactly the same, just on a larger scale and with more detailed data. A single organization might have thousands of log sources, all generating millions of log entries every day.
To manage all that data, security teams use Security Information and Event Management (SIEM) systems, which collect logs from hundreds of sources into one place. This makes it easier to search for suspicious patterns. For instance, if a firewall log shows a connection from an unknown country at 2 AM, and a nearby server log shows a failed login attempt at the same time, the SIEM can alert a security analyst. Without identifying which log sources are important and how to interpret their data, you would be overwhelmed by noise and miss critical warnings.
Full Technical Definition
A log source in IT security is any entity that produces event records in a defined format, typically timestamped, describing activities or state changes within a system. These sources include operating systems, network devices, applications, databases, security appliances, cloud services, and IoT endpoints. Log sources are fundamental to security monitoring, forensic investigation, and compliance reporting, as they provide an auditable trail of user actions, system events, and network traffic.
Log sources operate by recording events according to local configurations. For example, a Windows system uses Event Logging services to write to Application, System, and Security logs. Linux systems use syslog or systemd-journald to capture messages from the kernel and user-space processes. Network devices like routers and firewalls generate syslog messages defined by RFC 3164 or RFC 5424, which include facility codes, severity levels, and structured data. Application logs may use custom formats or standard frameworks like log4j for Java applications.
Key protocols and standards involved in log aggregation include syslog (UDP port 514, TCP port 6514 for TLS), SNMP traps, Windows Event Forwarding (WEF), and JSON or CEF (Common Event Format) for SIEM integration. Many modern log sources support RESTful APIs to push logs to central collectors. For cloud services like AWS CloudTrail or Azure Monitor, logs are accessible via APIs and can be streamed to SIEM platforms using event hubs or S3 buckets.
Components of a log entry typically include a timestamp, source identifier (hostname, IP address), event type or ID, severity level, user or process account, and a description of the event. For example, a Windows Security Event ID 4625 indicates a failed logon attempt, with details such as the account name, source IP, and logon type. In syslog, the message format includes a PRI (priority), header, structured data, and a message body.
In real IT implementations, organizations configure log sources to forward events to a centralized log management system. This is done by installing agents on endpoints (e.g., Winlogbeat, Sysmon, or osquery), configuring network devices to send syslog to a collector (e.g., rsyslog, Logstash), or enabling API integrations for cloud services. The central system normalizes logs into a common schema for analysis. Without proper log source configuration, critical events may be missed, leading to security gaps. Best practices include enabling verbose logging for security-relevant events, ensuring NTP synchronization so timestamps are accurate, and setting appropriate retention policies for compliance with regulations like PCI DSS or HIPAA.
Exam-accurate detail: In the CompTIA Security+ exam, log sources are covered under domain 3.0 (Implementation) and 4.0 (Operations and Incident Response). Specific exam objectives include identifying log types (security, application, system, network), understanding SIEM functionality, and correlating log data to identify anomalies. In the CISSP exam, log sources are part of the Security Operations domain, focusing on audit trails, monitoring, and evidence collection. The CEH exam emphasizes log analysis for detecting attacker footprints. Understanding the difference between standardized logs (syslog, Windows Event Log) and application-specific logs is critical for these exams.
Real-Life Example
Imagine you are the manager of a large apartment building with 200 units. To keep everyone safe, you install a log source at each entrance. These are not just cameras; they also record keycard swipes, door open alerts, and motion sensors. Each device is a log source. One day, a resident reports that their package was stolen from the mailroom. You check the log source for the mailroom door. The log shows that at 2:17 PM, a keycard belonging to unit 105 was used to enter. Another log source in the hallway camera shows a person walking from the mailroom at 2:19 PM. The log from the elevator shows they went to the third floor. Together, these log sources help you identify that a specific resident might have taken the package. Without each log source, you would have only a partial picture.
Now think of a company network. Each server, firewall, workstation, and cloud application is like an entrance or a camera in the building. A firewall log records every connection attempt, much like a door sensor. A web server log records every request to a website, similar to a check-in desk. An Active Directory server logs every login and privilege change, like an ID badge scanner. When a security analyst investigates a breach, they look at all these log sources to reconstruct the attack timeline. They start with the firewall log showing an incoming connection from a suspicious IP, then check the web server log to see which page was exploited, and finally examine the database log to see if data was extracted.
This real-life analogy also highlights why log sources need careful management. In the apartment building, if the camera is pointing the wrong way or the keycard reader is broken, you lose valuable data. In IT, if a log source is misconfigured or stops forwarding logs, you might miss a critical alert. That is why security professionals regularly test log sources to ensure they are working and sending data to the central monitoring system. They also set retention periods because, just like video footage is overwritten after a certain time, logs can be deleted to save space. Knowing how long to keep logs (often 90 days to 1 year) is a compliance requirement for many industries.
Finally, consider that not all log sources are equal. The camera in the parking lot may have lower resolution than the one inside the lobby. Similarly, a router log gives basic connection info, while a database log provides detailed data access records. Understanding the strengths and limitations of each log source is essential for accurate analysis.
Why This Term Matters
Log sources are the backbone of IT security operations because they provide the raw data needed to detect, investigate, and respond to threats. Without log sources, security teams would be blind to what is happening on the network. Think about it: how would you know if an attacker broke in if you did not have records of login attempts, file changes, or network connections? Log sources turn invisible digital actions into visible evidence. In a typical organization, thousands of log sources generate millions of events every day. A firewall logs every connection, a server logs every user action, and an application logs every transaction. This data is the equivalent of a security camera system for the digital world.
In practical IT contexts, log sources are critical for incident response. When a breach occurs, the first thing a security analyst does is pull logs from relevant sources to answer questions like: When did the attack start? Which user account was compromised? What data was accessed? Did the attacker move to other systems? The answers come from logs. Without them, you are guessing. For example, if a ransom note appears on a server, the analyst checks the server’s security log for unusual logins, the firewall log for suspicious outbound connections, and the endpoint detection log for malware execution. Each log source adds a piece to the puzzle.
Log sources also matter for compliance. Regulations like PCI DSS, HIPAA, and GDPR require organizations to collect and store logs for auditing. An auditor will ask to see logs showing who accessed patient records or credit card data. If you cannot produce those logs, you face fines and reputational damage. Log sources help with performance monitoring. System administrators use application logs to debug errors, network logs to identify bottlenecks, and security logs to spot brute-force attacks. In short, log sources are not just a security tool; they are a fundamental component of IT operations.
For IT certification learners, understanding log sources is essential because nearly every exam includes questions on log types, SIEM implementation, and log analysis. You need to know which log source provides which type of data and how to interpret common log entries. Mastery of log sources shows that you understand how to monitor and secure a network, which is a core expectation for roles like Security Analyst, SOC Analyst, and Network Administrator.
How It Appears in Exam Questions
Exam questions about log sources typically fall into several patterns: identification, interpretation, configuration, and troubleshooting. Understanding these patterns will help you approach questions methodically.
Scenario-based questions: These are the most common. The question describes an incident, and you must determine which log source to check or what the log entry means. For example: 'A user reports that they cannot access the company's web application. The IT team suspects the web server is dropping requests. Which log source should be examined first?' The correct answer is the web server log (e.g., IIS logs or Apache access logs), because it records each HTTP request and response. Another scenario: 'An organization detects unusual outbound traffic from a file server at 3 AM. Which log source would provide the most relevant information about the connections?' The answer is the firewall log, because it tracks all outgoing network connections.
Configuration questions: These ask you to apply settings to enable logging or forward logs. For example: 'A network administrator wants to send syslog messages from a Cisco router to a central log server at 192.168.1.100. Which command should be used?' The answer is 'logging host 192.168.1.100' in global configuration mode. Another example: 'To capture all successful and failed login attempts on a Windows server, which log should be enabled?' The answer is the Security log, with Auditing enabled via Group Policy or secpol.msc.
Interpretation questions: You are given a snippet of a log entry and asked what it means or what attack it indicates. For example: 'A syslog entry shows: Nov 29 10:15:32 webserver sshd[1234]: Failed password for root from 10.0.0.5 port 22. What does this indicate?' The answer: An unsuccessful SSH login attempt to the root account from IP 10.0.0.5. Another example: 'A Windows Event Log shows Event ID 4688 with the command line: 'cmd.exe /c del C:\Users\Public\*.docx'. What is a likely interpretation?' The answer: A user or process executed a command to delete Word documents, possible evidence of data destruction or cleanup.
Troubleshooting questions: These focus on why a log source is not providing expected data or how to fix common issues. For example: 'A SIEM is not receiving logs from a Linux server. The syslog service is running. What could be the problem?' Possible answers: The server is not configured to forward to the SIEM IP, the UDP port 514 is blocked by a firewall, or the syslog format is incompatible. Another example: 'A security analyst notices that Windows Security logs are not capturing logon events. What should be checked?' The answer: The local audit policy settings, specifically 'Audit logon events' must be configured to log success and failure.
Comparison questions: You may be asked to differentiate between log sources. For instance: 'What is the difference between a syslog message and a Windows Event Log?' The expected answer: Syslog uses plain text with a defined format (timestamp, host, message) and is common on Linux/network devices, while Windows Event Log uses a structured XML format with Event IDs and is viewed via Event Viewer. Or: 'Which log source is best for detecting a DDoS attack?' The answer: The network firewall or router logs showing a high volume of incoming traffic from many source IPs.
Exam tips: Always read the question carefully to identify which type of log the scenario points to. Look for keywords like 'failed login' (security log), 'file access' (file server audit log), 'network connection' (firewall log), 'HTTP 404' (web server log), 'CPU usage' (system log). Remember that different devices generate different logs: routers (syslog), Windows servers (Event Log), web servers (access/error logs), databases (transaction logs). Practice reading sample log entries from exam study guides to become comfortable with common formats.
Practise Log source Questions
Test your understanding with exam-style practice questions.
Example Scenario
Imagine you are working as a junior security analyst for a mid-sized company. One morning, the manager tells you that the finance department's file server may have been accessed by an unauthorized person last night. Your task is to investigate using log sources. You start by opening the Windows Event Viewer on the file server. You navigate to the Security log, which records all logon and logoff events. You filter for events between 10 PM and 6 AM. You see an Event ID 4624 (successful logon) at 2:34 AM with the account name 'jsmith.' You know that John Smith works in marketing, not finance, and he usually leaves by 6 PM. This is suspicious.
Next, you check the log source from the network firewall. You look at the firewall logs for outbound connections from the file server's IP address around the same time. You see a connection to an external IP address that is known for hosting malware command-and-control servers, according to your threat intelligence platform. This suggests that after John's account logged in, the server connected to a malicious host. Then, you check the file server's audit logs, which record file accesses. You see that at 2:35 AM, a user with John's account accessed a folder named 'Payroll 2024' and downloaded multiple Excel files.
Now you have a clear picture: John Smith's account was compromised (maybe his password was stolen), the attacker used it to log into the file server at 2:34 AM, downloaded sensitive payroll files, and then established a connection to an external command server. You collect all these log entries from the three log sources (Security log, firewall log, file audit log) and compile them into a timeline. This evidence is used to block the external IP, revoke John's account privileges, and start the incident response process. Without these log sources, you would only have a vague suspicion and no proof.
This scenario mirrors real-world investigations. It shows how multiple log sources work together to provide a complete story. In certification exams, you might be given a similar scenario and asked which log source to examine first or what the next logical step is. The key is to think step by step: identify the incident type (unauthorized access), identify the likely log sources (security log for logins, file audit for access, firewall for network connections), and then analyze the logs to find anomalies. This structured approach is exactly what examiners want to see.
Common Mistakes
Thinking all logs are the same and can be analyzed without context.
Different log sources have different formats and purposes. A syslog message from a router looks very different from a Windows Event Log entry. Applying the same interpretation to all logs leads to missed details and false conclusions.
Learn the common formats for each type of log source (syslog, Windows Event, Apache access log, etc.) and know what each field means. Always identify the source before analyzing the log entry.
Assuming that if a log source is enabled, it is automatically forwarding logs to the SIEM.
Many devices have logging enabled locally but are not configured to forward logs to a central collector. The SIEM may show no data from that source, giving a false sense of security. This is a common issue in real environments.
Verify log forwarding by checking the device's syslog or agent configuration. Test by generating a test event and confirming it appears in the SIEM. Regular audits of log source health are essential.
Ignoring timestamps and time zone differences when correlating logs.
Logs from different sources may use different time zones or may not be synchronized via NTP. A log entry that appears at 10:00 AM from one server might actually correspond to 2:00 PM from another. This makes timeline correlation inaccurate.
Always configure NTP on all log sources. When analyzing logs, convert all timestamps to a common time zone (typically UTC) to avoid confusion. In exams, be aware that timestamps are often given in UTC or local time.
Believing that log sources cannot be tampered with or deleted.
Attackers often try to delete or modify logs to cover their tracks. If logs are stored locally on a compromised system, they can be altered. Assuming logs are immutable can lead to incorrect conclusions.
Implement log protection measures: send logs to a remote, write-once storage (immutable), use log signing, and restrict access to log files. In exams, know that securing log integrity is a key security objective.
Confusing a log source with the log management system itself.
A SIEM or log collector is not a log source; it is a system that aggregates and analyzes logs from many sources. The actual log sources are the devices and applications that generate the logs. Confusing them can lead to incorrect answers about where certain data originates.
Remember: log sources are devices/servers/apps. SIEM is a tool that consumes logs. For example, a firewall is a log source; the SIEM is where logs are sent. Questions asking 'which log source' expect the origination point.
Exam Trap — Don't Get Fooled
{"trap":"In a scenario where multiple log sources show conflicting timestamps, choosing the log source with the most recent timestamp as the 'correct' one.","why_learners_choose_it":"Learners assume that the most recent log entry is the most accurate or relevant, without considering time zone differences or NTP synchronization issues. They also may think that the newer timestamp means the event happened later, but the difference could be caused by clock skew."
,"how_to_avoid_it":"Always check the time zone and NTP synchronization of all log sources. If timestamps conflict, verify the clock settings on each device. In exams, look for clues like 'all servers are set to UTC' or 'NTP is configured.'
The correct approach is to normalize timestamps to a common reference before drawing conclusions. The most recent log might actually be from a system with a fast clock."
Step-by-Step Breakdown
Identify the log source
Determine which device or application will generate the needed data. For example, if you need to see login attempts, the log source is the authentication server (like a domain controller). If you need network traffic, the log source is the firewall or router. This step is crucial because it dictates where to look for data.
Enable logging on the source
Many devices have logging disabled by default. You must enable the appropriate logging feature. On a Windows server, you configure audit policies via Group Policy. On a Linux server, you start the syslog service. On a network device, you use commands like 'logging on' or 'logging buffered'. Without this step, no logs are generated.
Configure log destination
Decide where the log entries will be stored or forwarded. Options include local storage (e.g., a file on the device), a remote syslog server, a SIEM, or a cloud service. Configure the device with the destination IP and port. For syslog, this involves setting the log server address and port (usually UDP 514). For Windows, you may configure Windows Event Forwarding.
Set log retention and size limits
Logs consume disk space. Set a maximum file size or retention period (e.g., keep logs for 90 days). Older logs may be rotated (archived) or deleted. This step ensures that the system does not run out of space and that logs are available for compliance requirements.
Verify log generation and forwarding
After configuration, generate a test event (e.g., a failed login) and check if it appears in the destination. On the source, you can view local logs. On the destination, confirm receipt. This step catches misconfigurations early. For example, if the firewall is blocking the syslog port, logs will not reach the server.
Analyze logs for anomalies
Once logs are flowing, use SIEM or manual inspection to look for suspicious patterns. This includes spikes in failed logins, unusual outbound connections, or changes to system files. Automated alerts can be configured based on thresholds. This step is where the security value of log sources is realized.
Protect log integrity
Ensure that logs cannot be tampered with after generation. Options include sending logs to a write-once storage, using digital signatures, or forwarding to a remote immutable server. Access to logs should be restricted to authorized personnel only. This step is critical for forensic validity and compliance.
Practical Mini-Lesson
Log sources are the starting point for nearly every security operation. In practice, a security professional must understand how to set up, maintain, and troubleshoot log sources to ensure reliable data collection. Let's walk through what you need to know in a real-world context.
First, consider the common types of log sources you will encounter. In a typical corporate network, you have domain controllers that log authentication events (Windows Security log), file servers that log access to sensitive files (via audit policies), web servers that log HTTP requests (access logs), firewalls that log network connections (syslog or proprietary formats), email servers that log message metadata, and database servers that log queries and changes. Each of these has a unique configuration. For example, to enable logging on a Windows file server, you must configure Advanced Audit Policy under the Local Group Policy Editor, specifically enabling 'Audit File Share' and 'Audit Detailed File Share'. Then you must also enable the corresponding audit object access settings. Without both, file access may not appear in the Security log.
On a Linux system, log sources are managed via syslog-ng or rsyslog. The configuration file /etc/rsyslog.conf defines which facilities (e.g., auth, kern, mail) are logged and where they are sent. For security purposes, you would configure authpriv.* to be sent to a remote log server. You must also ensure the rsyslog service is running and set to start on boot. Troubleshooting log forwarding often involves checking the firewall on both the source and destination to ensure port 514 (UDP) or 6514 (TCP/TLS) is open. A common issue is that the log receiver blocks the source IP; checking /var/log/messages on the receiver can reveal connection attempts.
For network devices like Cisco routers or switches, logging is configured via the command line. The basic commands are: logging on (enable logging), logging host 192.168.1.100 (set remote syslog server), logging trap informational (set severity level), and logging source-interface Loopback0 (set source IP for syslog messages). It is also important to set the logging timestamp with 'service timestamps log datetime msec' to include milliseconds. Without that, correlating logs with other sources becomes difficult.
What can go wrong? Many things. Log sources can stop generating logs if the device runs out of disk space, if the logging service crashes, if the system clock drifts, or if the configuration is accidentally reverted. Attackers may also purposely disable logging. For example, an attacker who gains root access to a Linux server might stop the rsyslog service and delete the log files. To guard against this, you should enable remote logging that is write-only from the source, and use a log management system that alerts when a source stops sending data. Logs that are stored locally should be protected with restricted permissions and, if possible, write-once media.
In certification exams, you may be asked to configure a log source or troubleshoot why logs are not appearing. The key is to systematically check: is logging enabled? Is the destination reachable? Are the correct settings applied (e.g., severity level)? Are firewalls blocking the traffic? Also, remember that some devices require you to specify the logging facility and severity level. For example, a Cisco router defaults to logging everything at debugging level, which can overwhelm the server; you typically set it to informational. Practice these commands until they are second nature. Understanding practical log source management will serve you well both in exams and on the job.
Memory Tip
Remember 'SLIP': Source, Log, Integrity, Protect. Source identifies what device, Log enables the feature, Integrity ensures logs are not tampered with, and Protect means secure access.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
CS0-003CompTIA CySA+ →220-1102CompTIA A+ Core 2 →SC-900SC-900 →SOA-C02SOA-C02 →CDLGoogle CDL →ISC2 CCISC2 CC →Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
N10-008N10-009(current version)SY0-601SY0-701(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
What is the difference between a log source and a log file?
A log source is the device or application that creates log entries, such as a web server or firewall. A log file is the actual file on disk where those entries are stored. For example, Apache is a log source, and /var/log/apache/access.log is a log file.
Do I need to enable logging manually on all devices?
Yes, many devices have logging disabled by default. You must configure audit policies, syslog services, or logging tags to start collecting logs. For example, on Windows, you must enable Audit Logon Events via Group Policy.
What is the best log source for detecting malware infections?
Endpoint detection logs (like Windows Event Log for process creation - Event ID 4688) combined with network firewall logs showing suspicious outbound connections are two of the best. Antivirus logs also help.
Why are timestamps important in logs?
Timestamps allow you to create a timeline of events, which is essential for incident response. Without accurate timestamps (synchronized via NTP), you cannot correlate events from different log sources, making forensic analysis impossible.
What happens if a log source stops sending logs?
You lose visibility into that device's activities, which could allow an attacker to operate undetected. SIEM systems can alert you when a log source goes silent (a 'heartbeat' event fails). Regular health checks are crucial.
Can I use the same log source for both performance monitoring and security?
Yes, but you may need to tune the logging level. For security, you want verbose logging for events like failed logins. For performance, you may want only errors. Some organizations use separate log streams for each purpose.
How long should I keep logs?
It depends on compliance requirements. PCI DSS requires 12 months of log history with 90 days immediately available. HIPAA often requires 6 years. In general, a minimum of 90 days is common. Check your industry's regulations.