This article concludes our four-part series on the basic differences between traditional IT security and blockchain security. Previous articles discussed the security differences critical for node operators, smart contract developers, and end users.
In many ways, Security Operations Center (SOC) analysts and node operators face similar blockchain-related security challenges. The scale of SOC operations brings with it unique security challenges. Reduced telemetry from decentralized infrastructure hinders SOC detection, but additional information available on-chain could drive new ways of detecting security-related events.
The effectiveness of a SOC that is focused on detecting and responding to blockchain, crypto, and DeFi threats might be significantly improved if it took a “fusion” approach that combines various fraud detection methods with the most effective cybersecurity methods, all adapted for blockchains and decentralized networks.
To illustrate the differences, this article examines the scenario in which a corporate SOC monitors and detects threats to assets and solutions deployed on a permissionless, immutable, public blockchain. Other blockchain types, such as Hybrid, Consortium, or Private, that give an organization more control over the blockchain would have more similarities with traditional IT SOCs.
The Role of the SOC
The SOC is responsible for securing an enterprise against attack. This includes operating and monitoring security solutions, investigating potential attacks, and performing incident remediation and response.
Corporate digital transformation efforts have increased the complexity of the environments that SOC teams are responsible for securing. In recent years SOC functions are becoming accountable for securing increasingly heterogeneous, complex environments of on-prem systems, data centers, cloud deployments, Internet of Things (IoT) and other IT and Operational Technology (OT) infrastructure.
Corporate SOCs may face the most significant challenge yet with the adoption of blockchains and decentralized networks, as they are given the responsibility to monitor and mitigate threats to solutions they might have no control over.
SOC Operations for Traditional IT vs Blockchain-Based Decentralized Networks
Growing institutional investment in blockchain technology means that SOC teams will increasingly become responsible for assets and solutions deployed on blockchain-based decentralized networks. However, blockchain environments differ significantly from traditional IT systems, and security solutions designed for conventional IT may not map cleanly to blockchain ecosystems.
SOC analysts are accustomed to having access to a great deal of data — and often too much data — regarding the systems under their care. For example, a SOC commonly has access to log files, network traffic (various network flows), other data from their endpoints, contextual information, etc. This information can then be used to identify potential threats to the organization and its systems.
With blockchain-based systems, the amount of data available to SOC analysts depends on their involvement in the blockchain network. A SOC for an organization that operates a full blockchain node would have complete visibility into all operations performed on the blockchain, including those with very limited or no relevance to the company’s addresses and smart contracts.
On the other hand, a company that doesn’t operate a node can be more deliberate about the information it collects and processes. However, this comes at the cost of relying on one or more node operators for accurate telemetry.
In many cases, a SOC might not have access to any node telemetry at all.
Over time, SOC analysts have been slowly relinquishing control over their IT infrastructure stack. With on-prem IT architecture, an organization has complete control over its IT systems and networks. This allows the SOC to appropriately configure security controls and use a wide range of tools to monitor and protect its IT infrastructure.
With the adoption of cloud computing, security teams have given up a certain amount of control over their IT infrastructure stack. Cloud service providers manage, maintain, and secure leased services’ infrastructure. As a result, security teams are more limited in the security solutions they can use to monitor and protect their cloud deployments.
With decentralized networks and public blockchain technology, companies give up even more control over their IT infrastructure. Blockchains are hosted by networks of distributed nodes, which are not under an organization’s control (unless it is a private, internal blockchain network). As a result, SOC teams may have limited visibility into their underlying architecture and be unable to enforce secure configurations for nodes in the blockchain network.
If their business solutions are deployed to or utilize public blockchains, SOC teams have to operate under the assumption that they have zero control over the underlying decentralized infrastructure.
Threat management is one of the core responsibilities of a SOC team. In a traditional IT environment, SOC analysts are often tasked with triaging and investigating alerts to identify ongoing attacks and threats to the organization. Usually, this results in a mix of threat prevention — blocking attacks before they pose a threat — and threat detection and response.
In a traditional IT environment, a SOC has multiple tools at its disposal for detecting, and stopping, potentially malicious activity at every step of a cyber kill chain – from reconnaissance to maintenance or exfiltration. It gives a SOC multiple opportunities to stop a threat actor before they execute on their objectives.
On the blockchain, threat detection and prevention stakes are much higher.
Due to potentially very limited visibility, a SOC might not be able to observe any useful signals from any steps in a cyber kill chain until the final step – “Actions on Objectives” (in Lockheed Martin Cyber Kill Chain).
Blockchain immutability means that attacks cannot be reversed, so they must be prevented. Or detected and stopped very quickly to limit the losses.
When the visibility is reduced to potentially only the final step in a cyber kill chain, and the reaction time for containment is reduced to potentially minutes, SOC’s Mean Time To Detect (MTTD) and Mean Time To Respond (MTTR) objectives are compressed to a small fraction of what they would be in a traditional IT SOC.
In traditional IT, one of the most significant challenges of post-incident digital forensics is collecting complete, trustworthy evidence. Data stored in volatile and mutable memory may be overwritten or modified by an attacker. Additionally, the tools used to collect various types of evidence can cause other evidence to be corrupted or missed entirely.
One advantage of the blockchain for security is that all forensic evidence of on-chain activities is preserved and readily available. All transactions performed on the blockchain are recorded on its immutable digital ledger. This makes it easy for SOC analysts — and anyone else — to conduct an in-depth investigation of a cyberattack. This visibility can be invaluable for tracking the parties behind an attack and, ideally, regaining stolen assets.
However, the same access to evidence doesn’t extend to attacks against the nodes that host the blockchain network. Since these nodes are globally distributed and outside the organization’s control, a company may have very limited or no visibility into attacks targeting the blockchain’s nodes and networks. As a result, eclipse attacks and similar infrastructure-level exploits may be difficult or impossible to investigate.
Incident response and remediation is an integral duty of the corporate SOC or incident response team (IRT). After thoroughly investigating a security incident and collecting any necessary digital evidence, the IRT and SOC are responsible for restoring corporate systems to normal operations and, ideally, preventing a similar attack from occurring again.
For blockchain-based systems, a SOC’s ability to remediate a security incident is limited. The blockchain’s digital ledger is immutable, so it is impossible to reverse an attack after it has occurred. In most cases, incident response boils down to damage control and developing a plan to compensate affected parties for lost assets.
Developing Security Operations Approaches for Corporate Blockchains
SOC teams are responsible for developing and implementing security plans to cover their organization’s IT infrastructure. With expansion into blockchain-based technologies come unique risks and security challenges. Blockchain architecture works very differently from traditional systems, and security incidents are much more difficult to detect or manage after the fact.
As a result, SOC teams must develop security plans tailored to the unique needs and constraints of their blockchain-based systems.
Shift Left Security
Shift left refers to moving security sooner in the development process. A tighter integration of security throughout the software development and deployment processes leads to better security outcomes. With limited options for threat detection and monitoring in production, this becomes even more critical. And a SOC should have a role to play in this.
The SOC model is already changing. In many organizations, it is becoming the function that helps merge development, security and operations teams into a unified model and drive efficiencies by applying its automation skills to this new DevSecOps model. In addition to driving security-related processes such as static application security testing (SAST); dynamic application security testing (DAST); container scans; compliance scans; dependency scans; etc. a blockchain SOC should also integrate Smart Contract audits, penetration tests and other smart contract-specific preventative steps in order to help identify as many vulnerabilities as possible before deployment.
Blockchain Network Layer Detection
Blockchain security based on consensus mechanisms is highly dependent on the security of the underlying blockchain network. Blockchain network nodes must be capable of reliably exchanging ledger state information. Through network layer attacks, e.g., large-scale eclipse attacks, DDoS attacks, Sybil and Erebus attacks, the attacked nodes or subnets could become isolated from the blockchain main network and start generating different ledger copies. An attacker could capture unlawful interests and undermine the stability and security of the entire blockchain system.
For example, in an eclipse attack, an attacker could take over control of a number of IP addresses (through e.g. routing table poisoning). This would allow the attacker to monopolize all connections with the victim blockchain network nodes and isolate them from the master network, which could then allow the attacker to, for example, present a different state of the ledger to the victim.
A blockchain-focused SOC should understand these blockchain-specific network layer attack methods and implement detection rules tuned for features present in specific attack traffic.
While a blockchain SOC might have significantly reduced telemetry from networks and nodes compared to traditional IT, on-chain data provides a powerful new security-relevant source of information.
By expanding its scope to include signals traditionally belonging to fraud or financial crime monitoring, a SOC could significantly improve its detection correlation effectiveness. Monitoring on-chain activity and correlating it with off-chain signals and contextual information allows it to detect threats and anomalies in blockchain, DeFi, NFT, governance, bridges and other Web3 systems in real-time. Where exploits require multiple transactions over multiple chains and bridges, as was the case in many of the largest recent attacks, a “fusion” approach offers the opportunity for early detection and mitigation before the exploit is complete.
For example, traditional node and network security monitoring signals could be correlated with blockchain-specific cybersecurity-focused monitoring such as smart/proxy contract upgrades, ownership transfers, admin address changes, calls to administrative smart contract methods; which could be further correlated with fincrime-focused and business signals such as protocol executing out of bounds, transactions with unusually high gas prices, transactions from high-risk addresses, transactions that significantly affect liquidity, etc. Such “fusion” approach could significantly increase detection rates.