How can decentralization improve cybersecurity?
Over 200,000 victims in 150 countries have suffered through one of the largest cyberattacks in history over the last few days. With global IT systems still clearly vulnerable to assaults of this magnitude, it’s time to banish idealistic notions of how everyone will behave and confront reality: we live in a world in which some portion of actors will choose to act maliciously, and the increasing connectedness of our technological infrastructure greatly increases the potential damage such acts can wreck. In such a world, the stakes in cybersecurity are growing; and, the need to develop more secure, resilient systems intensifies in tandem.
A problem with making our systems more secure is that it is impractical to eliminate all vulnerabilities. The main reason for this is that one of the main sources of vulnerabilities is human error — such as with phishing — and we’re not going to stop all human error :). Beyond that reason, such impracticality is also supported by bugs introduced from the continued development of new or existing technologies and by the complexity of IT systems. So, bad actors will likely continue to have a set of vulnerabilities available for them to exploit to compromise systems.
A solution to this problem is to increase the number of points of failure, meaning the number of parts of a system that would have to be compromised by an attacker in order for the system to fail. The worst case is a single point of failure, such as you might have with one power cord running between a backup generator and a home (i.e if the cord is cut then the system fails). In general, more points of failure means that the system is more resilient because an attacker would have to compromise a larger number of parts of a system in order to cause it to fail.
Decentralization, such as is found in the systems underlying cryptocurrencies like Bitcoin, can greatly increase the number of points of failure. In general, decentralization — for cryptocurrencies or other applications —typically means that the number of points of failure is roughly equivalent to the number of the computers that constitute a majority or sizable portion of the network in some respect. For instance, an attacker would have to compromise a majority of the computational power within the Bitcoin network in order to effectively attack the system (which is largely infeasible); with some other cryptocurrencies, the attacker needs to compromise a majority of some other network resource such as coin ownership (again, close to practically infeasible). So, decentralization increases the number of points of failures and therefore makes systems more robust.
Given the above, in a world where malicious hackers and IT vulnerabilities will remain a persistent reality, decentralization offers a means to improve system security and resilience via increasing the number of points of failure. If we adopt technologies that use decentralization (such as BitBounce) then, in the future, we can better defend against attacks like the one that just occurred.
Quick caveat to my post in response to an objection from a friend: my analysis doesn’t apply to cases in which the vulnerability is in the decentralized system itself, such as with the DAO attack (http://www.coindesk.com/dao-attacked-code-issue-leads-60-million-ether-theft/).
My argument primarily applies to cases such as with the WanaCry attack in which a vulnerability is unevenly distributed.
Also, here’s a more concise version of the argument:
Say there’s some vulnerability v that a node either has or doesn’t have, and that nodes run services that can be h (hackable). For a centralized service, if the software running on its nodes has v then it is h. For a decentralized service, a majority of the nodes (in some respect) would have to have v in order for the service to be h. Since there is typically diversity in the software running on the nodes in a decentralized service (because of different OSs, operators, admins, etc), it’s less likely that a majority of nodes will have v and therefore the service won’t be h.