Security & GRCbeginner

Security Audit Log Fundamentals

Key takeaway

Learn what the ABAP Security Audit Log records, why event selection and retention matter, and how security teams use the log as evidence rather than as a replacement for business context.

Explanation

📌 KEY POINTS
✅ The log proves an event occurred — it does not by itself prove intent. Correlate with transport, change, and emergency-access evidence.
⚠️ Recording everything without sizing creates volume problems; recording too little creates blind spots.
💡 Access to audit configuration must itself be restricted — privileged admins should not be able to disable monitoring casually.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHAT IT RECORDS

Security-relevant events in an ABAP system — successful/failed logons, user administration, other security-sensitive activity depending on configuration and release

━━━━━━━━━━━━━━━━━━━━
▶ 2. SCOPING IT DELIBERATELY

Select relevant event classes and user/system scope according to risk — this is a deliberate design choice, not a default to leave alone

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. PROTECTING THE LOG ITSELF

Access to audit configuration and logs must be restricted
Privileged administrators should not be able to disable monitoring casually and erase accountability

━━━━━━━━━━━━━━━━━━━━
▶ 4. RETENTION AND CORRELATION

Retention should support investigation and compliance needs
Forwarding to a SIEM improves correlation, but local log health still needs monitoring
An event proves an action occurred — not malicious intent; investigations correlate it with transport, change, emergency-access and business evidence

✅ CHECKPOINT: explain why "the log shows it happened" is not the same as "the log proves why."

Real project scenario

Configure logging for failed privileged logons, then review events and correlate them with a known test account to understand what the log can and cannot prove.

Common mistakes

Enabling every event without sizing.
Keeping retention too short for investigations.
Giving monitored administrators unrestricted log control.
Assuming no record means no activity without checking log health.
Treating one event as proof of motive.

Best practices

Select events by risk.
Protect audit configuration.
Monitor log health.
Set retention deliberately.
Correlate audit events with other evidence.

Interview angle

Explain purpose, event selection, retention, access control and SIEM integration.

Practice this lesson

Quick check

1. In the lesson "Security Audit Log Fundamentals", consider this project situation: Configure logging for failed privileged logons, then review events and correlate them with a known test account to understand what the log can and cannot prove. Which statement is correct?

2. Which practice best supports effective long-term management of Security Audit Log data growth on application servers?

3. Which of the following is NOT one of the standard event categories (audit classes) that can be selected when defining a Security Audit Log filter?

Interview questions

1. You are the senior consultant/architect responsible for SAP Security Audit Log: SM19/SM20, Event Selection and Retention. The project situation is: An incident investigation needed failed privileged logons from six weeks earlier, but local audit retention was only seven days and no SIEM forwarding existed. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?

Answer it in your own words first, then compare.

2. Using this SAP project situation — Configure logging for failed privileged logons, then review events and correlate them with a known test account to understand what the log can and cannot prove — explain Security Audit Log Fundamentals. What should happen, which concepts or process steps matter, and what common mistake would you avoid?