# 8. Security Monitoring & Auditing

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 8. Security Monitoring & Auditing

### 8.1 Login Activity Logging
**What it does:** Records every login event — success and failure, across all methods (password, OTP, social, SSO) — with full context, providing the raw data that powers the security dashboard, incident response, and audits. The log is append-only and immutable, and it is the first place the Super Admin looks when investigating any account-access question.

**Sub-features:**
- Log fields per event: user (or attempted email), timestamp, outcome (success/failure/block), failure reason (invalid password, OTP expired, IP blocked, location blocked, locked, suspended), IP address, device, approximate location, authentication method
- Real-time security dashboard: live feed of recent login activity with success/failure indicators
- Filtering and search: by user, outcome, failure reason, method, IP, location, and time range
- Per-account login history: the full chronological login record for a single user
- Pattern views: failures clustered by IP, by account, or by location over a selected window
- Retention per policy with secure, access-controlled storage
- Export of login logs (filtered) for audits and incident reports
- Append-only integrity: entries cannot be edited or deleted by any role

**Super Administrator User Journey:**
1. Super Admin opens the Security Monitoring dashboard and reviews the live login activity feed: a scrolling list of recent successes and failures with method and location indicators.
2. Filters failures by reason "invalid password" over the last 24 hours and sorts by count per account.
3. Notices a cluster: one account with nine failures from an unfamiliar location, followed by a single success. This "many failures then a success" pattern is a classic brute-force-then-compromise indicator.
4. Opens that account's full login history: the nine failures are spaced seconds apart from one IP; the success is from the same IP ten minutes later, using password + OTP.
5. Determines the account is likely compromised (the attacker obtained the password and had temporary access to the OTP channel).
6. Takes the standard response: force logout of all sessions for the account, trigger a password reset, and flag the account for review (suspend pending user contact).
7. Adds the attacker IP to the deny list and records the incident in the audit trail with the timeline and actions taken.
8. For the monthly security review, Super Admin exports the filtered login log (failures by reason, top source IPs) to include in the review pack.

**Rules & Edge Cases:**
- Logs are append-only and immutable; no role, including Super Admin, can edit or delete entries (integrity for audits and forensics).
- Sensitive values (passwords, full OTP codes) are never written to logs; only the event and its non-sensitive context are recorded.
- Log volume is high; the dashboard shows summaries and trends with drill-down to individual events, so the full log is never dumped into the UI at once.
- Failed attempts for non-existent emails are logged (with the attempted email) to support enumeration-attack detection, subject to privacy handling of the raw email.
- Retention follows policy; after the retention period, logs are purged automatically and the purge is itself recorded.
- Exports are access-controlled and the export action is audit-logged (who exported what, when).

### 8.2 Security Audit Trail
**What it does:** A comprehensive, tamper-evident record of security-relevant actions across the platform — who did what, when, and from where — covering authentication events, permission changes, account status changes, admin actions, policy changes, and privileged data access. It is the system of record for compliance and forensics, and it supports point-in-time reconstruction of what the platform's security state was at any moment.

**Sub-features:**
- Audit event coverage: authentication events, permission changes, account status changes, admin actions (forced logout, resets, 2FA resets), security policy changes, IP/location rule changes, and privileged-role data access
- Each event records: actor, action, target, before/after state (where applicable), timestamp, IP, and device
- Tamper-evidence: entries are immutable and integrity-checked; alteration attempts are themselves logged and alerted
- Search and filter: by actor, actor type, action type, target, and time range
- Point-in-time policy snapshots: what the security policy was at a given date
- Retention per compliance requirements (the strictest applicable regulation governs)
- Export for external audits in standard formats
- Compliance dashboard: open items, recent privileged actions, and audit-readiness indicators

**Super Administrator User Journey:**
1. An external auditor requests the audit trail for all administrator actions over the last quarter, plus the security policy state during that period.
2. Super Admin opens the Security Audit Trail and filters by actor type "Administrator" and the quarter's date range.
3. Reviews the entries: each shows the actor, the action (e.g., "forced logout", "permission change", "policy update"), the target, the before/after state where applicable, and the timestamp.
4. Generates the point-in-time policy snapshots for the quarter's start and end dates, so the auditor can see exactly what the security configuration was.
5. Exports the filtered trail and the policy snapshots in the format the auditor requires.
6. Shares the export with the auditor through the secure channel and records the provision in the compliance log (what was provided, to whom, when).
7. During the audit, the auditor asks about a specific forced logout three weeks ago. Super Admin retrieves the entry, shows the before/after state, the acting admin, the recorded reason, and the linked login-activity events, demonstrating the full chain of evidence.
8. After the audit, Super Admin confirms the trail's integrity check passed for the period and files the completed audit record.

**Rules & Edge Cases:**
- The audit trail is not modifiable by any role; attempts to alter it are themselves logged and raise an alert (tamper-evidence).
- Privileged data access (e.g., an admin viewing a user's personal data or a minor's record) is audit-logged to support right-to-access and safeguarding obligations.
- Before/after state is captured for configuration and permission changes so any change can be reconstructed, not just detected.
- Retention periods follow the strictest applicable regulation across the jurisdictions the platform operates in.
- Exports are read-only copies; the source trail remains immutable and authoritative.
- The audit trail spans all modules (not only authentication); this section covers the security-relevant subset, with the same immutability guarantees.

