Crypto Logging, Monitoring, and SIEM: The Web3 Security Operations Guide

Why Logging and Monitoring Is the Blind Spot of Web3 Security

The Web3 security industry has developed a concentrated focus on pre-deployment security: smart contract audits, formal verification, penetration testing before launch. These are necessary controls. They are not sufficient controls. A firm that completes a rigorous audit and then operates without any logging or monitoring capability has eliminated one attack surface while leaving the rest of its infrastructure in complete darkness.

The practical consequence of this gap is visible in the post-breach forensics of every major crypto hack of the past four years. When investigators attempt to reconstruct what happened, how the attacker entered, what they accessed, how long they had access, and what data was exfiltrated, they routinely find one of two situations: either the relevant logs were never retained, or the attacker deleted them as part of the intrusion. In both cases, the investigation is severely limited, the full scope of the breach cannot be established, and regulatory reporting obligations cannot be met.

Without logs, you cannot detect an insider threat until after material damage has occurred. You cannot identify a compromised account based on anomalous behaviour. You cannot determine the scope of a breach during response. You cannot produce the evidence required for law enforcement, litigation, or regulatory notification. Logging is not a nice-to-have. It is the foundational capability that makes all other security functions possible.

The counterargument, that logging is operationally complex and expensive, is increasingly untenable. Cloud-native SIEM tools have reduced both the cost and the complexity of centralised log management significantly. The cost of operating a minimal logging capability is a fraction of the cost of a single successful breach with no forensic trail.

What a Crypto Firm Must Log

Log sources for a crypto firm span four distinct layers: infrastructure, on-chain activity, application behaviour, and endpoint activity. Each layer covers a different set of attack paths. Gaps in any layer create blind spots that attackers can exploit without generating a detectable signal.

Infrastructure and System Logs

Authentication events are the highest-priority log source for any organisation. Every successful login, every failed login, every password reset, every privilege escalation, and every session token issuance must be logged with the associated identity, timestamp, source IP, and device identifier. Authentication anomalies, logins from unexpected geographies, logins at unusual hours, rapid sequential authentication failures, are among the most reliable early indicators of account compromise.

Privilege escalation events require particular attention. In most infrastructure environments, a legitimate user has no reason to escalate privileges routinely. Any use of sudo, administrative role assumption, or elevated permission grant should generate a log entry that is reviewed. Unexplained privilege escalation is a strong indicator of lateral movement by an attacker who has gained an initial foothold.

Configuration changes to infrastructure, security groups, firewall rules, IAM policies, and network configurations must be logged and ideally subject to change management controls that require human review before application. Attackers who gain administrative access commonly modify configurations to establish persistent access or disable security controls. These changes leave log traces if logging is enabled.

Blockchain and On-Chain Events

On-chain activity represents a log source with no analogue in traditional enterprise security. Every transaction broadcast to a blockchain is permanently recorded and publicly verifiable. The question for a crypto firm is not whether the record exists, but whether the firm has the tooling to monitor that record in real time and generate alerts when anomalous activity occurs.

Treasury wallet transactions, smart contract interactions including governance function calls, bridge operations, and liquidity pool movements all generate on-chain events that must be monitored. A treasury wallet that sends an unexpected transaction at an unexpected time is one of the clearest possible signals of a key compromise. A governance contract that receives a proposal from an unexpected address may indicate an attempt to pass a malicious governance action.

Application Logs

API authentication events, including issued tokens, token revocations, and rate limit breaches, provide visibility into how services are being accessed and whether credential abuse is occurring. Admin panel access must be logged comprehensively: who accessed the panel, what actions they took, and what data they queried. Failed authentication attempts to admin interfaces, particularly in patterns that suggest automated credential stuffing, should generate immediate alerts.

Unusual query patterns in databases and APIs, including very high query volumes, queries for data outside the user's normal scope, and queries that span multiple high-value data sets sequentially, are characteristic of data exfiltration. Application-layer logging that captures query patterns enables detection of these behaviours before material data leaves the organisation.

