Recommended network policies
We recommend you add the following network policies to build an Internet and SaaS app security strategy for your organization.
For more information on building network policies, refer to Network policies.
Quarantined-Users-NET-Restricted-Access
Restrict access for users included in an identity provider (IdP) user group for risky users. This policy ensures your security team can restrict traffic for users of whom malicious or suspicious activity was detected.
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | not in list | Quarantined-Users-IPAllowlist | Or | Block |
SNI | not in list | Quarantined-Users-HostAllowlist | Or | |
Domain SNI | not in list | Quarantined-Users-DomainAllowlist | And | |
User Group Names | in | Quarantined Users |
Posture-Fail-NET-Restricted-Access
Restrict access for devices where baseline posture checks have not passed. If posture checks are integrated with service providers such as Crowdstrike or Intune via the API, this policy dynamically blocks access for devices that do not meet predetermined security requirements.
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | not in list | Posture-Fail-IPAllowlist | Or | Block |
SNI | not in list | Posture-Fail-HostAllowlist | Or | |
Domain SNI | not in list | Posture-Fail-DomainAllowlist | And | |
Passed Device Posture Checks | not in | Windows 10 or higher (OS version) |
You can add a number of WARP client device posture checks as needed, such as Disk encryption and Domain joined. For more information on device posture checks, refer to Enforce device posture.
FinanceUsers-NET-HTTPS-FinanceServers (example)
Allow HTTPS access for user groups. For example, the following policy gives finance users access to any known financial applications:
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | in list | Finance Servers | And | Allow |
User Group Names | in | Finance Users |
All-NET-Internet-Blocklist
Block traffic to destination IPs, SNIs, and domain SNIs that are malicious or pose a threat to your organization.
You can implement this policy by either creating custom blocklists or by using blocklists provided by threat intelligence partners or regional Computer Emergency and Response Teams (CERTs). Ideally, your CERTs can update the blocklist with an API automation to provide real-time threat protection.
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | in list | IP Blocklist | Or | Block |
SNI | in list | Host Blocklist | Or | |
Domain SNI | in list | Domain Blocklist |
All-NET-SSH-Internet-Allowlist
Allow SSH traffic to specific endpoints on the Internet for specific users. You can create a similar policy for other non-web endpoints that required access.
Optionally, you can include a selector to filter by source IP or IdP group.
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | in list | SSHAllowList | Or | Allow |
SNI | in list | SSHAllowlistFQDN | And | |
Detected Protocol | is | SSH | And | |
User Group Names | in | SSH-Allowed-Users |
All-NET-NO-HTTP-HTTPS-Internet-Deny
Block all non-web traffic towards the Internet. By using the Detected Protocol selector, you will ensure alternative ports for HTTP and HTTPS are allowed.
Selector | Operator | Value | Logic | Action |
---|---|---|---|---|
Destination IP | not in list | InternalNetwork | And | Block |
Detected Protocol | not in | HTTP, HTTP2 |
All-NET-InternalNetwork-ImplicitDeny
Implicitly deny all of your internal IP ranges included in a list. We recommend you place this policy at the bottom of your policy list to ensure you explicitly approve traffic defined in the above policies.
Selector | Operator | Value | Action |
---|---|---|---|
Destination IP | in list | Internal Network IPs | Block |