idnits 2.17.1 draft-taddei-smart-cless-introduction-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1831 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Taddei 3 Internet-Draft C. Wueest 4 Intended status: Informational K. Roundy 5 Expires: September 26, 2019 Symantec Corporation 6 D. Lazanski 7 Last Press Label 8 March 25, 2019 10 Capabilities and Limitations of an Endpoint-only Security Solution 11 draft-taddei-smart-cless-introduction-00 13 Abstract 15 In the context of existing, proposed and newly published protocols, 16 this draft RFC is to establish the capabilities and limitations of 17 endpoint-only security solutions and explore benefits and 18 alternatives to mitigate those limits with the support of real case 19 studies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 26, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Endpoints: definitions, models and scope . . . . . . . . . . 6 60 5.1. Internal representation of an endpoint . . . . . . . . . 7 61 5.2. Endpoints modeled in an end-to-end context . . . . . . . 8 62 6. Threat Landscape . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Endpoint Security Capabilities . . . . . . . . . . . . . . . 10 64 8. What would be a perfect endpoint security solution? . . . . . 13 65 9. The defence-in-depth principle . . . . . . . . . . . . . . . 15 66 10. Endpoint Security Limits . . . . . . . . . . . . . . . . . . 16 67 10.1. No possibility to put an endpoint security add-on on the 68 UE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 10.1.1. Not receiving any updates or functioning patches . . 18 70 10.1.2. Mirai IoT bot . . . . . . . . . . . . . . . . . . . 19 71 10.2. Endpoints may not see the malware on the endpoint . . . 19 72 10.2.1. LoJax UEFI rootkit . . . . . . . . . . . . . . . . . 19 73 10.2.2. SGX Malware . . . . . . . . . . . . . . . . . . . . 20 74 10.2.3. AMT Takeover . . . . . . . . . . . . . . . . . . . . 20 75 10.2.4. AMT case study (anonymised) . . . . . . . . . . . . 21 76 10.2.5. Users bypass the endpoint security . . . . . . . . . 22 77 10.3. Endpoints may miss information leakage attacks . . . . . 22 78 10.3.1. Meltdown/Specter . . . . . . . . . . . . . . . . . . 22 79 10.3.2. Network daemon exploits . . . . . . . . . . . . . . 22 80 10.3.3. SQL injection attacks . . . . . . . . . . . . . . . 23 81 10.3.4. Low and slow data exfiltration . . . . . . . . . . . 23 82 10.4. Suboptimality and gray areas . . . . . . . . . . . . . . 24 83 10.4.1. Stolen credentials . . . . . . . . . . . . . . . . . 24 84 10.4.2. Zero Day Vulnerability . . . . . . . . . . . . . . . 25 85 10.4.3. Port scan over the network . . . . . . . . . . . . . 25 86 10.4.4. DDoS attacks . . . . . . . . . . . . . . . . . . . . 26 87 11. Learnings from production data . . . . . . . . . . . . . . . 27 88 11.1. Endpoint only incidents . . . . . . . . . . . . . . . . 28 89 11.2. Security incidents detected primarily by network 90 security products . . . . . . . . . . . . . . . . . . . 29 91 11.2.1. Unauthorized external vulnerability scans . . . . . 29 92 11.2.2. Unauthorized internal vulnerability scans . . . . . 30 93 11.2.3. Malware downloads resulting in exposed endpoints . . 30 94 11.2.4. Exploit kit infections . . . . . . . . . . . . . . . 30 95 11.2.5. Attacks against servers . . . . . . . . . . . . . . 31 96 12. Regulatory Considerations . . . . . . . . . . . . . . . . . . 32 97 12.1. IoT Security . . . . . . . . . . . . . . . . . . . . . . 32 98 12.2. Network infrastructure . . . . . . . . . . . . . . . . . 33 99 12.3. Auditing and Assessment . . . . . . . . . . . . . . . . 33 100 12.4. Privacy Considerations . . . . . . . . . . . . . . . . . 34 101 13. Human Rights Considerations . . . . . . . . . . . . . . . . . 34 102 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 104 16. Informative References . . . . . . . . . . . . . . . . . . . 34 105 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 108 1. Introduction 110 This Internet Draft aims to be a reference to the designers of 111 protocols on the capabilities and limitations of security solutions 112 on endpoint devices against malware and other attacks. As security 113 is entering a new phase in the arms race between attackers and 114 defenders, with many technical, economic and regulatory changes, and 115 with a significant increase in major data breaches, it is a good 116 moment to propose a systematic review and update on what is an old 117 and constantly evolving problem: endpoint security. 119 With the above context in mind this document will focus on the 120 capabilities and limitations of an endpoint-only security solution. 122 We want to explore a number of questions: 124 o What endpoint models do we have? 126 o What is the threat landscape under consideration? 128 o Can we differentiate security and privacy threats? 130 o What are common endpoint security capabilities? 132 o What would be an ideal endpoint security solution? 134 o What are the limits to endpoint security? 136 o What is real production data telling us? 138 o What can defence-in-depth help us with? 140 o What are the economic considerations? 142 o What are the regulatory considerations and constraints? 144 o What are the human rights considerations? 145 Our goal with this review is to describe the benefits and limitations 146 of endpoint security in the real world, rather than in the abstract. 147 We aim to highlight security limitations that cannot be addressed by 148 endpoint solutions and to suggest how these may be mitigated with the 149 concept of a defence-in-depth approach, in order to increase the 150 resilience against attacks and data breaches. 152 2. Abbreviations 154 In this section we provide main abbreviations expansions 156 ABAC Attribute Based Access Control 158 AI Artificial Intelligence 160 AMT Active Management Technology 162 C&C Command and Control 164 CFI Control Flow Integrity 166 CFG Control Flow Guard 168 DDoS Distributed Denial of Service 170 DEP Data Execution Prevention 172 DGA Domain Generating Algorithms 174 DLP Data Loss Prevention 176 DMARC Domain-based Message Authentication, Reporting and Conformance 178 DoS Denial of Service 180 EE Execution Environment 182 EDR Endpoint Detection and Response 184 EPP Endpoint Protection Platform 186 FP False Positive 188 HIPS Host Intrusion Prevention System 190 ICD Integrated Cyber Defence 192 ICMP Internet Control Message Protocol 193 IDS Intrusion Detection System 195 IoT Internet of Things 197 IPS Intrusion Prevention System 199 ML Machine Learning 201 MSS Managed Security Services 203 MSSP Managed Security Services Provider 205 NIST National Institute of Standards and Technology 207 NX No Execute Bit 209 P2P Peer to Peer 211 RAP Reuse Attack Protector 213 RBAC Role Based Access Control 215 RDP Remote Desktop Protocol 217 ROP Return Oriented Programming 219 SANS System Administration, Networking, and Security 221 SGX Software Guard eXtensions 223 SSH Secure SHell 225 UE User Equipment 227 UEFI Unified Extensible Firmware Interface 229 UX User Experience 231 VM Virtual Machine 233 XSS Cross Site Scripting 235 3. Definitions 237 In this section we provide definitions that are marked 239 o (L) Local to this document 240 o (G REFERENCE) Global and then will be preceded by a reference 242 DoS (L) Literally a Denial of Service. Not to be confused with a 243 Network DoS or DDoS. 245 Endpoint security capabilities (L) How to protect the endpoint with 246 three different aspects of protection: 248 o Prevention - The attack doesn't succeed by intrinsic or explicit 249 security capabilities. 251 o Detection - The attack is happening or has happened and is 252 recorded and/or signalled to another component for action. 254 o Mitigation - Once detected, the attack can be halted or its 255 effects can at least be reduced or reversed. 257 System (L) A system is a heterogeneous set of any IT capabilities 258 including hardware, software, endpoints (including IoT), networks, 259 data centers and platforms with no assumptions on deployment form 260 factor (physical, virtual, microservices), deployment scenario, 261 geographic distribution, or dispersion. 263 User Equipment (G ITU-T H.360) Equipment under the control of an End 264 User 266 4. Disclaimer 268 This document is a first draft and is incomplete on purpose. Indeed 269 there are several areas where there are different ways to develop 270 this draft and the authors are seeking for feedback and extended 271 collaboration. This is to be noted too, that this is the first draft 272 RFC for the authors and contributors, so, coaching and help will be 273 appreciated. Overall, 'a bon entendeur, salut'. 275 Comments are solicited and should be addressed to the authors. 277 5. Endpoints: definitions, models and scope 279 Endpoints are the origin and destination for a communication between 280 parties. This encompasses User Equipment (UE) and the Host at the 281 other end of the communication. More work to model the various 282 endpoint types would be helpful for this draft (in the same spirit as 283 the IETF TEEP Working Group generalized its work, see [TEEP]). 285 We require a framework in order to define and model the endpoint 286 itself and the position of the endpoint in the network. In this 287 initial analysis we focus on endpoints that are User Equipment (UE) 288 rather than on hosts. In the future, we hope to balance and unify 289 the model. 291 For example: 293 o The following would be considered as UEs: a smartphone, a smart 294 device, any IoT device, a laptop, a desktop, a workstation, etc. 296 o Hosts represent too, physical servers, virtual servers/machines, 297 etc. 299 We need two models for the endpoint, internally and in an end-to-end 300 context within the network. With this approach we expect both models 301 to help us cover all the threat landscape and capabilities for 302 endpoint security. This will help us understand point attacks versus 303 composite attacks within context, and, accordingly, understand 304 holistically the capabilities and the limitations of endpoint 305 security. For example to differentiate when only an application on 306 the end point is affected. 308 5.1. Internal representation of an endpoint 310 An internal representation of an endpoint could be generalized by the 311 simple diagram below: 313 +----------------------------+ 314 | Application | 315 +----------------------------+ 316 | OS / Execution Environment | 317 +----------------------------+ 318 | Hardware | 319 +----------------------------+ 321 Today there are many combinations of Hardware, OS/EE pairing and 322 Application layers, offering the user a vast set of features with a 323 wide spectrum of capabilities. 325 Furthermore we can consider that an application running on a UE or a 326 host is an endpoint too, so we have multiple ways to read the above 327 diagram. 329 In essence we want to consider here endpoints including those which 330 have a variance in electrical power, computational power, memory, 331 disk, network interfaces, size, ownership, etc. 333 5.2. Endpoints modeled in an end-to-end context 335 A representation of endpoints in an end-to-end context could look 336 like the following diagram: 338 +-------+ +---------------------+---------+ 339 | Human | <- (1) -> | Digital Persona | Application | <- (2) -> 340 +-------+ +-----------+-------------------+ 341 | User Equipment | 342 +-------------------------------+ 344 +----------------+ +----------------+ 345 <- (2) -> | Network | <- (3) -> | Platform/Hosts | 346 | Infrastructure | +----------------+ 347 +----------------+ 349 1. Humans have a user experience (UX) with the UE, starting with an 350 explicit or implicit Digital Persona, engaging with an 351 application 353 2. The application will have sessions through a large Network 354 Infrastructure where we do not assume anything of the 355 infrastructure (could be landlines, mobile networks, satellites, 356 etc.) and those sessions reach 358 3. a Platform consisting of many Hosts either physical or virtual 359 and it ensures a large part of the end-to-end user experience. 361 In this end-to-end model we see that many other systems may have 362 interactions with the UE: the human, the UX, the digital persona, the 363 sessions, the intermediate network infrastructure, and the hosts and 364 application at the destination. 366 If we now look at security aspects of the above models, the threat 367 landscape is very large and the attack surface will cover all the 368 components and interactions at any level. 370 6. Threat Landscape 372 (Editor's note: this section will require a significant amount of 373 future development.) 374 Given the vast number of combinations that the above generic modeling 375 offers us, defining a threat landscape should be done carefully and 376 will require a systematic methodology. 378 Therefore this entire section will be developed through future 379 iterations of the document, in this initial version we will start 380 structuring an approach and then adjust this based on feedback. 382 There is no doubt that we want to cover typical known attacks such 383 as: 385 o Malware (Trojans, viruses, backdoors, bots, etc.) 387 o Adware and spyware 389 o Exploits 391 o Phishing 393 o Script based attacks 395 o Ransomware, local Denial of Service (DoS) attacks 397 o Denial of Service (DoS) attacks 399 o Malicious removable storage devices (USB) 401 o In memory attacks 403 o Rootkits and firmware attacks 405 o Scams and online fraud 407 o System abuse (staging/proxying) 409 o etc. 411 To illustrate the difficulty to define a good threat landscape, when 412 it comes to cryptojacking and coinmining that were on the rise, in 413 which category do they fall: malware? DoS? system abuse? or a 414 category on its own? 416 This is why we wanted to conduct a thorough gap analysis using 417 existing definitions and frameworks, but we couldn't find an existing 418 comprehensive and recognized taxonomy dedicated to the threat 419 landscape on endpoints. We found however different models in this 420 field, and have considered two. We are open to further suggestions. 422 Indeed both of the analysed frameworks contain threat landscape 423 descriptions: 425 o MITRE Common Attack Pattern Enumeration Classification (CAPEC). 426 See [CAPEC]. 428 o MITRE ATT&CK. See [ATTACK]. 430 These offer us interesting ways to assess the threat landscape: 432 o CAPEC offers a hierarchical view of attack patterns by domains 433 which can match some aspects of both of our above models, but we 434 will need to identify those attacks that fit exactly in our scope. 436 o ATT&CK offers a very straightforward categorized knowledge base of 437 attacks, but it concentrates on the entreprise attack chain, so we 438 will need to do some work to extract what we need. 440 We recognise however that these frameworks do not address all of the 441 threats that can affect the security of a system, for example they do 442 not cover; routing hijacking, flooding, selective blocking, 443 unauthorised modification of data sent to an endpoint, etc. Further 444 work to define categories of threats is therefore required. 446 As a further example, phishing should be included as an attack, but 447 whilst this is indeed an attack that will materialize on a device 448 through an application (email, webmail, etc.), the real target of 449 this attack is not the device, but the human behind the digital 450 persona. 452 Having a methodology of assessment is necessary here, because it will 453 help decide what is in scope vs. out of scope. 455 We are aware that once a method and the categories are fully defined 456 in this section, it will force a review of all the following sections 457 in the document. Whilst remapping will be necessary, it should not 458 drastically change the draft. 460 7. Endpoint Security Capabilities 462 In this section we try to define some endpoint security capabilities 463 (Editor's note: this section will require future development.) 465 In this version of the document we will start by developing a 466 framework to categorize and position endpoint security capabilities 467 with the goal of defining what an ideal endpoint security capability 468 would look like. 470 By endpoint security capabilities we mean how to protect the endpoint 471 against attacks. Protection has many meanings, we want to 472 distinguish three different aspects of protection: 474 o Prevention - The attack doesn't succeed by intrinsic or explicit 475 security capabilities. 477 o Detection - The attack is happening or has happened and is 478 recorded and/or signalled to another component for action. 480 o Mitigation - Once detected, the attack can be halted or its 481 effects can at least be reduced or reversed. 483 For example, prevention methods include keeping the software updated 484 and patching vulnerabilities, implementing measures to authenticate 485 the provenance of incoming data to stop the delivery of malicious 486 content, or choosing strong passwords. Detection methods include 487 inspecting logs or network traffic. Mitigation could include 488 deploying backups to recover from an attack with minimal disruption. 490 Our intention however is not just to consider each endpoint security 491 capability separately, but also the overall endpoint security 492 holistically with all its interdependencies. Indeed, we defined a 493 simple endpoint, but each layer may or may not have a certain 494 spectrum of intrinsic capabilities and there may be multiple ways to 495 provide add-on and third-party endpoint security capabilities, 496 allowing complex interactions between all of these components. 498 We define two different aspects of endpoint security capabilities and 499 their subdivisions as: 501 o (A) Intrinsic security capability can be built-into each of the 502 endpoint model layers 504 * (1) Hardware 506 * (2) OS/EE 508 * (3) Application 510 o (B) Add-on security capability can be 512 * (4) a component of the hardware 514 * (5) a component of the OS/EE 516 * (6) an application by itself 518 In (A) we relate to a 'security by design' intention of the 519 developers and they will intrinsically offer a security model and 520 security capabilities as part of their design. A typical example of 521 this is the authorization model. 523 In (B) a 3rd party is offering an additional security component which 524 was not necessarily considered when the Hardware, OS/EE or 525 Application were designed. 527 In the future we will review all the main categories of security 528 capabilities that are known to date and assess security capability 529 enablers like Artificial Intelligence (AI) and Machine Learning (ML). 530 For each category we will try to give a review on how effective the 531 capability is in securing the system. 533 With regard to (6), there are many available options for add-on 534 security capabilities offered by third-parties as applications on a 535 commercial or open-source basis. Gartner (see [GARTNERREPORT]) 536 highlights the evolution of endpoint security towards two directions 537 as shown in [EPPEDR], [EPPSECURITY], [EPPGUIDE]. 539 o Endpoint Protection Platform (EPP) as an integrated security 540 solution designed to detect and block threats at the device level. 542 o Endpoint Detection and Response (EDR) as a combination of next 543 generation tools to provide anomaly detection and alerting, 544 forensic analysis and endpoint remediation capabilities. 546 Among the security capabilities that we list, the endpoint can 547 perform the following: 549 o Intrinsic 551 * Software updates / patching 553 * Access Control (RBAC, ABAC, etc.) 555 * Authentication 557 * Authorization 559 * Detailed event logging 561 o Execution protection 563 * Exploit mitigation (file/memory) 565 * Tamper protection 566 * Whitelisting filter by signatures, signed code or other means 568 * System hardening and lockdown (HIPS, trusted boot, etc.) 570 o Malware protection 572 * Scanning - on access/on write/scheduled/quick scan (file/ 573 memory) 575 * Reputation-based blocking on files or by ML 577 * Behavior-based detection - (heuristic based/ML) 579 * Rootkit and firmware detection 581 * Threat intelligence based detection (cloud-based/on premise) 583 * Static detection - generic, by emulation, by ML, by signature 585 o Attack/Exploit/Application Protection 587 * Application protection (browser, messaging clients, social 588 media, etc.) 590 + Disinformation Protection (anti-phishing, fake news, anti- 591 spam, etc.) 593 + Detection of unintended link location (URL blocklist, etc.) 595 + Memory exploit mitigation, e.g. browsers 597 * Network Protection (local firewall, IDS, IPS and local proxy) 598 inbound and outbound 600 * Detection of network manipulation (ARP, DNS, etc.) 602 * Data Loss Prevention and exfiltration detection (incl. covert 603 channels) 605 8. What would be a perfect endpoint security solution? 607 With all the above knowledge, let's consider what we could expect 608 from a perfect endpoint security 'system'. It would: 610 o find instantly accurate reputation for any file before it gets 611 executed and block it if needed. 613 o monitor any behavior on the endpoint, including inbound and 614 outbound network traffic, learn and identify normal behavior and 615 detect and block malicious actions, even if the attack is misusing 616 legitimate clean system tools or hiding with a rootkit. 618 o patch instantly across all devices/systems/OSes, including virtual 619 patching, meaning you can patch or shield an application even 620 before an official patch is released. 622 o exploit protection methods for all processes where applicable, 623 e.g. no execute bit (NX), data execution prevention (DEP), address 624 space layout randomization (ASLR), Control Flow Integrity Guard 625 (CFI/CFG), stack canaries, shadow stack, reuse attack protection 626 (RAP), etc. all of which are methods, which make it very difficult 627 to successfully run any exploit, even for zero day 628 vulnerabilities. 630 o detect attempts to re-route data to addresses other than those 631 which the user intended, e.g. detect incorrectly served DNS 632 entries, TLS connections to sites with invalid certificates, data 633 that is being proxied without explicit user consent, etc. 635 o have an emulator/sandbox/micro virtualization to execute code and 636 analyse the outcome and perform a roll back of all actions if 637 needed, e.g. for ransomware. 639 o allow the endpoint to communicate with the other endpoints in the 640 local network and globally, to learn from 'the crowd' and 641 dynamically update rules based on its findings. 643 o be in constant sync with all other endpoints deployed on a network 644 and other security solutions, run on any OS, with no delay 645 (including offline modes and on legacy systems). 647 o run from the OS/EE when possible. 649 o run as one of the first process on the OS/EE and protect itself 650 from any form of unwanted tampering. 652 o offers a reliable logging that can't be tampered with, even in the 653 event of system compromise. 655 o receive updates instantly from a trusted central entity. 657 9. The defence-in-depth principle 659 In this section we give a high level view of what we mean by 660 'defence-in-depth'. 662 Whilst endpoint security systems have good capabilities, sometimes it 663 is debatable and perhaps suboptimal to let the endpoint run the 664 capability alone or at all. It is generally considered good security 665 practice to adopt a defence-in-depth approach (see [USCERT]). The 666 Open Web Application Security Project group (OWASP) describes the 667 concept as follows: "The principle of defense-in-depth is that 668 layered security mechanisms increase security of the system as a 669 whole. If an attack causes one security mechanism to fail, other 670 mechanisms may still provide the necessary security to protect the 671 system." (see [OWASP]) 673 Indeed there are many other constituencies as per our end-to-end 674 model that can participate in the defence process: The network, the 675 infrastructure itself, the platform, the human, the user experience 676 and in a hybrid of an on premise and cloud approach, an Integrated 677 Cyber Defence (ICD) of the entire chain. 679 The simple idea behind the concept is that "every little helps". If 680 the endpoint is not 100% secure itself, the detection chance can 681 increase with additional security capabilities from other entities. 682 We acknowledge that there are some case where adding an additional 683 component to the system may degrade the overall security level by 684 introducing new weaknesses. 686 There are various reference article in the industry highlighting 687 limitations of endpoint only solutions. For example this quote here, 688 which talks about multi-tier solutions: "There are limitations with 689 any endpoint protection solution, however, that can limit protection 690 to only the client layer. There is also a need for security above 691 the client layer, as endpoint protection products cannot intercept 692 traffic. Vendors will often sell a multi-tiered solution that 693 enables a network appliance to assist the endpoint protection client 694 by intercepting traffic between the attacker and the infected client. 695 Vendors will also sell solutions that monitor and intercept traffic 696 on internal or external network segments to protect the enterprise 697 from these threats. A prime example of the limitations of endpoint 698 protection software is infection via a phishing attack." [ADAPTURE]. 700 Some sources point out that even the best solution might not get 701 deployed in the optimal way in a real world scenario as the 702 environment can be very complex: "While endpoint security has 703 improved significantly with the introduction of application 704 whitelisting and other technologies, our systems and devices are 705 simply too diverse and too interconnected to ensure that host 706 security can be deployed 100% ubiquitously and 100% effectively." 707 [NETTODAY] 709 On these grounds it is considered a good idea to follow a layered 710 approach when it comes to security. "In today's complex threat 711 environment, companies need to adopt a comprehensive, layered 712 approach to security, which is a challenging task in such as rapidly 713 evolving, crowded market." [HSTODAY] 715 It is important to comprehend the capabilities of endpoint security 716 solutions in this overall picture of the connected environment, which 717 includes other systems, networks and various protocols that are used 718 to interact with these entities. Understanding possible shortcomings 719 from single layered solutions can help counterbalance such weaknesses 720 in the architectural concept or the protocol design. 722 In order to quantify any potential benefits or limitations of the 723 various layered scenarios in regards to security a solid data set is 724 needed. This section requires statistics about proportions of 725 attacks that go undetected in various cases. We propose analysing 726 data for the following four cases: 728 o There is no security solution 730 o Security is only on the endpoint 732 o Security is only on the network 734 o Security is on both the endpoint and the network 736 However reconciling various statistics requires a lot of caution and 737 time, a methodology and consistent classification to avoid any 738 misinterpretation. 740 10. Endpoint Security Limits 742 The previous section defines an ideal endpoint security 'system', 743 however, from the real world, the expectation of what we can get from 744 an endpoint security solution will look more along the following 745 lines: 747 o may not be able to run at full capacity due to computational power 748 limits, battery life, performance, or policies (such as BYOD 749 restrictions in enterprise networks), etc. 751 o may not be able to run at full capacity as it slows down 752 performance too much. 754 o will miss some of the malware or attacks, regardless of detection 755 method used, like signatures, heuristics, machine learning (ML), 756 artificial intelligence (AI), etc. 758 o have some level of False Positives (FP). 760 o not monitoring or logging all activities on the system, e.g. due 761 to constraints of disk space or when a clean windows tool is being 762 triggered to do something malicious but the activity is not 763 logged. Such activity can be logged, but a decision needs to be 764 made if it's clean or not. 766 o have its own vulnerabilities or simple instabilities that could be 767 used to compromise the system. 769 o be tampered with by the user, e.g. disabled or reconfigured. 771 o be tampered with by the attacker, e.g. exceptions added or log 772 files wiped. 774 In the section below we review a number of these limitations through 775 real examples, step by step. Some limitations are absolute, and some 776 limitations result in a grey area or suboptimality for the solution. 778 10.1. No possibility to put an endpoint security add-on on the UE 780 UEs will vary a lot; by 2022, an estimated 29 billion devices will be 781 connected, with 18 billion of them related to IoT [ERICSSON]. Many 782 IoT products lack the capacity to install any endpoint security 783 capabilities, are unable to update the software, and it is not 784 possible to force the UE provider to improve or even offer an 785 intrinsic security capability. 787 We acknowledge that the numbers do vary significantly depending on 788 the source, for example: 790 o [STATISTA1] is showing the current trajectory of IoT devices from 791 25B to date to 40+B in 2022 and 75B in 2025. 793 o [ERICSSON] is more conservative and might requires an update, but 794 it was reaching 29B devices in 2022, with a nice breakdown between 795 device types and connectivity. 797 o [STATISTA2] is showing a breakdown by verticals and is even more 798 conservative than both of the above. 800 o [ENISA] it refers to a [GARTNERIOT] report from 2017 which sets a 801 trajectory to 20B devices by 2020. 803 In IoT we find UEs such as medical devices which are limited by 804 regulation, welding robots that can't be slowed down, smart light 805 bulbs which are limited by the processing power, etc. There are many 806 factors influencing whether endpoint security can be added to a UE: 808 o The UE is simply not powerful enough or the performance hit is too 809 high. 811 o Adding your own security will breach the warranty or will 812 invalidate a certification or a regulation (breach of validity). 814 o The UE needs to run in real-time and any delay introduced by a 815 security process might break the process. 817 o Some UEs are simply locked by design and the manufacturer does not 818 provide a security solution (e.g. smart TV, fitness tracker or 819 personal artificial assistants) see [CANDID1], [CANDID2]. 821 In the future, a possible research problem would be to find hard data 822 on the exact proportion of IoT devices that are unable to run any 823 endpoint security add-on or that have no intrinsic security built-in. 825 The other hidden dimension here is the economical aspect. Many 826 manufacturer are reluctant to invest in IoT device security, because 827 it can significantly increases the cost of their solution and there 828 is the perception that they will lose market shares, as customers are 829 not prepared to pay the extra cost for added security. 831 10.1.1. Not receiving any updates or functioning patches 833 The endpoint security system may lack a built-in capability to be 834 patched or it may be connected to a network that prevents the process 835 of downloading updates automatically. For example stand-alone 836 medical systems or industrial systems in isolated network segments 837 often do not have a communication channel to the Internet. 839 Even if security updates are received, they typically will only be 840 periodically updated; hence there will be a window of opportunity for 841 an attacker, between the time the attack is first used, and the time 842 the attack is discovered/patched and the patch is deployed. 844 In addition updates and patches may themselves be malicious by 845 mistake, or on purpose if not properly authenticated, or if the 846 source of the updates has malicious intent. This could be part of a 847 software update supply chain attack or an elaborate attacker breaking 848 the update process, as for example seen with the Flamer group (see 849 [FLAMER]). 851 A recent survey found that fewer than 10% of consumer IoT companies 852 follow vulnerability disclosure guidelines at all, which is regarded 853 as a basic first step in patching vulnerabilities (see 854 [IOTPATCHING]). This indicates that many IoT devices do not have a 855 defined update process or may not even create patches for most of the 856 vulnerabilities. 858 Furthermore some endpoints system may reach the end of their support 859 period and therefore no longer receive any updates for the OS/EE or 860 the security solution due to missing licenses. However the systems 861 may remain in use and become increasingly vulnerable as time goes on 862 and new attacks are discovered. 864 10.1.2. Mirai IoT bot 866 +-------------+-----------------------------------------------------+ 867 | Description | A Mirai bot infecting various IoT devices through | 868 | | weak passwords over Telnet port TCP 23 and by using | 869 | | various vulnerabilities, for example the SonicWall | 870 | | GMS XML-RPC Remote Code Execution Vulnerability | 871 | | (CVE-2018-9866) on TCP port 21009. Once a device is | 872 | | compromised it will scan for further victims and | 873 | | then start a DoS attack. | 874 +-------------+-----------------------------------------------------+ 875 | Simplified | Compromised device scans network for multiple open | 876 | attack | ports, attempts infection through weak password and | 877 | process | exploits, downloads more payload, starts DoS | 878 | | attack. | 879 | | | 880 | UE | No security tool present on majority of IoT | 881 | | devices, hence no detection possible. If a | 882 | | rudimentary security solution with limited | 883 | | capabilities such as outgoing firewall is present | 884 | | on the IoT device e.g. router, then it might be | 885 | | able to detect the outbound DoS attack and slow it | 886 | | down. | 887 | | | 888 | References | [MIRAI1][MIRAI2] | 889 +-------------+-----------------------------------------------------+ 891 10.2. Endpoints may not see the malware on the endpoint 893 10.2.1. LoJax UEFI rootkit 894 +-------------+-----------------------------------------------------+ 895 | Description | A device compromised with the LoJax UEFI rootkit, | 896 | | which is active before the OS/EE is started, hence | 897 | | before the endpoint security is active. It can pass | 898 | | back a clean 'image' when the security solution | 899 | | tries to scan the UEFI. Infection can either happen | 900 | | offline with physical access or through a dropper | 901 | | malware from the OS/EE. | 902 +-------------+-----------------------------------------------------+ 903 | UE | A perfect endpoint security could potentially | 904 | | detect the installation process if it is done from | 905 | | the OS/EE and not with physical modification or in | 906 | | the factory. Once the device is compromised the | 907 | | endpoint security solution can neither detect nor | 908 | | remove the rootkit. The endpoint solution may | 909 | | detect any of the exhibited behaviour, for example | 910 | | if the rootkit drops another malware onto the OS/EE | 911 | | at a later stage. | 912 | | | 913 | Reference | [LOJAX] | 914 +-------------+-----------------------------------------------------+ 916 10.2.2. SGX Malware 918 +-------------+-----------------------------------------------------+ 919 | Description | Malware can hide in the Intel Software Guard | 920 | | eXtensions (SGX) enclave chip feature. This is a | 921 | | hardware-isolated section of the CPU's processing | 922 | | memory. Code running inside the SGX can use return- | 923 | | oriented programming (ROP) to perform malicious | 924 | | actions. | 925 +-------------+-----------------------------------------------------+ 926 | UE | Since the SGX feature is by design out of reach for | 927 | | the OS/EE, an endpoint security solution can | 928 | | neither detect nor remove any injected malware. A | 929 | | perfect endpoint security solution could | 930 | | potentially detect the installation process if it | 931 | | is done from the OS/EE and not with physical | 932 | | modification or in the factory. | 933 | | | 934 | References | [SGX1] [SGX2] | 935 +-------------+-----------------------------------------------------+ 937 10.2.3. AMT Takeover 938 +-------------+-----------------------------------------------------+ 939 | Description | A targeted attack group can remotely execute code | 940 | | on a system through the Intel AMT (Active | 941 | | Management Technology) vulnerability | 942 | | (CVE-2017-5689) over TCP ports 16992/16993. This | 943 | | provides full access to the computer, including | 944 | | remote keyboard and monitor access. The attacker | 945 | | can install malware, modify the system or steal | 946 | | information. | 947 +-------------+-----------------------------------------------------+ 948 | UE | The AMT is accessible even if the PC is turned off. | 949 | | Therefore any endpoint security software installed | 950 | | on the OS, would not be able to see this traffic | 951 | | and therefore also not able to detect it. | 952 | | | 953 | References | [AMT1], [AMT2] | 954 +-------------+-----------------------------------------------------+ 956 10.2.4. AMT case study (anonymised) 958 An enterprise has a data center containing very sensitive data. 959 Their workstations use a certain Intel chipset which integrates the 960 AMT feature for remote computer maintenance. AMT is an interface for 961 hardware management of the workstations, including transmission of 962 screen content and keyboard and mouse input for remote maintenance. 963 Communication with the management workstation is implemented by AMT 964 through the network interface card (NIC) on the motherboard. The 965 network packets generated in this way are invisible both to the main 966 processor and thus to the OS running on the workstation. In autumn 967 of 2015, it became known that some AMT-enabled computers had a flaw 968 that allowed AMT's remote maintenance component to be activated and 969 configured by attackers. This also worked when the workstations were 970 switched off. The leakage of data through this vulnerability is 971 elusive and difficult to detect. The identified threat situation led 972 the organization to a new requirement implementing a method that can 973 reliably detect this and similar vulnerabilities. In particular, the 974 detection of rootkits and manipulated firmware, and this includes 975 also (UEFI) BIOS - has also been a focus of their attention. 977 The method used as a solution, compares the desired data packets 978 generated by a client operating system - the user, with the data 979 packets received on the switch port. If more data has been received 980 on the switch port than was been sent by the operating system - the 981 user, there is a strong possibility that something bad is happening - 982 like for example an infection via modified firmware or by rootkit. 984 10.2.5. Users bypass the endpoint security 986 +-------------+-----------------------------------------------------+ 987 | Description | Endpoint security systems should not interfere with | 988 | | the normal operation of the endpoint to the extent | 989 | | that users become frustrated and want to disable | 990 | | them or configure them to disable a significant | 991 | | fraction of important security capabilities. | 992 +-------------+-----------------------------------------------------+ 993 | UE | Add-on endpoint security is now bypassed or | 994 | | disabled by the user. Unless the endpoint is under | 995 | | monitored management or can prevent a user from | 996 | | modifying the configuration, then this is shutting | 997 | | down a significant fraction of the security | 998 | | capabilities. | 999 | | | 1000 | References | [NINESIGNS] | 1001 +-------------+-----------------------------------------------------+ 1003 10.3. Endpoints may miss information leakage attacks 1005 Another aspect that endpoint security has issues in detecting are 1006 information disclosure or leakage attacks, especially on shared 1007 virtual/physical systems. 1009 10.3.1. Meltdown/Specter 1011 The Meltdown/Specter vulnerabilities and all its variants may allow 1012 reading of physical memory belonging to another virtual machine (VM) 1013 on the same physical system. This could reveal passwords, 1014 credentials, certificates etc. The trick is that an attacker can 1015 spin up his own VM on the same physical hardware. As this VM is 1016 controlled by the attacker, they will ensure that there is no 1017 endpoint security that detects the Meltdown exploit code when run. 1018 It is very difficult for the attacked VM to detect the memory read- 1019 outs. For know CPU vulnerabilities there are software patches 1020 available than can be applied. If it is an external service 1021 provider, it might not be in the power of the user to patch the 1022 physical system or to determine if this has been done by the 1023 provider. 1025 10.3.2. Network daemon exploits 1027 Other attack types, which leak memory data from a vulnerable web 1028 server, are quite difficult to detect for an endpoint security. For 1029 example the Heartbleed bug allows anyone on the Internet to read the 1030 memory of the systems protected by the vulnerable versions of the 1031 OpenSSL software. This could lead to credentials or keys being 1032 exposed. An endpoint solution needs to either patch the vulnerable 1033 application or monitor it for any signs of exploitation or data 1034 leakage and prevent the data from being exfiltrated. 1036 10.3.3. SQL injection attacks 1038 A SQL injection attack is an example of an attack that exploits the 1039 backend logic of an application. Typically this is a web application 1040 with access to a database. By encoding specific command characters 1041 into the query string, additional SQL commands can be triggered. A 1042 successful attack can lead to the content of the whole database being 1043 exposed to the attacker. There are other similar attacks that can be 1044 grouped together for the purpose of this task, such as command 1045 injection or cross site scripting (XSS). Although they are different 1046 attacks, they all at their core fail at input filtering and 1047 validation, leading to unwanted actions being performed. 1049 Applications that are vulnerable to SQL injections are very common 1050 and are not restricted to web applications. An endpoint solution 1051 needs to monitor all data entered into possible vulnerable 1052 applications. This should include data received from the network. A 1053 generic pattern matching for standard SQL injection attack strings 1054 can be applied to potentially block some of the attacks. In order to 1055 block all types of SQL injection attacks the endpoint solution should 1056 have some knowledge about the logic of the monitored application, 1057 which helps to determine how normal requests differ from attacks. 1058 Applications can be analysed at source code level for potential 1059 weaknesses, but dynamically patching is very difficult. See [SQL] 1061 10.3.4. Low and slow data exfiltration 1063 An endpoint security solution can detect low and slow data 1064 exfiltration, for example when interesting data sources are tracked 1065 and access to them is monitored. If the data source is not on the 1066 endpoint itself, e.g. a database in the network, then the received 1067 data needs to be tagged and its further use needs to be tracked. To 1068 make detection difficult, an attacker could decide to use an 1069 exfiltration process that sends only 10 bytes every Sunday to a 1070 legitimate cloud service. If that is not in the normal behavior 1071 pattern, then this anomaly could be detected by the endpoint. If the 1072 process that sends the data or the destination IP address have a bad 1073 reputation, then they could be stopped. Though it is very difficult 1074 to reliably block such an attack and most solutions have a specific 1075 threshold that needs to be exceeded before it is detected as an 1076 anomaly. 1078 10.4. Suboptimality and gray areas 1080 10.4.1. Stolen credentials 1082 Stolen credentials and misuse of system tools such as RDP, Telnet or 1083 SSH are a valid scenario during attacks. An attacker can use stolen 1084 credentials to remotely log into a system and access data or execute 1085 commands in this context like the legitimate user might do. An 1086 endpoint security solution can restrict access from specific IP 1087 addresses, but this is difficult in a dynamic environment and when an 1088 attacker might have already compromised a trusted device and misuse 1089 it as a stepping stone for lateral movement. The endpoint could 1090 perform additional checks of the source device, such as verifying 1091 installed applications and certain conditions. Again this will not 1092 work in all scenarios, e.g. a hijacked valid device during lateral 1093 movement. 1095 This means that the system will not be able to simply block the 1096 connection if the authentication with the stolen credentials 1097 succeeds. A multi factor authentication (MFA) could limit the use of 1098 stolen credentials, but depending on the system used and the 1099 determination of the attacker they might be able to bypass this 1100 hurdle as well e.g. cloning a SIM card to read text message codes. 1102 As a next step, a solution on the endpoint can monitor the behavior 1103 of the logged in user and determine if it represents expected normal 1104 behavior. Unfortunately, there is the chance for false positives 1105 that might block legitimate actions, hence the rules are usually not 1106 applied too tightly. The system can monitor for suspicious behavior, 1107 similar to malware detection, where every action is carefully 1108 analyzed and all activity is tracked. For example if the SSH user is 1109 adding all files to archives with passwords and then deletes the 1110 original files in the file explorer, then this could result in a 1111 ransomware case scenario. If only a few files are processed per 1112 hour, then this activity will be very difficult for the endpoint to 1113 distinguish from normal activity, in order to flag it as malicious. 1115 The problem of attackers blending in with normal activity is one of 1116 the biggest challenges with so called living off the land attack 1117 methods. The attacker chooses to keep their profile low by not 1118 installing any additional binary files on the system, but instead 1119 misuses legitimate system tools to carry out their malicious intent. 1120 This means that there is no malware file that could be identified and 1121 the detection relies solely on other methods such as behaviour based 1122 monitoring [LOTLSYMC]. 1124 If information is shared across multiple endpoints, then each one 1125 could learn from the others and see how many connections came in from 1126 that source, what files were involved and what behavior the clients 1127 exhibited. This crowd wisdom approach would allow blocking rules to 1128 be applied after the first incident across multiple endpoints. 1130 10.4.2. Zero Day Vulnerability 1132 +-------------+-----------------------------------------------------+ 1133 | Description | An attacker exploits a zero day vulnerability or | 1134 | | any recent vulnerability. | 1135 +-------------+-----------------------------------------------------+ 1136 | UE | In theory this scenario could be handled by the | 1137 | | endpoint security: a) Once the intrinsic security | 1138 | | system has been patched, exploitation of the | 1139 | | vulnerability can be prevented. b) The add-on | 1140 | | security with enhanced capabilities or updated | 1141 | | methods can detect and mitigate the vulnerability. | 1142 | | It does not necessarily require the official patch. | 1143 | | | 1144 | Challenge | In practice many systems remain vulnerable to a | 1145 | | vulnerability months or even years after a security | 1146 | | fix has been released. Moreover there is a big gap | 1147 | | between when a vulnerability is disclosed and when | 1148 | | a security fix is available. Also there is a big | 1149 | | gap between when a security fix is available and | 1150 | | when the security fix is actually applied. A recent | 1151 | | study over three years, examined the patching time | 1152 | | of 12 client-side and 112 server-side applications | 1153 | | in enterprise hosts and servers. It took over 6 | 1154 | | months on average to patch 90% of the population | 1155 | | across all vulnerabilities. [NDSSPATCH]. We note | 1156 | | too: "The patching of servers is overall much worse | 1157 | | than the patching of client applications. On | 1158 | | average a server application remains vulnerable for | 1159 | | 7.5 months." | 1160 | | | 1161 | References | [ZERODAY1][ZERODAY2] | 1162 +-------------+-----------------------------------------------------+ 1164 10.4.3. Port scan over the network 1166 An infected machine, let's say a Mirai bot on a router, is scanning a 1167 class B network for IP addresses with TCP port 80 open. The malware 1168 can slow it down to 1 IP address per 5 seconds (or any other 1169 threshold) and it can go in randomized order (like for example the 1170 nmap tool does) in order to make it difficult to find a sequential 1171 pattern. To increase detection difficulties, legitimate requests to 1172 existing web servers can be added in at random intervals. 1174 An endpoint solution might be able to detect this behaviour, 1175 depending on the threshold, but it will be difficult. At some point 1176 the pattern will be similar to browsing the web, so either the 1177 endpoint blocks the bot scanning and also the user from surfing, or 1178 it allows both. 1180 To make it even harder, the attacker can use a botnet that 1181 communicates over peer-to-peer (P2P) or a central command and control 1182 server (C&C) and then distribute the scan load over multiple hosts. 1183 This means each endpoint only scans a subset, let's say 100 IP 1184 addresses, but all 1,000 bots scan a total of 100,000 IP addresses. 1186 This attack is difficult to detect by a reasonable threshold on each 1187 endpoint individually. If the endpoints talk to each other and 1188 exchange information, then a collective decision can be made on the 1189 bigger picture of the bot traffic. 1191 Another option for the endpoint solution is to block the bot malware 1192 from operating on the computer, for example by detecting the 1193 installation, analyzing the behavior of the process or by preventing 1194 the binary from accessing the network. This includes blocking any 1195 form of communication for the process to its C&C server, regardless 1196 of if it is using a P2P network or misusing legitimate system tools 1197 or browsers to communicate with the Internet. Blocking indirect 1198 communication over system tools as part of living off the land 1199 tactics, can be very challenging. 1201 See [BOT] 1203 10.4.4. DDoS attacks 1205 For this example let us consider a botnet of 100,000 compromised 1206 computers and each one sends a burst of traffic to a remote target, 1207 for one second each, alternating in groups. This will generate some 1208 waves of pulse attack traffic. Similar comments can be made about 1209 overall pulsed DDoS attacks [PDDoS]. 1211 A solution on the endpoint can attempt to detect the outgoing 1212 traffic. If the DoS attack is volume based and the time span of each 1213 pulse is large enough or the repeating frequency for each bot is 1214 high, then detection with thresholds on the endpoint is feasible. It 1215 is different, if it is an application layer DoS attack, where the 1216 logic of the receiving application is targeted, for example with too 1217 many search queries in HTTP GET requests. This would flood the 1218 backend server with intensive search requests, which can result in 1219 the web site no longer being responsive. Such attacks can succeed 1220 with a low amount of requests being sent, especially if its 1221 distributed over a botnet. This makes it very difficult for a single 1222 endpoint to detect such an ongoing attack, without knowledge from 1223 other endpoints or the network. 1225 Another option for the endpoint solution is to block the bot malware 1226 from operating on the computer, for example by detection the 1227 installation, analyzing the behavior of the process or by preventing 1228 the binary from accessing the network. This includes blocking any 1229 form of communication for the process to its C&C server, regardless 1230 of if it is using a P2P network or misusing legitimate system tools 1231 or browsers to communicate with the Internet. Blocking indirect 1232 communication over system tools as part of living off the land 1233 tactics, can be very challenging. 1235 11. Learnings from production data 1237 From the above limited considerations we can now check what we see 1238 from real production data using 1240 o the method described in [MONEYBALL] 1242 o the anonymised production data of Symantec MSS production for the 1243 past 3 months 1245 The core idea is to consider, based on all the imperfections we 1246 started to list above including the 'grey areas', that cybersecurity 1247 analysts are often presented with suspicious machine activity that 1248 does not conclusively indicate a compromise, resulting in undetected 1249 incidents or costly investigations into the most appropriate remedial 1250 actions. 1252 As Managed Security Services Providers (MSSP's) are confronted with 1253 these data quality issues, but also possess a wealth of cross-product 1254 security data that enables innovative solutions, we decided to use 1255 the Symantec MSS service for the past 3 months. The Symantec MSS 1256 service monitors over 100 security products from a wide variety of 1257 security vendors for hundreds of enterprise class customers from all 1258 verticals. 1260 We selected the subset of customers using the service that deploy 1261 both network and endpoint security products to determine which types 1262 of security incidents were most likely to be detected by endpoint 1263 products vs. network products. In doing so, we were particularly 1264 interested in identifying which categories of incidents are detected 1265 by endpoint products and not network products, and vice versa. Thus, 1266 we examined prevalent categories of incidents for which the only 1267 actionable security alerts were predominantly produced by one type of 1268 security product and not the other. To do so, we extracted all 1269 security incidents detected by Symantec MSS on behalf of hundreds of 1270 customers that deploy both network and endpoint security products, 1271 over a three-month period from December 2018 through the end of 1272 February 2019. We acknowledge that some attacks might have been 1273 blocked by the first product and therefore have never been seen by 1274 the next security solution, which influences the final numbers. 1276 With this in mind, we could identify incidents based on: 1278 +------------+------------------------------------------------------+ 1279 | Severity | 4 - Emergency, 3 - Critical, 2 - Warning, 1 - | 1280 | | Informational | 1281 +------------+------------------------------------------------------+ 1282 | Incident | Malicious Code, Deception Activity, Improper Usage, | 1283 | Category | Investigation, etc. | 1284 | | | 1285 | Incident | Trojan Horse Infection, Suspicious DGA Activity, | 1286 | Type | Suspicious Traffic, Suspicious URL Activity, | 1287 | | Backdoor infection, etc. | 1288 | | | 1289 | # network | Amount of network only security incidents | 1290 | incidents | | 1291 | | | 1292 | # all | What is the total amount of incidents on all | 1293 | incidents | security solutions | 1294 | | | 1295 | Percentage | Percentage of network security only incidents | 1296 +------------+------------------------------------------------------+ 1298 We ended up with 1300 o Hundreds of thousands of security incidents 1302 o which we could categorize in 275 incident types by category and 1303 severity (triplets Severity-Category-Type) 1305 o out of which we searched how many incidents of each type were 1306 detected by a network security product and missed by deployed 1307 endpoint security products at least 75% of the time or vice versa 1309 11.1. Endpoint only incidents 1311 The categories of incidents that are detected primarily by endpoint 1312 security products are fairly intuitive. They consist primarily of 1313 detections of file-based threats and detection of malicious behaviors 1314 through monitoring of system and network behavior at the process 1315 level. The most prevalent of these behavioral detections include 1316 detections of suspicious URLs based on heuristics and blacklists of 1317 IP addresses or domain names. Since most of these alerts are not 1318 corroborated by network products, it seems probable that the 1319 blacklists associated with network products tend to be more focused 1320 on attacks while host-based intrusion prevention system alerts focus 1321 more on malware command and control traffic. Most other behavioral 1322 detections at the endpoint provide alerts based on system behavior 1323 that is deemed dangerous and symptomatic of malicious intent by a 1324 malicious or infected process. The highest severity incidents 1325 detected on endpoints are instances of post-compromise outbound 1326 network behavior that are symptomatic of command and control 1327 communications traffic, but these did not show up as being primarily 1328 detected by endpoint products as they are frequently corroborated by 1329 network-based alerts. 1331 11.2. Security incidents detected primarily by network security 1332 products 1334 Perhaps less intuitive are the results of examining categories of 1335 security incidents that are detected primarily by network security 1336 products and only rarely corroborated by endpoint security products. 1337 Below we provide details regarding incident categories for which a 1338 network security product produced a detection and for which there 1339 were no actionable endpoint alerts for at least 75% of the incidents 1340 in the category. 1342 In our study we found 32 incident type, category, and severity 1343 triplets of this type. The following categories critical incident 1344 types were reported by MSS customers, and we discuss each in turn in 1345 decreasing order of prevalence: 1347 11.2.1. Unauthorized external vulnerability scans 1349 Perhaps unsurprisingly, unauthorized external attempts to scan 1350 corporate resources for vulnerabilities and other purposes are 1351 detected in large volumes by a broad variety of network-focused 1352 security products. 79% of incidents of this type were detected by 1353 network security products with critical-severity alerts, these 1354 security incident detections are not accompanied by any actionable 1355 endpoint alerts, despite the fact that endpoint security products are 1356 deployed by these enterprises. This category of threats encompasses 1357 a broad variety of attacks, the most prevalent of which are the 1358 following: Horizontal scans, SQL injection attacks, password 1359 disclosure vulnerabilities, directory traversal attacks, and 1360 blacklist hits. Of these categories of detections, horizontal scans 1361 stand out as the category of detection that endpoint-security 1362 products are least likely to detect on their own. 1364 11.2.2. Unauthorized internal vulnerability scans 1366 Unauthorized internal vulnerability scans, though less frequent, are 1367 more alarming, as they are likely to represent possible post- 1368 compromise activity. We note that the Managed Security Service works 1369 with its customers to maintain lists of devices that are authorized 1370 to perform internal vulnerability scans, and their activity is 1371 reported separately at a lower levels of incident severity. 89% of 1372 detected unauthorized internal vulnerability scans are detected by 1373 network products without any corroborating actionable alerts from 1374 endpoint security products. As compared to unauthorized external 1375 scan incidents, internal hosts that perform vulnerability scans are 1376 far more active and the fraction of alerts that detect horizontal 1377 scans is higher, representing half of the total alerts generated. 1378 Alerts focused on Network-Behavior Anomaly Detection also appear for 1379 internal hosts. 1381 11.2.3. Malware downloads resulting in exposed endpoints 1383 This category of threats is generally detected by network security 1384 appliances. Despite these enterprises being purchasers of endpoint 1385 security products, 76% of the incidents detected by the network 1386 security products do not show a corresponding alert by an endpoint 1387 security product. A broad variety of network appliances contributed 1388 to the detection of a diverse collection of malware samples. 1390 11.2.4. Exploit kit infections 1392 This category of infections represents instances in which the 1393 customer's machines are exposed to exploit kits. These threats were 1394 detected by network appliances that extract suspicious URLs from 1395 network traffic taps and use a combination of sandbox technology and 1396 blacklists to identify websites that deploy a variety of exploit kits 1397 that were not being caught by endpoint security products. In this 1398 three month time period, the most prevalent categories of exploit 1399 kits detected involved redirections to the Magnitude exploit kit and 1400 exploit kits associated with phishing scams and attempts to expose 1401 users to fake Anti-Virus warnings and tools. A breakdown of the 1402 results is included below: 1404 +---------------------+-----------------------+ 1405 | Severity | 3 - Critical | 1406 +---------------------+-----------------------+ 1407 | Incident Category | Malicious Code | 1408 | | | 1409 | Incident Type | Exploit Kit Infection | 1410 | | | 1411 | # network incidents | 26 | 1412 | | | 1413 | # all incidents | 26 | 1414 | | | 1415 | Percentage | 100% | 1416 +---------------------+-----------------------+ 1418 The network security product that detected these incidents produced 1419 the following alerts: 1421 o Advanced Malware Payloads 1423 o Exploit.Kit.FakeAV 1425 o Exploit.Kit.Magnitude 1427 o Exploit.Kit.MagnitudeRedirect 1429 o Exploit.Kit.PhishScams 1431 o HTMLMagnitudeLandingPage 1433 11.2.5. Attacks against servers 1435 In addition to detecting the aforementioned critical security 1436 incident categories, network security devices frequently detect a 1437 broad variety of attacks against servers that usually lack 1438 corroboration at the endpoint. Most server attacks are not matched 1439 by endpoint protection alerts: 62% are unmatched for critical 1440 incidents, and 88% are unmatched as lower severity incidents. This 1441 category of incidents is the most prevalent category of incidents 1442 detected primarily by network products, but they are usually rated 1443 lower in severity than the aforementioned classes of alerts as they 1444 are very commonplace. Even when these alerts are corroborated by 1445 endpoint protection alerts, the endpoint alerts are often low in 1446 severity, as in the case of file-based threats that appear to have 1447 been blocked or successfully cleaned up by an Anti-Virus solution. 1448 The challenge in taking action against server attacks is that it can 1449 be difficult to assess which of these attacks were successful in 1450 causing actual damage, and for this reason, for the fraction of 1451 server attacks that demonstrate corroborating endpoint security 1452 alerts, even if of low severity, should be examined. It is 1453 interesting to note the cooperative role played by both network and 1454 endpoint security devices in these instances. 1456 12. Regulatory Considerations 1458 This section will briefly look at the regulatory landscape and 1459 develop a specific view on the impact on endpoints with the goal to 1460 see what we might be able to learn. 1462 Legal requirements, compliance, regulatory frameworks and mandatory 1463 reporting are no longer separate from any security evaluation, 1464 process or requirement within an organisation, enterprise system or 1465 intranet. It is essential to look at the technical and regulatory 1466 approaches together. This section will look at two examples of legal 1467 requirements and guidance: 1469 (1) IoT security (2) Network infrastructure 1471 This section is by no means complete, but it does a discussion on 1472 this aspect of endpoint and ecosystem regulation. 1474 12.1. IoT Security 1476 IoT security regulation is emerging in the form of voluntary 1477 frameworks and self-assessments that relate to endpoint security 1478 issues.. These frameworks focus first on the end point, or mobile 1479 device, in the IoT environment and then on the holistic ecosystem 1480 itself. 1482 In 2017 the National Institute of Standards and Technology released 1483 its draft IoT Cybersecurity Framework based on consultations and 1484 interviews with all stakeholders over several years previously 1485 [NISTIOTP]. Some of the themes which emerged was the need for IoT 1486 governance, assessment frameworks, review of all aspects of the IoT 1487 ecosystem and a process for coordinated vulnerability disclosure 1488 inside an organisation. As evidenced by the 2018 Endpoint Protection 1489 and Response Survey by SANS, only 47% of organisations know that 1490 their endpoints have been breached and a further 20% are unsure 1491 [EPRSANS]. So a systemic approach from NIST was welcomed and the 1492 NIST framework became the gold standard for national IoT security 1493 frameworks. 1495 Other IoT security frameworks include the Singapore IoT Cyber 1496 Security Guide from January 2019 and the UK's Secure by Design or The 1497 Government's Code of Practice for Consumer Internet of Things (IoT) 1498 Security for manufacturers, with guidance for consumers on smart 1499 devices at home [IMDAIOTG], [SBDGOVUK]. Once again both look at 1500 securing the IoT device or endpoint, but also security for the entire 1501 value chain of the IoT system. The Singapore framework makes the 1502 point about the entire system clear, "Similar to any system, an IoT 1503 system is as secure as its weakest link. It is thus important to 1504 ensure that proper security considerations and measures are put in 1505 place for both the implementation and operational stages of the 1506 deployment of any IoT system." [IMDAIOTG] Finally, the IoT Security 1507 Foundation, the GSMA and the Internet Society have all released their 1508 own frameworks for IoT security. All have similar characteristics 1509 which focus on the entire value chain and ecosystem, but also on 1510 vulnerability disclosure and checklist assessments. What makes each 1511 of these approaches slightly different is the differing perspectives 1512 of the organization advocating it. The GSMA is the mobile trade 1513 association and so it focuses on mobile devices while the Internet 1514 Society focuses on the Internet ecosystem and a multistakeholder 1515 approach. Systematically underpinning all the frameworks is the 1516 holistic approach with voluntary best practices and implementation 1517 based on the needs of the user or organisation adopting the framework 1518 [IOTSFCF], [GSMAIOT], [ISTRUST]. 1520 12.2. Network infrastructure 1522 In Europe, the Network and Information Security Directive, which was 1523 passed in July 2016, require implementation by each European member 1524 state with a threefold aim. First, to put into place a national 1525 strategy for network and infrastructure security including best 1526 practices, guidelines, training and stakeholder consultations. 1527 Second, to coordinate national CSIRTs with CERT-EU and third to 1528 provide incident control and response systems for critical 1529 infrastructure and digital services [EURLEX]. This Directive 1530 demonstrates the importance give across the EU to network resilience 1531 and incident reporting. While securing the endpoint is acknowledged, 1532 the focus is on ensuring the security of European interoperable 1533 networks. In short, the importance of the security of the network 1534 including incident response shows that it isn't only the endpoints 1535 that should be the focus of the regulation and legal frameworks. 1537 12.3. Auditing and Assessment 1539 This section will talk about other risk assessment and auditing 1540 regulatory requirements beyond the NIS directive. 1542 One example of risk assessment as a regulatory requirement is the New 1543 York State law 23 NYCRR 500 of the Regulations of the Superintendent 1544 of Financial Services (Cybersecurity Requirements for Financial 1545 Services Companies). Among the requirements, audit, risk assessment 1546 and risk reporting are included like, 1547 (2) include audit trails designed to detect and respond to 1548 Cybersecurity Events that have a reasonable likelihood of materially 1549 harming any material part of the normal operations of the Covered 1550 Entity. [NYCYBER] 1552 12.4. Privacy Considerations 1554 We may consider a specific focus on privacy in the future. 1556 13. Human Rights Considerations 1558 This section may develop a specific view of requirements, limits and 1559 constraints coming from Human Rights perspective on endpoint 1560 security. 1562 14. Security Considerations 1564 This document is about Security Considerations 1566 15. IANA Considerations 1568 This document has no actions for IANA 1570 16. Informative References 1572 [ADAPTURE] 1573 Cullen, T., "Limits of endpoint only", July 2017, 1574 . 1577 [AMT1] Khandelwal, S., "Explained - How Intel AMT Vulnerability 1578 Allows to Hack Computers Remotely", May 2017, 1579 . 1582 [AMT2] Symantec, ., "Web Attack Intel AMT Privilege Escalation 1583 CVE-2017-5689", 2017, 1584 . 1587 [ATTACK] "MITRE ATT&CK", n.d., . 1589 [BOT] Marinho, R., "Exploring a P2P transient botnet - From 1590 Discovery to Enumeration", July 2017, 1591 . 1594 [CANDID1] Wueest, C., "How my TV got infected with ransomware and 1595 what you can learn about it", November 2015, 1596 . 1599 [CANDID2] Dickson, B., "Millions of smart TVs are vulnerable to 1600 hackers", February 2014, 1601 . 1603 [CAPEC] "MITRE CAPEC", n.d., 1604 . 1606 [ENISA] ENISA, ., "Baseline Security Recommendations for IoT in 1607 the context of Critical Information Infrastructures", 1608 November 2017, . 1611 [EPPEDR] Redscan, ., "EPP and EDR - What's the difference?", June 1612 2018, . 1615 [EPPGUIDE] 1616 "IT Pro's Guide to Endpoint Protection", n.d., 1617 . 1620 [EPPSECURITY] 1621 Hunt, J., "Advantages and Disadvantages of Three Top 1622 Endpoint Security Vendors", n.d., 1623 . 1626 [EPRSANS] Neely, L., "Endpoint Protection and Response A SANS 1627 Survey", June 2018, . 1630 [ERICSSON] 1631 Ericsson, ., "Internet of Things forecast", n.d., 1632 . 1635 [EURLEX] EUP, ., "Directive (EU) 2016/1148", July 2016, 1636 . 1639 [FLAMER] Symantec, ., "W32.Flamer Microsoft Windows Update Man-in- 1640 the-Middle", June 2012, 1641 . 1644 [GARTNERIOT] 1645 Van der Meulen, R., "Gartner Says 8.4 Billion Connected 1646 Things Will be in Use in 2017, Up 31 percent from 2016", 1647 February 2017, . 1651 [GARTNERREPORT] 1652 Crotty, J., "New Gartner Report Redefines Endpoints 1653 Protection for 2018", January 2018, 1654 . 1657 [GSMAIOT] GSMA, ., "GSMA IoT Security Guidelines and Assessment", 1658 n.d., . 1661 [HSTODAY] Hstoday, ., "Layered Approach Critical to Effective 1662 Endpoint Protection", October 2016, 1663 . 1667 [IMDAIOTG] 1668 IMDA, ., "IMDA IoT Cyber Security Guide", January 2019, 1669 . 1675 [IOTPATCHING] 1676 Rogers, D., "Handling vulnerabilities as an IoT vendor", 1677 December 2018, . 1681 [IOTSFCF] IoTSF, ., "IoT Security Compliance Framework", December 1682 2018, . 1685 [ISTRUST] ISOC, ., "Internet of Things (IoT) Trust Framework v2.5", 1686 May 2018, 1687 . 1690 [LOJAX] ESET, ., "LoJax First UEFI rootkit found in the wild, 1691 courtesy of the Sednit group", September 2018, 1692 . 1695 [LOTLSYMC] 1696 Wueest, C., "Living off the land and fileless attack 1697 techniques", July 2017, 1698 . 1702 [MIRAI1] Symantec, ., "Mirai, what you need to know about the 1703 botnet behind recent major DDoS attacks", October 2016, 1704 . 1707 [MIRAI2] Krebsonsecurity, ., "19 Mirai Botnet Authors Avoid Jail 1708 Time", September 2018, 1709 . 1711 [MONEYBALL] 1712 Roundy, K., "Predicting Cyber Threats with Virtual 1713 Security Products. ACSAC", 2017, 1714 . 1717 [NDSSPATCH] 1718 Caballero, J., "Mind Your Own Business A Longitudinal 1719 Study of Threats and Vulnerabilities in Enterprises", 1720 February 2019, . 1724 [NETTODAY] 1725 Dix, J., "Layered Security Defenses What layer is most 1726 critical network or endpoint", July 2011, 1727 . 1731 [NINESIGNS] 1732 Smith, K., "9 signs your endpoint security isn't working", 1733 May 2017, . 1736 [NISTIOTP] 1737 NIST, ., "NIST Cybersecurity for IoT Program", November 1738 2016, . 1741 [NYCYBER] NYCRR, ., "See 3 NYCRR 500 of the Regulations of the 1742 Superintendent of Financial Services (Cybersecurity 1743 Requirements for Financial Services Companies)", n.d., 1744 . 1747 [OWASP] OWASP, ., "Defense in depth definition", August 2015, 1748 . 1750 [PDDoS] Seals, T., "Pulse-Wave DDoS Attacks Mark a New Tactics in 1751 Q2", October 2017, . 1754 [SBDGOVUK] 1755 UK, GOV., "Secure by Design", February 2019, 1756 . 1759 [SGX1] Claburn, T., "Intel SGX safe room easily trashed by white- 1760 hat hacking marauders Enclave malware demoed", February 1761 2019, . 1764 [SGX2] Cimpanu, C., "Researchers hide malware in Intel SGX 1765 enclaves", February 2019, . 1768 [SQL] Cobb, M., "SQL injection detection tools and prevention 1769 strategies", November 2009, 1770 . 1773 [STATISTA1] 1774 Statista, ., "Internet of Things (IoT) connected devices 1775 installed base worldwide from 2015 to 2025 (in billions)", 1776 n.d., . 1779 [STATISTA2] 1780 Statista, ., "Size of Internet of Things market worldwide 1781 in 2014 and 2020 by industry (in billion U.S dollars)", 1782 n.d., . 1786 [TEEP] Cam-Winget, N., "Trust Execution Environment Protocol", 1787 March 2018, . 1789 [USCERT] Michael, C., "Principles of defense-in-depth", September 1790 2005, . 1794 [ZERODAY1] 1795 McHugh, J., "Windows of Vulnerability A Case Study 1796 Analysis", 2000, . 1799 [ZERODAY2] 1800 Plattner, B., "Large-Scale Vulnerability Analysis", 1801 September 2006, . 1804 Appendix A. Contributors 1806 o Arnaud Taddei 1807 Symantec 1808 arnaud_taddei@symantec.com 1810 o Bret Jordan 1811 Symantec 1812 bret_jordan@symantec.com 1814 o Candid Wueest 1815 Symantec 1816 candid_wueest@symantec.com 1818 o Chris Larsen 1819 Symantec 1820 chris_larsen@symantec.com 1822 o Andre Engel 1823 Symantec 1824 andre_ngel@symantec.com 1826 o Kevin Roundy 1827 Symantec 1828 kevin_roundy@symantec.com 1830 o Yuqiong Sun 1831 Symantec 1832 Yuqiong_Sun@symantec.com 1834 o David Wells 1835 Symantec 1836 David_Wells@symantec.com 1838 o Dominique Lazanski 1839 Last Press Label 1840 dml@lastpresslabel.com 1842 Authors' Addresses 1844 Arnaud Taddei 1845 Symantec Corporation 1846 350 Ellis Street 1847 Mountain View CA 94043 1848 USA 1850 Email: arnaud_taddei@symantec.com 1852 Candid Wueest 1853 Symantec Corporation 1854 350 Ellis Street 1855 Mountain View CA 94043 1856 USA 1858 Email: candid_wueest@symantec.com 1860 Kevin A. Roundy 1861 Symantec Corporation 1862 350 Ellis Street 1863 Mountain View CA 94043 1864 USA 1866 Email: kevin_roundy@symantec.com 1867 Dominique Lazanski 1868 Last Press Label 1869 Flat 1, 109A Columbia Road 1870 London E2 7RL 1871 UK 1873 Email: dml@lastpresslabel.com