blog

Leveraging Interledger Functionality in Automated Responsible Disclosure of Vulnerabilities

Yki Kortesniemi & Dmitrij Lagutin, Aalto University

Security vulnerabilities have become a major risk factor for the Internet of Things (IoT): many IoT devices have been exploited with significant impact [1, 2] - and these problems are unlikely to disappear in the near future. All types of systems are susceptible to vulnerabilities, but IoT devices often face higher risks because many IoT devices are relatively simple systems, yet they are left completely unmonitored for extended periods of time. Many of the products also have only short market life-times and all compete for fast time to market, leading to an increased number of security issues. And, finally, because of the relatively low margins of many IoT devices, vendors are often disinterested in addressing the vulnerabilities in their products.

Responsible Disclosure has Problems

Vulnerabilities are often discovered by third parties, who then face the dilemma of how to notify the vendor without revealing the details of the vulnerability to the world at large and still motivating the vendor to patch the vulnerability in a timely manner. Responsible Disclosure is a model to disclose security vulnerabilities in a way that allows the vendor some time to create a patch before the vulnerability is publicly revealed. Currently, most security experts use this model to report vulnerabilities [3]. 

The idea behind the responsible disclosure is sound, but unfortunately it often does not work that well in practice:

● In many situations there are no clear and enforced time limits after which the vulnerability will be disclosed, and the vendors often request extensions to the disclosure if they are not able to provide patches in time.

● There have been several cases, where the security experts have been pressured, threatened, or even sued by vendors to not release the vulnerability within a reasonable time frame [4][5].

● Due to the lack of transparency to the details of the vulnerability, the vendor may release a patch that does not properly address the vulnerability merely to appear as security conscious.

● It is impossible for the customers and the public in general to know, how many vulnerabilities in each vendor’s products have been identified and how many of them remain unpatched. 

Now, if the vulnerabilities would be disclosed in a more strict and transparent manner, the situation would change: vendors would have stronger incentives to improve the security of their products.

Interledger provides Transparency and Privacy

Distributed Ledger Technologies (DLTs), such as blockchains, offer decentralised solutions for collaboration, interoperability and trust. One of the main features of DLTs is the immutability of data: ledgers are append-only databases where existing data cannot be modified and only new data can be added. This allows individuals, organizations, and devices that may not fully trust each other to collaborate in a safe and transparent manner.

Different types of DLTs each offer different trade-offs in terms of latency, throughput, consensus algorithm, functionality, etc., which renders them suitable for different types of applications, e.g. cryptocurrency payments, recording of IoT events, or access authorisation. It is therefore often not efficient or even feasible to use only a single DLT for everything, hence the interledger approach (which e.g. the SOFIE project is actively studying) that allows different DLTs to securely transact with each other is required in many situations [6].

Using multiple ledgers is also beneficial for privacy reasons: participants within a DLT can access all data stored in that DLT to independently verify its integrity, which encourages the participants to use private ledgers, and store only a subset (e.g. a hash) of the data to the main ledger used for collaboration with others. At a later time, when the original data is revealed, the hash in the open ledger proves that the original data has not been modified.

Automated Responsible Disclosure (ARD)

In the new Automated Responsible Disclosure (ARD) shown in Figure 1, DLTs and interledger  are used to immutably record, when a vulnerability is disclosed to authorities and vendor, and after the set time period the vulnerability is then automatically revealed to the public (regardless of whether it has been patched or not).



Figure 1: Automated Responsible Disclosure

 

The solution is designed to utilise two distributed ledgers, a private one maintained by the authority and used for storing the details of the vulnerability during the disclosure process, and a public one for first disclosing the existence of a vulnerability and later the details of the vulnerability. A key element is then the interledger functionality, which facilitates the automatic disclosure of the information from the private ledger to the public one once the conditions for disclosure have been met. The process of ARD is described in Figure 2.




Figure 2: ARD process

 

ARD provides transparency to the process by making the number of solved and unsolved vulnerabilities of each product available on the public ledger and provides clear incentives and enforced deadlines for the vendors to patch their products. If all parties act properly, ARD acts automatically and the patch and vulnerability information are made publicly available, but if any of the parties tries to cheat or otherwise act against the process, this is immediately visible on the public ledgers and the other parties can then take remedial actions. 

More details of ARD can be found in the upcoming book by Now Publishers ‘Security Risk Management for the Internet of Things - Technologies and Techniques for IoT Security, Privacy and Data Protection’.



References

[1]        L. O'Donnell. 2 Million IoT Devices Vulnerable to Complete Takeover. Threatpost, 2019. Available at: https://threatpost.com/iot-devices-vulnerable-takeover/144167/ (Accessed 27.3.2020).

[2]        D. Voolf, S. Boddy, and R. Cohen. Gafgyt Targeting Huawei and Asus Routers and Killing Off Rival IoT Botnets. F5 Labs, 2019. Available at: https://www.f5.com/labs/articles/threat-intelligence/gafgyt-targeting-huawei-and-asus-routers-and-killing-off-rival-iot-botnets (Accessed 27.3.2020).

[3]        J. Trull. Responsible Disclosure: Cyber Security Ethics. CSO Online, 2015. Available at: https://www.csoonline.com/article/2889357/responsible-disclosure-cyber-security-ethics.html (Accessed 27.3.2020).

[4]        T. Spring. The Vulnerability Disclosure Process: Still Broken. Threatpost, 2018. Available at: https://threatpost.com/the-vulnerability-disclosure-process-still-broken/137180/ (Accessed 27.3.2020).

[5]        K. Zetter. A Bizarre Twist in the Debate Over Vulnerability Disclosures. Wired, 2015. https://www.wired.com/2015/09/fireeye-enrw-injunction-bizarre-twist-in-the-debate-over-vulnerability-disclosures/ (Accessed 27.3.2020).

[6]        Chapter ‘The SOFIE Approach to Address the Security and Privacy of the IoT using Interledger Technologies’ in the upcoming book ‘Security and Privacy in Internet of Things: Challenges and Solutions’.