AppliedProcesses

Risk Treatments for Cosmos Hub / Tendermint Validator Risks

In a previous post we covered the risk assessment of Cosmos Hub / Tendermint Validators. That opens the question of what should be done to address those risks. When performing risk treatment, you have four general approaches:

  1. Risk reduction: Controls are put in place that reduce the likelihood of the risk occurring, or the impact of it if it does. For example, a firewall reduces the likelihood of a network attack by reducing the number of network services that are exposed.
  2. Risk avoidance: A given function is not performed such that no risks may arise from it. For example, you may elect not to provide a web interface to your cryptocurrency wallet because it would cost too much to secure it for what convenience that feature would provide.
  3. Risk transfer: Make the risk someone else’s problem — typically done using insurance products or outsourcing functions. For example, you buy insurance to cover any losses that occur from a fire.
  4. Risk acceptance: Proceed anyway with the understanding that the risk may occur and that it will be dealt with at such time. For example, you may accept that an informational kiosk could be compromised and that you will just wipe-and-reload if and when that happens. This also includes self-insuring to cover losses when they occur.

In practice, most risks are dealt with using some combination of these four approaches. For example, the a fore mentioned firewall won’t protect you from 100% of network attacks, so you may choose to accept the remaining risk.

In the remainder of this post we will review assumptions, baseline controls, then go through each of the risks raised in the risk assessment and recommend treatments for each of them. The risks will be covered starting with the set of highest risks and proceeding in decreasing fashion. For risk reduction, we use NIST 800-53r4 as a general guide, but do not stick to it absolutely when we believe controls are missing or could be better stated. The NIST controls are referenced throughout in square brackets. One should note that we do not simply follow any of the 800-53 high, medium, or low baselines; and instead we tailor the controls for what is needed for validator operators. One will also note that we distill the controls down greatly: we distilled over 240 controls down to 44 controls (plus a few new ones) — this hopefully makes the task of implementing those controls seem more tractable.

Forward / License

BuboWerks has prepared this risk treatment for validator operators in the course of offering our services such as security controls implementation and validator assessment. We welcome the community sharing it and creating derivative works (such as translations) for non-commercial purposes. That is to say, if you’re a validator operator, please use it as you see fit! If you are producing any derivative works such as security assessments based on this document, please contact us to license the material. Cosmos is a global community and we understand that many operators will be better served by localized security expertise.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Assumptions

This is designed to be a generic risk treatment approach for validators. As such, we had to make some assumptions about what the organization running the validator looks like. To that end:

  • The organization is small — say under a dozen people — where everyone knows everyone.
  • Turnover is low.
  • The owners are active in the operations of the organization; as such, all mention to policies and rules must be binding on them as well through partnership agreements, operating agreements, or other similar instruments.
  • Outside contractors or consultants are essentially treated as employees from a vetting and trust standpoint.
  • The organization is primarily focused on running a Tendermint / Cosmos Hub validator, or they are operating it and its infrastructure completely separate from other systems the organization operates.
  • The organization is not developing any custom software.

To the extent these assumptions do not hold for an organization, the controls should be reviewed accordingly.

Baseline Controls

There are some controls that help mitigate most or all risks. Rather than repeat them dozens of times, we will capture them here:

  • Security Awareness Training: Users (privileged and otherwise) are the first line of defense against most threats, so all users should receive security awareness training [AT-2]. That training should be appropriate for the user’s role [AT-3], particularly providing appropriate education for privileged users to identify when anomalous behaviour may be indicative of a compromise [AT-3(4)]. Training should be required for all by policy [AT-1] and tracked for currency [AT-4].
  • Auditing: Keeping a record of what happened on systems when is critical to both detecting when a risk has been realized as well as investigating how it occurred [AU-2, AU-12]; this should include policy [AU-1], updates [AU-2(3)], content [AU-3], response [AU-5], process, storage [AU-4], central collection [AU-6(4), AU-9(2)] and review [AU-6, AU-6(1)], integrated with vulnerability data [AU-6(5)], retention [AU-11], authoritative timestamps [AU-8, AU-8(1), AU-12(1)], and cryptographic protection [AU-9, AU-9(3)].
  • Security Assessment: An organization needs to know its security posture to best protect itself. Doing so includes a policy [CA-1], independent specialized assessments [CA-2, CA-2(1), CA-2(2)] (such as those provided by BuboWerks), continuous monitoring of that posture [CA-7], and independent penetration testing [CA-8, CA-8(1)].
  • Configuration Management: A lot of security comes from good engineering practices; a key example of that is the benefits of a carefully managed environment. This is much more easily accomplished these days through the use of tools like Ansible, Puppet, and Chef for automated baseline configuration [CM-2, CM-2(2), CM-6] with development and test environments [CM-2(6)], automated change control [CM-3, CM-3(2), CM-6(2)] with tests [CM-3(3), CM-6(1)] and access control [CM-5].
  • Contingency Plan: Things will go wrong. One should be prepared for this — in general — by always having backups [CP-9] that are tested [CP-9(1)], and ready to be used as part of procedures to rebuild systems [CP-10].
  • User Identification and Authorization: A lot of IDentity and Access Management (IDAM) is unnecessary for small organizations, but they should still have unique accounts for every user [IA-2], use a dedicated gateway for remote access [IA-2(11)], establish strength requirements for authenticators such as passwords [IA-5, IA-5(1)], change all default passwords [IA-5(5)], not embed cleartext authenticators in code or configurations [IA-5(7)], use multi-factor authentication with a token (hard or soft) when appropriate (such as remote access and key systems) [IA-5(11)], and not reveal information when authentication fails [IA-6].
  • Incident Response: An incident occurs when one of your risks is realized; some people focus on incidents as successful attacks, but really anything that harms your organization is an incident: you need to be ready for it. That means having a policy, procedure, and plans [IR-1, IR-8] including how incidents are handled [IR-4]; when to execute Continuity of Operations plans [IR-4(3)]; training [IR-2]; testing [IR-3]; monitoring for incidents [IR-5 — overlaps with AU-6]; and internal reporting [IR-6]. Smaller organizations, such as many validator operators, should give serious thought to keeping an external incident response team on retainer.
  • Physical and Environmental Protection: Hardware lives in the real world, and is susceptible to real world threats like theft, fires, and flooding. As such, every organization should have a physical and environmental protection policy and procedure [PE-1] covering who is authorized to physically access the hardware [PE-2], limiting access by people with no need to physically access the equipment [PE-2(3)], physical access controls like door locks [PE-3], monitoring of the physical facility [PE-6], intrusion alarms [PE-6(1)], fire protection [PE-13], and water protection [PE-15]. To the extent that hardware is in third-party data centers, the organization should ensure that the data center offers these protections.
  • Security Plan: If you want to succeed, you need to plan, and that is as true for security as anything else. This document is a first step you can use to plan out your security [PL-2]. From here you can add your policy and procedures [PL-1], and architecture [PL-8]. We encourage you to consider environmental heterogeneity [SC-29] as part of that architecture.
  • Security Program Plan: In order for your security plan to be successful, you need someone to execute it. That should be established with a policy [PM-1] that creates a senior information security officer (many places call this a CISO, but title as you see appropriate) [PM-2], ensure they have the resources they need [PM-3], have a plan for addressing the gap between where you are and where your security plan says you want to be [PM-4], have an inventory of your assets (that goes into more depth than what we did in the risk assessment) [PM-5, RA-1, RA-2, RA-3], have a strategy for managing your risks (for which the risk assessment is a key first step) [PM-9], make contacts with other security groups (especially in the Cosmos / Tendermint, and larger blockchain community) [PM-15], and establish a capability to track threats [PM-16]. To the extent that your team may not have the expertise to carry this out internally or desire to hire a full-time person for this position, BuboWerks can help you outsource this function either directly or through one of our partners.
  • System and Communication Protection: Most of these controls are focused on addressing specific risks. From a baseline perspective, there should be a policy regarding the necessity of those controls [SC-1, SI-1], and a plan for protecting any wireless communications [SC-40, AC-18, AC-18(1)].
  • System Integrity: Some technical controls are so common that we pull them into their own omnibus control. That includes automated centralized patching [SI-2, SI-2(1), SI-2(2), SI-2(5)], automated centralized malicious code protection (commonly called anti-virus software) [SI-3, SI-3(1), SI-3(2)], SIEM [SI-4, SI-4(2), SI-4(4), SI-4(5), SI-4(16) — overlaps with IR-5 and AU-6] including correlations with Indicators of Compromise (IoCs) [SI-4(24)], and systems integrity checks covering — at a minimum — signatures on all software updates [SI-7, SI-7(15)].

High Risks

Compromise due to exploited trust link from sentry or support system

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Access Control: Access control is a very standard thing on modern systems. Any organization should easily be able to establish an access control policy [AC-1], access enforcement [AC-3], and session lock [AC-11]. For the high level of security required by validators, operators should also be performing account management [AC-2] including automated disabling of inactive accounts [AC-2(3), AC-2(4)], inactivity logouts [AC-2(5), AC-12, SC-10], prohibit shared accounts [AC-2(9)], monitor for atypical usage [AC-2(12)], dual authorization [AC-3(2)], mandatory access control through something like SELinux (particularly limiting what can be executed on the system and what particular processes can access) [AC-3(3), CM-7(2), CM-7(5), CM-11(2)], least privilege for users [AC-6, AC-6(2)] and least functionality for processes [CM-7], auditing violations [AC-6(9)], reporting last logon and any unsuccessful logons [AC-7, AC-9, AC-9(1)], prohibiting more than one remote connection to the authenticator at a time (recommend admins use a terminal multiplexer like screen or tmux over this single connection) [AC-10], requiring that remote connection come from a dedicated gateway [AC-17, AC-17(3)] over an encrypted protocol like ssh [AC-17(2)], and establishing what remote machines are allowed to connect to the dedicated gateway [AC-20].
  • Multi-factor Authentication: All logons should require at least two factors, both locally and over the network [IA-2(1), IA-2(2), IA-2(3), IA-2(4)]. These factors should be replay resistant [IA-2(8), IA-2(9)].
  • Device Authentication: Remote connections to the authenticator should come from a dedicated gateway device that mutually authenticates itself with the authenticator [IA-3, IA-3(1)].
  • Network Firewall: with established policy of what traffic is necessary to flow in and out of the various segments of the validator network including limiting access to components such as validators and sentries to only those systems and ports that must access them[AC-4, SC-7, SC-7(11), SC-7(15), SC-7(21)], limiting trusted flows to only authenticated partners [AC-4(17)], ensuring that all paths in and out of the network are covered [SC-7(3), SC-7(4)], deny traffic by default [SC-7(5)], fail in a secure state (preferably by failing over to a backup firewall with a mirror of the configuration) [SC-7(18)], and limit what information is returned on failures [SC-7(23)].
  • Host-based Firewall: in addition to the network firewall, high value systems should use an host-based firewall such as iptables to limit incoming and outgoing traffic to only that which is necessary [SC-7(12)].
  • Encrypted Transmissions: As noted in Access Control, remote access to systems should be performed using an encrypted protocol such as ssh. Such a protocol should provide both confidentiality and integrity assurances [SC-8, SC-8(1)].
  • Integrity Monitoring: beyond the software signature checks that should be performed on all systems, high-value systems should use a centralized integrity monitoring capability such as from Tripwire Enterprise, OSSEC, or AIDE) [SI-7(1), SI-7(2), SI-7(3), SI-7(6), SI-7(9)].
  • Network and Security Documentation: In order to implement controls like Network Firewalls and Vulnerability Management, you need to know what needs to be running on your network. For that you should have a policy [SA-1] that as you acquire systems and software [SA-4] those systems and software must include documentation of what network access they require [SA-4(9)] and what security best practices and controls they recommend [SA-5].

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x High = Moderate

Notes: This is probably the most likely way that a validator system would be compromised, so the use of extensive risk reduction — even when it results in inconvenience to administer the system — is called for.

Compromise due to exploited trust link from validator or support system

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Access Control covered in Compromise due to exploited trust link from sentry or support system
  • Multi-factor Authentication covered in Compromise due to exploited trust link from sentry or support system
  • Device Authentication covered in Compromise due to exploited trust link from sentry or support system
  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Encrypted Transmissions covered in Compromise due to exploited trust link from sentry or support system
  • Integrity Monitoring covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: As part of the architecture, there should be heterogeneous sentries such that if some are compromised, the others should not be. This will allow any compromised sentries to easily be taken off-line as part of the incident response, reducing the impact.

Compromise due to MitM attack

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Encrypted Transmissions covered in Compromise due to exploited trust link from sentry or support system
  • Secure DNS: DNS is easily the least secure part of modern Internet communications. By using secure DNS — where available (and frankly, adoption is seriously lagging) — one has a much higher degree of assurance that they are being directed to the intended destination and not an attacker in the middle (SC-21). While the primary intention here is for the organization to access others securely, this also necessitates a secure authoritative DNS [SC-20] such that remote access to the organization is not redirected.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: The specified controls still allow for BGP rerouting attacks, but render them ineffective for the attacker to compromise the confidentiality or integrity of the data.

