Annex A: Endpoint Security
Overview
The Endpoint Security (END) Enterprise Security Focus Area (ESFA) represents IP-enabled physical and virtual computing platforms that consist of hardware and its associated operating environments. The operating environment includes operating systems, virtual machine managers (hypervisor, microvisor), and utility software. Utility software includes web browsers that essentially act as containers for downloadable mission-specific functionality. Mission-specific capabilities hosted by the endpoint are defined in other ESFAs. In particular, the NCS, OPS, and ICA ESFAs define a number of mission-specific functions hosted by endpoints.
General-purpose platforms that host functions not specifically identified by this architecture (see APP ESFA page) are characterized as client endpoints (directly accessed by the end user) and server endpoints (usually resident in a GC data centre or cloud provider). Endpoints can be further characterized as follows:
- Client Endpoint (workstation, desktop, tablet, smartphone, etc.)
- Server Endpoint (application server, database server, file server, etc.)
- Network Endpoint (switch, router, network security appliance, etc.)
- Network-Attached Peripheral Endpoint (printer, scanner, etc.)
- Hybrid Endpoint that relays network traffic but also provides application functionality (application proxy, email relay/server, etc.)
Components
The image below shows the components used to define the END ESFA. The components are intended to represent the superset of functionality required by a wide range of endpoint form factors and characteristics.
Descriptions of each of these components, including key interfaces with elements of the GC enterprise, can be found in the ESADD Annex A: Endpoint Security (END) document. The list of example technologies for each component contains examples of the types of technical solutions that embody the functions of that component.
Context
The image below shows the context of the END ESFA within the architecture of the GC enterprise. As shown, the END ESFA interacts with the other ESFAs as well as external entities.
_Context_View.PNG){kind=link}
Please see the ESADD Main Body for descriptions of the various GC Enterprise External Entities (i.e. direct attached peripherals, commercial application provider, etc.) for more information about the nature of each interface and the security considerations associated with each interfacing element.
Perspectives
This section will describe different aspects of the END ESFA architecture including security capabilities, an endpoint lifecycle perspective, and security models of endpoints.
For more information about this, please read the following sections which can be expanded by clicking on 'Expand' on the far right.
Capability Desires and Applicable Security Control Families
In support of characterizing device capability/usability desires from a functional user perspective, an endpoint is grouped into the following primary form factors:
- (ST) Stationary devices, such as traditional PCs, thin clients, operating systems and server platforms connected to network appliances (switch, router, firewall, etc.), and printers.
- (PT) Portable devices, such as laptops and tablets connected to various internal and external networks
- (MB) Mobile devices, such as smart phones with connectivity to commercial cellular infrastructure, various internal and external networks
- (SM) Storage media devices, such as SD cards, USB flash memory, external optical drives, tape drives, fibre SAN, and CD/DVD disks
Portable storage media, such as USB tokens may ben connected as a peripheral to ST, PT, and MB devices. While not endpoints, they influence user perspective and are therefore listed in a table under SM in the ESADD Annex A: Endpoint Security (END) document. The table lists what an end user desires from a capability or functionality standpoint in support of meeting their personal operational (e.g. ease of use, performance, access, convenience, etc.) perspectives.
For more information, please read the ESADD Annex A: Endpoint Security (END) document.
Endpoint Security (END) Target Security Architecture
With the rapid adoption of personal smart phone and tablet technologies, end users find themselves juggling multiple devices to manage their personal life and their work environment. End users are increasingly interested in a single device for both personal use and work use. Mobile device technology continues to evolve rapidly and this will place increasing pressure on industry and government to support Bring Your Own Device (BYOD) and Bring Your Own Government-Owned Device (BYGOD) policies that allow their employees to use the latest technology in performance and fashion.
A key element to making these paradigms a reality is the separation of personal applications and data from work-related applications and data. The integrity of the overall device must be maintained such that any attacks on the personal environment cannot put at risk the confidentiality or integrity of the work environment. Additionally, the information and processing of the personal side needs to be isolated from the work environment to avoid leakage of Personally Identifiable Information (PII) or other protected privacy information into the work environment.
A side benefit for government is that more robust versions of the same technologies may be used to provide secure separation between different sensitivities of data. In fact, several PC-based hypervisors have been approved by the United States government to simultaneously host adjacent classification levels of data (e.g. Unclassified and Secret or Secret and Top Secret).
As shown in the image on the right, a software component called a hypervisor (traditionally known as a Virtual Machine Monitor, or VMM) controls the hardware and allocates resources to Virtual Machines (VMs), each of which is capable of running an operating system and applications. Each VM is independent with the exception of explicitly permitted information flows between them. All allowed information flows are configured using well-defined policy rules, thereby reducing the risk of unauthorized leakage and/or tampering of data between VMs. The image directly below shows an example mapping of the functional architecture to the technical architecture. In an ideal world, all endpoint components with the exception of the Application Execution Environment would be mapped to Trust Services. In practice, these components may be mapped to Trust Services, the Support VM, or distributed over both.
The image on the right is an example that shows the co-existence of a personal environment and work environment of an endpoint.
In addition to supporting the BYOD and BYGOD use cases, these same techniques can be used to provide separation between VMs operating at different sensitivity levels on a government-issued device. In the architecture shown, each VM is responsible for implementing its own host-based protection capabilities, including malware detection and intrusion detection/prevention (IDS/IPS). These protection capabilities may be specific to the guest OS running in each VM. If virtual networking capabilities are implemented in the support VM, they could include network-based firewall and IDS/IPS functions.
The final component shown above and on the right is a Support VM. The Support VM acts as a unified Mobile Device Management (MDM) agent that monitors, controls, and configures the device on behalf of Security Operations (Monitoring/Diagnostics and Configuration Management components) running in the enterprise. At present, MDM solutions are proprietary, fragmented, and offer different feature sets, but this situation is expected to improve during the transition to the target Endpoint Security (END) architecture. In addition, the Support VM can be used to provide virtual security services to the Application VMs, it should be of equal or greater robustness to the Application VMs (preferably greater if it is mediating access to external interfaces), but need not be more robust than the hypervisor that hosts it.
The colours in the image above and on the right show the relative levels of trust in the different components of the architecture from an overall platform perspective. Within each VM, the Guest Operating System (OS) would be more trusted than the applications that run on the Guest OS. A layered and modular trust model of this nature is easier to develop, maintain, and evaluate for correctness than a single large monolithic environment. The strength of security mechanisms used to instantiate this architecture are the driving factor in the use of the eventual solution for separating sensitive environments on a single device.
The hypervisor is primarily responsible for making time- and space-partitioned hardware resources available to the VMs and is supported in that task by the Trust Services. The Trust Services are shown as being separate from the hypervisor as they may use hardware resources (such as ARM TrustZone technology) to isolate themselves from not only the VMs but also the hypervisor. The use of multiple layers of protection in this manner provides a very secure computing environment. This technology can also be used to isolate trusted platform functionality from a standalone operating system if virtualization is not required. From a security perspective, the preferred type of hypervisor is a "bare-metal" hypervisor, also known as a Type 1 hypervisor. Unlike a "hosted" (Type 2) hypervisor, a bare-metal hypervisor does not require an underlying general-purpose operating system. This allows it to be smaller, more efficient, and easier to evaluate for secure operation than a hosted hypervisor.
While only a single non-application VM is shown (the Support VM), other VMs can be created to implement trusted functionality that is not appropriate for Trust Services. As an example, this could include the VPN client. By implementing the VPN client in a separate VM, the Application VMs no longer need direct access to network interfaces and do not have the ability to bypass the VPN client. In addition if session keys are loaded into VM RAM for performance reasons (e.g. if an available hardware cryptographic module does not have the power or throughput to perform bulk encryption operations), performing encryption services in a dedicated VM provides greater protection to those keys from unauthorized access by other processes.
As the Support VM provides a limited set of specialized services, it can be built on top of a small operating environment (e.g. a microkernel) that is significantly easier to evaluate (and thereby achieve a higher level of robustness) than the general-purpose operating systems running in the Application VMs.
Endpoint Security (END) Sub-Elements
This section summarizes the role and identifies the sub-elements of each architectural element that comprises the Endpoint Security components.
Hardware
The hardware minimally consists of the CPU, Random Access Memory (RAM), non-volatile memory (e.g. flash) and peripheral interfaces. It may also consist of integrated Trusted Computing Base, power manegment, timing, cryptographic functions (including non-deterministic random number generation), and radio capabilities.
Other hardware capabilities may be installed after manufacture of the base endpoint device. They may be replaceable, or they may be permanently installed (e.g. with epoxy adhesive) to prevent subsequent replacement or tampering.
- External Cryptographic Module: This could be in the form of an SD card, microSD card, or Universal Integrated Circuit Card (UICC).
- External Non-Volatile Storage: External non-volatile storage may include integrated Data-at-Rest (DR) encryption capabilities.
Trust Services
Trust Services contains the most critical software capabilities that require evaluation to the highest levels of assurance.
- Virtual Trusted Computing: Provide virtual trusted computing capabilities to virtual machines. These virtual trusted computing capabilities may use physical trusted computing capabilities from the underlying platform for security.
- Cryptographic Services: Provides software-based cryptographic services to VMs.
- Policy Management: Cooperates with the hypervisor to enforce platform-level policy decisions. these include access to hardware resources by VMs and inter-VM information flows.
- Partition Management: Manages the time- and space-partitioning of processor and memory resources among VMs and cooperates with the hypervisor to enforce the partitioning. Includes adding, deleting, and updating partitions.
- Secure Storage: Provides software-based secure storage (in contrast to a self-encrypting flash drive, for example). This service may interact with the hardware Root of Trust for Storage (RTS) to provide this function.
- Use Interface Trusted Path: Provides a User Interface (UI) capability that cannot be taken over, hidden, or mimicked by a VM. Provides a guarantee that the user is interacting with Trust Services.
- Secure Channel: Provides a secure connection to the enterprise for management of the platform firmware updates, hypervisor updates, and configuration of the VMs.
- Runtime Integrity: Monitors the integrity of the hypervisor and VMs at runtime to detect any unauthorized changes to privileged executing code and other selected application code.
- Secure Boot: Supports the hardware Trusted Computing Base in providing secure and trusted boot services for the base platform. Implements the Trusted Network Connect (TNC) or equivalent protocol. This sub-element may also be responsible for ongoing runtime monitoring of the execution environment (specifically Trust Services and the hypervisor) to detect any loss of integrity and shut down the endpoint if detected.
Type 1 Bare-Metal Hypervisor
The hypervisor provides time- and space-partitioning, access to hardware resources, and inter-VM communications in cooperation with Trust Services. In this role, the hypervisor can be considered to be a Policy Enforcement Point (PEP) and Trust Services a Policy Decision Point (PDP).
The hypervisor may provide device driver support depending on its specific design. If it does not, device drivers may be implemented directly in each VM ("direct access"), in a separate privileged VM, or in Trust Services. In the last two cases, VMs are configured to use proxy drivers that communicate with the real hardware drivers wherever they are located.
User Interface
The User Interface (UI) provides the mechanisms for the end-user to interact with the VMs while maintaining the required separation. If permitted by policy, the UI may support the ability to transfer information between VMs (e.g. copy-and-paste). Trust Services is shown as having its own UI but may also use the capabilities of the UI sub-component. However, it should implement a trusted path feature that guarantees the end user is communicating directly with Trust Services.
Support VM
The Support VM provides local and remote device management services that are outside the scope of Trust Services. Other services, such as client VPN capability, may be included in this VM or in other dedicated support VMs. VMs of this nature are sometimes referred to as "helper VMs" as they often do not provide user-visible functionality but exist solely to support the Application VMs that do. Because they are specialized, they may run a small real-time operating system or other minimal operating environment. They may also be granted more privileges than Application VMs by the hypervisor. The specialized functionality and limited operational environment make it easier to evaluate a Support VM to a higher level of assurance than an Application VM. Moving privileged code to a Support VM as much as possible can limit the damage caused by privilege escalation attacks in the Application VM.
Application VM
The application VM runs the user's approved applications with a general-purpose operating system. This is the only type of VM that a regular end-user can modify through configuration or loading applications. The Application VM may be granted direct access to hardware resources, such as radios and network interfaces by the hypervisor, or it may be required to communicate with a Support VM through a proxy driver. This will often be the case for a network interface as this allows firewall, intrusion detection, and network encryption (VPN) services to be implemented in a dedicated VM that provides a high degree of resistance to tampering and bypass by a compromised or defective Application VM.
Mobile Device Ecosystem
It is important to recognize that an endpoint that conforms to the target architecture described above requires a sophisticated ecosystem to support it. The endpoint must interact with all other ESFAs over its lifecycle. The ecosystem services, including Mobile Device Management (MDM), are described in the subsequent ESADD Annexes which can be found on the ESA Reference Materials page.
The image below illustrates the scope of an ecosystem required to support and endpoint in the highest-risk connection scenario - that of a mobile endpoint connecting to the GC enterprise over a public network. As shown, the endpoint connects via a VPN gateway and then an Application Proxy. In addition to providing application-layer protocol validation and networking isolation, the Application Proxy can also provide a second layer of Data-in-Transit (DIT) encryption for sensitive data and authenticate the end user prior to granting access to the enterprise network. For mobile endpoints, mobility-specific application services (that, for example, use the reported GPS location of the endpoint), may be made available without the need to access to the GC enterprise network.
For more information, please read the ESADD Annex A: Endpoint Security (END) document.
ESADD Annex A: Endpoint Security (END) Pattern Diagrams
For the Pattern Diagrams for Endpoint Security (END) from the ESADD Annex A: Endpoint Security (END) document, please visit the ESA Pattern Diagram Repository.
List of ESADD Annex A Pattern Diagrams
- Pattern PN-EUD-001 Authenticate Device to Network
- Pattern PN-EUD-002 Install Security Patch
- Pattern PN-EUD-003 Wipe EUD – Local
- Pattern PN-EUD-007 Downloading Application Software to an EUD
- Pattern PN-EUD-008 Perform Vulnerability Scan – Local
- Pattern PN-EUD-009 Detect EUD Intrusion Attempt (Firewall)
- Pattern PN-EUD-010 Power On EUD (Authenticate to the EUD using Local or Cached Credentials)
- Pattern PN-EUD-011 Authenticate User to Enterprise
- Pattern PN-EUD-015 Provision EUD for Initial Use
- Pattern PN-EUD-018A Establish VPN – EUD User Initiated
- Pattern PN-EUD-018B Establish VPN – EUD Application Initiated
- Pattern PN-EUD-038 First Use of EUD
- Pattern PN-OPS-001 Discover Unauthorized Device
- Pattern PN-OPS-002 Detect Unauthorized EUD Configuration Change
- Pattern PN-OPS-003 Validate EUD Configuration
- Pattern PN-OPS-005 Load Standard SW-FW on EUD
- Pattern PN-OPS-006 Provision EUD Applications