idnits 2.17.1 draft-lazanski-protocol-sec-design-model-t-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 434 has weird spacing: '...rencies beca...' == Line 449 has weird spacing: '...isoning and r...' == Line 814 has weird spacing: '...ections etc....' == Line 931 has weird spacing: '...cluding attac...' -- The document date (March 8, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '21' is defined on line 1048, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6962 (ref. '8') (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB Programme D. Lazanski 2 Internet Draft Last Press Label 3 Intended status: Informational March 8, 2020 4 Expires: September 9, 2020 6 Security Considerations for Protocol Designers 7 draft-lazanski-protocol-sec-design-model-t-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 8, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document is a non-exhaustive set of considerations for protocol 50 designers and implementers with regards to attack defence. These 51 considerations can be used as an aid to analyse protocol design 52 choice and in turn to help combat threats and defend users of these 53 protocols and systems against malicious attacks. 55 First, we list well-known classes of attacks that pose threats, with 56 relevant case studies and descriptions. Next, we give a list of 57 defence measures against these attacks to be considered when 58 designing and deploying protocols. Naturally, deployments of 59 protocols vary greatly between use cases; therefore, some attacks and 60 defensive measures outlined may require more consideration than 61 others, dependent on use case. 63 This RFC can be used by protocol designers to write the Security 64 Considerations section in an RFC. The impact on attack defence of a 65 protocol should be considered in multiple use cases across the 66 multiple layers of the internet in its this section. Defence against 67 malicious attacks can be improved and it can be weakened by design 68 features of protocols. Designers should acknowledge the role of 69 protocols in attack prevention, detection and mitigation; this 70 document aims to be a useful guide in doing so. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Attacks........................................................4 76 2.1. Endpoint Compromise.......................................5 77 2.2. Network Compromise........................................6 78 2.3. Denial of Service (DoS) and Distributed DoS (DDoS)........7 79 2.4. Phishing..................................................8 80 2.5. Malware Infection.........................................9 81 2.6. Insider Threat...........................................10 82 2.7. Hijacking Traffic........................................11 83 2.8. Web-based Attacks........................................11 84 2.9. Malware-free Attacks.....................................12 85 2.10. Real-world effects......................................12 86 2.10.1. Data Exfiltration..................................13 87 2.10.2. Identity Theft.....................................14 88 2.11. Table of Attacks........................................14 89 3. Defensive Measures............................................14 90 3.1. Response to Attacks......................................15 91 3.2. Recovery from Attacks....................................15 92 3.3. Reporting of Attacks.....................................16 93 3.4. Sinkholing...............................................16 94 3.5. Firewalls/Middleboxes/Gateways...........................17 95 3.6. Intrusion Prevention System (IPS) and Intrusion Detection 96 System (IDS)..................................................17 97 3.7. Upstream Filtering.......................................18 98 3.8. Malicious Domain Monitoring and Takedown.................19 99 3.9. Filtering Type...........................................19 100 3.10. Implementation of Trust.................................20 101 3.11. Endpoint Security.......................................20 102 3.12. Email Anti-spoofing Measures............................21 103 3.13. Social/User Interface Interventions.....................21 104 3.14. Detection of Exfiltration and Data Leakage..............22 105 3.15. Table of Defences.......................................22 106 4. The Overall Security Picture..................................23 107 5. Attack Defence in Security Considerations.....................24 108 6. Security Considerations.......................................24 109 7. IANA Considerations...........................................24 110 8. References....................................................24 111 8.1. Normative References.....................................24 112 9. Acknowledgments...............................................26 114 1. Introduction 116 This draft aims to give a non-exhaustive set of attack defence 117 considerations for protocol designers and implementers to consider 118 when designing and deploying protocols. These considerations are 119 focused on informing the design of protocols so that protocols may 120 better defend users and systems from malicious attacks. This is 121 essential information and should be considered for protocol 122 development. No protocols should be finalised without security 123 guidance just as no protocols should be designed without privacy 124 considerations. This document is a useful and necessary and it is 125 the intention of the authors that the IETF makes full use of all 126 the security expertise in its community through the updating of 127 this document. 129 In Section 2, we list some of the many attacks that are a 130 malicious presence on the internet today, with their 131 methodologies, notable case studies and attack outcomes. This is 132 not, and can never be, an exhaustive list; threats have been 133 chosen based on their frequency and regularity, likelihood of 134 occurring, and impact on victims. 136 In Section 3, we document some known popular current defensive 137 practice, giving a list of defence measures that can and are 138 widely used against attacks from Section 2. These current 139 practices should be considered when designing and deploying 140 protocols to avoid obsoleting them unwittingly. Other possible 141 defensive measures for protocol designs are included where 142 relevant. 144 Section 4 outlines the motivations and use of this draft, and 145 Section 5 suggests the methodology by which considerations 146 outlined in this draft may be consistently thought through in 147 protocol design. 149 2. Attacks 151 In this section we outline some attack types that are well-known 152 in industry and in public. For each attack type, we give examples 153 of how this attack is carried out, case studies of notable attacks 154 where appropriate, and the outcomes that attackers are trying to 155 achieve. Some considerations for protocol designers in relation to 156 each specific attack are also listed. 158 Throughout this draft the aim to use common industry references, 159 taxonomies and terminology for types of attack to avoid confusion. 161 Considerations for protocol designers and deployments in each 162 section are summarised in a table in Section 2.11 for ease of reference. 164 2.1. Endpoint Compromise 166 Attack Description: Endpoint compromise is when a malicious and 167 unauthorised attacker has control of an endpoint beyond their 168 access and privilege level. This may be achieved through many 169 attack vectors, such as: stealing legitimate credentials that give 170 access to the endpoint, malware infection, a phishing attack, and 171 insider threats. Attackers have multiple motivations to compromise 172 an endpoint, some of which we list here and include: to exfiltrate 173 personal or IPR data on the endpoint, to perform reconnaissance 174 for other malware to deploy, to move laterally around a network, 175 to harvest legitimate credentials, for financial gain, or for 176 reputational or political reasons. And according to IDC 70% of 177 successful cybersecurity breaches originate at the endpoint. 179 When an endpoint is compromised, it is common practice to utilise 180 a communication channel (either a new one is opened or an existing 181 one is leveraged) to exfiltrate data, communicate to the command 182 centre, explore the network or propagate to other endpoints. Such 183 a communication channel would typically attempt to "look like" a 184 routine connection to a server or a peer. Furthermore, malware 185 often disables any protection on the endpoint as part of its 186 initial infection process allowing this to happen quickly. 188 Case Study: Silex Malware 190 In June 2019 a strain of maleware was found that wipes the 191 firmware of an IoT device. It does this by using known credentials 192 for logging into IoT devices and completely wipes the system and 193 removes the network configuration. It impacted thousands of 194 devices by rendering them useless. [1] 196 Design Considerations: A protocol design consideration against 197 this attack would therefore be preserving the ability to detect 198 the abnormality of connections on host systems. Abnormalities 199 might include unusual traffic flow to a server, attempting to 200 contact many IP addresses (scanning), or beaconing behaviour 201 patterns. 203 These are just some examples of potential endpoint compromise 204 situations and subsequent mitigations which can be considered and 205 included in protocol development. More detailed consideration of 206 endpoints, especially with respect to endpoint-only security 207 solutions can be found in Capabilities and Limitations of an 208 Endpoint-only Security Solution draft-taddei-smart-cless- 209 introduction-02 and a related taxonomy, Endpoint Taxonomy for 210 CLESS draft-mcfadden-smart-endpoint-taxonomy-for-cless-01 which is 211 a taxonomy of specific endpoint equipment, devices and 212 applications. These drafts both highlight important points. In the 213 draft-taddei-smart-cless-introduction-02 researchers found that 214 75% of incidents were detected not by endpoint security products, 215 but by network detection products. 217 2.2. Network Compromise 219 Attack Description: Network compromise is where a malicious and 220 unauthorised attacker has presence on or control of part of a 221 network beyond their privilege level. An attacker may compromise a 222 network to achieve any one of many objectives, such as: to obscure 223 endpoint compromise, to move laterally around a network 224 undetected, to perform reconnaissance, to gain information or data 225 and to escalate privilege. 227 Case Study: TBD 229 Design Considerations: Listed here three different types of 230 network compromise and associated design considerations: 232 1) In the case of an unauthorised attacker accessing a passive 233 inspection point in the network, a protocol design consideration 234 would be to apply cryptography for confidentiality protection. 236 2) In the case of an attacker modifying contents of data packets on 237 the network, a protocol design consideration would be to apply 238 cryptography for integrity protection. 240 3) In the case of an attacker re-routing, re-ordering, replaying, 241 delaying or dropping data on the network, which is arguably less 242 well-handled by existing Internet transport protocols than case 243 1) or 2). Protocol design considerations would include strong 244 sender authentication, integrity checks over whole sessions not 245 just individual packets, replay detection, and out-of-order 246 packet detection. 248 2.3. Denial of Service (DoS) and Distributed DoS (DDoS) 250 Attack Description: Denial of Service (DoS) attacks intend to 251 prevent any service and service delivery. Attackers usually select a high- 252 profile, online web target that they intend to make unavailable in 253 the short-term. Distributed DoS attacks utilise multiple 254 compromised endpoints to distribute the DoS attack, removing the 255 possibility of blocking the attack by removing the single device 256 launching the attack. 258 DDoS attacks can occur: 260 1) at the network layer, known as a Layer 2 DDoS attack, launched 261 via malformed packets, flooding or spoofing 262 2) at the application layer, known as a Layer 7 DDoS attack, 263 launched via Ping of Death, HTTP floods, XDoS. 264 3) a combination of both network and application services, 265 resulting in amplification and reflection attacks 267 Common DDoS Attacks include: 269 1) HTTP POST attack in which an attack floods an HTTP POST or GET 270 request by exploiting an open connection and sending data to 271 connected web servers, typically over a period of time. This 272 takes place at Layer 7 and is successful because it is an 273 asymmetric attack which leaves the connection open for a long 274 duration. An update would be required to fix this issue. 275 2) ICMP flood or ping flood is when an attacker takes down a 276 computer by sending a large number of request packets. This is 277 accomplished by knowing the destination IP address and sending 278 the requests. 279 3) TCP Syn flood is when an attacker intends to overwhelm the 280 target by sending many SYN requests in an attempt to establish a 281 TCP connection. Permanent denial-of-service attacks, or 282 phlashing, is an attack currently which exploits a vulnerability 283 in a network-based firmware update. DDoS attacks enabled by the 284 Constrained Application Protocol [2] allows for a flood of 285 traffic which can overwhelm the intended individual or device. 286 [3] 288 A successful DDoS attack, where the service is inaccessible for a 289 period of time, achieves the attacker objective include 290 degradation of service. In some cases, this may be used by the 291 attacker as an opportunity for extortion. 293 Case study: Dyn attack, Mirai 295 The Mirai botnet was first identified in 2016. The Mirai botnet as 296 well as variants target and infect Internet of Things devices 297 Those infected devices scan the Internet for IP addresses of 298 other Internet of Things devices, thus creating a multiplication 299 of IoT devices which are infected. Though the bot still exists in 300 various forms, the most serious attack took place on 21 October 301 2016 when the Domain Name System (DNS) provider Dyn was attacked 302 by DDoS using a coordinated system of infected IoT devices. Much 303 of the Internet was unreachable after three attacks occurred 304 during the same day. Though eventually resolved on that day, the 305 sheer size and scale of the attack is still viewed as one of the 306 biggest attacks on the Internet to take place. [4] 308 Design Considerations: Some people take the attitude of "DDoS 309 attack? Welcome to the internet". But protocol designers should be 310 aware of potential issues that help DDoS attacks, such as: CoAP 311 flooding, protocols that permit mass unscheduled deliveries, 312 provision of the ability for an attacker to mask e.g. IP 313 addresses, provision of the ability to amplify, a lack of sender 314 authentication, a long time open request and an inability to 315 filter at scale. 317 2.4. Phishing 319 Attack Description: A phishing attack is where an unsolicited 320 message with malicious content is received. Malicious content 321 could be either in the message itself (email, messages), or 322 directing the user to a malicious domain. Varieties of phishing 323 exist, based on difference social engineering approaches, 324 including: spear phishing, clone phishing and whaling. Phishing is 325 cited as the initial attack vector for 91% of reported malicious 326 attacks.[5] 328 For a phishing attack to succeed, the user has to be unwittingly 329 duped into an action, where they can't be assumed to have the 330 knowledge to check their action. For example, users can be 331 confused by domain names that render almost identically but are 332 different at a binary level, such as internationalised domain 333 names. Also users may see that a sender of an email to them is 334 someone they know, but not realise that the email address is 335 different. 337 Case Study: Ukrainian Power Grid Attack 339 The cyber attack on the Ukrainian Power Grid took place on 340 December 23, 2015. It was the first known cyber attack on a power 341 grid. Around 250,000 individual customers were impacted. DDoS 342 telephone attacks also prevented people from calling help centres 343 to report the lack of electricity. All of this began with a spear- 344 phishing campaign initiated 9 months before that was eventually 345 successful. [6] 347 Design Considerations: design protocols with strong 348 authentications and identification/proof of ownership of domains 349 required. Provide users with means to assist checking their 350 actions are safe (or automate the means that can check a user's 351 actions). 353 Network infrastructure should be able to detect whether data has 354 strong authentication and policies can be specified for handling 355 unauthenticated data (e.g. SPF, DMARC). One defensive measure 356 employed by domain owners to check for unauthorised usage of 357 identical or similar domain names is to use Certificate 358 Transparency logs [7] with automated notifications to the domain 359 owner where domains with 'close' domain names log a certificate, 360 indicating a malicious spoofed domain and therefore access is 361 denied. [8] 363 2.5. Malware Infection 365 Attack Description: Malware is one attack vector used to achieve 366 network or endpoint compromise. As 367 https://datatracker.ietf.org/doc/draft-fabini-smart-malware- 368 lifecycle/ draft-fabini-smart-malware-lifecycle-00 describes, 369 there are many interactions between malware and protocols which 370 allows for infection and attacks. Malware comes in many different 371 strains and flavours: exploit kits, ransomware, viruses, trojans, 372 worms, rootkits and more. The attack outcomes are incredibly 373 varied too - attackers might want to recruit bots, deploy malware 374 that leaves behind physical damage, steal IPR material for 375 corporate espionage, exfiltrate of credentials to gain accesses 376 elsewhere in the system, perform reconnaissance for a later 377 attack, or make some financial gains. 379 Case Study: WannaCry 381 In 2017, a ransom attack was launched by using a cryptoworm 382 targeting computers running the Microsoft operating system. The 383 attack encrypted person and computer data and then asked for a 384 ransom in order to unencrypt the data. The attack was eventually 385 stopped by a 'kill switch' that was discovered, but not without 386 infecting 200,000 computers first.[9] 388 Design Considerations: As malware is often carried to an endpoint 389 by an Internet protocol, there are considerations for protocol 390 designers. Moreover, once it's arrived at its destination, malware 391 needs to use protocols for discovery of peers, of C2, for exfil. 392 Therefore, such connections and the features from those protocols 393 can be used to detect, track and mitigate outbreaks in real-time. 394 For example, SMTP headers can detect malware spreading through e- 395 mail, and other protocol connections can show the lateral movement 396 of malware through a network. 398 2.6. Insider Threat 400 Attack Description: This attack involves social manipulation of an 401 authorised person so that they knowingly attempt malicious 402 actions, using their authorised privileges, credentials and 403 accesses to achieve nefarious attacker objectives. This is 404 different social engineering to phishing (Section 2.4), where the 405 user is unwitting to their actions. 407 The insider themselves might be the sole attacker, for various 408 reasons - ranging from a desire to gain notoriety or to inflict 409 deliberate harm on their employer. If the insider is manipulated 410 by another attacker, their role is likely to provide information 411 only accessible by an outsider, to enable further attacks. 412 Eventual attacker outcomes are to gain access to the network or 413 endpoints, potentially for insider trading, fraudulent 414 transactions or IPR theft. 416 Case Study: Anthem 418 A contractor working for a consultancy employed by Anthem stole 419 18,500 individual files with personal details and used them for 420 personal gain.[10] 422 Design Consideration: There is therefore a need for authorisation 423 to be a design consideration for protocols, and also provisioning 424 the ability to create and manage logs, and to create audit trails 425 for document access. 427 2.7. Hijacking Traffic 429 Attack Description: Border Gateway Protocol hijacking, or BGP 430 hijacking is when a group of IP addresses are taken over maliciously 431 by routing table manipulation and corruption. 433 BGP hijacking is fairly common and is a frequent attack used against 434 cryptocurrencies because hosting centralisation makes it 435 particularly vulnerable to attacks. As recently as June 2019 a large 436 amount of European Internet traffic was re-routed through China 437 because of a BGP route leak. However, instead of China telecom 438 ignoring the leak it hijacked the routes as their own. [11] 440 Case Study: In 2018 Amazon Web Services DNS offering called 441 Amazon's Route 53 was hijacked by using BGP table updates which 442 directed the traffic to a malicious server at an IXP in Chicago. 443 The attack lasted two hours and resulted in stolen Ethereum 444 cryptocurrency from myetherwallet.com [12] 446 Design Considerations: Protocol design considerations should 447 include increased authentication and handshake management when 448 sending and accepting traffic. Ability to prevent DNS cache 449 poisoning and route table manipulation. 451 2.8. Web-based Attacks 453 Attack Description: Web-based attacks are those that use web 454 systems and services as the main surface for compromising the 455 victim [13] including browser exploitations, like the Firefox zero 456 day exploit found in the new version of Mozilla's browser in 457 January 2020 [14] and injections, drive-by downloads, cross-site 458 request forgery, water-holing, and more. Web-based attacks are on 459 the rise and Web application attacks also continue in the form of 460 malicious web applications, SQL injections and cross-site 461 scripting. [15] 463 Case Study: Chrome 465 As recently as February 2020 a security vulnerability in older 466 versions of the Chrome browser allowed for the exploitation of 467 user's computers in a zero day attack scenario. Though the 468 vulnerability has been fixed through updates, a number of attacks 469 have taken place. Number unknown to date. [16] 471 Design Considerations: Many mitigations to these attacks rely on 472 endpoint security, such as patching - possibly explaining the rise 473 in this attack trend. However, protocol designers should be aware 474 of other mitigations to avoid designing them out, such as web- 475 traffic filtering and web-traffic encryption. 477 2.9. Malware-free Attacks 479 Attack Description: According to Crowdstrike's 2020 Cyberattack 480 report, for the first time since starting the report, malware-free 481 attacks accounted for 51% of all global cyberattack types. A 482 malware free attack is one that does not employ a malicious file 483 or fragment a computer disk. Instead, stolen credentials, running 484 legitimate tools or executing code from memory are all possible 485 types of attacks. Malware-free attacks are more difficult to 486 detect unless actively looking for cyberattacks in systems. 488 Case Study: TBD 490 Protocol Considerations: Building in resilience to malware-free 491 cyber attacks. Allow for search and notification of potential 492 cybersecurity issues as a preemptive measure. 494 2.10. Real-world effects 496 Attack Description: Alteration of data on a remote system, e.g. an 497 Industrial Control System, to achieve an effect that would, for 498 example, change the delivery of products in a supply chain or 499 change the characteristics of a product during production may 500 cause harm to people using that product intended for one use, but 501 designed to malfunction. 503 RDP allows cyber attacks to access the Internet-facing parts of an 504 ICS from where they may able to move to the operational 505 environment. 507 Case Study: Industrial Control Systems or TBD [17] 509 Protocol considerations: Industrial Control Systems are expensive 510 and are often patched in slower-time, and a defence-in-depth 511 approach is advocated; endpoint security alone is not enough. 512 Additional considerations include the ability to real-time monitor 513 easily, and to note that internet protocols are used for high- 514 threat systems. 516 2.10.1. Data Exfiltration 518 Attack Description: Data exfiltration is a frequent outcome of 519 compromise, where data is taken from a system by an unauthorised 520 user. This information leakage includes customer data (often in 521 high-profile breaches) or theft of IPR material from enterprises. 522 Exfiltration of data can be: 524 1) High-volume, where the attacker expects to detected or wants to 525 operate quickly. 526 2) Low-and-slow, where data is siphoned off at a low level for a 527 long period of time, in the hope of avoiding detection. 528 Case study: Equifax 530 In March 2017, attackers searched the web looking for 531 vulnerabilities that were known, but had not been fixed. These 532 attackers targeted the dispute resolution portal at a credit 533 ratings company called Equifax in the US. The hackers used a 534 vulnerability in Apache Struts which allowed access and 535 exfiltration of personal information on the portal. [18] 537 Design Considerations: Endpoints can tag/watermark content so that 538 leaked data can be identified and possibly stopped at a gateway, 539 or at least traced back to the user that leaked the material. For 540 this, protocol data could include a protective marking field that 541 is visible to a firewall, even if the content is encrypted. 543 Another issue to consider is the detection of data exfiltrated 544 through covert channels. Protocols should be designed with this 545 abuse in mind, with designers minimising existence and size of 546 covert channels. 548 2.10.2. Identity Theft 550 Attack Description: Fraud committed from the theft of personal 551 identifiable information - such as bank details, home address and 552 date of birth - strengthened by the massive digitisation and 553 centralisation of people's personal data. Credential stealing and 554 credential stuffing are two of many ways to obtain personal data. 556 Case Study: JP Morgan Chase 558 In 2014 JP Morgan Chase had over 83 million accounts compromised 559 and hackers made over $100 million through fraud and identity 560 theft. To date it is one of the largest data breaches in 561 history.[19] 563 Design Considerations: Provision and protect a way that allows 564 breaches of personal data to be detected in real-time and stopped. 565 Use strong authentication to secure access. 567 2.11. Table of Attacks 569 Table to be added in the next version of this draft. 571 3. Defensive Measures 573 Defensive measures broadly fall into three classes: 575 1. prevention of attacks - stopping most attacks from achieving the 576 attacker's objectives, i.e. from taking hold on a system, 577 network or endpoint. 578 2. detection of attacks - how attacks are detected quickly, 579 efficiently, with a high-degree of confidence and accuracy. 580 3. mitigation of attacks - once an attack happens, the capability 581 to stop the damage done by the attack, e.g. preventing the 582 spread of the compromise within an organisation, limiting the 583 data exfiltrated or stopping the attack from being replicated 584 globally on unaffected systems. 586 All defences listed in this section relate to one or more attacks 587 listed in Section 2. 589 For each type of defensive measure, we categorise the method as 590 prevention, detection, mitigation or a combination of these; we 591 link to the type of attack in Section 2 that is prevented; and we 592 describe how the defence works. 594 Considerations for protocol designers (in relation to each 595 defensive measure) are also listed throughout, and summarised in 596 Table 3.15 to provide an easier reference. 598 3.1. Response to Attacks 600 Defence Type: Mitigation 602 A system can be designed to ensure availability under attack, e.g. 603 by segregating classes of devices on a network, or considering 604 system architecture. Components that are under attack have a 605 channel for reporting that attack that is distinct from the 606 channel used for launching the attack. 608 Case Study: TBD 610 Design Considerations: Design protocols that allow such 611 segregation in architecture in a simple and scalable way. Design 612 protocols for reporting of attacks that use channels that are less 613 susceptible to attacks. 615 3.2. Recovery from Attacks 617 Defence Type: Prevention 619 If organisations and individuals assume that a security breach 620 will happen then defences will be optimised in or to allow for a 621 quick response and minimal impact. 623 For example, encrypt data when stored so that if it is stolen, the 624 attacker can't decrypt it. For another example, if data is backed 625 up regularly, then the threat held by ransomware is minimised. 627 Case Study: TBD 628 Design Considerations: Design protocols that can deliver encrypted 629 payloads to capable endpoints. Practice strong separation of the 630 keys used to encrypt data at rest from the data, with high levels 631 of protection applied to the keys. Design protocols that allow for 632 regular, automatic backup of data minimising the amount of user 633 interaction required. 635 3.3. Reporting of Attacks 637 Defence Type: Detection 639 Logging is an important feature. Multiple logs allow cross- 640 referencing and establishing truth data, so it is important to 641 provide logging in multiple places, to detect false reporting by 642 compromised endpoints or networks. Logging allows strengthened 643 forensics, which reduces the risk of similar attacks in future. 644 Forensic analysis of logs makes it easier to detect and locate 645 attacks, so can be a deterrent to attackers. For this same reason, 646 malicious manipulation of logs to prevent detection is an 647 attractive attacker objective. 649 Reliable logging helps to find the source of an attack, its spread 650 and what devices and networks have been compromised. Unreliable 651 logging can slow attempts to mitigate it. 653 Case Study: TBD 655 Design Considerations: How a protocol might help/hinder the 656 ability to troubleshoot or have separate logging in multiple 657 places (for truth data), allow for reliable logging across points 658 in a network. 660 3.4. Sinkholing 662 Defence Type: Mitigation 664 Mitigation against where a DDoS attack has already been launched, 665 to prevent a successful attack outcome (i.e. a denial of service). 667 Case Study: TBD 668 Design Considerations: Ability to determine whether a connection 669 is likely malicious or not, and filter out malicious connections 670 at speed. Ability to reliably determine the source of a connection 671 and verify that it is accurate and from an address authorised to 672 make the connection. 674 3.5. Firewalls/Middleboxes/Gateways 676 Defence Type: Prevention and detection 678 Firewalls, middleboxes and gateways can be used to inspect traffic 679 and make decisions whether to allow, block or modify data content. 680 These decisions can be based on simple IP address / port / 681 protocol rules, or on deep packet inspection of individual data 682 packets, or use artificial intelligence / machine learning 683 techniques to make more complex decisions based on analysis of 684 traffic over a period of time. 686 Case Study: TBD 688 Design Considerations: Protocols should allow for selective and/or 689 minimally intrusive analysis, balanced against the need to protect 690 the privacy of the user content and any personally identifiable 691 information. Minimally intrusive analysis could include the 692 ability to block traffic that it associated with known insecure 693 protocols or ports, known malicious activity or known malicious 694 users. A protocol that makes all traffic look essentially 695 indistinguishable forces the firewall into making an "all-or- 696 nothing" decision, which would be ineffective for defending 697 against attacks if it is still to allow some communications. 699 A firewall should not be able to undetectably modify traffic; 700 where it is necessary to modify traffic to prevent a threat, the 701 modification should be apparent to the receiver. 703 3.6. Intrusion Prevention System (IPS) and Intrusion Detection System 704 (IDS) 706 Defence Type: prevention and detection 707 These systems provide the abilities to prevent and detect malware 708 infection, vulnerability exploits, and lateral movement on 709 compromised networks and endpoints. 711 Signatures for bad content - IPS/IDSs don't work on traffic if 712 attacks have legitimate content but bad intent, e.g. DDoS. 713 However, the IPS/IDS may detect the malware that compromised the 714 endpoint to launch the DDoS attack. 716 IDSs are passive systems that scan traffic and report to the 717 traffic owner on threats; IPSs are inline, taking an active role 718 and making automated decisions and applying these actions to 719 traffic. 721 Case Study: TBD 723 Design Considerations: For IDS, protocols should allow for logging 724 of data relating to the connection, which may include any or all 725 of IP addresses, ports, protocols and payloads, balanced with the 726 requirement to protect privacy of user data. For IPS, protocols 727 should allow for signature/statistical anomaly detection, the 728 ability to selectively drop traffic and respond at efficient scale 729 and speed. 731 3.7. Upstream Filtering 733 Defence Type: Mitigation 735 Content is filtered through a "scrubbing" centre to forward only 736 good traffic. This is provided as a service by e.g. Cloudflare, 737 Akamai.[ 739 Case Study: TBD 741 Design Considerations: allow for forwarding of traffic on this 742 scale through robust internet infrastructure. Attack traffic 743 should be easily recognisable through its externals, e.g. packet 744 destination, traffic flow patterns, protocol type, signatures. 745 This relies on being able to filter at speed and weed out 746 malicious connections. 748 3.8. Malicious Domain Monitoring and Takedown 750 Defence Type: to detection and prevention. 752 We wish to detect the existence and determine the intent of 753 malicious domains as soon as possible, and remove or deny access 754 to them before most harm can be done. For example, removal of 755 malicious domains that are created to receive clicks from phishing 756 emails; if the domain can be removed before most emails are read, 757 the links won't work and the harm is reduced with no effort from 758 the user. 760 Takedown services can levy copyright protections to request 761 takedowns. Combined with techniques to use email authentication, 762 these proactive measures rather than reactive ones have had 763 considerable effect in UK government efforts to minimise phishing 764 [20] 766 Case Study: TBD 768 Design Considerations: Protocols should allow users to determine 769 the identity of the domain that they are connecting before they 770 are exposed to data from that domain. Protocols should provide a 771 means for users to verify the authenticity of a connection to a 772 domain. Protocols should minimise the opportunities for users to 773 confuse malicious domains with legitimate domains. Protocols 774 should provide a method for legitimate domain owners to recognise 775 attempts by a malicious domain to masquerade as the legitimate 776 domain. 778 3.9. Filtering Type 780 Defence Type: Prevention and mitigation. 782 Filtering of traffic can be done according to black lists of 783 addresses, content types or signatures specified by malware threat 784 feeds. Filtering can also be done using statistical and machine 785 learning techniques, e.g. for spam. Filtering can prevent malware 786 infection or mitigate it by stopping the further spread of 787 malware. 789 Case Study: TBD 790 Design Considerations: Protocols should allow for selective and/or 791 minimally intrusive analysis of traffic in order to determine 792 whether to allow data through the filter. Malware may try to shape 793 malicious traffic to appear like benign traffic, so protocol 794 specifications should minimise the opportunity for malicious 795 payloads to masquerade as legitimate payloads. For example, 796 encrypting all data so that it looks the same, then you're 797 removing any discriminating features that filtering systems could 798 use to base their decisions on. 800 Protocols therefore should be designed with an awareness that 801 hiding features that expose malicious traffic as malicious will 802 enable malicious payload delivery, therefore it would be response 803 to work out which, and preserve features that, would still allow 804 effective detection. 806 3.10. Implementation of Trust 808 Defence Type: Prevention. 810 Content is filtered so that data from non-trusted sources is 811 filtered out before it arrives. TBD 813 e.g. DMARC/SPF to prevent phishing, secure authenticated log-in, 814 enforcement of PKI certificate validity on TLS connections etc. 816 Case Study: TBD 818 Design Considerations: Protocols should be resilient and should 819 not prevent informed users from opting into services that 820 protected delivery of only trusted content. Protocols should 821 allow for verification of data source and integrity. Protocols 822 should include policies for handling and management of non-trusted 823 data. 825 3.11. Endpoint Security 827 Defence Type: prevention, detection and mitigation. 829 Security hygiene, like regular patches to fix the latest 830 discovered software vulnerabilities, form an important part of the 831 security of any system. However, some endpoints are unable to 832 maintain their own security and can introduce vulnerabilities 833 themselves. 835 Case Study: TBD 837 Design Considerations: Consider whether the protocol data is 838 available for inspection by the endpoint security solution. At 839 what point in the protocol stack is protected data decrypted and 840 can be analysed or blocked by the endpoint security? 842 3.12. Email Anti-spoofing Measures 844 Defence Type: Prevention 846 These are preventive measures designed to prevent and reduce 847 phishing emails. 849 Configure anti-spoofing controls on a domain you own to prevent 850 email spoofing, such as Domain-based Message Authentication, 851 Reporting and Conformance (DMARC), Sender Policy Framework (SPF) 852 and Domain-Keys Identified Mail (DKIM). [22] 854 Case Study: TBD 856 Design Considerations: Allow for strong authentication of source 857 of user data. Policies for delivery of non-authenticated data. 859 3.13. Social/User Interface Interventions 861 Defence Type: Prevention and detection. 863 Since phishing is a social engineering type of attack, there 864 should be education and training for people to prevent phishing. 865 Futhermore, presenting a user with a photo on log-in to prevent 866 logging into a phishing domain and two factor authentication (2FA) 867 are some of the mitigation strategies. Also reporting of abnormal 868 behaviour/user mistakes should be encouraged and failed log-in 869 attempts should be displayed to the user. Finally appropriate 870 password policies should be in place. 872 Case Study: TBD 873 Design Considerations: Protocols should support secure 874 communication of security-critical information to and from the 875 user interface; this could include passwords, biometric 876 information, other credentials, user activity logs, PKI 877 certificate properties and validity, origin authentication using 878 auxiliary information (such as identifying phrases or photos). 880 3.14. Detection of Exfiltration and Data Leakage 882 Defence Type: detection and mitigation 884 When a compromise of a network has occurred, either by malware 885 infection or insider threat, it is important to be able to detect 886 attempts to exfiltrate data from the network and stop exfiltration 887 as soon as the leak has been reliably confirmed. 889 Detection of exfiltration can be through packet metadata analysis, 890 statistical analysis of data collected over a period of time, or 891 content inspection on unencrypted data. 893 Case Study: TBD 895 Design Considerations: Encryption of data can make inspection of 896 data at a gateway for malicious exfiltration less reliable. 898 Statistical properties of traffic may be used to detect 899 exfiltration occurring over an extended period of time; it would 900 be very bad for attack defence in general if protocols sought to 901 hide patterns of traffic that are be indicative of exfiltration. 902 If data is watermarked to indicate the origin of protected 903 content, protocols should not destroy the watermarks. Protocols 904 should minimise covert channels that can be used for the 905 exfiltration of data by malware. 907 3.15. Table of Defences 909 Table to be added in the next version of this draft. 911 4. The Overall Security Picture 913 Deployments of protocols vary greatly and use cases show the 914 variety and diversity of design, development and implementation of 915 protocols; There are varying levels of risk and a variety of 916 threats being more likely than others depending on context in 917 which the protocol is deployed. Therefore, some attacks and 918 defensive measures outlined in the above sections may be more 919 frequent than others. For example, an enterprise might consider 920 customer data exfiltration a greater threat than its resilience to 921 zero-day vulnerability exploitation, but an individual user might 922 be more concerned with their protection against phishing than with 923 seeing all traffic leaving their network. 925 For protocol designers, it is important that a protocol's impact 926 on different attack defence cases across the layers of the 927 internet should be considered when designing the protocol. 929 Defence against malicious attacks can be either improved or 930 weakened by the design features of protocols. Designers should 931 acknowledge that including attack prevention, detection and 932 mitigation is essential in protocol development. 934 There is no one-size-fits-all approach for protocol deployment; 935 each specific implementation and use case should be considered 936 separately, as deployments require a mature a whole-system 937 security view. This allows for a system wide analysis so that the 938 security of the protocol isn't the only security considered. 940 For example, a user with a client that runs DoH might feel 941 completely secure, as the information is encrypted and you have a 942 private connection to the DNS resolver. However, this could 943 actually bypass defensive filtering protections, without the 944 protection afforded blocking of malicious domains. Further, unless 945 DNSSEC is also deployed, you have no trust that the resolver is 946 returning the correct results. 948 Another popular example is the padlock in most browsers that tells 949 users they have a secure HTTPS connection. Users can conflate the 950 meaning of the padlock, assuming that use of HTTPS automatically 951 confers a legitimate connection - even if the domain being 952 connected to is fake or malicious. 954 5. Attack Defence in Security Considerations 956 The impact of new protocols on existing systems that defend 957 against malicious attacks is not systematically considered in the 958 Security Considerations sections in RFCs. This draft is the first 959 step in developing a reference guide to enable a systematic and 960 consistent assessment across different protocols with respect to 961 attack defence. 963 Hence, protocols should be assessed against a range of attacks and 964 detections methods, such as those attack types listed in the Table 965 in Section 2 and those defensive measures listed in the Table in 966 Section 3, as a standard consideration in all protocol design, and 967 to make the potential impacts clear to deployers. 969 When writing the Security Considerations for a protocol, protocol 970 designers should consider known attacks and prevention, detection 971 and mitigation methods. As the type, kind and characteristics of 972 attacks grow in complexity, it is important that protocol 973 designers take into account attack types and mitigation strategies 974 into their designs. In fact this should be backed into the 975 security considerations from the start. This draft RFC is a 976 helpful guide to those considerations. 978 6. Security Considerations 980 This document is entirely about Internet security and is an input to 981 the IAB Model T work. 983 7. IANA Considerations 985 This draft has no actions for IANA. 987 8. References 989 8.1. Normative References 991 [1] https://www.zdnet.com/article/new-silex-malware-is-bricking- 992 iot-devices-has-scary-plans/ 994 [2] RFC 7252 Shelby, Z. et al, "The Constrained Application 995 Protocol (CAP)" RFC 7252, June 2014. 997 [3] https://www.zdnet.com/article/the-coap-protocol-is-the-next- 998 big-thing-for-ddos-attacks/ 1000 [4] https://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos- 1001 attack-cause-outage-status-explained 1003 [5] https://www.darkreading.com/endpoint/91--of-cyberattacks- 1004 start-with-a-phishing-email/d/d-id/1327704 1006 [6] https://www.wired.com/2016/01/everything-we-know-about- 1007 ukraines-power-plant-hack/ 1009 [7] https://developers.facebook.com/docs/certificate-transparency/ 1011 [8] RFC 6962 Laurie B., et al, "Certificate Transparency" RFC 1012 6962, June 2013. 1014 [9] https://techcrunch.com/2019/05/12/wannacry-two-years-on/ 1016 [10] https://www.cnbc.com/2017/07/31/new-anthem-data-breach-by- 1017 contractor-affects-more-than-18000-enrollees.html 1019 [11] https://www.zdnet.com/article/for-two-hours-a-large-chunk-of- 1020 european-mobile-traffic-was-rerouted-through-china/ 1022 [12] https://www.internetsociety.org/blog/2018/04/amazons-route-53- 1023 bgp-hijack/ 1025 [13] https://www.enisa.europa.eu/topics/threat-risk- 1026 management/threats-and-trends/enisa-threat-landscape 1028 [14] https://www.welivesecurity.com/2020/01/09/mozilla-rushes- 1029 patch-firefox-zero-day/ 1031 [15] https://www.forbes.com/sites/emilsayegh/2020/02/12/more-cloud- 1032 more-hacks-pt-2/#7c0c47d669b3 1034 [16] https://threatpost.com/google-patches-chrome-browser-zero-day- 1035 bug-under-attack/153216/ 1037 [17] https://www.computerweekly.com/news/252446423/Industrial- 1038 controls-systems-a-specialised-cyber-target 1040 [18] https://www.cnet.com/news/equifaxs-hack-one-year-later-a-look- 1041 back-at-how-it-happened-and-whats-changed/ 1043 [19] https://www.wired.com/2015/11/four-indicted-in-massive-jp- 1044 morgan-chase-hack/ 1046 [20] https://www.ncsc.gov.uk/guidance/phishing 1048 [21] http://www.circleid.com/posts/20170214_blocking_a_ddos_upstrea 1049 m/ 1051 [22] https://www.ncsc.gov.uk/collection/email-security-and-anti- 1052 spoofing 1054 9. Acknowledgments 1056 This document was prepared using 2-Word-v2.0.template.dot. 1058 Authors' Addresses 1060 Dominique Lazanski 1061 Last Press Label 1062 London, UK 1064 Email: dml@lastpresslabel.com