In this article we will take what we have learned about policy constructs and logic to create and deploy meaningful policy.
Quick Links:
Deploying a Policy Using Graphical Policy Visualization Matrix
Deploying a Policy Using Traffic Flow Visualization Matrix
As a reminder, Elisity policy logic has two modes: Explicit Trust enabled and Explicit Trust Disabled. When this setting is enabled, all access by users, devices, and applications is denied by default until a policy explicitly allows it (default deny rule). When this setting is disabled, all access is allowed by default until a policy explicitly denies it (default allow rule). Enabling Explicit Trust is a common greenfield deployment strategy (i.e., over new infrastructure), while disabling it is a typical brownfield deployment strategy to avoid disrupting business operations while access policies are being built. It is recommended to disable Explicit Trust if the strategy is to observe, learn, and build access policies as part of a brownfield deployment. Be advised that switching from “disabled” Explicit Trust to “enabled” after access policies were created could cause disruption at policy enforcement points and require adjustments to existing policies.
Building an Elisity policy is as simple as specifying the source and destination of the traffic as well as the desired security rules. The match criterion for source and destination is very flexible and includes options such as Active Directory group, Department, Title, cloud native tag, device type, device vendor, and much more.
There are a couple of ways to select your source and destination objects: by manually deploying a policy and searching for match criteria and by using the Policy Matrix.
First, let’s look at deploying a policy using the Graphical Policy Visualization Matrix.
Go To: Policies -> All Policies -> Graphical View
At the bottom right of the policy matrix, there is a toggle button that allows you to switch between Graphical View and Traffic Flow. Graphical View is used to show what policies are deployed and give a visualization of the type of traffic that is or is not allowed to flow. Traffic Flow view allows you to see where traffic has been observed in the network, whether that traffic was allowed or blocked, and if there is a policy in place. In both views, deploying a new policy or even modifying an existing policy, is as simple as finding the intersection between the source group on the left and the destination group on the top, and clicking on the box at the intersection. From here, deploying a policy is as simple as selecting your security rules.
Here we want to deploy a policy that denies access from Physicians to Roku TVs on the network to block them from controlling the TVs with their mobile devices. To deploy policy, we find the intersection between these groups, click on the empty box, and select our rules.
Graphical Policy Visualization View
(Click to enlarge)
Traffic Flow View
(Click to enlarge)
We can see in the image below that source and destination were automatically populated upon clicking on an intersection in the Graphical Policy Visualization Matrix. There are a couple of options to select when deploying security rules.
- Select a pre-defined Security Profile, and select, edit, or clone.
Select: allows you to copy the security rules from the security profile and modify them without affecting the security profile in any way.
Edit: allows you to copy in security rules, modify them, and apply them to the original security profile upon deploying.
Clone: Allows you to copy security rules into a new security profile, and any modifications to security rules will be saved with the new security profile. By default, the SP name has "_clone" added to the name. You can change the Security Profile name and save.
Note: this does not apply to system default security profiles like DENY_ALL or ALLOW_ALL.
(Click to enlarge)
- Create a new set of Security Rules
Select L3/L4 Protocol and create a custom set of rules.
(Click to enlarge)
Deny All Policy Example
Here is an example of denying all traffic between two PGs: IT_Workstations and OT_PLC_RTU. There should never be any communication between these two groups, so let's insert a "Deny All" Policy. We have clicked on the intersection between two Policy Groups on the Graphical Policy Matrix. We will select the system default DENY_ALL security profile. We then click deploy, and in just a few seconds we have built and deployed a policy.
(Click to enlarge)
Unclassified Assets Policy Example
- Let's create a policy that only allows internet access for any unclassified device on our network. These are both system generated Policy Groups that already exist on the Policy Matrix, so we simply need to click the intersections and define security rules.
First we will shift click and select all Policy Groups except for our InternetPG. Click "Add security profile to the selected Policy cells"
Now we will select our default security profile DENY_ALL and click deploy. Remember, this system default Security Profile does not require any security profile actions. Simply select, and click Deploy.
After deploying we can see the policy cells are now populated with our deny policy. Now we will select the policy cell located at the intersection between Unclassified and InternetPG to define what traffic we will allow from our Unclassified devices to the Internet.
We will select the default Security Profile ALLOW_ALL and deploy (not shown). Now we can see clearly our set of policies for our unclassified devices that only allows access to the internet, and denies access to any other device on the network, including other unclassified devices.
Traffic Flow Visualzation Matrix
Filtering Traffic Flows in the Traffic Flow Visualization Matrix
With our Traffic Flow Visualization Matrix, users in Cloud Control Center can see what traffic flows are occurring between established Policy Groups. This is very useful when determining what protocols should be allowed in the security profiles between Policy Groups. Users can filter traffic flows to see the last hour, the last 24 hours, the last 7 days, or the last 28 days. The ability to filter traffic flows means that shortly after deploying new Policy Groups or implementing a new policy, administrators can filter down to the most recent traffic flows to get an accurate representation of how the devices in the Policy Group are interacting with the rest of the network, and how a policy change could have affected those traffic flows. Filtering for a longer period like 28 days gives admins a good idea of normal long-term traffic behaviors for established Policy Groups, simplifying policy decisions.
Below we can see the difference in traffic flows represented on the Traffic Flow Visualization Matrix if filtering for the last 24 hours vs filtering for the last 28 days.
filtering by last 24 hours - click to enlarge
filtering by last 28 days - click to enlarge
As more data is learned, policy should be continually revised and improved. New traffic flows, devices, user groups, processes, and added connectors can all require revision and improvement of policy groups and policy. Continually tightening and hardening network segmentation is important as attack vectors continually grow, and cyber attacks find new mediums to exploit network vulnerabilities.
Traffic Flow Policy Example
Clicking on an intersection in the Traffic Flow Visualization Matrix will bring you to the following screen.
Here we have clicked on the intersection between Media Players and unclassified assets on our network. We can see exactly what traffic flows have occurred in our selected window of 28 days. If you click "Add Policy" these observed flows will automatically be converted into Security Rules, which you can choose to allow or deny.
Next, let’s look at manually deploying a policy.
Go To: Policies -> All Policies -> Add Policy
(Click to enlarge)
Step 1: Define Source Match Criteria
(Click to enlarge)
Step 2: Define Destination Match Criteria
(Click to enlarge)
Step 3: Define Security Rules OR Select a Security Profile
(Click to enlarge)