idnits 2.17.1 draft-lazanski-protocol-sec-design-model-t-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security Considerations for Protocol Designers' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 142 has weird spacing: '...cluding attac...' == Line 320 has weird spacing: '... by the attac...' == Line 691 has weird spacing: '...crypted payl...' -- The document date (July 6, 2021) is 997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '10' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1220, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 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 July 6, 2021 4 Expires: January 6, 2022 6 Security Considerations for Protocol Designers 7 draft-lazanski-protocol-sec-design-model-t-03.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 July 7, 2021. 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. This 51 document follows on from the way forward outlined in draft-lazanski- 52 users-threat-model-t-03. These considerations both supplement and 53 support the work on threat models. They can be used as an aid to 54 analyse protocol design choice and in turn to help combat threats 55 and defend users of these protocols and systems against malicious 56 attacks. 58 First, we list well-known classes of attacks that pose threats, with 59 relevant case studies and descriptions. Next, we give a list of 60 defence measures against these attacks to be considered when 61 designing and deploying protocols. Naturally, deployments of 62 protocols vary greatly between use cases; therefore, some attacks 63 and defensive measures outlined may require more consideration than 64 others, dependent on use case. 66 This RFC can be used by protocol designers to write the Security 67 Considerations section in an RFC. The impact on attack defence of a 68 protocol should be considered in multiple use cases across the 69 multiple layers of the internet. Defence against malicious attacks 70 can be improved and it can be weakened by design features of 71 protocols. Designers should acknowledge the role of protocols in 72 attack prevention, detection and mitigation; this document aims to 73 be a useful guide in doing so. 75 Table of Contents 77 1. Introduction...................................................3 78 2. Attacks........................................................4 79 2.1. Endpoint Compromise.......................................4 80 2.2. Network Compromise........................................6 81 2.3. Denial of Service (DoS) and Distributed Denial of Service 82 (DDos).........................................................7 83 2.4. Phishing..................................................8 84 2.5. Malware Infection.........................................9 85 2.6. Insider Threat...........................................10 86 2.7. Hijacking Traffic........................................10 87 2.8. Web-based Attacks........................................11 88 2.9. Malware Free Attacks.....................................12 89 2.10. Table of Attacks TODO...................................12 90 3. Real World Impacts............................................12 91 3.1. Remote Data Alteration...................................12 92 3.2. Data Exfiltration........................................13 93 3.3. Identity Theft...........................................13 95 4. Defensive Measures............................................14 96 4.1. Response to Attacks......................................14 97 4.2. Recovery from Attacks....................................15 98 4.3. Reporting of Attacks.....................................15 99 4.4. Sinkholing...............................................16 100 4.5. Firewalls/Middleboxes/Gateways...........................16 101 4.6. Intrusion Prevention System (IPS) and Intrusion Detection 102 System (IDS)..................................................17 103 4.7. Upstream Filtering.......................................18 104 4.8. Malicious Domain Monitoring and Takedown.................18 105 4.9. Filtering................................................19 106 4.10. Implementation of Trust.................................20 107 4.11. Endpoint Security.......................................20 108 4.12. Email Anti-spoofing Measures............................21 109 4.13. Social/User Interface Interactions......................21 110 4.14. Detection of Exfiltration and Data Leakage..............22 111 4.15. Misuse of the Domain Name System........................22 112 4.16. Attack and Defense Table TODO...........................23 113 5. The Overall Security Picture..................................23 114 6. Attack Defence in Security Considerations.....................23 115 7.Security Considerations........................................24 116 8. IANA Considerations...........................................24 117 9. Conclusions...................................................24 118 10. References...................................................24 119 10.1. Normative References....................................24 120 11. Acknowledgments..............................................27 122 1. Introduction 124 This draft aims to give a non-exhaustive set of attack defence 125 considerations for protocol designers and implementers to consider 126 when designing and deploying protocols. These considerations are 127 focused on informing the design of protocols so that protocols may 128 better defend users and systems from malicious attacks.[1] This is 129 essential information and should be considered for protocol 130 development. No protocols should be finalised without security 131 guidance just as no protocols should be designed without privacy 132 considerations. This document is a useful and necessary reference 133 and it is the intention of the authors that the IETF makes full use 134 of all the security expertise in its community through the updating 135 of this document. 137 For protocol designers, it is important that a protocol's impact on 138 different attack defence cases across the layers of the internet 139 should be considered. Defence against malicious attacks can be 140 either improved or weakened by the design features of protocols. 142 Designers should acknowledge that including attack prevention, 143 detection and mitigation is essential in protocol development. 145 In Section 2, we list some of the many attacks that are a malicious 146 presence on the internet today, with their methodologies, notable 147 case studies and attack outcomes. This is not, and can never be, an 148 exhaustive list; threats have been chosen based on their frequency 149 and regularity, likelihood of occurring, and impact on victims. In 150 Section 3, we describe some real world impacts following up on some 151 of the attacks listed in Section 2. 153 In Section 4, we document some known popular current defensive 154 practice, giving a list of defence measures that can and are widely 155 used against attacks from Section 2. These current practices should 156 be considered when designing and deploying protocols to avoid 157 obsoleting them unwittingly. Other possible defensive measures for 158 protocol designs are included where relevant. 160 Section 5 outlines the motivations and use of this draft, and 161 Section 6 suggests the methodology by which considerations outlined 162 in this draft may be consistently thought through in protocol 163 design. 165 2. Attacks 167 In this section we outline some attack types that are well-known in 168 industry and in public. For each attack type, we give examples of 169 how this attack is carried out, case studies of notable attacks 170 where appropriate, and the outcomes that attackers are trying to 171 achieve. Some considerations for protocol designers in relation to 172 each specific attack are also listed. 174 Throughout this draft the aim to use common industry references, 175 taxonomies and terminology for types of attack to avoid confusion. 176 Considerations for protocol designers and deployments in each 177 section are summarised in a table in Section 2.11 for ease of 178 reference. 180 2.1. Endpoint Compromise 182 According to IDC 70% of successful cybersecurity breaches originate 183 at the endpoint as their initial point of contact and penetration. 184 Attack Description: Endpoint compromise is when a malicious an 185 unauthorised attacker has control of an endpoint beyond their access 186 and privilege level. Endpoint compromises not yet been mentioned in 187 RFC 3552. However, they may be achieved through many attack vectors, 188 such as: stealing legitimate credentials that give access to the 189 endpoint, malware infection, a phishing attack, and insider threats. 191 Attackers have multiple motivations to compromise an endpoint, some 192 of which we list here and include: to exfiltrate personal or 193 intellectual proper data on the endpoint, to perform reconnaissance 194 for other malware to deploy, to move laterally around a network, to 195 harvest legitimate credentials, for financial gain, or for 196 reputational or political reasons. See draft-lazanski-users-threat- 197 model-t 199 When an endpoint is compromised, it is common practice to utilize a 200 communication channel (either a new one is opened or an existing one 201 is leveraged) to exfiltrate data, communicate to the command centre, 202 explore the network or propagate to other endpoints. Such a 203 communication channel would typically attempt to "look like" a 204 routine connection to a server or a peer. Furthermore, malware often 205 disables any protection, if any protection exits, on the endpoint as 206 part of its initial infection process allowing this to happen 207 quickly. 209 Case Study: Silex Malware 211 In June 2019 a strain of malware was found that wipes the firmware 212 of an IoT device. It does this by using known credentials for 213 logging into IoT devices and completely wipes the system and removes 214 the network configuration. It impacted thousands of devices by 215 rendering them useless. [2] 217 Protocol Design Considerations: A protocol design consideration 218 against this attack would therefore preserve prevention mechanisms 219 and allow for the detection of the abnormality of connections on 220 host systems. This allows for network-based defence in depth. 221 Abnormalities might include unusual traffic flow to a server, 222 attempting to contact many IP addresses (scanning), or beaconing 223 behavior patterns, which is when it 'calls home' at regular 224 intervals. 226 This is just one example of potential endpoint compromise situations 227 and subsequent mitigations which can be considered and included in 228 protocol development. More detailed consideration of endpoints, 229 especially with respect to endpoint-only security solutions can be 230 found in Capabilities and Limitations of an Endpoint-only Security 231 Solution draft-taddei-smart-cless introduction-02 and a related 232 taxonomy, Endpoint Taxonomy for CLESS draft-mcfadden-smart-endpoint- 233 taxonomy-for-cless-01 which is a taxonomy of specific endpoint 234 equipment, devices and applications. These drafts both highlight 235 important points. In the draft-taddei-smart-cless-introduction-02 236 researchers found that 5% of incidents were only detected by network 237 based systems while the rest was detected by endpoint security. This 238 is why the reliance on network-based protocols shouldn't be the only 239 focus in protocol design. 241 2.2. Network Compromise 243 Attack Description: Network compromise is where a malicious and 244 unauthorised attacker has presence on or control of part of a 245 network beyond their privilege level. An attacker may compromise a 246 network to achieve any one of many objectives, such as: to obscure 247 endpoint compromise, to move laterally around a network undetected, 248 to perform reconnaissance, to gain information or data and to 249 escalate privilege. 251 Case Study: NotPetya 253 The NotPetya virus initiated a series of global, sustained attacks 254 in 2017 which originated in the Ukraine, but spread rapidly. A 255 variant of Petya ransomware virus, NotPetya targets Windows based 256 systems in order to infect the master boot loader which in turn 257 encrypts the hard drive's file system. However, unlike Petya, 258 NotPetya spreads on its own through network compromise and encrypts 259 everything. Also, it looks like Petya ransomware, but is in fact not 260 ransomware (hence the name NotPetya). Though the attack was global, 261 the global shipping and logistics company Maersk lost their entire 262 IT system which impacted their business. The estimated loss to their 263 business was around 300 million Euros.[3] 265 Protocol Design Considerations: 267 If there is an unauthorised attacker accessing a passive inspection 268 point in the network, a protocol design consideration would be to 269 apply cryptography for confidentiality protection. 271 A protocol design consideration for an attacker modifying contents 272 of data packets on the network would be to apply cryptography for 273 integrity protection. 275 Finally, if an attacker engages in re-routing, re-ordering, 276 replaying, delaying or dropping data on the network, which is 277 arguably less well-handled by existing Internet transport protocols, 278 then protocol design considerations would include development of 279 strong sender authentication, integrity checks over whole sessions 280 not just individual packets, replay detection, and out-of-order 281 packet detection. 283 2.3. Denial of Service (DoS) and Distributed Denial of Service (DDos) 285 Attack Description: Denial of Service (DoS) attacks intend to 286 prevent any service and service delivery. Attackers usually select a 287 high-profile, online web target that they intend to make unavailable 288 in the short-term. Distributed DoS attacks utilise multiple 289 compromised endpoints to distribute the DoS attack, removing the 290 possibility of blocking the attack by removing the single device 291 launching the attack. 293 DDoS attacks can occur: 295 1) at the network layer, known as a Layer 2 DDoS attack, launched 296 via malformed packets, flooding or spoofing. 298 2) at the application layer, known as a Layer 7 DDoS attack, 299 launched via Ping of Death, HTTP floods, XDoS. 301 3) a combination of both network and application services, resulting 302 in amplification and reflection attacks. 304 Common DDoS Attacks include: 306 1) HTTP POST attack in which an attack floods an HTTP POST or GET 307 request by exploiting an open connection and sending data to 308 connected web servers, typically over a period of time. This takes 309 place at Layer 7 and is successful because it is an asymmetric 310 attack which leaves the connection open for a long duration. An 311 update would be required to fix this issue. 313 2) ICMP flood or ping flood is when an attacker takes down a 314 computer by sending a large number of request packets. This is 315 accomplished by knowing the destination IP address and sending the 316 requests. 318 A successful DDoS attack, where the service is inaccessible for a 319 period of time, achieves the attacker objective include degradation 320 of service. In some cases, this may be used by the attacker as an 321 opportunity for extortion. 323 Case study: Dyn attack, Mirai 325 The Mirai botnet was first identified in 2016. The Mirai botnet as 326 well as variants target and infect Internet of Things devices. Those 327 infected devices scan the Internet for IP addresses of other 328 Internet of Things devices, thus creating a multiplication of IoT 329 devices which are infected. Though the bot still exists in various 330 forms, the most serious attack took place on 21 October 2016 when 331 the Domain Name System (DNS) provider Dyn was attacked by DDoS using 332 a coordinated system of infected IoT devices. Much of the Internet 333 was unreachable after three attacks occurred during the same day. 334 The decentralised nature of the Internet helped to mitigate the 335 severity of attack and the attack was eventually resolved on that 336 day. However, the sheer size and scale of the attack is still viewed 337 as one of the biggest attacks on the Internet to take place.. [4] 338 Changes in the threat landscape, including risk of consolidation and 339 IoT changes could upend these mitigations in future and promote 340 over-reliance on one single security solution rather than a 341 decentralized, resilient network. 343 Protocol Design Considerations: Some people take the attitude of 344 "DDoS attack? Welcome to the internet" and this is the approach of 345 RFC 3552 as well. However, the use of the Internet and data that 346 travels over it has increased exponentially. Protocol designers 347 should be aware of potential issues that help DDoS attacks, such as: 348 CoAP flooding, protocols that permit mass unscheduled deliveries, 349 provision of the ability for an attacker to mask e.g. IP addresses, 350 provision of the ability to amplify, a lack of sender 351 authentication, a long time open request and an inability to filter 352 at scale.[5] Assessment of protocol for abuse and DoS amplification 353 should be a part of the security assessment during the design 354 iteration process. 356 2.4. Phishing 358 Attack Description: A phishing attack is where an unsolicited 359 message with malicious content is received. Malicious content could 360 be either in the message itself (email, messages), or directing the 361 user to a malicious domain. Varieties of phishing exist, based on 362 difference social engineering approaches, including: spear phishing, 363 clone phishing and whaling. Phishing is cited as the initial attack 364 vector for 91% of reported malicious attacks.[6] 366 For a phishing attack to succeed, the user has to be unwittingly 367 duped into an action, where they can't be assumed to have the 368 knowledge to check their action. For example, users can be confused 369 by domain names that render almost identically but are different at 370 a binary level, such as internationalised domain names. Also users 371 may see that a sender of an email to them is someone they know, but 372 not realise that the email address is different. 374 Case Study: Ukrainian Power Grid Attack 376 The cyber attack on the Ukrainian Power Grid took place on December 377 23, 2015. It was the first known cyber attack on a power grid. 378 Around 250,000 individual customers were impacted. DDoS telephone 379 attacks also prevented people from calling help centres to report 380 the lack of electricity. All of this began with a spear-phishing 381 campaign initiated 9 months before that was eventually successful. 382 [7] 384 Protocol Design Considerations: design protocols with strong 385 authentications and identification/proof of ownership of domains 386 required. Provide users with means to assist checking their actions 387 are safe (or automate the means that can check a user's actions). 389 Network infrastructure should be able to detect whether data has 390 strong authentication and policies can be specified for handling 391 unauthenticated data (e.g. SPF, DMARC). One defensive measure 392 employed by domain owners to check for unauthorised usage of 393 identical or similar domain names is to use Certificate Transparency 394 logs [8] with automated notifications to the domain owner where 395 domains with 'close' domain names log a certificate, indicating a 396 malicious spoofed domain and therefore access is denied. [9] 398 2.5. Malware Infection 400 Attack Description: Malware is one attack vector used to achieve 401 network or endpoint compromise. As Lockheed Martin's Killchain 402 describes,[10] there are many interactions between malware and 403 protocols which allows for infection and attacks. In the case of 404 Lockheed Martin there are seven distinct stages each with protocols 405 associated with them. Malware comes in many different strains and 406 flavours: exploit kits, ransomware, viruses, trojans, worms, 407 rootkits and more. The attack outcomes are incredibly varied too - 408 attackers might want to recruit bots, deploy that leaves behind 409 physical damage, steal IPR material for corporate espionage, 410 exfiltrate of credentials to gain accesses elsewhere in the system, 411 perform reconnaissance for a later attack, or make some financial 412 gains. 414 Case Study: WannaCry 416 In 2017, a ransom attack was launched by using a cryptoworm 417 targeting computers running the Microsoft operating system. The 418 attack encrypted person and computer data and then asked for a 419 ransom in order to unencrypt the data. The attack was eventually 420 stopped by a 'kill switch' that was discovered. DNS monitoring 421 detected the infection, but not without infecting 200,000 computers 422 first.[11] 423 Protocol Design Considerations: As malware is often carried to an 424 endpoint by an Internet protocol, there are considerations for 425 protocol designers. Moreover, once it's arrived at its destination, 426 malware needs to use protocols for discovery of peers, for C2, for 427 exfil. Therefore, such connections and the features from those 428 protocols can be used to detect, track and mitigate outbreaks in 429 real-time. For example, SMTP headers can detect malware spreading 430 through e-mail, and other protocol connections can show the lateral 431 movement of malware through a network. 433 TODO: Details for detection for protocol design. 435 2.6. Insider Threat 437 Attack Description: This attack involves social manipulation of an 438 authorised person so that they knowingly attempt malicious actions, 439 using their authorised privileges, credentials and accesses to 440 achieve nefarious attacker objectives. This is different social 441 engineering to phishing (Section 2.4), where the user is unwitting 442 to their actions. 444 The insider themselves might be the sole attacker, for various 445 reasons - ranging from a desire to gain notoriety or to inflict 446 deliberate harm on their employer. If the insider is manipulated by 447 another attacker, their role is likely to provide information only 448 accessible by an outsider, to enable further attacks. Eventual 449 attacker outcomes are to gain access to the network or endpoints, 450 potentially for insider trading, fraudulent transactions or IPR 451 theft. 453 Case Study: Anthem 455 A contractor working for a consultancy employed by Anthem stole 456 18,500 individual files with personal details and used them for 457 personal gain.[12] 459 Protocol Design Consideration: There is therefore a need for 460 authorization to be a design consideration for protocols, and also 461 provisioning the ability to create and manage logs, and to create 462 audit trails for document access. 464 TODO: Fill in authorization process and abnormality detection for 465 protocol design. 467 2.7. Hijacking Traffic 469 Attack Description: Border Gateway Protocol hijacking, or BGP 470 hijacking is when a group of IP addresses are taken over maliciously 471 by routing table manipulation and corruption. BGP hijacking is 472 fairly common and is a frequent attack used against cryptocurrencies 473 because hosting centralization makes it particularly vulnerable to 474 attacks. As recently as June 2019 a large amount of European 475 Internet traffic was re-routed through China because of a BGP route 476 leak. However, instead of China telecom ignoring the leak it 477 hijacked the routes as their own. [13] 479 Case Study: In 2018 Amazon Web Services DNS offering called Amazon's 480 Route 53 was hijacked by using BGP table updates which directed the 481 traffic to a malicious server at an IXP in Chicago. The attack 482 lasted two hours and resulted in stolen Ethereum cryptocurrency from 483 myetherwallet.com [14] 485 Protocol Design Considerations: Protocol design considerations 486 should include authentication and handshake management when sending 487 and accepting traffic. This will be an ongoing and iterative process 488 so the protocol design must take into consideration the management 489 of this repetitive process. Protocol design should also take into 490 account how to prevent DNS cache poisoning and route table 491 manipulation and communicate that such a process occurred. 493 2.8. Web-based Attacks 495 Attack Description: Web-based attacks are those that use web systems 496 and services as the main surface for compromising the victim [15] 497 including browser exploitations, like the Firefox zero day exploit 498 found in the new version of Mozilla's browser in January 2020 [16] 499 and injections, drive-by downloads, cross-site request forgery, 500 water-holing, and more. Web-based attacks are on the rise and Web 501 application attacks also continue in the form of malicious web 502 applications, SQL injections and cross-site scripting. [17] 504 Case Study: Chrome 506 As recently as February 2020 a security vulnerability in older 507 versions of the Chrome browser allowed for the exploitation of 508 user's computers in a zero day attack scenario. Though the 509 vulnerability has been fixed through updates, a number of attacks 510 have taken place. Number unknown to date. [18] 512 Protocol Design Considerations: Many mitigations to these attacks 513 rely on endpoint security, such as patching. This may possibly 514 explain the rise in this attack trend. One simple way to mitigate 515 this attack vector is to make patching updates as easy and 516 straightforward as possible. This includes clear communication for 517 when updates are needed and how the user can safely and securely 518 patch and update. Protocol designers should be aware of other 519 mitigations, such as web-traffic filtering and web-traffic 520 encryption, in order to take them into consideration. 522 2.9. Malware Free Attacks 524 Attack Description: Malware-free attacks accounted for 51% of all 525 global cyberattack types, according to Crowdstrike's 2020 Global 526 Threat Report [19] for the first time since starting the report. A 527 malware free attack is one that does not employ or write a malicious 528 file or fragment a computer disk. Instead, memory executed code or 529 stolen credentials, running legitimate tools or executing code from 530 memory are all possible types of attacks. Malware-free attacks are 531 more difficult to detect unless actively looking for cyberattacks in 532 systems. 534 Case Study: TBD TODO 536 Protocol Considerations: Building in resilience to malware-free 537 cyber attacks. Allow for search and notification of potential 538 cybersecurity issues as a pre-emptive measure. 540 2.10. Table of Attacks TODO 542 This section will be a table of attacks, case studies and the 543 relating protocol design considerations. It will updated once all of 544 the case studies have been added. 546 3. Real World Impacts 548 The following section focuses on the impacts and outcomes that 549 happen as a result of cyber attacks. This section is by no means 550 comprehensive, but will expand as examples are added through 551 contributions and collaborations with those who are interested. 553 3.1. Remote Data Alteration 555 Attack Description: Alteration of data on a remote system, e.g. a 556 Industrial Control System, to achieve an effect that would, for 557 example, change the delivery of products in a supply chain or change 558 the characteristics of a product during production may cause harm to 559 people using that product intended for one use, but designed to 560 malfunction. RDP allows cyber attacks to access the Internet-facing 561 parts of an ICS from where they may able to move to the operational 562 environment. 564 Case Study: Industrial Control Systems or TBD [20] TODO 565 Protocol design considerations: Industrial Control Systems are 566 expensive and are often patched in slower-time, and a defence-in- 567 depth approach is advocated; endpoint security alone is not enough. 568 Additional considerations include the ability to real-time monitor 569 easily, and to note that internet protocols are used for high- 570 threat systems. 572 3.2. Data Exfiltration 574 Attack Description: Data exfiltration is a frequent outcome of 575 compromise, where data is taken from a system by an unauthorized 576 user. This information leakage includes customer data (often in 577 high-profile breaches) or theft of IPR material from enterprises. 579 Exfiltration of data can be: 581 1) High-volume, where the attacker expects to be detected or wants 582 to operate quickly. 584 2) Low-and-slow, where data is siphoned off at a low level for a 585 long period of time, in the hope of avoiding detection. 587 Case study: Equifax 589 In March 2017, attackers searched the web looking for 590 vulnerabilities that were known, but had not been fixed. Making 591 patches easier to download would have easily solved this issues. 592 These attackers targeted the dispute resolution portal at a credit 593 ratings company called Equifax in the US. The hackers used a 594 vulnerability in Apache Struts which allowed access and 595 exfiltration of personal information on the portal. [21] 597 Protocol Design Considerations: Endpoints can tag/watermark content 598 so that leaked data can be identified and possibly stopped at a 599 gateway, or at least traced back to the user that leaked the 600 material. For this, protocol data could include a protective marking 601 field that is visible to a firewall, even if the content is 602 encrypted. 604 Another issue to consider is the detection of data exfiltrated 605 through covert channels. Protocols should be designed with this 606 abuse in mind, with designers minimising existence and size of 607 covert channels. 609 3.3. Identity Theft 611 Attack Description: Fraud committed from the theft of personal 612 identifiable information - such as bank details, home address and 613 date of birth - strengthened by the massive digitisation and 614 centralisation of people's personal data. Credential stealing and 615 credential stuffing are two of many ways to obtain personal data. 617 Case Study: JP Morgan Chase 619 In 2014 JP Morgan Chase had over 83 million accounts compromised and 620 hackers made over $100 million through fraud and identity theft. To 621 date it is one of the largest data breaches in history.[22] 623 Protocol Design Considerations: Provision and protect a way that 624 allows breaches of personal data to be detected in real-time and 625 stopped. 627 4. Defensive Measures 629 Defensive measures broadly fall into three classes: 631 1. prevention of attacks - stopping most attacks from achieving the 632 attacker's objectives, i.e. from taking hold on a system, network or 633 endpoint. 635 2. detection of attacks - how attacks are detected quickly, 636 efficiently, with a high-degree of confidence and accuracy. 638 3. mitigation of attacks - once an attack happens, the capability to 639 stop the damage done by the attack, e.g. preventing the spread of 640 the compromise within an organisation, limiting the data exfiltrated 641 or stopping the attack from being replicated globally on unaffected 642 systems. 644 All defences listed in this section relate to one or more attacks 645 listed in Section 2. 647 For each type of defensive measure, we categorise the method as 648 prevention, detection, mitigation or a combination of these; we 649 link to the type of attack in Section 2 that is prevented; and we 650 describe how the defence work. 652 Considerations for protocol designers (in relation to each defensive 653 measure) are also listed throughout, and summarised in Table 4.16 to 654 provide an easier reference. 656 4.1. Response to Attacks 658 Defence Type: Mitigation 659 A system can be designed to ensure availability under attack, e.g. 660 by segregating classes of devices on a network, or considering 661 system architecture. Components that are under attack have a channel 662 for reporting that attack that is distinct from the channel used for 663 launching the attack. 665 Case Study: TBD TODO 667 Protocol Design Considerations: Design protocols that allow such 668 segregation in architecture in a simple and scalable way. Design 669 protocols for reporting of attacks that use channels that are less 670 susceptible to attacks. 672 4.2. Recovery from Attacks 674 Defence Type: Prevention 676 If organisations and individuals assume that a security breach will 677 happen then defences will be optimised in or to allow for a quick 678 response and minimal impact. This is an important point that is 679 missing from the current version of RFC 3552 because the scale and 680 size of attacks has changed over the years since it was published as 681 noted in draft-mcfadden-rfc3552-research-methodology. 683 For example, encrypt data when stored so that if it is stolen, the 684 attacker can't decrypt it. For another example, if data is backed up 685 regularly and stored offline, then the threat held by ransomware is 686 minimised. 688 Case Study: TBD TODO 690 Protocol Design Considerations: Design protocols that can deliver 691 encrypted payloads to capable endpoints. Practice strong 692 separation of the keys used to encrypt data at rest from the data, 693 with high levels of protection applied to the keys. Design protocols 694 that allow for regular, automatic backup of data minimising the 695 amount of user interaction required. 697 4.3. Reporting of Attacks 699 Defence Type: Detection 701 Logging is an important feature. Multiple logs allow cross 702 referencing and establishing truth data, so it is important to 703 provide logging in multiple places, to detect false reporting by 704 compromised endpoints or networks. Logging allows strengthened 705 forensics, which reduces the risk of similar attacks in future. 706 Forensic analysis of logs makes it easier to detect and locate 707 attacks, so can be a deterrent to attackers. For this same reason, 708 malicious manipulation of logs to prevent detection is an attractive 709 attacker objective. 711 Reliable logging helps to find the source of an attack, its spread 712 and what devices and networks have been compromised. Unreliable 713 logging can slow attempts to mitigate it. 715 Case Study: TBD TODO 717 Protocol Design Considerations: How a protocol might help/hinder the 718 ability to troubleshoot or have separate logging in multiple places 719 (for truth data), allow for reliable logging across points in a 720 network. 722 4.4. Sinkholing 724 Defence Type: Mitigation 726 Mitigation against where a DDoS attack has already been launched, to 727 prevent a successful attack outcome (i.e. a denial of service). 729 Case Study: Nitol Botnet 731 Through counterfeit Microsoft products, Nitol malware infected over 732 4000 Windows computers primarily in China. The botnet originated 733 from the domain 3322.org which was a dynamic DNS service. The 734 subdomains of 3322.org from which the malware originated, could 735 redirect traffic to additional sites also infected with malware. The 736 malware propagating itself through Internet traffic. [23] At least 737 70,000 subdomains were infected. Microsoft attempted to disrupt the 738 supply chain of the infected Microsoft products and block the 739 subdomains. [24] 741 Protocol Design Considerations: Ability to determine whether a 742 connection is likely malicious or not, and filter out malicious 743 connections at speed. Ability to reliably determine the source of a 744 connection and verify that it is accurate and from an address 745 authorised to make the connection. Ongoing monitoring and reporting 746 is necessary. 748 4.5. Firewalls/Middleboxes/Gateways 750 Defence Type: Prevention and detection 751 Firewalls, middleboxes and gateways can be used to inspect traffic 752 and make decisions whether to allow, block or modify data content. 753 These decisions can be based on simple IP address/port/protocol 754 rules, or on deep packet inspection of individual data packets, or 755 use artificial intelligence/machine learning techniques to make more 756 complex decisions based on analysis of traffic over a period of 757 time. 759 Case Study: TBD TODO 761 Protocol Design Considerations: Protocols should allow for selective 762 and/or minimally intrusive analysis, balanced against the need to 763 protect the privacy of the user content and any personally 764 identifiable information. Minimally intrusive analysis could include 765 the ability to block traffic that it associated with known insecure 766 protocols or ports, known malicious activity or known malicious 767 users. A protocol that makes all traffic look essentially 768 indistinguishable forces the firewall into making an "all-or- 769 nothing" decision, which would be ineffective for defending against 770 attacks if it is still to allow some communications. Allowing for 771 communication would be detrimental for privacy as well. 773 A firewall should not be able to undetectably modify traffic; where 774 it is necessary to modify traffic to prevent a threat, the 775 modification should be apparent to the receiver. 777 4.6. Intrusion Prevention System (IPS) and Intrusion Detection System 778 (IDS) 780 Defence Type: prevention and detection 782 These systems provide the abilities to prevent and detect malware 783 infection, vulnerability exploits, and lateral movement on 784 compromised networks and endpoints. Signatures for bad content - 785 IPS/IDSs don't work on traffic if attacks have legitimate content 786 but bad intent, e.g. DDoS. However, the IPS/IDS may detect the 787 malware that compromised the endpoint to launch the DDoS attack. 789 IDSs are passive systems that scan traffic and report to the traffic 790 owner on threats; IPSs are inline, taking an active role and making 791 automated decisions and applying these actions to traffic. 793 Case Study: Vishing and Covid-19 795 IDS and IPS are employed in companies and organisations especially 796 in office and controlled physical environments. However, because of 797 Covid-19 people are working from home or remotely. IDS is used in 798 offices; now people working remotely or working from home don't have 799 that protection. This has led to an upsurge in vishing. Vishing is 800 when an attacker builds a profile and convinces the victim to 801 download and use remote assistance software which becomes the way 802 the attacker penetrates an organisation. In a remote environment 803 without IDS or IPS this could happen without adequate defence. [25] 805 Protocol Design Considerations: For IDS, protocols should allow for 806 logging of data relating to the connection, which may include any or 807 all of IP addresses, ports, protocols and payloads, balanced with 808 the requirement to protect privacy of user data. For IPS, protocols 809 should allow for signature/statistical anomaly detection, the 810 ability to selectively drop traffic and respond at efficient scale 811 and speed. 813 4.7. Upstream Filtering 815 Defence Type: Mitigation 817 Content is filtered through a "scrubbing" centre to forward only 818 good traffic. This is provided as a service by e.g. Cloudflare, 819 Akamai. 821 Case Study: Akamai scrubbing 823 In August 2019, Akamai opened a new scrubbing centre in Melbourne to 824 compliment its other Asian regional centres in Sydney, Tokyo, Hong 825 Kong, Osaka and Singapore. [26] Because of the surge or DDoS attacks 826 in the region, the scrubbing capacity has increased at least three 827 times to that of the largest DDoS attack. For all content delivery 828 centres, traffic is redirected to scrubbing centres by making a BGP 829 change. Upstreaming filtering or scrubbing is meant to prevent 830 attacks before they reach data and applications in the cloud. The 831 largest mitigated attack to date was Mirai at 1.3 TBPS. Distributed 832 scrubbing centres aid in mitigation of such attacks. 834 Protocol Design Considerations: allow for forwarding of traffic on 835 this scale through robust internet infrastructure. Attack traffic 836 should be easily recognisable through its externals, e.g. packet 837 destination, traffic flow patterns, protocol type, signatures. This 838 relies on being able to filter at speed and weed out malicious 839 connections. 841 4.8. Malicious Domain Monitoring and Takedown 843 Defence Type: Mitigation, detection and prevention 845 We wish to detect the existence and determine the intent of 846 malicious domains as soon as possible, and remove or deny access to 847 them before most harm can be done. For example, removal of malicious 848 domains that are created to receive clicks from phishing emails; if 849 the domain can be removed before most emails are read, the links 850 won't work and the harm is reduced with no effort from the user. 852 Takedown services can levy copyright protections to request 853 takedowns. Combined with techniques to use email authentication, 854 these proactive measures rather than reactive ones have had 855 considerable effect in UK government efforts to minimise phishing. 856 [27] 858 Case Study: TBD TODO 860 Protocol Design Considerations: Protocols should allow users to 861 determine the identity of the domain that they are connecting before 862 they are exposed to data from that domain. Protocols should provide 863 a means for users to verify the authenticity of a connection to a 864 domain. Protocols should minimise the opportunities for users to 865 confuse malicious domains with legitimate domains. Protocols should 866 provide a method for legitimate domain owners to recognize attempts 867 by a malicious domain to masquerade as the legitimate domain. 869 4.9. Filtering 871 Defence Type: Prevention and mitigation. 873 Filtering of traffic can be done according to block lists of 874 addresses, content types or signatures specified by malware threat 875 feeds. Filtering can also be done using statistical and machine 876 learning techniques, e.g. for spam. Filtering can prevent malware 877 infection or mitigate it by stopping the further spread of malware. 879 Case Study: Telstra and Covid-19 Scams 881 The CEO of Telstra warned that Covid-19 malware scams are a boom to 882 malware brokers and attackers. The rise and prevalence of Covid-19 883 scams in the first six months of 2020 is not surprising, but the 884 Telstra CEO said clearly that they are strengthening their screening 885 and filtering activities on their networks. [28] 887 Protocol Design Considerations: Protocols should allow for selective 888 and/or minimally intrusive analysis of traffic in order to determine 889 whether to allow data through the filter. Malware may try to shape 890 malicious traffic to appear like benign traffic, so protocol 891 specifications should minimise the opportunity for malicious 892 payloads to masquerade as legitimate payloads. For example, 893 encrypting all data so that it looks the same, then you're removing 894 any discriminating features that filtering systems could use to base 895 their decisions on. 897 Protocols therefore should be designed with an awareness that hiding 898 features that expose malicious traffic as malicious will enable 899 malicious payload delivery, therefore it would be responsible to 900 work out which, and preserve features that, would still allow 901 effective detection. 903 4.10. Implementation of Trust 905 Defence Type: Prevention. 907 A trusted ecosystem is one in which a user or organization has a 908 level of confidence in the security and reliability of the system. 909 No ecosystem can ever be 100% secure, but trust is created when risk 910 analysis and technical mitigations are in place. 912 For example, content is filtered so that data from non-trusted 913 sources is filtered out before it arrives. DMARC/SPF to prevent 914 phishing, secure authenticated log-in, PKI certificate validity on 915 TLS connections is enforce. Updates and patch 917 Case Study: TBD TODO 919 Protocol Design Considerations: Protocols should be resilient and 920 should not prevent informed users from opting into services that 921 protected delivery of only trusted content. Protocols should allow 922 for verification of data source and integrity. Protocols should 923 include policies for handling and management of non-trusted data. 925 4.11. Endpoint Security 927 Defence Type: prevention, detection and mitigation. 929 Security hygiene, like regular patches to fix the latest discovered 930 software vulnerabilities, form an important part of the security of 931 any system. However, some endpoints are unable to maintain their own 932 security and can introduce vulnerabilities themselves. 934 Case Study: Netgear 936 Netgear is one of many examples available relating to prevention, 937 detection and mitigation of endpoints. In July 2020 Netgear released 938 security advisories for a number of its routers, modems, gateways 939 and extenders. [29] Firmware updates to patch the issue are linked 940 to the corresponding network device. 942 Protocol Design Considerations: Consider whether the protocol data 943 is available for inspection by the endpoint security solution. At 944 what point in the protocol stack is protected data decrypted and can 945 be analysed or blocked by the endpoint security? 947 4.12. Email Anti-spoofing Measures 949 Defence Type: Prevention 951 These are preventive measures designed to prevent and reduce 952 phishing emails. Configure anti-spoofing controls on a domain you 953 own to prevent email spoofing, such as Domain-based Message 954 Authentication, Reporting and Conformance (DMARC), Sender Policy 955 Framework (SPF) and Domain-Keys Identified Mail (DKIM). [30] 957 Case Study: Cosmic Lynx 959 Cosmic Lynx is a new business email compromise cybercrime gang which 960 has already had over 200 targets in 46 countries since July 2019. 961 [31] The criminal gang focus their attack on companies which don't 962 deploy DMARC by using a fake 'mergers and acquisitions' email. The 963 emails are linguistically well thought out and uses words not seen 964 in phishing scams normally. Throughout the email correspondence 965 about the business deal, they can directly spoof reply-to email 966 addresses in order to look legitimate. Recipients are scammed into 967 participating in sales and payments to attackers' bank accounts. 969 Protocol Design Considerations: Allow for strong authentication of 970 source of user data. Create policies for delivery of non- 971 authenticated data. Ensure authentication of all communication at 972 the protocol level and enable security checks and communication at 973 all stages of the process. 975 4.13. Social/User Interface Interactions 977 Defence Type: Prevention and detection. 979 Since phishing is a social engineering type of attack, there should 980 be education and training for people to prevent phishing. 981 Furthermore, presenting a user with a photo on log-in to prevent 982 logging into a phishing domain and two factor authentication (2FA) 983 are some of the mitigation strategies. Also reporting of abnormal 984 behaviour/user mistakes should be encouraged and failed log-in 985 attempts should be displayed to the user. Finally appropriate 986 password policies should be in place. 988 Case Study: TBD TODO 990 Protocol Design Considerations: Protocols should support secure 991 communication of security-critical information to and from the user 992 interface; this could include passwords, biometric information, 993 other credentials, user activity logs, PKI certificate properties 994 and validity, origin authentication using auxiliary information 995 (such as identifying phrases or photos). 997 4.14. Detection of Exfiltration and Data Leakage 999 Defence Type: detection and mitigation 1001 When a compromise of a network has occurred, either by malware 1002 infection or insider threat, it is important to be able to detect 1003 attempts to exfiltrate data from the network and stop exfiltration 1004 as soon as the leak has been reliably confirmed. 1006 Detection of exfiltration can be through packet metadata analysis, 1007 statistical analysis of data collected over a period of time, or 1008 content inspection on unencrypted data. 1010 Case Study: SamSam is a ransomware that infects and then attacks 1011 after a period of monitoring networks and/or users. [31]Instead of 1012 attacking right away like WannaCry, SamSam manages to infect, delay 1013 and then attack again with the goal of infection, data infiltration 1014 and ransoming.[32] 1016 Protocol Design Considerations: Encryption of data can make 1017 inspection of data at a gateway for malicious exfiltration less 1018 reliable. 1020 Statistical properties of traffic may be used to detect exfiltration 1021 occurring over an extended period of time; it would be very bad for 1022 attack defence in general if protocols sought to hide patterns of 1023 traffic that are be indicative of exfiltration. If data is 1024 watermarked to indicate the origin of protected content, protocols 1025 should not destroy the watermarks. Protocols should minimise covert 1026 channels that can be used for the exfiltration of data by malware. 1028 Additionally, designing a recurring monitoring and reporting 1029 mechanism within the protocol would allow for regular and consistent 1030 logging. 1032 4.15. Misuse of the Domain Name System. 1034 TODO 1035 Defence Type: Detection and mitigation 1037 Case Study: TBD TODO 1039 4.16. Attack and Defense Table TODO 1041 This section will be a table with attack, defence type, case 1042 studies, links and comments on the impact to protocol designs. This 1043 will be completed once the case studies have been added. 1045 5. The Overall Security Picture 1047 Deployments of protocols vary greatly and use cases show the variety 1048 and diversity of design, development and implementation of 1049 protocols; There are varying levels of risk and a variety of threats 1050 being more likely than others depending on context in which the 1051 protocol is deployed. Therefore, some attacks and defensive measures 1052 outlined in the above sections may be more frequent than others. For 1053 example, an enterprise might consider customer data exfiltration a 1054 greater threat than its resilience to zero-day vulnerability 1055 exploitation, but an individual user might be more concerned with 1056 their protection against phishing than with seeing all traffic 1057 leaving their network. 1059 There is no one-size-fits-all approach for protocol deployment; each 1060 specific implementation and use case should be considered 1061 separately, as deployments require a mature a whole-system security 1062 view. This allows for a system wide analysis so that the security of 1063 the protocol isn't the only security considered. 1065 For example, a user with a client that runs DoH might feel 1066 completely secure, as the information is encrypted and the user has 1067 a private connection to the DNS resolver. However, this could 1068 actually bypass defensive filtering protections, without the 1069 protection afforded blocking of malicious domains. Further, unless 1070 DNSSEC is also deployed, you have no trust that the resolver is 1071 returning the correct results and no passive auditor to check this. 1073 Another popular example is the padlock in most browsers that tells 1074 users they have a secure HTTPS connection. Users can conflate the 1075 meaning of the padlock, assuming that use of HTTPS automatically 1076 confers a legitimate connection - even if the domain being connected 1077 to is fake or malicious. 1079 6. Attack Defence in Security Considerations 1081 The impact of new protocols on existing systems that defend against 1082 malicious attacks is not systematically considered in the Security 1083 Considerations sections in RFCs. This draft is the first step in 1084 developing a reference guide to enable a systematic and consistent 1085 assessment across different protocols with respect to attack 1086 defence. 1088 Hence, protocols should be assessed against a range of attacks and 1089 detections methods, such as those attack types listed in the Table 1090 in Section 2 and those defensive measures listed in the Table in 1091 Section 4, as a standard consideration in all protocol design, and 1092 to make the potential impacts clear to deployers. 1094 When writing the Security Considerations for a protocol, protocol 1095 designers should consider known attacks and prevention, detection 1096 and mitigation methods. As the type, kind and characteristics of 1097 attacks grow in complexity, it is important that protocol designers 1098 take into account attack types and mitigation strategies into their 1099 designs. In fact this should be backed into the security 1100 considerations from the start. This draft RFC is a helpful guide to 1101 those considerations. 1103 7.Security Considerations 1105 This document is entirely about Internet security and is an input to 1106 the IAB Model T work. 1108 8. IANA Considerations 1110 This draft has no actions for IANA. 1112 9. Conclusions 1114 This draft is a work in progress, but is a set of considerations for 1115 protocol designers and implementors with respect to attack defence. 1116 Collaborations and contributions would expand this document to make 1117 it more robust. 1119 10. References 1121 10.1. Normative References 1123 [1] RFC 7252 Shelby, Z. et al, "The Constrained Application Protocol 1124 (CAP)" RFC 7252, June 2014. 1126 [2] https://www.zdnet.com/article/new-silex-malware-is-bricking-iot- 1127 devices-has-scary-plans/ 1129 [3] https://www.omdia.com/resources/product-content/maersk-ciso-offers- 1130 important-lessons-three-years-after-notpetya-attack-int005-000068] 1131 [4] https://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack- 1132 cause-outage-status-explained 1134 [5] https://www.zdnet.com/article/the-coap-protocol-is-the-next-big- 1135 thing-for-ddos-attacks/ 1137 [6] https://www.darkreading.com/endpoint/91--of-cyberattacks-start- 1138 with-a-phishing-email/d/d-id/1327704 1140 [7] https://www.wired.com/2016/01/everything-we-know-about-ukraines- 1141 power-plant-hack/ 1143 [8] https://developers.facebook.com/docs/certificate-transparency/ 1145 [9] RFC 6962 Laurie B., et al, "Certificate Transparency" RFC 6962, 1146 June 2013. 1148 [9] https://techcrunch.com/2019/05/12/wannacry-two-years-on/ 1150 [10] https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber- 1151 kill-chain.html# 1153 [11] https://www.kaspersky.com/resource-center/threats/ransomware- 1154 wannacry 1156 [12] https://www.cnbc.com/2017/07/31/new-anthem-data-breach-by- 1157 contractor-affects-more-than-18000-enrollees.html 1159 [13] https://www.zdnet.com/article/for-two-hours-a-large-chunk-of- 1160 european-mobile-traffic-was-rerouted-through-china/ 1162 [14] https://www.internetsociety.org/blog/2018/04/amazons-route-53- 1163 bgp-hijack/ 1165 [15] https://www.enisa.europa.eu/topics/threat-risk- 1166 management/threats-and-trends/enisa-threat-landscape 1168 [16] https://www.welivesecurity.com/2020/01/09/mozilla-rushes-patch- 1169 firefox-zero-day/ 1171 [17] https://www.forbes.com/sites/emilsayegh/2020/02/12/more-cloud- 1172 more-hacks-pt-2/#7c0c47d669b3 1174 [18] https://threatpost.com/google-patches-chrome-browser-zero-day- 1175 bug-under-attack/153216/ 1176 [19] https://www.crowdstrike.com/resources/reports/2020-crowdstrike- 1177 global-threat-report/] 1179 [20] https://www.computerweekly.com/news/252446423/Industrial- 1180 controls-systems-a-specialised-cyber-target 1182 [21] https://www.cnet.com/news/equifaxs-hack-one-year-later-a-look- 1183 back-at-how-it-happened-and-whats-changed/ 1185 [22] https://www.wired.com/2015/11/four-indicted-in-massive-jp-morgan- 1186 chase-hack/ 1188 [23] https://www.darkreading.com/risk/microsoft-hands-off-nitol-botnet- 1189 sinkhole-operation-to-chinese-cert/d/d-id/1138455] 1191 [24] https://www.darkreading.com/risk/microsoft-hands-off-nitol-botnet- 1192 sinkhole-operation-to-chinese-cert/d/d-id/1138455] 1194 [25] https://www.itproportal.com/features/how-it-can-combat-the-rise- 1195 in-vishing-attacks-in-this-new-normal/ 1197 [26] https://securitybrief.com.au/story/second-akamai-scrubbing-centre- 1198 opens-in-melbourne 1200 [27] https://www.ncsc.gov.uk/guidance/phishing 1202 [28] https://www.smh.com.au/business/companies/weakened-defences-covid- 1203 19-a-boon-for-malware-merchants-warns-telstra-boss-20200505-p54q2a.html] 1205 [29] https://kb.netgear.com/000061982/Security-Advisory-for-Multiple- 1206 Vulnerabilities-on-Some-Routers-Mobile-Routers-Modems-Gateways-and- 1207 Extenders 1209 [30] https://www.ncsc.gov.uk/collection/email-security-and-anti- 1210 spoofing 1212 [31] https://threatpost.com/russian-bec-gang-cosmic-lynx- 1213 uncovered/157166/ 1215 [32] https://www.infradata.co.uk/resources/what-is-samsam-ransomware/ 1217 [33] https://blog.malwarebytes.com/cybercrime/2018/05/samsam- 1218 ransomware-need-know/ 1220 [34] https://www.informationsecuritybuzz.com/study-research/new- 1221 intelligence-reveals-that-alina-point-of-sale-malware-is-still-lurking- 1222 in-dns/ 1223 11. Acknowledgments 1225 This document was prepared using 2-Word-v2.0.template.dot. 1227 Authors' Addresses 1229 Dominique Lazanski 1230 Last Press Label 1231 London, UK 1233 Email: dml@lastpresslabel.com