CY6: Logging, monitoring and detection
What to log, and how
🎯You'll be able to
Choose which events to log, with which fields, and keep logs accurate, safe and available when they're needed.
🏠The everyday picture
A building's visitor book records who came in, when, whom they visited and when they left. It doesn't record what they said in the meeting, and it's kept somewhere a visitor can't tear out a page.
📘What it really is
-
Security events to log: logins (success and failure), logouts, password and MFA changes, role and permission changes, access to sensitive records, admin actions, errors, and changes to settings.
-
Fields: a timestamp, the event type, the user, the source address, the target, and the result.
-
Time: record times in UTC with a clear format, such as
2026-10-30T21:40:00Z, and keep server clocks synchronised. Show local times, such as IST (UTC+05:30), only when presenting. -
One event per line in a structured format, such as JSON lines, so tools can read them.
- Don't log secrets: no passwords (even wrong ones), tokens or full card numbers, and only the personal data needed.
- Protect logs: send copies to a separate system that the app's servers can't edit or delete.
- Retention: keep logs long enough to investigate. CERT-In's directions of April 2022 ask organisations in India to keep ICT system logs for 180 days, and to synchronise clocks to standard time sources. Check the current requirements for your organisation.
📝A worked example
Input: AarogyaDesk's login and web logs in data/logs/auth.jsonl and data/logs/web.jsonl.
Steps:
- Read a login line:
{"ts": "2026-10-26T03:40:00Z", "event": "login", "user": "S06", "ip": "198.51.100.10", "ok": false}. - Check the fields: time in UTC, event, user, address, result. There's no password, which is right.
- Read a web line: it has the time, address, user, method, path, query and status code.
Expected output: a note saying the logs cover logins, role changes and record views, and what's missing (for example, logouts).
🌍Where it's used
- Banks log every transaction and login for fraud checks.
- Cloud providers offer audit logs of every admin action in an account.
- Investigations depend on logs that are complete, accurate and untouched.
📝Case scenario
After a suspected breach, a company found its web servers' clocks were 47 minutes apart and logs were kept for only 7 days. It couldn't put events in order or see how the intruder first got in. Clock sync and longer retention were the first fixes.
🖱️Try it
Open data/logs/auth.jsonl in the kit and find the first line that isn't valid JSON. Success: you can say what's wrong with it.
⚠️Common mistakes
- Logging passwords. Sign: failed-login lines with the password typed. Fix: never log secrets.
- Local times without a zone. Sign: "10:30" with no offset. Fix: UTC with a
Zor an explicit offset. - Logs only on the server they describe. Sign: no copy elsewhere. Fix: send them to a separate store.
🛠️For your project
Project 3 reads both log files and builds alerts and a timeline from them.
✅Quick check
Why record log times in UTC?
Show the answer
So events from different servers and places can be put in one order without confusion.
Name two things that should never be written to logs.
Show the answer
Passwords and session tokens (also full card numbers).