Security Posture of the UEM Modern Architecture

Introduction

The new Modern SaaS Architecture enables IT administrators to manage large device fleets with the speed and efficiency required in today's dynamic environments. This modernized architecture is composed of multiple microservices, each deploying its own group of service nodes and maintaining its own persistent data storage. The existing UEM components, such as the Console, Device Service, and API, will continue to serve as the application gateway to the modern SaaS architecture.

The microservices within the modern UEM architecture are interdependent and operate as a cohesive unit to deliver the UEM functionalities that IT administrators rely on. These microservices are hosted on a foundational platform called the Workspace ONE Control Plane (CP). CP is a horizontally and vertically scalable platform that allows UEM microservices and their dependent services to be widely distributed. The compute nodes, database nodes, and infrastructure nodes for the modern UEM architecture are deployed together in units called Control Plane Logical Deployments (LDs). A UEM SaaS datacenter may contain multiple such LDs to ensure effective load distribution and scaling. A single LD can serve multiple traditional UEM environments.

Security of the modern UEM architecture, including its microservices, CP, and infrastructure, is ensured through multiple layers of security measures and secure development practices. This document focuses on the security posture that protects customer environments and data within the modern stack.

Security Measures

The modern UEM architecture is secured through the following measures:

In Development:
- Secure Coding Practices
- Security Vulnerability Scanning
In Production / During Operation:
- Encryption in Transit
- Encryption at Rest
- Secure Data Boundary
- Authentication and Authorization

Secure Coding Practices

Secure coding practices involve adhering to a set of guidelines and best practices designed to minimize vulnerabilities and enhance the security of software applications. By incorporating secure coding during the development phase, potential security flaws such as SQL injection, cross-site scripting (XSS), and buffer overflows can be proactively mitigated. The modern UEM architecture engineering teams follow and adhere to many of the OWASP Secure Coding Practices. These practices include a well-defined design review process, thorough code reviews, static code analysis using SonarQube, and secret management using Vault. Implementing secure coding practices ensures that the modern UEM architecture not only functions efficiently but also protects sensitive data and withstands malicious attacks, thereby enhancing the overall security posture of the application.

Security Vulnerability Management

The modern UEM architecture follows a well-defined vulnerability management and remediation process for identifying and rectifying security vulnerabilities. This process involves leveraging tools such as Twistlock and Docker CIS Benchmark analysis. Discovered vulnerabilities are addressed based on specified SLAs (driven by hardened requirement sets like FedRAMP), ensuring timely remediation. This approach not only enables the modern UEM architecture teams at Omnissa to stay ahead of security vulnerabilities but also ensures compliance with government regulations and security requirements.

CVSS Score	Severity	Mitigation Plan
9.0-10.0	Critical (Zero Day)	Work on a fix or a corrective action begins immediately and is provided to customers in the shortest commercially reasonable time.
7.0-8.9	High	A fix is delivered in the next planned maintenance or update release of the product where relevant
4.0-6.9	Moderate	A fix is delivered with the next planned release of the product.
0.1-3.9	Low	A fix is delivered with the next planned release of the product.

Additional information can be found at the source page for Ominssa’s External Vulnerability Response and Remediation Policy.

Encryption in Transit

Encryption in transit refers to the practice of encrypting data as it moves between components and systems. This ensures that data remains secure and protected from interception or tampering during transmission. As the number of microservices grows and the complexity of service dependencies increases in a distributed microservice-based system, traditional approaches to service networking with load balancers and firewall rules are insufficient to handle the dynamic nature of service communications. By using approaches like service mesh and protocols like TLS (Transport Layer Security), the modern UEM architecture ensures that customer data is securely encrypted and remains confidential while travelling from one point to another. This is a crucial layer of security as it maintains the integrity and privacy of data exchanges.

A service mesh is a software-driven approach to routing and segmentation. The service mesh, deployed within the Modern SaaS Architecture, is designed to simplify microservice networking by shifting routing, authorization, and other networking functionalities from centralized middleware to the endpoints distributed across the network using software proxies, such as Envoy.

All traffic between services is encrypted and authenticated with mutual TLS. Using TLS provides a strong guarantee of the identity of communicating services and ensures all data in transit is encrypted. TLS certificates are used to identify services and secure communications. These certificates use the SPIFFE format for interoperability with other platforms.

Encryption at Rest

Encryption at rest refers to the practice of encrypting data stored on a disk to protect it from unauthorized access. This ensures that even if physical security measures fail and storage devices are accessed by malicious actors, the data remains unreadable without the proper encryption keys. By implementing encryption at rest, the Modern Architecture inherently safeguards sensitive information, maintaining data confidentiality and integrity while complying with regulatory requirements and industry standards.

The UEM modern architecture implements data encryption at rest at the storage block level using Linux Unified Key Setup (LUKS). LUKS is a specification for block device encryption that establishes the on-disk data format and encryption key management policy. Data is encrypted and decrypted transparently when reading from or writing to the disk. LUKS accesses the kernel device mapper using the dm-crypt module, enabling low-level mapping that handles encryption and decryption of data as it is written to or read from the disk. The cryptsetup utility is used for creating and accessing LUKS encrypted mounts on virtual machines (VMs).

In addition to primary data storage, data backups (taken for recovery purposes in case of unexpected events and disasters) are also secured and encrypted using LUKS.

