Last updated October 2024

Introduction

Twingate helps customers to improve information security in their organizations by providing a better, simpler approach to securing access to their private network resources. However, to deliver on that promise, we’re cognizant that we must first ensure that our own security practices are in order.

This document contains information that is intended to provide customers and prospective customers with transparency on and confidence in Twingate’s security posture, practices, and processes. While this document represents Twingate’s security at the point in time it was last updated, ensuring information security is an ongoing process of continuous improvement, and it is something we never stop assessing and bolstering.

This document is divided into two sections:

• Information Security at Twingate Twingate’s general approach to information security.
• Product Security Our approach to securely architecting and delivering the Twingate product.

1. Information Security at Twingate

Customers entrust us with carriage of their most sensitive and confidential information, and therefore information security is core to our business and a constant priority that each one of us at Twingate takes seriously.

People Security

Responsibility & Governance

Twingate’s Chief Technology Officer has primary responsibility over Twingate’s information security program and practices. Twingate also maintains a cross-disciplinary security team that is responsible for implementing, reviewing, and maintaining its information security program and includes members of senior management. However, as a security company, Twingate views security as a pervasive issue and therefore a shared responsibility throughout our entire organization. For example, all of our engineers are required to consider security as a fundamental part of their work, and they do not simply delegate all responsibility to other colleagues who focus more on security.

Twingate maintains a suite of written information security plans, policies and procedures that are reviewed on at least an annual basis, and are supplemented by periodic risk reviews that feed into the continual development of our information security program.

Employee Background Checks

All incoming employees in the U.S. are subject to background checks conducted by a third party provider that specializes in background checks. Background checks include: SSN trace, criminal searches (including county searches, multi-state, and national sex offenders public registry) and OFAC/SDN checks.

Outside of the U.S., we conduct background checks on incoming employees in accordance with local practices and subject to local law.

Contractual Protections

All employees and independent contractors are required to sign contracts under which they agree to protect customer and other proprietary information as confidential information.

Offboarding Employees

We have documented processes that we follow to ensure that when an employee departs the company, their access is revoked in a timely manner and any company assets they possess are returned or destroyed (whichever is appropriate).

Workforce Security Training

All employees are required to undergo information security training during onboarding. Additionally, employees receive periodic security refresher training and updates about security best practices. Employees are required to review and acknowledge that they have reviewed the company’s information security policies and procedures, which include an acceptable use policy for IT resources.

Data Protection & Access Control

Data Access

We provision user access based on user roles and the principle of least privilege.

Access to private network resources in our production and other environments is secured using Twingate, with authentication performed by our identity provider’s single sign on system with multi-factor authentication enabled. Using Twingate also allows us to exercise granular control over user access rights at the resource level (rather than network level), in accordance with the principle of least privilege, and apply different security policies based on the authenticated identity of the user, device, and context in which access is being requested.

Internal corporate applications use SSO and MFA for authentication where possible, with minimum password complexity requirements enforced.

We also automate our production environment deployment processes which removes the need for manually making changes directly to the production environment. This enables Twingate to avoid granting access rights to human users. Developers do not have direct access to databases containing customer data. Developers generally do not have or require SSH access into production environment servers (including via SSH).

Access Monitoring

We use Twingate and other logging systems to monitor access to various systems and aspects of Twingate infrastructure.

Data Encryption

Customer data is encrypted both in transit and at rest using industry standard encryption protocols and algorithms.

In transit, client app communications are secured over TLS/SSL connections.

At rest, customer data is stored in a Google Cloud Platform managed database encrypted using AES-256 or better, with symmetric keys. The data keys are themselves encrypted using a master key stored in a secure keystore and changed regularly.

We do not use any custom or proprietary cryptographic frameworks or implementations. Note that Twingate does not store any customer passwords.

When it comes to deciding which ciphers to support, Twingate follows NIST recommendations as stipulated in NIST SP 800-52 Rev. 2.

Data Backups

Automated, daily backups are made of our customer database. Backups are stored for a limited period for disaster recovery purposes and are regularly tested.

Data Deletion

Customer data is permanently and securely deleted upon request and in accordance with any contractual commitments made to customers.

Vendor Management

Vendor Security

We work with vendors and service providers who help us to provide our services to customers, such as email service providers, payment processors, and infrastructure providers. Some of these vendors have the ability to access or store customer data, and we adopt a variety of measures to ensure that they only do this in an appropriate and secure manner. First, we select vendors based on our experiences working with them, their reputation, and an evaluation of how well they meet our business requirements. Second, we perform due diligence on potential vendors, which includes a risk assessment of their security posture. Third, when we engage a new vendor, we ensure that we have a written contract with them that includes appropriate provisions with respect to confidentiality, security, privacy, and service levels, where relevant. In general, vendors are only permitted to use data provided to them (including our customers’ data) for the purpose of providing their services to Twingate.

Infrastructure Security

Device Security

All end user laptop and desktop computers are required to have anti-virus/anti-malware software installed and full disk encryption enabled. We use mobile device management (MDM) software to monitor our device fleet, enforce security settings, and push software updates. All IT assets issued by the company to employees are inventoried and tracked.

Infrastructure Change Management

Each proposed change to our production environment (including infrastructure changes) must be approved, and each such change and corresponding approval are logged. Our CI/CD pipeline provisions infrastructure changes in an automated manner after they are approved.

Secrets Management

We use a commercially available secrets management system provided by a major vendor to store secrets such as authentication tokens, passwords, API credentials and certificates.

Server Hardening

We use Google Cloud Platform to provide pre-hardened server infrastructure. We interact with servers predominantly by deploying Docker containers orchestrated with Kubernetes.

Infrastructure Redundancy

Twingate’s infrastructure is hosted in multiple, physically separated Google Cloud Platform (GCP) data centers for redundancy in case of technical fault or natural disaster and for load balancing. GCP also provides protective measures against DDOS attacks. We use a variety of automated tools to monitor our services 24/7 and alert us of any service availability issues. Customers can monitor service status and scheduled maintenance periods at status.twingate.com.

Disaster Recovery & Business Continuity Planning

Twingate has a written DRP/BCP. Our goal is to ensure that customers always have access to our services whenever they are needed.

Physical Security

Twingate has a globally distributed workforce and currently does not have any fixed offices. Twingate employees are instructed and trained to ensure that their physical working environment is kept secure (whether it is a home, airport, cafe, or other remote location), and that any work equipment is secured appropriately, including when not in use.

Twingate uses Google Cloud Platform data centers which are physically secured by Google.

SOC 2 Report

Twingate undergoes annual SOC 2 audits and has a SOC 2 Type 2 report. Reach out to your Twingate contact to request a copy.

2. Product Security

Our approach to securely architecting and delivering the Twingate product.

Application Security & Product Development Security

Customer Data Overview

The main types of customer data that Twingate handles are user details (such as email addresses, names, and group membership, but not passwords, since Twingate delegates authentication to third party identity providers), and infrastructure information (such as network details, resource details, and access control lists). Twingate components also log certain events that allow customers to monitor user activity (e.g. user logins and token requests), and collect crash and error reports for diagnostic and troubleshooting purposes.

Software Development Practices

All software code written undergoes a code review by a second person. Changes to production code require at least one person (other than the code creator) to approve and merge such changes via a pull request (PR) mechanism. More than one reviewer may be required depending on the nature of the code change. Additionally, Twingate performs internal and third party security testing, as described in the sections below.

Customer data is not used for testing.

We generally notify customers of major updates to downloadable software components. Minor updates, such as user interface tweaks, are regularly released without express notification. We recommend customers upgrade to the latest stable versions of Twingate software when they are made available.

Security is an integral part of the software development process and is considered at the design phase through to the testing of production code.

Internal Security Testing

Twingate uses a variety of tools to perform static analysis of code and report issues - both with our proprietary code, as well as vulnerabilities in third party libraries. Vulnerabilities detected are patched as promptly as practicable.

Third Party Security Testing

Twingate works with Hacker House, a reputable third party security specialist company to perform regular security testing on its applications. Hacker House’s testing activities extend beyond penetration testing to application security assurance and product analysis, including:

• analyzing Twingate on a component-by-component basis in a “white box” environment;
• subjecting each component to reverse engineering, run time, and static analysis to ensure engineering is performed in accordance with best practice security guidelines;
• performing automated stress testing (“fuzzing”), manual vulnerability discovery, and both run-time and source code reviews; and
• conducting threat modeling.

Penetration Testing Requests

We permit customers to conduct penetration testing on our systems in certain circumstances. Customers must have prior approval from, and give advance notice to, our security team about the timing and scope of a penetration test and may be required to sign an agreement that covers such testing activities. Contact your account manager for more information.

Domain Claiming

Twingate customers may register accounts tied to a twingate.com subdomain specified by them. Under Twingate’s Customer Agreement, discretion over subdomain allocation ultimately rests with Twingate and Twingate is empowered to take action to remedy incidents of trademark infringement, spoofing, or other undesirable activity relating to customers improperly claiming subdomain names.

Product Architecture

When we designed Twingate, we wanted to build a solution that was foundationally secure given how people work and access information resources today. We therefore started from the premise of assuming that an attacker was already “inside” a network.

As such, Twingate was architected on the principles that:

• Every request to a network resource should be authenticated, verified and authorized
• Users should only be able to access what they are explicitly granted access to
• Logging should be performed to facilitate monitoring and investigations

At a high level, these principles manifest themselves in the following ways:

• No single Twingate component can independently make a decision to allow traffic to flow to a secured resource on your remote network. User and data flow authorization is always confirmed with multiple components running multiple checks. Moreover, user data flows and user authentication flows are handled by separate components and require separate validation checks.

• We delegate user authentication to a third party identity provider (IdP), which creates a separation of concerns that provides an additional layer of security.

• We support extensive logging, providing enhanced visibility that helps administrators to monitor, troubleshoot and investigate activity throughout their networks and endpoints.

• User data flows are encrypted end-to-end, and even though they may pass through relays (components on Twingate-controlled infrastructure), Twingate has no ability to decrypt such data.

• Our client applications are designed to be always on in the background.

From the customer’s perspective, our product architecture provides additional security benefits as it relates to:

• not needing to publicly expose a public gateway to the world, meaning that customer networks remain invisible to the public internet (as well as hiding the fact that a customer is using Twingate)

• restricting user access to specific resources, rather than entire networks

• centrally managing access to all private resources, which helps IT team to audit and maintain access lists

• usability for both administrators and end users. Usability promotes security. From an administrative perspective, solutions that are easier to configure and maintain are less error prone and more effective. From an end user perspective, an easy-to-deploy solution that “just works” and stays out the user’s way when operating, promotes adoption

• reliability (scalability and availability)