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