Security policy templates

A Security Policy Template, also known as SPT in Xshield, is a set of workload role-based rules used to define Access policies for the real-world application Workload groups in Xshield. An SPT rule is set between workloads of the source role (for example, APP workloads) and the workloads of the destination role (for example, DB workloads) of the same group, to allow communication on a specific port/protocol combination (Access parameter). Multiple SPT rules help you build communication paths for the services in the real-world application grouped to an Xshield Wokload group.

Security policy templates page

All SPTs created in the instance are listed on the Policies > Templates > Security policy templates page. You can see the name, description, and number of rules in the templates.

Security policy template rules

A rule in an SPT defines the allowed communication between workloads of different roles in a Workload group. SPT rules are built using the values of the Role tag. The default values of the Role tag are WEB, APP, DB, and ALL.

You can add more custom values for the Role tag and use them to build more role-based policies.

Security policies enforcement

Apply SPTs to Workload groups when you begin the Policy simulation efforts for the groups. Enforce SPTs when you want to enforce Zero Trust-based access on the workloads in the groups. Before you enforce, you must ensure that all the services required for the workloads are configured through SPTs or other policies such as CPTs and custom Access policies.

Access policies relevant to the SPTs are automatically enforced on the relevant workloads along with other policies. All such enforced SPT-based Access policies are listed on the Policies > Access Policies page.

Use the system-level, default SPT ALL:any:ALL to allow unrestricted communication between all the workload assets in a Workload group. This may be needed during the initial phase of Policy simulation or to fall back if the workloads in a 3-tier Workload group stop working as expected after Policy enforcement.
Use an SPT APP:<Access Paramter>:DB to restrict communication between workload using the APP and DB roles on one specific port/protocol combination only.

Create Security policy templates

Decide upon the workload roles and Access parameters for which the SPT must apply. Reusing SPTs for multiple Workload groups can reduce the overhead to update them constantly. See some examples of how to use SPTs with Workload groups.

One of the most commonly created SPT is for intra-group communication in a Workload group for a 3-tier application.

Go to Policies > Templates.
Go to the Security Policy Template tab.
Click Create Security Policy Template.
In the Name text box, enter a name for the SPT.
Add a useful description.
In the Rules area, Click Add and add one or more rules.
A rule is added as follows.
1. From the Role list on the left, select the role of the source workloads (For example, APP.
2. From the Access Parameters list, select the Access parameter (For example, tcp:3306.
3. From the Role list on the right, select the role of the destination workloads (For example, DB)
Repeat step 7 to add all the rules needed for the SPT.
Click Save.

Edit Security policy templates

Edit SPTs when you want to add new rules (to scale for new components you add to the applications) or change the Access parameters for the rules. For example, you want to change the standard port to a custom port 1434 on UDP.

SPT edits impact the Policy enforcement on all Workload groups in which the SPT is used.

Delete Security policy templates

Delete SPTs that are not used anymore. Once deleted, SPTs cannot be retrieved.

A prerequisite to delete SPTs is that they must not be currently in use for Workload groups. So, you must first edit the Workload group(s) to which an SPT is assigned and unassign the SPT from the group(s).