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.

Node Telemetry

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.

Infrastructure Management

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 Detection

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.

Forensic Operations

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

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.

“Fusion” Approach

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.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 4 – Security Operations (SOC) appeared first on Cryptosec.

This article explores how user security differs between traditional IT and blockchain environments.  While identical products and services may be hosted in traditional IT and blockchain environments, the differences between these ecosystems can have significant security implications for their users.

IT vs. Blockchain Security for Users

Traditional IT and the blockchain operate under very different philosophies.  Many traditional IT systems are centralized and try to control every aspect of the user experience.  In contrast, the ethos of distributed ledger technology focuses on decentralization and self-custody.

These different philosophies have resulted in very different infrastructures and ways of doing things.  These differences have significant impacts on the user experience and user security.  Some of the biggest differences between IT and blockchain security for users include the following.

Account Security

Traditionally, access to user accounts has been managed based on passwords.  Ideally, a user will have a unique, strong, and random password for each account, but this is not always true.  As a result, biometrics, multi-factor authentication (MFA), and other techniques have emerged to improve account security.

On the blockchain, control over an account is managed via private keys.  Creating an account requires generating a private key from which a public key and account address can be derived.  Every distributed ledger transaction made using that account must be digitally signed with the appropriate private key.

While a private key is more secure than a password, it is also more difficult for users to remember and manage.  A lost private key is a significant threat for users.  If a key is lost, then access to the account is lost forever without the option to reset it like there is with a password.

Like with passwords, private key security is also a significant risk on the blockchain.  Attackers have developed numerous means for stealing keys, including phishing, malware, and other threats.  Also, the structure of private keys and mnemonic phrases makes them easier for an attacker to search for them in a computer’s memory.

Credential Management

In traditional IT systems, users have two main options for credential management.  One is to use weak credentials that they can easily remember and input into their accounts.  The other is to rely upon password managers, single sign-on, and similar tools that make the use of strong credentials possible and scalable.  In general, many of the leading solutions are well-established and have undergone thorough security audits.

One of the main selling points of blockchain technology is self-custody or the fact that a user has full control over their account and the value that it contains.  However, private keys are random, which makes them difficult to recall.  As a result, many blockchain users rely on various tools — software wallets, hardware wallets, third-party key management services, etc. — to store and manage their private keys.

These key management solutions introduce new risks for blockchain users.  If the solution is compromised, malicious, or goes out of business, then an attacker may perform transactions on the user’s behalf or access to their account may be lost forever.  Also, the security of these various platforms and tools can vary greatly, and users may struggle to determine which ones are legitimate and secure.

Incident Recovery

Security incidents can happen to any organization, and after a breach happens companies take action to remediate the incident.  In traditional IT environments, organizations can often restore systems from backups, apply updates, reset passwords, and take other actions to reverse the effects of a security incident.

On the blockchain, the immutability of the blockchain’s digital ledger makes this more difficult.  Once a security incident occurs, no means exists for reversing it.  Additionally, fully decentralized blockchain platforms lack the ability to freeze transactions to block further exploitation of identified vulnerabilities.

As a result, a hack against a blockchain-based project can have a much larger impact on users than a similar incident for a traditional organization.  Any funds stolen by the attacker are lost forever, and the project may lack the resources necessary to compensate users.  Additionally, the design of the blockchain makes recovery actions such as password resets infeasible as private keys are irrevocably tied to a particular blockchain account.

User Privacy

User privacy and data security have become a growing concern for organizations in recent years.  Data protection laws such as the EU’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) have placed strict limits on how companies can collect and use data and laid out requirements on how that data must be protected.

On the blockchain, all actions taken by a user are recorded on a public, immutable digital ledger.  While blockchain accounts are pseudonymous, it is possible to determine the identity of the person behind an account via analysis of blockchain transactions.

As a result, users of blockchain-based platforms have limited privacy unless they actively take actions to protect that privacy, such as the use of single-use accounts and addresses.  On a public blockchain, anyone can determine the balance in a particular account and every action taken by that account to date.

Additionally, blockchain immutability and decentralization mean that this data can never be deleted.  This contributes to the risk that an attacker could collect and correlate multiple pieces of non-sensitive data to derive more sensitive information.  For example, the combination of age, birthday, and zip code is enough to uniquely identify 87.1% of US citizens.  Preserving privacy requires being very careful about what information is posted to public blockchains.

Encryption and Data Privacy

Encryption is one of the most effective means of ensuring data privacy and security.  Modern encryption algorithms are designed to be secure against known attacks and can’t be broken with currently available technology.

However, this will not always be true.  Encryption algorithms commonly used in the past have been broken, and modern algorithms will be breakable in the future.  For example, common public key encryption algorithms such as RSA will be broken as soon as a sufficiently large quantum computer is created.  Even without quantum computers, the length of RSA keys needed for security continues to grow as computers become faster.

Data stored by traditional IT systems can be updated as needed if an encryption algorithm is broken.  However, the same is not true of data stored on the blockchain’s digital ledger.  Blockchain ledgers are immutable and distributed, meaning that data can’t be deleted from them.  As a result, any data stored encrypted on the ledger will most likely become public at some point.  If this includes a user’s personal data, their privacy may be at risk depending on how soon the encryption algorithm is broken.

Corporate Anonymity and Authenticity

In traditional IT environments, the people behind a product or service are publicly known.  For example, the leadership team of Microsoft, Google, Meta, and other companies is well known.  While companies may use shell corporations and similar tools to obfuscate their paper trails, these may not hold up to in-depth investigation.

The design of blockchain environments makes it possible and not uncommon for the team behind a project to be anonymous.  A project team can write and launch code and public marketing materials with most or all of the team anonymous or operating under a pseudonym.

This anonymity makes it much more difficult for a user to determine if a particular project is authentic or a fraud.  While scams are common in traditional IT as well, large rug pulls have become a common occurrence in the crypto space.

Using Blockchain Solutions Securely

Blockchain technology offers users unique solutions and the opportunity for greater ownership and control over their accounts and data.  However, this ownership and the design of the blockchain also create new security challenges.  Blockchain users must also take ownership of their security and intentionally take steps to protect it, such as the use of hardware wallets to protect high-value blockchain accounts and performing their own research before investing in a DeFi project.

This article is the third in a four-part series discussing the differences in security between IT and blockchain environments.  If you haven’t already, check out the first two instalments in the series discussing the differences in security for node operators and application developers.  Also, watch for an upcoming article discussing how blockchain security and IT security differ for Security Operations Centers (SOCs).

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 3 – User Security appeared first on Cryptosec.

This article focuses on the differences between application security (AppSec) for traditional applications and smart contracts.  While the first blockchains, like Bitcoin, were not designed to support smart contracts, their invention dramatically expanded the capabilities of blockchain platforms.  The ability to deploy code on top of the blockchain has been one of the main drivers of blockchain’s widespread adoption and success.

Traditional Development vs. Smart Contract Development

Traditional applications and smart contracts can implement much of the same functionality.  Smart contract platforms are Turing complete, and, on some of them, developers can use the same programming languages as for traditional application development.

However, traditional applications and smart contracts operate in very different environments.  Some of the big differences include the following:

• Infrastructure Stack: Most applications run directly on top of the operating system.  Smart contracts are more like web applications, code that runs within the context of another application.  This design places constraints on the smart contract’s capabilities and the increased complexity creates more opportunities for exploitable vulnerabilities.
• Immutable Ledger: Traditional applications have mutable code and data that are stored on a private server.  Smart contract code and data are stored on an immutable digital ledger that is publicly visible.
• Languages and Ecosystems: Traditional application development is often performed with well-established languages on stable platforms.  Many smart contract platforms use programming languages and virtual machines designed specifically for them that are relatively new.

The same program can be written as a traditional application or a smart contract.  However, the differences between the two programs’ operating environments mean that they face very different security risks and secure coding best practices can vary greatly.

Traditional vs. Blockchain AppSec

Application security (AppSec) is a priority in both IT and blockchain environments. In fact, AppSec is even more vital on the blockchain due to the multiple layers of application code that can exist, including the blockchain software itself and smart contract code that runs on top of blockchain platforms.

However, the challenges of securing applications differ significantly between IT and blockchain environments. Some common AppSec techniques in the traditional IT space include the following.

Technological Maturity

Most of the IT systems and protocols that we rely on today have been around for decades and have undergone extensive security research.  While new vulnerabilities are discovered on a regular basis, many of these are simply new iterations of well-known programming errors.  The fact that the OWASP Top Ten list has changed very little since its initial introduction makes this evident.

Blockchain and smart contract platforms, on the other hand, are much newer.  Bitcoin, the first blockchain, was introduced in 2008, and Ethereum pioneered smart contracts in 2015.  Smart contracts and decentralized finance are reliant on technologies that are less than a decade old, and many Ethereum competitors are much younger.

The relative immaturity of smart contract platforms means that many of the top platforms have received limited security research and entire classes of vulnerabilities may not have been discovered yet.  Additionally, most smart contract platforms are still under development, meaning that new types of vulnerabilities may be introduced over time.  As a result, ensuring that an application is secure is much more difficult in the blockchain space.

Ecosystem Fragmentation and Stability

Application developers write code for a variety of environments, including desktop OSes, mobile devices, and browsers.  However, only a few platforms of each type exist (especially when considering *nix platforms as a single group), and the platforms are relatively stable.  As a result, developers know how various platforms work and best practices for developing secure code for them.

The smart contract ecosystem is much more fragmented and unstable.  While some platforms, such as Ethereum, have developed an early lead and a strong community, technological changes may eventually render them obsolete.  At the same time, new platforms are being developed and are competing for dominance.

The lack of ecosystem stability in smart contract environments makes it more difficult for developers to create secure, stable applications.  Changes to a platform’s design could undermine the security of deployed code, or a smart contract platform could lose the fight for dominance, bringing down the contracts that it hosts with it.  Additionally, the youth and lack of stability in the smart contract ecosystem means that contracts may be written by developers with limited experience with a platform and its secure coding best practices.

Proprietary vs. Public Code

Organizations commonly take extensive measures to keep their application code and intellectual property secret. Applications are commonly closed-source and use obfuscation and legal protections to attempt to deter reverse engineering and attempted exploitation.  By making vulnerabilities more difficult to find, these organizations raise the bar for attackers looking to exploit these vulnerabilities.

Smart contract code is deployed on the blockchain, making the compiled code publicly accessible, and disassemblers are available for some platforms.  Additionally, the source code of many contracts is posted and linked on GitHub

The open-source nature of smart contract code makes it easy for other developers to reuse existing code, which may contain exploitable vulnerabilities.  It also makes it easier for attackers to find vulnerabilities to exploit.  Source code is easier to read and comprehend, and many of the smart contract security tools are designed for static code analysis, which requires source code access.

Operating Environment Privacy

Traditionally, applications run on a server that is under an organization’s control.  Managing access to this server is a core component of a corporate security policy.  By doing so, an organization limits the information available to an attacker, including the code and data used by the application.

Smart contracts run on top of the blockchain, and all of their code and data are recorded in the blockchain’s digital ledger. As a result, all information available to the smart contract is also visible to a potential attacker or malicious contracts.

Writing code that runs in a public environment is very different from writing code for a private server, and secure coding best practices differ for each.  For example, in traditional IT, seeding a cryptographically secure pseudorandom number generator (CSPRNG) with a random value to generate secure random numbers is best practice.  For a smart contract, this is a classic example of a weak randomness vulnerability as the “secret” seed would be publicly visible on the blockchain and anyone could generate the same series of values, breaking the contract’s security.

Access Management

Many of the applications that an organization uses are not designed to be exposed to the public Internet. Firewalls are commonly used to limit access to internal applications by restricting the types of traffic that can cross a network boundary.  By limiting access to their applications, companies make it more difficult for attackers to gain the access and permissions required to exploit any vulnerabilities that may exist.

In contrast, most smart contract platforms are public, permissionless blockchains. Anyone can create an account on the blockchain and interact with any deployed contract.  Additionally, smart contracts can interact with one another, allowing a malicious smart contract to exploit vulnerabilities in other smart contracts.

Without any external access control, smart contracts must implement access management internally.  Smart contract functions must include access controls that restrict access to privileged functionality as an attacker can execute any publicly accessible function.

Reactive vs. Preventative Security

In traditional IT, application security management is often focused on threat detection and response rather than prevention. In many cases, applications and systems can be restored to a secure state after an attack has occurred.  Additionally, vulnerabilities are often handled via updates and patches to code deployed in production.

Blockchain immutability means that smart contract exploits cannot be easily reversed, and deploying updates to code is difficult unless the code is designed to be updatable. Additionally, all security features must be built into smart contract code since no equivalent to a web application firewall (WAF) or intrusion prevention system (IPS) exists for smart contract environments. As a result, smart contract threat management must focus on prevention rather than detection and response.

Security Tool Availability

As mentioned previously, traditional IT applications operate in relatively stable ecosystems, and many of the common vulnerabilities have already been identified.  As a result, numerous solutions exist to help identify vulnerabilities and protect against exploitation.

Smart contract environments’ relative immaturity means that smart contract developers and blockchain security specialists have fewer tools available.  While solutions exist for established platforms such as Ethereum, they still fall short of the available solutions for web application developers.  For developers on newer and less established platforms, vulnerabilities may be totally unknown and solutions non-existent.

Without tools to automate the vulnerability discovery process, securing smart contracts becomes more reliant on individual knowledge and manual effort.  As a result, security audits are even more important in the blockchain space than they are for traditional IT environments.

Regulations and Best Practices

For traditional IT security, regulations, standards, best practices, and guidelines are often readily available.  For example, web application developers can use the OWASP Top Ten List, CWE Top 25, and applicable regulations, such as PCI DSS for sites processing payment card data, as references for common vulnerabilities and security best practices.  While regulatory compliance requirements can be a headache, they are also a valuable resource for ensuring that common vulnerabilities are covered.

Blockchain developers, on the other hand, have much less access to security guides and resources.  While some platforms, such as Ethereum, provide listings of known vulnerabilities, this is not true of all platforms.  Additionally, no universal regulation or standard exists for blockchain and smart contract security.  As a result, it can be more difficult for developers to validate that their code is actually secure and compliant with best practices.

Developing Secure Smart Contracts

Smart contract development is very different from traditional application development.  These contracts operate in a unique environment and face very different security risks.  At the same time, security research and tools have not caught up, making it more difficult to identify and fix vulnerabilities in these contracts.

The high risks associated with smart contract vulnerabilities make secure coding and threat prevention more important than ever.  Adoption of DevSecOps best practices can help smart contract developers to identify and remediate potential security risks in their code before it is deployed to the immutable digital ledger.  Additionally, all smart contracts should undergo security audits before launch to help identify and remediate potentially exploitable vulnerabilities.

This article is the second in a four-part series exploring how security differs between traditional IT and blockchain environments.  Check out the first article in the series here, and keep an eye out for upcoming articles discussing how blockchain security differs for users and Security Operations Centers (SOCs).

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 2 – Smart Contract Developers appeared first on Cryptosec.

As blockchain increasingly underpins major systems, blockchain security becomes increasingly vital.  Financial systems built on the blockchain can suffer significant losses due to exploited blockchain security vulnerabilities.  The use of blockchain for supply chain tracking and audit logging relies on the blockchain being immutable.

However, the widespread adoption of blockchain technology is relatively recent, and blockchain security has not always kept up with the technology.  In many cases, traditional IT security best practices do not work for the blockchain security, leaving the potential for security gaps and additional breaches.

This article is the first in a four-part series exploring how blockchain security differs from IT security or “traditional” cybersecurity.  In this article, we explore the differences for node operators, followed by smart contract developers and the blockchain’s users.

The Transition from IT to Blockchain Security

Blockchains such as Bitcoin, Ethereum, and others are built on top of traditional IT systems. A blockchain node is a computer that processes transactions, builds and validates blocks, and stores a copy of the blockchain in memory. The blockchain’s peer-to-peer network operates on top of a corporate network or the public Internet.

Since blockchain technology runs on top of traditional IT systems, many traditional IT security risks and best practices apply for blockchain security. Some of the overlaps between IT and blockchain security include the following:

• Node Security: The blockchain runs on nodes, which are traditional computers. Malware, data exfiltration, Denial of Service (DoS) attacks, and other threats to traditional IT computer systems also apply to blockchain nodes.
• Network Security: The blockchain’s peer-to-peer network runs over traditional IT networks. Distributed DoS (DDoS) attacks against blockchain nodes, border gateway protocol (BGP) hijacking, and other network-level threats can impact the performance and security of a blockchain-based system.
• Application Security: Blockchain systems are implemented as software that runs on a distributed network of blockchain nodes. This blockchain software may contain exploitable vulnerabilities or be vulnerable to DoS attacks that restrict access to CPU, memory, or network connections.
• Web Security: Many DeFi projects have their backends hosted as smart contracts on the blockchain but interact with users via traditional websites. Cross-site scripting (XSS), injection, and other web security threats are common attack vectors for these Web2 frontends.

Blockchain’s reliance on traditional IT systems means that many IT security threats and best practices still apply. If the computers, networks, and websites that make blockchain-based projects operate are attacked, this impacts the blockchain security as well.

However, the blockchain infrastructure stack does not end at the application level. Blockchain software creates a new ecosystem on top of IT nodes and networks that includes:

• Consensus algorithms
• Smart contract platforms
• Layer 2 protocols
• Cross-chain bridges

Traditional IT security controls and best practices only go so far toward securing blockchain platforms. Blockchain accounts, smart contracts, and applications (DeFi, NFTs, etc.) need blockchain security controls and best practices designed for them as well.

Blockchain Security vs. IT Security

Blockchain ecosystems and traditional IT environments are very different. As a result, many of the security challenges and best practices differ significantly between IT Security and Blockchain Security. Here are some of the main ways in which blockchain security and IT security diverge for node operators.

Perimeter Security

Historically, IT security has primarily been focused on perimeter security. Based on the assumption that most threats originate from outside of the network, organizations deploy security solutions such as firewalls, intrusion prevention systems (IPS), and other tools at the boundary of the corporate network. By blocking potential threats at the network perimeter, they reduce the probability and costs of a security incident.

While the perimeter is dissolving in corporate IT with the growth of the cloud, it never existed in blockchain technology in the first place. Most blockchains are public blockchains that anyone can join and participate in. Transaction processing and storage are distributed, and anyone can operate a blockchain node. As a result, many of the traditional IT security solutions and controls used to protect the corporate network perimeter do not apply in the blockchain space.

Vulnerability and Patch Management

All software can have bugs, and some of these bugs are exploitable vulnerabilities.  The blockchain implements multiple different layers of software (the blockchain software, smart contracts, cross-chain bridges, etc.), creating multiple opportunities for vulnerabilities.

In traditional IT, vulnerability management processes are often centralized and well-defined.  After a vulnerability has been reported to a software manufacturer, the company develops and releases a patch for the issue.  While some patches may be applied manually, other updates are automatically pushed to the manufacturer’s software.

In the blockchain space, node operators can run any software that does its job and complies with the current version of the blockchain protocol.  As a result, blockchain networks can be composed of multiple blockchain software with operators running varying versions of each.

The heterogeneity and decentralization of blockchain networks make vulnerability and patch management more complex than for traditional IT systems.  The responsibility lies with node operators to identify if a patch is needed and available, and no central authority has the ability to compel operators to patch their systems.  As a result, unless an update includes a hard fork that breaks backward compatibility, nodes may continue to run versions of the blockchain software that place themselves and the health of the blockchain network at risk.

Identity Management

Identity and access management (IAM) is a complex process in traditional IT systems. Some of the main challenges of IAM in traditional IT include the following:

• Verifying User Identities: User authentication is essential to effective access control. Many organizations are turning to multi-factor authentication (MFA) and password authentication to ensure that users are who they claim to be.
• Managing Access: After the identity of an employee, customer, or other user is validated, they are granted limited access based on their role. Implementing effective access management is the goal of the zero-trust security movement.
• Digital Signature Validation: Digital signatures are commonly used to validate the integrity and authenticity of data and to authenticate users. Companies commonly implement public key infrastructure (PKI) to create, distribute, and validate digital certificates to support the use of digital signatures.

In the blockchain space, identity and access management operates very differently from traditional IT. Some of the main differences include the following:

• User Identity Verification: Most public blockchains are designed to provide anonymity to users. Instead, identity management is based on blockchain accounts. If someone has access to the private key associated with a blockchain account, they can generate digital signatures and transactions on its behalf.
• Access Management: Most public blockchains are permissionless, allowing anyone to participate in the blockchain, creating transactions and operating nodes. Access management is primarily performed at the smart contract level with these applications limiting access to privileged functionality. Private blockchains may be either permissionless or permissioned, allowing an organization to implement traditional security controls.
• Digital Signature Management: In traditional IT, validating the authenticity of a public key is one of the largest challenges of digital signature management and PKI. On the blockchain, blockchain addresses are derived from public keys, making it easy to determine if a digital signature is valid for a particular blockchain account.

Traditional IAM solutions may be necessary for managing the nodes that host a private blockchain. However, for most public blockchains, identity is managed at the blockchain account level, and access controls must be implemented in the blockchain software or smart contract code itself.

Data Security

Data security is a primary concern for traditional IT security. Companies have a responsibility to protect sensitive customer data from unauthorized access and exposure, especially if it is protected by data privacy laws. Additionally, companies have intellectual property and other internal data that must be kept secret to protect competitive advantage.

On most blockchains, all data is public. Transactions added to the distributed ledger are broadcast to all blockchain nodes, making it impossible to delete or redact data after the fact. The contents of the blockchain’s distributed ledger are publicly visible and searchable on multiple block explorers.

Data security on the blockchain boils down to not posting sensitive data on the blockchain. Unless an organization is using a private, permissioned blockchain, anything added to the digital ledger should be considered publicly visible. Data classification and blockchain security controls must be performed before data is included in a transaction and posted to the ledger.

Monitoring and Visibility

Security visibility and monitoring are essential to an effective threat management program. Security personnel can’t manage or respond to vulnerabilities and threats that they do not use exist.

In traditional IT environments, security personnel often struggle to maintain effective visibility. They are responsible for monitoring and managing numerous, diverse environments and security solutions that are often not designed to work together. Security information and event management (SIEM) solutions can help with this, but they can be difficult to configure and manage.

Visibility is one of the few areas where blockchain environments may be easier to manage than traditional IT ones. On the blockchain, everything is publicly visible, and transactions stored on the ledger — which constitutes the audit log of all actions performed on the blockchain — are often searchable on block explorers. Blockchain data can also be integrated into SIEM solutions to converge visibility across traditional IT and blockchain environments.

However, blockchain nodes also often send out less telemetry than traditional IT solutions.  As a result, the data that is available to a node operator may be insufficient to diagnose an issue or determine if an attack has taken place.

Designing Blockchain Security

Blockchain environments differ significantly from traditional IT systems. While they are dependent on the functionality of computers and networks, they built a complex ecosystem on top of them.

Within these blockchain environments, traditional IT security tools and best practices do not always apply. This article focused on how the blockchain security differs from that of traditional IT systems.  Keep an eye out for the other articles in this blockchain security series, which will explore the security differences for smart contract developers and blockchain users.

Cryptosec is a leading provider of blockchain security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post How Blockchain Security Differs From Traditional Cybersecurity – 1 – Node Operators appeared first on Cryptosec.

A blockchain is a complex, multi-layered system.  Bitcoin, the original blockchain, maintained a distributed and decentralized digital ledger on top of a peer-to-peer network.  Later blockchains, like Ethereum, added complexity by integrating smart contract functionality and the technology needed to support these programs that run on top of the blockchain.

In addition to these various blockchain layers, there is now the concept of Layer 0, 1, and 2 blockchain solutions.  Each of these “blockchain layers” is intended to describe a particular function that has been added to or abstracted from the blockchain.

Blockchain Layers – In the Beginning, There Was Only Layer 1

When Bitcoin — and many other blockchain platforms — was created, there was no concept of Layer 0 or Layer 2 solutions.  Bitcoin, Ethereum, and similar blockchains are examples of what would today be called a Layer 1 blockchain.

Layer 1 blockchains are standalone solutions designed to maintain a distributed and decentralized digital ledger and potentially support smart contracts.  To varying degrees, blockchains are based on the design of Bitcoin.  Blockchains use a peer-to-peer network to communicate, organize transactions into blocks, use a consensus algorithm to achieve agreement on the contents of a particular block, and “chain” blocks together by including the hash of the previous block in the header of the next.  The details of the various blockchains can differ significantly, but they all clearly have a common ancestor.

Blockchain Layers – Layer 2 Solutions Address Layer 1 Limitations

The leading blockchain platforms, such as Bitcoin and Ethereum, are good at their jobs.  However, they are far from perfect solutions and have their limitations.  For example, Bitcoin has significant energy consumption and a slow block rate.  Ethereum, in its current form, has a low transaction bandwidth that can lead to the blockchain being overwhelmed.

Layer 2 blockchain solutions are designed to address some of the limitations of blockchain platforms without replacing these platforms entirely.  Instead, Layer 2 blockchain solutions perform off-chain activities that are then recorded on-chain.  Two common examples of Layer 2 blockchain solutions are state channels and sidechains.

State Channels

A state channel is established via an on-chain transaction that funds the channel with cryptocurrency from one or both participants.  After the channel is established, the participants can perform off-chain transactions by changing the balance of the allocated assets in the channel.  The channel can be closed by either participant with an on-chain transaction that records the current balance of cryptocurrency in the channel and releases the locked cryptocurrency accordingly.

State channels provide the ability to make instantaneous transactions with near-infinite scalability.  Since only the opening and closing transactions are recorded on-chain, there is no need to wait for intermediate transactions to be recorded in blocks, and the blockchain is not bloated with these transactions.  State channels also enable indirect transactions by allowing value transfers between multiple point-to-point state channels.

Sidechains

A blockchain like Bitcoin has the benefit of being well-established with strong security.  However, it lacks support for smart contracts, has a relatively slow block rate, and has other limitations.

Sidechains address these limitations by linking a blockchain like Bitcoin to another blockchain (called a sidechain).  This is commonly accomplished using bridges like Binance Bridge, cBridge, or AnySwap.  To transfer assets between chains, a user sends them to a particular address on one chain, and, after the transaction is approved, the corresponding assets are unlocked on the other chain.

Sidechains offer the potential to dramatically increase the scalability of a blockchain system by allowing transactions to be recorded on another chain.  It also interconnects the ecosystem of blockchains, allowing blockchain users to take advantage of the various benefits of different blockchains by transferring their assets between them using blockchain bridges.  For example, a user may store assets on Bitcoin for greater security but transfer them to other chains to use smart contracts deployed on those blockchains.

Blockchain Layers – Layer 0 Increases Blockchain Interoperability

Blockchains like Bitcoin, Ethereum, and many others were built largely independently of one another.  While modern blockchains are all based on the design of Bitcoin, the implementation details vary dramatically.  Also, many blockchains introduce new functionality or new takes on existing functions, such as the introduction of smart contract support in Ethereum or the creation of new consensus algorithms such as Proof of Stake.

The problem with the creation of completely independent blockchain systems is interoperability.  In the beginning, all smart contract platforms wanted to be “Ethereum killers”.  Now, Ethereum’s longevity and market share have made interoperability the major goal.  Other smart contract platforms are linking via Layer 2 solutions as well as attempting to develop support for the Ethereum Virtual Machine (EVM) to enable smart contracts developed for Ethereum to run on other platforms and vice versa.

Layer 0 blockchain platforms are intended to make it easier to build and integrate blockchains by providing the building blocks needed to do so.  Layer 0 protocols like Cosmos and Polkadot provide tools for developing Layer 1 blockchains and enable integration and communication between various blockchains within their ecosystems.  For example, blockchains built within the Polkadot Ecosystems (called parachains) can communicate internally via the Polkadot Relay Chain or use the Layer 2 protocol’s bridges to connect to non-Polkadot blockchains (such as Bitcoin or Ethereum).

Introduction to Blockchain Layers 0, 1, and 2 Blockchain Security

The introduction of Blockchain Layers 0 and 2 concepts to the blockchain ecosystem increases the complexity of discussing blockchain security.  For example, blockchains like Bitcoin and Ethereum have no Layer 0; all of the functionality of the blockchain is implemented at Layer 1.  In contrast, blockchains built on Polkadot or Cosmos have split core functionality between blockchain layers 0 and 1.

Regardless of whether a blockchain is implemented independently (like Bitcoin) or via a Layer 0 protocol, certain security risks exist, including:

• Cryptography: Blockchain security is heavily dependent on the security of hash functions and digital signatures.  If a blockchain uses an insecure hash or digital signature algorithm or the algorithm that it uses is broken in the future, then the security of the entire blockchain ecosystem falls apart.
• Consensus: Blockchain consensus algorithms are designed to ensure that all nodes in the blockchain network agree on the current state of the digital ledger while protecting against cheating.  The relative security of different blockchain consensus algorithms (such as Proof of Work vs. Proof of Stake) is hotly debated.
• Node Security: Blockchains are implemented as software running on a computer.  If the blockchain software contains vulnerabilities or the host node is infected with malware, then these security risks can affect both the node and the blockchain network as a whole.
• Network Security: Blockchain nodes communicate over a peer-to-peer network that is sparsely connected.  If an attacker can intercept or block communications between nodes, they can perform a Denial of Service (DoS) attack on the blockchain or threaten consensus security.
• Smart Contract Security: Many modern blockchains are designed to support the execution of Turing-complete programs on top of the blockchain (i.e. smart contracts).  These smart contracts could have design errors or implementation flaws that place them and their users at risk.  Most cyberattacks against the blockchain occur at the smart contract level.

Many of these security risks could be considered as Layer 1 security risks since they exist in independent blockchains like Bitcoin and Ethereum as well as blockchains created using Layer 0 protocols.  However, the introduction of Layer 0 and Layer 2 protocols can create additional threats to blockchain security across all blockchain layers.

Layer 0 Security

Layer 0 protocols are designed to abstract away the details of implementing a blockchain by exposing pre-built modules to a blockchain developer.  They also provide the ability to communicate with other blockchains within the Layer 0 ecosystem.

By using a Layer 0 protocol, blockchains accept certain security risks, such as:

• Centralization: Blockchains implemented using Cosmos, Polkadot, or other Layer 0 protocols all depend on shared modules, infrastructure, etc.  This centralizes significant power in the hands of the team behind the Layer 0 protocols, creating the potential for supply chain attacks, targeting by cyber threat actors, or internal abuse of this power.
• Vulnerable Code: With a Layer 0 platform, many blockchains may be implemented using the same modules.  If these modules contain design errors, implementation flaws, or exploitable vulnerabilities, they can affect multiple different blockchains.  For example, an error in CosmWasm’s implementation of the Bech32 specification impacted the security of smart contracts hosted on 20+ blockchains.
• Complexity: Layer 0 protocols are designed to create a complex ecosystem of interoperable blockchains.  This makes security analysis more difficult and creates the potential for attacks that take advantage of undesirable and unintentional interactions between the various blockchains within the Layer 0 ecosystem.
• Ease of Use: Layer 0 platforms make it possible to implement a blockchain with much less knowledge and understanding of the technology than is required to write one from scratch.  This is good for expanding access to blockchain technology and encourages the use of well-tested, more secure modules rather than custom code.  However, it also creates the potential that blockchain code will be cobbled together without a full understanding of how it actually works, resulting in code that insecure, inefficient, or otherwise less functional.

Layer 2 Security

Layer 2 protocols such as state channels and sidechains are designed to improve the scalability, throughput, and other aspects of a blockchain.  However, they can also introduce security risks.

Some of the security risks associated with state channels include:

• Off-Chain Transactions: The transactions performed between the parties in a state channel are not recorded on the blockchain’s digital ledger.  This means that they are only indirectly protected by blockchain immutability.
• Denial of Service Attacks: A transaction can only be made between two parties if there is a path between them via state channels that have enough capacity for the transfer.  An attacker that refuses transactions or sufficiently unbalances state channels could render a transaction impossible.
• Blocked Disputes: When a state channel is closed by a single party, the other has the opportunity to dispute the final state of the channel.  A DoS attack against that account could prevent a dispute transaction from being registed within the dispute window, allowing theft of some of the value stored within the channel.

Sidechains, implemented using blockchain bridges, can also create security risks, such as:

• Centralization: Often, a blockchain bridge is implemented and managed by a small number of parties that approve transactions between chains.  This centralization can be exploited by an attacker.  For example, the Ronin Network was the victim of the largest hack in DeFi history to date due to an attacker compromising 5 of the bridge’s 9 validating nodes and using this power to approve fake transactions.
• Cross-Bridge Effects: Blockchain bridges enable integration of multiple different blockchains, which can amplify the effects of an attack.  For example, Hundred Finance lost $3.3 million when an attack on the Meter.io blockchain bridge locally depreciated BNB.bsc on Binance Smart Chain. Attackers acquired the tokens at a low price and use them as collateral for loans with Hundred Finance — which used the higher global Chainlink price — to extract more valuable assets.
• Bridge-Focused Exploits: Bridges must be properly integrated into multiple blockchains to correctly read deposits on one blockchain and release funds on another.  If an attacker can trick a bridge into accepting a fake deposit, they can drain value from the bridge contract.  This occurred in the Wormhole hack where the attacker created a transaction that exploited a flaw in signature validation by the bridge to drain $326 million from the bridge with a fake deposit.

Taking a Holistic Approach to Blockchain Layers Security

Often, security audits of blockchain systems focus on the smart contract level where many attacks against the blockchain occur.  However, the various levels of the blockchain ecosystem can impact the security of smart contracts running on a platform or the blockchain as a whole.  For example, Layer 2 exploits against blockchain bridges commonly have an impact on DeFi protocols due to their effects on the value of tokens on different blockchains.

Securing the blockchain requires considering all blockchain layers and their security.  This includes taking into account the effects that Layer 0 and Layer 2 protocols can have on the security of a blockchain system.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Introduction to Blockchain Layers 0, 1, and 2 Security appeared first on Cryptosec.

One of the main shortcomings of most DevOps programs is that they overlook security, focusing on getting software released as quickly as possible.  As a result, tens of thousands of vulnerabilities reach production each year, putting customers at risk.  Additionally, fixing vulnerabilities in production is costlier than in the development and steals resources away from developing new software.

With the rise of smart contracts and decentralized finance (DeFi), software development is increasingly moving to the blockchain.  However, traditional development practices – with security treated as an afterthought – do not work for blockchain environments.  Blockchain developers must adopt DevSecOps practices and tools to ensure the usability and security of their projects.

Blockchain Development is Different From Traditional Development and Requires DevSecOps

Vulnerability management and secure coding are important for both traditional and blockchain development.  In both cases, vulnerable code exploited by an attacker can have a dramatic impact on a company and its customers.

However, the environments where traditional software and smart contracts operate are very different.  Traditional software is designed to run on a computer, while smart contracts run on top of the blockchain.  The differences between these two ecosystems create significant challenges for smart contract developers and amplify the potential impacts of attacks against software hosted on the blockchain.

Why DevSecOps – The Blockchain Ecosystem is Fragmented

For traditional software development, there are only a few environments that software developers work in.  Computer operating systems are largely broken up into Windows and *nix (Linux, Mac, etc.).  While differences exist between Windows versions or Linux flavors, the overall consolidation of the ecosystem makes it easier for developers to understand how a platform works and how to write secure, effective code for it.

The blockchain ecosystem is much more fragmented.  Smart contract platforms are still in their early stages of development with new contenders trying to unseat more established platforms, such as Ethereum.  As a result, there are many more smart contract platforms than there are types of OSes.

Most smart contract platforms use their own virtual machines (VMs) to run smart contracts.  Some of these are developed in-house, while others use existing systems (such as the Java Virtual Machine).  Each VM has its own quirks and idiosyncrasies, making it more difficult for developers to create functional and secure code that runs in different smart contract environments.

Why DevSecOps – Blockchain is Relatively New

Modern digital computers have been around since the 1940s, and the concept originated over a century before.  Since then, computer usage and the development of computer programs have grown rapidly and dramatically.  Despite this, vulnerabilities are still common, and the same programming errors appear again and again.

