Skip to content

Vulnerability

Vulnerability Response Plan

A Vulnerability Response Plan is a process of agreed steps to take when an issue is reported with a crosschain protocol (or any other software system). The term vulnerability should be used carefully. When an issue is first reported, it should be considered a possible Security Issue. A Security Issue could be classified as a Vulnerability (also known as a Security Vulnerability) if the issue can be exploited to cause some sort of damage to the crosschain protocol.

Identify a Vulnerability Response Virtual Team

The Vulnerability Response Virtual Team is a cross functional team that will manage the vulnerability response process. The team should include domain experts such as the lead protocol designer, system architects, and lead engineer, and representatives from teams such as DevOps, SecOps, Product Management, Public Relations, and Executive Management. The team is a virtual team as it draws on team members on an as needs basis.

If the team is too large, then the probability of information about the vulnerability leaking increases. Additionally, the more people in the team, the more people who have their focus diverted from their core work. Having the team too small may mean that people who could provide useful insights are excluded. Experts could be brought into a small team on an as needs basis. However, this approach assumes that members of the team can identify the correct people to temporarily bring into the team.

Reporting Mechanism

Organizations should identify and advertise how they expect vulnerabilities to be reported. External parties such as White Hat Hackers and University Researchers (see Section Operational Security) need a mechanism communicate with the Vulnerability Response Virtual Team. This could be via a group email alias or via a web form.

People within the organization should have a defined way of reporting vulnerabilities. Using the standard bug tracking system will advertise the issue to anyone who can access the system. Additionally, the true significance of the issue may not be fully understood, and other higher priority issues may be resolved ahead of the vulnerability. Reporting to an individual such as a manager again might mean that the significance of the issue is not fully understood. Allowing the person to directly contact the Vulnerability Response Virtual Team, possibly by the same mechanism as external parties, will ensure the issue is appropriately triaged.

Once a vulnerability has been reported to the Vulnerability Response Virtual Team, someone from the team needs to take responsibility as the contact point for the person who reported the issue (from now on, the vulnerability reporter) for the duration of the vulnerability response. They need to assure the the vulnerability reporter that they are being taken seriously, and that the issue is being triaged. They should provide a realistic schedule for when they will respond to the the vulnerability reporter with the results of the triage process.

Triage

Once a possible Security Issue has been reported to the Vulnerability Response Virtual Team, the issue needs to be triaged. The team can analyze the issue against the following criteria:

  • Scope: This could be:
    • Fundamental cryptographic building block: For example, an issue found in a cryptographic algorithm such as SHA256 would affect all protocols and systems using that protocol, and their implementations in all programming languages.
    • A protocol or system: For example, an issue found in a communications protocol such as Transport Layer Security (TLS) would affect all applications that use TLS, independent of programming language.
    • Software Library: All applications and systems using a software library.
    • Crosschain Protocol: The issue just pertains to this crosschain protocol. If the protocol is implemented in a variety of programming languages, does the issue apply to all languages, or just one implementation.
  • On-chain or off-chain components: Does the issue relate to contracts that are on-chain or off-chain services?
  • Not deployed, Deployed, or Historic: Does the issue relate to code that has never been deployed, is currently deployed, or was deployed previously, but has subsequently been superseded?
  • Direct Impact: What is the direct impact of exploiting the issue? Could funds be stolen? Could a Denial of Service (DOS) be mounted against the protocol? Could private information such as customer data be stolen?
  • Reputational Impact: Could the issue cause reputational loss?

Contact the vulnerability reporter once the triage process has been completed. Discuss the findings of the process and give feedback to the the vulnerability reporter. They may highlight some misunderstandings that the Vulnerability Response Virtual Team has. If the Vulnerability Response Virtual Team feels that there is no substantive issue, it would be good if they could convince the the vulnerability reporter of this, so that they don't go public with their perception that there is a serious issue with the protocol. Assuming there is a vulnerability, the the vulnerability reporter needs to be given the planned schedule of events that will culminate in the vulnerability fix being deployed and the issue being publicly announced.

Creating, Validating, and Deploying a Fix

Once how the vulnerability will be addressed is determined, the code for the fix will need to be written, tested, and then deployed. Even if the project uses an open source repository for their main development effort, a private repository must be used for developing, testing and deploying the vulnerability fix code. The reason for this is that submitting vulnerability fix code to a public repository is tantamount to publishing the vulnerability. Even if the time between submitting the vulnerability fix code and deploying it is a matter of ten minutes, this will be long enough for an attacker who is already aware of the vulnerability. The attacker may have been preparing to mount an attack. Faced with the prospect of the vulnerability fix code being deployed soon, the attacker will launch their attack.

Prior to deploying the fix, it may be helpful to again reach out to the the vulnerability reporter to check that they too believe the fix will address the vulnerability.

Publishing a Root Cause Analysis

Immediately after the vulnerability code has been deployed, a Root Cause Analysis should be published. This should identify what the issue was, possible impacts if it had been exploited, how it was resolved, actions that users should take, any bug bounty that has been paid, and, most importantly, it should attribute finding of the vulnerability to the the vulnerability reporter. The publication of this analysis should be coordinated with the the vulnerability reporter as they may wish to publish their own press release. The details of the analysis should be checked with the the vulnerability reporter to ensure they agree with what has been said in the analysis.

Last update: October 13, 2023
Created: October 13, 2023