Gigamon Comments on Applying Zero Trust to Enterprise Mobility

Editor’s note: As a supplier of network software and hardware to multiple U.S. government agencies, Gigamon reviews and comments on many draft standards and documents issued by government agencies. This has accelerated as Zero Trust became a key focus, not only within the U.S. federal government, but also to other governments worldwide and into enterprises and even service providers. It’s safe to say that Zero Trust is a major driving force in security architecture.

To this end, Gigamon has decided to publish our feedback to these government documents here on this blog. The purpose of this is twofold:

1. To explain our strategic thinking around this major shift in the way we architect our INFOSEC infrastructure
2. To elicit comment and feedback from our customers and security architects, with the aim of enhancing the practicality and deployability of Zero Trust architectures

While NIST SP 800-207 has given us an excellent definition of what Zero Trust architecture is, there are so many ways this can be achieved and those discussions are worthwhile and mutually beneficial. Please feel free to do so by emailing Ian at (ian dot farquhar at gigamon.com) or by participating in the Gigamon Community’s Public Sector group.

Note: You can download the original draft document from CISA here.

Lastly, we welcome your feedback on whether this is beneficial. Our aim is to publish here moving forward when the response seems beneficial.

---

Gigamon appreciates the opportunity to provide comments on CISA’s draft whitepaper, Applying Zero Trust Principles to Enterprise Mobility (“ZT and Mobility Paper”). We believe this effort is a critical aspect of the federal government’s Zero Trust journey considering the highly sensitive data that traverse mobile devices in agency environments and the attendant risk associated with mobile device compromises. To that end, as explained in much greater detail below, Gigamon recommends that CISA modify the key takeaways of the ZT and Mobility Paper in a way that:

(1) Encourages agencies to reduce reliance on trusted hardware and built-in security features because (a) there is a mismatch between the prioritization of security between the mobile device/OS vendors and the federal government; and (b) considering the relatively low cost of most mobile devices, our adversaries can easily acquire, reverse engineer, and likely locate usable exploits in them; and

(2) Encourages agencies to incorporate network-based mechanisms to assess mobile device behavior and detect anomalies that may be indicative of compromised hardware and/or software, including within the device’s security infrastructure.

Consistent with the principles and tenets of Zero Trust, organizations should anticipate that mobile devices will be compromised and develop mechanisms to detect and mitigate this risk that are independent from the device itself. An organization cannot trust a compromised device to detect and alert on itself, particularly in a sophisticated supply chain exploit that implants code during the lifecycle of the device. In our experience, the packets are the ground truth, as an exploit must communicate with command and control infrastructure and to perform attacks. If an organization is monitoring behavior, these communications will be detectible even if a device is compromised.

Reduce Implicit Trust in Hardware and Built-in Security Features in Mobile Devices

Since mobile devices can be acquired easily and destructively analyzed, a motivated adversary will leverage the opportunity to use them as an attack vector.

The lessons learned from the video game console industry illustrate the challenges associated with delivering truly secure hardware and the ways hardware can be penetrated when the end user has access to the device. With only a couple of exceptions, video game consoles are sold as a “loss leader” through much of their lifecycle, where the console hardware is sold at cost, or at a loss, and profits are made via the sale of video games to run on that console.¹ As such, the “data right managements” protections in the form of software authenticity verification are essential to preserving the value of the business. While console manufacturers have deployed extremely sophisticated hardware and software protections, relatively low-resource/highly motivated individuals have penetrated and compromised these approaches using highly sophisticated attacks. Andrew Huang’s well-documented attack on the original Microsoft Xbox console, while a student at MIT, remains the canonical example and is documented in his book Hacking the Xbox: An Introduction to Reverse Engineering.²

Mobile device manufacturers will face the same challenges from well-resourced, highly motivated adversaries, who are likely to succeed in reverse engineering and compromising the devices. As such, the government must assume that the devices will be breached and develop a strategy to mitigate this risk. First and foremost, the agencies should not rely exclusively on security mechanisms built into mobile devices. Instead, the implementing agencies should develop network-based mechanisms to assess mobile device behavior to rapidly detect anomalies and mitigate risk from compromised mobile device hardware and/or software.

Further, while some devices are developed by a single domestic vendor (like Apple iOS) that maintains strong supply chain controls, other devices (such as third-party devices running Google’s Android operating system) are provided by many companies with varying supply chain and product support policies. In a BYOD environment, managing risk effectively for a variety of devices becomes challenging, even in a Zero Trust environment. Organizations will need effective checks and balances. In the mobility context, a network-based mechanism evaluating device behavior and detecting anomalies will mitigate the risk that a device’s security protections have been compromised and vice-versa. Neither approach should be trusted implicitly.

The “Impedance Mismatch” Between Mobile Device/OS Vendors and Government End-Users

Electrical engineers use the term “impedance mismatch” to describe a situation where the source and load of an electrical signal do not match, and the result is poor efficiency and outcomes. It represents an excellent metaphor for the next issue.

Device manufacturers, government agencies, and end users have different priorities, which can lead to the originator and consumer of mobile security infrastructure being mismatched. Government end users seek to protect their data and infrastructure from attack and ensure that legal, compliance, and regulatory requirements are met. Mobile device vendors recognize this but must balance other priorities, such as maximizing value to shareholders. While U.S. government enterprise users are a major segment, it seems unlikely that they will be the largest or even among the group of the largest users. The ability to protect the “walled gardens” of their app stores, to prevent loss of intellectual property, and many other considerations may be prioritized ahead of the needs of enterprise users.

