Introducing “Grey Zone Devices (GZDs)”: Bridging the Gap in System Classification

Talking about certain systems in cybersecurity can be tricky when we don’t have the right terms. In a previous blog post, I pointed out a group of systems that attackers are increasingly targeting. There’s a lot of talk about XDR (Extended Detection and Response) these days, suggesting it covers more than just the usual endpoints like in EDR (Endpoint Detection and Response). This often means including different devices and operating systems, mainly by using their built-in logging.

System groups and EDR / XDR coverage

But recent incidents show there’s a group of systems that doesn’t fit the usual “endpoint” or “IoT” labels. Most are appliances, but some are services on limited systems. Some can’t be modified because of their design, while others have strict user agreements that prevent the installation of additional software.

This lack of a clear name for these systems can cause confusion and missed security issues. To help, I’m introducing the term “Grey Zone Devices (GZDs)” for this group.

Definition of GZDs

GZDs are not traditional systems such as workstations or servers, nor are they considered IoT devices. They essentially represent the spectrum of devices that don’t fit within these two established groups. Predominantly, these are appliances, with a minority functioning as services running on locked down operating systems. These systems are often constrained by vendor restrictions, which can be either technical limitations or legal constraints, such as specific licensing terms. Unlike conventional platforms, they often lack standard tools and permissions, which could facilitate integration and security management.

GZDs Cybersecurity Implications

Bypass Standard Solutions

• GZDs often fall outside the coverage of traditional Endpoint Detection and Response (EDR) or Antivirus (AV) solutions.
• Vendors often include clauses in their EULAs prohibiting modifications, reverse engineering, or unauthorized integrations with additional security software. Breaching these terms can lead to a voided warranty.
• Technical limitations further hinder the protection of these devices. These might include an uncommon operating system, a restricted shell, less prevalent architectures like ARM, missing software libraries, or the simple fact that security solution vendors do not offer support for these platforms.

Lack of Centralized Integration

• The challenge isn’t just the absence of centralized logging. Many GZDs have local user management systems, meaning password complexity policies might deviate from standard organizational practices.
• Overall, there’s a significant deficiency in integration and visibility into these devices, making consistent policy enforcement and monitoring problematic.

Potential Targets

• There’s a noticeable trend of threat actors targeting GZDs.
• An increasing number of incidents indicate GZDs are being used for persistence or as staging areas for further malicious activities within networks.

Examples of GZDs

1. Appliances: Many network or security appliances come with a specialized OS tailored for the device’s primary function. These systems are locked down to ensure optimized performance and security. This category includes devices from vendors like Palo Alto, Fortinet, Citrix, or Cisco, where adding software not sanctioned by the vendor might be restricted.
2. Specialized Industrial Systems: These can include industrial control systems (ICS) or SCADA systems utilized in specific industries or critical infrastructures. Vendors such as Honeywell, Siemens, and Rockwell often have strict requirements regarding software configurations to maintain system stability and safety.
3. Embedded Systems in Non-IoT Devices: These are computer systems with a dedicated function within a more extensive system. Examples could be ATMs or certain types of digital kiosks. They often run a stripped-down version of an OS and might have limitations on software installations to ensure they run their primary function efficiently.
4. Mobile Device Management (MDM) Platforms: These solutions control how corporate mobile devices are used and secure the data on them. Companies like Ivanti (previously MobileIron) or VMware AirWatch might set limitations on the software that can be installed on devices they manage, especially if it interferes with the MDM’s functionality.
5. PBX Systems: PBX systems manage internal and external communication for organizations. Modern solutions, offered by vendors like Avaya, Cisco, Siemens, or Mitel, often run on proprietary or customized platforms. Given their critical role, vendors impose strict restrictions to ensure stability and security. Unauthorized software additions can breach EULAs, cause system instabilities, or result in loss of vendor support. These constraints are pivotal, as disruptions can significantly impact an organization’s operations.

Links

Mention of this type of devices in chapter “Threat Actors Using Systems Out of EDR Scope for Persistenc” in my recent blog post on “Emerging Cybersecurity Threats: What to Watch Out For in Q4 2023”
https://cyb3rops.medium.com/emerging-cybersecurity-threats-what-to-watch-out-for-in-q4-2023-54d4d149d0ab