Why Logging and audit trails in Cybersecurity? - Purpose & Use Cases

The Big Idea

What if you could instantly know who did what and when, without digging through messy notes?

The Scenario

Imagine you run a small shop and keep a notebook to write down every sale and visitor by hand.

One day, you need to find out who bought a specific item or when a problem happened, but your notes are messy and incomplete.

The Problem

Writing logs by hand is slow and easy to forget important details.

It's hard to track who did what and when, making it difficult to fix problems or prove what happened.

The Solution

Logging and audit trails automatically record every important action and event in a clear, organized way.

This helps you quickly find answers, spot issues, and keep your system safe and trustworthy.

Before vs After

✗ Before

Write notes on paper for each event

✓ After

Use automated logging tools to record events with timestamps

What It Enables

It makes tracking actions easy and reliable, so you can quickly solve problems and improve security.

Real Life Example

In a bank, audit trails show who accessed accounts and when, helping catch fraud and keep money safe.

Key Takeaways

Manual logging is slow and error-prone.

Automated logs capture detailed, accurate records.

Audit trails help solve problems and protect systems.

Practice

1. What is the main purpose of logging in cybersecurity?

easy

A. To speed up the computer's processing power

B. To record important system and user actions for review

C. To delete old files automatically

D. To block unauthorized users from accessing the system

Solution

1. Step 1: Understand the role of logging

   Logging is used to keep a record of system and user activities.

2. Step 2: Identify the correct purpose

   Logging helps in reviewing actions for security and troubleshooting.

3. Final Answer:

   To record important system and user actions for review -> Option B

4. Quick Check:

   Logging = Record actions [OK]

Hint: Logging means recording actions, not blocking or deleting [OK]

Common Mistakes:

• Confusing logging with access control
• Thinking logging speeds up processing
• Assuming logging deletes files

2. Which of the following is the correct syntax to configure a basic log file in Linux using rsyslog?

easy

A. *.info /var/log/messages*

B. *.info /var/log/messages;

C. *.info > /var/log/messages

D. *.info /var/log/messages

Solution

1. Step 1: Review rsyslog syntax basics

   In rsyslog, the format is: selector action, e.g., '*.info /var/log/messages'.

2. Step 2: Identify the correct syntax

   *.info /var/log/messages matches the correct syntax without extra characters.

3. Final Answer:

   *.info /var/log/messages -> Option D

4. Quick Check:

   rsyslog syntax = selector + space + file path [OK]

Hint: No semicolon or special chars after file path in rsyslog config [OK]

Common Mistakes:

• Adding semicolon at end of line
• Using > instead of space for file path
• Appending extra characters like * after file path

3. Given this snippet from a log file:

2024-06-01 10:15:30 user1 LOGIN SUCCESS
2024-06-01 10:16:05 user2 LOGIN FAILURE
2024-06-01 10:17:00 user1 LOGOUT

What event happened at 10:16:05?

medium

A. User2 failed to log in

B. User1 logged out

C. User1 logged in successfully

D. User2 logged in successfully

Solution

1. Step 1: Read the log entry at 10:16:05

   The log shows 'user2 LOGIN FAILURE' at that time.

2. Step 2: Interpret the event

   This means user2 tried to log in but failed.

3. Final Answer:

   User2 failed to log in -> Option A

4. Quick Check:

   LOGIN FAILURE = failed login [OK]

Hint: Look for LOGIN FAILURE to spot failed login attempts [OK]

Common Mistakes:

• Mixing user1 and user2 events
• Confusing LOGIN SUCCESS with FAILURE
• Ignoring timestamps

4. You configured auditd to log file access but notice no logs are generated. Which is the most likely cause?

medium

A. auditd service is not running

B. The log file is too large

C. The system clock is incorrect

D. The user has admin rights

Solution

1. Step 1: Check auditd service status

   If auditd is not running, no audit logs will be created.

2. Step 2: Rule out other options

   Log file size or system clock issues do not stop logging; admin rights do not prevent logs.

3. Final Answer:

   auditd service is not running -> Option A

4. Quick Check:

   auditd must run to log events [OK]

Hint: Ensure auditd service is active to generate logs [OK]

Common Mistakes:

• Assuming large log files stop logging
• Blaming system clock for missing logs
• Thinking admin rights block logging

5. You want to create an audit trail that records user login and logout times, but only for users in the 'admin' group. Which approach best achieves this?

hard

A. Manually check login times daily for admin users

B. Enable system-wide logging for all users without filters

C. Configure audit rules to watch /var/log/auth.log and filter by admin group users

D. Disable logging for non-admin users

Solution

1. Step 1: Understand audit trail requirements

   We need logs for login/logout only for admin group users.

2. Step 2: Choose filtering method

   Configuring audit rules to watch auth logs and filter by group targets only admin users.

3. Step 3: Evaluate other options

   System-wide logging is too broad; manual checks are inefficient; disabling logging for others may miss events.

4. Final Answer:

   Configure audit rules to watch /var/log/auth.log and filter by admin group users -> Option C

5. Quick Check:

   Audit rules + filtering = targeted logs [OK]

Hint: Use audit rules with filters to log specific user groups [OK]

Common Mistakes:

• Logging all users wastes resources
• Relying on manual checks is error-prone
• Disabling logs risks missing important events