Episode 97 — Investigation Data Types: Access, Device, Server, Application, Authentication, Communication, and Audit Logs (4.8)
In this episode, we look at the major log categories used during security investigations and how each one tells part of the story. When something suspicious happens, the first alert is rarely enough to explain the full event. You may know that an account signed in, a file changed, or a system sent traffic somewhere unusual, but you still need supporting evidence to understand what it means. Logs are records of activity, and different logs answer different questions. Access logs can show what someone reached. Device logs can show what happened on a laptop, phone, or workstation. Server logs can show activity on systems that provide services. Application logs can show user actions inside business software. Authentication logs can show sign-in behavior. Communication logs can show how messages and traffic moved. Audit logs can show controlled records of important actions and changes.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
Access logs show attempts to reach resources, and they are often one of the first places an investigator looks when trying to understand who touched what. An access log may record that a user opened a file, viewed a record, connected to a database, reached a shared folder, entered a cloud storage location, or used a protected application. These logs help answer basic but important questions. Who accessed the resource? When did access happen? Was the access allowed or denied? What resource was involved? Did the activity match the person’s normal role? A single access event may not prove anything by itself, but repeated access to unusual resources can be meaningful. If an account suddenly views sensitive data it has never used before, that access pattern may deserve close review.
Access logs are especially useful when an investigation involves possible data exposure or misuse. Suppose a user reports that confidential files may have been viewed by someone who should not have had permission. The access logs can help show whether the files were opened, which account opened them, and when the activity occurred. If the logs include source device or location information, they may also show where the access came from. That helps the investigator decide whether the activity looks like normal work, a permission mistake, or possible account compromise. Access logs can also reveal failed attempts, which matter because denied access may show curiosity, probing, or an attacker trying to find what a stolen account can reach. Allowed access and denied access both help tell the story.
Device logs come from endpoints and other user-facing or operational devices. A device may be a laptop, desktop, mobile phone, tablet, printer, network appliance, or specialized equipment. Device logs can show local sign-ins, software installations, process activity, security tool events, removable media use, hardware changes, errors, crashes, and configuration changes. These logs matter because many incidents become visible at the device level. A phishing email may lead to a malicious file running on a workstation. A stolen laptop may show failed unlock attempts or missing encryption status. A suspicious process may connect to the internet or try to change files. Device logs help investigators understand what happened close to the user or system where activity occurred. They can show whether the device behaved normally or whether something unusual started.
Device logs also help connect human activity to technical evidence. A user might say they opened an attachment, clicked a link, or noticed their computer became slow. The device logs may show what process launched afterward, whether a security tool blocked anything, whether new files appeared, or whether the device connected to an unfamiliar destination. This does not mean the user did something wrong. It means the investigator can line up the user’s report with evidence from the device. Device logs can also show whether a security agent was active, whether updates were missing, or whether local settings changed. These details can matter during root cause analysis because they show not only what happened, but also whether the device had the expected protections in place.
Server logs come from systems that provide services to users, applications, or other systems. A server may host a website, database, file share, directory service, email function, business application, or internal platform. Server logs can show service requests, errors, administrative actions, resource usage, connections, file activity, and system events. They are valuable because servers often sit near important data and business processes. If an attacker compromises a server, the impact can be much larger than activity on a single workstation. Server logs can help investigators identify unusual requests, unexpected restarts, suspicious administrative access, failed service activity, or changes to important configuration files. They can also show whether a server was under stress, which may matter during availability incidents or denial of service investigations.
Server logs often need to be compared with other evidence because server activity can be complex. A web server may show many requests from many sources, and most of them may be normal. A database server may show queries from applications rather than directly from people. A file server may show access from many accounts throughout the day. The investigator needs context, such as which server is affected, what business function it supports, what normal traffic looks like, and whether the activity matches expected patterns. Server logs can help confirm whether an alert involved real interaction with the system. They can also show whether a vulnerability was probed or exploited. In many investigations, server logs provide the middle part of the story between an outside connection, a user account, and the data or service being targeted.
Application logs describe what happens inside software. This is important because applications understand actions that other systems may see only as traffic or file access. An application log might show a password reset request, a shopping cart change, a record lookup, a report download, an administrator setting change, a failed form submission, or an unusual error. A firewall may know that a connection reached the application, but the application log may know what the user did after the connection arrived. This makes application logs especially valuable for business context. If the investigation involves fraud, misuse, data access, or abuse of application features, application logs may provide details that network and device logs cannot. They show behavior at the level where business actions actually occur.
Application logs can also reveal attacks that do not look obvious at the system level. A user may send unexpected input into a form, request records in a strange pattern, try to access another person’s data, or trigger repeated errors that suggest probing. A business application may show a normal sign-in followed by actions that do not fit the user’s role. This can happen when an account is compromised or when permissions are too broad. Application logs also help developers and security teams understand whether a vulnerability affected real users or data. The challenge is that application logs vary widely. Some applications record rich detail, while others record very little. A security program should understand which applications hold sensitive data and make sure their logs are detailed enough to support investigations.
Authentication logs focus on proving identity and tracking sign-in activity. They may show successful logins, failed logins, password changes, Multi-Factor Authentication (M F A) challenges, session creation, session revocation, account lockouts, new device registration, and risky sign-in decisions. Authentication logs are central to investigations because many attacks involve stolen credentials or attempts to gain access as a legitimate user. These logs help answer who tried to sign in, where the attempt came from, whether the attempt succeeded, what factor was used, and whether the behavior matched normal patterns. Repeated failed attempts may suggest password guessing. A successful login after many failures may suggest compromise. A login from a new country or unfamiliar device may deserve review, especially when followed by sensitive access.
Authentication logs are most useful when they are connected to access and activity logs. A sign-in by itself may not be enough to show harm. You need to know what happened after the sign-in. Did the account access sensitive files? Did it create new forwarding rules? Did it change permissions? Did it connect to administrative systems? Did it download large amounts of data? Connecting authentication logs to later actions helps the investigator understand whether suspicious sign-in activity led to meaningful impact. These logs can also help rule out certain concerns. If an account was suspected of compromise but authentication records show no successful access during the time in question, the team may narrow the investigation. Authentication logs help establish the doorway, but other logs show what happened after the door opened.
Communication logs describe messages, connections, and exchanges between people, systems, or services. This category may include email logs, chat records, call records, network communication metadata, Domain Name System (D N S) queries, web proxy records, and Virtual Private Network (V P N) connection records. Communication logs help investigators understand how contact occurred and how information moved. In a phishing investigation, email logs may show who received the message, who clicked a link, and whether similar messages reached other users. In a malware investigation, D N S logs may show a device trying to resolve a suspicious domain. In a remote access investigation, V P N logs may show when a user connected and from what source. These records often help connect separate events into one timeline.
Communication logs can be sensitive because they may reveal relationships, behavior patterns, business discussions, and technical details. Investigators should use them carefully and follow organizational rules, legal requirements, and privacy expectations. The purpose of reviewing communication logs is not casual curiosity. It is to answer specific investigation questions. Did the suspicious message reach other people? Did the device communicate with a known malicious destination? Did an account send unusual messages after compromise? Did data leave through an approved communication channel or an unexpected one? Communication logs can also show direction and volume. A system sending a large amount of data to an unfamiliar external destination may be concerning. A user account sending hundreds of messages after a strange login may suggest account takeover.
Audit logs are formal records of important actions, especially actions that affect security, access, configuration, data, or compliance. They may show who changed a permission, who created an account, who approved a request, who modified a policy, who deleted a record, or who exported data. Audit logs are designed to support accountability. They help answer not only what happened, but also who did it and whether the action was authorized. In many environments, audit logs are especially important for administrative activity. A privileged account changing group membership, disabling a control, or modifying cloud permissions should leave a record. If those records are missing, incomplete, or easy to alter, the organization has a serious visibility problem. Audit logs need protection because attackers may try to hide their actions by changing or deleting evidence.
Audit logs are also important for compliance, internal review, and post-incident reporting. After an incident, the organization may need to show which actions occurred, which controls were changed, and who approved or performed sensitive steps. During an investigation, audit logs can help distinguish a legitimate administrative change from unauthorized activity. For example, a firewall rule change may be harmless if it matches an approved maintenance request and was performed by the expected administrator. The same change may be suspicious if it happened outside a maintenance window, from an unusual account, or without approval. Audit logs become even more valuable when they are tied to ticketing systems, change records, and access reviews. They help turn technical events into an accountability trail that the organization can explain.
The real strength of investigation data comes from correlation, which means connecting related records from different sources. An authentication log may show a successful sign-in from an unusual location. An access log may show that the same account opened sensitive files. A communication log may show outbound traffic to an unfamiliar destination. A device log may show a suspicious process. An application log may show that records were exported. An audit log may show that permissions were changed afterward. Any one of those records gives only a piece of the story. Together, they can show a sequence of actions that makes the event much clearer. This is why centralized logging and a Security Information and Event Management (S I E M) platform can be so helpful during investigations. They make it easier to search across sources and build a timeline.
The main takeaway is that different log types answer different investigation questions. Access logs show what resources were reached or denied. Device logs show what happened on endpoints and other equipment. Server logs show activity on systems that provide services. Application logs show actions and errors inside software where business activity occurs. Authentication logs show sign-in attempts, identity checks, and session behavior. Communication logs show messages, connections, and traffic relationships. Audit logs show controlled records of important actions and changes. No single log category tells the whole story by itself. A strong investigation uses these sources together to understand identity, device behavior, system activity, application context, data movement, and accountability. When you understand what each log type contributes, you can follow an incident from first signal to evidence-based conclusion with much more confidence.
