Using Visualizations to Gut-Check Security

Part 1- Getting the Data Connected

I’ve always been a sucker for informative data visualizations, but admittedly, have never been one to generate them. However, with the close of a recent project, I recognized a sort of unique opportunity to get my feet wet. During this project, the use of white list-based firewall rules was employed. This means that specific host-to-host traffic required a corresponding firewall rule, per port (or port range), to allow network traffic to flow. Our model dictated that each application or service requiring connectivity to another host be evaluated, and permitting rules be drafted. Inherently, these rules define a specific source and destination for each potential network traffic path. Then I realized, this is exactly the content of an incidence matrix of a directed network!

This is when I gathered that the overlap between my passion for abstract networks and information security could be represented in an almost “artistic” medium. To get going, I had to get the data I was desiring.

As this project involved creating an infrastructure in Microsoft’s Azure, I knew that the data for the firewall rules I was looking for were contained within Network Security Groups, whose content is retrievable via the Azure PowerShell cmdlets. I created a PowerShell script to combine all the Network Security Rules into a single data set. After logging into an Azure subscription, the following can be run to generate a single CSV. Please excuse my lack of scripting optimization – I am not a developer by trade (I would gladly send anyone the plain-text of the script).

After source and destination address prefixes are obtained, they can be used to populate the vertices and edges of a NodeXL template.  Then, an image similar to the following is created. 

Simply, it displays all of the nodes in our subscription, and how they are connected, and in turn, how they are able to communicate with other nodes. A couple of key realizations are made off the bat. First, the trunk that seems to cut the middle of the circle is Active Directory communication. As many Active directory services require unique ports, there were many rules to write. Also, as every domain joined system communicates with Active Directory, so it makes sense that this trunk exists. Second, the arc connecting the 10 o'clock and 11 o'clock positions is application server to database server communication. There is another set of arcs that correspond to web servers communicating with application servers, but they are almost too faint to see without zooming in. Also, we can observe the occurrence of "loop-back" rules (see around 1 o'clock). This is where nodes (typically subnet ranges) are able to talk to themselves over specific ports/port ranges. This could give evidence of over permissive rules, depending on the scope of the Network Security Group.

My plans for the next part in this blog series are to incorporate node size and edge width. Currently, no scaling is given to either of those properties. My thought is to give the visual more meaning by weighting node size on the number of host address contained in a node (ie a /24 node would be much larger than a single address).  Additionally, increasing the width of the edge based upon the number of open ports commutation is able to be facilitated on will give more substance to node connections. These actions are both easier said than done, however. 

So, stay tuned for another iteration of creating information security visuals for your Microsoft Azure network, and feel free to reach out with any questions or comments!