TrustSec Policy Analytics – Part Two: Policy Visualization

In Part One of the Cisco TrustSec Policy Analytics blog series, Samuel Brown addressed some of the challenges related to designing group-based security policies and introduced one of the new feature sets of Cisco Secure Network Analytics – TrustSec Analytics reports. In this blog, we’ll dive a little bit deeper into the challenges associated with designing segmentation policies and how TrustSec Analytics reports and the visibility they provide can help make this easier.

I’d like to do segmentation, but I don’t want to get fired.

The above statement illustrates this problem space and is an actual statement that a CISO at a large healthcare organization made to me. This CISO had looked at his network design, understood the types of devices, applications, and users on it, and had realized that he needed to implement group-based segmentation policies east-west across his environment; however, he had also realized that in order to proceed, he would run the risk of disrupting business and operations, which, in the healthcare world, could be, well, pretty bad and fraught with consequences to say the least. What this CISO needed was a tool that would have allowed him to move forward with confidence that the policies designed, the groups assigned, and the policies enforced would not disrupt operations – this is where Secure Network Analytics comes in: with its database of all east-west as well as north-south communications across a network, Secure Network Analytics provides visibility into what’s happening on the network and facilitates a data-driven approach to designing segmentation policies.

Many years ago, Secure Network Analytics (then called Stealthwatch) was integrated with Cisco Identity Services Engine (ISE) to address various use cases, one of which was getting the Security Group Tags (SGTs) that it assigns to hosts and decorate flow records with those tags. In the years since, I’ve worked with customers like our above CISO to build effective segmentation policies by leveraging the visibility provided by Secure Network Analytics. Once an organization has a handle on the groups and labels they want to implement on their network, the next and most fundamental questions that need to be addressed are:

• How do I decide what policies should exist between my groups?
• How do I know that my policies are correct and won’t disrupt operations?

While it is possible to leverage the SGT decorated flow data in Secure Network Analytics to answer these questions, the new TrustSec Analytics reports introduced in version 7.3.1 make it much quicker and easier to do so through visualizations of all group communications across the network.

How do I decide what policies should exist between my groups?

This can be a surprisingly hard question, which has two parts – both the technical and the nontechnical. The nontechnical is business related and must balance acceptable risk, compliance, and logic in an attempt to implement least privileges, for example, “Should I allow contractors to communicate to my bottling line?” The second, technical, part is about what type of communication should be allowed, or disallowed, between those groups – for example, “What ports, protocols, applications, and other permissions does my bottling line need in order to operate?”

With some thinking, you could turn those natural language questions into a flow query and ask them of Secure Network Analytics. The TrustSec Analytics report, seen below, helps to show you the answers before you ask the question.

You can note in the top right of Figure 1 that the report has been configured to display 7 of the 18 total security groups I have in my organization.

In the report, colored cells indicate traffic between two security groups, while gray cells indicate that there is no traffic. This is the first step in deciding if a proposed policy could disrupt operations – if there is traffic, that means something or someone is communicating and that it might be important, while if there isn’t any traffic, that might indicate that you can start thinking about implementing least privileges between those groups. Keep in mind that time can be a major consideration in this decision, and sometimes it’s worth it to run multiple versions of this report, covering varying time periods such as last 7 days, last 30 days, or even longer depending on the nature of your operations.

The next step is testing the proposed policy, and that’s what the colors are indicating – there is traffic and there is an Access Control List (ACL) applied in the TrustSec policy matrix for that cell in ISE.

• Gray – no traffic
• Green – there is traffic and a permit IP ACL exists
• Red – there is traffic and a deny IP ACL exists
• Blue – there is traffic and an ACL other than permit IP or deny IP exists

Clicking on a cell generates a popout showing some high-level details about the communications between the groups in the cell. You can then pivot from here to some top reports and/or the actual flow records and use this raw data to develop a policy for each cell. For example, in Figure 2, we’ve expanded the cell Employees (source) to Production_Bottling_Line (destination). I had been working on a hypothesis that from a business standpoint, users in the Employees security group should not have network access to the Production_Bottling_Line group, and had proposed a “deny IP” rule for the cell (hence the red coloring), but am now seeing that there is indeed traffic between those two groups.

Clicking “Flow Search” prebuilds a flow query, and after verifying and running returns the below result.

In Figure 3, we can view details about the traffic flows that have occurred between a user (“Darrin”) and a server (10.160.160.100) in my production bottling line. We came here because this flow is counter to what I had thought should be the least privilege policy between the Security Group Employees and the Security Group Production_Bottling_Line. So now we have a decision to make – was the policy wrong or is this in fact a policy violation? In this case, given that it is the only flow between the two groups and having some familiarity with Darrin, I’m going to decide this is a policy violation and assume that my policy is correct. This process can be repeated for other cells and other proposed polices, growing in sophistication as users see fit.

In the above example I’ve quickly moved through the data to help address those fundamental questions, leveraging visibility and data to test policy hypothesis and hopefully moving quickly to being able to implement segmentation polices in my organization.

Unfortunately, or fortunately, depending on your outlook in life, we’re not fully done yet: even if we’ve decided that the policy between our groups is correct, we will need to verify that it is still correct tomorrow, that it is being enforced the way we expect it to be, and whether it is being adhered to or whether there are nefarious actors on our network.

Stay tuned for TrustSec Policy Analytics – Part Three, which will address policy validation.

Don’t have Secure Network Analytics? Learn more by visiting www.cisco.com/go/secure-network-analytics or try the solution out for yourself today with a free visibility assessment.

Share: