Cybersecurity

Crypto vulnerability management

Blog Images 2021 crypto tile

Decentralized finance (DeFi) AppSec demands preemptive planning for SDLC risk mitigation

In this blog series, we’ve discussed in detail how crypto assets and currencies are no longer passing fads. Even if your C-suite remains skeptical, security leaders and teams can’t afford to keep watching, waiting, and speculating about what’s going to happen or when your organization will be directly affected. The time for action has come, and it’s now your responsibility to get development and security programs attuned to decentralized architecture before crypto adoption.

Why? Because the continuous integration and deployment of products and applications on one or more blockchains makes the software development lifecycle (SDLC) far more vulnerable than it was when compared to the development of traditional non-blockchain based applications. Like it or not, a bad string of code was of less consequence back in the old days. But today, despite the perceived security of blockchain technology, bad actors are finding ways inside via exposed code and crypto vulnerabilities, and attack surfaces are expanding within decentralized financial programming environments.

As network perimeters continue to disintegrate, workloads are spinning up and down at hyperscale and on blockchains, and out to the edge of networks that we no longer have complete control over or that we even have eyes on.

Best practices for secure coding

Existing software development lifecycle best practices, such as those from SEI CERT, CVE, and OWASP among others, provide a solid base framework for secure coding. While these standards vary, each covers the required and key aspects.

As an example, OWASP secure coding practices cover the following:

  • Security by design
  • Password management
  • Access control
  • Error handling and logging
  • System configuration
  • Threat modeling
  • Cryptographic practices
  • Input validation and output encoding

Unfortunately, taking these SDLC components forward is not enough if your business is going to implement DeFi Ethereum-backed blockchain applications. A good starting point to understanding Ethereum and security within its smart contracts is to familiarize yourself with Ethereum’s security documentation.

Similar to common SDLC non-blockchain frameworks, the Smart Contract Weakness Classification and Test Cases (SWC) Registry was founded to define critical security weaknesses affecting smart contracts. This includes a comprehensive listing of 36 key risks to support developers with knowledge of known attack vectors and common protocol patterns.

Developers should also be aware of risks about implementation tokens as they relate to smart contracts. They may also gain this training about blockchain and smart contract security through one or more SANS classes.

Trust, but verify

It is critically important to use one or more security tools and/or third parties to validate the security of applications, and to make this part of your routine. These commercial and freely available tools cover DeFi application visualization, static and dynamic analysis, and test cases supporting strong quality control standards.

If your organization chose not to follow and keep up on smart contract, token, and protocol vulnerabilities of Ethereum and the medium used to generate and maintain smart contracts (commonly Solidity), prepare to be breached. Here’s a non-exhaustive listing of DeFi companies that fell prey to attacks:

The recent hack of the interoperability protocol PolyNetwork demonstrates how difficult it can be to track down a vulnerability within a smart contract. It also demonstrates the importance of effective incident response policies, procedures, and incident handling. The speed of their disclosure of the breach on Twitter as it happened, engaging relevant exchanges to “follow the money,” was a critical step. Given the transparency of blockchains, it wasn’t long before addresses were actively being tracked and blacklisted. Lucky for PolyNetwork, the remaining $141M of the $600M in crypto assets was returned. The PolyNetwork offered a bug bounty of $500K as a reward for the disclosure of the cross-chain vulnerability used in the attack. While the attacker didn’t formally accept the $500K reward, PolyNetwork transferred $500K in Ethereum to their public account. That’s a lot of potential liability that could go the wrong way next time.

Even if we think that we’ve got our own environment under control, our suppliers, vendors, partners, and customers may not. Code is exposed to more known and unknown vulnerabilities than ever before, and crypto transactions are starting to creep in around the edges. Again, this is happening whether we like it or not, or whether or not we choose to participate in crypto on any level.

Security teams need to learn the ropes of crypto transactions and blockchain tracking, and to take the preemptive steps now to protect the development lifecycle in adapting to a dynamic currency environment.

More from this blog series:
Part 1: Payments paradigm shift
Part 2: The road to secure crypto: start getting risk management priorities on your threat modeling radar