Creating policies

Following are the types of policies you can create in Protect:

Anti-Malware policy

Anti-malware policies use the Microsoft Anti-malware engine to protect your endpoints from viruses.

AppLocker policy

AppLocker policies provide access control by using application whitelisting. Use AppLocker policies to prevent unwanted executables from running on your endpoints (Deny rules) or to only allow certain applications to run on endpoints (Allow rules).

Windows device control

Use Windows device control policies to administer devices on Windows endpoints by denying specific permissions to categories of removable devices or restricting the installation of new devices.

Enhanced Mitigation Experience Toolkit (EMET) policy

Policies created via Microsoft EMET add protection against common memory corruption attacks. These mitigations might be system-wide and/or application-specific. EMET rules can also protect against “man in the middle” attacks on websites that use Transport Layer Security (TLS).

Firewall management policy

Firewall management policies consist of rules that block or allow network traffic using the built-in Windows Firewall.

Software Restriction Policy (SRP)

SRPs consist of rules that block the execution of applications and are created using Windows SRP component.

Remediation Policy

A remediation policy is a list of tasks that run sequentially on the endpoint(s).

See Using best practices with policies and rules for more details on successfully creating policies and rules in Protect.

A Protect policy can contain only one policy type.

Create an Anti-malware policy

Anti-malware policies consist of groups of settings. You can only have one Anti-malware rule per policy; however, a single Anti-malware rule within one policy can have multiple settings.

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select Anti-Malware from the Policy Type drop-down menu.
  3. Click Change settings for SCEP Installation depending on if you already have Microsoft System Center Endpoint Protection (SCEP) installed on your endpoints or if you want Tanium to automatically install SCEP when enforcing Anti-malware policies.
  4. Anti-malware policies require that endpoints have either SCEP or Windows Defender installed. When SCEP Installation is enabled, enforcing an Anti-malware policy automatically installs SCEP on endpoints that do not support Windows Defender. See Enable Microsoft System Center Endpoint Protection (SCEP) Installation to understand how to correctly enable SCEP installation.

  5. Determine if you should keep Deploy definition update using Tanium for Managed Definitions enabled.


  6. By default, Anti-malware rules are configured to use Tanium to deploy Anti-malware definition updates. If an endpoint has not received an update within the specified grace period, it is considered unenforced. When this option is unchecked, endpoints retrieve definitions directly from Microsoft.

  7. Complete the fields for Definition Grace Period to specify how often endpoints use Tanium to check for Anti-malware definition updates. This value represents how old an Anti-malware definition can be before the policy is considered unenforced. The default grace period is 1 day.
  8. Under Settings, click + Add Setting Group and select a setting group. See Reference: Anti-malware settings for definitions of Anti-malware settings.
  9. Click + Add setting to add another setting to that setting group.
  10. Click + Add Setting Group to add another setting group.
  11. Click Create to create your policy with this rule.
  12. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Create an AppLocker policy

For successful AppLocker rule enforcement, Protect starts the Application Identity service.

Protect allows you to select Whitelist or Blacklist templates for default Allow rules. You can also create a Custom template and define custom default Allow and/or Deny rules.

You can choose a Rule Template and define default Allow and Deny rules in Default AppLocker Executable Rules by clicking settings at the top right of the Protect Home page or by clicking Set Defaults for AppLocker > Set AppLocker rules within Settings in the Configure Protect section of the Home page.

The Blacklist Rule Template has the default All files Allow rule, which allows all executables to be run. You can then specify Deny rules to block specific applications.

The Whitelist Rule Template, by default, allows only applications that administrators run, or that are run out of special folders specified as follows:

  • All files located in the Program Files folder: applies to Everyone
  • All files located in the Windows folder: applies to Everyone
  • All files: applies to Administrators

You can expand the allowed applications by adding additional Allow rules or Deny rules to specify exceptions to otherwise allowed applications.





