Best Practices for Security Policies

Let's review the types of Policies available, what they mean, and the scope they cover.

Twingate allows administrators to define granular Security Policies to control access to Resources and the Admin Console.

Types of Security Policies

TypeDescriptionScopeComponent
Admin Console Security PolicyGates access to the Twingate Admin ConsoleTwingate Users with access to the Admin ConsoleAdmin Console only
Minimum Authentication RequirementsGates access to the Twingate environment, does not grant access to ResourcesAll users connecting to the Twingate environmentClient
Resource PolicyGates access to ResourcesUsers when accessing ResourcesClient

Admin Console Security Policy

This policy is set under the Settings page of the Admin Console and only applies to Twingate users with either Admin, DevOps or Support role assigned. It is only enforced when accessing the Admin Console. Our recommended best practice for configuring this policy is the following:

Minimum Authentication Requirements

This policy is visible under the Policies tab in the Admin Console. It applies to all Twingate users regardless of what Group(s) they belong to. It is enforced when any Twingate user connects to their Twingate Client.

It is important to note that the Minimum Authentication Requirements do not grant access to any Resource unless it is behind a Resource Policy for which the Authentication Requirements have been disabled. Our recommended best practice for configuring  this policy is the following:

Defining Policies

A Resource Policy is, as its name suggests, assigned to a Resource and applies to all users who are permitted to access the Resource. It is enforced when a Twingate user is connected to their Twingate Client and attempts to access a Twingate Resource.

Resource Policies
Resource Policies

A Resource Policy is designed to answer four questions:

  • Does the user need to authenticate to gain access to a Resource?
  • What attributes does the device attempting to connect to a Resource need to possess? (For instance, should the device be trusted in advance?)
  • Does a user need to provide multi-factor authentication to gain access to a Resource?
  • How often does a user need to re-authenticate after they access a Resource?

Designing Resource Policies

Cataloging Resources

Let’s first look at the types of public and private Resources you want to protect behind Twingate in conjunction with how you measure risk for your business.

The definition of risk for assets is usually measured against several dimensions, but the dimensions you consider and their relative impact will on your own business constraints and priorities. As an example, some of our customers have chosen to factor in the following dimensions when thinking of risk:

  • the data types handled by a given asset (for example, PII vs. non PII, confidential intellectual property, etc.)
  • the data volume (how much data can be reviewed when accessing the asset, for instance 1 record at a time via a UI vs. full database access)
  • the business impact of data modifications (for example a change to Terraform code for production can potentially have more impact than a change in a SIEM configuration)
  • the method of access (UI, CLI, RDP, ssh, etc.)

A common approach is to quantify these risks along a numerical scale and create a risk score for each asset. Once you have performed this risk assessment, think of mapping risk scores to specific policy definitions. In our example, we will use the following simple logic:

High Risk: Users must re-authenticate once every 2 hours, must be required to provide MFA and musty access the Resource from a verified device.

Medium risk: Users must re-authenticate once a day, must be required to provide MFA and must access the resource from a verified device.

Low risk: Users must re-authenticate once a week, must be required to provide MFA and musty access the resource from a verified device.

Very Low risk: Users must re-authenticate once a week, do not need to provide MFA and must access the resource from a verified device.

AssetGroups with AccessRisk Score (based on business specific factors)Re-authentication FrequencyMFADevice Verification
Fileshare serverFinanceMediumonce a dayYesAlways required
Source Code repositoryEngineeringHighevery 2 hoursYesAlways required
Non-production infrastructureEngineering, ITMediumonce a dayYesAlways required
Production infrastructureITHighevery 2 hoursYesAlways required
Internal Support systemITMediumonce a dayYesAlways required
POS systemRetail, Contractors 1Very Lowonce a weekNoAlways required
Synthetic data repoEngineering, Contractors 2Lowonce a weekYesAlways required
Active Directory / Domain Controllers (Admin)ITHighevery 2 hoursYesAlways required
Identity Provider (Admin)ITHighevery 2 hoursYesAlways required
Identity Provider (non-admin)*EveryoneVery LowNo AuthNoAlways required
Active Directory / Domain Controllers (non-admin)*EveryoneVery LowNo authNoAlways required

Device Verification

A device is considered verified if it has passed an automated EDR or MDM integration (such as CrowdStrike, SentinelOne, Kandji, Jamf, etc.) or was manually marked as verified in the Twingate Admin Console.

Device verification often depends on what type of workers make up the workforce of an organization. For instance, it is common to roll out an EDR/MDM to all employee devices but much less common to do the same on the devices used by contractors.

Device Groups
Device Groups

Let’s take the time to look at some examples of the types of devices our users typically use to connect to Resources, including what constraints we can and want to put on those:

GroupDevice OS allowedDevice Verification
FinanceCompany approved macOS or Windowsvia CrowdStrike
EngineeringCompany approved macOS or Windowsvia CrowdStrike
RetailCompany approved Windowsvia SentinelOne
ITCompany approved macOS or Windowsvia CrowdStrike
Contractors 1BYOD WindowsTwingate verification via Serial Number (No EDR available)
Contractors 2BYOD macOSNone, device verification not required (Assets protected through authentication and MFA)

Now that we have a mapping of which Groups can be required to fulfill device verification and MFA, let’s tie it back to our list of assets, factoring in any exceptions:

AssetGroups with AccessDevice VerificationExceptions to device verification requirements for specific Groups
Fileshare serverFinanceRequiredNone
Source Code repositoryEngineeringRequiredNone
Non-prod infrastructureEngineering, ITRequiredNone
Prod infrastructureITRequiredNone
Internal Support systemITRequiredNone
POSRetail, Contractors 1RequiredNone
Synthetic data repoEngineering, Contractors 2RequiredContractors 2 (device verification not available for this Group)
Active Directory / Domain Controllers (Admin)ITRequiredNone
Identity Provider (Admin)ITRequiredNone
Identity Provider (non-admin)EveryoneRequiredNone
Active Directory / Domain Controllers (non-admin)EveryoneRequiredNone

Configuring Trusted Profiles & Minimum OS Requirements

Devices that do not require verification

Almost all users need to be on company devices that are verified via either CrowdStrike or SentinelOne. However, for “Contractors 2”, verification via EDR/MDM or via Twingate itself are not an option. Because we only want to do native posture checks for these users, we will need to allow a path for macOS devices without verification to connect. As this is only true for macOS, we can block the other operating systems:

Minimum OS Requirements - Nothing Required
Minimum OS Requirements - Nothing Required

A valid refinement at this point is to ask whether it is still reasonable for us to require “Contractors 2” for certain device posture checks. We could, for instance, require Screen Lock and Biometric Configuration for macOS users:

Minimum OS Requirements - macOS Requirements
Minimum OS Requirements - macOS Requirements

Devices that require verification

There are 3 “device verification providers” in our context: CrowdStrike, SentinelOne and Twingate itself (for “Contractors 1”).

Let’s start by configuring CrowdStrike and SentinelOne in the Admin Console under Device Integrations.

Once done, here is what we will need to create under “Trusted Profiles”:

  • a Trusted Profile for macOS requiring CrowdStrike
  • a Trusted Profile for Windows requiring CrowdStrike
  • a Trusted Profile for Windows requiring SentinelOne
  • a Trusted Profile for Windows requiring manual verification
Trusted Profiles
Trusted Profiles

Device Trust

Device Trust goes a bit beyond device verification (covered above): a device is considered trusted if it meets the requirements of a Trusted Profile which is made up of one or more verification methods (automated EDR/MDM integration or manual verification) as well as additional posture checks.

Now that we have our two Trusted Profiles, we should determine if additional posture checks should also be added to those. For instance, on Windows, we could require none, several or all of the following:

  • HD Encryption
  • Screen Lock
  • Firewall
  • Antivirus

If we want to enforce all four, we should simply select them within the Trusted Profile for Windows:

Device Posture Checks
Device Posture Checks

Creating Policies

Let’s now map Resource Policies to assets based on the information gathered so far. Let’s use a meaningful naming convention for our policy names to make things more readable once we have all the policies in place:

<Re-auth>-<MFA requirements>-<device verification requirements>

Re-auth: (D = day, H = hour)

MFA requirements: (MFA = MFA is required, NoMFA = MFA is not required)

Device verification requirements: (Verif = device verification is required, NoVerif = device verification is not required)

Let’s also consider existing exceptions and potential additional exceptions based on application permissions:

