Logging for Accountability — Managing Incidents — TryHackMe Walkthrough

Learn about the role accountability plays in logging and incident response

ROOM URL: https://tryhackme.com/r/room/loggingforaccountability

Task 1 Introduction

Logging is used to provide a “source of truth” for activity that occurs on a network. Logging is most commonly used, but not limited to incident response and security monitoring. During the incident response process, a user may be held accountable for an action or behavior, and logging plays a crucial role in proving a user’s actions.

Accountability is the final pillar of the Identification, Authentication, Authorization, and Accountability (IAAA) model. The model is used to protect and maintain confidentiality, integrity, and availability of information.

Accountability holds users and peers on a network responsible for their actions. Logging is a large part of this pillar and maintains a record of activities.

To ensure the efficacy of accountability, logs and other data sources must be protected, and their authenticity must be proved. If it cannot be proven that a log was kept in its original state, it loses its integrity for accountability and the incident response process.

Learning Objectives

• Understand where data originates, how it is stored, and how a security engineer can leverage it.
• Understand why accountability is important to security and how logging can help improve its efficacy.
• Apply logs and other data sources to incident response and the principle of accountability.

Before beginning this room, we recommend you understand logging capabilities and log data sources or complete Intro to Logs. We also recommend a basic understanding of Splunk or complete Splunk Basics.

Throughout this room, we will introduce how logging and data maintain accountability. We will break down best practices and explain accountability in different stages of the incident response procedure.

Answer the questions below

Read the above before continuing to the next task.

Task 2 Importance of Logging and Data Aggregation

Logging aids any member involved in the incident response process. Depending on the log source, it may provide different benefits or visibility into a network or device. Some examples may include:

• Files created.
• Emails sent.
• Other TTPs (Tactics, Techniques, and Procedures) as outlined by the MITRE ATT&CK framework.

Because logs play an important role in incident response, they must be authentic and, when analyzed, identical to when they were produced.

Adding accountability to the incident response process, when log sources are guaranteed to be authentic, a user can be held accountable for their actions, as proven by logs.

This use of accountability is more formally known as non-repudiation and contributes to many threat models, such as the STRIDE model. Non-repudiation means that an individual cannot contest an action, the opposite of repudiation, where an individual disputes an action.

Security Information and Event Management

A Security Information and Event Management system (SIEM) is a tool used to collect, index, and search data from various endpoints and network locations. While this room won’t cover in-depth log analysis and SIEMs, it is important to create a basic level of understanding. We will leverage an SIEM in later tasks to get hands-on with the concepts presented in this room.

SIEMs have many features and capabilities, often for specific use cases. Below is a summary of the benefits and features that an SIEM can offer at the most basic level:

• Real-time log ingestion.
• Alerting against abnormal activities.
• 24/7 monitoring and visibility.
• Data insights and visualization.
• Ability to investigate past incidents.

Examples of SIEMs may include Wazuh, Splunk, ELK, and QRadar. For more information, check out Auditing and Monitoring.

Answer the questions below

2. A user being held accountable for their actions, as proven by logs, is known as what?

Non-repudiation is a security principle ensuring that an individual cannot deny the authenticity of their actions or communications. This concept is achieved through the use of accurate, tamper-proof logs that provide evidence of activities. It is particularly vital in incident response and legal investigations, where accountability is critical.

Answer: non-repudiation

Consider an insider threat scenario where an employee improperly accesses sensitive data. If the organization’s logging system captures the specific time, username, and device details of the access, the employee cannot dispute their involvement. This evidence, backed by secure logging practices and a strong SIEM, provides non-repudiation.

Sources:

MITRE ATT&CK Framework: https://attack.mitre.org

STRIDE Threat Model Overview: https://owasp.org/www-community/Threat_Modeling

Security Logging Practices: https://www.cisecurity.org

Task 3 Log Ingestion and Storage

While this room won’t cover in-depth log analysis and SIEMs, it is important to create a basic level of understanding.

SIEMs are typically architected with three components used for searching, indexing, and load-balancing; these components are commonly known as the search head, indexer, and forwarder, respectively.

In this room, our objective is accountability, so we will focus primarily on the indexer and how data arrives from a device to the indexer; this process is commonly known as data ingestion.

• Types of data ingestion
• Agent/forwarder
• Port-forwarding
• Syslog
• Upload

While there are several ways of ingesting data, there tend to be fewer ways to store the data. Although the primary point of failure for accountability is ingestion, storage can be equally challenging.

When dealing with storage concerns, it is often not attackers we must worry about, but technical faults; for example, an index is accidentally deleted, or a storage device is corrupted.

