User needs should be at the heart of the protocol design process. Prioritising use cases and users, while also considering the protocol’s context, when making design decisions will ensure that a protocol provides functionality and security for users.
Before beginning protocol design, it is important to take a step back and consider the protocol’s context. Establishing the context of a protocol is essential to good protocol design. This means thinking not only about where the protocol will be used and what threats it will face, but also dependence on any stakeholders, who will use it and how. A big part of this is considering the unique threat model for the protocol - only once this is clearly laid out is it possible to decide whether the protocol is secure.
Protocols with different user bases or operating environments will likely have very different threat models and very different security requirements. For example, when writing protocols that will operate in high latency or constrained environments, designers will consider the importance of protecting against certain threats balanced against operational concerns. The speed needed, battery constraints and processing power requirements for protocols running on (for example) IoT devices will contrast greatly to those running in data centres. The assumption of physically secure endpoints is also often made implicitly but, for many use cases, this assumption is unwise. Different user bases will also assign conflicting priorities to different security concerns, for example absolute confidentiality of communications weighed against ease of malware detection, leading to what may be contradictory pressures on protocol designers.
Some protocols will have a variety of use cases and operate in a variety of contexts. All of these should be considered in the design process if the protocol is to be secure for all its users. It won’t always be possible to meet all of the desired use cases, in which case the design should make it clear when the protocol should and should not be used. As they become successful, it is likely protocols will be considered for a range of use cases beyond those they were designed for – this clear assessment in the design should give potential users enough information to decide if it is appropriate for their use case, or whether a new protocol is needed.
The more information that can be seen in the clear, the more privacy is lost, and the less work an attacker must do to see user data and to compromise other user data. For example, unencrypted Transmission Control Protocol (TCP) traffic can allow an attacker to read packets, whereas unencrypted Domain Name System (DNS) requests can allow an attacker present on the network to build up a picture of a user’s browsing habits. Both attacks can be mitigated by encrypting the relevant data, but they carry very different risk profiles, with severity to be judged according to the use case and threat model.
Metadata also matters. Many protocols need metadata to provide functionality (e.g. routing) and metadata is often used by trusted tools to improve security. Additionally, some protocols need metadata to discover other systems or indicate their presence to them. However, metadata can also leak information about users. If this is done gratuitously, then attackers have a head start for future attacks; at a minimum, they could begin to build a picture of a user's habits or of vulnerable software present on a particular device.
Traditionally, system designers have placed trust in a specific network, but, with movement toward 'zero-trust' architectures , this is becoming less common. It is, therefore, rarely sensible to assume that protocols operate in a wholly trusted environment. Trust is not a constant, and not all or nothing - legitimate users can become adversaries, devices can be stolen or compromised. Endpoints can also be unpatched but not exploited; malware can be cleaned-up and trust restored. These examples illustrate why network administrators cannot trust all nodes absolutely in a trusted network. Detecting a compromised node exfiltrating data (or communicating with command and control nodes) is vital to network defence.
Most protocols will operate in a constantly changing trust landscape. An endpoint could be compromised at any point, so it is important to consider how a protocol should operate if one or more endpoints are not trusted. Revocation of trust is a valuable tool in these cases, but has proven complex to implement successfully, leading to hard failures and UI warnings or even acting as an attack vector itself. Considering ease of revocation (or reduction) of trust should be key for designers.
The problem of establishing trust in an endpoint is also increasingly important. Bootstrapping trust is a hard problem, and being able to restore trust to an endpoint is vital for resilience. Allowing use of mature, proven services for identity management, key exchange and revocation, such as those provided by an operating system, is a good way to manage trust. Finding the right balance of trust is important and should take account of a range of factors, including levels of trust in the endpoints, levels of trust in the network and the impact of an undetected compromise.
A key method for detecting compromise is to detect activity linked to that compromise. This means distinguishing it from expected activity – metadata for malicious behaviour will usually look quite different to the normal activity from that device. Certain protocol artefacts, such as IP addresses or domain names linked to malware, are known as Indicators of Compromise (IoCs). These IoCs are a vital part of the cyber defence strategy for many organisations and individuals, and are easy to share, helping to limit the scale of compromise. This detection, using IoCs or otherwise, cannot take place if a protocol is designed such that distinguishing different types of traffic is impossible. A protocol can take different routes to allow detection of misuse – either a built-in ability to detect misuse or making information (such as IoCs) available to other services – but whatever solution is chosen should meet the use case and any limitations should be made explicit in the design.
There are also use cases that prioritise integrity (for example non-sensitive control messages), and in these cases, sending data over an encrypted tunnel can mean that a security device is unable to decrypt the traffic and so cannot detect misuse. However, taking an approach of providing only integrity to the messages allows security appliances to do their job without compromising the integrity required by the recipient device. Integrity is often closely linked with confidentiality, so can be difficult to do well in isolation, but an integrity-only solution should be considered if it meets the security requirements of the use case.
The value an attacker gains from knowledge of an artefact might be less than the value of an admin knowing what is traversing their network - implementing blanket encryption could prevent a defender from spotting malicious activity. There’s strong asymmetry here; large scale defensive monitoring must be very efficient while an adversary can choose to focus massive effort on a single packet. Logs are also a vital tool for defenders, and protocols should support logging that allows detection of misuse. It’s important to consider the use case and threat model when deciding what should be logged and when developing error messages.
Preventing potential data breaches, both immediately and in the future, through detecting compromise needs to be balanced against the ability of attackers to access traffic - but for many users and use cases, enabling defence will be of prime importance. Finding the right balance is important to both ensure the security of users and to protect their privacy.
Not every security problem is due to a malicious attacker, and not every threat happens purely in the digital realm. A system - comprising networks, machines and protocols - can be compromised without malicious intent, and it is important that recovery is possible in these situations. Such a compromise could be a loss of timing synchronisation, a software bug, a corrupted hard disk or even a natural disaster resulting in infrastructure outage. Ensuring data remains secure if an endpoint becomes unavailable should be an important consideration, as should the operation of endpoints when they are offline. Protocols designed with lack of availability in mind can help this recovery. Of course, a situation where all hardware conducting the protocol is destroyed cannot be fully accounted for, but the level of resilience should be determined by the use case and made explicit in design.
Another way that a protocol design can help a system to be resilient is to outline possible failure cases, and what mitigations should be taken if they occur. If an event should not happen, it may well still do so, and, if possible, a user should be equipped with a well-defined, secure mechanism with which to recover. Considering these failure states during the design process will help produce a resilient protocol that is able to recover properly, and retain security, in a range of situations.
Defence-in-depth is a cornerstone of modern cyber defence. The goal is simple; use layers of defence with several different mitigations at each layer. This approach provides multiple opportunities to detect compromises at different parts of the system, to prevent them causing further damage, and to account for different points of failure. Indicators of compromise, as discussed in 1.4, can be detected both at the network level and on endpoints, meaning they are a perfect fit for this defence-in-depth resilience.
Different use cases will place different priorities on the CIA triad of Confidentiality, Integrity, and Availability. Providing the resilience across components required when using a defence-in-depth approach means that certain information must be made available to the relevant components to allow them to perform their functions. This means that even if one or more security appliances fail, or are compromised, then defence is maintained and privacy is protected. Protocol designers should consider overall systems, and how they would apply and allow defence-in-depth, when considering how to mitigate different attacks and how to combine confidentiality, integrity, and availability.