EXERCISE 1 — Logging strategy for e-commerce app (what to log + redaction + centralization) =============================================================================================== 5 SECURITY EVENTS TO LOG (with example data + sensitive redaction): 1. FAILED LOGIN ATTEMPT What to log: timestamp, username (or email), IP address, user agent, reason (invalid password, account locked, MFA failure). Example: 2025-06-28T14:32:17Z user=alice@example.com ip=203.0.113.42 reason=invalid_password mfa_attempt=false Sensitive data to redact: the actual PASSWORD (never log it, even on failure). Same for MFA codes/tokens. ✓ OK: log that MFA failed; ✗ WRONG: log the MFA code the user entered. 2. SUCCESSFUL LOGIN What to log: timestamp, user ID (internal ID, not email if possible), IP address, user agent, session ID (hashed/anonymized), MFA method used. Example: 2025-06-28T14:33:02Z user_id=12345 ip=203.0.113.42 session_hash=abc123def456 mfa_method=totp Sensitive data to redact: the SESSION TOKEN itself (don't log the full token), the user's email address (if you can use user ID instead), plaintext user agent (safe to log). ✓ OK: log the session ID is hashed so it can't be replayed; ✗ WRONG: log the full session cookie value. 3. ADMIN ACTION (e.g., REFUND, USER SUSPENSION) What to log: timestamp, admin user ID, action (refund_issued, user_suspended, password_reset_initiated), target (order ID, user ID), amount (if applicable), reason/approval code. Example: 2025-06-28T15:00:00Z admin_id=789 action=refund_issued order_id=ORD-54321 amount=99.99 reason=customer_request Sensitive data to redact: customer's full name/email (log user ID instead), payment method (don't log credit card last 4 digits; log the order/transaction ID instead), passwords or API keys used for the refund. ✓ OK: log order ID and amount so you can track financial transactions; ✗ WRONG: log credit card numbers or API secrets. 4. FAILED INPUT VALIDATION / INJECTION ATTEMPT What to log: timestamp, user ID (or IP if unauthenticated), endpoint, payload (sanitized version showing the attack pattern), validation error, severity. Example: 2025-06-28T15:15:33Z user_id=12345 endpoint=/api/search payload_pattern=sql_injection_detected error=unexpected_quotes severity=high Sensitive data to redact: the user's actual search query (if it contains PII like a credit card they're looking for in logs), the exact payload (log an abstraction, e.g. "SQL keyword detected in parameter" instead of the full input). ✓ OK: log that an injection was detected and what type; ✗ WRONG: log the exact user input if it contains their data. 5. UNAUTHORIZED ACCESS ATTEMPT / IDOR What to log: timestamp, user ID, target resource (order ID, user profile ID, URL accessed), user's role, required role, outcome (denied/allowed). Example: 2025-06-28T15:45:12Z user_id=12345 user_role=customer target_resource=order_54999 required_role=admin outcome=denied Sensitive data to redact: the resource owner's name/email (log resource ID instead), the exact content of the denied resource (log just the resource ID and access level required). ✓ OK: log the user tried to access order 54999 but isn't authorized; ✗ WRONG: log the order details (customer name, items, shipping address). --- WHY CENTRALIZING LOGS TO A SEPARATE SERVICE IS CRITICAL: SCENARIO WITHOUT CENTRALIZATION: - Logs are written to the app server's filesystem (e.g., /var/log/app.log). - An attacker compromises the app server (via an XSS, SQLi, RCE, or weak deploy). - First thing the attacker does: delete the logs (rm -f /var/log/app.log). - Now the breach is invisible. The admin checks logs days later: "No suspicious activity found." The attacker had weeks to steal data, and nobody knows. - The post-breach forensics are useless — the crime scene was cleaned. SCENARIO WITH CENTRALIZATION: - App logs are sent in real-time to a separate logging service (AWS CloudWatch, Splunk, Datadog, ELK Stack, etc.). - App server is compromised. - Attacker tries to delete logs on the app server: rm -f /var/log/app.log. - The logs that were already sent to the remote service are STILL THERE, UNAFFECTED. The attacker would need to compromise the logging service to delete them — much harder (separate creds, separate infrastructure, separate access controls). - On-call team sees the attack in real-time (or within minutes) because the logging service is monitoring and alerting. - Forensics are available and complete. CRITICAL PRINCIPLE: Logging should be a one-way valve: app sends logs OUT, but the logging system doesn't let the app delete them. This is why centralization is non-negotiable for security logging. If an attacker can compromise the source of the logs, they can't cover their tracks. BEST PRACTICES: - Log to a service that enforces "write-once" semantics or immutability (CloudTrail, Stackdriver, or a SIEM with audit-log protection). - Use separate credentials for the logging service (don't use the app's main database creds to authenticate to the logging service; use API keys with restricted permissions). - Encrypt logs in transit (TLS) and at rest (encryption on the logging service). - Restrict read access to logs (only security team, maybe ops; not the app server, not general developers). - Set up alerts so that large-scale log deletion or unusual access triggers an incident. --- ONE-LINE TAKEAWAY: Log security events (auth, authz, input validation, config changes, errors) · redact secrets and PII · centralize to a separate, immutable service so attackers can't delete them after compromising the app.