Security Considerations for Protocol Designers
draft-lazanski-protocol-sec-design-model-t-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Dominique Lazanski | ||
| Last updated | 2020-03-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lazanski-protocol-sec-design-model-t-00
IAB Programme D. Lazanski
Internet Draft Last Press Label
Intended status: Informational March 8, 2020
Expires: September 9, 2020
Security Considerations for Protocol Designers
draft-lazanski-protocol-sec-design-model-t-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 8, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Lazanski Expires September 8, 2020 [Page 1]
Internet-Draft Security Considerations for Protocol Designers March 2020
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document is a non-exhaustive set of considerations for protocol
designers and implementers with regards to attack defence. These
considerations can be used as an aid to analyse protocol design
choice and in turn to help combat threats and defend users of these
protocols and systems against malicious attacks.
First, we list well-known classes of attacks that pose threats, with
relevant case studies and descriptions. Next, we give a list of
defence measures against these attacks to be considered when
designing and deploying protocols. Naturally, deployments of
protocols vary greatly between use cases; therefore, some attacks and
defensive measures outlined may require more consideration than
others, dependent on use case.
This RFC can be used by protocol designers to write the Security
Considerations section in an RFC. The impact on attack defence of a
protocol should be considered in multiple use cases across the
multiple layers of the internet in its this section. Defence against
malicious attacks can be improved and it can be weakened by design
features of protocols. Designers should acknowledge the role of
protocols in attack prevention, detection and mitigation; this
document aims to be a useful guide in doing so.
Table of Contents
1. Introduction...................................................3
2. Attacks........................................................4
2.1. Endpoint Compromise.......................................5
2.2. Network Compromise........................................6
2.3. Denial of Service (DoS) and Distributed DoS (DDoS)........7
2.4. Phishing..................................................8
2.5. Malware Infection.........................................9
2.6. Insider Threat...........................................10
2.7. Hijacking Traffic........................................11
2.8. Web-based Attacks........................................11
Lazanski Expires September 8, 2020 [Page 2]
Internet-Draft Security Considerations for Protocol Designers March 2020
2.9. Malware-free Attacks.....................................12
2.10. Real-world effects......................................12
2.10.1. Data Exfiltration..................................13
2.10.2. Identity Theft.....................................14
2.11. Table of Attacks........................................14
3. Defensive Measures............................................14
3.1. Response to Attacks......................................15
3.2. Recovery from Attacks....................................15
3.3. Reporting of Attacks.....................................16
3.4. Sinkholing...............................................16
3.5. Firewalls/Middleboxes/Gateways...........................17
3.6. Intrusion Prevention System (IPS) and Intrusion Detection
System (IDS)..................................................17
3.7. Upstream Filtering.......................................18
3.8. Malicious Domain Monitoring and Takedown.................19
3.9. Filtering Type...........................................19
3.10. Implementation of Trust.................................20
3.11. Endpoint Security.......................................20
3.12. Email Anti-spoofing Measures............................21
3.13. Social/User Interface Interventions.....................21
3.14. Detection of Exfiltration and Data Leakage..............22
3.15. Table of Defences.......................................22
4. The Overall Security Picture..................................23
5. Attack Defence in Security Considerations.....................24
6. Security Considerations.......................................24
7. IANA Considerations...........................................24
8. References....................................................24
8.1. Normative References.....................................24
9. Acknowledgments...............................................26
1. Introduction
This draft aims to give a non-exhaustive set of attack defence
considerations for protocol designers and implementers to consider
when designing and deploying protocols. These considerations are
focused on informing the design of protocols so that protocols may
better defend users and systems from malicious attacks. This is
essential information and should be considered for protocol
development. No protocols should be finalised without security
guidance just as no protocols should be designed without privacy
considerations. This document is a useful and necessary and it is
Lazanski Expires September 8, 2020 [Page 3]
Internet-Draft Security Considerations for Protocol Designers March 2020
the intention of the authors that the IETF makes full use of all
the security expertise in its community through the updating of
this document.
In Section 2, we list some of the many attacks that are a
malicious presence on the internet today, with their
methodologies, notable case studies and attack outcomes. This is
not, and can never be, an exhaustive list; threats have been
chosen based on their frequency and regularity, likelihood of
occurring, and impact on victims.
In Section 3, we document some known popular current defensive
practice, giving a list of defence measures that can and are
widely used against attacks from Section 2. These current
practices should be considered when designing and deploying
protocols to avoid obsoleting them unwittingly. Other possible
defensive measures for protocol designs are included where
relevant.
Section 4 outlines the motivations and use of this draft, and
Section 5 suggests the methodology by which considerations
outlined in this draft may be consistently thought through in
protocol design.
2. Attacks
In this section we outline some attack types that are well-known
in industry and in public. For each attack type, we give examples
of how this attack is carried out, case studies of notable attacks
where appropriate, and the outcomes that attackers are trying to
achieve. Some considerations for protocol designers in relation to
each specific attack are also listed.
Throughout this draft the aim to use common industry references,
taxonomies and terminology for types of attack to avoid confusion.
Considerations for protocol designers and deployments in each
section are summarised in a table in Section 2.11 for ease of reference.
Lazanski Expires September 8, 2020 [Page 4]
Internet-Draft Security Considerations for Protocol Designers March 2020
2.1. Endpoint Compromise
Attack Description: Endpoint compromise is when a malicious and
unauthorised attacker has control of an endpoint beyond their
access and privilege level. This may be achieved through many
attack vectors, such as: stealing legitimate credentials that give
access to the endpoint, malware infection, a phishing attack, and
insider threats. Attackers have multiple motivations to compromise
an endpoint, some of which we list here and include: to exfiltrate
personal or IPR data on the endpoint, to perform reconnaissance
for other malware to deploy, to move laterally around a network,
to harvest legitimate credentials, for financial gain, or for
reputational or political reasons. And according to IDC 70% of
successful cybersecurity breaches originate at the endpoint.
When an endpoint is compromised, it is common practice to utilise
a communication channel (either a new one is opened or an existing
one is leveraged) to exfiltrate data, communicate to the command
centre, explore the network or propagate to other endpoints. Such
a communication channel would typically attempt to "look like" a
routine connection to a server or a peer. Furthermore, malware
often disables any protection on the endpoint as part of its
initial infection process allowing this to happen quickly.
Case Study: Silex Malware
In June 2019 a strain of maleware was found that wipes the
firmware of an IoT device. It does this by using known credentials
for logging into IoT devices and completely wipes the system and
removes the network configuration. It impacted thousands of
devices by rendering them useless. [1]
Design Considerations: A protocol design consideration against
this attack would therefore be preserving the ability to detect
the abnormality of connections on host systems. Abnormalities
might include unusual traffic flow to a server, attempting to
contact many IP addresses (scanning), or beaconing behaviour
patterns.
These are just some examples of potential endpoint compromise
situations and subsequent mitigations which can be considered and
included in protocol development. More detailed consideration of
Lazanski Expires September 8, 2020 [Page 5]
Internet-Draft Security Considerations for Protocol Designers March 2020
endpoints, especially with respect to endpoint-only security
solutions can be found in Capabilities and Limitations of an
Endpoint-only Security Solution draft-taddei-smart-cless-
introduction-02 and a related taxonomy, Endpoint Taxonomy for
CLESS draft-mcfadden-smart-endpoint-taxonomy-for-cless-01 which is
a taxonomy of specific endpoint equipment, devices and
applications. These drafts both highlight important points. In the
draft-taddei-smart-cless-introduction-02 researchers found that
75% of incidents were detected not by endpoint security products,
but by network detection products.
2.2. Network Compromise
Attack Description: Network compromise is where a malicious and
unauthorised attacker has presence on or control of part of a
network beyond their privilege level. An attacker may compromise a
network to achieve any one of many objectives, such as: to obscure
endpoint compromise, to move laterally around a network
undetected, to perform reconnaissance, to gain information or data
and to escalate privilege.
Case Study: TBD
Design Considerations: Listed here three different types of
network compromise and associated design considerations:
1) In the case of an unauthorised attacker accessing a passive
inspection point in the network, a protocol design consideration
would be to apply cryptography for confidentiality protection.
2) In the case of an attacker modifying contents of data packets on
the network, a protocol design consideration would be to apply
cryptography for integrity protection.
3) In the case of an attacker re-routing, re-ordering, replaying,
delaying or dropping data on the network, which is arguably less
well-handled by existing Internet transport protocols than case
1) or 2). Protocol design considerations would include strong
sender authentication, integrity checks over whole sessions not
just individual packets, replay detection, and out-of-order
packet detection.
Lazanski Expires September 8, 2020 [Page 6]
Internet-Draft Security Considerations for Protocol Designers March 2020
2.3. Denial of Service (DoS) and Distributed DoS (DDoS)
Attack Description: Denial of Service (DoS) attacks intend to
prevent any service and service delivery. Attackers usually select a high-
profile, online web target that they intend to make unavailable in
the short-term. Distributed DoS attacks utilise multiple
compromised endpoints to distribute the DoS attack, removing the
possibility of blocking the attack by removing the single device
launching the attack.
DDoS attacks can occur:
1) at the network layer, known as a Layer 2 DDoS attack, launched
via malformed packets, flooding or spoofing
2) at the application layer, known as a Layer 7 DDoS attack,
launched via Ping of Death, HTTP floods, XDoS.
3) a combination of both network and application services,
resulting in amplification and reflection attacks
Common DDoS Attacks include:
1) HTTP POST attack in which an attack floods an HTTP POST or GET
request by exploiting an open connection and sending data to
connected web servers, typically over a period of time. This
takes place at Layer 7 and is successful because it is an
asymmetric attack which leaves the connection open for a long
duration. An update would be required to fix this issue.
2) ICMP flood or ping flood is when an attacker takes down a
computer by sending a large number of request packets. This is
accomplished by knowing the destination IP address and sending
the requests.
3) TCP Syn flood is when an attacker intends to overwhelm the
target by sending many SYN requests in an attempt to establish a
TCP connection. Permanent denial-of-service attacks, or
phlashing, is an attack currently which exploits a vulnerability
in a network-based firmware update. DDoS attacks enabled by the
Constrained Application Protocol [2] allows for a flood of
traffic which can overwhelm the intended individual or device.
[3]
A successful DDoS attack, where the service is inaccessible for a
period of time, achieves the attacker objective include
Lazanski Expires September 8, 2020 [Page 7]
Internet-Draft Security Considerations for Protocol Designers March 2020
degradation of service. In some cases, this may be used by the
attacker as an opportunity for extortion.
Case study: Dyn attack, Mirai
The Mirai botnet was first identified in 2016. The Mirai botnet as
well as variants target and infect Internet of Things devices
Those infected devices scan the Internet for IP addresses of
other Internet of Things devices, thus creating a multiplication
of IoT devices which are infected. Though the bot still exists in
various forms, the most serious attack took place on 21 October
2016 when the Domain Name System (DNS) provider Dyn was attacked
by DDoS using a coordinated system of infected IoT devices. Much
of the Internet was unreachable after three attacks occurred
during the same day. Though eventually resolved on that day, the
sheer size and scale of the attack is still viewed as one of the
biggest attacks on the Internet to take place. [4]
Design Considerations: Some people take the attitude of "DDoS
attack? Welcome to the internet". But protocol designers should be
aware of potential issues that help DDoS attacks, such as: CoAP
flooding, protocols that permit mass unscheduled deliveries,
provision of the ability for an attacker to mask e.g. IP
addresses, provision of the ability to amplify, a lack of sender
authentication, a long time open request and an inability to
filter at scale.
2.4. Phishing
Attack Description: A phishing attack is where an unsolicited
message with malicious content is received. Malicious content
could be either in the message itself (email, messages), or
directing the user to a malicious domain. Varieties of phishing
exist, based on difference social engineering approaches,
including: spear phishing, clone phishing and whaling. Phishing is
cited as the initial attack vector for 91% of reported malicious
attacks.[5]
For a phishing attack to succeed, the user has to be unwittingly
duped into an action, where they can't be assumed to have the
knowledge to check their action. For example, users can be
confused by domain names that render almost identically but are
Lazanski Expires September 8, 2020 [Page 8]
Internet-Draft Security Considerations for Protocol Designers March 2020
different at a binary level, such as internationalised domain
names. Also users may see that a sender of an email to them is
someone they know, but not realise that the email address is
different.
Case Study: Ukrainian Power Grid Attack
The cyber attack on the Ukrainian Power Grid took place on
December 23, 2015. It was the first known cyber attack on a power
grid. Around 250,000 individual customers were impacted. DDoS
telephone attacks also prevented people from calling help centres
to report the lack of electricity. All of this began with a spear-
phishing campaign initiated 9 months before that was eventually
successful. [6]
Design Considerations: design protocols with strong
authentications and identification/proof of ownership of domains
required. Provide users with means to assist checking their
actions are safe (or automate the means that can check a user's
actions).
Network infrastructure should be able to detect whether data has
strong authentication and policies can be specified for handling
unauthenticated data (e.g. SPF, DMARC). One defensive measure
employed by domain owners to check for unauthorised usage of
identical or similar domain names is to use Certificate
Transparency logs [7] with automated notifications to the domain
owner where domains with 'close' domain names log a certificate,
indicating a malicious spoofed domain and therefore access is
denied. [8]
2.5. Malware Infection
Attack Description: Malware is one attack vector used to achieve
network or endpoint compromise. As
https://datatracker.ietf.org/doc/draft-fabini-smart-malware-
lifecycle/ draft-fabini-smart-malware-lifecycle-00 describes,
there are many interactions between malware and protocols which
allows for infection and attacks. Malware comes in many different
strains and flavours: exploit kits, ransomware, viruses, trojans,
worms, rootkits and more. The attack outcomes are incredibly
varied too - attackers might want to recruit bots, deploy malware
Lazanski Expires September 8, 2020 [Page 9]
Internet-Draft Security Considerations for Protocol Designers March 2020
that leaves behind physical damage, steal IPR material for
corporate espionage, exfiltrate of credentials to gain accesses
elsewhere in the system, perform reconnaissance for a later
attack, or make some financial gains.
Case Study: WannaCry
In 2017, a ransom attack was launched by using a cryptoworm
targeting computers running the Microsoft operating system. The
attack encrypted person and computer data and then asked for a
ransom in order to unencrypt the data. The attack was eventually
stopped by a 'kill switch' that was discovered, but not without
infecting 200,000 computers first.[9]
Design Considerations: As malware is often carried to an endpoint
by an Internet protocol, there are considerations for protocol
designers. Moreover, once it's arrived at its destination, malware
needs to use protocols for discovery of peers, of C2, for exfil.
Therefore, such connections and the features from those protocols
can be used to detect, track and mitigate outbreaks in real-time.
For example, SMTP headers can detect malware spreading through e-
mail, and other protocol connections can show the lateral movement
of malware through a network.
2.6. Insider Threat
Attack Description: This attack involves social manipulation of an
authorised person so that they knowingly attempt malicious
actions, using their authorised privileges, credentials and
accesses to achieve nefarious attacker objectives. This is
different social engineering to phishing (Section 2.4), where the
user is unwitting to their actions.
The insider themselves might be the sole attacker, for various
reasons - ranging from a desire to gain notoriety or to inflict
deliberate harm on their employer. If the insider is manipulated
by another attacker, their role is likely to provide information
only accessible by an outsider, to enable further attacks.
Eventual attacker outcomes are to gain access to the network or
endpoints, potentially for insider trading, fraudulent
transactions or IPR theft.
Lazanski Expires September 8, 2020 [Page 10]
Internet-Draft Security Considerations for Protocol Designers March 2020
Case Study: Anthem
A contractor working for a consultancy employed by Anthem stole
18,500 individual files with personal details and used them for
personal gain.[10]
Design Consideration: There is therefore a need for authorisation
to be a design consideration for protocols, and also provisioning
the ability to create and manage logs, and to create audit trails
for document access.
2.7. Hijacking Traffic
Attack Description: Border Gateway Protocol hijacking, or BGP
hijacking is when a group of IP addresses are taken over maliciously
by routing table manipulation and corruption.
BGP hijacking is fairly common and is a frequent attack used against
cryptocurrencies because hosting centralisation makes it
particularly vulnerable to attacks. As recently as June 2019 a large
amount of European Internet traffic was re-routed through China
because of a BGP route leak. However, instead of China telecom
ignoring the leak it hijacked the routes as their own. [11]
Case Study: In 2018 Amazon Web Services DNS offering called
Amazon's Route 53 was hijacked by using BGP table updates which
directed the traffic to a malicious server at an IXP in Chicago.
The attack lasted two hours and resulted in stolen Ethereum
cryptocurrency from myetherwallet.com [12]
Design Considerations: Protocol design considerations should
include increased authentication and handshake management when
sending and accepting traffic. Ability to prevent DNS cache
poisoning and route table manipulation.
2.8. Web-based Attacks
Attack Description: Web-based attacks are those that use web
systems and services as the main surface for compromising the
victim [13] including browser exploitations, like the Firefox zero
day exploit found in the new version of Mozilla's browser in
January 2020 [14] and injections, drive-by downloads, cross-site
Lazanski Expires September 8, 2020 [Page 11]
Internet-Draft Security Considerations for Protocol Designers March 2020
request forgery, water-holing, and more. Web-based attacks are on
the rise and Web application attacks also continue in the form of
malicious web applications, SQL injections and cross-site
scripting. [15]
Case Study: Chrome
As recently as February 2020 a security vulnerability in older
versions of the Chrome browser allowed for the exploitation of
user's computers in a zero day attack scenario. Though the
vulnerability has been fixed through updates, a number of attacks
have taken place. Number unknown to date. [16]
Design Considerations: Many mitigations to these attacks rely on
endpoint security, such as patching - possibly explaining the rise
in this attack trend. However, protocol designers should be aware
of other mitigations to avoid designing them out, such as web-
traffic filtering and web-traffic encryption.
2.9. Malware-free Attacks
Attack Description: According to Crowdstrike's 2020 Cyberattack
report, for the first time since starting the report, malware-free
attacks accounted for 51% of all global cyberattack types. A
malware free attack is one that does not employ a malicious file
or fragment a computer disk. Instead, stolen credentials, running
legitimate tools or executing code from memory are all possible
types of attacks. Malware-free attacks are more difficult to
detect unless actively looking for cyberattacks in systems.
Case Study: TBD
Protocol Considerations: Building in resilience to malware-free
cyber attacks. Allow for search and notification of potential
cybersecurity issues as a preemptive measure.
2.10. Real-world effects
Attack Description: Alteration of data on a remote system, e.g. an
Industrial Control System, to achieve an effect that would, for
example, change the delivery of products in a supply chain or
change the characteristics of a product during production may
Lazanski Expires September 8, 2020 [Page 12]
Internet-Draft Security Considerations for Protocol Designers March 2020
cause harm to people using that product intended for one use, but
designed to malfunction.
RDP allows cyber attacks to access the Internet-facing parts of an
ICS from where they may able to move to the operational
environment.
Case Study: Industrial Control Systems or TBD [17]
Protocol considerations: Industrial Control Systems are expensive
and are often patched in slower-time, and a defence-in-depth
approach is advocated; endpoint security alone is not enough.
Additional considerations include the ability to real-time monitor
easily, and to note that internet protocols are used for high-
threat systems.
2.10.1. Data Exfiltration
Attack Description: Data exfiltration is a frequent outcome of
compromise, where data is taken from a system by an unauthorised
user. This information leakage includes customer data (often in
high-profile breaches) or theft of IPR material from enterprises.
Exfiltration of data can be:
1) High-volume, where the attacker expects to detected or wants to
operate quickly.
2) Low-and-slow, where data is siphoned off at a low level for a
long period of time, in the hope of avoiding detection.
Case study: Equifax
In March 2017, attackers searched the web looking for
vulnerabilities that were known, but had not been fixed. These
attackers targeted the dispute resolution portal at a credit
ratings company called Equifax in the US. The hackers used a
vulnerability in Apache Struts which allowed access and
exfiltration of personal information on the portal. [18]
Design Considerations: Endpoints can tag/watermark content so that
leaked data can be identified and possibly stopped at a gateway,
or at least traced back to the user that leaked the material. For
this, protocol data could include a protective marking field that
is visible to a firewall, even if the content is encrypted.
Lazanski Expires September 8, 2020 [Page 13]
Internet-Draft Security Considerations for Protocol Designers March 2020
Another issue to consider is the detection of data exfiltrated
through covert channels. Protocols should be designed with this
abuse in mind, with designers minimising existence and size of
covert channels.
2.10.2. Identity Theft
Attack Description: Fraud committed from the theft of personal
identifiable information - such as bank details, home address and
date of birth - strengthened by the massive digitisation and
centralisation of people's personal data. Credential stealing and
credential stuffing are two of many ways to obtain personal data.
Case Study: JP Morgan Chase
In 2014 JP Morgan Chase had over 83 million accounts compromised
and hackers made over $100 million through fraud and identity
theft. To date it is one of the largest data breaches in
history.[19]
Design Considerations: Provision and protect a way that allows
breaches of personal data to be detected in real-time and stopped.
Use strong authentication to secure access.
2.11. Table of Attacks
Table to be added in the next version of this draft.
3. Defensive Measures
Defensive measures broadly fall into three classes:
1. prevention of attacks - stopping most attacks from achieving the
attacker's objectives, i.e. from taking hold on a system,
network or endpoint.
2. detection of attacks - how attacks are detected quickly,
efficiently, with a high-degree of confidence and accuracy.
3. mitigation of attacks - once an attack happens, the capability
to stop the damage done by the attack, e.g. preventing the
spread of the compromise within an organisation, limiting the
data exfiltrated or stopping the attack from being replicated
globally on unaffected systems.
Lazanski Expires September 8, 2020 [Page 14]
Internet-Draft Security Considerations for Protocol Designers March 2020
All defences listed in this section relate to one or more attacks
listed in Section 2.
For each type of defensive measure, we categorise the method as
prevention, detection, mitigation or a combination of these; we
link to the type of attack in Section 2 that is prevented; and we
describe how the defence works.
Considerations for protocol designers (in relation to each
defensive measure) are also listed throughout, and summarised in
Table 3.15 to provide an easier reference.
3.1. Response to Attacks
Defence Type: Mitigation
A system can be designed to ensure availability under attack, e.g.
by segregating classes of devices on a network, or considering
system architecture. Components that are under attack have a
channel for reporting that attack that is distinct from the
channel used for launching the attack.
Case Study: TBD
Design Considerations: Design protocols that allow such
segregation in architecture in a simple and scalable way. Design
protocols for reporting of attacks that use channels that are less
susceptible to attacks.
3.2. Recovery from Attacks
Defence Type: Prevention
If organisations and individuals assume that a security breach
will happen then defences will be optimised in or to allow for a
quick response and minimal impact.
For example, encrypt data when stored so that if it is stolen, the
attacker can't decrypt it. For another example, if data is backed
up regularly, then the threat held by ransomware is minimised.
Case Study: TBD
Lazanski Expires September 8, 2020 [Page 15]
Internet-Draft Security Considerations for Protocol Designers March 2020
Design Considerations: Design protocols that can deliver encrypted
payloads to capable endpoints. Practice strong separation of the
keys used to encrypt data at rest from the data, with high levels
of protection applied to the keys. Design protocols that allow for
regular, automatic backup of data minimising the amount of user
interaction required.
3.3. Reporting of Attacks
Defence Type: Detection
Logging is an important feature. Multiple logs allow cross-
referencing and establishing truth data, so it is important to
provide logging in multiple places, to detect false reporting by
compromised endpoints or networks. Logging allows strengthened
forensics, which reduces the risk of similar attacks in future.
Forensic analysis of logs makes it easier to detect and locate
attacks, so can be a deterrent to attackers. For this same reason,
malicious manipulation of logs to prevent detection is an
attractive attacker objective.
Reliable logging helps to find the source of an attack, its spread
and what devices and networks have been compromised. Unreliable
logging can slow attempts to mitigate it.
Case Study: TBD
Design Considerations: How a protocol might help/hinder the
ability to troubleshoot or have separate logging in multiple
places (for truth data), allow for reliable logging across points
in a network.
3.4. Sinkholing
Defence Type: Mitigation
Mitigation against where a DDoS attack has already been launched,
to prevent a successful attack outcome (i.e. a denial of service).
Case Study: TBD
Lazanski Expires September 8, 2020 [Page 16]
Internet-Draft Security Considerations for Protocol Designers March 2020
Design Considerations: Ability to determine whether a connection
is likely malicious or not, and filter out malicious connections
at speed. Ability to reliably determine the source of a connection
and verify that it is accurate and from an address authorised to
make the connection.
3.5. Firewalls/Middleboxes/Gateways
Defence Type: Prevention and detection
Firewalls, middleboxes and gateways can be used to inspect traffic
and make decisions whether to allow, block or modify data content.
These decisions can be based on simple IP address / port /
protocol rules, or on deep packet inspection of individual data
packets, or use artificial intelligence / machine learning
techniques to make more complex decisions based on analysis of
traffic over a period of time.
Case Study: TBD
Design Considerations: Protocols should allow for selective and/or
minimally intrusive analysis, balanced against the need to protect
the privacy of the user content and any personally identifiable
information. Minimally intrusive analysis could include the
ability to block traffic that it associated with known insecure
protocols or ports, known malicious activity or known malicious
users. A protocol that makes all traffic look essentially
indistinguishable forces the firewall into making an "all-or-
nothing" decision, which would be ineffective for defending
against attacks if it is still to allow some communications.
A firewall should not be able to undetectably modify traffic;
where it is necessary to modify traffic to prevent a threat, the
modification should be apparent to the receiver.
3.6. Intrusion Prevention System (IPS) and Intrusion Detection System
(IDS)
Defence Type: prevention and detection
Lazanski Expires September 8, 2020 [Page 17]
Internet-Draft Security Considerations for Protocol Designers March 2020
These systems provide the abilities to prevent and detect malware
infection, vulnerability exploits, and lateral movement on
compromised networks and endpoints.
Signatures for bad content - IPS/IDSs don't work on traffic if
attacks have legitimate content but bad intent, e.g. DDoS.
However, the IPS/IDS may detect the malware that compromised the
endpoint to launch the DDoS attack.
IDSs are passive systems that scan traffic and report to the
traffic owner on threats; IPSs are inline, taking an active role
and making automated decisions and applying these actions to
traffic.
Case Study: TBD
Design Considerations: For IDS, protocols should allow for logging
of data relating to the connection, which may include any or all
of IP addresses, ports, protocols and payloads, balanced with the
requirement to protect privacy of user data. For IPS, protocols
should allow for signature/statistical anomaly detection, the
ability to selectively drop traffic and respond at efficient scale
and speed.
3.7. Upstream Filtering
Defence Type: Mitigation
Content is filtered through a "scrubbing" centre to forward only
good traffic. This is provided as a service by e.g. Cloudflare,
Akamai.[
Case Study: TBD
Design Considerations: allow for forwarding of traffic on this
scale through robust internet infrastructure. Attack traffic
should be easily recognisable through its externals, e.g. packet
destination, traffic flow patterns, protocol type, signatures.
This relies on being able to filter at speed and weed out
malicious connections.
Lazanski Expires September 8, 2020 [Page 18]
Internet-Draft Security Considerations for Protocol Designers March 2020
3.8. Malicious Domain Monitoring and Takedown
Defence Type: to detection and prevention.
We wish to detect the existence and determine the intent of
malicious domains as soon as possible, and remove or deny access
to them before most harm can be done. For example, removal of
malicious domains that are created to receive clicks from phishing
emails; if the domain can be removed before most emails are read,
the links won't work and the harm is reduced with no effort from
the user.
Takedown services can levy copyright protections to request
takedowns. Combined with techniques to use email authentication,
these proactive measures rather than reactive ones have had
considerable effect in UK government efforts to minimise phishing
[20]
Case Study: TBD
Design Considerations: Protocols should allow users to determine
the identity of the domain that they are connecting before they
are exposed to data from that domain. Protocols should provide a
means for users to verify the authenticity of a connection to a
domain. Protocols should minimise the opportunities for users to
confuse malicious domains with legitimate domains. Protocols
should provide a method for legitimate domain owners to recognise
attempts by a malicious domain to masquerade as the legitimate
domain.
3.9. Filtering Type
Defence Type: Prevention and mitigation.
Filtering of traffic can be done according to black lists of
addresses, content types or signatures specified by malware threat
feeds. Filtering can also be done using statistical and machine
learning techniques, e.g. for spam. Filtering can prevent malware
infection or mitigate it by stopping the further spread of
malware.
Case Study: TBD
Lazanski Expires September 8, 2020 [Page 19]
Internet-Draft Security Considerations for Protocol Designers March 2020
Design Considerations: Protocols should allow for selective and/or
minimally intrusive analysis of traffic in order to determine
whether to allow data through the filter. Malware may try to shape
malicious traffic to appear like benign traffic, so protocol
specifications should minimise the opportunity for malicious
payloads to masquerade as legitimate payloads. For example,
encrypting all data so that it looks the same, then you're
removing any discriminating features that filtering systems could
use to base their decisions on.
Protocols therefore should be designed with an awareness that
hiding features that expose malicious traffic as malicious will
enable malicious payload delivery, therefore it would be response
to work out which, and preserve features that, would still allow
effective detection.
3.10. Implementation of Trust
Defence Type: Prevention.
Content is filtered so that data from non-trusted sources is
filtered out before it arrives. TBD
e.g. DMARC/SPF to prevent phishing, secure authenticated log-in,
enforcement of PKI certificate validity on TLS connections etc.
Case Study: TBD
Design Considerations: Protocols should be resilient and should
not prevent informed users from opting into services that
protected delivery of only trusted content. Protocols should
allow for verification of data source and integrity. Protocols
should include policies for handling and management of non-trusted
data.
3.11. Endpoint Security
Defence Type: prevention, detection and mitigation.
Security hygiene, like regular patches to fix the latest
discovered software vulnerabilities, form an important part of the
security of any system. However, some endpoints are unable to
Lazanski Expires September 8, 2020 [Page 20]
Internet-Draft Security Considerations for Protocol Designers March 2020
maintain their own security and can introduce vulnerabilities
themselves.
Case Study: TBD
Design Considerations: Consider whether the protocol data is
available for inspection by the endpoint security solution. At
what point in the protocol stack is protected data decrypted and
can be analysed or blocked by the endpoint security?
3.12. Email Anti-spoofing Measures
Defence Type: Prevention
These are preventive measures designed to prevent and reduce
phishing emails.
Configure anti-spoofing controls on a domain you own to prevent
email spoofing, such as Domain-based Message Authentication,
Reporting and Conformance (DMARC), Sender Policy Framework (SPF)
and Domain-Keys Identified Mail (DKIM). [22]
Case Study: TBD
Design Considerations: Allow for strong authentication of source
of user data. Policies for delivery of non-authenticated data.
3.13. Social/User Interface Interventions
Defence Type: Prevention and detection.
Since phishing is a social engineering type of attack, there
should be education and training for people to prevent phishing.
Futhermore, presenting a user with a photo on log-in to prevent
logging into a phishing domain and two factor authentication (2FA)
are some of the mitigation strategies. Also reporting of abnormal
behaviour/user mistakes should be encouraged and failed log-in
attempts should be displayed to the user. Finally appropriate
password policies should be in place.
Case Study: TBD
Lazanski Expires September 8, 2020 [Page 21]
Internet-Draft Security Considerations for Protocol Designers March 2020
Design Considerations: Protocols should support secure
communication of security-critical information to and from the
user interface; this could include passwords, biometric
information, other credentials, user activity logs, PKI
certificate properties and validity, origin authentication using
auxiliary information (such as identifying phrases or photos).
3.14. Detection of Exfiltration and Data Leakage
Defence Type: detection and mitigation
When a compromise of a network has occurred, either by malware
infection or insider threat, it is important to be able to detect
attempts to exfiltrate data from the network and stop exfiltration
as soon as the leak has been reliably confirmed.
Detection of exfiltration can be through packet metadata analysis,
statistical analysis of data collected over a period of time, or
content inspection on unencrypted data.
Case Study: TBD
Design Considerations: Encryption of data can make inspection of
data at a gateway for malicious exfiltration less reliable.
Statistical properties of traffic may be used to detect
exfiltration occurring over an extended period of time; it would
be very bad for attack defence in general if protocols sought to
hide patterns of traffic that are be indicative of exfiltration.
If data is watermarked to indicate the origin of protected
content, protocols should not destroy the watermarks. Protocols
should minimise covert channels that can be used for the
exfiltration of data by malware.
3.15. Table of Defences
Table to be added in the next version of this draft.
Lazanski Expires September 8, 2020 [Page 22]
Internet-Draft Security Considerations for Protocol Designers March 2020
4. The Overall Security Picture
Deployments of protocols vary greatly and use cases show the
variety and diversity of design, development and implementation of
protocols; There are varying levels of risk and a variety of
threats being more likely than others depending on context in
which the protocol is deployed. Therefore, some attacks and
defensive measures outlined in the above sections may be more
frequent than others. For example, an enterprise might consider
customer data exfiltration a greater threat than its resilience to
zero-day vulnerability exploitation, but an individual user might
be more concerned with their protection against phishing than with
seeing all traffic leaving their network.
For protocol designers, it is important that a protocol's impact
on different attack defence cases across the layers of the
internet should be considered when designing the protocol.
Defence against malicious attacks can be either improved or
weakened by the design features of protocols. Designers should
acknowledge that including attack prevention, detection and
mitigation is essential in protocol development.
There is no one-size-fits-all approach for protocol deployment;
each specific implementation and use case should be considered
separately, as deployments require a mature a whole-system
security view. This allows for a system wide analysis so that the
security of the protocol isn't the only security considered.
For example, a user with a client that runs DoH might feel
completely secure, as the information is encrypted and you have a
private connection to the DNS resolver. However, this could
actually bypass defensive filtering protections, without the
protection afforded blocking of malicious domains. Further, unless
DNSSEC is also deployed, you have no trust that the resolver is
returning the correct results.
Another popular example is the padlock in most browsers that tells
users they have a secure HTTPS connection. Users can conflate the
meaning of the padlock, assuming that use of HTTPS automatically
confers a legitimate connection - even if the domain being
connected to is fake or malicious.
Lazanski Expires September 8, 2020 [Page 23]
Internet-Draft Security Considerations for Protocol Designers March 2020
5. Attack Defence in Security Considerations
The impact of new protocols on existing systems that defend
against malicious attacks is not systematically considered in the
Security Considerations sections in RFCs. This draft is the first
step in developing a reference guide to enable a systematic and
consistent assessment across different protocols with respect to
attack defence.
Hence, protocols should be assessed against a range of attacks and
detections methods, such as those attack types listed in the Table
in Section 2 and those defensive measures listed in the Table in
Section 3, as a standard consideration in all protocol design, and
to make the potential impacts clear to deployers.
When writing the Security Considerations for a protocol, protocol
designers should consider known attacks and prevention, detection
and mitigation methods. As the type, kind and characteristics of
attacks grow in complexity, it is important that protocol
designers take into account attack types and mitigation strategies
into their designs. In fact this should be backed into the
security considerations from the start. This draft RFC is a
helpful guide to those considerations.
6. Security Considerations
This document is entirely about Internet security and is an input to
the IAB Model T work.
7. IANA Considerations
This draft has no actions for IANA.
8. References
8.1. Normative References
[1] https://www.zdnet.com/article/new-silex-malware-is-bricking-
iot-devices-has-scary-plans/
[2] RFC 7252 Shelby, Z. et al, "The Constrained Application
Protocol (CAP)" RFC 7252, June 2014.
Lazanski Expires September 8, 2020 [Page 24]
Internet-Draft Security Considerations for Protocol Designers March 2020
[3] https://www.zdnet.com/article/the-coap-protocol-is-the-next-
big-thing-for-ddos-attacks/
[4] https://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-
attack-cause-outage-status-explained
[5] https://www.darkreading.com/endpoint/91--of-cyberattacks-
start-with-a-phishing-email/d/d-id/1327704
[6] https://www.wired.com/2016/01/everything-we-know-about-
ukraines-power-plant-hack/
[7] https://developers.facebook.com/docs/certificate-transparency/
[8] RFC 6962 Laurie B., et al, "Certificate Transparency" RFC
6962, June 2013.
[9] https://techcrunch.com/2019/05/12/wannacry-two-years-on/
[10] https://www.cnbc.com/2017/07/31/new-anthem-data-breach-by-
contractor-affects-more-than-18000-enrollees.html
[11] https://www.zdnet.com/article/for-two-hours-a-large-chunk-of-
european-mobile-traffic-was-rerouted-through-china/
[12] https://www.internetsociety.org/blog/2018/04/amazons-route-53-
bgp-hijack/
[13] https://www.enisa.europa.eu/topics/threat-risk-
management/threats-and-trends/enisa-threat-landscape
[14] https://www.welivesecurity.com/2020/01/09/mozilla-rushes-
patch-firefox-zero-day/
[15] https://www.forbes.com/sites/emilsayegh/2020/02/12/more-cloud-
more-hacks-pt-2/#7c0c47d669b3
[16] https://threatpost.com/google-patches-chrome-browser-zero-day-
bug-under-attack/153216/
[17] https://www.computerweekly.com/news/252446423/Industrial-
controls-systems-a-specialised-cyber-target
Lazanski Expires September 8, 2020 [Page 25]
Internet-Draft Security Considerations for Protocol Designers March 2020
[18] https://www.cnet.com/news/equifaxs-hack-one-year-later-a-look-
back-at-how-it-happened-and-whats-changed/
[19] https://www.wired.com/2015/11/four-indicted-in-massive-jp-
morgan-chase-hack/
[20] https://www.ncsc.gov.uk/guidance/phishing
[21] http://www.circleid.com/posts/20170214_blocking_a_ddos_upstrea
m/
[22] https://www.ncsc.gov.uk/collection/email-security-and-anti-
spoofing
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Lazanski Expires September 8, 2020 [Page 26]
Internet-Draft Security Considerations for Protocol Designers March 2020
Authors' Addresses
Dominique Lazanski
Last Press Label
London, UK
Email: dml@lastpresslabel.com
Lazanski Expires September 8, 2020 [Page 27]