For stakeholders to begin effective conversations regarding cyber threats to AR device solutions, it is useful to understand a few key terms and distinctions:
Threat The expressed potential for occurrence of a harmful event such as an attack.
Attack An action taken against a target with the intention of doing harm.
Vulnerability A weakness that makes targets susceptible to an attack.
When assessing the overall security posture of an AR device within the enterprise, it is important to establish these distinctions in order to communicate clearly with stakeholders, evaluators, and testers. An instance of an AR device may have certain threat vectors that stem from its communication protocols, storage capabilities or operating system. Vulnerabilities may be weaknesses in those features that can be exploited for an attack. When establishing a security profile of a device, threats are normally static, based on the implementation, and vulnerabilities are dynamic, based on the protection mechanism established. Attacks may be categorized to provide penetration testers with a target scope of interest for their evaluation.
| Today, AR devices inherit protection from the OS, connected host system, and MDM platforms – which is insufficient. |
As discovered in the AREA study team’s device research, most AR devices today inherit protection mechanisms from either the operating system platform, the connected host systems, or a mobile device management (MDM) system – which are individually and collectively insufficient. For example in the case of reliance on host operating systems primarily derived from mobile OS platforms (Android® and Windows® 10), protections share the strengths and weaknesses of those systems. The vast majority of Android platforms exist in the mobile cell phone space and security mechanisms are largely handled by ecosystem-wide updates pushed down by the cellular provider. Enterprises with AR devices not directly connected to an external provider are forced to implement a separate patch management program. This gap provides a potential attack vector as vulnerabilities are discovered in the mobile platform space. Evaluating each component of the integrated AR system will help to discretely identify such vulnerabilities.
To identify system components and interrelations, the ISO/IEC are currently working on a Mixed and Augmented Reality (MAR) Reference Model. Expanding on that ISO MAR model, the Electric Power Research Institute (EPRI) recently published a report on Enterprise AR Vision, Interoperability Requirements, and Standards proposing an AR Interoperability Framework. The Interoperability Framework is divided into three-layers of Information and Communications Technology (ICT) components required for presenting AR experiences to a user (see Figure 1-4, below). The top layer shows those components closest to the physical world used for context capture and experience presentation. The middle layer illustrates middleware components necessary for AR presentation from the native device operating system to the local and remote resources shared with other mobile systems and applications, depicted on the bottom layer. Each component in the AR Interoperability Framework can give rise to threat vectors from which the system must be protected.
FIGURE 1-4: Component layers of the Augmented Reality Interoperability Framework. Courtesy EPRI and Perey Research and Consulting.
Taking a functional viewpoint on many of the same ICT elements shown above, the ISO MAR Reference Model offers the element schematic, shown in Figure 1-5, below. That viewpoint illustrates both the components and required connectivity to offline data sources, all of which expose potential attack vectors in the communication, authentication, authorization, and verification space. The connected nature and offloaded security mechanisms provide opportunity for interception, manipulation, and perturbation of data to/from the AR device.
FIGURE 1-5: Component viewpoint of ISO Mixed and Augmented Reality Reference Model. Courtesy EPRI and Perey Research and Consulting.
To reiterate, when evaluating risks to the enterprise from introducing AR devices, one cannot simply inherit requirements directly from existing mobile and IoT frameworks. AR devices engender new and novel threats and impact risks. AR system threat boundaries cross into multiple product domains and share commonalities with a wide variety of devices. The majority of platform-based threats are inherited from common operating system threats, referenced above, and application threats in the enterprise will typically be customized software requiring traditional code analysis to determine data resiliency. Additionally, AR devices introduce bridges between cyber threats and kinetic factors similar to characteristics of devices in the IoT domain.
| Mobile and IoT cyber security frameworks are insufficient for evaluating risks to the enterprise from introducing AR devices. |
From a software perspective, AR devices are quite similar to mobile devices like tablet computers. Most current AR devices feature multi-purpose OSs, such as Android, Windows, or Linux. Many of the software security functions can be provided by these OSs (access control, etc). The processing power of the devices allows them to run several processes, and functions such as software encryption and signing could easily be performed in software. The best way to secure these systems is to harden the OS utilizing best practices appropriate for the specific OS of the device.
AR devices will be loaded with new software applications and drivers which may never have been thoroughly tested for security. The asset owner should require a complete manifest of all software included on their devices, references to known security vulnerabilities, and for higher protection levels, strict secure coding standards for all software. Owners should also utilize independent security evaluations of all new software.
A critical difference between AR devices and other mobile devices is the methods for user interaction. Common modes for interacting with an AR device are gestures, gaze, and voice, opening the software to new UI attack vectors. Many AR devices feature remote management consoles to allow setup, policies, debugging, monitoring, and other functions. These remote consoles need to be properly developed and secured to prevent remote vulnerabilities.
The International Electrotechnical Commission (IEC) is an internationally-recognized non-profit organization that publishes standards for electrical, electronic and related technologies. IEC 62443-3-3, Security for industrial automation and control systems – System security requirements and security levels, defines four security levels for rating cyber threat protection elements, providing guidance on how to evaluate the protection levels for different security functions.
IEC security protection levels.
| IEC Security Protection Level | Description |
| SL1 | Protection against casual violation |
| SL2 | Protection against intentional violation using simple means |
| SL3 | Protection against intentional violation using sophisticated means |
| SL4 | Protection against intentional violation using sophisticated means with extended resources |
The following items are required for SL > 0
The following items are required for SL >1
The following items are required for SL >2
The following items are required for SL >3
You must be an AREA subscriber and logged in to access this content. Please login or click below to create your free AREA subscriber account and access this valuable content today.
Need more advice on the types of membership you cant get? Click here for our FAQ section on memberships.