The differing threat landscapes, priorities, and approaches may sometimes coincide, but often will be antithetical. For example, vendors may provide APIs to monitor application sandboxes on the OS for an enterprise user, which may be misused by attackers to undermine application security (and potentially the integrity of the vendor’s app store) in non-enterprise environments. Policy capabilities required by mobile application management (MAM) or mobile threat detection (MTD) may not be present because they’re not seen as economically critical enough by the vendor, and the threat model which mobile application vetting (MAV) uses can be more focused on the profits of the mobile device vendor than the end user’s legitimate InfoSec needs.

Fundamentally, any technique which relies upon the capabilities of the hardware, mobile operating system, or applications on the mobile device must extend at least some trust into that device. The ability to assess trustability is limited if you are running your code inside the blast radius that can be affected by an attacker on a compromised device. In this context, where the security prioritization between the government and the vendor do not necessarily align, the government should not implicitly trust the security protections in the device but should develop a way to externally validate device integrity.

Furthermore, treating the whole device as a single processor running the operating system inappropriately minimizes mobile device complexity. Most mobile devices contain multiple offload processors in addition to the main application processor: modem baseband processors, security processors, media accelerators, and so on. Indeed, the use of “application processor” as a term in mobile devices is a clear indication that more are present, which should be acknowledged, and the attendant risk managed. Many of these non-application processors run firmware which could operate independently of the overlying operating system and present a platform for the attacker to leverage, yet be essentially “below the firmware” or “implants” and be invisible to even the OS. For example, an implant in the Wi-Fi baseband processor may be able to generate traffic without the mobile operating system (and MDM software it is running) even being aware that traffic has been sent. It will also see any packets traveling through that NIC. Finally, few mobile device vendors are willing to provide agencies access to their internal microarchitectural design to even allow adequate risk assessment. There are even other issues like “binning” components, where off-the-shelf application processors may have functional cores which are not disclosed but may still be functional, depending on how the vendor fabricates the device.

In summary, understanding the attack surface and effectively mitigating risk within a mobile device is extremely difficult, and Gigamon recommends adding an NDR component that evaluates mobile device behavior to detect anomalies that may be indicative of a compromise.

Network-Based Mobile Threat Defense (As a Form of Network Detection and Response)

Gigamon recommends that behavioral observability (the “network environment” pillar and “visibility and analytics” overlay described in the draft CISA Zero Trust Maturity Model) be considered in terms of internal and external observability. In the current draft of the ZT and Mobility Paper, internal observability is robust and characterized as the ability to deploy enterprise mobility management (EMM), MAV, and SCT. These are critical but nonetheless incomplete if the security infrastructure of the device is compromised. Gigamon therefore recommends implementing an “external visibility” solution via MTD for the following reasons:

1. While the entire device may be completely compromised (irrespective of whether it’s at the application, operating system, or hardware level), any implant needs to communicate with its command-and-control infrastructure and perform attacks to advance the mission of the threat actor. These must transit the network and thus would be visible to network-based MTD and enable the policy engine to restrict the device and remediate the risk.

2. It removes the impedance mismatch between mobile device vendor and government end-user. The approach is independent of the device and doesn’t leverage the capabilities deployed by the vendor on the device, making this mismatch irrelevant.

3. While many communications protocols are encrypted, in-flight break-and-inspect decryption can be deployed, either pervasively or selectively. Furthermore, threat detection without decryption remains possible and widely deployed, and is especially useful when large numbers of otherwise similar devices are present, as anomalies between devices will become very clear. Selective decryption can be deployed on the basis of the policy engine evaluating device risk.

4. BYOD remains used in multiple U.S. government agencies, and MDM may simply not be deployable on these devices. Monitoring their on-prem network traffic could, however, provide controls to alleviate risk and measure device posture. BYOD also introduces the risk of a very large range of running mobile OS versions, especially for the Android ecosystem, the older and newer of which the MDM solution may not support.

5. It is also usable against traditional IT infrastructure and even devices (like IoT/OT/ICS/SCADA) that support neither MDM nor EDR. Anything which generates network traffic can be monitored, including traditional IT infrastructure.

6. While adversaries may attempt to leverage network evasion techniques, our extensive experience with network detection and response (which would include network MDT) demonstrates that adversaries have a much harder time evading network detections than evading logging and host-based detections. In fact, disabling host-based telemetry and agents has been a standard technique of successful attackers for decades, including the perpetrators of the SolarWinds breach. While different techniques may need to be used on mobile devices, it will be exceedingly difficult to prevent a successful exploit. An assumption of breach should be assumed across the board, and checks and balances to ensure the integrity of each mitigation measure need to be incorporated into the Zero Trust architecture.

To be clear, Gigamon fully supports EMM and the government’s evolving Zero Trust strategy. We do, however, recommend an approach that incorporates EMM plus MDT, so that MDT may check and confirm the trustability of EMM, and vice versa, consistent with the principles and tenets of Zero Trust.

---

Notes

1. Note that prepaid handsets are sometimes sold using a loss-leader business model.
2. Andrew Huang. Hacking the Xbox: An Introduction to Reverse Engineering. 2003. No Starch Press. https://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf.