Security control catalogue
Introduction
This document provides an overview of the security controls available in Citrix SecurSpaces™. It supports security assessments, risk evaluations, and third-party due diligence reviews.
The controls described in this document reflect the SecurSpaces security architecture, operational practices, and shared responsibility model as a customer-hosted solution. They are designed to align with enterprise security requirements and industry best practices.
Additional documentation and supporting evidence can be provided on request to address specific security, compliance, or audit requirements.
About these identifiers
Each control below has a stable identifier, such as SDS-NET-01. These identifiers are assigned by Citrix so that a specific control can be cited in an assessment, a questionnaire response, or a support case.
They are not a mapping to ISO 27001, SOC 2, NIST, or any other framework, and they do not imply certification against one. For a mapping to a specific framework, or for supporting evidence, contact Citrix and specify what your review requires.
Identifiers are stable. A control that is withdrawn keeps its identifier, which is not reused.
Identity and access
| ID | Control | Implementation |
|---|---|---|
| SDS-IAM-01 | Single sign-on and multi-factor authentication | SecurSpaces supports enterprise single sign-on (SSO) through standards-based identity federation using SAML 2.0 or OpenID Connect (OIDC). Multi-factor authentication (MFA) can be enforced by the identity provider as part of the authentication flow. SecurSpaces also includes native MFA capabilities. |
| SDS-IAM-02 | Identity and authentication | SecurSpaces supports SAML 2.0 and OIDC for SSO and MFA enforcement. SecurSpaces also supports System for Cross-domain Identity Management (SCIM) for automated user provisioning, deprovisioning, and identity lifecycle synchronization from a central identity provider. |
| SDS-IAM-03 | Access management | SecurSpaces includes built-in role-based access control (RBAC). Administrators can map application permissions to local user accounts or to directory groups synchronized from the identity provider. For more information, see Role-based access control. |
| SDS-IAM-04 | Manage IT-level privileges | SecurSpaces separates infrastructure-level management from application-level administration. Because SecurSpaces is containerized and hosted on Kubernetes, the customer’s infrastructure team retains control over the underlying cluster, nodes, and container orchestration layer. Application-specific IT privileges, such as user management and configuration changes, are restricted to the application layer through granular RBAC. These privileges do not require direct access to the hosting infrastructure. |
Cryptography and secrets
| ID | Control | Implementation |
|---|---|---|
| SDS-CRY-01 | Encrypt data in transit | SecurSpaces encrypts data in transit using secure protocols. External web traffic uses HTTPS. TLS is terminated at the ingress controller, so the permitted TLS versions and cipher suites are set by the customer’s ingress configuration. Secure terminal sessions use SSH. Within the Kubernetes cluster, ingress-to-service and service-to-service traffic is encrypted with TLS. For the full list, see Cryptography. |
| SDS-CRY-02 | Encrypt data at rest | SecurSpaces is a customer-hosted solution. The customer is responsible for provisioning and managing the underlying database and persistent storage volumes. SecurSpaces is compatible with industry-standard encryption-at-rest technologies, including cloud-managed storage encryption, such as AWS KMS or Azure Key Vault, and encrypted Kubernetes Persistent Volumes (PVs). SecurSpaces also applies application-layer protection. When the external Vault feature is not enabled, developer secrets are encrypted in the database using AES-128-GCM. |
| SDS-CRY-03 | Manage certificates and certificate lifecycle | SecurSpaces relies on standard X.509 certificates for TLS encryption. For external traffic, SecurSpaces supports automated certificate lifecycle management tools, such as cert-manager, Let’s Encrypt, or internal PKI, to support certificate renewal without application downtime. For internal cluster traffic, SecurSpaces automatically manages the certificates required to maintain TLS between the ingress controller and backend services. |
| SDS-CRY-04 | Secrets management | SecurSpaces separates application and infrastructure secret handling. Application and developer secrets are managed at the application layer. By default, these secrets are encrypted before being written to the database using AES-128-GCM. SecurSpaces also supports integration with an external HashiCorp Vault instance. Secrets are injected securely into workspace runtimes through environment variables or volume-mounted configuration files. Infrastructure secrets, such as platform bootstrap credentials and database connections, use standard Kubernetes Secrets. Because SecurSpaces is customer-hosted, customers can add infrastructure-level protections, such as cloud provider KMS envelope encryption for etcd or a Secrets Store CSI Driver to inject infrastructure keys from an enterprise vault. |
Network security
| ID | Control | Implementation |
|---|---|---|
| SDS-NET-01 | Restrict network port usage to essential services | SecurSpaces operates with a minimal network footprint and exposes only the essential ports required for primary services: HTTPS on port 443, and SSH on an external port that you choose when you configure the ingress controller, commonly port 22. SecurSpaces also supports Kubernetes Network Policies, allowing network security teams to isolate pod-to-pod communication within the cluster and restrict traffic to essential paths. For the full list, see Ports and protocols. |
| SDS-NET-02 | Network policies | SecurSpaces is containerized and requires a Kubernetes environment. It can be deployed in an isolated virtual private cloud (VPC) or subnet. SecurSpaces includes preconfigured Kubernetes Network Policies to restrict internal pod-to-pod communication. Customers can add or customize these policies to match their cluster security requirements. |
| SDS-NET-03 | Protect exposed applications | SecurSpaces is designed to run behind the customer’s preferred web application firewalls (WAFs), reverse proxies, and API gateways. These controls can help filter malicious web traffic and protect against common web application risks, including OWASP Top 10 threats. |
| SDS-NET-04 | Zero-trust data protection | SecurSpaces applies zero-trust principles across the application and network layers. At the application layer, every API call and data request requires explicit authentication and authorization. SecurSpaces verifies cryptographic tokens before granting data access. At the network layer, traffic from the ingress controller to backend services is encrypted with TLS. Within the cluster, SecurSpaces supports Kubernetes Network Policies to isolate and restrict pod-to-pod communication so that only explicitly authorized microservices can exchange network traffic. |
Platform and container hardening
| ID | Control | Implementation |
|---|---|---|
| SDS-HRD-01 | Hardening baseline | SecurSpaces uses a hardened container baseline. Core SecurSpaces service container images are built on the Debian-based Distroless image gcr.io/distroless/static-debian12, which remove unnecessary packages, shells, and system utilities to minimize the exploitable attack surface. A dedicated Ubuntu-based image is used only where specific SecurSpaces workspace features require standard OS utilities. |
| SDS-HRD-02 | Container security | Core backend services use minimal Debian Distroless images to reduce the attack surface. Where specific workspace features require standard OS utilities, SecurSpaces uses dedicated Ubuntu images. Because SecurSpaces is customer-hosted, customers are responsible for implementing and operating runtime container scanning to validate images against corporate baselines. SecurSpaces is compatible with these scanning controls. |
| SDS-HRD-03 | Image build isolation | Images built on the platform with Create Image From Existing run in a Kubernetes Job using rootless BuildKit inside a user namespace. The build container is not privileged and runs as a non-root user, all Linux capabilities are dropped, and the user-supplied build process itself holds none. CPU and memory ceilings bound the build so a runaway script cannot exhaust the node, a wall-clock deadline stops a hung build, and the Job is never retried. The feature is inactive until a platform administrator configures a destination registry. |
Data loss prevention
| ID | Control | Implementation |
|---|---|---|
| SDS-DLP-01 | Data loss prevention | SecurSpaces provides native controls that support a data loss prevention (DLP) strategy. Clipboard security can be enforced to prevent users from pasting content from the IDE or secure browser into external applications. Workspace app security can require workspace applications to open only in a secure browser, helping reduce data exfiltration risk when developers share internal apps. Outbound network policies can restrict workspace traffic to approved repositories and domains. Audit events provide visibility into monitored or blocked activity. Where remote development over SSH is enabled, DLP effectiveness might be reduced and should be governed by customer policy. See Layered controls with the Citrix platform. |
Logging and monitoring
| ID | Control | Implementation |
|---|---|---|
| SDS-LOG-01 | Apply logging policy | SecurSpaces provides structured platform logging and real-time audit events. Platform logs capture application and service behavior to support operational troubleshooting, platform monitoring, and security investigations. The audit capability records security-relevant events, including authentication and session activity, user and workspace authorization actions, and data security events such as clipboard, upload, download, and monitored outbound network activity. These events are available on the SecurSpaces Audit page, where security teams can filter them by event type, severity, workspace, user, and date and time. This provides an operational audit trail for investigation and review. Platform audit events can also be exported in standard formats for downstream monitoring and SIEM integration. |
| SDS-LOG-02 | Send logs to a Security Information and Event Management system | SecurSpaces supports Security Information and Event Management (SIEM) integration by writing security logs in Common Event Format (CEF) to the underlying host nodes. These logs can be collected and streamed to the corporate SIEM by configuring a standard log forwarder, such as Filebeat or Fluent Bit, to monitor the configured directory. For more information, see SIEM integration. |
| SDS-LOG-03 | Establish detection use cases with the CSIRT | The SIEM integration supports filtering logs by severity threshold and event type. This allows the Cyber Security Incident Response Team (CSIRT) to create alerts for critical events, such as privilege changes or unauthorized access attempts. For more information, see Event categories and attributes. |
Operations and resilience
| ID | Control | Implementation |
|---|---|---|
| SDS-OPS-01 | Vulnerability management | Citrix continuously scans SecurSpaces source code and software dependencies for vulnerabilities. Security patches and minor updates are released periodically. |
| SDS-OPS-02 | Patch management | SecurSpaces deployments use standard container tags and package management mechanisms. Updates can be rolled out with minimal disruption, using approaches such as rolling updates or blue-green deployments, depending on the customer’s infrastructure configuration. |
| SDS-OPS-03 | Apply backup policy | SecurSpaces separates stateless application logic from stateful data stores. Customers can apply standard snapshotting, database backup scripts, and backup retention policies to the underlying storage volumes. |
| SDS-OPS-04 | Segregate production and non-production environments | The SecurSpaces deployment model supports isolated instances. Customers can deploy separate clusters or servers for development, staging, and production environments using separate environment configurations. |
Governance and assurance
| ID | Control | Implementation |
|---|---|---|
| SDS-GOV-01 | Governance and change management | SecurSpaces supports standard DevOps and GitOps deployment pipelines. Application configuration changes can be tracked through version control and infrastructure as code (IaC). Upgrades and configuration changes are documented in the release notes. For more information, see What’s new in SecurSpaces. |
| SDS-GOV-02 | Provide architecture documentation | SecurSpaces architecture documentation is available in the product documentation. A data flow diagram can also be provided as an annex when required. For more information, see Architecture. |
| SDS-GOV-03 | Application inventory | Citrix can provide an application and component inventory for the SecurSpaces platform on request. Customers should specify the required level of detail for their assessment. |
| SDS-GOV-04 | Infrastructure and access | SecurSpaces is customer-hosted. Physical, operating system, and infrastructure-level access are controlled and managed by the customer. SecurSpaces does not require external inbound vendor connectivity to function. |
| SDS-GOV-05 | Security stack on the SecurSpaces platform | SecurSpaces deployment configurations, such as Helm charts or Kubernetes manifests, and delivered container images are compatible with validation through the customer security stack. Although proprietary source code is not provided, SecurSpaces supports automated infrastructure-as-code linting, configuration compliance checks, and container image vulnerability scanning, including software composition analysis (SCA), before deployment. |
| SDS-GOV-06 | Third-party due diligence | Citrix can provide standard third-party assurance documentation on request. Customers should specify the artifacts required for their review. |
| SDS-GOV-07 | Security annex | A data flow diagram can be provided as part of the security annex when required for assessment or audit purposes. |
| SDS-GOV-08 | Non-disclosure agreement | Non-disclosure agreements are covered as part of the global contractual framework with Citrix. |
Related information
Security control catalogue
Copied!
Failed!