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. 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.
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. The first describes Twingate’s approach to information security generally, and the second describes our approach to securely architecting and delivering the Twingate product.
Responsibility & Governance
Twingate’s Chief Technology Officer has primary responsibility over Twingate’s information security program and practices. However, as a security company, Twingate views security as a pervasive issue and therefore a shared responsibility throughout our team. 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.
Employee Background Checks
All candidates in the U.S. to whom we extend offers of employment must pass background checks conducted by a third party specialized background checking company. 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 if local laws permit them.
All employees and independent contractors are required to sign contracts under which they agree to protect customer and other proprietary information as confidential information.
We have documented processes that we follow to ensure that when an employee departs the company, their access is timely revoked 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.
We provision user access based on user roles and the principle of least privilege. We also automate our production environment deployment processes, meaning that users have no rights to manually or directly make changes to production. Developers do not have direct access to databases containing customer data. Developers generally do not have or require SSH access into production environment servers.
Access to private network resources in our production and other environments is secured using Twingate, with authentication performed by a 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.
Internal corporate applications use SSO and MFA for authentication where possible, with minimum password complexity requirements enforced.
Customer data is encrypted both in transit and at rest using industry standard encryption protocols.
In transit, client app communications are secured over TLS/SSL (HTTPS) 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.
Automated, daily backups are made of customer data. Backups are stored for a limited period.
Customer data is permanently and securely deleted upon request and in accordance with any contractual commitments made to customers.
We use vendors who help us to provide our services. 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, when we consider new vendors, we perform due diligence on their security practices and reputation. Secondly, when we engage a new vendor, we include contractual obligations with respect to confidentiality, security and privacy, where relevant. Examples of security obligations we may contractually require include specifying minimum security safeguards, notification of data security incidents, and audit rights.
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.
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.
We use Google Cloud Platform to provide pre-hardened server infrastructure. We interact with servers predominantly by deploying Docker containers orchestrated with Kubernetes.
Our production network is segmented into different zones based on security levels. Each environment has its own subnet and internal communications are only allowed based on a predefined whitelist-based network policy.
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.
Twingate uses Google Cloud Platform data centers which are physically secured by Google.
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. Additionally, Twingate performs internal and third party security testing, as described in the sections below.
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.
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.
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: (1) every request to a network resource should be authenticated, verified and authorized, (2) users should only be able to access what they are explicitly granted access to, and (3) 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)
Updated a day ago