Evolution of Endpoint Security - An Operational Perspective
draft-mcfadden-opsec-endp-evolve-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Mark McFadden | ||
Last updated | 2021-02-14 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-mcfadden-opsec-endp-evolve-00
Individual Submission M. McFadden Internet Draft internet policy advisors, ltd uk Intended status: Informational February 14, 2021 Expires: August 14, 2021 Evolution of Endpoint Security - An Operational Perspective draft-mcfadden-opsec-endp-evolve-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 14, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in McFadden Expires August 14, 2021 [Page 1] Internet-Draft Evolution of Endpoint Security February 2021 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This draft discusses the traditional model of security where endpoints in the network are protected by a variety of tools. It proposes a model for endpoints and then argues that the older, traditional approach is no longer sufficient for operational security at the endpoint. A series of operational examples are discussed in an Appendix. Table of Contents 1. Introduction...................................................3 2. Endpoints, Definition, Model and Scope.........................3 2.1. Scope.....................................................3 2.2. Models....................................................4 2.3. Internal representation of an endpoint....................4 2.4. External representation of an endpoint....................5 3. Limitations of the Threat Landscape............................6 3.1. Typical Categories of Threats.............................7 3.2. Evolution of threat types and their descriptions..........7 4. Endpoint Security Capabilities.................................8 4.1. Intrinsic versus added security...........................9 4.2. Specific Endpoint Security Capabilities..................10 5. Optimal Properties of an Endpoint Security Solution...........11 6. Case Studies in the Limitations of Endpoint Security Only.....12 6.1. Unable to put an endpoint security add-on on the UE......13 6.2. Endpoints may not see the malware on the endpoint........16 6.3. Endpoints may miss information leakage attacks...........18 6.4. Suboptimality and gray areas.............................20 7. Defense-in-depth from the perspective of protocol design......23 8. Endpoint security from the perspective of protocol design.....24 8.1. Simplicity of design is important........................25 8.2. Diversity in protocol design.............................25 8.3. Protocol design and failure of intermediaries............26 8.4. Protocol evolution.......................................26 9. Security Considerations.......................................26 10. IANA Considerations..........................................27 11. Acknowledgements.............................................27 12. References...................................................27 12.1. Informative References..................................27 Appendix A. Operational Experience and Endpoint Security.........31 A.1. Endpoint only incidents..................................32 McFadden Expires August 14, 2021 [Page 2] Internet-Draft Evolution of Endpoint Security February 2021 A.2. Security incidents detected primarily by network security products......................................................33 1. Introduction There is currently significant discussion of the evolution of the Internet's treat model. The evolution of the Internet has brought new approaches to transport, connectivity, service provision and the type of devices connected to the Internet. This document is a discussion of the capabilities and limitations of security solutions based on the traditional strategy of protecting endpoint devices. The typical approach of protecting endpoints is affected by the evolution of those endpoints and the emergence of threats that do not rely on exploits at the endpoints. The goal of this document is to provide an operational perspective on this evolution. The focus here will be capabilities and limitations of endpoint-only security solutions and the impact of the evolution of the Internet's threat model on operational security. Our goal with this review is to describe the benefits and limitations of endpoint security in the real world - from an operational perspective - rather than in the abstract. We aim to highlight security limitations that cannot be addressed by endpoint solutions and to suggest how these may be mitigated with the concept of a defence-in-depth approach, in order to increase the resilience against attacks and data breaches. Finally, this draft suggests how this approach might affect protocol design. 2. Endpoints, Definition, Model and Scope 2.1. Scope Endpoints are the origin and destination for a communication between parties. This encompasses User Equipment (UE) and the Host at the other end of the communication. This is a simplification of operational experience in the real world. In fact, there is an enormous variety of devices at the endpoints of communication of parties. However, a generalized approach to endpoints is not only possible, but the subject of other work in the IETF. For instance, the TEEP Working Group [1] has attempted to describe a generalized model for endpoints. As a companion to this work, a taxonomy of endpoints [2] is also provided. McFadden Expires August 14, 2021 [Page 3] Internet-Draft Evolution of Endpoint Security February 2021 The goal is to provide a uniform way to describe the security properties of endpoints in order to also describe the threat model, or attack surface, of those endpoints. For example: o The following would be considered UEs: a smartphone, a smart device, any IoT device, a laptop, a desktop, a workstation, etc. o Hosts might be represented by the following examples: physical servers, virtual servers/machines, etc. 2.2. Models In what follows, the discussion is limited to modeling the endpoints that are User Equipment (UE) rather than hosts. Having a model for Internet hosts is important but beyond the scope of this draft. The goal is to have a generalized description of the endpoint, its security properties, and the position of the endpoint in the network. In addition, there are two separate descriptions for the endpoint. First, an internal view of the endpoint is provided and then a view of the external model for the endpoint is suggested. This approach provides a mechanism to cover the full attack surface and the threat landscape for the endpoint. 2.3. Internal representation of an endpoint The companion endpoint taxonomy draft [2] provides a hierarchy of endpoint types, properties and capabilities. The taxonomy draft begins from the simplification represented in the following diagram: +----------------------------+ | Application | +----------------------------+ | OS / Execution Environment | +----------------------------+ | Hardware | +----------------------------+ Internal Endpoint Model Today there are an enormous set of combinations of Hardware, OS/EE pairing, and Application layers, offering the user a vast set of features with a wide spectrum of capabilities. One of the features McFadden Expires August 14, 2021 [Page 4] Internet-Draft Evolution of Endpoint Security February 2021 of the evolution of the Internet's threat model is that the variety of these combinations is an enormous change compared to one or two decades ago. The variety of combinations provide users with a rich set of new capabilities. Applications designers can provide services that were not possible even five years ago. However, with those new capabilities come new risks: new vectors for delivery of attacks and new attack surfaces at the endpoint. The result is: the operational implications for endpoint security have evolved as the capabilities and variety of endpoints has expanded. 2.3.1. Applications as Endpoints One of the other features of this evolution is that the application layer has evolved in such a way that it can be an endpoint as well. This has important operational security implications because prior approaches to providing endpoint security emphasized "per-device" security. In an evolved internet, the endpoint may be the application with multiple applications running on a single piece of User Equipment (UE). In this case, the threat model may be different for individual applications - resulting in different threat landscapes on a single device. 2.4. External representation of an endpoint Section 2.3 describes a model for understanding the threat landscape of an individual UE device. In order to provide a complete view of the threat landscape there must also be a model for the connectivity properties of the device. This is a view of the attack surface of the device as viewed externally. A representation of endpoints in an end-to-end context could look like the following diagram: +-------+ +---------------------+---------+ | Human | <- (1) -> | Digital Persona | Application | <- (2) -> +-------+ +-----------+-------------------+ | User Equipment | +-------------------------------+ McFadden Expires August 14, 2021 [Page 5] Internet-Draft Evolution of Endpoint Security February 2021 +----------------+ +----------------+ <- (2) -> | Network | <- (3) -> | Platform/Hosts | | Infrastructure | +----------------+ +----------------+ External Endpoint Model 1. Humans have a user experience (UX) with the UE, starting with an explicit or implicit Digital Persona, engaging with an application; 2. The application will have sessions through a network infrastructure. There are no assumptions made about how the network infrastructure is provisioned or what its properties are, (as an example, it could include landlines, mobile networks, satellites, etc.) nor are any assumptions made about the characteristics of those sessions (for instance, unicast or multicast, or sessions sourced from multiple hosts). 3. A platform consisting of many Hosts either physical or virtual which ensures a large part of the end-to-end user experience. In this end-to-end model we see that many other systems may have interactions with the UE: the human, the UX, the digital persona, the sessions, the intermediate network infrastructure, and the hosts and applications at the destination. This means that the operational security requirements for the model have expanded significantly. The threat landscape is very large and the attack surface will involve all the components and interactions at any level of either model. 3. Limitations of the Threat Landscape In sections 2.3 and 2.4 above we saw that the pace of evolution of endpoints on the Internet has had a resulting change to the types and properties of attacks on those endpoints. In the past, the number of User Equipment (UE) was well-bounded and an approach to operational security that addressed the endpoints made intuitive and practical sense. In today's Internet, the vast number and range of combinations that the generic modeling in sections 2.3 and 2.4 offers us, makes defining a threat landscape far more complicated. From an McFadden Expires August 14, 2021 [Page 6] Internet-Draft Evolution of Endpoint Security February 2021 operational perspective the prior approach of concentrating security on endpoints may have to be reconsidered. 3.1. Typical Categories of Threats Any description of a threat model for endpoints must address typical, well-known attacks such as: o Malware (Trojans, viruses, backdoors, bots, etc.) o Adware and spyware o Exploits o Phishing o Script-based attacks o Ransomware, local Denial of Service (DoS) attacks o Denial of Service (DoS) attacks o Malicious removable storage devices (USB) o In memory attacks o Rootkits and firmware attacks o Scams and online fraud o System abuse (staging/proxying) 3.2. Evolution of threat types and their descriptions However, the threat landscape is not static. Like the endpoints themselves, the threats evolve. It's difficult, for instance, to decide if cryptojacking or coinmining belong as examples of attacks in categories above. It is possible that they represent new categories of attack. In either case, a model of endpoint security must cope with a threat landscape that evolves as the properties of the endpoints evolve. There are frameworks for describing threats: O MITRE Common Attack Pattern Enumeration Classification (CAPEC). See [3]. CAPEC offers a hierarchical view of attack patterns by domains which can match some aspects of both of our above models, McFadden Expires August 14, 2021 [Page 7] Internet-Draft Evolution of Endpoint Security February 2021 but we will need to identify those attacks that fit exactly in our scope. O MITRE ATT&CK. See [4]. ATT&CK offers a very straightforward categorized knowledge base of attacks, but it concentrates on the enterprise attack chain, so we will need to do some work to extract what we need. In both cases, the frameworks do not address all of the threats that can affect the security of a system, for example they do not cover: routing hijacking, flooding, selective blocking, unauthorised modification of data sent to an endpoint, etc. Phishing is an example of the limitations of using this approach. Phishing should be included as an attack, but while this is indeed an attack that will materialize on an end-device through an application (email, webmail, etc.), the real target of this attack is not the device, but the human behind the digital persona. 4. Endpoint Security Capabilities For the purpose of this draft, endpoint security capabilities are the features that are used to protect the endpoint from attack. Protection has many meanings, however it is important to distinguish three different aspects of protection: o Prevention - The attack doesn't succeed by intrinsic or explicit security capabilities. o Detection - The attack is happening or has happened and is recorded and/or signaled to another component for action. o Mitigation - Once detected, the attack can be halted or its effects can at least be reduced or reversed. For example, prevention methods include keeping the software updated and patching vulnerabilities, implementing measures to authenticate the provenance of incoming data to stop the delivery of malicious content, or choosing strong passwords. Detection methods include inspecting logs or network traffic. Mitigation could include deploying backups to recover from an attack with minimal disruption. The endpoint model definitions in sections 2.3 and 2.4 are simple but the security capabilities of each component may be complex. Each layer may or may not have a certain spectrum of intrinsic capabilities and there may be multiple ways to provide add-on and McFadden Expires August 14, 2021 [Page 8] Internet-Draft Evolution of Endpoint Security February 2021 third-party endpoint security capabilities, allowing complex interactions between all of these components. 4.1. Intrinsic versus added security In terms of security capabilities for each layer of the model, there are those capabilities that are built-in or intrinsic, and there are those that are added to the layer through external means. (A) Intrinsic security capability can be built-into each of the endpoint model layers o (1) Hardware o (2) OS/EE o (3) Application (B) Add-on security capability can be o (4) a component of the hardware o (5) a component of the OS/EE o (6) an application by itself In (A), there is a built-in, 'security by design' approach of the developer or manufacturers. They often offer a security model and security capabilities as part of their design. In (B), a 3rd party is offering an additional security component which was not necessarily considered when the Hardware, OS/EE or Application was designed. With regard to (6), there are many available options for add-on security capabilities offered by third-parties as applications on a commercial or open-source basis. Gartner (see [5] highlights the evolution of endpoint security towards two directions as shown in [6], [7], and [8]. o Endpoint Protection Platform (EPP) as an integrated security solution designed to detect and block threats at the device level. o Endpoint Detection and Response (EDR) as a combination of next generation tools to provide anomaly detection and alerting, forensic analysis and endpoint remediation capabilities. McFadden Expires August 14, 2021 [Page 9] Internet-Draft Evolution of Endpoint Security February 2021 4.2. Specific Endpoint Security Capabilities Endpoint security capabilities can be grouped into four broad areas: o those capabilities that are intrinsic to the endpoint and its network connectivity o those that protect against the execution of problematic code o those that protect against malware installation and execution o those that protect against weaknesses in applications. In the following sections, examples of these capabilities are provided. 4.2.1. Intrinsic Capabilities o Software updates / patching o Access Control (RBAC, ABAC, etc.) o Authentication o Authorization o Detailed event logging 4.2.2. Execution protection o Exploit mitigation (file/memory) o Tamper protection o Whitelisting filter by signatures, signed code or other means o System hardening and lockdown (HIPS, trusted boot, etc.) 4.2.3. Malware protection o Scanning - on access/on write/scheduled/quick scan (file/memory) o Reputation-based blocking on files or by ML o Behavior-based detection - (heuristic based/ML) o Rootkit and firmware detection McFadden Expires August 14, 2021 [Page 10] Internet-Draft Evolution of Endpoint Security February 2021 o Threat intelligence based detection (cloud-based/on premise) o Static detection - generic, by emulation, by ML, by signature 4.2.4. Attack/Exploit/Application Protection 4.2.4.1. Application protection (browser, messaging clients, social media, etc.) o Disinformation Protection (anti-phishing, fake news, anti-spam, etc.) o Detection of unintended link location (URL blocklist, etc.) o Memory exploit mitigation, e.g. browsers 4.2.4.2. Network Protection (local firewall, IDS, IPS and local proxy) inbound and outbound o Detection of network manipulation (ARP, DNS, etc.) o Data Loss Prevention and exfiltration detection (incl. covert channels) 5. Optimal Properties of an Endpoint Security Solution It is impossible to provide a complete list of the properties of an optimal endpoint security solution. The evolution of the threat landscape ensures that endpoint security solutions will require new features in the future. However, it is possible to provide a (non- exhaustive) list of properties - in the spirit of best practices - for an endpoint security solution. o find instantly accurate reputation for any file before it gets executed and block it if needed. o monitor any behavior on the endpoint, including inbound and outbound network traffic, learn and identify normal behavior and detect and block malicious actions, even if the attack is misusing legitimate clean system tools or hiding with a rootkit. o patch instantly across all devices/systems/OSes, including virtual patching, meaning you can patch or shield an application even before an official patch is released. o exploit protection methods for all processes where applicable, e.g. no execute bit (NX), data execution prevention (DEP), address McFadden Expires August 14, 2021 [Page 11] Internet-Draft Evolution of Endpoint Security February 2021 space layout randomization (ASLR), Control Flow Integrity Guard (CFI/CFG), stack canaries, shadow stack, reuse attack protection (RAP), etc. all of which are methods, which make it very difficult to successfully run any exploit, even for zero day vulnerabilities. o detect attempts to re-route data to addresses other than those which the user intended, e.g. detect incorrectly served DNS entries, TLS connections to sites with invalid certificates, data that is being proxied without explicit user consent, etc. o have an emulator/sandbox/micro virtualization to execute code and analyse the outcome and perform a roll back of all actions if needed, e.g. for ransomware. o allow the endpoint to communicate with the other endpoints in the local network and globally, to learn from 'the crowd' and dynamically update rules based on its findings. o be in constant sync with all other endpoints deployed on a network and other security solutions, run on any OS, with no delay (including offline modes and on legacy systems). o run from the OS/EE when possible. o run as one of the first process on the OS/EE and protect itself from any form of unwanted tampering. o offers a reliable logging that can't be tampered with, even in the event of system compromise. o receive updates instantly from a trusted central entity. 6. Case Studies in the Limitations of Endpoint Security Only The previous section discusses what some of the optimal features of endpoint security 'system' would be. However, a more realistic view, based on operational security data would indicate: o may not be able to run at full capacity due to computational power limits, battery life, performance, or policies (such as BYOD restrictions in enterprise networks), etc. o may not be able to run at full capacity as it slows down performance too much. McFadden Expires August 14, 2021 [Page 12] Internet-Draft Evolution of Endpoint Security February 2021 o will miss some of the malware or attacks, regardless of detection method used, like signatures, heuristics, machine learning (ML), artificial intelligence (AI), etc. o have some level of False Positives (FP). o not monitoring or logging all activities on the system, e.g. due to constraints of disk space or when a clean windows tool is being triggered to do something malicious but the activity is not logged. Such activity can be logged, but a decision needs to be made if it's clean or not. o have its own vulnerabilities or simple instabilities that could be used to compromise the system. o be tampered with by the user, e.g. disabled or reconfigured. o be tampered with by the attacker, e.g. exceptions added or log files wiped. In the following section, a number of these limitations are reviewed in case studies.. Some limitations are absolute, and some limitations result in a grey area or suboptimality for the endpoint security solution. 6.1. Unable to put an endpoint security add-on on the UE We have seen that UEs will vary a lot; by 2022, an estimated 29 billion devices will be connected, with 18 billion of them related to IoT [9]. Many IoT products lack the capacity to install any endpoint security capabilities, are unable to update the software, and it is not possible to force the UE provider to improve or even offer an intrinsic security capability. In IoT we find UEs such as medical devices which are limited by regulation, welding robots that can't be slowed down, smart light bulbs which are limited by the processing power, etc. There are many factors influencing whether endpoint security can be added to a UE: * The UE is simply not powerful enough or the performance hit is too high. * Adding your own security will breach the warranty or will invalidate a certification or a regulation (breach of validity). * The UE needs to run in real-time and any delay introduced by a security process might break the process. McFadden Expires August 14, 2021 [Page 13] Internet-Draft Evolution of Endpoint Security February 2021 * Some UEs are simply locked by design and the manufacturer does not provide a security solution (e.g. smart TV, fitness tracker or personal artificial assistants) see [10], [11]. In the future, a possible research problem would be to find hard data on the exact proportion of IoT devices that are unable to run any endpoint security add-on or that have no intrinsic security built-in. The other hidden dimension here is the economical aspect. Many manufacturer are reluctant to invest in IoT device security, because it can significantly increases the cost of their solution and there is the perception that they will lose market shares, as customers are not prepared to pay the extra cost for added security. 6.1.1. Not receiving any updates or functioning patches The endpoint security system may lack a built-in capability to be patched or it may be connected to a network that prevents the process of downloading updates automatically. For example stand- alone medical systems or industrial systems in isolated network segments often do not have a communication channel to the Internet. Even if security updates are received, they typically will only be periodically updated; hence there will be a window of opportunity for an attacker, between the time the attack is first used, and the time the attack is discovered/patched and the patch is deployed. In addition updates and patches may themselves be malicious by mistake, or on purpose if not properly authenticated, or if the source of the updates has malicious intent. This could be part of a software update supply chain attack or an elaborate attacker breaking the update process, as for example seen with the Flamer group (see [12]). A recent survey found that fewer than 10% of consumer IoT companies follow vulnerability disclosure guidelines at all, which is regarded as a basic first step in patching vulnerabilities (see [13]). This indicates that many IoT devices do not have a defined update process or may not even create patches for most of the vulnerabilities. Furthermore some endpoints system may reach the end of their support period and therefore no longer receive any updates for the OS/EE or the security solution due to missing licenses. However the systems may remain in use and become increasingly vulnerable as time goes on and new attacks are discovered. McFadden Expires August 14, 2021 [Page 14] Internet-Draft Evolution of Endpoint Security February 2021 In the following sections, individual examples of attacks on endpoints unable to provide for their own security are examined. In each case, the description of the attack follows the format of . . . 6.1.2. Mirai IoT bot 6.1.2.1. Mirai Description 1 | Description | A Mirai bot infecting various IoT devices through weak passwords over Telnet port TCP 23 and by using various vulnerabilities, for example the SonicWall GMS XML-RPC Remote Code Execution Vulnerability (CVE-2018-9866) on TCP port 21009. Once a device is compromised it will scan for further victims and then start a DoS attack. | | Simplified attack process | Compromised device scans network for multiple open ports, attempts infection through weak password and exploits, downloads more payload, starts DoS attack. | | UE | No security tool present on majority of IoT devices, hence no detection possible. If a rudimentary security solution with limited capabilities such as outgoing firewall is present on the IoT device e.g. router, then it might be able to detect the outbound DoS attack and slow it down. | | References | [14] }[15] | 6.1.2.2. Mirai Description 2 | Name | Mirai | | Description | A device infection for participation into a botnet activity | | Endpoint Targeted | IoT Devices | | Attack Surface Categories Involved | Telnet remote access; Weak default and existing passwords; Code vulnerabilities in exposed services | | Attack Surface Examples | Weak passwords over Telnet TCP port 23; SonicWall GMS XML-RPC Remote Code Execution Vulnerability (CVE-2018- 9866) on TCP port 21009 | | Attack Objective | Deployment of a custom code or commands on the device for participation in botnet activities | McFadden Expires August 14, 2021 [Page 15] Internet-Draft Evolution of Endpoint Security February 2021 | Attack Category | Botnet Deployment; DDoS | | Attack Orchestration | Exploit remote access weaknesses on the device to deploy a bot on the device | | Mitigation | If a rudimentary security solution with limited capabilities such as outgoing firewall is present on the IoT device e.g. router, then it might be able to detect the added bot or the outbound DoS attack and slow it down | | Attack Surface Minimisation | Better password management; Uptodate patching | | References | [14] [15] | 6.2. Endpoints may not see the malware on the endpoint 6.2.1. LoJax UEFI rootkit | Description | A device compromised with the LoJax UEFI rootkit, which is active before the OS/EE is started, hence before the endpoint security is active. It can pass back a clean 'image' when the security solution tries to scan the UEFI. Infection can either happen offline with physical access or through a dropper malware from the OS/EE. | | UE | A perfect endpoint security could potentially detect the installation process if it is done from the OS/EE and not with physical modification or in the factory. Once the device is compromised the endpoint security solution can neither detect nor remove the rootkit. The endpoint solution may detect any of the exhibited behaviour, for example if the rootkit drops another malware onto the OS/EE at a later stage. | | Reference | [16] | 6.2.2. SGX Malware | Description | Malware can hide in the Intel Software Guard eXtensions (SGX) enclave chip feature. This is a hardware-isolated section of the CPU's processing memory. Code running inside the SGX can use return-oriented programming (ROP) to perform malicious actions. | | UE | Since the SGX feature is by design out of reach for the OS/EE, an endpoint security solution can neither detect nor remove any injected malware. A perfect endpoint security solution could McFadden Expires August 14, 2021 [Page 16] Internet-Draft Evolution of Endpoint Security February 2021 potentially detect the installation process if it is done from the OS/EE and not with physical modification or in the factory. | | References | [17] [18] | 6.2.3. AMT Takeover | Description | A targeted attack group can remotely execute code on a system through the Intel AMT (Active Management Technology) vulnerability (CVE-2017-5689) over TCP ports 16992/16993. This provides full access to the computer, including remote keyboard and monitor access. The attacker can install malware, modify the system or steal information. | | UE | The AMT is accessible even if the PC is turned off. Therefore any endpoint security software installed on the OS, would not be able to see this traffic and therefore also not able to detect it. | | References | [19], [20] | 6.2.4. AMT case study (anonymised) An enterprise has a data center containing very sensitive data. Their workstations use a certain Intel chipset which integrates the AMT feature for remote computer maintenance. AMT is an interface for hardware management of the workstations, including transmission of screen content and keyboard and mouse input for remote maintenance. Communication with the management workstation is implemented by AMT through the network interface card (NIC) on the motherboard. The network packets generated in this way are invisible both to the main processor and thus to the OS running on the workstation. In autumn of 2015, it became known that some AMT-enabled computers had a flaw that allowed AMT's remote maintenance component to be activated and configured by attackers. This also worked when the workstations were switched off. The leakage of data through this vulnerability is elusive and difficult to detect. The identified threat situation led the organization to a new requirement implementing a method that can reliably detect this and similar vulnerabilities. In particular, the detection of rootkits and manipulated firmware, and this includes also (UEFI) BIOS - has also been a focus of their attention. The method used as a solution, compares the desired data packets generated by a client operating system - the user, with the data packets received on the switch port. If more data has been received on the switch port than was been sent by the operating system - the user, there is a strong possibility that something bad is happening - like for example an infection via modified firmware or by rootkit. McFadden Expires August 14, 2021 [Page 17] Internet-Draft Evolution of Endpoint Security February 2021 6.2.5. Users bypass the endpoint security | Description | Endpoint security systems should not interfere with the normal operation of the endpoint to the extent that users become frustrated and want to disable them or configure them to disable a significant fraction of important security capabilities. | | UE | Add-on endpoint security is now bypassed or disabled by the user. Unless the endpoint is under monitored management or can prevent a user from modifying the configuration, then this is shutting down a significant fraction of the security capabilities. | | References | [21] | 6.3. Endpoints may miss information leakage attacks Another aspect that endpoint security has issues in detecting are information disclosure or leakage attacks, especially on shared virtual/physical systems. 6.3.1. Meltdown/Specter The Meltdown/Specter vulnerabilities and all its variants may allow reading of physical memory belonging to another virtual machine (VM) on the same physical system. This could reveal passwords, credentials, certificates etc. The trick is that an attacker can spin up his own VM on the same physical hardware. As this VM is controlled by the attacker, they will ensure that there is no endpoint security that detects the Meltdown exploit code when run. It is very difficult for the attacked VM to detect the memory read- outs. For known CPU vulnerabilities there are software patches available than can be applied. If it is an external service provider, it might not be in the power of the user to patch the physical system or to determine if this has been done by the provider. 6.3.2. Network daemon exploits Other attack types, which leak memory data from a vulnerable web server, are quite difficult to detect for an endpoint security. For example the Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This could lead to credentials or keys being exposed. An endpoint solution needs to either patch the vulnerable application or monitor it for any signs of exploitation or data leakage and prevent the data from being exfiltrated. McFadden Expires August 14, 2021 [Page 18] Internet-Draft Evolution of Endpoint Security February 2021 6.3.3. SQL injection attacks A SQL injection attack is an example of an attack that exploits the backend logic of an application. Typically, this is a web application with access to a database. By encoding specific command characters into the query string, additional SQL commands can be triggered. A successful attack can lead to the content of the whole database being exposed to the attacker. There are other similar attacks that can be grouped together for the purpose of this task, such as command injection or cross site scripting (XSS). Although they are different attacks, they all at their core fail at input filtering and validation, leading to unwanted actions being performed. Applications that are vulnerable to SQL injections are very common and are not restricted to web applications. An endpoint solution needs to monitor all data entered into possible vulnerable applications. This should include data received from the network. A generic pattern matching for standard SQL injection attack strings can be applied to potentially block some of the attacks. In order to block all types of SQL injection attacks the endpoint solution should have some knowledge about the logic of the monitored application, which helps to determine how normal requests differ from attacks. Applications can be analysed at source code level for potential weaknesses, but dynamically patching is very difficult. See { [22] } 6.3.4. Low and slow data exfiltration An endpoint security solution can detect low and slow data exfiltration, for example when interesting data sources are tracked and access to them is monitored. If the data source is not on the endpoint itself, e.g. a database in the network, then the received data needs to be tagged and its further use needs to be tracked. To make detection difficult, an attacker could decide to use an exfiltration process that sends only 10 bytes every Sunday to a legitimate cloud service. If that is not in the normal behavior pattern, then this anomaly could be detected by the endpoint. If the process that sends the data or the destination IP address have a bad reputation, then they could be stopped. Though it is very difficult to reliably block such an attack and most solutions have a specific threshold that needs to be exceeded before it is detected as an anomaly. McFadden Expires August 14, 2021 [Page 19] Internet-Draft Evolution of Endpoint Security February 2021 6.4. Suboptimality and gray areas 6.4.1. Stolen credentials Stolen credentials and misuse of system tools such as RDP, Telnet or SSH are a valid scenario during attacks. An attacker can use stolen credentials to remotely log into a system and access data or execute commands in this context like the legitimate user might do. An endpoint security solution can restrict access from specific IP addresses, but this is difficult in a dynamic environment and when an attacker might have already compromised a trusted device and misuse it as a stepping stone for lateral movement. The endpoint could perform additional checks of the source device, such as verifying installed applications and certain conditions. Again this will not work in all scenarios, e.g. a hijacked valid device during lateral movement. This means that the system will not be able to simply block the connection if the authentication with the stolen credentials succeeds. A multi factor authentication (MFA) could limit the use of stolen credentials, but depending on the system used and the determination of the attacker they might be able to bypass this hurdle as well e.g. cloning a SIM card to read text message codes. As a next step, a solution on the endpoint can monitor the behavior of the logged in user and determine if it represents expected normal behavior. Unfortunately, there is the chance for false positives that might block legitimate actions, hence the rules are usually not applied too tightly. The system can monitor for suspicious behavior, similar to malware detection, where every action is carefully analyzed and all activity is tracked. For example if the SSH user is adding all files to archives with passwords and then deletes the original files in the file explorer, then this could result in a ransomware case scenario. If only a few files are processed per hour, then this activity will be very difficult for the endpoint to distinguish from normal activity, in order to flag it as malicious. The problem of attackers blending in with normal activity is one of the biggest challenges with so called living off the land attack methods. The attacker chooses to keep their profile low by not installing any additional binary files on the system, but instead misuses legitimate system tools to carry out their malicious intent. This means that there is no malware file that could be identified and the detection relies solely on other methods such as behaviour based monitoring { [23] }. McFadden Expires August 14, 2021 [Page 20] Internet-Draft Evolution of Endpoint Security February 2021 If information is shared across multiple endpoints, then each one could learn from the others and see how many connections came in from that source, what files were involved and what behavior the clients exhibited. This crowd wisdom approach would allow blocking rules to be applied after the first incident across multiple endpoints. 6.4.2. Zero Day Vulnerability | Description | An attacker exploits a zero day vulnerability or any recent vulnerability. | | UE | In theory this scenario could be handled by the endpoint security: a) Once the intrinsic security system has been patched, exploitation of the vulnerability can be prevented. b) The add-on security with enhanced capabilities or updated methods can detect and mitigate the vulnerability. It does not necessarily require the official patch.| | Challenge | In practice many systems remain vulnerable to a vulnerability months or even years after a security fix has been released. Moreover there is a big gap between when a vulnerability is disclosed and when a security fix is available. Also there is a big gap between when a security fix is available and when the security fix is actually applied. A recent study over three years, examined the patching time of 12 client-side and 112 server-side applications in enterprise hosts and servers. It took over 6 months on average to patch 90% of the population across all vulnerabilities. { [24] }. We note too: "The patching of servers is overall much worse than the patching of client applications. On average a server application remains vulnerable for 7.5 months." | | References | { [25] }{{ [26] } | 6.4.3. Port scan over the network An infected machine, let's say a Mirai bot on a router, is scanning a class B network for IP addresses with TCP port 80 open. The malware can slow it down to 1 IP address per 5 seconds (or any other threshold) and it can go in randomized order (like for example the nmap tool does) in order to make it difficult to find a sequential pattern. To increase detection difficulties, legitimate requests to existing web servers can be added in at random intervals. McFadden Expires August 14, 2021 [Page 21] Internet-Draft Evolution of Endpoint Security February 2021 An endpoint solution might be able to detect this behaviour, depending on the threshold, but it will be difficult. At some point the pattern will be similar to browsing the web, so either the endpoint blocks the bot scanning and also the user from surfing, or it allows both. To make it even harder, the attacker can use a botnet that communicates over peer-to-peer (P2P) or a central command and control server (C&C) and then distribute the scan load over multiple hosts. This means each endpoint only scans a subset, let's say 100 IP addresses, but all 1,000 bots scan a total of 100,000 IP addresses. This attack is difficult to detect by a reasonable threshold on each endpoint individually. If the endpoints talk to each other and exchange information, then a collective decision can be made on the bigger picture of the bot traffic. Another option for the endpoint solution is to block the bot malware from operating on the computer, for example by detecting the installation, analyzing the behavior of the process or by preventing the binary from accessing the network. This includes blocking any form of communication for the process to its C&C server, regardless of if it is using a P2P network or misusing legitimate system tools or browsers to communicate with the Internet. Blocking indirect communication over system tools as part of living off the land tactics, can be very challenging. See { [27] } 6.4.4. DDoS attacks For this example let us consider a botnet of 100,000 compromised computers and each one sends a burst of traffic to a remote target, for one second each, alternating in groups. This will generate some waves of pulse attack traffic. Similar comments can be made about overall pulsed DDoS attacks { [28] }. A solution on the endpoint can attempt to detect the outgoing traffic. If the DoS attack is volume based and the time span of each pulse is large enough or the repeating frequency for each bot is high, then detection with thresholds on the endpoint is feasible. It is different, if it is an application layer DoS attack, where the logic of the receiving application is targeted, for example with too many search queries in HTTP GET requests. This would flood the backend server with intensive search requests, which can result in the web site no longer being responsive. Such attacks can succeed McFadden Expires August 14, 2021 [Page 22] Internet-Draft Evolution of Endpoint Security February 2021 with a low amount of requests being sent, especially if its distributed over a botnet. This makes it very difficult for a single endpoint to detect such an ongoing attack, without knowledge from other endpoints or the network. Another option for the endpoint solution is to block the bot malware from operating on the computer, for example by detection the installation, analyzing the behavior of the process or by preventing the binary from accessing the network. This includes blocking any form of communication for the process to its C&C server, regardless of if it is using a P2P network or misusing legitimate system tools or browsers to communicate with the Internet. Blocking indirect communication over system tools as part of living off the land tactics, can be very challenging. 7. Defense-in-depth from the perspective of protocol design While endpoint security systems have good capabilities (for instance, those seen in section 5 above), sometimes it is debatable and perhaps suboptimal to let the endpoint run the capability alone or at all. It is generally considered good security practice to adopt a defense-in-depth approach (see [29]). The Open Web Application Security Project group (OWASP) describes the concept as follows: "The principle of defense-in-depth is that layered security mechanisms increase security of the system as a whole. If an attack causes one security mechanism to fail, other mechanisms may still provide the necessary security to protect the system." (see [29]). Indeed, there are many other constituencies as per our end-to-end model that can participate in the defence process: The network, the infrastructure itself, the platform, the human, the user experience and in a hybrid of an on premise and cloud approach, an Integrated Cyber Defence (ICD) of the entire chain. The simple idea behind the concept is that "every little bit helps". If the endpoint is not 100% secure itself, the detection chance can increase with additional security capabilities from other entities. We acknowledge that there are some case where adding an additional component to the system may degrade the overall security level by introducing new weaknesses. There are various reference articles in the industry highlighting limitations of endpoint only solutions. For example this quote here, which talks about multi-tier solutions: McFadden Expires August 14, 2021 [Page 23] Internet-Draft Evolution of Endpoint Security February 2021 "There are limitations with any endpoint protection solution, however, that can limit protection to only the client layer. There is also a need for security above the client layer, as endpoint protection products cannot intercept traffic. Vendors will often sell a multi-tiered solution that enables a network appliance to assist the endpoint protection client by intercepting traffic between the attacker and the infected client. Vendors will also sell solutions that monitor and intercept traffic on internal or external network segments to protect the enterprise from these threats. A prime example of the limitations of endpoint protection software is infection via a phishing attack." [30]. Some sources point out that even the best solution might not get deployed in the optimal way in a real world scenario as the environment can be very complex: "While endpoint security has improved significantly with the introduction of application whitelisting and other technologies, our systems and devices are simply too diverse and too interconnected to ensure that host security can be deployed 100% ubiquitously and 100% effectively." [31] On these grounds it is considered a good idea to follow a layered approach when it comes to security. "In today's complex threat environment, companies need to adopt a comprehensive, layered approach to security, which is a challenging task in such as rapidly evolving, crowded market." [331] It is important to comprehend the capabilities of endpoint security solutions in this overall picture of the connected environment, which includes other systems, networks and various protocols that are used to interact with these entities. Understanding possible shortcomings from single layered solutions can help counterbalance such weaknesses in the architectural concept or the protocol design. 8. Endpoint security from the perspective of protocol design The previous sections have reviewed two models for endpoints on the Internet, a review of how endpoints have evolved, an examination of the features of endpoint security and - finally - a view of how endpoint security, alone, may not be sufficient to protect endpoints and users in a evolved Internet. A taxonomy of endpoints is provided in a companion draft [2]. The evolution has brought a significant set of new threats and there is evidence that endpoint security is not enough to protect against those threats. McFadden Expires August 14, 2021 [Page 24] Internet-Draft Evolution of Endpoint Security February 2021 This is an observation about operational security, but what does it mean for protocol design? 8.1. Simplicity of design is important Protocol design is often informed by attempting to get all possible use cases addressed in early versions of the protocol design. It is widely observed that subsequent versions of a protocol - popular or not - are difficult to achieve. However, simplicity in protocol design ensures that a protocol will be well-understood at design- time, it can be modelled and receive a full (and, perhaps formal) security analysis. The Security Directorate already routinely reviews protocols in Last Call for their security characteristics - a practice that should endure. However, making protocol design decisions that allow for easy, open review helps build confidence in the security of the underlying design. It is certain that there will always be unintended consequences in choices made at protocol design time. However, if the underlying protocol is not overly complex, those unintended consequences can be limited. It also make possible modularization or code-reuse allowing for the reuse of security analysis from one protocol to another. It is worth noting that implementation is also affected by protocol design decisions. Complex or poorly defined methods for deployment of software that implements a protocol means that they are more likely to be deployed incorrectly or insecurely. 8.2. Diversity in protocol design Protocol design can include decisions that limit - or, encourage the limitation - or service diversity. This has market-facing risks but also has security implications. Where a protocol is too complex to upgrade or implement, only those with the necessary resources are likely to benefit from the deployment. Where larger stakeholders dominate deployment of a particular protocol - because of its underlying design - the result can be a limited pool of deployments with potentially smaller numbers of points of failure. When protocol choices lead to lack of service diversity, this also increases the risk of shared vulnerabilities among a small set of providers of service. In this case, the attractiveness of the target becomes higher as the number of service implementation becomes lower. Protocol design should encourage diversity of service provision. McFadden Expires August 14, 2021 [Page 25] Internet-Draft Evolution of Endpoint Security February 2021 8.3. Protocol design and failure of intermediaries The rise of intermediaries has been an important feature of the evolution of the Internet. In a prior era, it would have been natural and sufficient to concentrate on deploying security at endpoints. The end-to-end principle seems to encourage thinking of building intelligence - and thus, protection - at the edges of the network. From previous sections, it is apparent that a strict view of the end-to-end model no longer applies. Even the model for an endpoint, as provided in section 2, no longer can support the view of endpoint protection being for the device or UE. The result is the security of the endpoint is, in part, dependent on the security of the middleboxes and intermediary hosts that provide services. From the point of protocol design, planning for this includes planning for when those intermediaries are compromised, unavailable or stop delivering expected services correctly. Protocols that depend upon intermediaries should clearly adapt to failure modes of the intermediaries and give choices to endpoint on what actions to take in the event of third-party failure. 8.4. Protocol evolution A core message in this draft is that: as the Internet evolves, its endpoints do as well, and with them the threats they face. Even ancient protocols are rarely static - especially if they have any deployment base. As protocols evolve their designers have to achieve a balance between interoperability, strictness, agility and extensibility. Considering this deployment, and altered use case, during design has the property of making protocol evolution more secure. Care must be taken, especially in complex protocols where many new use cases are being account for, in development of the evolution. It may make the underlying protocol so complex that few are able to implement it securely. Thus, while the protocol itself may be secure, it's complexity makes for error in implementation which leads to operational security problems. 9. Security Considerations This document is all about security considerations of operational security for endpoints. In particular it provides a model for McFadden Expires August 14, 2021 [Page 26] Internet-Draft Evolution of Endpoint Security February 2021 endpoint security and then discusses why traditional approaches to endpoint security are no longer sufficient. 10. IANA Considerations This memo contains no instructions or requests for IANA. The authors continue to appreciate the efforts of IANA staff in support of the IETF. 11. Acknowledgements The original idea for this draft came from another, now expired draft [33]. The authors of that draft intended a comprehensive discussion of endpoint security and a clear description of how the evolution of the Internet made endpoint security - on its own - insufficient. The author thanks those previous contributors: Arnaud Taddei, Bret Jordan, Candid Wueest, Chris Larsen, Andre Engel, Kevin Roundy, Yugiong Sun, and David Wells. The author also extends his appreciation to the discussions in the IAB Activity called model-t where the future of the Internet's threat landscape has also been discussed. This document was prepared using 2-Word-v2.0.template.dot. 12. References 12.1. Informative References [1] Thaler, D. and Tschofenig, H., Pei, M., Tsukamoto, A., " Trust Execution Environment Protocol ", draft-ietf-teep-protocol-02 (work in progress), April 2020. [2] McFadden, M., "Evolution of Endpoint Security - A Taxonomy for Endpoints," draft-mcfadden-opsec-endp-taxonomy-00 (work in progress), February 2021. [3] "MITRE CAPEC", <https://capec.mitre.org/data/definitions/3000.html>, n. d. [4] "MITRE ATT&CK", <https://attack.mitre.org>, n.d. [5] Crotty, J., "New Gartner Report Redefines Endpoints Protection for 2018 ", January 2018, <https://www.crowdstrike.com/blog/new-gartner-report- redefines-endpoint-protection-for-2018/>. McFadden Expires August 14, 2021 [Page 27] Internet-Draft Evolution of Endpoint Security February 2021 [6] Redscan, ., "EPP and EDR - What's the difference?", June 2018, <https:/ /www.redscan.com/news/epp-vs-edr-whats-the-difference/>. [7] Hunt, J., "Advantages and Disadvantages of Three Top Endpoint Security Vendors", n.d., <https://www.adapture.com/blog/evaluating-leading-endpo int-security-vendors/>. [8] "IT Pro's Guide to Endpoint Protection", n.d., <https://www.barkly.com/ it-pros-guide-to-endpoint-protection>. [9] Ericsson, ., "Internet of Things forecast", n.d., <https://www.ericsson .com/en/mobility-report/internet-of-things-forecast>. [10] Wueest, C., "How my TV got infected with ransomware and what you can le arn about it", November 2015, <https://www.symantec.com/connect/blogs/h ow-my-tv-got-infected-ransomware-and-what-you-can-learn-it>. [11] Dickson, B., "Millions of smart TVs are vulnerable to hackers", Februar y 2014, <https://www.dailydot.com/debug/protect-smart-tv/>. [12] Symantec, ., "W32.Flamer Microsoft Windows Update Man-in-the-Middle", J une 2012, <https://www.symantec.com/connect/blogs/w32flamer-microsoft-w indows-update-man-middle>. [13] Rogers, D., "Handling vulnerabilities as an IoT vendor", December 2018, <https://www.iotsecurityfoundation.org/less-than-10-of-consumer-iot-com panies-follow-vulnerability-disclosure-guidelines/>. [14] Symantec, ., "Mirai, what you need to know about the botnet behind rece nt major DDoS attacks", October 2016, <https://www.symantec.com/connect /blogs/mirai-what-you-need-know-about-botnet-behind-recent-major-ddos-a ttacks>. [15] Krebs on security, ., "19 Mirai Botnet Authors Avoid Jail Time", Septem ber 2018, <https://krebsonsecurity.com/tag/mirai-botnet/>. [16] ESET, ., "LoJax First UEFI rootkit found in the wild, courtesy of the S ednit group", September 2018, <https://www.welivesecurity.com/2018/09/2 7/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/>. [17] Claburn, T., "Intel SGX safe room easily trashed by white-hat hacking m arauders Enclave malware demoed", February 2019, <https://www.theregist er.co.uk/2019/02/12/intel_sgx_hacked/>. [18] Cimpanu, C., "Researchers hide malware in Intel SGX enclaves", February 2019, <https://www.zdnet.com/article/researchers-hide-malware-in-intel- sgx-enclaves/>. McFadden Expires August 14, 2021 [Page 28] Internet-Draft Evolution of Endpoint Security February 2021 [19] Khandelwal, S., "Explained - How Intel AMT Vulnerability Allows to Hack Computers Remotely", May 2017, <https://thehackernews.com/2017/05/intel -amt-vulnerability.html>. [20] Symantec, ., "Web Attack Intel AMT Privilege Escalation CVE-2017-5689", 2017, <https://www.symantec.com/security_response/attacksignatures/deta il.jsp?asid=29888> [21] Smith, K., "9 signs your endpoint security isn't working", May 2017, <h ttps://securelement.com/9-signs-your-endpoint-security-isnt-working/>. [22] Cobb, M., "SQL injection detection tools and prevention strategies", No vember 2009, <https://www.computerweekly.com/tip/SQL-injection-detectio n-tools-and-prevention-strategies>. [23] Wueest, C., "Living off the land and fileless attack techniques", July 2017, <https://www.symantec.com/content/dam/symantec/docs/security-cent er/white-papers/istr-living-off-the-land-and-fileless-attack-techniques -en.pd>. [24] Caballero, J., "Mind Your Own Business A Longitudinal Study of Threats and Vulnerabilities in Enterprises", February 2019, <https://www.ndss-s ymposium.org/wp-content/uploads/2019/02/ndss2019_03B-1-2_Kotzias_paper. pdf> [25] McHugh, J., "Windows of Vulnerability A Case Study Analysis", 2000, <ht tp://www.cs.colostate.edu/~cs635/Windows_of_Vulnerability.pdf>. [26] Plattner, B., "Large-Scale Vulnerability Analysis", September 2006, <ht tp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.173.3056&rep=rep 1&type=pdf>. [27] Marinho, R., "Exploring a P2P transient botnet - From Discovery to Enum eration", July 2017, <https://morphuslabs.com/exploring-a-p2p-transient -botnet-from-discovery-to-enumeration-e72870354950>. [28] Seals, T., "Pulse-Wave DDoS Attacks Mark a New Tactics in Q2", October 2017, <https://www.infosecurity-magazine.com/news/pulsewave-ddos-attack s-mark-q2/>. [29] UK, GOV., "Secure by Design", February 2019, <https://www.gov.uk/govern ment/collections/secure-by-design>. [30] Cullen, T., "Limits of endpoint only", July 2017, <https://www.adapture .com/blog/evaluating-leading-endpoint-security-vendors/> McFadden Expires August 14, 2021 [Page 29] Internet-Draft Evolution of Endpoint Security February 2021 [31] Dix, J., "Layered Security Defenses What layer is most critical network or endpoint", July 2011, <https://www.networkworld.com/article/2220204/ tech-debates/layered-security-defenses--what-layer-is-most-critical--ne twork-or-endpoint-.html>. [32] Hstoday, ., "Layered Approach Critical to Effective Endpoint Protection ", October 2016, <https://www.hstoday.us/channels/federal-state-local/l ayered-approach-critical-to-effective-endpoint-protection/>. [33] Taddei, A., et.al., [I-D:draft-taddei-smart-cless- introduction], "Capabilities and Limitations of an Endpoint- only Security Solution, July 2020, (expired). McFadden Expires August 14, 2021 [Page 30] Internet-Draft Evolution of Endpoint Security February 2021 Appendix A. Operational Experience and Endpoint Security This appendix attempts to document operational experience related to endpoint security. The original text in this Appendix comes from research and experienced from a single security solution provider. What follows is reporting from that organization. There are two appaorches to reporting on security incidents that are based on operational experience. They are: o the method described in {{MONEYBALL}} o the anonymised production data of Symantec MSS production for the past 3 months The core idea is to consider, based on all the imperfections we started to list above including the 'grey areas', that cybersecurity analysts are often presented with suspicious machine activity that does not conclusively indicate a compromise, resulting in undetected incidents or costly investigations into the most appropriate remedi As Managed Security Services Providers (MSSP's) are confronted with these data quality issues, but also possess a wealth of cross- product security data that enables innovative solutions, we decided to use the Symantec MSS service for the past 3 months. The Symantec MSS service monitors over 100 security products from a wide variety of security vendors for hundreds of enterprise class customers from all verticals. We selected the subset of customers using the service that deploy both network and endpoint security products to determine which types of security incidents were most likely to be detected by endpoint products vs. network products. In doing so, we were particularly interested in identifying which categories of incidents are detected by endpoint products and not network products, and vice versa. Thus, we examined prevalent categories of incidents for which the only actionable security alerts were predominantly produced by one type of security product and not the other. To do so, we extracted all security incidents detected by Symantec MSS on behalf of hundreds of customers that deploy both network and endpoint security products, over a three-month period from December 2018 through the end of February 2019. We acknowledge that some attacks might have been blocked by the first product and therefore have never been seen by the next security solution, which influences the final numbers. With this in mind, we could identify incidents based on: McFadden Expires August 14, 2021 [Page 31] Internet-Draft Evolution of Endpoint Security February 2021 | Severity | 4 - Emergency, 3 - Critical, 2 - Warning, 1 - Informational | | Incident Category | Malicious Code, Deception Activity, Improper Usage, Investigation, etc. | | Incident Type | Trojan Horse Infection, Suspicious DGA Activity, Suspicious Traffic, Suspicious URL Activity, Backdoor infection, etc. | | # network incidents | Amount of network only security incidents | | # all incidents | What is the total amount of incidents on all security solutions | | Percentage | Percentage of network security only incidents | We ended up with o Hundreds of thousands of security incidents o which we could categorize in 275 incident types by category and severity (triplets Severity-Category-Type) o out of which we searched how many incidents of each type were detected by a network security product and missed by deployed endpoint security products at least 75% of the time or vice versa A.1. Endpoint only incidents The categories of incidents that are detected primarily by endpoint security products are fairly intuitive. They consist primarily of detections of file-based threats and detection of malicious behaviors through monitoring of system and network behavior at the process level. The most prevalent of these behavioral detections include detections of suspicious URLs based on heuristics and blacklists of IP addresses or domain names. Since most of these alerts are not corroborated by network products, it seems probable that the blacklists associated with network products tend to be more McFadden Expires August 14, 2021 [Page 32] Internet-Draft Evolution of Endpoint Security February 2021 focused on attacks while host-based intrusion prevention system alerts focus more on malware command and control traffic. Most other behavioral detections at the endpoint provide alerts based on system behavior that is deemed dangerous and symptomatic of malicious intent by a malicious or infected process. The highest severity incidents detected on endpoints are instances of post-compromise outbound network behavior that are symptomatic of command and control communications traffic, but these did not show up as being primarily detected by endpoint products as they are frequently corroborated by network-based alerts. A.2. Security incidents detected primarily by network security products Perhaps less intuitive are the results of examining categories of security incidents that are detected primarily by network security products and only rarely corroborated by endpoint security products. Below we provide details regarding incident categories for which a network security product produced a detection and for which there were no actionable endpoint alerts for at least 75% of the incidents in the category. In our study we found 32 incident type, category, and severity triplets of this type. The following categories critical incident types were reported by MSS customers, and we discuss each in turn in decreasing order of prevalence: A.2.1. Unauthorized external vulnerability scans Perhaps unsurprisingly, unauthorized external attempts to scan corporate resources for vulnerabilities and other purposes are detected in large volumes by a broad variety of network-focused security products. 79% of incidents of this type were detected by network security products with critical-severity alerts, these security incident detections are not accompanied by any actionable endpoint alerts, despite the fact that endpoint security products are deployed by these enterprises. This category of threats encompasses a broad variety of attacks, the most prevalent of which are the following: Horizontal scans, SQL injection attacks, password disclosure vulnerabilities, directory traversal attacks, and blacklist hits. Of these categories of detections, horizontal scans stand out as the category of detection that endpoint-security products are least likely to detect on their own. A.2.2. Unauthorized internal vulnerability scans Unauthorized internal vulnerability scans, though less frequent, are more alarming, as they are likely to represent possible post- McFadden Expires August 14, 2021 [Page 33] Internet-Draft Evolution of Endpoint Security February 2021 compromise activity. We note that the Managed Security Service works with its customers to maintain lists of devices that are authorized to perform internal vulnerability scans, and their activity is reported separately at a lower levels of incident severity. 89% of detected unauthorized internal vulnerability scans are detected by network products without any corroborating actionable alerts from endpoint security products. As compared to unauthorized external scan incidents, internal hosts that perform vulnerability scans are far more active and the fraction of alerts that detect horizontal scans is higher, representing half of the total alerts generated. Alerts focused on Network-Behavior Anomaly Detection also appear for internal hosts. A.2.3. Malware downloads resulting in exposed endpoints This category of threats is generally detected by network security appliances. Despite these enterprises being purchasers of endpoint security products, 76% of the incidents detected by the network security products do not show a corresponding alert by an endpoint security product. A broad variety of network appliances contributed to the detection of a diverse collection of malware samples. A.2.4. Exploit kit infections This category of infections represents instances in which the customer's machines are exposed to exploit kits. These threats were detected by network appliances that extract suspicious URLs from network traffic taps and use a combination of sandbox technology and blacklists to identify websites that deploy a variety of exploit kits that were not being caught by endpoint security products. In this three month time period, the most prevalent categories of exploit kits detected involved redirections to the Magnitude exploit kit and exploit kits associated with phishing scams and attempts to expose users to fake Anti-Virus warnings and tools. A breakdown of the results is included below: | Severity | 3 - Critical | | Incident Category | Malicious Code | | Incident Type | Exploit Kit Infection | | # network incidents | 26 | | # all incidents | 26 | | Percentage | 100% | McFadden Expires August 14, 2021 [Page 34] Internet-Draft Evolution of Endpoint Security February 2021 The network security product that detected these incidents produced the following alerts: o Advanced Malware Payloads o Exploit.Kit.FakeAV o Exploit.Kit.Magnitude o Exploit.Kit.MagnitudeRedirect o Exploit.Kit.PhishScams o HTMLMagnitudeLandingPage A.2.5. Attacks against servers In addition to detecting the aforementioned critical security incident categories, network security devices frequently detect a broad variety of attacks against servers that usually lack corroboration at the endpoint. Most server attacks are not matched by endpoint protection alerts: 62% are unmatched for critical incidents, and 88% are unmatched as lower severity incidents. This category of incidents is the most prevalent category of incidents detected primarily by network products, but they are usually rated lower in severity than the aforementioned classes of alerts as they are very commonplace. Even when these alerts are corroborated by endpoint protection alerts, the endpoint alerts are often low in severity, as in the case of file-based threats that appear to have been blocked or successfully cleaned up by an Anti-Virus solution. The challenge in taking action against server attacks is that it can be difficult to assess which of these attacks were successful in causing actual damage, and for this reason, for the fraction of server attacks that demonstrate corroborating endpoint security alerts, even if of low severity, should be examined. It is interesting to note the cooperative role played by both network and endpoint security devices in these instances. McFadden Expires August 14, 2021 [Page 35] Internet-Draft Evolution of Endpoint Security February 2021 Authors' Addresses Mark McFadden Internet policy advisors ltd uk 6 Bridge Street Chepstow, Wales NP16 5EY United Kingdom Phone: +44 2921 25 3649 Email: mark@internetpolicyadvisors.com McFadden Expires August 14, 2021 [Page 36]