Logging and audit trails in Cybersecurity - Step-by-Step Execution

Concept Flow - Logging and audit trails

Event Occurs

↓

Log Entry Created

↓

Log Stored Securely

↓

Audit Trail Updated

↓

Review or Alert Triggered

↓

Action Taken or Report Generated

This flow shows how an event is recorded as a log entry, stored securely, updated in the audit trail, and then reviewed or triggers alerts for action.

Execution Sample

Cybersecurity

event = 'User login'
log = []
log.append(f'Event: {event} at time 10:00')
audit_trail = log.copy()
alert = 'No alert'
if 'login' in event:
    alert = 'Alert: Login detected!'

This code logs a user login event, copies it to an audit trail, and triggers an alert if the event is a login.

Analysis Table

Step	Action	Variable/Condition	Result/State Change	Output/Alert
1	Set event	event = 'User login'	event holds 'User login'
2	Initialize log	log = []	log is empty list
3	Append log entry	log.append(...)	log contains ['Event: User login at time 10:00']
4	Copy to audit trail	audit_trail = log.copy()	audit_trail contains ['Event: User login at time 10:00']
5	Initialize alert	alert = 'No alert'	alert set to 'No alert'
6	Check event for login	'login' in event	True
7	Set alert	alert = 'Alert: Login detected!'	alert updated	Alert: Login detected!
8	End	No more steps	Final state set	Final alert: Alert: Login detected!

💡 All steps executed; alert triggered because event contains 'login'

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	Final
event	undefined	'User login'	'User login'	'User login'	'User login'	'User login'	'User login'	'User login'	'User login'
log	undefined	undefined	[]	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']
audit_trail	undefined	undefined	undefined	undefined	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']	['Event: User login at time 10:00']
alert	undefined	undefined	undefined	undefined	undefined	'No alert'	'No alert'	'Alert: Login detected!'	'Alert: Login detected!'

Key Insights - 2 Insights

Why does the alert change only after checking the event content?

Because the alert is initially set to 'No alert' (Step 5) and only updated to 'Alert: Login detected!' after the condition 'login' in event is True (Step 6 and 7), as shown in the execution_table.

Why do we copy the log to the audit trail instead of using the same list?

Copying the log to audit_trail (Step 4) ensures the audit trail is a separate record that won't change if the log list changes later, preserving a secure history.

Visual Quiz - 3 Questions

Look at the execution table at Step 3. What does the log contain?

A ['Event: User login at time 10:00']

B An empty list

C ['Alert: Login detected!']

D ['User login']

💡 Hint

Check the 'Result/State Change' column at Step 3 in the execution_table.

At which step does the alert change from 'No alert' to 'Alert: Login detected!'?

A Step 5

B Step 7

C Step 6

D Step 8

💡 Hint

Look at the 'Action' and 'Output/Alert' columns for alert changes in the execution_table.

If the event was 'File upload' instead of 'User login', what would the alert be after Step 7?

A 'Alert: Login detected!'

B 'Alert: File upload detected!'

C 'No alert'

D Empty string

💡 Hint

Refer to the condition check in Step 6 where 'login' must be in event to trigger alert.

Concept Snapshot

Logging and audit trails record events step-by-step.
Events create log entries stored securely.
Audit trails keep copies for review and security.
Alerts trigger on important events.
This helps track and respond to system activity.

Full Transcript

Logging and audit trails start when an event happens. The event is recorded as a log entry with details like time. This log is stored safely and copied to an audit trail to keep a secure history. The system checks the event content to decide if an alert should be raised. For example, if the event is a user login, an alert is triggered. This process helps monitor system actions and respond quickly to important events.

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