Cloud Provider Logs

AWS CloudTrail, GCP Audit Logs, and Azure Activity Log are the cloud provider equivalents of infrastructure logs, capturing every API call made against the cloud environment. These logs are available but not enabled by default in all configurations, and critically, they are not retained indefinitely by default. Firms must explicitly enable comprehensive audit logging and configure log forwarding to a centralised retention system outside the primary cloud account. Logs stored only in the same account that was compromised will be accessible to an attacker with account-level access.

Cloud provider logs capture IAM changes, storage bucket policy modifications, network configuration changes, and compute instance launches, all actions that an attacker with cloud credentials will take. They also capture data access events: which identities accessed which S3 buckets or GCS objects, and when. This is essential for determining the scope of data exfiltration during a breach investigation.

Endpoint Logs

Endpoint detection and response agents on developer workstations, signing machines, and privileged access workstations generate logs covering process execution, network connections, file system changes, and user activity. These logs are particularly important for detecting malware that has been deployed on a privileged machine, including keyloggers of the type used in the LastPass breach. Endpoint logs must be forwarded to a centralised system immediately: an attacker who compromises a machine may be able to delete local logs, but cannot delete logs that have already been shipped to a remote system.

Log Retention Requirements

Log retention policy must balance operational access requirements, storage costs, and regulatory obligations. For crypto firms operating under or preparing for European regulatory frameworks, the minimum retention periods are not discretionary.

Twelve months of hot storage is the operational standard for immediately accessible logs. Logs within this window should be queryable in real time for incident response and threat hunting. The 12-month window covers the majority of breach scenarios where dwell time is measured in weeks to months, and provides sufficient history for investigating incidents that are discovered with a delay.

Seven years of archive storage is the standard implied by financial services regulatory frameworks including DORA and MiCA, which require that organisations be able to support regulatory investigations and demonstrate auditability over extended periods. Archive logs do not need to be immediately queryable, but must be retrievable within a defined and tested timeframe.

Immutable log storage is not optional. Attackers who gain system access routinely delete or modify logs to obstruct investigation. Write-once storage, achieved through cloud services like AWS S3 Object Lock, GCP Cloud Storage with retention policies, or dedicated immutable log platforms, ensures that logs cannot be modified or deleted even by a compromised account with administrative privileges. Log integrity verification using cryptographic hashing provides an additional layer of assurance that stored logs have not been tampered with.

The tradeoff between centralised and distributed log storage is primarily one of access control and resilience. Centralised storage in a dedicated logging account or SIEM reduces the risk of logs being deleted via a compromised production account, but creates a high-value target if the logging account is not itself adequately secured. Distributed storage across multiple regions and accounts increases resilience but complicates querying. Most crypto firms at early to mid scale will achieve an adequate balance with a dedicated logging account in their cloud provider, with cross-region replication enabled.

What Is a SIEM and Does a Crypto Firm Need One

A Security Information and Event Management (SIEM) system aggregates log data from across an organisation's infrastructure, applies correlation rules to identify patterns that span multiple log sources, and generates alerts when those patterns match known attack behaviours or anomalies. The SIEM is the operational hub of a security operations function: the platform through which analysts investigate alerts, conduct threat hunting, and maintain situational awareness.

The question of whether a crypto firm needs a SIEM is best answered by asking a different question: can the firm's current security team manually review the volume of logs being generated and identify anomalies in time to respond? For a two-person startup with minimal infrastructure, the answer may genuinely be yes, with structured log review processes and targeted alerting. For any firm with multiple cloud accounts, a significant developer team, a live protocol with on-chain activity, and a treasury holding material assets, the answer is almost certainly no.

The leading cloud-native SIEM platforms relevant to crypto firms are:

• Splunk Enterprise Security: The established enterprise standard, with the broadest ecosystem of integrations and detection content. Cost is a significant factor at smaller scale.
• Elastic SIEM (Elastic Security): Open-source foundation with enterprise support options. Strong fit for firms already using the Elastic stack for application logging.
• Microsoft Sentinel: Cloud-native SIEM with deep Azure integration and consumption-based pricing. Cost-effective for firms operating primarily on Azure.
• Datadog Security Monitoring: Strong fit for firms already using Datadog for infrastructure observability. Allows converging security and operational monitoring into a single platform.
• Chronicle (Google Security Operations): Google's cloud-native SIEM with a flat-rate pricing model and strong threat intelligence integration.

For early-stage firms that are not yet ready to operate a full SIEM, cloud provider native security services provide a meaningful intermediate step. AWS Security Hub, GCP Security Command Center, and Azure Defender aggregate findings from cloud-native security services and provide a centralised view of security posture without requiring a separate SIEM deployment. These services should be enabled immediately, before a full SIEM is in place.

The security operations centre model, whether internal or managed, provides the human layer that makes a SIEM operationally effective. A SIEM without analysts reviewing alerts and tuning detection rules will generate noise without producing security value. Firms that cannot staff an internal security operations function should consider a managed detection and response (MDR) provider that operates a SIEM on their behalf.

On-Chain Monitoring: The Layer Most Firms Miss

Traditional SIEM platforms were built for enterprise IT environments. They have no native understanding of blockchain transactions, smart contract states, or decentralised protocol mechanics. A crypto firm that deploys a SIEM and considers its monitoring needs addressed has left an entire attack surface unobserved.

Treasury wallet monitoring is the most immediately critical on-chain monitoring requirement. Every address holding organisational funds must be monitored for unexpected outbound transactions in real time. The response time window for a treasury drain is measured in minutes: once funds have moved on-chain, a rapid response to pause bridges, notify exchanges, and engage blockchain analytics firms is the only path to partial recovery. A firm that discovers a treasury drain hours after it occurred because they had no real-time monitoring has permanently lost the recovery window.

A breach that goes undetected for six months is not a technical failure. It is a logging and monitoring failure. Every major crypto hack has involved an extended dwell time that better visibility would have cut short.

Governance contract monitoring is essential for any protocol with on-chain governance. Unexpected proposal submissions, voting anomalies, and attempts to pass governance actions from previously inactive addresses are characteristic of governance attacks. Monitoring must cover proposal creation events, not just execution events. By the time a malicious proposal is executing, the response window may already have closed.

Bridge and liquidity pool monitoring applies to protocols with cross-chain components or AMM liquidity. Anomalous flow patterns, including unusually large single transactions, transactions that approach or exceed pool limits, and transaction patterns consistent with price manipulation, should generate alerts. Many of the largest protocol exploits in history have involved transaction patterns that, in retrospect, would have been identifiable in the minutes before the exploit completed.

The primary tools for on-chain monitoring are:

• Forta Network: A decentralised network of detection bots that monitor blockchain activity. Firms can deploy custom bots that monitor their specific contracts and wallet addresses, or subscribe to community bots that monitor known exploit patterns.
• Tenderly: Provides real-time alerting on smart contract events, transaction monitoring, and simulation capabilities. Strong fit for EVM-compatible protocol monitoring.
• Custom webhook alerting via RPC providers: Direct subscription to blockchain events via providers such as Alchemy, Infura, and QuickNode, with custom filtering and alerting logic. Provides maximum flexibility but requires internal engineering investment.
• Chainalysis and TRM Labs: Enterprise blockchain analytics platforms with real-time alerting on counterparty risk, sanctions screening, and anomalous transaction patterns.

Alert thresholds and escalation paths for on-chain monitoring must be defined before deployment. An alert that reaches nobody is no better than no alert. Every on-chain monitoring alert category should have a defined escalation path specifying who is notified, through which channel, and what the initial response steps are, including out-of-hours coverage for treasury alerts.

