There’s a certain panic that sets in when you pick up the phone and hear, “We think you might have been breached, can you take a look?” After doing this for as long as I have, I’ve learned to stay calm and methodical. But there’s one scenario that still sends a chill down my spine: arriving at a client site and discovering they have no central security information and event management (SIEM) platform and a motley collection of logs scattered across servers, clouds and applications. It's like stepping onto a crime scene and realizing the surveillance cameras were never turned on.
Key Takeaways
|
In cybersecurity, the first minutes of an incident response dictate the arc of the entire investigation. When an alert triggers in a properly instrumented environment, analysts can retrace an attacker’s steps, determine what was accessed, and contain the breach quickly. Without a SIEM or coherent logging strategy, those first minutes turn into days or weeks of guesswork.
The OWASP Top 10 calls out security logging and monitoring failures because inadequate logs leave organizations blind to active threats and unable to detect breaches. The category isn’t just about collecting events; it’s about detecting, escalating and responding. If failed logins, account changes or high-value transactions aren’t recorded, there is no way to know when a malicious actor has gained a foothold. Real attackers don’t always deploy ransomware on day one. They probe quietly, move laterally and cover their tracks. Without a SIEM to correlate events, a burst of PowerShell commands on a domain controller and a suspicious API call in a cloud environment remain isolated curiosities rather than indicators of compromise.
Logging hygiene is about consistency. Each system should log key events with enough context (timestamps, usernames, IP addresses, process IDs) to reconstruct a timeline. Those logs should be centrally aggregated and protected from tampering. When I see systems logging to local text files with default retention, I know that evidence may be overwritten or deleted in days.
Most organizations don’t deliberately neglect logging. Instead, they accumulate a patchwork of point solutions: a firewall with built-in logging, a web application with its own audit trail, cloud vendor logs accessible through yet another console. Each component holds a piece of the puzzle, but no one can see the whole. Add to this the myth that migrating to the cloud means your provider will take care of logging. Network activity logs such as AWS CloudTrail and VPC Flow Logs are critical for detecting malicious events, yet the associated storage costs can tempt organizations to turn them off. Without those logs, visibility disappears and forensic investigations are severely hampered, forcing responders to extrapolate from partial evidence.
There’s also the budget question. SIEM platforms and log storage aren’t free. In lean times, CFOs may see log management as a cost center and ask security teams to trim data ingestion. I once worked with a mid-sized manufacturer that decided to disable logs for its ERP system to save on storage. When the finance department later discovered fraudulent wire transfers, we had no way to prove whether the attackers compromised credentials or exploited a vulnerability. The company ended up replacing the entire ERP platform because it couldn’t trust the integrity of its data.
Legacy systems contribute to the problem. Many industrial control systems and legacy applications either don’t support modern logging or use proprietary formats. Integrating them into a SIEM often requires custom parsers. It’s easier to ignore them until something goes wrong. By then, it’s too late.
Imagine being called into an organization that suspects a breach. They have no SIEM, minimal log retention, and unstructured logs. Here’s what happens.
Without centralized alerting, the incident may be detected by chance. A customer complains of a strange email, or a third-party threat intelligence vendor notifies the company of leaked data. By the time security staff are aware, the adversary may have been inside for weeks. Verizon’s Data Breach Investigations Reports regularly find that the median dwell time (the period attackers remain undetected) can extend to months for organizations lacking monitoring. In my own experience, I’ve seen threat actors lurk in payment processing environments for over 100 days because no one correlated failed login attempts or unusual network connections.
When the team finally springs into action, there’s a mad scramble to collect logs from endpoints, servers, cloud services and SaaS platforms. Without a SIEM, each log source must be accessed separately. Maybe the Windows event logs were overwritten. Perhaps the firewall logs rotated last week. Cloud audit trails might require manual export. The result is gaps, inconsistent timestamps and formats, and missing context.
During one retail breach investigation, the lack of log correlation forced us to rely on firewall traffic captures and web server logs to piece together a SQL injection attack. We couldn’t identify how the attackers pivoted to the point-of-sale network because the endpoint logs were unavailable. Months later, the same attacker returned via a different vector because we hadn’t identified their initial foothold.
Without reliable logs, forensic investigations devolve into educated guesses. You cannot prove or disprove whether sensitive data was accessed, making regulatory reporting tricky. Under GDPR, organizations must notify authorities if personal data was compromised. How do you know? Regulators may take a conservative approach and require notification if you can’t provide evidence to the contrary. Insurers also care; they may deny claims if you cannot demonstrate appropriate logging controls. Good forensic analysts can sometimes reconstruct events from network artifacts or memory captures, but this is expensive, time-consuming and not guaranteed.
A central SIEM helps responders contain incidents by showing all hosts that contacted a malicious IP or executed a particular binary. Without this correlation, containment is manual. You quarantine the obvious infected machines, only to have the attacker reappear because you missed an infected endpoint hidden in a remote office. The same holds for cloud incidents: if you don’t have CloudTrail logs, you won’t know which identities created new API keys or modified IAM policies. Attackers often maintain persistence by creating backdoor accounts. Without logs, those backdoors remain invisible.
Customers and partners expect organizations to have basic monitoring. When they learn that a breach went undetected for weeks because of poor logging, confidence erodes. During one post-incident briefing, a board member asked me if the organization would have known about the breach had the attacker not accidentally triggered a business disruption. The answer was no. That realization is a reputational blow.
Responding to a breach without a SIEM is painful, but it’s not hopeless. Here’s how I approach these situations:
1. Stabilize the environment: Before chasing logs, isolate critical systems from the network to prevent further damage. Pull network taps or enable traffic mirroring to capture evidence moving forward.
2. Collect what you can: Work with system administrators to gather whatever logs exist. Prioritize:
a. Authentication logs (domain controllers, identity providers)
b. Endpoint detection and response (EDR) logs if available
c. Firewall and network device logs
d. Web server and application logs
e. Cloud audit trails (e.g., AWS CloudTrail, Azure Activity Log)
3. Normalize and correlate: Use forensic tools or SIEM-like features in incident response platforms to convert disparate logs into a common format. Align timestamps, correct for time zones and normalize fields. This process is tedious but critical. In a pinch, I have used open-source log analysis frameworks like ELK (Elasticsearch, Logstash, Kibana) and OSSEC to ingest logs quickly.
4. Establish a timeline: Identify the earliest indicator of compromise you can find. Then map each event to build a timeline: credential usage, file access, network connections, changes to systems or permissions. Even partial timelines can reveal patterns.
5. Hunt for persistence: Search for new accounts, scheduled tasks, or registry keys that may allow the attacker to regain access. Without central logs, this requires manual inspection and endpoint forensic tools.
6. Engage external expertise: When evidence is scarce, bringing in a digital forensics team can help. They may perform memory analysis, disk imaging and network forensics to uncover activity not captured in logs. This is expensive but often necessary.
7. Report truthfully: If you cannot conclusively determine the scope, be transparent with regulators, customers and insurers. Explain the limitations due to logging gaps and commit to remedial actions.
Once the immediate crisis is contained, leadership inevitably asks, “How do we prevent this in the future?” My answer is always the same: start with logging hygiene and a SIEM, and treat it as a strategic business investment rather than an afterthought.
Before tossing every log into a central store, identify which systems and data are most critical. Payment platforms, identity providers, source code repositories, manufacturing control systems, these are your crown jewels. Ensure they log events such as access attempts, configuration changes and data exports. Map their dependencies so you don’t miss adjacent systems.
Not all SIEMs are equal. Some rely on on-premises infrastructure; others are cloud-native. Evaluate based on scalability, cost, ease of integration and analytics capabilities. Consider open-source stacks like ELK or enterprise platforms like Google SecOps, Splunk, Microsoft Sentinel, SentinelOne or Sumo Logic. The goal is not just centralization but correlation and context. Many modern platforms incorporate user and entity behavior analytics (UEBA) to detect anomalies.
Collecting every log can be overwhelming and expensive. Prioritize based on risk and detection value. Authentication and identity logs, network traffic flows, endpoint events and critical application logs usually provide the most insight. Set retention periods based on regulatory requirements and investigative needs. For example, PCI DSS requires at least one year of audit logs, with three months immediately available. Longer retention helps detect long-term campaigns but incurs storage costs. Use compression and tiered storage to manage budgets.
Establish a consistent logging format and use secure protocols to transmit logs to your SIEM. Include essential fields: timestamp, user identifier, source and destination IPs, request method, response code, event outcome, and unique identifiers. Protect logs from tampering by storing them in append-only repositories or enabling immutable storage features. Monitor the logging infrastructure itself to detect tampering attempts.
Logging without monitoring is just record keeping. Configure your SIEM to alert on suspicious behavior: repeated login failures, privileged account creation, unusual data exfiltration, abnormal process execution, or anomalies in network flows. Use threat intelligence to flag connections to known malicious IPs. Avoid over-alerting; tune thresholds and correlation rules to reduce noise. Invest in skilled analysts to triage and respond to alerts.
Logging and SIEM are living systems. Perform regular purple team exercises where red-teamers attempt to bypass detection and blue-teamers test alerting. Use the lessons learned to refine log collection and alert logic. Align with frameworks like NIST SP 800-61 Rev. 2 for incident handling and NIST SP 800-92 for log management. These provide detailed guidance on planning, data sources, implementation, and continuous improvement. In regulated industries, align with requirements such as PCI DSS, HIPAA and GDPR. Document processes for audits.
Beyond the obvious technical benefits, robust logging and monitoring support strategic objectives:
• Insurance and liability: Insurers increasingly scrutinize security controls when underwriting. Demonstrating a mature logging program can help secure coverage and avoid exclusions for “lack of due diligence.” When a breach occurs, comprehensive logs provide evidence to support claims.
• Regulatory compliance: Many laws and standards require logs. The Payment Card Industry Data Security Standard (PCI DSS), HIPAA, GDPR and SOC 2 all reference audit trails. Failing to log adequately can lead to fines and reputational damage
• Operational insight: Logs aren’t just for security. They reveal system performance issues, configuration errors and user behavior. This information helps teams improve reliability and user experience.
• Incident learning: After an incident, logs allow teams to conduct root-cause analysis, refine detection and improve defences. Over time, this builds organizational muscle memory and resilience.
It’s worth reflecting on some real cases. The July 2024 CrowdStrike incident is a stark reminder that even security tooling itself can fail catastrophically. A single faulty content update caused millions of endpoints to crash simultaneously, underscoring that no tool is immune to failure and that the telemetry around your security stack matters as much as the stack itself. Similarly, multiple ransomware victims have discovered that their backups were destroyed because the attackers silently disabled logging on the backup servers weeks earlier. Without logs, no one noticed until the restoration phase.
In my career, I’ve responded to a breach at a regional hospital where patient records were exfiltrated. The organization lacked EHR application logs, and the database audit trail was turned off to improve performance. We discovered that the attacker had exploited a misconfigured VPN account months earlier. But because there were no logs, we couldn’t prove whether the attacker accessed certain records. The hospital was forced to notify all patients and faced a class-action lawsuit. Implementing an appropriate logging strategy would have cost tens of thousands of dollars. The breach cost millions.
Technical solutions alone won’t fix logging hygiene. Organizations must cultivate a culture where logs and monitoring are valued. Here are some human and organizational factors:
• Ownership: Assign clear ownership of logging and monitoring. Someone must be responsible for ensuring logs are collected, forwarded, stored and reviewed. Without ownership, logging becomes everyone’s problem and no one’s priority.
• Education: Developers need to understand which events should be logged and why. Operations teams must appreciate the trade-offs between cost and visibility. Incident responders should know what logs exist and how to access them. Cybersecurity awareness training should include guidance on logging and monitoring.
• Executive sponsorship: Logging budgets compete with product features and marketing. Executives must champion the need for logging and SIEM investment, seeing it as foundational for risk management. Show them the cost of incidents where logs were missing compared with the cost of the logging program.
• Continuous improvement: Threats evolve. Logging strategies must adapt. Establish feedback loops between detection engineers, incident responders and developers. Conduct post-mortems after incidents and near misses. Adjust logging and monitoring accordingly.
Responding to cyber incidents without a SIEM and with poor logging hygiene is like trying to piece together a jigsaw puzzle with most of the pieces missing. It prolongs detection, complicates containment, hampers forensics and erodes trust. Yet, many organizations still operate in this mode due to cost, complexity or complacency. The good news is that logging and monitoring are solvable problems. They require investment, discipline and cultural change, but they pay dividends in incident response, compliance and business continuity.
As someone who has walked into too many blind situations, my advice is simple: turn on the lights before you need them. Build a comprehensive logging and SIEM program tailored to your organization’s risk and scale. Test it, refine it and make it part of the fabric of your operations. That way, when the next alert comes in, you won’t be fumbling in the dark. You’ll have the evidence you need to respond decisively, minimize damage and demonstrate to regulators, insurers and customers that you take security seriously. If you’d like help building a detection and response program that turns your logs into real-time intelligence, contact the Arctiq team