These are a few examples of things to consider when architecting a storage solution for log sources. While keeping this data authentic and secure is important for accountability, it often has overlapping themes with compliance. Compliance and regulations go hand in hand; one such regulation may be that log data must be archived or stored for X amount of time. This plays into accountability again, where non-repudiation must be applied to a log source for compliance. For example, an audit requires the past six months of X log source. As a stakeholder, you must guarantee that those log sources reflect the activity of the network.

One solution to the storage problem is cold storage. Cold storage is a process or standard for storing data, which can be summarized as storing a large quantity of data optimally.

Cold storage is rarely accessed and thus does not require high-performance storage devices. Examples of cold storage may include low-cost hard drives or even tape drives! Conversely, hot storage is data accessed often and requires higher performance, which may consist of solid-state drives and, in some cases, high-performance hard drives. There may be other levels of access and performance throughout the life cycle of data that can be referred to as warm storage.

The standard for how long data stays in each phase will depend on regulatory requirements and company guidelines. An example of a storage process may be that data is stored hot for six months, warm for three months, and cold for three years. Depending on the data, it may be indefinitely stored in cold storage.

Payment Card Industry Data Security Standard (PCI DSS) is one example of a standard that requires audit logs to be stored for a year and kept immediately available for 90 days to remain compliant.

Answer the questions below

3.1 What component of an SIEM is responsible for searching data?

The search head serves as the user interface for querying and analyzing data within the SIEM. It allows security analysts to perform searches, create reports, visualize trends, and investigate incidents by pulling data from the indexer.

Answer: search head

3.2 How many years must all audit data be stored to be PCI DSS compliant?

The Payment Card Industry Data Security Standard (PCI DSS) establishes guidelines to secure cardholder data and ensure robust security practices. One of the key requirements is related to audit log retention, which mandates the following:

1. Retention Period: Audit logs must be retained for at least one year to allow organizations to review historical data in the event of a security incident, forensic investigation, or compliance audit.
2. Immediate Availability: The most recent 90 days of audit logs must be readily available for review. This ensures quick access to data for active investigations or ongoing monitoring.

Why is this Important?

1. Accountability and Non-Repudiation:

Logs provide a detailed record of actions performed within an environment. Retaining them for one year ensures that evidence exists to hold individuals accountable for unauthorized or malicious activities.

2. Incident Response: Security incidents may not always be detected immediately. The one-year retention period ensures that older logs can still be analyzed for indicators of compromise (IOCs) or patterns leading up to an incident.

3. Compliance with Regulatory Standards: The one-year retention period aligns with legal and regulatory requirements for protecting sensitive information and ensuring transparency.

4. Audit Readiness: Logs are essential during compliance audits. An inability to produce logs within the retention period could result in non-compliance, fines, or loss of certification.

How This Works in Practice

1. Storage Management: Logs for the first 90 days are kept in hot or warm storage (accessible quickly, often on high-performance systems).

Logs older than 90 days but within the 1-year window are typically moved to warm or cold storage (slower but more cost-effective solutions like tape drives or archival disks).

2. Example: A company experiences a data breach and discovers it six months later. To investigate, security analysts rely on logs from 6 months ago, stored in warm or cold storage, to identify the breach timeline and affected systems. Without the 1-year retention requirement, this investigation might not be possible.

Answer: 1

Task 4 Types of Logs and Data Sources

Now that some problems are solved with how data will be sent to an indexer and SIEM solution, we must consider — what makes a good log.

While an SIEM provides excellent functionality, its purpose is to ingest any data and provide an effective and easy way to index and search it.

If a log does not give you the information required for an investigation, it cannot be used for accountability and does not uphold non-repudiation.

Many log sources exist to collect data efficiently with as much relevant information as possible. In this task, we will outline a few of the most common log sources and how they may be used in the incident response process.

• Manual log sources
• Any log that is manually written or composed by an author
• Change logs
• Automated log sources
• Any logs that are automatically generated by default, for example, a configuration, tool, or from a developer
• System logs
• Application logs
• Other types of logs
• Some logs may not be categorized but are often required for compliance
• Email logs
• Messaging or other communication

A good log source may not include only one log. Due to the nature of a network, it may require multiple log types to create one quality log source, for example, a firewall log and a system log used together to hold each other accountable. That is, the validity of one log can be proven using another and vice-versa.

A log source could also be collecting too much information; that is, if several types of logs are collecting the same data or creating the same alerts, it can increase noise, storage complexity, and other consequences.

Answer the questions below

4.1 A change log is an example of what log source?

A change log is an example of a manual log source.

Manual log sources are logs that are written or composed manually by an author.

A change log is typically maintained by developers, system administrators, or project teams to document updates, modifications, or changes to a system or application over time.

Example: A software development team might keep a change log to track new features or bug fixes in each release of their application.

Answer: manual

4.2 An application log is an example of what log source?

An application log is an example of an automated log source.

Automated log sources are generated automatically by tools, systems, or applications without manual intervention.

Application logs are created by applications to record events such as errors, performance metrics, or user actions.