Compared to computers, smart contract platforms are relative newborns.  Ethereum, the oldest smart contract platform, launched in July 2016, and its competitors are even younger.  This means that developers lack the same level of experience with smart contract programming languages and virtual machines that they have with more established languages and environments.  Smart contract programming is riskier because many developers lack the experience to do it properly, and the environments themselves lack the maturity and level of security testing of traditional computers.

Why DevSecOps – Everything is “Open Source”

Exploiting vulnerable software is always easier with access to the source code.  With the ability to read the code, a potential attacker can use static code analysis tools and more easily understand the intended function and flow of code and where vulnerabilities may exist.  For this and other reasons, many organizations do not publish their source code.

On the blockchain, all smart contract code is essentially open-source.  Many blockchain projects publish their source code, and decompilers exist for those that do not.  While decompiled code is not as readable as the original, it is good enough for most attackers’ purposes.

The open-source ecosystem of the blockchain makes it far easier for potential attackers.  The ability to read the source code and understand the developers’ logic (and the potential flaws it contains) makes smart contract exploitation easier in general than with traditional, closed source code.

Why DevSecOps – Software Updates Aren’t Easy

Traditional software development processes are heavily dependent on the ability to update the software when needed.  The many vulnerabilities that reach production can be easily addressed by sending out an update with better, more secure code.  This upgradeability is the foundation of agile development as well because it allows the software to be built and deployed in segments.

On the blockchain, software updates, while possible, are not as easy to perform.  The blockchain is designed to maintain an immutable digital ledger, meaning that any transactions performed on the blockchain cannot be changed after they have been added into a block that is validated and accepted by the network.

Smart contract code is deployed as a blockchain transaction and stored on the immutable digital ledger.  If vulnerable code is pushed to the blockchain, it cannot be easily overwritten with better, more secure code as is possible for traditional software.  While smart contracts can (and should) be written to allow updates, this must be an intentional feature of the design and implementation and is not supported by default.

Why DevSecOps – Exploitation is Easy

It’s a cliche that a criminal needs means, motive, and opportunity.  For smart contract exploitation, the means is a vulnerability and the motive is the fact that many smart contracts (especially in the DeFi space) store massive amounts of value.  Smart contract hackers have plenty of motivation and weak development practices provide the means needed to exploit them.

The design of the blockchain also provides ample opportunity for an attacker to exploit smart contracts.  Most major blockchains are designed to be open, permissionless platforms, meaning that anyone can create an account and perform transactions on them.  While a particular smart contract may require privileged access to certain functions or data, most smart contracts are designed to have functions that are publicly accessible.

This means that smart contract attackers can easily gain the access needed to exploit a vulnerable smart contract.  The blockchain makes it easy to create an account and send transactions to vulnerable software running on top of it.  Additionally, the pseudo-anonymity of the blockchain also makes smart contract exploitation relatively low-risk because it is extremely difficult to attribute a particular account and the attacks performed by it to its real owner.

Why DevSecOps – Attacks Are Not Easily Reversible

In traditional IT, many of the biggest types of cyberattacks are reversible given the right resources.  An attack by ransomware or wiper malware can be fixed by restoring any encrypted or deleted data from backups.  Financial fraud can sometimes be reversed if a financial institution is contacted in time.  An infected computer can always be restored to operation by reinstalling its operating system.

The blockchain, on the other hand, is designed to implement an immutable digital ledger.  Once a transaction is performed on the blockchain, it is relatively permanent.  This means that, except in very rare cases (such as the Ethereum DAO hack), a successful attack is not reversible.

This fact dramatically raises the stakes of smart contract security.  Without the ability to undo a successful hack, smart contract developers need to ensure that the hack cannot happen in the first place, which requires strong code security.

Blockchain Development Requires Strong DevSecOps Practices

Traditional development practices often focus on time to release instead of security.  This is also true of many blockchain projects as developers try to release new projects as quickly as possible to beat the competition or take advantage of the hype.

Integration of security into the development process or “DevSecOps” is vital for traditional development.  The massive and growing number of vulnerabilities discovered in production software each year is unsustainable and places customers at risk.

However, strong DevSecOps is arguably even more important for blockchain projects due to the unique nature of the blockchain ecosystem.  Many smart contract-based projects are high-profile and valuable, making them tempting targets for attackers.  At the same time, it is more difficult to write secure code and to fix any issues that are discovered after a project is released to the blockchain.  Additionally, smart contract hackers have significant advantages because they can often read a project’s source code, they can easily gain the access needed to perform their attacks, and a successful attack is not easily reversed.

Managing the threat of insecure code on the blockchain requires developers to embrace the DevSecOps movement and update their development pipelines to better integrate security.  Tools exist for detecting vulnerabilities in smart contract code, and many of these can be integrated into automated development pipelines.  By taking advantage of these solutions and auditing all code before launching it on the blockchain, smart contract developers can minimize the threat that vulnerable code poses to them and their users.

This article is the first in a series on improving smart contract security.  Keep an eye out for future articles on smart contract security auditing tools, security best practices, and other key aspects of smart contract security.

Cryptosec is a leading provider of security solutions in the rapidly evolving world of blockchain, cryptocurrency, DeFi. Their specialist investigations arm, Crypto Investigators, offers expert services in blockchain forensics and legal investigations, leveraging deep industry knowledge and advanced investigative techniques to navigate the complexities of the digital age.

The post Why DevSecOps is Essential for the Secure Blockchain Ecosystem appeared first on Cryptosec.