For instance, we cannot verify devices from the “Contractors 2” group (existing exception).

Additionally, and after further review, IT staff should be required to provide MFA and re-authenticate more often to the POS system (because they have greater access to it than members of the “Retail” group) (additional exception).

AssetPrimary PolicyGroups with AccessPolicy Exceptions
Fileshare server1D-MFA-VerifFinanceNone
Source Code repository2H-MFA-VerifEngineeringNone
Non-production infrastructure1D-MFA-VerifEngineering, ITNone
Production infrastructure2H-MFA-VerifITNone
Internal Support system1D-MFA-VerifITNone
POS1W-NoMFA-VerifRetail, Contractors 1, IT“IT” required to provide MFA and re-authenticate every 1 day.
Synthetic data repo1W-MFA-VerifEngineering, Contractors 2“Contractors 2” cannot be required to provide device verification
Active Directory / Domain Controllers (Admin)2H-MFA-VerifITNone
Identity Provider (Admin)2H-MFA-VerifITNone
Identity Provider (non-admin)1D-NoMFA-NoneEveryoneNone
Active Directory / Domain Controllers (non-admin)1D-NoMFA-VerifEveryoneNone

Removing the assets and primary policy duplicates, it boils down to just the following 6 policies:

1D-MFA-Verif
2H-MFA-Verif
1W-NoMFA-Verif
1W-MFA-Verif
1D-NoMFA-Verif
1D-NoMFA-None

Now, looking at all exceptions, let’s see what additional policies we will need:

For “IT” access to “POS”, we will need the following policy: 1D-MFA-Verif. Fortunately, this policy will already be created as part of our primary policies listed above.

For “Contractors 2” access to the “synthetic data repo”, we will need a new policy that does not exist in the list of primary policies: 1D-MFA-None.

Great! Let’s now create all of our defined policies in Twingate based on the following definitions:

Policy NameAuthenticate everyMFADevice Security
1D-MFA-Verif1 dayMFA requiredOnly Trusted Devices
2H-MFA-Verif2 hoursMFA requiredOnly Trusted Devices
7D-NoMFA-Verif7 daysMFA not requiredOnly Trusted Devices
7D-MFA-Verif7 daysMFA requiredOnly Trusted Devices
1D-NoMFA-Verif1 dayMFA not requiredOnly Trusted Devices
1D-NoMFA-None1 dayMFA not requiredAny Device
1D-MFA-None1 dayMFA requiredAny Device

Putting it all together

We should now have a complete mapping of:

  • Resource assignments to Groups
  • Primary policy for each Resource
  • Override Policies (per Group) for each Resource
Asset / ResourcePrimary PolicyGroups Primary PolicyGroup based policy Exceptions
Fileshare server1D-MFA-VerifFinanceNone
Source Code repository2H-MFA-VerifEngineeringNone
Non-production infrastructure1D-MFA-VerifEngineering, ITNone
Production infrastructure2H-MFA-VerifITNone
Internal Support system1D-MFA-VerifITNone
POS1W-NoMFA-VerifRetail, Contractors 1, IT“IT”:1D-MFA-Verif
Synthetic data repo1W-MFA-VerifEngineering, Contractors 2“Contractors 2”:1D-MFA-None
Active Directory / Domain Controllers (non-admin)1D-NoMFA-VerifEveryoneNone
Active Directory / Domain Controllers (Admin)2H-MFA-VerifITNone
Identity Provider (non-admin)1D-NoMFA-NoneEveryoneNone
Identity Provider (Admin)2H-MFA-VerifITNone

We can now configure all Resources, Policies and overrides in Twingate!

The “Everyone” Group

The “Everyone” Group is the only Group in Twingate that exists by default and cannot be deleted. It contains all Twingate users. Our recommended best practices regarding the Everything Group are the following:

Resource assignment for the “Everyone” Group

  • add a Resource for your IdP (ex: .okta.com)
  • [Windows environments only] add Resources for your Active Directory & Domain Controllers (see our Active Directory guide)

Resource Policy for the “Everyone” Group

  • Does not require authentication (this is important if you actively use Domain Controllers as it will allow the Twingate Client to access your Domain Controllers before user logon)
  • Requires device trust (either native or via EDR/MDM)

Last updated 3 months ago