Policy Types

Twingate has two types of Security Policies, both of which are used for different purposes. Different policy types may have different rules available to them, based on what is appropriate for the use case.

• Resource Policies: These Policies are applied to Resources at the time they are accessed by a user. Use these Policies to apply extra security to more sensitive Resources on your Network. There is always one Default Policy which is applied to all new Resources by default. You can create additional Resource Policies in the Admin Console.
• Minimum Authentication Requirements: This policy is applied to all users of Twingate when they attempt to log into the network. Users must fulfill the policy’s criteria before attempting to access any Resources, even if those Resources have more permissive Security Policies. In addition to the Minimum Authentication Requirements, a user’s device must meet either the minimum OS requirements or a Trusted Profile as specified in the Device Security Guide.

There’s an additional Admin Console Security Policy that can be configured. This is managed under the Settings tab. This policy is only applied to Twingate administrators when they attempt to sign into the Admin Console. Admins do not need to sign into Twingate to access the Admin Console, so the minimum authentication requirements are not applied here. See Admin Console Security for more information.

Rule Types

The following rule types may be applied to Policies:

Policy Management

You can create a new Resource Policy by clicking the “Create Policy” button under Resource Policies.

You can edit new or existing Security Policies by selecting the relevant policy in the Policies tab. Here you can add new requirements and edit or remove existing requirements. Authentication Requirements specify the authentication needed for this policy specifically, and layers on top of broader Minimum Authentication Requirements. Device Security identifies which types of devices (all, Trusted Devices, or custom) will meet this policy. For more information, see Device Security Guide.

Security Policies are applied to Resources, and Groups are assigned access to Resources. If a user is in a Group with access to a Resource, they will need to fulfill any requirements of the Security Policy for that Resource. By default, all Resources will use the Default Policy; you can change this by editing the Resource.

The Resource Policy assigned to the Resource can be overriden with a different policy for specific Groups with access to the Resource. For example, in the screenshot above, the Resource Policy is the Default Policy. For any Groups that are given access to this staging environment, they will automatically have the Default Policy applied. However, for the Contractor and Normal groups, different Policies are required. This means that users within the Contractor group will need to meet the Contractor Policy in order to access the staging environment, and users within the Normal group will need to meet the Secure Policy in order to access the staging environment.

The policy for a specific Group can be modified via the Resource page.

Once a policy has been changed for a specific Group, the policy will be considered overridden. Even if the Resource Policy changes, the policy for that specific Group will not be changed. In the example above, if the staging environment’s Resource Policy is changed from Default Policy to Secure Policy, the Contractor Group will still continue to use the Contractor Policy. In order to have the Contractor Group return to inheriting the Resource Policy, the override can be removed by resetting it for that Group.

Recommendations

Twingate recommends that you apply comparatively less strict Policies to the Minimum Authentication Requirements and focus more security controls on Resource Policies, especially those that are applied to more sensitive Resources. This will reduce the number of authentication or other security controls that users must go through, focusing them only on the times when they are actually accessing a protected Resource.