On-chain monitoring data should be fed into the firm's central cyber threat intelligence function, correlating blockchain activity with intelligence on known attacker wallets, sanctioned addresses, and addresses associated with previous exploits. This correlation can identify threats at the point of reconnaissance before an attack is attempted.

Detecting Insider Threats Through Logging

Insider threats represent one of the most difficult risk categories to address in any organisation, and crypto firms face an elevated version of this risk. The presence of high-value, liquid, and largely irrecoverable assets creates a financial incentive for insider action that exceeds most corporate environments. A single insider with access to key management systems or treasury signing authority can cause losses that would be catastrophic for a fund or protocol.

Insider threats leave characteristic patterns in logs. No insider operates with perfect operational security across all systems, and the combination of access logs, authentication records, data transfer logs, and endpoint activity creates a multi-source picture that is difficult to suppress entirely. The key is ensuring that these log sources are enabled, centralised, and subject to analysis.

Anomalous access timing is one of the most reliable indicators. Legitimate employees access systems during working hours. Access events at unusual times, particularly late at night or during company holidays, warrant investigation when they involve sensitive systems. Access timing alone is not proof of malicious intent, but combined with other anomalies it is a strong signal.

Data volume anomalies are characteristic of pre-exfiltration behaviour. An employee who downloads an unusually large volume of data, particularly structured data such as credential lists, customer records, or internal documentation, in the days or weeks before their departure (or before they are detected) is exhibiting a pattern consistent with insider threat activity. Log-based data loss prevention (DLP) detects this pattern.

Lateral movement and out-of-scope system access occur when an insider attempts to access systems outside their normal role, or when a compromised account is used to access new systems. A developer who suddenly accesses financial systems, or an operations employee who attempts to query internal security tooling, is exhibiting a pattern that warrants investigation.

User and Entity Behaviour Analytics (UEBA) applies machine learning to establish a behavioural baseline for each user and entity in the environment, then generates alerts when behaviour deviates from that baseline in ways associated with threat patterns. UEBA is available as a capability within most enterprise SIEM platforms and as standalone solutions. For high-risk personnel, including key custodians, treasury signatories, and individuals with access to critical signing infrastructure, UEBA provides a layer of detection that rule-based monitoring alone cannot achieve.

Incident Response Integration: From Alert to Action

A monitoring capability that generates alerts without a defined response process provides incomplete protection. The response process determines whether a detected threat is contained before material damage occurs, or whether the detection arrives too late to prevent loss. Integration between monitoring and incident response is the bridge that turns visibility into protection.

The mean time to detect (MTTD) is the key metric for monitoring effectiveness. It measures the time from when an attacker's activity first becomes detectable in logs to when a security team identifies it as a threat. For crypto firms, where the consequence of a breach is often immediate and irreversible fund loss, MTTD should be measured in minutes for high-severity alert categories such as treasury wallet transactions and key management system access. For lower-severity categories, hours to days may be acceptable, depending on the potential impact.

The incident response plan must include specific playbooks for the alert types generated by the monitoring programme. A treasury wallet alert playbook at 3am must specify: who is contacted and how, what immediate technical actions are taken (pausing bridges, contacting exchanges, initiating a multi-sig freeze), what information is gathered to confirm whether the alert is a true positive or false alarm, and who has authority to escalate to external response resources. Playbooks that are not tested are not reliable. Each critical alert type should be exercised through tabletop exercises at minimum once annually.

Alert fatigue is a real operational risk. A monitoring configuration that generates hundreds of low-fidelity alerts per day will cause analysts to become desensitised, increasing the probability that a genuine high-severity alert is missed in the noise. Tuning detection rules to reduce false positives, and tiering alerts by severity and confidence, are ongoing operational disciplines. The initial alert configuration will not be optimal. Improvement requires data from real alert handling, reviewed in a structured retrospective process.