If you choose to enforce the default Protect Whitelist Rule Template, you might block applications unintentionally. The Protect Whitelist Rule Template blocks applications without explicitly listing the applications. For example, a program being run by a user out of that user’s profile directory is blocked. For best results, deploy whitelist policies initially in Audit Only mode until audit reports can be reviewed and the desired results are confirmed. See Using best practices with policies and rules: AppLocker policies for an example workflow.

The Blacklist Rule Template is the default template used in Protect for new deployments until you change it.

The Custom Rule Template does not contain any default Allow or Deny rules.

To go back to the original default settings, click Restore to Default.

Create a new AppLocker policy

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select AppLocker from the Policy Type drop-down menu.
  3. Select Audit Only or Blocking for Mode.
  4. Click + Add another next to Deny to create a Deny rule that prevents applications from running on endpoints or scroll down past the default Allow rules and click + Add another to create an Allow rule that allows certain applications to run.
  5. Deny AppLocker rules take precedence over Allow AppLocker rules.

  6. Provide a Name for the AppLocker rule.
  7. Select Path, Hash, or Publisher from the Rule type drop-down list.
    1. For Path, provide the full name or path in the Path field.
    2. For Hash Rule Type, provide the Hash and File Size (bytes). You can add multiple hashes.
    3. For Publisher, provide the Publisher, Product Name, File Name, and File Version, indicating if you want earlier or later versions included or only the version you specify. Use the * character as a wildcard in any of these values.
  8. Select Everyone or Administrators in the Windows user drop-down list.
  9. Click + Add exception to add and configure exceptions to a Path or Publisher rule type. With rule exceptions, you can specify files or folders to exclude from an AppLocker rule.

  10. Either click Create to create your policy with the rule you have configured or click + Add another to continue adding rules.
  11. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Be aware of AppLocker Allow or Deny rules set in your Domain Policy – these rules might take precedence over AppLocker rules created in Protect.

Import an AppLocker rule

Protect allows you to import AppLocker rules using the XML files you generate in the AppLocker section of Windows Local Security Policy Tool. This way you can quickly add multiple rules to a policy.

  1. Select Create from the New Policy drop-down menu on the Policies page to create a new policy with imported AppLocker rules or select a policy from the Policies page and click Edit to import AppLocker rules into an existing policy.
  2. In the Policy Details section, enter a Name and Description for the policy. Select AppLocker from the Policy Type drop-down menu.
  3. Select Audit Only or Blocking for Mode.
  4. Click Choose File under Import Rules From XML:.
  5. Select the XML file that contains the exported AppLocker rule and click Open.
  6. The Import Pending Review window shows three tabs including the new rules added to the policy from the imported XML file, the rules Protect cannot import, and duplicate rules.
  7. Click Proceed to import the XML file.
  8. Click Save if you are creating a new policy
  9. Click Enforce Changes (if enforcements exist) or Update (if there are no enforcements in place) to add the imported rules to a policy you are editing.

Create a Windows device control policy

Windows device control policies provide two modes for administering devices on Windows endpoints.

Removable Storage

Controls access permissions on removable media. The types of removable media predefined by Microsoft are CD-ROM and DVD drives, floppy disk drives, removable disk drives, tape drives, and Windows Portable Devices (WPD).

With this mode, you can deny specific permissions to categories of removable devices. On the endpoint, the permissions are managed using local group policy settings located in Administrative Templates > System > Removable Storage Access.






All Devices

Restricts the installation of new devices. This advanced mode provides more granular control by using a whitelist-based approach.

With this mode, the installation of any new device is blocked unless the device is explicitly allowed by either the device class or the hardware ID of the device. Optional settings allow administrators to bypass all restrictions and to uninstall existing USB storage devices that are not on the allowed list of devices. On the endpoint, the permissions are managed using local group policy settings located in Administrative Templates > System > Device Installation > Device Installation Restrictions.











