A Singapore-based financial services firm recently asked us to investigate how an attacker had moved from a compromised third-party vendor portal to their core banking network — undetected, for 11 weeks. The answer was not sophisticated threat actor tradecraft. It was a logging gap. The company had invested heavily in a SIEM platform, staffed a SOC team, and maintained compliance with MAS TRM audit requirements. But the SIEM had no visibility into the Azure Active Directory sign-in logs from their own IT service accounts — because those logs required a separate licensing tier that had not been activated. The attacker used those exact credentials to pivot from the vendor portal into the production environment. The SIEM never saw it.
This is not an unusual story. In our incident response work across Singapore organisations — financial institutions, government-linked companies, healthcare operators, and mid-sized enterprises — we find the same pattern: a SIEM is deployed, compliance requirements are nominally satisfied, and yet the detection capability is full of blind spots that sophisticated attackers routinely exploit. The gaps are rarely exotic. They are mundane. And they are fixable.
The Compliance-Ready vs. Detection-Ready Gap
Singapore organisations face two distinct logging pressures. The first is regulatory: MAS TRM guidelines require financial institutions to maintain audit trails for privileged access, system changes, and security events. The Cybersecurity Act 2024 and its associated CII Governance Standards impose similar obligations on Critical Information Infrastructure operators. PDPA requires access logs for systems processing personal data. These requirements are well-defined, and most organisations can produce evidence of compliance when auditors ask.
The second pressure is operational detection: logging that actually enables your SOC to see an active attack in progress — not after the forensic review that comes weeks later. These two objectives overlap, but they are not the same. A SIEM that satisfies your compliance auditor may still leave you blind to the initial access vector that launches a major incident. The MAS TRM guidelines and the CII Governance Standards are increasingly moving toward requiring detection capability, not just evidence of log storage. Organisations that treat logging as a compliance exercise — not a detection investment — will find themselves exposed.
The Five Most Common Logging Gaps We Find in Singapore Environments
1. Cloud Identity Provider Logs — Partial Coverage
Microsoft 365 E3 licenses include only basic Azure AD sign-in logs. Full sign-in log retention, which captures the client application, device ID, and risk flags necessary to detect anomalous authentication patterns, requires Microsoft 365 E5 or a separate Azure AD P2 license. Many Singapore organisations run a mixed environment — E3 for most users, E5 for security-sensitive roles — and have not consolidated identity logging across both tiers. Attackers exploit this gap routinely by authenticating through a standard E3 account to access email and collaboration tools, then using that access to discover and abuse service accounts that have broader permissions.
2. Service Account and Application Logs — Zero Coverage
Service accounts — the non-human identities used by applications, integrations, and automation scripts — are among the most privileged and least monitored credentials in a Singapore enterprise environment. They typically have long-lived secrets, no MFA, and permission to access sensitive systems including production databases, cloud APIs, and SCADA interfaces. When a Singapore-based logistics company's third-party TMS integration was compromised, the attacker used the service account credentials to access their container yard management system directly. The SIEM had no logs for the application authentication events because the TMS vendor's API used OAuth and the organisation had not configured log forwarding for OAuth token issuance events.
3. Endpoint Security Telemetry — Volume Without Quality
Most Singapore organisations have an EDR platform deployed. Many also forward EDR telemetry to their SIEM. But the forwarding configuration often captures only alert data — the detections that the EDR rule engine already fired — and not the raw endpoint telemetry that allows a SOC analyst to reconstruct an attacker's activity chain. When a threat actor uses living-off-the-land tools like PsExec, Rmmi, or WMI to move laterally, the EDR alert may be a generic "suspicious process execution" flag. Without the raw telemetry — parent-child process relationships, command-line arguments, loaded DLLs — the SOC cannot distinguish between a legitimate automation script and an attacker running reconnaissance. The result is alert fatigue, missed detections, and a SIEM that is full of data but provides no investigative depth.
4. Network Flow Logs — Missing the East-West Traffic
VPC flow logs, firewall logs, and network detection sensors capture north-south traffic — traffic entering and leaving the corporate network. East-west traffic — lateral movement between internal systems — is frequently invisible. A compromised workstation that uses SMB to connect to a file server, or a service account that queries the domain controller via LDAP from an internal host, generates very little network-level log data in most Singapore enterprise environments unless network segmentation monitoring has been explicitly deployed. By the time the attacker reaches a valuable target and generates an outbound connection to exfiltrate data, the dwell time may have been weeks.
5. SaaS Application Logs — The Blind Spot in the Architecture
Singapore organisations now run a significant portion of their operations on SaaS platforms — HR systems, CRM, project management tools, development platforms. Each of these platforms generates authentication and access logs that are rarely forwarded to the central SIEM. A compromised Okta or Salesforce account may generate no alerts in the corporate SOC because the events occur entirely within the SaaS vendor's infrastructure. We have responded to multiple incidents where the initial access came through a compromised SaaS admin account — the organisation had no visibility into the login events from that platform because the integration had never been configured.
The MAS TRM Implication: For MAS-regulated entities, the Technology Risk Management guidelines require that security events — including privileged access and anomalous authentication — be logged and reviewed. If your SIEM has incomplete coverage of your identity provider logs, your cloud service account activity, or your SaaS platforms, you may face regulatory findings during your next technology risk assessment — even if you have a SOC and a SIEM deployed. Regulators are increasingly asking: not just "do you have logs" but "do your logs actually let you see attacks?"
A Practical Logging Audit Sequence
Most organisations need a structured audit before they can close these gaps meaningfully. The sequence below is what we use with Singapore clients as part of our security logging assessment.
- Map your identity providers and their license tiers. Document which identity sources feed your SIEM and what log types each license tier provides. Activate full sign-in logging for Azure AD and any other IdP in your environment. This is the single highest-impact change for most Singapore organisations.
- Audit service account inventory and exposure. Identify every service account with privileged access to production systems. Determine which of these accounts have long-lived secrets (more than 90 days) and which have no MFA. Configure SIEM-level alerting on service account authentication events — particularly from new IP ranges or unusual times.
- Review your EDR-to-SIEM integration configuration. Confirm that raw telemetry — process events, network connections, file writes — is being forwarded, not just alert detections. If your SIEM is receiving only EDR alerts, you have a significant investigative gap that you may not be aware of.
- Assess east-west visibility. Deploy network detection sensors or configure NetFlow/VPC flow log analysis for internal subnets. If you cannot see lateral movement between your workstation VLAN and your server VLAN, that is a known blind spot — treat it as one.
- Inventory your SaaS platforms with administrative access. For each critical SaaS platform, confirm that authentication and admin activity logs are accessible via API or SIEM connector. Configure forwarding for Okta, Salesforce, ServiceNow, and any HR platform that contains sensitive personal data.
- Test your logging with a red team exercise. The only way to verify that your SIEM actually detects real attack behaviour is to simulate it. A red team engagement with explicit success criteria around detection time and log quality will surface every blind spot in your current configuration — before an actual attacker finds them.
Know What Your SIEM Cannot See
Detection gaps are fixable — but only if you know they exist. Infinite Cybersecurity's Security Logging Assessment gives Singapore organisations a complete map of their SIEM blind spots, ranked by actual risk exposure. We test log coverage against MITRE ATT&CK techniques, benchmark your detection coverage against MAS TRM requirements, and provide a prioritised remediation roadmap that your SOC can implement without disrupting operations.
Continuous Visibility, Not Periodic Compliance
The logging gap problem is ultimately a visibility culture problem. Organisations that treat security logging as an annual audit requirement will always have blind spots. The organisations that detect attacks fastest — and recover fastest — are those that treat logging as a live operational capability. Log sources are added and removed as the environment changes. New cloud services, new SaaS platforms, new service accounts — each change introduces a potential logging gap that must be detected and closed.
Singapore's threat landscape is not passive. The Monetary Authority's heightened expectations around technology risk, the Cybersecurity Act's expanded CII obligations, and the growing sophistication of threat actors targeting financial and critical infrastructure mean that the cost of a logging blind spot is no longer theoretical. It is a regulatory finding, a breach notification, and a board-level incident that could have been detected — and contained — with the right visibility in place.
Start the audit today. The gaps are there. The question is only whether you find them before an attacker does.