idnits 2.17.1 draft-mcfadden-opsec-endp-evolve-01.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 53 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 868 has weird spacing: '...example when ...' -- The document date (August 16, 2021) is 956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '331' is mentioned on line 1093, but not defined == Unused Reference: '32' is defined on line 1353, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-02 == Outdated reference: A later version (-01) exists of draft-mcfadden-opsec-endp-taxonomy-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission M. McFadden 2 Internet Draft internet policy advisors, ltd uk 3 Intended status: Informational August 16, 2021 4 Expires: February 16, 2022 6 Evolution of Endpoint Security - An Operational Perspective 7 draft-mcfadden-opsec-endp-evolve-01.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. This document may not be modified, 13 and derivative works of it may not be created, except to publish it 14 as an RFC and to translate it into languages other than English. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on February 16, 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This draft discusses the traditional model of security where 52 endpoints in the network are protected by a variety of tools. It 53 proposes a model for endpoints and then argues that the older, 54 traditional approach is no longer sufficient for operational 55 security at the endpoint. A series of operational examples are 56 discussed in an Appendix. 58 Table of Contents 60 1. Introduction...................................................3 61 2. Endpoints, Definition, Model and Scope.........................3 62 2.1. Scope.....................................................3 63 2.2. Models....................................................4 64 2.3. Internal representation of an endpoint....................4 65 2.4. External representation of an endpoint....................5 66 3. Limitations of the Threat Landscape............................6 67 3.1. Typical Categories of Threats.............................7 68 3.2. Evolution of threat types and their descriptions..........7 69 4. Endpoint Security Capabilities.................................8 70 4.1. Intrinsic versus added security...........................9 71 4.2. Specific Endpoint Security Capabilities..................10 72 5. Optimal Properties of an Endpoint Security Solution...........11 73 6. Case Studies in the Limitations of Endpoint Security Only.....12 74 6.1. Unable to put an endpoint security add-on on the UE......13 75 6.2. Endpoints may not see the malware on the endpoint........16 76 6.3. Endpoints may miss information leakage attacks...........18 77 6.4. Suboptimality and gray areas.............................20 78 7. Defense-in-depth from the perspective of protocol design......23 79 8. Endpoint security from the perspective of protocol design.....24 80 8.1. Simplicity of design is important........................25 81 8.2. Diversity in protocol design.............................25 82 8.3. Protocol design and failure of intermediaries............26 83 8.4. Protocol evolution.......................................26 84 9. Security Considerations.......................................26 85 10. IANA Considerations..........................................27 86 11. Acknowledgements.............................................27 87 12. References...................................................27 88 12.1. Informative References..................................27 89 Appendix A. Operational Experience and Endpoint Security.........31 90 A.1. Endpoint only incidents..................................32 91 A.2. Security incidents detected primarily by network security 92 products......................................................33 94 1. Introduction 96 There is currently significant discussion of the evolution of the 97 Internet's treat model. The evolution of the Internet has brought 98 new approaches to transport, connectivity, service provision and the 99 type of devices connected to the Internet. This document is a 100 discussion of the capabilities and limitations of security solutions 101 based on the traditional strategy of protecting endpoint devices. 103 The typical approach of protecting endpoints is affected by the 104 evolution of those endpoints and the emergence of threats that do 105 not rely on exploits at the endpoints. The goal of this document is 106 to provide an operational perspective on this evolution. 108 The focus here will be capabilities and limitations of endpoint-only 109 security solutions and the impact of the evolution of the Internet's 110 threat model on operational security. 112 Our goal with this review is to describe the benefits and 113 limitations of endpoint security in the real world - from an 114 operational perspective - rather than in the abstract. We aim to 115 highlight security limitations that cannot be addressed by endpoint 116 solutions and to suggest how these may be mitigated with the concept 117 of a defence-in-depth approach, in order to increase the resilience 118 against attacks and data breaches. 120 Finally, this draft suggests how this approach might affect protocol 121 design. 123 2. Endpoints, Definition, Model and Scope 125 2.1. Scope 127 Endpoints are the origin and destination for a communication between 128 parties. This encompasses User Equipment (UE) and the Host at the 129 other end of the communication. This is a simplification of 130 operational experience in the real world. In fact, there is an 131 enormous variety of devices at the endpoints of communication of 132 parties. However, a generalized approach to endpoints is not only 133 possible, but the subject of other work in the IETF. For instance, 134 the TEEP Working Group [1] has attempted to describe a generalized 135 model for endpoints. As a companion to this work, a taxonomy of 136 endpoints [2] is also provided. 138 The goal is to provide a uniform way to describe the security 139 properties of endpoints in order to also describe the threat model, 140 or attack surface, of those endpoints. 142 For example: 144 o The following would be considered UEs: a smartphone, a smart 145 device, any IoT device, a laptop, a desktop, a workstation, etc. 147 o Hosts might be represented by the following examples: physical 148 servers, virtual servers/machines, etc. 150 2.2. Models 152 In what follows, the discussion is limited to modeling the endpoints 153 that are User Equipment (UE) rather than hosts. Having a model for 154 Internet hosts is important but beyond the scope of this draft. The 155 goal is to have a generalized description of the endpoint, its 156 security properties, and the position of the endpoint in the 157 network. 159 In addition, there are two separate descriptions for the endpoint. 160 First, an internal view of the endpoint is provided and then a view 161 of the external model for the endpoint is suggested. This approach 162 provides a mechanism to cover the full attack surface and the threat 163 landscape for the endpoint. 165 2.3. Internal representation of an endpoint 167 The companion endpoint taxonomy draft [2] provides a hierarchy of 168 endpoint types, properties and capabilities. The taxonomy draft 169 begins from the simplification represented in the following diagram: 171 +----------------------------+ 172 | Application | 173 +----------------------------+ 174 | OS / Execution Environment | 175 +----------------------------+ 176 | Hardware | 177 +----------------------------+ 178 Internal Endpoint Model 180 Today there are an enormous set of combinations of Hardware, OS/EE 181 pairing, and Application layers, offering the user a vast set of 182 features with a wide spectrum of capabilities. One of the features 183 of the evolution of the Internet's threat model is that the variety 184 of these combinations is an enormous change compared to one or two 185 decades ago. 187 The variety of combinations provide users with a rich set of new 188 capabilities. Applications designers can provide services that were 189 not possible even five years ago. However, with those new 190 capabilities come new risks: new vectors for delivery of attacks and 191 new attack surfaces at the endpoint. 193 The result is: the operational implications for endpoint security 194 have evolved as the capabilities and variety of endpoints has 195 expanded. 197 2.3.1. Applications as Endpoints 199 One of the other features of this evolution is that the application 200 layer has evolved in such a way that it can be an endpoint as well. 201 This has important operational security implications because prior 202 approaches to providing endpoint security emphasized "per-device" 203 security. In an evolved internet, the endpoint may be the 204 application with multiple applications running on a single piece of 205 User Equipment (UE). In this case, the threat model may be different 206 for individual applications - resulting in different threat 207 landscapes on a single device. 209 2.4. External representation of an endpoint 211 Section 2.3 describes a model for understanding the threat landscape 212 of an individual UE device. In order to provide a complete view of 213 the threat landscape there must also be a model for the connectivity 214 properties of the device. This is a view of the attack surface of 215 the device as viewed externally. 217 A representation of endpoints in an end-to-end context could look 218 like the following diagram: 220 +-------+ +---------------------+---------+ 222 | Human | <- (1) -> | Digital Persona | Application | <- (2) -> 224 +-------+ +-----------+-------------------+ 226 | User Equipment | 228 +-------------------------------+ 229 +----------------+ +----------------+ 231 <- (2) -> | Network | <- (3) -> | Platform/Hosts | 233 | Infrastructure | +----------------+ 235 +----------------+ 236 External Endpoint Model 238 1. Humans have a user experience (UX) with the UE, starting with an 239 explicit or implicit Digital Persona, engaging with an application; 241 2. The application will have sessions through a network 242 infrastructure. There are no assumptions made about how the network 243 infrastructure is provisioned or what its properties are, (as an 244 example, it could include landlines, mobile networks, satellites, 245 etc.) nor are any assumptions made about the characteristics of 246 those sessions (for instance, unicast or multicast, or sessions 247 sourced from multiple hosts). 249 3. A platform consisting of many Hosts either physical or virtual 250 which ensures a large part of the end-to-end user experience. 252 In this end-to-end model we see that many other systems may have 253 interactions with the UE: the human, the UX, the digital persona, 254 the sessions, the intermediate network infrastructure, and the hosts 255 and applications at the destination. 257 This means that the operational security requirements for the model 258 have expanded significantly. The threat landscape is very large and 259 the attack surface will involve all the components and interactions 260 at any level of either model. 262 3. Limitations of the Threat Landscape 264 In sections 2.3 and 2.4 above we saw that the pace of evolution of 265 endpoints on the Internet has had a resulting change to the types 266 and properties of attacks on those endpoints. In the past, the 267 number of User Equipment (UE) was well-bounded and an approach to 268 operational security that addressed the endpoints made intuitive and 269 practical sense. 271 In today's Internet, the vast number and range of combinations that 272 the generic modeling in sections 2.3 and 2.4 offers us, makes 273 defining a threat landscape far more complicated. From an 274 operational perspective the prior approach of concentrating security 275 on endpoints may have to be reconsidered. 277 3.1. Typical Categories of Threats 279 Any description of a threat model for endpoints must address 280 typical, well-known attacks such as: 282 o Malware (Trojans, viruses, backdoors, bots, etc.) 284 o Adware and spyware 286 o Exploits 288 o Phishing 290 o Script-based attacks 292 o Ransomware, local Denial of Service (DoS) attacks 294 o Denial of Service (DoS) attacks 296 o Malicious removable storage devices (USB) 298 o In memory attacks 300 o Rootkits and firmware attacks 302 o Scams and online fraud 304 o System abuse (staging/proxying) 306 3.2. Evolution of threat types and their descriptions 308 However, the threat landscape is not static. Like the endpoints 309 themselves, the threats evolve. It's difficult, for instance, to 310 decide if cryptojacking or coinmining belong as examples of attacks 311 in categories above. It is possible that they represent new 312 categories of attack. In either case, a model of endpoint security 313 must cope with a threat landscape that evolves as the properties of 314 the endpoints evolve. 316 There are frameworks for describing threats: 318 O MITRE Common Attack Pattern Enumeration Classification (CAPEC). 319 See [3]. CAPEC offers a hierarchical view of attack patterns by 320 domains which can match some aspects of both of our above models, 321 but we will need to identify those attacks that fit exactly in our 322 scope. 324 O MITRE ATT&CK. See [4]. ATT&CK offers a very straightforward 325 categorized knowledge base of attacks, but it concentrates on the 326 enterprise attack chain, so we will need to do some work to extract 327 what we need. 329 In both cases, the frameworks do not address all of the threats that 330 can affect the security of a system, for example they do not cover: 331 routing hijacking, flooding, selective blocking, unauthorised 332 modification of data sent to an endpoint, etc. 334 Phishing is an example of the limitations of using this approach. 335 Phishing should be included as an attack, but while this is indeed 336 an attack that will materialize on an end-device through an 337 application (email, webmail, etc.), the real target of this attack 338 is not the device, but the human behind the digital persona. 340 4. Endpoint Security Capabilities 342 For the purpose of this draft, endpoint security capabilities are 343 the features that are used to protect the endpoint from attack. 344 Protection has many meanings, however it is important to distinguish 345 three different aspects of protection: 347 o Prevention - The attack doesn't succeed by intrinsic or explicit 348 security capabilities. 350 o Detection - The attack is happening or has happened and is 351 recorded and/or signaled to another component for action. 353 o Mitigation - Once detected, the attack can be halted or its 354 effects can at least be reduced or reversed. 356 For example, prevention methods include keeping the software updated 357 and patching vulnerabilities, implementing measures to authenticate 358 the provenance of incoming data to stop the delivery of malicious 359 content, or choosing strong passwords. Detection methods include 360 inspecting logs or network traffic. Mitigation could include 361 deploying backups to recover from an attack with minimal disruption. 363 The endpoint model definitions in sections 2.3 and 2.4 are simple 364 but the security capabilities of each component may be complex. Each 365 layer may or may not have a certain spectrum of intrinsic 366 capabilities and there may be multiple ways to provide add-on and 367 third-party endpoint security capabilities, allowing complex 368 interactions between all of these components. 370 4.1. Intrinsic versus added security 372 In terms of security capabilities for each layer of the model, there 373 are those capabilities that are built-in or intrinsic, and there are 374 those that are added to the layer through external means. 376 (A) Intrinsic security capability can be built-into each of the 377 endpoint model layers 379 o (1) Hardware 381 o (2) OS/EE 383 o (3) Application 385 (B) Add-on security capability can be 387 o (4) a component of the hardware 389 o (5) a component of the OS/EE 391 o (6) an application by itself 393 In (A), there is a built-in, 'security by design' approach of the 394 developer or manufacturers. They often offer a security model and 395 security capabilities as part of their design. 397 In (B), a 3rd party is offering an additional security component 398 which was not necessarily considered when the Hardware, OS/EE or 399 Application was designed. 401 With regard to (6), there are many available options for add-on 402 security capabilities offered by third-parties as applications on a 403 commercial or open-source basis. 405 Gartner (see [5] highlights the evolution of endpoint security 406 towards two directions as shown in [6], [7], and [8]. 408 o Endpoint Protection Platform (EPP) as an integrated security 409 solution designed to detect and block threats at the device level. 411 o Endpoint Detection and Response (EDR) as a combination of next 412 generation tools to provide anomaly detection and alerting, forensic 413 analysis and endpoint remediation capabilities. 415 4.2. Specific Endpoint Security Capabilities 417 Endpoint security capabilities can be grouped into four broad areas: 419 o those capabilities that are intrinsic to the endpoint and its 420 network connectivity 422 o those that protect against the execution of problematic code 424 o those that protect against malware installation and execution 426 o those that protect against weaknesses in applications. 428 In the following sections, examples of these capabilities are 429 provided. 431 4.2.1. Intrinsic Capabilities 433 o Software updates / patching 435 o Access Control (RBAC, ABAC, etc.) 437 o Authentication 439 o Authorization 441 o Detailed event logging 443 4.2.2. Execution protection 445 o Exploit mitigation (file/memory) 447 o Tamper protection 449 o Whitelisting filter by signatures, signed code or other means 451 o System hardening and lockdown (HIPS, trusted boot, etc.) 453 4.2.3. Malware protection 455 o Scanning - on access/on write/scheduled/quick scan (file/memory) 457 o Reputation-based blocking on files or by ML 459 o Behavior-based detection - (heuristic based/ML) 461 o Rootkit and firmware detection 462 o Threat intelligence based detection (cloud-based/on premise) 464 o Static detection - generic, by emulation, by ML, by signature 466 4.2.4. Attack/Exploit/Application Protection 468 4.2.4.1. Application protection (browser, messaging clients, social 469 media, etc.) 471 o Disinformation Protection (anti-phishing, fake news, anti-spam, 472 etc.) 474 o Detection of unintended link location (URL blocklist, etc.) 476 o Memory exploit mitigation, e.g. browsers 478 4.2.4.2. Network Protection (local firewall, IDS, IPS and local proxy) 479 inbound and outbound 481 o Detection of network manipulation (ARP, DNS, etc.) 483 o Data Loss Prevention and exfiltration detection (incl. covert 484 channels) 486 5. Optimal Properties of an Endpoint Security Solution 488 It is impossible to provide a complete list of the properties of an 489 optimal endpoint security solution. The evolution of the threat 490 landscape ensures that endpoint security solutions will require new 491 features in the future. However, it is possible to provide a (non- 492 exhaustive) list of properties - in the spirit of best practices - 493 for an endpoint security solution. 495 o find instantly accurate reputation for any file before it gets 496 executed and block it if needed. 498 o monitor any behavior on the endpoint, including inbound and 499 outbound network traffic, learn and identify normal behavior and 500 detect and block malicious actions, even if the attack is misusing 501 legitimate clean system tools or hiding with a rootkit. 503 o patch instantly across all devices/systems/OSes, including virtual 504 patching, meaning you can patch or shield an application even before 505 an official patch is released. 507 o exploit protection methods for all processes where applicable, 508 e.g. no execute bit (NX), data execution prevention (DEP), address 509 space layout randomization (ASLR), Control Flow Integrity Guard 510 (CFI/CFG), stack canaries, shadow stack, reuse attack protection 511 (RAP), etc. all of which are methods, which make it very difficult 512 to successfully run any exploit, even for zero day vulnerabilities. 514 o detect attempts to re-route data to addresses other than those 515 which the user intended, e.g. detect incorrectly served DNS entries, 516 TLS connections to sites with invalid certificates, data that is 517 being proxied without explicit user consent, etc. 519 o have an emulator/sandbox/micro virtualization to execute code and 520 analyse the outcome and perform a roll back of all actions if 521 needed, e.g. for ransomware. 523 o allow the endpoint to communicate with the other endpoints in the 524 local network and globally, to learn from 'the crowd' and 525 dynamically update rules based on its findings. 527 o be in constant sync with all other endpoints deployed on a network 528 and other security solutions, run on any OS, with no delay 529 (including offline modes and on legacy systems). 531 o run from the OS/EE when possible. 533 o run as one of the first process on the OS/EE and protect itself 534 from any form of unwanted tampering. 536 o offers a reliable logging that can't be tampered with, even in the 537 event of system compromise. 539 o receive updates instantly from a trusted central entity. 541 6. Case Studies in the Limitations of Endpoint Security Only 543 The previous section discusses what some of the optimal features of 544 endpoint security 'system' would be. However, a more realistic view, 545 based on operational security data would indicate: 547 o may not be able to run at full capacity due to computational power 548 limits, battery life, performance, or policies (such as BYOD 549 restrictions in enterprise networks), etc. 551 o may not be able to run at full capacity as it slows down 552 performance too much. 554 o will miss some of the malware or attacks, regardless of detection 555 method used, like signatures, heuristics, machine learning (ML), 556 artificial intelligence (AI), etc. 558 o have some level of False Positives (FP). 560 o not monitoring or logging all activities on the system, e.g. due 561 to constraints of disk space or when a clean windows tool is being 562 triggered to do something malicious but the activity is not logged. 563 Such activity can be logged, but a decision needs to be made if it's 564 clean or not. 566 o have its own vulnerabilities or simple instabilities that could be 567 used to compromise the system. 569 o be tampered with by the user, e.g. disabled or reconfigured. 571 o be tampered with by the attacker, e.g. exceptions added or log 572 files wiped. 574 In the following section, a number of these limitations are reviewed 575 in case studies.. Some limitations are absolute, and some 576 limitations result in a grey area or suboptimality for the endpoint 577 security solution. 579 6.1. Unable to put an endpoint security add-on on the UE 581 We have seen that UEs will vary a lot; by 2022, an estimated 29 582 billion devices will be connected, with 18 billion of them related 583 to IoT [9]. Many IoT products lack the capacity to install any 584 endpoint security capabilities, are unable to update the software, 585 and it is not possible to force the UE provider to improve or even 586 offer an intrinsic security capability. 588 In IoT we find UEs such as medical devices which are limited by 589 regulation, welding robots that can't be slowed down, smart light 590 bulbs which are limited by the processing power, etc. There are many 591 factors influencing whether endpoint security can be added to a UE: 593 * The UE is simply not powerful enough or the performance hit is too 594 high. 596 * Adding your own security will breach the warranty or will 597 invalidate a certification or a regulation (breach of validity). 599 * The UE needs to run in real-time and any delay introduced by a 600 security process might break the process. 602 * Some UEs are simply locked by design and the manufacturer does not 603 provide a security solution (e.g. smart TV, fitness tracker or 604 personal artificial assistants) see [10], [11]. 606 In the future, a possible research problem would be to find hard 607 data on the exact proportion of IoT devices that are unable to run 608 any endpoint security add-on or that have no intrinsic security 609 built-in. 611 The other hidden dimension here is the economical aspect. Many 612 manufacturer are reluctant to invest in IoT device security, because 613 it can significantly increases the cost of their solution and there 614 is the perception that they will lose market shares, as customers 615 are not prepared to pay the extra cost for added security. 617 6.1.1. Not receiving any updates or functioning patches 619 The endpoint security system may lack a built-in capability to be 620 patched or it may be connected to a network that prevents the 621 process of downloading updates automatically. For example stand- 622 alone medical systems or industrial systems in isolated network 623 segments often do not have a communication channel to the Internet. 625 Even if security updates are received, they typically will only be 626 periodically updated; hence there will be a window of opportunity 627 for an attacker, between the time the attack is first used, and the 628 time the attack is discovered/patched and the patch is deployed. 630 In addition updates and patches may themselves be malicious by 631 mistake, or on purpose if not properly authenticated, or if the 632 source of the updates has malicious intent. This could be part of a 633 software update supply chain attack or an elaborate attacker 634 breaking the update process, as for example seen with the Flamer 635 group (see [12]). 637 A recent survey found that fewer than 10% of consumer IoT companies 638 follow vulnerability disclosure guidelines at all, which is regarded 639 as a basic first step in patching vulnerabilities (see [13]). This 640 indicates that many IoT devices do not have a defined update process 641 or may not even create patches for most of the vulnerabilities. 643 Furthermore some endpoints system may reach the end of their support 644 period and therefore no longer receive any updates for the OS/EE or 645 the security solution due to missing licenses. However the systems 646 may remain in use and become increasingly vulnerable as time goes on 647 and new attacks are discovered. 649 In the following sections, individual examples of attacks on 650 endpoints unable to provide for their own security are examined. In 651 each case, the description of the attack follows the format of . . . 653 6.1.2. Mirai IoT bot 655 6.1.2.1. Mirai Description 1 657 | Description | A Mirai bot infecting various IoT devices through 658 weak passwords over Telnet port TCP 23 and by using various 659 vulnerabilities, for example the SonicWall GMS XML-RPC Remote Code 660 Execution Vulnerability (CVE-2018-9866) on TCP port 21009. Once a 661 device is compromised it will scan for further victims and then 662 start a DoS attack. | 664 | Simplified attack process | Compromised device scans network for 665 multiple open ports, attempts infection through weak password and 666 exploits, downloads more payload, starts DoS attack. | 668 | UE | No security tool present on majority of IoT devices, hence no 669 detection possible. If a rudimentary security solution with limited 670 capabilities such as outgoing firewall is present on the IoT device 671 e.g. router, then it might be able to detect the outbound DoS attack 672 and slow it down. | 674 | References | [14] }[15] | 676 6.1.2.2. Mirai Description 2 678 | Name | Mirai | 680 | Description | A device infection for participation into a botnet 681 activity | 683 | Endpoint Targeted | IoT Devices | 685 | Attack Surface Categories Involved | Telnet remote access; Weak 686 default and existing passwords; Code vulnerabilities in exposed 687 services | 689 | Attack Surface Examples | Weak passwords over Telnet TCP port 23; 690 SonicWall GMS XML-RPC Remote Code Execution Vulnerability (CVE-2018- 691 9866) on TCP port 21009 | 693 | Attack Objective | Deployment of a custom code or commands on the 694 device for participation in botnet activities | 695 | Attack Category | Botnet Deployment; DDoS | 697 | Attack Orchestration | Exploit remote access weaknesses on the 698 device to deploy a bot on the device | 700 | Mitigation | If a rudimentary security solution with limited 701 capabilities such as outgoing firewall is present on the IoT device 702 e.g. router, then it might be able to detect the added bot or the 703 outbound DoS attack and slow it down | 705 | Attack Surface Minimisation | Better password management; Uptodate 706 patching | 708 | References | [14] [15] | 710 6.2. Endpoints may not see the malware on the endpoint 712 6.2.1. LoJax UEFI rootkit 714 | Description | A device compromised with the LoJax UEFI rootkit, 715 which is active before the OS/EE is started, hence before the 716 endpoint security is active. It can pass back a clean 'image' when 717 the security solution tries to scan the UEFI. Infection can either 718 happen offline with physical access or through a dropper malware 719 from the OS/EE. | 721 | UE | A perfect endpoint security could potentially detect the 722 installation process if it is done from the OS/EE and not with 723 physical modification or in the factory. Once the device is 724 compromised the endpoint security solution can neither detect nor 725 remove the rootkit. The endpoint solution may detect any of the 726 exhibited behaviour, for example if the rootkit drops another 727 malware onto the OS/EE at a later stage. | 729 | Reference | [16] | 731 6.2.2. SGX Malware 733 | Description | Malware can hide in the Intel Software Guard 734 eXtensions (SGX) enclave chip feature. This is a hardware-isolated 735 section of the CPU's processing memory. Code running inside the SGX 736 can use return-oriented programming (ROP) to perform malicious 737 actions. | 739 | UE | Since the SGX feature is by design out of reach for the 740 OS/EE, an endpoint security solution can neither detect nor remove 741 any injected malware. A perfect endpoint security solution could 742 potentially detect the installation process if it is done from the 743 OS/EE and not with physical modification or in the factory. | 745 | References | [17] [18] | 747 6.2.3. AMT Takeover 749 | Description | A targeted attack group can remotely execute code on 750 a system through the Intel AMT (Active Management Technology) 751 vulnerability (CVE-2017-5689) over TCP ports 16992/16993. This 752 provides full access to the computer, including remote keyboard and 753 monitor access. The attacker can install malware, modify the system 754 or steal information. | 756 | UE | The AMT is accessible even if the PC is turned off. Therefore 757 any endpoint security software installed on the OS, would not be 758 able to see this traffic and therefore also not able to detect it. | 760 | References | [19], [20] | 762 6.2.4. AMT case study (anonymised) 764 An enterprise has a data center containing very sensitive data. 765 Their workstations use a certain Intel chipset which integrates the 766 AMT feature for remote computer maintenance. AMT is an interface for 767 hardware management of the workstations, including transmission of 768 screen content and keyboard and mouse input for remote maintenance. 769 Communication with the management workstation is implemented by AMT 770 through the network interface card (NIC) on the motherboard. The 771 network packets generated in this way are invisible both to the main 772 processor and thus to the OS running on the workstation. In autumn 773 of 2015, it became known that some AMT-enabled computers had a flaw 774 that allowed AMT's remote maintenance component to be activated and 775 configured by attackers. This also worked when the workstations were 776 switched off. The leakage of data through this vulnerability is 777 elusive and difficult to detect. The identified threat situation led 778 the organization to a new requirement implementing a method that can 779 reliably detect this and similar vulnerabilities. In particular, the 780 detection of rootkits and manipulated firmware, and this includes 781 also (UEFI) BIOS - has also been a focus of their attention. 783 The method used as a solution, compares the desired data packets 784 generated by a client operating system - the user, with the data 785 packets received on the switch port. If more data has been received 786 on the switch port than was been sent by the operating system - the 787 user, there is a strong possibility that something bad is happening 788 - like for example an infection via modified firmware or by rootkit. 790 6.2.5. Users bypass the endpoint security 792 | Description | Endpoint security systems should not interfere with 793 the normal operation of the endpoint to the extent that users become 794 frustrated and want to disable them or configure them to disable a 795 significant fraction of important security capabilities. | 797 | UE | Add-on endpoint security is now bypassed or disabled by the 798 user. Unless the endpoint is under monitored management or can 799 prevent a user from modifying the configuration, then this is 800 shutting down a significant fraction of the security capabilities. | 802 | References | [21] | 804 6.3. Endpoints may miss information leakage attacks 806 Another aspect that endpoint security has issues in detecting are 807 information disclosure or leakage attacks, especially on shared 808 virtual/physical systems. 810 6.3.1. Meltdown/Specter 812 The Meltdown/Specter vulnerabilities and all its variants may allow 813 reading of physical memory belonging to another virtual machine (VM) 814 on the same physical system. This could reveal passwords, 815 credentials, certificates etc. The trick is that an attacker can 816 spin up his own VM on the same physical hardware. As this VM is 817 controlled by the attacker, they will ensure that there is no 818 endpoint security that detects the Meltdown exploit code when run. 819 It is very difficult for the attacked VM to detect the memory read- 820 outs. For known CPU vulnerabilities there are software patches 821 available than can be applied. If it is an external service 822 provider, it might not be in the power of the user to patch the 823 physical system or to determine if this has been done by the 824 provider. 826 6.3.2. Network daemon exploits 828 Other attack types, which leak memory data from a vulnerable web 829 server, are quite difficult to detect for an endpoint security. For 830 example the Heartbleed bug allows anyone on the Internet to read the 831 memory of the systems protected by the vulnerable versions of the 832 OpenSSL software. This could lead to credentials or keys being 833 exposed. An endpoint solution needs to either patch the vulnerable 834 application or monitor it for any signs of exploitation or data 835 leakage and prevent the data from being exfiltrated. 837 6.3.3. SQL injection attacks 839 A SQL injection attack is an example of an attack that exploits the 840 backend logic of an application. Typically, this is a web 841 application with access to a database. By encoding specific command 842 characters into the query string, additional SQL commands can be 843 triggered. A successful attack can lead to the content of the whole 844 database being exposed to the attacker. There are other similar 845 attacks that can be grouped together for the purpose of this task, 846 such as command injection or cross site scripting (XSS). Although 847 they are different attacks, they all at their core fail at input 848 filtering and validation, leading to unwanted actions being 849 performed. 851 Applications that are vulnerable to SQL injections are very common 852 and are not restricted to web applications. An endpoint solution 853 needs to monitor all data entered into possible vulnerable 854 applications. This should include data received from the network. A 855 generic pattern matching for standard SQL injection attack strings 856 can be applied to potentially block some of the attacks. In order to 857 block all types of SQL injection attacks the endpoint solution 858 should have some knowledge about the logic of the monitored 859 application, which helps to determine how normal requests differ 860 from attacks. 862 Applications can be analysed at source code level for potential 863 weaknesses, but dynamically patching is very difficult. See { [22] } 865 6.3.4. Low and slow data exfiltration 867 An endpoint security solution can detect low and slow data 868 exfiltration, for example when interesting data sources are tracked 869 and access to them is monitored. If the data source is not on the 870 endpoint itself, e.g. a database in the network, then the received 871 data needs to be tagged and its further use needs to be tracked. To 872 make detection difficult, an attacker could decide to use an 873 exfiltration process that sends only 10 bytes every Sunday to a 874 legitimate cloud service. If that is not in the normal behavior 875 pattern, then this anomaly could be detected by the endpoint. If the 876 process that sends the data or the destination IP address have a bad 877 reputation, then they could be stopped. Though it is very difficult 878 to reliably block such an attack and most solutions have a specific 879 threshold that needs to be exceeded before it is detected as an 880 anomaly. 882 6.4. Suboptimality and gray areas 884 6.4.1. Stolen credentials 886 Stolen credentials and misuse of system tools such as RDP, Telnet or 887 SSH are a valid scenario during attacks. An attacker can use stolen 888 credentials to remotely log into a system and access data or execute 889 commands in this context like the legitimate user might do. An 890 endpoint security solution can restrict access from specific IP 891 addresses, but this is difficult in a dynamic environment and when 892 an attacker might have already compromised a trusted device and 893 misuse it as a stepping stone for lateral movement. The endpoint 894 could perform additional checks of the source device, such as 895 verifying installed applications and certain conditions. Again this 896 will not work in all scenarios, e.g. a hijacked valid device during 897 lateral movement. 899 This means that the system will not be able to simply block the 900 connection if the authentication with the stolen credentials 901 succeeds. A multi factor authentication (MFA) could limit the use of 902 stolen credentials, but depending on the system used and the 903 determination of the attacker they might be able to bypass this 904 hurdle as well e.g. cloning a SIM card to read text message codes. 906 As a next step, a solution on the endpoint can monitor the behavior 907 of the logged in user and determine if it represents expected normal 908 behavior. Unfortunately, there is the chance for false positives 909 that might block legitimate actions, hence the rules are usually not 910 applied too tightly. The system can monitor for suspicious behavior, 911 similar to malware detection, where every action is carefully 912 analyzed and all activity is tracked. For example if the SSH user is 913 adding all files to archives with passwords and then deletes the 914 original files in the file explorer, then this could result in a 915 ransomware case scenario. If only a few files are processed per 916 hour, then this activity will be very difficult for the endpoint to 917 distinguish from normal activity, in order to flag it as malicious. 919 The problem of attackers blending in with normal activity is one of 920 the biggest challenges with so called living off the land attack 921 methods. The attacker chooses to keep their profile low by not 922 installing any additional binary files on the system, but instead 923 misuses legitimate system tools to carry out their malicious intent. 924 This means that there is no malware file that could be identified 925 and the detection relies solely on other methods such as behaviour 926 based monitoring { [23] }. 928 If information is shared across multiple endpoints, then each one 929 could learn from the others and see how many connections came in 930 from that source, what files were involved and what behavior the 931 clients exhibited. This crowd wisdom approach would allow blocking 932 rules to be applied after the first incident across multiple 933 endpoints. 935 6.4.2. Zero Day Vulnerability 937 | Description | An attacker exploits a zero day vulnerability or any 938 recent vulnerability. | 940 | UE | In theory this scenario could be handled by the endpoint 941 security: a) Once the intrinsic security system has been patched, 942 exploitation of the vulnerability can be prevented. b) The add-on 943 security with enhanced capabilities or updated methods can detect 944 and mitigate the vulnerability. It does not necessarily require the 945 official patch.| 947 | Challenge | In practice many systems remain vulnerable to a 948 vulnerability months or even years after a security fix has been 949 released. Moreover there is a big gap between when a vulnerability 950 is disclosed and when a security fix is available. Also there is a 951 big gap between when a security fix is available and when the 952 security fix is actually applied. A recent study over three years, 953 examined the patching time of 12 client-side and 112 server-side 954 applications in enterprise hosts and servers. It took over 6 months 955 on average to patch 90% of the population across all 956 vulnerabilities. { [24] }. We note too: "The patching of servers is 957 overall much worse than the patching of client applications. On 958 average a server application remains vulnerable for 7.5 months." | 960 | References | { [25] }{{ [26] } | 962 6.4.3. Port scan over the network 964 An infected machine, let's say a Mirai bot on a router, is scanning 965 a class B network for IP addresses with TCP port 80 open. The 966 malware can slow it down to 1 IP address per 5 seconds (or any other 967 threshold) and it can go in randomized order (like for example the 968 nmap tool does) in order to make it difficult to find a sequential 969 pattern. To increase detection difficulties, legitimate requests to 970 existing web servers can be added in at random intervals. 972 An endpoint solution might be able to detect this behaviour, 973 depending on the threshold, but it will be difficult. At some point 974 the pattern will be similar to browsing the web, so either the 975 endpoint blocks the bot scanning and also the user from surfing, or 976 it allows both. 978 To make it even harder, the attacker can use a botnet that 979 communicates over peer-to-peer (P2P) or a central command and 980 control server (C&C) and then distribute the scan load over multiple 981 hosts. This means each endpoint only scans a subset, let's say 100 982 IP addresses, but all 1,000 bots scan a total of 100,000 IP 983 addresses. 985 This attack is difficult to detect by a reasonable threshold on each 986 endpoint individually. If the endpoints talk to each other and 987 exchange information, then a collective decision can be made on the 988 bigger picture of the bot traffic. 990 Another option for the endpoint solution is to block the bot malware 991 from operating on the computer, for example by detecting the 992 installation, analyzing the behavior of the process or by preventing 993 the binary from accessing the network. This includes blocking any 994 form of communication for the process to its C&C server, regardless 995 of if it is using a P2P network or misusing legitimate system tools 996 or browsers to communicate with the Internet. Blocking indirect 997 communication over system tools as part of living off the land 998 tactics, can be very challenging. 1000 See { [27] } 1002 6.4.4. DDoS attacks 1004 For this example let us consider a botnet of 100,000 compromised 1005 computers and each one sends a burst of traffic to a remote target, 1006 for one second each, alternating in groups. This will generate some 1007 waves of pulse attack traffic. Similar comments can be made about 1008 overall pulsed DDoS attacks { [28] }. 1010 A solution on the endpoint can attempt to detect the outgoing 1011 traffic. If the DoS attack is volume based and the time span of each 1012 pulse is large enough or the repeating frequency for each bot is 1013 high, then detection with thresholds on the endpoint is feasible. It 1014 is different, if it is an application layer DoS attack, where the 1015 logic of the receiving application is targeted, for example with too 1016 many search queries in HTTP GET requests. This would flood the 1017 backend server with intensive search requests, which can result in 1018 the web site no longer being responsive. Such attacks can succeed 1019 with a low amount of requests being sent, especially if its 1020 distributed over a botnet. This makes it very difficult for a single 1021 endpoint to detect such an ongoing attack, without knowledge from 1022 other endpoints or the network. 1024 Another option for the endpoint solution is to block the bot malware 1025 from operating on the computer, for example by detection the 1026 installation, analyzing the behavior of the process or by preventing 1027 the binary from accessing the network. This includes blocking any 1028 form of communication for the process to its C&C server, regardless 1029 of if it is using a P2P network or misusing legitimate system tools 1030 or browsers to communicate with the Internet. Blocking indirect 1031 communication over system tools as part of living off the land 1032 tactics, can be very challenging. 1034 7. Defense-in-depth from the perspective of protocol design 1036 While endpoint security systems have good capabilities (for 1037 instance, those seen in section 5 above), sometimes it is debatable 1038 and perhaps suboptimal to let the endpoint run the capability alone 1039 or at all. It is generally considered good security practice to 1040 adopt a defense-in-depth approach (see [29]). The Open Web 1041 Application Security Project group (OWASP) describes the concept as 1042 follows: 1044 "The principle of defense-in-depth is that layered security 1045 mechanisms increase security of the system as a whole. If an attack 1046 causes one security mechanism to fail, other mechanisms may still 1047 provide the necessary security to protect the system." (see [29]). 1049 Indeed, there are many other constituencies as per our end-to-end 1050 model that can participate in the defence process: The network, the 1051 infrastructure itself, the platform, the human, the user experience 1052 and in a hybrid of an on premise and cloud approach, an Integrated 1053 Cyber Defence (ICD) of the entire chain. 1055 The simple idea behind the concept is that "every little bit helps". 1056 If the endpoint is not 100% secure itself, the detection chance can 1057 increase with additional security capabilities from other entities. 1058 We acknowledge that there are some case where adding an additional 1059 component to the system may degrade the overall security level by 1060 introducing new weaknesses. 1062 There are various reference articles in the industry highlighting 1063 limitations of endpoint only solutions. For example this quote here, 1064 which talks about multi-tier solutions: 1066 "There are limitations with any endpoint protection solution, 1067 however, that can limit protection to only the client layer. There 1068 is also a need for security above the client layer, as endpoint 1069 protection products cannot intercept traffic. Vendors will often 1070 sell a multi-tiered solution that enables a network appliance to 1071 assist the endpoint protection client by intercepting traffic 1072 between the attacker and the infected client. Vendors will also sell 1073 solutions that monitor and intercept traffic on internal or external 1074 network segments to protect the enterprise from these threats. A 1075 prime example of the limitations of endpoint protection software is 1076 infection via a phishing attack." [30]. 1078 Some sources point out that even the best solution might not get 1079 deployed in the optimal way in a real world scenario as the 1080 environment can be very complex: 1082 "While endpoint security has improved significantly with the 1083 introduction of application whitelisting and other technologies, our 1084 systems and devices are simply too diverse and too interconnected to 1085 ensure that host security can be deployed 100% ubiquitously and 100% 1086 effectively." [31] 1088 On these grounds it is considered a good idea to follow a layered 1089 approach when it comes to security. 1091 "In today's complex threat environment, companies need to adopt a 1092 comprehensive, layered approach to security, which is a challenging 1093 task in such as rapidly evolving, crowded market." [331] 1095 It is important to comprehend the capabilities of endpoint security 1096 solutions in this overall picture of the connected environment, 1097 which includes other systems, networks and various protocols that 1098 are used to interact with these entities. Understanding possible 1099 shortcomings from single layered solutions can help counterbalance 1100 such weaknesses in the architectural concept or the protocol design. 1102 8. Endpoint security from the perspective of protocol design 1104 The previous sections have reviewed two models for endpoints on the 1105 Internet, a review of how endpoints have evolved, an examination of 1106 the features of endpoint security and - finally - a view of how 1107 endpoint security, alone, may not be sufficient to protect endpoints 1108 and users in a evolved Internet. A taxonomy of endpoints is provided 1109 in a companion draft [2]. The evolution has brought a significant 1110 set of new threats and there is evidence that endpoint security is 1111 not enough to protect against those threats. 1113 This is an observation about operational security, but what does it 1114 mean for protocol design? 1116 8.1. Simplicity of design is important 1118 Protocol design is often informed by attempting to get all possible 1119 use cases addressed in early versions of the protocol design. It is 1120 widely observed that subsequent versions of a protocol - popular or 1121 not - are difficult to achieve. However, simplicity in protocol 1122 design ensures that a protocol will be well-understood at design- 1123 time, it can be modelled and receive a full (and, perhaps formal) 1124 security analysis. The Security Directorate already routinely 1125 reviews protocols in Last Call for their security characteristics - 1126 a practice that should endure. However, making protocol design 1127 decisions that allow for easy, open review helps build confidence in 1128 the security of the underlying design. 1130 It is certain that there will always be unintended consequences in 1131 choices made at protocol design time. However, if the underlying 1132 protocol is not overly complex, those unintended consequences can be 1133 limited. It also make possible modularization or code-reuse allowing 1134 for the reuse of security analysis from one protocol to another. 1136 It is worth noting that implementation is also affected by protocol 1137 design decisions. Complex or poorly defined methods for deployment 1138 of software that implements a protocol means that they are more 1139 likely to be deployed incorrectly or insecurely. 1141 8.2. Diversity in protocol design 1143 Protocol design can include decisions that limit - or, encourage the 1144 limitation - or service diversity. This has market-facing risks but 1145 also has security implications. Where a protocol is too complex to 1146 upgrade or implement, only those with the necessary resources are 1147 likely to benefit from the deployment. Where larger stakeholders 1148 dominate deployment of a particular protocol - because of its 1149 underlying design - the result can be a limited pool of deployments 1150 with potentially smaller numbers of points of failure. 1152 When protocol choices lead to lack of service diversity, this also 1153 increases the risk of shared vulnerabilities among a small set of 1154 providers of service. In this case, the attractiveness of the target 1155 becomes higher as the number of service implementation becomes 1156 lower. 1158 Protocol design should encourage diversity of service provision. 1160 8.3. Protocol design and failure of intermediaries 1162 The rise of intermediaries has been an important feature of the 1163 evolution of the Internet. In a prior era, it would have been 1164 natural and sufficient to concentrate on deploying security at 1165 endpoints. The end-to-end principle seems to encourage thinking of 1166 building intelligence - and thus, protection - at the edges of the 1167 network. 1169 From previous sections, it is apparent that a strict view of the 1170 end-to-end model no longer applies. Even the model for an endpoint, 1171 as provided in section 2, no longer can support the view of endpoint 1172 protection being for the device or UE. The result is the security of 1173 the endpoint is, in part, dependent on the security of the 1174 middleboxes and intermediary hosts that provide services. 1176 From the point of protocol design, planning for this includes 1177 planning for when those intermediaries are compromised, unavailable 1178 or stop delivering expected services correctly. Protocols that 1179 depend upon intermediaries should clearly adapt to failure modes of 1180 the intermediaries and give choices to endpoint on what actions to 1181 take in the event of third-party failure. 1183 8.4. Protocol evolution 1185 A core message in this draft is that: as the Internet evolves, its 1186 endpoints do as well, and with them the threats they face. Even 1187 ancient protocols are rarely static - especially if they have any 1188 deployment base. 1190 As protocols evolve their designers have to achieve a balance 1191 between interoperability, strictness, agility and extensibility. 1192 Considering this deployment, and altered use case, during design has 1193 the property of making protocol evolution more secure. 1195 Care must be taken, especially in complex protocols where many new 1196 use cases are being account for, in development of the evolution. It 1197 may make the underlying protocol so complex that few are able to 1198 implement it securely. Thus, while the protocol itself may be 1199 secure, it's complexity makes for error in implementation which 1200 leads to operational security problems. 1202 9. Security Considerations 1204 This document is all about security considerations of operational 1205 security for endpoints. In particular it provides a model for 1206 endpoint security and then discusses why traditional approaches to 1207 endpoint security are no longer sufficient. 1209 10. IANA Considerations 1211 This memo contains no instructions or requests for IANA. The authors 1212 continue to appreciate the efforts of IANA staff in support of the 1213 IETF. 1215 11. Acknowledgements 1217 The original idea for this draft came from another, now expired 1218 draft [33]. The authors of that draft intended a comprehensive 1219 discussion of endpoint security and a clear description of how the 1220 evolution of the Internet made endpoint security - on its own - 1221 insufficient. 1223 The author thanks those previous contributors: Arnaud Taddei, Bret 1224 Jordan, Candid Wueest, Chris Larsen, Andre Engel, Kevin Roundy, 1225 Yugiong Sun, and David Wells. 1227 The author also extends his appreciation to the discussions in the 1228 IAB Activity called model-t where the future of the Internet's 1229 threat landscape has also been discussed. 1231 This document was prepared using 2-Word-v2.0.template.dot. 1233 12. References 1235 12.1. Informative References 1237 [1] Thaler, D. and Tschofenig, H., Pei, M., Tsukamoto, A., " Trust 1238 Execution Environment Protocol ", draft-ietf-teep-protocol-02 1239 (work in progress), April 2020. 1241 [2] McFadden, M., "Evolution of Endpoint Security - A Taxonomy for 1242 Endpoints," draft-mcfadden-opsec-endp-taxonomy-00 (work in 1243 progress), February 2021. 1245 [3] "MITRE CAPEC", , n. 1246 d. 1248 [4] "MITRE ATT&CK", , n.d. 1250 [5] Crotty, J., "New Gartner Report Redefines Endpoints Protection for 2018 1251 ", January 2018, . 1254 [6] Redscan, ., "EPP and EDR - What's the difference?", June 2018, . 1257 [7] Hunt, J., "Advantages and Disadvantages of Three Top Endpoint Security 1258 Vendors", n.d., . 1261 [8] "IT Pro's Guide to Endpoint Protection", n.d., . 1264 [9] Ericsson, ., "Internet of Things forecast", n.d., . 1267 [10] Wueest, C., "How my TV got infected with ransomware and what you can le 1268 arn about it", November 2015, . 1271 [11] Dickson, B., "Millions of smart TVs are vulnerable to hackers", Februar 1272 y 2014, . 1274 [12] Symantec, ., "W32.Flamer Microsoft Windows Update Man-in-the-Middle", J 1275 une 2012, . 1278 [13] Rogers, D., "Handling vulnerabilities as an IoT vendor", December 2018, 1279 . 1282 [14] Symantec, ., "Mirai, what you need to know about the botnet behind rece 1283 nt major DDoS attacks", October 2016, . 1287 [15] Krebs on security, ., "19 Mirai Botnet Authors Avoid Jail Time", Septem 1288 ber 2018, . 1290 [16] ESET, ., "LoJax First UEFI rootkit found in the wild, courtesy of the S 1291 ednit group", September 2018, . 1294 [17] Claburn, T., "Intel SGX safe room easily trashed by white-hat hacking m 1295 arauders Enclave malware demoed", February 2019, . 1298 [18] Cimpanu, C., "Researchers hide malware in Intel SGX enclaves", February 1299 2019, . 1302 [19] Khandelwal, S., "Explained - How Intel AMT Vulnerability Allows to Hack 1303 Computers Remotely", May 2017, . 1306 [20] Symantec, ., "Web Attack Intel AMT Privilege Escalation CVE-2017-5689", 1307 2017, 1310 [21] Smith, K., "9 signs your endpoint security isn't working", May 2017, . 1313 [22] Cobb, M., "SQL injection detection tools and prevention strategies", No 1314 vember 2009, . 1317 [23] Wueest, C., "Living off the land and fileless attack techniques", July 1318 2017, . 1322 [24] Caballero, J., "Mind Your Own Business A Longitudinal Study of Threats 1323 and Vulnerabilities in Enterprises", February 2019, 1327 [25] McHugh, J., "Windows of Vulnerability A Case Study Analysis", 2000, . 1330 [26] Plattner, B., "Large-Scale Vulnerability Analysis", September 2006, . 1334 [27] Marinho, R., "Exploring a P2P transient botnet - From Discovery to Enum 1335 eration", July 2017, . 1338 [28] Seals, T., "Pulse-Wave DDoS Attacks Mark a New Tactics in Q2", October 1339 2017, . 1342 [29] UK, GOV., "Secure by Design", February 2019, . 1345 [30] Cullen, T., "Limits of endpoint only", July 2017, 1348 [31] Dix, J., "Layered Security Defenses What layer is most critical network 1349 or endpoint", July 2011, . 1353 [32] Hstoday, ., "Layered Approach Critical to Effective Endpoint Protection 1354 ", October 2016, . 1357 [33] Taddei, A., et.al., [I-D:draft-taddei-smart-cless- 1358 introduction], "Capabilities and Limitations of an Endpoint- 1359 only Security Solution, July 2020, (expired). 1361 Appendix A. Operational Experience and Endpoint Security 1363 This appendix attempts to document operational experience related to 1364 endpoint security. The original text in this Appendix comes from 1365 research and experienced from a single security solution provider. 1366 What follows is reporting from that organization. 1368 There are two appaorches to reporting on security incidents that are 1369 based on operational experience. They are: 1371 o the method described in {{MONEYBALL}} 1373 o the anonymised production data of Symantec MSS production for the 1374 past 3 months 1376 The core idea is to consider, based on all the imperfections we 1377 started to list above including the 'grey areas', that cybersecurity 1378 analysts are often presented with suspicious machine activity that 1379 does not conclusively indicate a compromise, resulting in undetected 1380 incidents or costly investigations into the most appropriate remedi 1382 As Managed Security Services Providers (MSSP's) are confronted with 1383 these data quality issues, but also possess a wealth of cross- 1384 product security data that enables innovative solutions, we decided 1385 to use the Symantec MSS service for the past 3 months. The Symantec 1386 MSS service monitors over 100 security products from a wide variety 1387 of security vendors for hundreds of enterprise class customers from 1388 all verticals. 1390 We selected the subset of customers using the service that deploy 1391 both network and endpoint security products to determine which types 1392 of security incidents were most likely to be detected by endpoint 1393 products vs. network products. In doing so, we were particularly 1394 interested in identifying which categories of incidents are detected 1395 by endpoint products and not network products, and vice versa. Thus, 1396 we examined prevalent categories of incidents for which the only 1397 actionable security alerts were predominantly produced by one type 1398 of security product and not the other. To do so, we extracted all 1399 security incidents detected by Symantec MSS on behalf of hundreds of 1400 customers that deploy both network and endpoint security products, 1401 over a three-month period from December 2018 through the end of 1402 February 2019. We acknowledge that some attacks might have been 1403 blocked by the first product and therefore have never been seen by 1404 the next security solution, which influences the final numbers. 1406 With this in mind, we could identify incidents based on: 1408 | Severity | 4 - Emergency, 3 - Critical, 2 - Warning, 1 - 1409 Informational | 1411 | Incident Category | Malicious Code, Deception Activity, Improper 1412 Usage, Investigation, etc. | 1414 | Incident Type | Trojan Horse Infection, Suspicious DGA Activity, 1415 Suspicious Traffic, Suspicious URL Activity, Backdoor infection, 1416 etc. | 1418 | # network incidents | Amount of network only security incidents | 1420 | # all incidents | What is the total amount of incidents on all 1421 security solutions | 1423 | Percentage | Percentage of network security only incidents | 1425 We ended up with 1427 o Hundreds of thousands of security incidents 1429 o which we could categorize in 275 incident types by category and 1430 severity (triplets Severity-Category-Type) 1432 o out of which we searched how many incidents of each type were 1433 detected by a network security product and missed by deployed 1434 endpoint security products at least 75% of the time or vice versa 1436 A.1. Endpoint only incidents 1438 The categories of incidents that are detected primarily by endpoint 1439 security products are fairly intuitive. They consist primarily of 1440 detections of file-based threats and detection of malicious 1441 behaviors through monitoring of system and network behavior at the 1442 process level. The most prevalent of these behavioral detections 1443 include detections of suspicious URLs based on heuristics and 1444 blacklists of IP addresses or domain names. Since most of these 1445 alerts are not corroborated by network products, it seems probable 1446 that the blacklists associated with network products tend to be more 1447 focused on attacks while host-based intrusion prevention system 1448 alerts focus more on malware command and control traffic. Most other 1449 behavioral detections at the endpoint provide alerts based on system 1450 behavior that is deemed dangerous and symptomatic of malicious 1451 intent by a malicious or infected process. The highest severity 1452 incidents detected on endpoints are instances of post-compromise 1453 outbound network behavior that are symptomatic of command and 1454 control communications traffic, but these did not show up as being 1455 primarily detected by endpoint products as they are frequently 1456 corroborated by network-based alerts. 1458 A.2. Security incidents detected primarily by network security products 1460 Perhaps less intuitive are the results of examining categories of 1461 security incidents that are detected primarily by network security 1462 products and only rarely corroborated by endpoint security products. 1463 Below we provide details regarding incident categories for which a 1464 network security product produced a detection and for which there 1465 were no actionable endpoint alerts for at least 75% of the incidents 1466 in the category. 1468 In our study we found 32 incident type, category, and severity 1469 triplets of this type. The following categories critical incident 1470 types were reported by MSS customers, and we discuss each in turn in 1471 decreasing order of prevalence: 1473 A.2.1. Unauthorized external vulnerability scans 1475 Perhaps unsurprisingly, unauthorized external attempts to scan 1476 corporate resources for vulnerabilities and other purposes are 1477 detected in large volumes by a broad variety of network-focused 1478 security products. 79% of incidents of this type were detected by 1479 network security products with critical-severity alerts, these 1480 security incident detections are not accompanied by any actionable 1481 endpoint alerts, despite the fact that endpoint security products 1482 are deployed by these enterprises. This category of threats 1483 encompasses a broad variety of attacks, the most prevalent of which 1484 are the following: Horizontal scans, SQL injection attacks, password 1485 disclosure vulnerabilities, directory traversal attacks, and 1486 blacklist hits. Of these categories of detections, horizontal scans 1487 stand out as the category of detection that endpoint-security 1488 products are least likely to detect on their own. 1490 A.2.2. Unauthorized internal vulnerability scans 1492 Unauthorized internal vulnerability scans, though less frequent, are 1493 more alarming, as they are likely to represent possible post- 1494 compromise activity. We note that the Managed Security Service works 1495 with its customers to maintain lists of devices that are authorized 1496 to perform internal vulnerability scans, and their activity is 1497 reported separately at a lower levels of incident severity. 89% of 1498 detected unauthorized internal vulnerability scans are detected by 1499 network products without any corroborating actionable alerts from 1500 endpoint security products. As compared to unauthorized external 1501 scan incidents, internal hosts that perform vulnerability scans are 1502 far more active and the fraction of alerts that detect horizontal 1503 scans is higher, representing half of the total alerts generated. 1504 Alerts focused on Network-Behavior Anomaly Detection also appear for 1505 internal hosts. 1507 A.2.3. Malware downloads resulting in exposed endpoints 1509 This category of threats is generally detected by network security 1510 appliances. Despite these enterprises being purchasers of endpoint 1511 security products, 76% of the incidents detected by the network 1512 security products do not show a corresponding alert by an endpoint 1513 security product. A broad variety of network appliances contributed 1514 to the detection of a diverse collection of malware samples. 1516 A.2.4. Exploit kit infections 1518 This category of infections represents instances in which the 1519 customer's machines are exposed to exploit kits. These threats were 1520 detected by network appliances that extract suspicious URLs from 1521 network traffic taps and use a combination of sandbox technology and 1522 blacklists to identify websites that deploy a variety of exploit 1523 kits that were not being caught by endpoint security products. In 1524 this three month time period, the most prevalent categories of 1525 exploit kits detected involved redirections to the Magnitude exploit 1526 kit and exploit kits associated with phishing scams and attempts to 1527 expose users to fake Anti-Virus warnings and tools. A breakdown of 1528 the results is included below: 1530 | Severity | 3 - Critical | 1532 | Incident Category | Malicious Code | 1534 | Incident Type | Exploit Kit Infection | 1536 | # network incidents | 26 | 1538 | # all incidents | 26 | 1540 | Percentage | 100% | 1541 The network security product that detected these incidents produced 1542 the following alerts: 1544 o Advanced Malware Payloads 1546 o Exploit.Kit.FakeAV 1548 o Exploit.Kit.Magnitude 1550 o Exploit.Kit.MagnitudeRedirect 1552 o Exploit.Kit.PhishScams 1554 o HTMLMagnitudeLandingPage 1556 A.2.5. Attacks against servers 1558 In addition to detecting the aforementioned critical security 1559 incident categories, network security devices frequently detect a 1560 broad variety of attacks against servers that usually lack 1561 corroboration at the endpoint. Most server attacks are not matched 1562 by endpoint protection alerts: 62% are unmatched for critical 1563 incidents, and 88% are unmatched as lower severity incidents. This 1564 category of incidents is the most prevalent category of incidents 1565 detected primarily by network products, but they are usually rated 1566 lower in severity than the aforementioned classes of alerts as they 1567 are very commonplace. Even when these alerts are corroborated by 1568 endpoint protection alerts, the endpoint alerts are often low in 1569 severity, as in the case of file-based threats that appear to have 1570 been blocked or successfully cleaned up by an Anti-Virus solution. 1571 The challenge in taking action against server attacks is that it can 1572 be difficult to assess which of these attacks were successful in 1573 causing actual damage, and for this reason, for the fraction of 1574 server attacks that demonstrate corroborating endpoint security 1575 alerts, even if of low severity, should be examined. It is 1576 interesting to note the cooperative role played by both network and 1577 endpoint security devices in these instances. 1579 Authors' Addresses 1581 Mark McFadden 1582 Internet policy advisors ltd uk 1583 6 Bridge Street 1584 Chepstow, Wales NP16 5EY 1585 United Kingdom 1587 Phone: +44 2921 25 3649 1588 Email: mark@internetpolicyadvisors.com