Hyperspace Security Design

Security is a top priority at Hyperspace and is taken seriously. This document describes the current state of security at Hyperspace. This information can change rapidly, as we are constantly improving our security and continue to build our product.

Hyperspace follows industry standards and guidelines for security compliance and successfully undergoes security approvals with Fortune 500 and Global 1000 organizations on a monthly basis. We understand the value of formal certifications and have an active program underway to pursue SOC 2 Type II and ISO 27001 certification, further demonstrating our commitment to maintaining a secure and trusted environment.

For access to our further security and compliance materials, please contact our security team at security@hyperspace.mv.

Cloud Security

Security Architecture & Infrastructure

At Hyperspace, we follow cloud-native best practices, leveraging the security policies of the public clouds we use. Our architecture is designed to be cloud-agnostic, with future plans to operate on Google Cloud, Azure, and AWS. Currently, all of our application services are hosted on Google Cloud Platform (GCP) with user scenes and media assets hosted on Amazon Web Services (AWS). Therefore, our security policies follow GCP's and AWS's best practices. When this document refers to Hyperspace servers, it means instances within GCP. We do not operate any physical hosting facilities or computer hardware of our own.

You can find more information about GCP's security processes here: https://cloud.google.com/security

Data Center Physical Security

Facilities 

Hyperspace uses infrastructure from Google Cloud (GCP) and Amazon Web Services (AWS). The data centers we use hold certifications such as ISO 27001, PCI DSS Service Provider Level 1, and SOC 1 and 2.

Our providers use robust controls to ensure the security and availability of their systems, including backup power, fire detection and suppression, and secure device destruction.

On-Site Security GCP and AWS implement layered physical security controls to ensure on-site security. These include vetted security guards, fencing, video monitoring, and intrusion detection technology.

Network and Access Security

In-house Security Team Our security team actively responds to security alerts and events to maintain a secure environment.

Third-Party Penetration Tests We conduct third-party penetration tests on our application and infrastructure at least annually. All findings are tracked and remediated. Reports are available upon request, subject to an appropriate NDA.

Threat Detection & Vulnerability Scanning We leverage Google Cloud's threat detection services for continuous monitoring of malicious activity and perform regular internal vulnerability scans. Any identified issues are tracked to remediation.

DDoS Mitigation We use a layered approach to DDoS protection, including Cloudflare's CDN with built-in protection, native GCP and AWS tools, and application-specific mitigation techniques.

Access Control

Hyperspace uses a least-privilege access model, ensuring staff only have the access necessary for their roles. This is enforced and monitored through regular audits, with two-factor authentication (2FA) required for all production systems.

Role-Based Access Control (RBAC) We enforce RBAC to manage user privileges and provide built-in roles that grant specific access levels within a metaverse world, down to a space-level granularity. More details can be found at https://hyperspace.mv/academy/user-roles/.

Network & Service Access The only ways to access stored data, servers, or services within Hyperspace's VPC are through our VPN servers or Hyperspace API endpoints.

  • VPN Access: VPN access for Hyperspace operations staff requires a unique TLS auth key, CA certificate, and individual credentials. It also requires a hardware token for 2FA. Access is limited to necessary employees and can be revoked quickly.
  • SSH Access: We use a configuration management system to control SSH access via public SSH keys. Passwords are not used, and SSHing as root is disabled. Keys can be quickly removed and rotated if a laptop is lost or a key is compromised.
  • Employee Laptops: Employee laptops have Mobile Device Management (MDM) enabled, which enforces strong passwords, disk encryption, a network firewall, and the ability to remotely lock or wipe the device.

Network Security Within the VPC We use specific network security groups for our instances. By default, none are publicly reachable. We follow an allowlist-only approach, ensuring only necessary ports and protocols are open from required sources.

  • Load Balancers: Our Internet-facing load balancers for the API and Dashboard accept only HTTPS traffic on port 443 and redirect all HTTP traffic.
  • Cloudflare: We use Cloudflare endpoints for our website and Dashboard, which also terminate TLS connections and redirect HTTP to HTTPS.

Application & Data Access

  • Dashboard Access: Access is based on valid user credentials, and we rely on OAuth 2.0 for both internal and customer authorization. We can configure per-customer authentication using Google, Okta, or any service that federates via SAML.
  • API Access: Access is controlled by API keys, which are created in the Dashboard or API. Each key's access is limited to the resources of the creating user. All API keys are stored in a secure, encrypted database.
  • Cloud Resource Access: Access to GCP and AWS resources is managed through IAM users and roles. We grant access to instances via instance roles, and to developers and administrators via service accounts that require 2FA tokens.
  • Cluster Manager API: Access is controlled via a role-based access mechanism tied to the GCP or AWS SSO user.

Security Architecture

Data in Transit All data transmitted between customers and Hyperspace is encrypted using TLS. We currently use the TLSv1.2_2021 security policy for our HTTPS load balancers. For our website and Dashboard, Cloudflare distributions terminate TLS connections.

Within Hyperspace's Virtual Private Cloud (VPC), data is transmitted between our internal services. Importantly, data is never sent outside of the VPC. The only entry points to the VPC are through the Hyperspace API and a VPN for our operations staff.

Data at Rest Data is persisted in two places, both with encryption enabled:

Encryption keys are managed by GCP and AWS Key Management Services (KMS). The master keys are never exposed and never leave the KMS hardware. For specific commercial installations, we can offer a way for customers to provide their own master key. All customer API keys and integration credentials are also stored in a secure, encrypted database.

Confidentiality

Hyperspace maintains confidentiality by strictly controlling access to systems, services, and data. Access is granted on a need-to-know basis to authorized users, service accounts, and employees.

  • Secrets Management: Sensitive information required for services at runtime is stored as Kubernetes Secrets within our GCP environment. Access to these secrets is managed via Kubernetes roles, adhering to the principle of least privilege. Employee access to third-party services is secured using 1Password.
  • Data Encryption: User credentials are encrypted at rest using AES-256 within a dedicated database.

Audit Logging

We implement comprehensive audit logging to ensure accountability and monitor activity across our infrastructure.

All actions on our cloud infrastructure are logged using GCP Cloud Logging. For each cluster, including production, logs are securely transferred to a dedicated GCP Cloud Storage bucket located in a separate security account. This bucket is configured with write-only access, which prevents logs from being modified or deleted.

Defense in Depth

Hyperspace employs a defense-in-depth strategy to protect its assets through multiple, layered security controls.

  • Access Control: Access to all systems requires two-factor authentication (2FA). Elevated privileges, which are required for critical operations, are also protected by 2FA.
  • Network Segregation: Development and production environments are isolated through strict network segregation to prevent unauthorized access and limit the potential blast radius of any breach.
  • Least Privilege: The principle of least privilege is enforced for all employee accounts, limiting permissions to only what is necessary for their roles.
  • Intrusion Detection: An Intrusion Detection System (IDS) is used to continuously monitor all development and production environments, providing immediate alerts to the security team upon detection of anomalies.

Availability and Continuity

Uptime Hyperspace is deployed on public cloud infrastructure with services configured to scale dynamically based on demand. We perform regular load tests and API response time tests as part of our release cycle to ensure stable performance.

You can view our public status page for real-time system availability, scheduled maintenance, and incident history.

Disaster Recovery In the event of a major outage, we have a tested and reviewed Disaster Recovery (DR) plan that allows us to deploy our application to alternative hosting. Our DR deployment uses the same configuration management and release processes as our production environment, ensuring all security configurations and controls are applied consistently.

Application Security

Quality Assurance Our Quality Assurance team reviews and tests the codebase for each project. Our security team provides resources and recommendations to the QA team to investigate and remediate security vulnerabilities in the code.

Environment Segregation Our testing, staging, and production environments are logically separated. No customer data is ever used in a development or test environment.

Security Mindset Program Hyperspace runs a Security Mindset program with active participation from every development team.

Personnel Security

Security Awareness All new hires must complete a robust Security Awareness Training program within 30 days of employment. All employees receive annual training, with quarterly focused sessions on topics like secure coding and data privacy.

Information Security Program Hyperspace maintains a comprehensive set of information security policies, which are distributed to all employees and contractors.

Employee Background Checks All employees undergo a background check prior to employment, covering a 5-year criminal history (where legal) and a 5-year employment verification.

