# Logging Monitoring > >- - **Type:** Skill - **Install:** `agentstack add skill-kyleoliveiro-sg-gov-skills-logging-monitoring` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [kyleoliveiro](https://agentstack.voostack.com/s/kyleoliveiro) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [kyleoliveiro](https://github.com/kyleoliveiro) - **Source:** https://github.com/kyleoliveiro/sg-gov-skills/tree/main/skills/logging-monitoring ## Install ```sh agentstack add skill-kyleoliveiro-sg-gov-skills-logging-monitoring ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # logging-monitoring: LM controls for SG government systems You are setting up or auditing **how a system captures, protects, and acts on its logs and telemetry** against the ICT&SS Policy Reform **Logging and Monitoring family (LM-1..LM-21)** — the largest cybersecurity family in the catalog. It covers what to log, where logs live, how long they survive, who watches them, and the operational monitoring (SLOs, golden signals, DORA, WOGAA) that keeps the service healthy. Two facts anchor everything: 1. **LM-12 (central security log management and monitoring) sits in the Level-0 spine of every published SSP** — mandatory, no deviation path, cloud and on-prem alike. **GCC tenants already have CSP tenant security logs stored centrally and available for forwarding to the Government Cyber Security Operations Centre (GCSOC)** — contact GCSOC for subscription. A system whose logs never leave the team's own account fails the one LM control that cannot be traded away. 2. **Security log coverage is enumerable, not a vibe.** The catalog names the five security log sources — **network flow logs, cloud management/audit logs, access logs, database logs, and host logs** (LM-3..LM-7, enumerated in LM-8's recommendation). Audit against that list; "we have logging" without all five is a coverage gap, not a pass. ## What this family is *not* about - **CSPM and vulnerability scanning are ST** (security-testing). ST-2 watches for cloud *misconfigurations*; LM-9 watches for *runtime threats and breaches* (GuardDuty-class detection). Findings from either feed the ST-5 vulnerability register. - **Where log stores reside and whether they're encrypted is DP** (data-protection). Logs are data: DP-1 residency and DP-2 at-rest encryption apply to the log bucket too. An unencrypted or overseas log store is a DP finding; LM owns capture, protection from tampering, retention, and monitoring. - **User-facing error hygiene is AS** (secure-coding-as). Not leaking stack traces to end users is an application-security concern; **LM-19 is about sensitive data written *into* the logs themselves** — sanitise before recording. - **WOGAA implementation detail is the service shell.** LM-18 mandates WOGAA in public facing digital services from the cybersecurity side; the DSS twin (PR-2) and the registration/tracking-code mechanics live in **sg-service-shell**. - **Pipeline controls are SD/SC** (secure-pipeline). LM-17 *measures* software delivery performance (DORA metrics); the branch protections and CI gates being measured belong to Secure Development. ## Source and currency Control text in this skill and `references/lm-controls.md` is embedded from **info.standards.tech.gov.sg as of 2026-07-23**; the LM family page was last updated **24 March 2026**. The standards iterate. For any compliance-critical decision, verify against the live page: - LM control catalog: https://info.standards.tech.gov.sg/control-catalog/cybersecurity/lm/ ## Reference files - `references/lm-controls.md` — full text of LM-1..LM-21 (statement, recommendations, risk, the three parameters) plus per-SSP level assignments and cross-family notes. Read it when you need exact wording for an audit response or SSP documentation. - `references/implementation-recipes.md` — concrete config per control: Terraform for flow logs/CloudTrail/ALB logging, off-box shipping and tamper-resistant bucket policies, retention lifecycle, OCSF/OTel formatting, sanitisation patterns, GuardDuty, and the monitoring stack (SLOs, golden signals, DORA, defacement). Read it when actually building. ## Before you start: the SSP parameters Get these values from the System Security Plan — if the SSP is missing or a value is blank, flag that as its own finding and ask; never invent a number (the sibling skill **ssp-navigator** determines levels): | Control | Parameter | What the SSP defines | |---|---|---| | LM-8 | lm-8_prm_1 | Security log retention period in days | | LM-12 | lm-12_prm_1 | The central security log management and monitoring service | | LM-21 | lm-21_prm_1 | Maximum days between malware/IOC detection updates | LM-12 is Level 0 in every SSP. Medium-Risk Cloud additionally promotes **LM-3, LM-4, LM-6, LM-9** to Level 0; High-Risk Cloud CII puts **LM-1..LM-9, LM-12, LM-13** at Level 0. The project's own SSP is authoritative. ## Procedure Work in this order. For **setup**, produce each configuration/artifact. For **audit**, verify each and record pass / fail / not-applicable-per-SSP with evidence (the logging config, the bucket policy, the retention rule, the GCSOC subscription, the dashboards). Recipes for every step are in `references/implementation-recipes.md`. ### Stage 1 — Capture every source (LM-3..LM-7) Enable all five security log sources: - **Network flow (LM-3)**: VPC Flow Logs or equivalent on every network interface. - **Cloud management/audit (LM-4)**: CloudTrail or equivalent for account, access, IAM and resource changes; for SaaS/COTS, enable the built-in audit logging features. - **Database (LM-5)**: RDS logging or equivalent audit events. - **Access (LM-6)**: WAF, load balancer, proxy, API gateway and web server request logs. - **Host security events (LM-7)**: OS security events, authentication, EDR alerts, configuration changes, account and access-rights changes. ### Stage 2 — Make the logs trustworthy (LM-1, LM-2, LM-19, LM-15, LM-8) **2a. Off the box, immediately (LM-1).** Ship logs to a different system/component than the one that generated them, as soon as possible after the event — an app server keeping its only copy on local disk means a compromise erases the evidence. Store cloud audit logs in a separate system or account. **2b. Tamper-resistant (LM-2).** Least-privilege access to log storage; **as far as possible, read-only**. Nobody on the delivery team needs delete rights on security logs. Logs sent to GCC Central Logs are tamper-resistant already. **2c. Sanitise before recording (LM-19).** Identify classified/sensitive data that could reach logs — NRIC-class PII, credentials, API keys, payment details — and mask or tokenise it *before* it is written or shared with any third party. **2d. Structured format (LM-15).** Security logs in OCSF/ECS-style schemas; operational logs in OpenTelemetry or structured JSON — consistent formats are what make central analysis and automated detection possible. **2e. Retain long enough (LM-8).** Security logs (all five Stage-1 sources) kept at least **lm-8_prm_1 days**, with lifecycle automation (e.g. S3 Lifecycle). Non-security logs: as long as needed for incident resolution and debugging. ### Stage 3 — Centralise and detect (LM-12, LM-9, LM-13, LM-20, LM-21, LM-14) **3a. Central security log management (LM-12 — Level 0 everywhere).** Centralise with the service named in lm-12_prm_1. On GCC, tenant security logs are already central and forwardable to **GCSOC** — subscribe rather than build. **3b. Security monitoring with automated alerts (LM-9).** GuardDuty / Defender / equivalents, alerting to somewhere a human responds. **Error tracking (Sentry-class tools) and uptime checks are not security monitoring** — they watch bugs and availability, not breaches. **3c. Deeper detection where warranted**: anomalous database activity monitoring (LM-13, e.g. RDS Activity Streams), UEBA integrated with the SIEM for insider-threat signals (LM-20), and **web defacement monitoring for internet-facing systems (LM-14)** with a recovery plan. **3d. Keep detections current (LM-21).** Malware/IOC detections updated at least every **lm-21_prm_1 days**, with automation to monitor rollout and conformance. ### Stage 4 — Watch the service, not just attackers (LM-10, LM-11, LM-16, LM-17, LM-18) - **Resource usage (LM-10)**: alerts on abnormal usage — spikes, access at unexpected hours, excessive charges. - **SLOs/SLIs (LM-11)** and the **4 Golden Signals — latency, traffic, errors, saturation (LM-16)**: track, alert, and use trends to improve. - **DORA metrics (LM-17)**: deployment frequency, lead time for changes, change failure rate, time to restore. - **WOGAA (LM-18)**: mandatory for public-facing digital services — register at https://wogaa.sg/ and implement per https://docs.wogaa.sg/ (mechanics in sg-service-shell). ## Audit checklist Verify each row; record evidence. "Param" marks controls whose pass criteria come from the SSP — ask for the values rather than inventing them. | ID | Check | Where | Param | |---|---|---|---| | LM-1 | Logs shipped off the generating component promptly; cloud audit logs in a separate system/account | Log pipeline config | | | LM-2 | Log storage least-privilege, read-only as far as possible; no team delete rights | IAM / bucket policy | | | LM-3 | Flow logs on all network interfaces | VPC config | | | LM-4 | Cloud management/audit events logged (CloudTrail or equivalent; SaaS audit features on) | Trail config | | | LM-5 | Database audit events logged | DB config | | | LM-6 | WAF / LB / proxy / web server access requests logged | LB/WAF config | | | LM-7 | Host security events logged (OS, auth, EDR, config and access changes) | Host/EDR config | | | LM-8 | Security logs retained ≥ lm-8_prm_1 days with lifecycle automation | Retention rules | ✓ | | LM-9 | Security monitoring with automated alerts (GuardDuty-class), responded to | Detection config | | | LM-10 | Resource usage monitoring and abnormal-usage alerts | Alarms | | | LM-11 | SLOs/SLIs monitored, maintained, alerted | Monitoring config | | | LM-12 | Central security log management with lm-12_prm_1 (GCC → GCSOC forwarding) | Central logging / subscription | ✓ | | LM-13 | Anomalous database activity monitored | DB activity streams | | | LM-14 | Web defacement detection and recovery measures (internet-facing) | Monitoring plan | | | LM-15 | Structured formats (OCSF/ECS for security; OTel/JSON for ops) | Log schema | | | LM-16 | 4 Golden Signals tracked and analysed | Dashboards | | | LM-17 | DORA 4 Key metrics measured and used | Delivery metrics | | | LM-18 | WOGAA implemented in public-facing services | WOGAA registration | | | LM-19 | Sensitive data masked/tokenised before logging or sharing | Log samples + pipeline | | | LM-20 | UEBA integrated with SIEM, tuned, real-time alerts | UEBA config | | | LM-21 | Detections updated ≤ every lm-21_prm_1 days, rollout automated | Update automation | ✓ | Report per control ID with pass / fail / not-applicable-per-SSP, the evidence found, and — for failures — the fix from `references/implementation-recipes.md`. Attribute log store encryption/residency findings to DP and misconfiguration-posture findings to ST-2, not LM; and correct, don't accept, "we have Sentry so monitoring is covered" reasoning. ## Related skills in this repo - **ssp-navigator** — which SSP applies and at which level each LM control sits (LM-12 is Level 0 everywhere; Medium-Risk Cloud promotes LM-3/4/6/9; High-Risk Cloud CII promotes LM-1..9, 12, 13). - **security-testing** — ST-2 CSPM (misconfig posture) vs LM-9 (runtime detection); detections and alerts feed the ST-5 vulnerability register and response SLAs. - **data-protection** — DP-1/DP-2 residency and encryption of the log stores themselves; DP-7 DLP for data flows beyond logs. - **sg-service-shell** — WOGAA registration and implementation (LM-18's DSS twin PR-2). - **secure-coding-as** — AS error hygiene (what users see) alongside LM-19 (what logs record). - **secure-pipeline** — the SD/SC pipeline controls that LM-17's DORA metrics measure. - **network-security** — NS-9 IPS/IDS detections and NS-11 firewall-change alerts are security log/alert sources that must feed the LM central pipeline and GCSOC; NS owns the sensors, LM owns the pipeline. - **resiliency-recovery** — RS/BR owns multi-AZ failover, scaling, backups, and DR; LM owns the health checks, SLOs, and golden-signal alerting that detect the failures RS absorbs and that load-test results are judged against. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [kyleoliveiro](https://github.com/kyleoliveiro) - **Source:** [kyleoliveiro/sg-gov-skills](https://github.com/kyleoliveiro/sg-gov-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-kyleoliveiro-sg-gov-skills-logging-monitoring - Seller: https://agentstack.voostack.com/s/kyleoliveiro - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.