### 8.3 Suspicious Activity Detection and Alerts
**What it does:** Applies configurable rules to authentication and account activity to detect suspicious patterns in near real time and raise alerts to the Super Admin for triage. Detection covers classic compromise indicators (impossible travel, velocity logins, repeated failures, new device plus new location, bulk access attempts, OTP delivery anomalies), and each alert links to the underlying events for fast investigation.

**Sub-features:**
- Detection rules: impossible travel, velocity logins, repeated failures, new device + new location, bulk account access attempts from one source, OTP delivery failure spikes, lockout spikes
- Alert severity levels: info, warning, critical
- Alert delivery: in-app dashboard, email, and (for critical) SMS to the on-duty admin
- Alert triage workflow: acknowledge, assign to an admin, resolve with outcome notes
- One-click context: each alert links to the underlying login/audit events for fast triage
- Rule configuration: enable/disable rules, tune thresholds and windows
- False-positive feedback: marking an alert a false positive feeds rule tuning to reduce noise
- Incident summary: resolved alerts compile into an incident record with timeline and actions

**Super Administrator User Journey:**
1. Super Admin receives a critical alert (in-app and SMS): "Impossible travel — account X logged in from two continents within 30 minutes."
2. Opens the alert in the Security Monitoring dashboard. The alert shows the two login events side by side: times, locations, devices, and methods, with a link to the full event context.
3. Reviews the context: the first login is the user's usual device and location; the second is an unfamiliar browser in a different continent, 25 minutes later, followed by bulk profile and data-access actions.
4. Determines the second login is unauthorized. Acknowledges the alert and assigns it to themselves.
5. Executes the compromise response: force logout of all sessions for the account, trigger a password reset, and suspend the account pending user contact.
6. Contacts the user through the registered channel to confirm and guide them through re-authentication once they respond.
7. Resolves the alert with outcome notes: "Compromised — unauthorized login confirmed. Sessions terminated, password reset issued, account suspended pending user contact. User notified."
8. The resolved alert compiles into an incident record with the full timeline (detection, acknowledgment, actions, resolution), which Super Admin reviews in the weekly security review.
9. Over time, Super Admin marks recurring benign patterns (e.g., a staff member's regular travel) as false positives, and tunes the impossible-travel rule's window to reduce that noise.

**Rules & Edge Cases:**
- Alerts are decision support, not automatic action — except where a rule is explicitly configured to auto-block (e.g., deny-list hits block without an alert triage step).
- Every alert carries a full context link to the underlying events, so triage does not require hunting through raw logs.
- Marking an alert a false positive is recorded and feeds rule tuning; it does not delete the alert or the underlying events.
- Critical alerts are delivered by SMS as well as in-app/email so they are seen even if the dashboard is not open.
- Unacknowledged critical alerts remain highlighted on the dashboard and in the compliance view until actioned.
- Rule and threshold changes are audit-logged (who changed which rule, before/after values).

### 8.4 Support for Regular Security Audits
**What it does:** Provides the tooling and reports needed to conduct periodic security audits — internal reviews and external assessments — efficiently: pre-built audit reports, point-in-time policy snapshots, evidence export packages, scheduling reminders, and findings tracking from identification through remediation to closure.

**Sub-features:**
- Pre-built audit reports: authentication events, permission changes, admin actions, and policy state over a selected period
- Point-in-time policy snapshots: the security policy as it was at a given date
- Evidence export packages: bundled logs, reports, and policy snapshots in standard formats for auditors
- Audit scheduling: recurring reminders for internal review cadence and external audit dates
- Findings tracking: log audit findings, assign remediation owners, track status to closure
- Compliance dashboard: open findings, upcoming audits, and audit-readiness indicators
- Record of completed audits with their evidence packages and outcomes

**Super Administrator User Journey:**
1. The annual security audit is scheduled for next month; Super Admin receives the scheduling reminder and blocks time to prepare.
2. Opens the audit support section and selects the audit period (the trailing 12 months).
3. Generates the evidence package: authentication logs summary, admin action trail, permission-change history, policy snapshots at period start/end, and the current detection-rule state.
4. Reviews the package for completeness against the auditor's requested scope, adding any specific exports the auditor pre-requested.
5. Shares the package with the auditor through the secure channel and records the provision in the compliance log.
6. During the audit, the auditor raises findings (e.g., "two admin accounts lacked 2FA for a 3-day window in March"). Super Admin enters each finding into findings tracking with the auditor's reference.
7. Assigns remediation owners and due dates: for the 2FA gap, confirms the accounts are now enrolled and documents the policy change that closed the gap.
8. Tracks each finding to closure with evidence of remediation; the compliance dashboard shows all findings closed.
9. Records the completed audit with its evidence package, findings, and remediation outcomes, so the next audit starts from a documented baseline.

**Rules & Edge Cases:**
- Evidence packages are read-only exports; the source logs and trail remain immutable and authoritative.
- Policy snapshots allow proving what the configuration was historically, not just what it is now — essential for period-specific audit questions.
- Findings remain tracked until explicitly closed with remediation evidence; open findings are always visible on the compliance dashboard.
- Audit scheduling reminders recur per the configured cadence so audits are not missed.
- Provision of evidence to external parties is access-controlled and logged (what was shared, with whom, when).
- Completed audit records are retained per policy and form the baseline for the next audit cycle.