Although the phrase “a picture is worth a thousand words” is a bit trite – it’s true. With 70% of our sensory data coming from vision, and having brains that are good at visual pattern recognition, humans are better at processing visualizations than we are at poring over numerous different text data sources. In this blog post, we’ll explore an attack surface visualization we’ve put together to help you better understand and manage server security.

I’ve recently written a program which uses the wonderful graphviz package to draw representations of IT infratructure from a few perspectives. This article will concentrate on visualizing the attack surface for a single computer. The graph below is information we discovered from a single system. From installation of the software to drawing the graph took less than 10 minutes. We tell you how to do this on your systems in a later blog post.

Visualizing the Attack Surface of a Single System

From the security perspective, one thing you often want to know about a single system is how it talks on the network – what ports are in use, what services are running behind them, and what user ids the services are running as, and so on We’ve included a sample services graph below. Please note that this diagram has a lot of detail, which if you have good eyes and a good monitor you can almost read in the picture below. To see all the details, right-click on it, and open it in another window. Even with this level of detail, you can see some things in red, so you’re probably thinking – things in red are usually bad. That’s the case here – things in red indicate areas of potential concern.

At the top of the attack surface graph, is a big red house-shaped icon representing the server I collected the data from. It has 31 known security violations (out of about 70 rules we’ve implemented so far), so it is highlighted with a bold red outline. The color and boldness of the outline change depending on the level of security issues we’ve observed (bold red being the most severe). If the server was shut down gracefully, the icon is filled with grey, and the outline is dashed. If it crashed, then the icon is filled with hot pink and has a dashed outline.

It is running 11 different TCP-based services (the icons with “file-folder” shapes). A few of them (rpcbind, sshd and apache) are running as root, so their details are in red text. I certainly didn’t realize that Ubuntu runs Apache as root by default! The icons with solid blue outlines are being monitored for correct operation, and those with dashed-blue outlines aren’t being monitored. The details we display on this chart are the binary name, the user and group ids that its running under and its working directory. We discover more information than this, but this seems like a reasonably informative and compact representation. For interpreted languages (like Java or python), we include the binary name (like java) and an indication of which script its running. For neo4j, the Java program name is org.neo4j.server.CommunityBootStrapper.

On the bottom line are rectangular icons with the IP:port combinations that the various services are accepting connections on. In addition to providing services, dropbox and skype also connect to (are client to) other IP addresses. For reasons not at all clear to me, Skype connects to three different IP:port addresses and listens on two. The xchat program has a rectangular shaped blue icon, as it only connects to outside IP addresses, and doesn’t provide any services.

The various kinds of arrows indicate the kinds of relationships on the graph. This diagram includes these types of relationships:

• hosting – indicates that the service being pointed to is hosted on the server where the arrow comes form
• tcpservice – indicates that the service where the arrow originates is listening on the given IP:port combination where it terminates.
• tcpclient – indicates that the process pointed to by the arrow has connected to the service listening on the originating end of the arrow. Note that these last two kinds of relationships indicate dependencies when seen in a larger graph.

Although this is useful and pretty cool, I’d love to know your opinions on what we could be providing, or what we should emphasize, and how you think we should emphasize it. This information is stored in the Neo4j graph database, which makes visualizations like this very natural and simple to create.

Of course, if you’d like to learn more about this, and how to produce such information across your entire infrastructure, and keep them up to date, check out the Assimilation System Management Suite – that provides this in a few minutes with near-zero human configuration.