Confidentiality Agreements All employees are required to sign Non-Disclosure and Confidentiality agreements.

Access Controls Access to our systems and network devices is granted through a documented, approved request process. All logical access to our servers and management systems requires two-factor authentication. We use a least-privilege methodology and perform quarterly reviews to ensure all permissions are commensurate with an employee's job function. Access is revoked immediately upon termination or change of role.

Data Privacy

At Hyperspace, we are committed to protecting the privacy and personal data of all our users, no matter where you are located. We adhere to a global privacy standard based on the principles of transparency, data minimization, and user control.

For Our Customers in the United States

As a USA-based company, we are fully committed to complying with applicable state-level data privacy laws, with a particular focus on the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA).

For Our Customers in the European Union (EU), United Kingdom (UK), and Switzerland

Hyperspace maintains compliance with the European Union’s General Data Protection Regulation (GDPR), the UK GDPR, and the Swiss Federal Act on Data Protection (FADP).

For the transfer of personal data from the EEA, UK, and Switzerland to our US-based infrastructure, we rely on the following primary legal mechanisms:

Standard Contractual Clauses (SCCs)

For data transfers with customers or partners we rely on the European Commission's approved Standard Contractual Clauses (SCCs). We also use these clauses in our agreements with any third-party sub-processors we may use. In line with the requirements of the Schrems II ruling, we supplement these clauses with additional safeguards, including a Transfer Impact Assessment, to ensure that personal data remains protected with a level of security and privacy essentially equivalent to that of the GDPR.

PCI-DSS

Hyperspace, as a card-not-present merchant, outsources all cardholder functions to a PCI-DSS Level 1 service provider. A copy of our SAQ-A is available upon request.

Privacy Policy

For details on how Hyperspace handles data, please refer to our full privacy policy. You can find it at: hyperspace.mv/privacy

If you have any questions or concerns about your privacy, feel free to contact us directly at: privacy@hyperspace.mv.

Third-Party Security and Vendor Management

At Hyperspace, we recognize the risks that come with working with third-party vendors. We have a thorough process to ensure that all vendors meet our security standards before we partner with them. If a vendor doesn't meet our requirements, we won't move forward with them. We also continuously monitor and reassess the security of our selected vendors, adapting to any changes.

For our core infrastructure and services, we use a select group of third-party sub-processors. We apply the same strict security evaluation process to these sub-processors as outlined in our Vendor Management Policy.

The list of subprocessors, which is incorporated herein by reference and applies to both Customers and Participants (Experiences), is accessible at the following location: https://hyperspace.mv/academy/subprocessors/

Responsible Disclosure Policy

At Hyperspace, we value the role of the security research community in helping us maintain a secure system. If you believe you've found a vulnerability, we invite you to report it to us.

How to Report a Vulnerability

Please email your findings to security@hyperspace.mv. Your report should include:

  • Finding Name and Severity
  • Domain and URL
  • A detailed Proof-of-Concept to reproduce the issue
  • Evidence, such as screenshots or video

General Guidelines

  • All testing must be done within your own account.
  • We only accept solo submissions.
  • Do not access, modify, or delete other people's data. Only use accounts you own or have explicit permission to use.
  • Please allow us a reasonable amount of time to fix the issue before publicly disclosing it.
  • Public disclosure of vulnerabilities is not currently permitted.

Out-of-Scope Activities and Exclusions

Please refrain from the following activities:

  • Denial of Service (DoS/DDoS)
  • Spamming or Email Bombing/Flooding
  • Social Engineering or phishing of our employees
  • Physical attacks on our property
  • Using automated vulnerability scanners
  • Testing third-party SaaS applications
  • Username/Email enumeration
  • Clickjacking
  • Missing security headers (e.g., DMARC, SPF, etc.)
  • OAuth misconfigurations
  • Logout Cross-Site Request Forgery
  • EXIF and Geolocation data-related vulnerabilities

Rewards

While we don't offer cash rewards, we will gratefully list your name in our Bug Hunters Hall of Fame for valid submissions.

How useful was this article?

Click on a star to rate it!

We are sorry that this article was not useful for you!

Let us improve this article!

Tell us how we can improve this article?