Create a Windows device control policy to administer removable storage

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section:
    1. Enter a Name and Description for the policy.
    2. Select Device Control - Windows from the Policy Type drop-down menu.
    3. For the Management Method, select Removable Storage.
  3. In the Deny Removable Storage Access section, select the type of removable storage that you want to administer and the access that you want to deny for that storage type.
  4. Click Create to create your policy.
  5. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Create a Windows device control policy to administer all devices

This mode blocks new installations of all devices by default. This mode includes an optional setting to uninstall existing USB storage devices that are not on the policy whitelist. All other existing devices remain installed and will not be blocked, including devices that are not currently connected but were installed previously. You must add devices to the policy whitelist to allow installation to endpoints. Carefully test configurations and their impacts before you deploy them widely.

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section:
    1. Enter a Name and Description for the policy.
    2. Select Device Control - Windows from the Policy Type drop-down menu.
    3. For the Management Method, select All Devices.
  3. Configure the Device Control settings for your policy:
    1. Optional. In the Deny section, select Provide a notification message for users when a device is denied access and specify a message to display when a user attempts to install a restricted device.
    2. In the Allow section, configure the following settings:

      General Device Rules

      • Select the Allow Administrators to bypass all restrictions option to enable end-users to bypass the restrictions if they are logged in as an administrator.

        Devices do not install automatically when this option is selected. Administrators must manually install the device through Device Manager.

      • Select the Uninstall existing USB storage devices not on the allowed list of devices option to uninstall USB storage devices that are not whitelisted.

        As a safeguard against uninstalling devices that are required for the system to run, other devices that are currently installed on an endpoint, including devices that are not currently connected but were installed previously, are not uninstalled when this option is selected. If the device is in use when the policy is enforced on the endpoint, the device is uninstalled at the next reboot of the endpoint. In this scenario, the policy status sensor returns a status indicating that prohibited devices are still installed.

      Device Classes

      Use the Device Classes section to define groups of devices that you want to allow in your environment. Many device classes are predefined by Microsoft, and you can define custom device classes. Each device class has a globally unique identifier (GUID). For more information about device classes, see Microsoft: Hardware Dev Center: Device Classes. When you add a device class, it is stored in the global device class list, which you can access from the Protect settings page. For more information on the global list, see Manage Windows device classes and devices.

      If you add a device by device class, you must allow all of the device nodes in the device tree for that class. For example, if you want to allow the installation of a USB storage device, you must allow the installation of Disk Drives and USB Bus Devices (hubs and host controllers). For more information, see Microsoft: Hardware Dev Center: Device nodes and device stacks.

      1. Click Import to query all Windows endpoints for their installed device classes and import them to the allow list. With this option, you can quickly add any custom device classes that might be used in your environment. Device classes that are already known to Protect, marked with a blocked icon , are not imported to avoid duplicates. From this page, you can select all device classes that were found on endpoints or you can select individual device classes. Click Proceed to add the selected device classes to the allow list.
      2. Click Manage Existing to add existing device classes to the allow list. This list contains the predefined device classes that are provided by Microsoft and any device classes that were manually added previously. From this page, you can add or remove all available device classes, or add or remove individual device classes.

        If you added a device class using the Create option, you will not see it in this list until you save the policy.

      3. Click Create to add a new device class. Specify a device class name, valid GUID, and optional description. Click Create again to add the device class to the allow list.

      Devices

      Use the Devices section to define individual devices that you want to allow in your environment. This option is useful if, for example, you want to allow a USB storage device from a specific manufacturer that is supported by your company, but no other USB storage devices. You do not need to allow the associated device classes when you allow a specific device. When you add a device, it is stored in the global device list, which you can access from the Protect settings page. For more information on the global list, see Manage Windows device classes and devices.

      • Click Create to add a new device. Specify a device name and an optional ID. Click Create again to add the device to the allow list.

        Most devices have several hardware IDs. These IDs range from the most specific, which identifies a particular device, to a more general ID, which might identify a device type. Use the hardware ID that is appropriate for your environment.

      • Click Manage Existing to add existing devices to the allow list. This list contains devices that were manually added previously. From this page, you can add or remove all available devices, or add or remove individual devices.

  4. Click Create to create your policy.
  5. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Create an EMET policy

Before creating EMET rules, read best practices for EMET rules. It is important that you also read and understand Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 5.5 User Guide and then carefully test mitigations and their impacts before deploying them widely.

If an endpoint does not have .NET 4.5, Protect dynamically installs .NET 4.5.2 in order to be able to create EMET rules. If an endpoint does not have EMET 5.5 installed, Protect dynamically installs this as well. If previous versions of EMET exist on the endpoint, Protect removes them. If you do not want the dynamic installation of either .NET or EMET, then you can disable this capability by selecting Protect Settings on the Protect Home page and then unchecking Automatically Install Prerequisites. If you disable this capability, you cannot enforce EMET rules on endpoints that do not meet the .NET and EMET requirements.

You must stage .NET and EMET packages on the Tanium Server before you can deploy EMET with Protect. If you are in an air-gapped environment (networks that are not exposed to the Internet), please consult with your TAM on the procedure to upload these packages in an air-gapped environment.

Refer to Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 5.5 User Guide for instructions on how to create an EMET protection profile and associated XML file. You must use the EMET application to create an EMET protection profile and export it from the main Enhanced Mitigation Experience Toolkit page to an XML file for use in Protect. This XML file is uploaded to Protect.

Protect does not support XML file creation or in-line editing. Protect verifies that the imported EMET XML file is valid and does not enforce an invalid EMET XML file.


Do not export the profile from any other EMET windows such as Application Configuration, Certificate Trust Configuration, etc. in order for the EMET rule to work correctly in Protect.

  1. Click Create Policy from the Protect Home page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select EMET from the Policy Type drop-down menu.
  3. Click Choose EMET XML file and browse to the file that contains XML code for the EMET rule.
  4. Click Create to create your policy.

Create a Windows firewall management policy

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select Firewall Management - Windows from the Policy Type drop-down menu.
  3. In the Firewall Profiles section, expand Domain, Private, and/or Public to define the policy profiles. For more information about protocols, see Microsoft Technet: Understanding Firewall Profiles. Choose Default, Enabled, or Disabled for Network Selection.

Create a new Windows firewall rule

  1. In the Firewall Rules section, click Add Rule.
  2. Complete the following fields for your firewall rule:
  3. Field Description
    Name This is a required field. Enter a brief name for the rule.
    Direction This is a required field. Select Outbound, Inbound, or Bi-directional for the direction of the connection.
    Action This is a required field. Select either Block or Allow depending on the type of rule you are creating.
    Network Protocol

    This is a required field. Select a protocol. If you specify UDP or TCP for the protocol, then you must specify at least one value in the following fields: Application Path, Local Address(es), Local Port(s), Remote Address(es), Remote Port(s), or Service Name.

    For more information about protocols, see Microsoft Technet: Firewall Rule Properties.

    Group This is an optional field. You can specify a group name here or choose one that already exists that can help organize your firewall rules.
    Profiles Select the applicable profiles. If you do not select one or more profiles, the rule is created as if all profiles were selected.
    Application Path An example of an application path is C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.
    Local Address(es) Use this field to target the rule to specific local IP addresses. Separate IP addresses with commas.
    Local Port(s) This field is most likely populated for Inbound connections. You can specify port ranges, for example: 80, 443, 5000-5010.
    Remote Address(es) This field can be used to target the rule to a specific remote IP address. Separate IP addresses with commas.
    Remote Port(s) This field is most likely populated for Outbound connections. You can specify port ranges, for example: 80, 443, 5000-5010.
    Service Name This field can be used for a Windows Service Display name.
  4. Click Create to create your policy or click Add Rule again to add another rule to the policy.
  5. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Import firewall rules from a Windows TSV file

Before you can import a firewall policy into Protect from a Windows TSV file, you must export it from Windows.

  1. In Windows, go to Windows Firewall Advanced Security.
  2. In the left pane, right-click on Inbound Rules and click Export List. Save the file as a Text (Tab Delimited) .txt file.
  3. In the Firewall Rules section, select Import from Windows TSV File from the Import drop-down list
  4. Select the files that contains the exported firewall rules and click Open. The Import window shows the file name and how many rules are being imported.
  5. Select the Direction.
  6. Click Proceed.
  7. Repeat these steps for Outbound Rules to export them from Windows and import them into Protect.

If the file you are importing does not include a Service column, a warning displays. If your firewall rules depend on the Service field, add the Service column and re-export the firewall rules from Windows.

To add a Service column

  1. In Windows, go to Windows Firewall with Advanced Security.
  2. Select Add/Remove Columns from the View menu.
  3. Select Service from Available columns and click Add.
  4. Click OK.
  5. Select Export List from the Action menu and save it to a file.

Import firewall rules from Tanium Endpoints

  1. In the Firewall Rules section, select Import Rules from Tanium Endpoints from the Import drop-down list.
  2. In the Import Firewall Rules from Tanium Endpoints window, select the rules already existing on Tanium endpoints that you want to import.
  3. Click Proceed.

Create a Linux firewall management policy

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select Firewall Management - Linux from the Policy Type drop-down menu.
  3. In the Linux Firewall Default Chain Policies section, select ACCEPT or DROP for the Input, Output, and Forward fields.

Create a new Linux firewall rule

  1. In the Linux Firewall Rules section, click Add Rule.
  2. Complete the following fields for your firewall rule:
  3. Field Description
    Name This is a required field. Enter a brief name for the rule.
    Chain This is a required field. Select INPUT, OUTPUT, or FORWARD to specify where in a packet's delivery path a rule is evaluated.
    Target

    This is a required field. Select one of the following:

    ACCEPT: Allows the packet.

    DROP: Drops the packet.

    QUEUE: Pass the packet to userspace.

    REJECT: Send a response back and drop the packet.

    Network Protocol

    This is an optional field where you can select the protocol of the rule or of the packet to check. The specified protocol can be one of the predefined options or it can be a numeric value, representing one of these protocols or a different one. Protocol all is the default when this option is omitted.

    State

    Select one of the following:

    • New: The packet has started a new connection.
    • Established: The packet is associated with a connection which has seen packets in both directions.
    • Related: The packet is starting a new connection, but is associated with an existing connection.
    • Invalid: The packet could not be identified for some reason.
    Source Address A comma separated list of network names, IP addresses with masks, plain IP addresses, or IP address ranges.
    Destination Address A comma separated list of network names, IP addresses with masks, plain IP addresses, or IP address ranges.
    Optional fields that might appear depending on choices you make for some of the fields above:
    Source port(s) A comma separated list of ports or port ranges.
    Destination ports(s) A comma separated list of ports or port ranges.
    In Interface Name of an interface via which a packet was received.
    Out Interface Name of an interface via which a packet is going to be sent.

    Depending on the choices you make for the Chain, Target, and Network Protocol fields, additional optional fields might appear that you can complete.

  4. Click Create to create your policy or click Add Rule again to add another rule to the policy.
  5. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Import Linux firewall rules from Tanium endpoints

In order to import Linux firewall rules from Tanium endpoints, you must deploy Protect tools to your endpoints. See Deploy Protect tools.

  1. In the Linux Firewall Rules section, click Import Rules from Tanium Endpoints.
  2. In the Import Firewall Rules from Tanium Endpoints window, select the rules already existing on Tanium endpoints that you want to import.
  3. Click Proceed.

Some rules might specify “rule not supported …”. This means that Protect does not support this rule, but the entire rule configuration is shown in the rule listing so that you can configure it manually if needed.

Create an SRP Management policy

When you enable Windows SRP for the first time, targeted endpoints must be rebooted in order for SRP Management policies to be enforced.

Create an SRP process rule using a path

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. In the Policy Details section, enter a Name and Description for the policy. Select SRP Management from the Policy Type drop-down menu.
  3. Click Add Path Rule.
  4. Enter a Name for the rule.
  5. Enter the path or filename in the Path field. Full paths, environment variables, and filenames are supported.
  6. Click Create to create your policy or continue to add rules.
  7. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Create an SRP process rule using a hash

  1. Select Create from the New Policy drop-down menu on the Policies page.
  2. Enter a Name and Description for the policy.
  3. Select SRP Management from the Policy Type drop-down menu.
  4. Click Add Hash Rule.
  5. Enter a Name for the rule.
  6. Enter the MD5 Hash.
  7. Enter the File Size in bytes.
  8. Click Create to create your policy or continue adding rules.
  9. Edit a policy once you have created it by selecting the policy on the Policies page and then clicking Edit, making any necessary changes, and clicking Enforce Changes if enforcements exist or Update (if no enforcements are in place).

Be aware of AppLocker Allow or Deny rules set in your Domain Policy – these rules might prevent SRP process rules created in Protect from being enforced.

Search for firewall and SRP management rules

Once you have created firewall or SRP management rules, you can open the policy and use the Filter and Search fields at the top right of the Firewall Rules or SRP sections to search for specific rules.

The policy must be in edit mode to see these fields.

Create a remediation policy

  1. From the Policies page, select Create from the New Policy drop-down list.
  2. In the Policy Details section, enter a Name and Description for the policy.
  3. Select the type of remediation policy from the Policy Type drop-down list (Remediation - Windows, Remediation - Linux, or Remediation - Mac).
  4. In the Remediation section, select the task you want to run on your endpoint(s) from the Add Task drop-down list.

    You can add the following seven types of tasks to a Windows remediation policy:

    • Delete Registry Key: deletes a registry key if it exists.
    • Delete File: deletes a single file or multiple files matching a glob pattern.
    • Edit Registry Data: modifies an existing registry value if it exists; optionally, the value can be created if it does not exist.
    • Update Registry Value: changes the name of a registry value if it exists or deletes the value if the delete option is selected.
    • Kill Process: kills all processes that match the specified Process Type options: name, path, or hash. You can also optionally enter Command Line Args to use a regular expression to match against process command line arguments for any of the Process Type options.
    • Run Service Action: changes the running state of the specified service.
    • Run Service Configuration: Changes the startup config of the specified service.
    • For tasks that modify the registry and target the HKEY_USERS hive, if you use the wildcard (*) to target all users, users that are logged out when the policy is enforced are skipped.

    You can add the following three types of tasks to a Linux or Mac remediation policy:

    • Delete File: deletes a single file or multiple files matching a glob pattern.
    • Kill Process: kills all processes that match the specified Process Type options: name, path, or hash. You can also optionally enter Command Line Args to use a regular expression to match against process command line arguments for any of the Process Type options.
    • Run Service Action: changes the running state of the specified service.
  5. Complete the required fields for the task you are defining.
  6. Add other tasks as needed for the policy. When you have added all tasks, click Create.

Import policies

You can import one or more policies from a JSON file.

  1. From the Policies page, select Import from the New Policy drop-down list at the top right.
  2. Click Choose File on the Import Policies page.
  3. Select a JSON file and click Open.
  4. Select the policies you want to import. Import Status shows one of the following:
    • New: The policy does not already exist.
    • Modified: A policy with this name exists and will be overwritten with the policy you are importing.
    • Error: A problem occurred during your import. You might not have sufficient privileges to import this policy.
  5. Click Import.
  6. Imported policies appear on the Policies page. The Change Type under Policy Details indicates Imported.

Export policies

  1. On the Policies page, select the policies you want to export.
  2. Click Export to export selected policies to a JSON file.

Last updated: 11/8/2018 4:46 PM | Feedback