Compromise due to other network vulnerability

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management: Most network compromises occur by attackers exploiting known flaws in some software running on the target network. In conjunction with patch management (covered above as a baseline control), vulnerability management is the best way to reduce this risk. Vulnerability management consists of scanning [RA-5] with a tool that receives regular updates [RA-5(1)], using both network and host-based scans (which subsequently means that access must be managed to the tool [RA-5(5)], and reviewing any information that the scans reveal about your systems [RA-5(4)].
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation: Consideration should be given to whether software (particularly admin desktops) sufficiently separates user and administrator functionality, to minimize the chances that a user could intentionally or unintentionally escalate their privileges [SC-2]. This can particularly limit the impact of phishing attacks by giving the attacker only user, not admin-level access to the target.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Moderate = Moderate

Notes: Even in a well maintained environment, things will still be missed, but the controls here greatly lowers both the changes of that and any impacts should it occur.

Compromise due to other network vulnerability over trusted link

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Interconnection Agreements: When establishing a trusted link with another validator operator, some due-diligence should be performed to ensure that they are trustworthy (one may consider their contributions to the community to this end) and hold security in a good light (such as whether they have had their security posture audited by a third-party and certified as trustworthy). In this case, the agreement may be informal (such as an exchange of emails as opposed to signed legal documents), as the important part is the due-diligence.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-High

Notes: Generally, trusted links should not call for any access to network services other than Tendermint, so the proper controls can effectively prevent this threat from occurring and isolate it to lower-impact systems (such as a sentry instead of a validator) if it does.

Compromise due to phishing / phishing hole

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Disable Mobile Code: Mobile Code such as browser-side Java, Flash, and PDF readers are commonly used in phishing attacks. Such browser plug-ins should be disabled [SC-18, SC-18(3)]. To the extent they are necessary, they should be used on dedicated machines that do not have access to other organizational network resources.
  • Spam Protection: Spam is more than just annoying — it is frequently used in phishing attacks. The organization’s email system should include centralized spam protection [SI-8, SI-8(1)] with automatic updates [SI-8(2)].
  • Credential Management: Credentials are the things like passwords that we use to access systems; when these are compromised, it allows the attacker to essentially act as us. While multi-factor authentication should be used where possible, this is not currently possible or feasible with all the various systems we need to run an operational system. Additionally, one of the factors is usually still a password. As such, organizations should have a policy regarding how credentials such as passwords are managed. This should address strength (recommend making it as long as 30 completely random letters, numbers, and symbols where ever possible) and storage in a password vault such as 1Password, LastPass (although we are leery of this one given past compromises), or KeePass. For particularly sensitive credentials, such as those associated with validator operator wallets, we recommend keeping those offline on removable media or even paper form with one copy in an onsite safe and a backup copy in an offsite safe such as a bank safe deposit box.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Moderate = Moderate

Notes: Phishing can be very sophisticated, and even savvy users can be successfully phished. The proper controls can reduce the chances of that, as well as the impact, but the remaining risk is still notable.

Compromise due to ransom / extortion / bribery

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Access Control subset of what was covered in Compromise due to exploited trust link from sentry or support system
  • Insider Threat Training: in addition to role-appropriate security awareness training, everyone should receive training on how to identify and counter insider threats [AT-2(2)]
  • Insider Incident Response: An extension of the general Incident Response plan, this should address any deviations in the plan when an insider is involved [IR-4(6)]. If one is not already employing an outside firm to handle incidents in the general case, it may be more advisable to consider in this case.
  • Media Limitations: These days half a terabyte of information can be secreted out of an organization on a piece of media the size of a thumbnail. Conversely, even the best network defenses can easily be bypassed by sticking a USB drive into a machine. As such, it is important to have a media access policy [MP-1] that specifies where and when removable media can be used and then implement technical controls to enforce it [MP-2, MP-7].
  • Rules of Behavior: Rules of Behavior may not stop someone from doing something they should not, but they are a good control against stupidity and ignorance (the “I didn’t know it was wrong” defense), and may also provide the organization with standing to bring legal action against personnel for malicious actions (we are not lawyers — we recommend discussing this point with your lawyers) [PL-4]. Such rules should include social media guidelines such that personnel do not reveal anything about the organization or themselves that could be used against them [PL-4(1)]. Rules should cover things such as appropriate notice before leaving, especially for key personnel.
  • Personnel Security: Related to the rules of behavior, there should be a personnel security policy [PS-1] that covers the designation of key positions [PS-2], personnel screening such as criminal and social media background checks [PS-3], termination procedures [PS-4], and sanctions for wrongdoing either from the perspective of security controls or otherwise [PS-8].

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The best controls here are background checks and transparency — that can greatly reduce the likelihood. Other controls help manage the impact.

Compromise due to supply chain attack

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Supply Chain Incident Coordination: In the event of a successful supply chain attack, it is likely that the upstream vendor is unaware of the issue, so it would be prudent to coordinate with them, both to expedite the investigation as well as prevent future occurrences [IR-4(10), IR-6(3)]. This is particularly true where any vulnerabilities with Tendermint are concerned.
  • Supply Chain Diversity: Just as the baseline security plan recommended heterogeneity in the architecture, heterogeneity is also beneficial in the supply chain such that if a component is compromised in transit, the organization will hopefully have similar components from other vendors that are not compromised [PL-8(2)].
  • Acquisition Protections: Some due-diligence can provide a great deal of protection against supply-chain attacks. For starters, you should have an acquisition policy [SA-1] and procedure [SA-2] that covers supply chain protection [SA-12] such as using supplier reviews [SA-12(2)] and reviewing received hardware to ensure that it has not been tampered with [SA-12(10)] and appears to be genuine [SA-19]; doing so typically requires some personnel to be specially trained [SA-19(1)].

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Moderate = Moderate

Notes: This threat is particularly difficult to control for, as any attacker that undertakes this route is going to be quite sophisticated. Nation states have dedicated teams with highly specialized training to detect tampered and counterfit parts. The obvious focus here should be on high-value hardware like hardware key modules and validator hardware and even some basic training will help admins detect issues that most would easily overlook.

Compromise due to Tendermint network vulnerability

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Supply Chain Incident Coordination covered in Compromise due to supply chain attack

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: High x Moderate = Medium-High

Notes:

  • Firewalls can limit exposure not only by limiting access between systems (such as a validator only talks to its sentries), but by limiting which parts of the Tendermint protocol (P2P versus application ports) it allows from those systems.
  • This is one of the most difficult threats to control for. Standard controls can reduce the impact should it occur, but Tendermint is still a new, untested code base, and while the Tendermint organization is putting a great amount of resources into testing the code and trying to uncover any security flaws, there is still a good chance something will be missed. This would be a good threat to buy insurance to further reduce the risk, but we are not aware of any insurers who offer such a policy.

Compromise due to Tendermint network vulnerability over trusted link

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Supply Chain Incident Coordination covered in Compromise due to supply chain attack
  • Interconnection Agreements covered in Compromise due to other network vulnerability over trusted link

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Moderate = Moderate

Notes:

  • Firewalls can limit exposure not only by limiting access between systems (such as a validator only talks to its sentries), but by limiting which parts of the Tendermint protocol (P2P versus application ports) it allows from those systems.
  • The lower exposure of trusted links once properly configured also reduces the likelihood versus the general case (above).

Compromise of any accessible assets due to extortion

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Access Control subset of what was covered in Compromise due to exploited trust link from sentry or support system
  • Insider Threat Training as covered in Compromise due to ransom / extortion / bribery
  • Insider Incident Response as covered in Compromise due to ransom / extortion / bribery
  • Rules of Behavior covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The best controls here are background checks and transparency — that can greatly reduce the likelihood. Other controls help manage the impact.

Extreme event leaves personnel unable to perform duties

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Personnel Security subset of what was covered in Compromise due to ransom / extortion / bribery
  • Cross Training: When only one person can perform a function within an organization, that is a key-person risk. The best way to address this is to ensure that there are at least two people who are capable of performing each function. This is typically accomplished by on-the-job training where the trainee shadows the trainer, then performs the activity themselves. This should be augmented by notes and documentation. It is best if the two people can split the workload on a regular basis so that the second person doesn’t forget something if the first becomes unavailable. Also be wary of assigning too many backup functions to one person such that if multiple people are unavailable, the one person is not overloaded. To the extent the two people can be in geographically separated locations the better, as any serious weather event preventing someone from working is likely having the same effect on others in the area.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: High x Low = Moderate

Notes: There is little we can do for the likelihood here, but cross training in particular can greatly reduce the impact.

Hardware Failure

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Infrastructure Redundancy: As noted in the DDoS protection control, a DNS failure can effectively cause the entire network to fail, so besides being protected against DDoS attacks, the DNS hardware should be redundant to protect against failures [SC-22].
  • Regular Maintenance: Hardware fails, but regular maintenance can extend its life and replacement before failure can prevent costly outages. The system should have a maintenance policy [MA-1] that covers performing vendor recommended maintenance [MA-2] on a regular basis [MA-6, MA-6(1)].
  • Life Cycle Management: Even with regular maintenance, hardware will still fail. The organization should determine what the expected hardware lifespan is and replace systems on a regular basis shorter than that lifespan [SI-13]. For instance, if the mean time between failure for a server is five years, it should be replaced every three or at most four years.
  • Power and Cooling: Proper power and cooling can vastly extend the life of hardware. To that end, the organization should see that the hardware has properly cabled conditioned power [PE-9], coming from two different circuits, preferably from two different mains [PE-9(1)] and that each circuit provides sufficient battery backup to keep the hardware running until the facility can provide emergency power [PE-11]. Additionally, the facility should provide an appropriate temperature and humidity for the hardware [PE-14].
  • Continuity of Operations Plan covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: This is a very big threat that can be very effiectively managed through regular maintenance and life cycle management. If reducing the likelihood is not sufficient, the continuity of operations plan will allow operations to be failed over to the backup site, greatly limiting the impact.

Loss due to compromise of the holder’s wallet

Initial likelihood x impact: High x High

Recommended primary treatment: Acceptance

Residual likelihood x impact = risk: High x High = High

Notes: Based on current knowledge, this is probably the biggest risk in operating a validator. We would like to better understand how the stake is managed by the network, but if there is indeed some sort of store of stake, its control is outside the hands of the validator operator (making this threat impossible to control). Ideally, one could buy insurance to cover their stake, but we are not aware of any company that offers such policies — given the lack of actuarial data they are unlikely to. That pretty much leaves operators to self-insure by setting aside enough to cover losses should this occur, although frankly one must question what the future of Cosmos Hub would be if this were to occur.

Network unavailable due to DDoS ransom

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • Denial of Service Protection: A DDoS plan should be in place [SC-5] with monitoring [SC-5(3)], spare capacity or ability to dynamically add capacity [SC-5(2)] and procedures to spin up that capacity as needed, preferably in an automated fashion. The DDoS plan should address severing network links when the attack is limited to those links and operations will continue over other network links. The DDoS plan should address availability of both authoritative and recursive DNS as taking down DNS will typically effectively take down the whole network [SC-22].

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes:

  • Never pay the ransom — it will stop the attack this time, but they’ll be back with more to throw at you next time.
  • Good controls and architecture (particularly the use of auto-scaling sentries) can greatly mitigate the impact of any attempted attack. Consequently, attackers are less likely to attack and focus their attention elsewhere.

Unavailable due to DDoS

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • Denial of Service Protection covered in Network unavailable due to DDoS ransom

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: Good controls and architecture (particularly the use of auto-scaling sentries) can greatly mitigate the impact of any attempted attack. Consequently, attackers are less likely to attack and focus their attention elsewhere.

Unavailable due to ransom / extortion

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Insider Threat Training as covered in Compromise due to ransom / extortion / bribery
  • Insider Incident Response as covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery
  • Key Management: As noted in the risk assessment, the validator keys are the most important  asset to a validator; as such, they are worthy of their own management policy and procedure that specifies how they should be protected [SC-12] yet kept available in the face of threats [SC-12(1)]. This policy should cover any other key cryptographic assets (such as wallets) and can extend as appropriate to other keys used in the management of the validator. The policy should cover what users and processes are allowed to access the keys, where the keys are stored, the fact they should not be stored anywhere else, particularly any shared resources [SC-4], the use of encryption in transit [SC-8, SC-8(1)] and at rest [SC-28, SC-28(1)], and when and where offline backups should be kept — preferably on encrypted media with one copy in an on-site safe and another in an off-site safe such as a bank safe deposit box. Any passwords used to protect the keys should be covered by the Credential Management policy.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The best controls here are background checks and transparency — that can greatly reduce the likelihood. Other controls help manage the impact.

Unavailable due to targeted network outage

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Denial of Service Protection covered in Network unavailable due to DDoS ransom (particularly the portion on targeting DNS)
  • Continuity of Operations Plan covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: Proper management will reduce any network hardware vulnerability, firewalls reduce the accessibility of any remaining vulnerabilities to attackers, and proper architecture ensures an alternative processing location not susceptible to the same flaw if an outage does occur.

Unstaked due to compromise of the owner’s credentials

Initial likelihood x impact: High x High

Recommended primary treatment: Reduction through controls

  • Key Management covered in Unavailable due to ransom / extortion
  • Credential Management covered in Compromise due to phishing / phishing hole

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x High = Moderate

Notes: While a high impact remains if it occurs, proper key and credential management can greatly reduce the likelihood of this occurring.

Medium-high Risks

Compromise due to infected USB device

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • Media Limitations covered in Compromise due to ransom / extortion / bribery

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: Essentially this boils down to: don’t use USB drives you don’t know the origin of, disable USB drive use on all machines other than workstations that are designated for its use and lock down those workstations (the use of an operating system such as Linux or BSD on said workstations would be advisable) — do that and the threat can be well mitigated.

Compromise for botnet due to network vulnerability

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: Be a hard enough target and opportunistic attackers will look elsewhere.

Compromise for botnet due to other network vulnerability

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Host-based Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: Be a hard enough target and opportunistic attackers will look elsewhere.

Compromise for botnet due to phishing / phishing hole

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Disable Mobile Code covered in Compromise due to phishing / phishing hole
  • Spam Protection covered in Compromise due to phishing / phishing hole
  • Credential Management covered in Compromise due to phishing / phishing hole

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: We will likely remain vulnerable to being phished, but through proper training and technical controls we can significantly reduce what is successful and additional controls greatly limit what the attacker can accomplish even when they are successful.

Compromise keys due to compromise of backup / support system

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Key Management covered in Unavailable due to ransom / extortion

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: This essentially boils down to: don’t use your regular backup system for your keys — have a separate more secure process to keep copies of them in case of emergency.

Compromise keys due to compromise of validator system

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Access Control subset of what was covered in Compromise due to exploited trust link from sentry or support system
  • Key Management covered in Unavailable due to ransom / extortion

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The two key points here are that Key Management should dictate a protection architecture for the keys that isolates them as much as possible from the validator, likely through a Hardware Key Module (HKM) that will not reveal the keys but instead only sign messages with them. The second point is that the validator should be locked down such that only authorized processes can access the HKM interface.

Death due to natural or unnatural causes

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Personnel Security subset of what was covered in Compromise due to ransom / extortion / bribery
  • Cross training covered in Extreme event leaves personnel unable to perform duties
  • Operations agreements: As we expect most validator operators to be small organizations, the loss of the sole-proprietor or a partner could put the future operations at serious risk. To protect against this, the organization should be a legal entity that will survive beyond the passing of any of the principals, and have an agreement in place such as an operations agreement, partnership agreement, articles of incorporation or similar that makes provisions for the continuity of operations even after the passing of anyone with an ownership stake.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: Perhaps more could be done on the prevention front (such as employee well-being initiatives), but these are difficult to create and run in small organizations, especially when the target audience is the ownership. Even so, through cross training and operations agreements, we can minimize the impact of such an unfortunate event.

Destruction due to sabotage

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Access Control subset of what was covered in Compromise due to exploited trust link from sentry or support system
  • Insider Threat Training as covered in Compromise due to ransom / extortion / bribery
  • Insider Incident Response as covered in Compromise due to ransom / extortion / bribery
  • Rules of Behavior covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery
  • Key Management covered in Unavailable due to ransom / extortion
  • Credential Management covered in Compromise due to phishing / phishing hole

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: Employee sabotage is almost always something you see signs for in advance. The controls here go a long way to preventing from escalating to a problem in the first place, and reducing the impact if it does.

Keys on discarded hardware

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Media Sanitization: Very sensitive data — such as validator keys — can walk right out the door on the hard drives and other media of discarded machines. As such, it is important to have a media policy [MP-1] that covers sanitization [MP-6] for media before it is discarded.
  • Local Maintenance: The system should have a maintenance policy [MA-1] that covers the requirement that all maintenance must be performed locally [MA-3(3)], otherwise all data must be appropriately sanitized before leaving the facility [MA-4].
  • Key Management covered in Unavailable due to ransom / extortion

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x High= Moderate

Notes: This raises the question for key management of what the lifespan is on keys. If they expire and are periodically renewed, that would reduce the impact as well.

Posting of hate speech or other inflammatory material

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Insider Threat Training as covered in Compromise due to ransom / extortion / bribery
  • Insider Incident Response as covered in Compromise due to ransom / extortion / bribery
  • Rules of Behavior covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery
  • Operations agreements covered in Death due to natural or unnatural causes
  • Public relations policy: This should cover how the organization operates in the public eye, including social media like Twitter, forums such as the Cosmos Forum, its own website, and email. In particular it should address how to respond to questions, comments, and feedback, as well as how any organizational shortcomings (such as security incidents) are presented.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The key controls here are the rules of behavior and operations agreements — they should spell out that these types of activities are not acceptable and what the repercussions are, especially to owners as it is easy to tell the world that a post was made by an employee, those views are not shared by the organization, and the employee has subsequently been terminated. The other controls should address what is done should this actually occur in terms of investigations and response.

Stake flip attack

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Acceptance

Notes: For many threats, when we talk about risk acceptance, we mean that we accept it could happen and will address it if and when it does. For a threat such as the stake flip attack, we would prefer to transfer the threat by insuring against it, but for lack of anyone who provides such policies we recommend that risk acceptance involves maintaining monetary reserves that can be quickly (within a matter of hours) converted into stake and used to reestablish the positioning of this validator.

Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Key Management covered in Unavailable due to ransom / extortion
  • Continuity of Operations Plan: Many businesses failed as a result of the 9/11 terrorist attacks; many also survived; the difference between those that failed and those that survived was largely related to whether or not they had a continuity of operations plan. This is a plan for what to do when things go really, really wrong. For a validator, one of the prime considerations must be what happens when the data center where the validator lives goes off-line for whatever reason, be it temporary (like a bad storm) or permanent (like a previously inactive fault line). The organization should have a policy to maintain a continuity of operations plan [CP-1, CP-2] that covers ensuring sufficient capacity [CP-2(2)], establishing what the essential functions are and how they will be carried on [CP-2(5)], an alternate processing and storage site that is not subject to the same threats as the primary site [CP-2(6), CP-6, CP-6(1), CP-7, CP-7(1)] yet accessible to personnel (keeping in mind that a major event may make travel difficult) [CP-6(3), CP-7(2)], ensuring that the backup site maintains a mirror copy of essential data such that it can be switched to with no down time [CP-9(5), CP-9(6)], coordinating with providers such as network operators to ensure traffic is rerouted as needed [CP-2(7), CP-8], ensuring there are no single points of failure (particularly from a backhoe attack) [CP-8(2)], having a backup network provider that does not share paths with the primary [CP-8(3)], ensuring that the backup site is ready to go [CP-7(4)], testing of the plan [CP-4, CP-8(5)] from failure (we recommend just pulling the power plug on the rack) [CP-4(2)] through recovery [CP-4(4)], and accounting for what should happen should the primary site be lost permanently [CP-7(6)]. Of particular interest to validators is how keys should be maintained in two physically separated locations; this ties in with Key Management — just because a site is a backup site does not relax its security requirements.
  • Site Selection: Ideally the Continuity of Operations Plan will never be needed. While some events cannot be predicted, many can. Numerous businesses were hurt by Hurricane Katrina because they chose to host their systems in inexpensive data centers in low-lying swampland protected by hundred year old levees whose days were already numbered. Select your primary and backup sites in areas that are not prone to severe storms, flooding, industrial accidents, political unrest, and so forth [PE-18(1)]. Also consider if the site will have all the resources you need for years to come: a desert can be very safe, but you may have severe resource contention for power, cooling (water), and people; you also want to have the option to easily switch network providers if need be — something that can’t happen if you’re already contracting with the only two that serve the area.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: Through the use of a couple well selected sites and a continuity of operations plan that allows operations to seamlessly and automatically fail-over between sites, this risk can be very effectively controlled.

Unavailable due to ransom / ransomware

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Access Control covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Key Management covered in Unavailable due to ransom / extortion
  • Credential Management covered in Compromise due to phishing / phishing hole

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes:

  • The key control here is actually the baseline control for good backups.
  • Never pay the ransom — it may stop the attack this time, but now that they know you’ll pay, they’ll be back and want more.
  • In general, this should be well addressed by controls that you should have in place for larger risks.

Unavailable due to targeted network outage over trusted link

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Denial of Service Protection covered in Network unavailable due to DDoS ransom (particularly the portion on targeting DNS)
  • Continuity of Operations Plan covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.
  • Interconnection Agreements covered in Compromise due to other network vulnerability over trusted link

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: This can largely be prevented by proper firewalls and architecture that prevent even trusted partners from having that sort of access to your network equipment. Beyond that, the impact can be mitigated by failing over to your backup site.

Unstaked due to ransom / extortion / bribery

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • Insider Threat Training as covered in Compromise due to ransom / extortion / bribery
  • Insider Incident Response as covered in Compromise due to ransom / extortion / bribery
  • Rules of Behavior covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: Much of the likelihood here can be mitigated through good personnel security practices such that there is little your personnel can be ransomed, extorted, or bribed over. Beyond that, just as you should have reserve funds in case of a stake flip attack, the same funds can be used here to buy additional stake if needed.

WAN unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Initial likelihood x impact: Moderate x High

Recommended primary treatment: Reduction through controls

  • Continuity of Operations Plan subset of what was covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc. (particularly the parts about network providers)
  • Site Selection covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: Just as system outages due to data center issues can be well mitigated, so can WAN issues — for starters, redundancy in WAN connections will hopefully prevent the loss of all connectivity to a data center, but even if that happens, you can just fail-over to the backup data center.

Website unavailable due to DDoS

Initial likelihood x impact: High x Moderate

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • Denial of Service Protection covered in Network unavailable due to DDoS ransom

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes:

  • Even if someone else is running the organization’s website, it should have the appropriate security controls in place.
  • In some respects DDoS protection for websites is easier because it is better understood — one can simply use one of the many DDoS protection services to front the website and protect it against attacks. Even if there is a DDoS attack its impact can be reduced.

Moderate Risks

Compromise due to phishing

Initial likelihood x impact: Low x High

Recommended primary treatment: Reduction through controls

  • User-Admin Separation covered in Compromise due to other network vulnerability
  • Disable Mobile Code covered in Compromise due to phishing / phishing hole
  • Spam Protection covered in Compromise due to phishing / phishing hole
  • Key Management covered in Unavailable due to ransom / extortion
  • Credential Management covered in Compromise due to phishing / phishing hole

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x High = Moderate

Notes:

  • This is a key example of where only three likelihood levels is rather insufficient, as the likelihood that any personnel would be tricked into sending the validator keys to someone that wasn’t supposed to have them was already fairly low (we assume a fair amount of common sense on the part of validator personnel) — the controls add technical protections to help prevent it further, hence making an already low likelihood almost negligible. That said, should it occur, the impact is still serious.
  • One might also consider a Data Loss Prevention (DLP) system here, but most do not work too well, and you would need to store your keys on it so it would know what to look for, which probably would make it the weak link to be attacked.

Compromise website to add false, misleading, or inflammatory statements due to network vulnerability

Initial likelihood x impact: Moderate x Moderate

Recommended primary treatment: Reduction through controls

  • Access Control subset of what was covered in Compromise due to exploited trust link from sentry or support system
  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Vulnerability Management covered in Compromise due to other network vulnerability
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • Credential Management covered in Compromise due to phishing / phishing hole
  • Public relations policy covered in Posting of hate speech or other inflammatory material

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: As noted above, even if the website is outsourced, it should still be secured. Given that we expect websites will largely be static using off-the-shelf software, this should be straightforward to do. Should an incident still occur, the public relations policy should cover how to address that.

Destruction due to event that destroys data center

Initial likelihood x impact: Low x High

Recommended primary treatment: Reduction through controls

  • Key Management covered in Unavailable due to ransom / extortion
  • Credential Management covered in Compromise due to phishing / phishing hole
  • Continuity of Operations Plan covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.
  • Site Selection covered in Unavailable due to data center unavailability (power, cooling, etc.) due to disaster, weather event, etc.

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes:As with other data center events, a good site selection and continuity of operations will address this very effectively.

Negative forum reviews

Initial likelihood x impact: High x Low

Recommended primary treatment: Reduction through controls

  • Public relations policy covered in Posting of hate speech or other inflammatory material

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: While a good public relations policy will primarily address the impact of negative reviews — which is already low as most people will not blindly accept what is written in reviews — by consistently presenting a positive, professional response to any reviews it should also dissuade anyone from attempting to use this approach as they see it is not effective. In short, don’t feed the trolls.

Negative forum reviews for extortion

Initial likelihood x impact: High x Low

Recommended primary treatment: Reduction through controls

  • Public relations policy covered in Posting of hate speech or other inflammatory material

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Moderate x Low = Medium-Low

Notes: As with negative reviews in general.

Tie up stake with end of operations

Initial likelihood x impact: Low x High

Recommended primary treatment: Reduction through controls

  • Rules of Behavior covered in Compromise due to ransom / extortion / bribery
  • Personnel Security covered in Compromise due to ransom / extortion / bribery
  • Operations agreements covered in Death due to natural or unnatural causes

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Moderate = Medium-Low

Notes: The controls here are mostly designed to reduce the likelihood, which was already low. Sometimes though, for various reasons, an organization must close shop. The operations agreements in particular should address how to do that in a controlled manner with sufficient notice so as to minimize the impact on all personnel and delegators.

Unavailable due to DDoS over trusted link

Initial likelihood x impact: Moderate x Moderate

Recommended primary treatment: Reduction through controls

  • Network Firewall covered in Compromise due to exploited trust link from sentry or support system
  • Network and Security Documentation covered in Compromise due to exploited trust link from sentry or support system
  • Denial of Service Protection covered in Network unavailable due to DDoS ransom
  • Interconnection Agreements covered in Compromise due to other network vulnerability over trusted link

Recommended additional treatment: Acceptance

Residual likelihood x impact = risk: Low x Low = Low

Notes: The limited bandwidth of dedicated links combined with a DDoS resistant architecture and firewalling along with due-diligence for the trusted link reduces both the likelihood and impact of this threat.

Medium-low and Low Risks

All medium-low and low risks in the risk assessment also appeared at a higher level and are covered above.

Conclusion

While Tendermint / Cosmos Validators are exciting new technology from a blockchain perspective, the threats to their operations and the subsequent risk treatments are well understood. Hopefully this document makes those risk treatments more accessible to the community. If you still need help implementing these controls, BuboWerks is here to help, just contact us and we’ll set up a call to discuss how we can help. If you think you’re in good shape and would like a third-party assessment of your controls, ask us about our fixed-price validator security assessment.

One thought on “Risk Treatments for Cosmos Hub / Tendermint Validator Risks

Leave a Reply

Your email address will not be published. Required fields are marked *