We previously went into application mapping in this blog post and we will delve into it further in this post to explain how that application mapping is used to create whitelists that can be used for micro-segmentation.
Application Map
With Tetration, the application mapping feature can show us how different workloads are accessing services or how certain sets of users are accessing an application. Going back to the application map we previously viewed, one can select a purple pin on the right-hand menu to see how that application is being accessed from between different clusters. For example, if one wanted to see how the internet was accessing a certain application, this would be a way to easily view it. One use case would be so one could create firewall rules and know exactly which services to allow and between which servers.
You could dig even deeper: Let’s say if you wanted to see how developers are accessing an application, it can be easily visualized here as shown below. The arrows show whether it’s unidirectional or bidirectional communication.
After planting the purple pin, the view shows how it is being accessed at a high level. If you hover the mouse over a cluster, you can see what ports it’s being accessed on.
Clicking on a cluster in their application map and then clicking on Provides in the right-hand pane, you can see the processes that are responsible for the open ports.
If the port is in port like shown in the above picture, that means they’re actively being used whereas the ones that are greyed out are not. This gives you a nice and easy way to see which services are currently active and which ones are not.
If you wanted to get more detail, we can click on the process in that right-hand pane and see the user that kicked off that process and what command was responsible for kicking it off.
Now imagine if a user came and asked to open several ports in the firewall because a vendor asked them to, Tetration would give an administrator the visibility to inspect the services being used by those applications and see if they actually need those ports open. Not only can Tetration see what’s actively being used, the administrator can review the history of the application and see if the ports were used in a specified timeframe. For example, they would be able to see that NTP’s port was open on a server and the process was running but there wasn’t a single packet sent or received for that port in an entire month and prove to the user that the port didn’t need to be opened in the firewall.
Whitelist Policy
Once Tetration builds the application map, it will automatically build the whitelist based on that application map.
If we click on one of the consumers or providers above, we can then see the specific servers in the right-hand pane.
Reading this policy is simple: The uat_haproxydb servers are allowed to talk to Active Directory using UDP port 53 (DNS) and UDP port 123 (NTP) according to the first line of the whitelist. If we click on the ports, we can see even more information in the right-hand panel as shown below.
Note: Even though Tetration software sensors are not installed in the endpoints in the campus, Tetration can still see the endpoints from the campus communicating with the application. If one clicks on the campus provider in the policy, they will see the endpoint IPs from the campus that have been detected by Tetration in the right-hand pane.
The above was just one example. By deploying the software sensors and giving Tetration a scope, it will build the application map and whitelist policy on its own.
After the whitelist policy has been built, it can still be modified. If one would like to add an entry in the whitelist policy, there are two methods of doing so:
DEFAULT POLICY
Add a default policy on the screen by clicking on the Add Default Policy button.
We would then choose the action, consumer, and provider. In the right-hand pane, we could add one or multiple service ports and protocols to that policy.
ABSOLUTE POLICY
The second option is to add the policy in a more global way. For example, if we know that SSH is widely used in the data center, we might want to create a policy entry that will apply over any data center and every application. To do this, one can build a global policy.
To do so, click on the Switch Application button on the top right-hand corner of the screen. The new application workspace screen should be display. This is where we can build that hierarchical model of policies.
If we build an absolute policy that starts at the top of the hierarchy, it will be like a domain group policy in Active Directory - it will apply to everything below it in the hierarchy.
Policy Views
The above view of the policy is the conversation view but we can click on Clusters to show the cluster view. When Tetration maps the applications together to create the whitelist, it will automatically create these clusters.
If we later add another server to this application with the software sensor installed, Tetration will know to automatically group it into the appropriate cluster and apply the appropriate whitelist policy that’s already there for that cluster as long as it has the same process, traffic pattern and query. Since Tetration can dynamically cluster these workloads together, the administrator doesn’t have to manually add or remove these servers from the cluster.
Tetration has another view of the policy called the chord chart. If we click on the chart button on the policy screen, it will switch the view to the chord chart.
Lets say we see a whitelist policy created for the uat_siwapp_app servers to communicate with the data_feed servers on certain ports and we aren’t sure if there was communicate for one server or with multiple in that data_feed cluster. Since Tetration isn’t stating the specifics from the policy screen and it’s created the whitelist based on that cluster, we can do a couple of things:
We can click on the policy entry and then click on View Conversations in the right-hand pane.
By clicking on this, Tetration will build out the conversations so we can see which specific consumers and providers communicated.
So with Tetration, we has the power to filter with clusters but also break down the specific conversations.
Another way to see the above specific conversations is using the chord chart again. The way to do this is to go back to the Policies screen and click on the chart button.
To see the individual traffic patterns, we can move the mouse over a certain cluster to see the ports.
Click on the cluster to select the cluster and then click on the magnifying glass to expand that cluster.
At this point, Tetration breaks it out a little more.
Now Tetration will show all the individual servers that are having those conversations in the cluster and when we hover the mouse over it, it will paint the conversation.