Example: A web server might generate application logs to track requests, responses, and errors, such as HTTP 404 or 500 errors.

Answer: Automated

Task 5 Using Logs Effectively

There are many types of SIEMs to choose from, and each feature and capability can impact how you can use logs effectively. If you are not using a specific feature of an SIEM, it does not signify that you are not effectively using logs, as it depends on log sources and usage requirements. For example, if you are only using logs as an incident response tool and not for real-time monitoring, you may not need or use the real-time feature of some SIEMs.

As briefly introduced in task four, using multiple log types and sources is beneficial for validating logs and creating a complete story of an incident. This concept is more formally known as correlation or building a relationship between two things: logs and data. For example, if a user performed a suspicious action (created a DLL file on the disk), a browser application log could be used to correlate their browser search history with their behavior. If they were searching for a specific installer or troubleshooting process, it may explain the suspicious action. If email logs showed a potential phishing attempt directly followed by the suspicious action, it could cause more investigation. Data enrichment can also be included in correlation efforts.

Answer the questions below

5. What is the process of using multiple log types and sources as part of incident response formally known as?

Correlation involves building relationships between logs and data from different sources to create a comprehensive understanding of an event or incident. By analyzing logs together, investigators can:

1. Validate Information: Cross-check data from multiple sources to confirm its authenticity and reliability.
2. Identify Patterns: Detect suspicious activities by linking seemingly unrelated events.
3. Reconstruct Events: Build a timeline or story of how an incident occurred by piecing together data from different log sources.

Answer: correlation

Real-World Example of Correlation in Incident Response:

A suspicious DLL file is created on a user’s computer.

System logs show the file was created at a specific time.

Browser logs reveal the user searched for an installer or a troubleshooting guide.

Email logs indicate the user received a phishing email with a malicious link shortly before the DLL file was created.

Through correlation, the investigator identifies that the phishing email led to the installation of a malicious file, providing a complete understanding of the incident.

Task 6 Improving Incident Response with Accountability

We have provided web application access to a commonly used SIEM, Splunk. A dataset that contains all the information you need to answer the upcoming questions has already been loaded for you.

In this exercise, we are looking to practice the correlation of log sources and prove accountability’s efficacy.

To access the terminal, deploy the virtual machine attached to this task by pressing the green Start Machine button. Please allow the machine 3–5 minutes to deploy. You can access the web application from your web browser via https://LAB_WEB_URL.p.thmlabs.com/.

Answer the questions below

6.1 How many total events are indexed by Splunk?

Adjust the time range “All Time”

Use the following search query in Splunk to searches across all indexes and counts the total number of events.

index=* | stats count as TotalEvents

OR

Adjusted the time range to span from April 15, 2022, to April 16, 2022. To calculate the total number of events indexed in Splunk for this timeframe:

Answer: 12,256

6.2 How many events were indexed from April 15th to 16th 2022?

Use the following search query in Splunk to filter events to the specified timeframe and counts them.

index=* earliest="04/15/2022:00:00:00" latest="04/16/2022:23:59:59" | stats count as EventsInTimeRange

Answer: 12,250

6.3 How many unique users appear in the data set?

Use the following search query in Splunk to use dc(user) (distinct count) to count the number of unique users in the dataset.

index=* | stats dc(user) as UniqueUsers

Findings:

1. The query determined there are 4 unique users in the dataset.
2. The identified users include:

NT AUTHORITY\SYSTEM

Cybertees\Alberto

NT AUTHORITY\NETWORK SERVICE

Cybertees\James

Each user is shown along with the number and percentage of events they are associated with in the dataset.

Answer: 4

6.4 How many events are associated with the user “James”?

Use the following search query in Splunk to filter events associated with the user “James” and counts them (Cybertees\James).

index=* User="Cybertees\\James"

The query uses double backslashes (\\) to escape the backslash in the username (since Splunk treats a single backslash as a special character).

Answer: 5

6.5 What utility was used in the oldest event associated with “James”?

Use the following search query in Splunk to sort James’s events by the oldest timestamp .

index=* User="Cybertees\\James" | sort 0 _time | table _time, CommandLine, EventID

Details of the Oldest Event:

Timestamp: 2022–04–15 08:06:01

Utility Used: WMIC.exe

Answer: wmic

6.6 What event ID followed process creation events associated with “James”? (Question Hint Look for network connections coming from the same user and process).

Use the following search query in Splunk to lists the process creation events for “James,” including details about the process and its parent.

Scroll down

Process Creation (Event ID 1 or Sysmon’s equivalent of 4688) resulted in the creation of WMIC.exe as a process.

The subsequent Network Connection Event (Event ID 3) indicates that this process (WMIC.exe) attempted or succeeded in making an outbound network connection to IP 172.18.39.6 on port 61249.

Answer: 3