Secure Data Boundary

Historically, the Workspace ONE UEM data boundary was drawn solely at the SQL database level, leading to an inconsistent experience across all available Workspace ONE UEM hosting options and placing heavy reliance on the physical layer to implement data-level controls. With the introduction of the modern UEM architecture, the team at Omnissa is significantly enhancing how we structure and classify all data that traverses through the modern system at the application layer. These improvements are driven by the implementation of tenancy context at the individual data element level.

Tenancy Context allows Workspace ONE UEM to evolve in many different ways across the platform. Before delving into those advancements, it is important to define what the Tenancy Boundary is and how those boundaries are structured. Within Workspace ONE UEM’s Modern Architecture, several boundary lines have been established. The primary boundary line is the Customer OG (Tenant), as this is the level at which most customers interact from a top-level organizational perspective. Within a Customer OG, multiple subgroups (child OGs) can represent internal organizational divisions based on various functional, geographic, and organizational entities, allowing for inheritance. In addition, this tenant-level separation also facilitates multi-tenancy, ensuring that data is managed securely and efficiently within the platform.

Now that we understand where these lines are drafted – let’s jump into how this is evolving the platform.

Data Security - With the Tenancy ID implementation all data is now earmarked to a specific tenant in the database using Row Level Security (RLS). This earmarking combined with the service-to-service token enhancement we will talk about in the next section leads us to an experience where all data elements are only granted in a least access format leading to an assurance that any data stored within the Workspace ONE UEM system is completely secured and only visible to a matching tenant request.
This tenancy ID is also a uniquely generated and non-enumerable value which can only be accessed by the service level implementation.
Tenant Mobility - With the introduction of Tenancy ID data is stored in a more structured fashion which can improve how we manage or even balance that data. Where it was never possible to migrate information into or out of a Shared SaaS environment - with this data context we can better meet customer needs and ensure their data resides where it is needed all while providing a better performance experience for all Workspace ONE UEM customers.
Row-Level Security (RLS) - In addition to the data security provided by the Tenancy ID Workspace ONE UEM has also implemented Row-Level Security in PostgreSQL. RLS allows the definition of security policies on the data structures held within UEM to restrict row access and modifications in SELECT, INSERT, UPDATE, and DELETE queries. This allows cloud-centric SaaS service design to exist while not compromising any customer’s data boundary as the data boundary can be defined as granular as the row level.
Document-Level Security (DLS) is implemented in OpenSearch to ensure that data is accessible only to authorized entities. This mechanism safeguards the confidentiality, integrity, and availability of data by enforcing access controls at the document level.

Authentication and Authorization

We laid a solid and clean foundation for application authentication and authorization for the modern UEM architecture from the beginning. The tenancy boundary is consistently maintained in the entire call chain among the services and in all the layers in each service’s implantation.

The tenancy boundary, which is expressed as the tenant UUID (a.k.a., tenant ID), is determined when a request is first received by the upstream services, such as Console, Device Service and API. The tenant ID is passed along by the upstream services in the subsequent requests to the modern UEM architecture services.

The authentication protocol for the modern UEM architecture is the OAuth2 Client Credentials Grant. Each Logical deployment has a Token Service, which signs JWT tokens with the Token Service’s private key. A request to a modern UEM architecture service must include a valid JWT token in the Authorization header. To obtain that JWT token, the client must first request the token from the Token Service. The Token Service issues OAuth tokens only to trusted clients, who have valid client credentials. The tenant ID is a required claim in the OAuth token. Putting these measures together, it is ensured that the tenant ID is always included in each request and it cannot be faked by untrusted clients.

When a modern UEM architecture service receives a request, it first validates if the token is signed with the trusted issuer and it has not expired. After token validation, the service uses the trusted tenant ID in the token to check whether the requested resource in the request URL or request body is in the data boundary set by the tenant ID, and the service also passes the tenant ID to the database for the database script to include the tenant id in the data query.

Summary and Additional Resources

By implementing a hardened development process and supplementing that with a core focus on software security, Omnissa’s Workspace ONE UEM positions itself to ensure that we continue to deliver on our commitment to providing a secure and trusted platform. These strategies, accompanied by a culture of transparency through communication and documentation, highlight that Omnissa is not only focused on the software side of the equation but also on what makes any software company great - Its customer and partner relationships. Through this combined approach, Omnissa strives to foster an even greater level of trust among customers and partners, both present and future, ensuring long-term success and stability in an ever-evolving software landscape.

Additional Resources

Explore the following resources for certification and compliance:

Compliant Product Workspace ONE UEM Version 2209
Workspace ONE UEM makes strides towards EAL4+ In Evaluation Status
Workspace ONE Cloud Services Security

Changelog

The following updates were made to this guide:

Date	Description of Changes
2024/08/13	Guide was published.

About the Author and Contributors

This guide was authored by:

Benjamin Jacoby, Group Product Line Manager, Omnissa.
Jinsong Liu, Engineering Manager, Omnissa.
Gajan Pathmanathan, Engineering Manager, Omnissa.

Feedback

Your feedback is valuable.

To comment on this paper, contact End-User-Computing Technical Marketing at tech_content_feedback@omnissa.com.

Filter Tags

Workspace ONE Workspace ONE UEM Document Fundamental Overview Public Sector