Escalation paths must be defined for after-hours alerts. Crypto protocols operate continuously. Attackers do not restrict their activity to business hours. The most effective attacks are often timed to occur during low-coverage periods, such as nights, weekends, and public holidays in the firm's primary timezone. A monitoring programme that has no out-of-hours coverage for critical alerts is providing only partial protection.

Logging as a Regulatory Requirement

DORA compliance requirements establish explicit obligations for ICT-related incident detection that have direct implications for logging and monitoring. Article 10 of DORA requires that financial entities implement mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. This is not a principles-based obligation: it requires demonstrable capability to detect, log, and report on ICT incidents.

DORA further requires that financial entities maintain detailed records of ICT incidents and that these records be available to competent authorities on request. An organisation that suffers a breach and cannot produce adequate log evidence for a regulatory investigation faces both the consequences of the breach itself and potential regulatory sanctions for inadequate incident detection and record-keeping. For firms seeking to operate as regulated financial entities under DORA, a functional logging and SIEM capability is not optional.

The Markets in Crypto-Assets Regulation (MiCA) does not contain prescriptive logging requirements equivalent to DORA Article 10, but its broader operational security requirements implicitly require the auditability that only adequate logging can provide. A firm that cannot demonstrate to a regulator how its infrastructure is monitored, how it would detect a breach, and how long it retains security-relevant records will struggle to evidence compliance with MiCA's operational resilience requirements.

Beyond formal regulatory obligations, logging is essential for the forensic investigations and insurance claims that follow a significant breach. Cyber insurance underwriters are increasingly requiring evidence of logging and monitoring capabilities as a condition of coverage. Firms that cannot evidence adequate controls may find coverage denied or premiums significantly elevated.

Building a Minimal Viable Logging Programme

For firms that currently have no structured logging capability, the objective is not to immediately deploy a full SIEM. It is to move from zero visibility to meaningful coverage as quickly as possible, prioritising the log sources that cover the most critical attack paths.

Priority 1: Enable cloud provider audit logs. This is a configuration change, not a product deployment. In AWS, enable CloudTrail in all regions with S3 log storage in a dedicated logging account. In GCP, enable Cloud Audit Logs for all services. In Azure, enable Activity Log and Diagnostic Settings for all resources. Configure log retention to at least 12 months. This single action provides visibility into every API call against your cloud infrastructure and is the most impactful logging improvement available for the least effort.

Priority 2: Centralise authentication event logging. Ensure that your identity provider, whether Okta, Google Workspace, Azure AD, or another platform, is configured to log all authentication events and that those logs are retained and regularly reviewed. Authentication events are the earliest signal of account compromise. Enable alerts for failed login patterns and logins from new geographies as a minimum.

Priority 3: Deploy on-chain monitoring for treasury addresses. Configure real-time alerting for all addresses holding organisational funds, using one of the platforms described above. This requires no change to existing infrastructure and directly addresses the highest-consequence attack category for a crypto firm.

Priority 4: Implement monthly log review. Before investing in automated correlation and alerting, establish the discipline of manual monthly log review. A structured review of authentication logs, admin actions, and cloud API calls, even conducted manually, will identify issues that automated rules miss and build the institutional knowledge needed to tune automated detections later.

Priority 5: Deploy a SIEM when the log volume justifies it. Once the firm has multiple sources generating meaningful log volumes, the manual review approach becomes inadequate. At that point, evaluate SIEM platforms based on the log sources you have, the budget available, and whether you have the internal capability to operate the platform or need a managed service.

The endpoint for a mature logging programme is a continuously monitored environment where every significant event across cloud infrastructure, authentication systems, applications, endpoints, and on-chain activity generates a log that is retained for regulatory purposes, searchable for investigations, and subject to automated correlation that generates prioritised alerts for the security team. Getting there is a journey. The critical step is beginning it with the right priorities rather than waiting for the perfect solution.