Using the Assimilation Project to Perform Service Discovery and Inventory of Systems
I recently thought of the apocryphal story about the solid reliability of the IBM AS/400 systems. I’ve heard several variations on the story, but as the most common version of the story goes, an IBM service engineer shows up at a customer site one day to service an AS/400. The hapless employees have no idea what the service engineer is talking about. Eventually the system is found in a closet or even sealed in a walled off space where it had been reliably running the business for years completely forgotten and untouched. From a reliability perspective, this is a great story. From a security perspective, it is a nightmare. It represents Donald Rumsfeld’s infamous “unknown unknowns” statement regarding the lack of evidence linking the government of Iraq with the supply of weapons of mass destruction to terrorist groups.
Alan Robertson, an open source developer and high availability expert, likes to ask people how long it would take them to figure out which of their services are not being monitored. Typical answers range from three days to three months. The irony is that the converse is easy to figure out, so it should be easy (famous last words) to determine the difference between the list of services being offered and the list of services being monitored. But as the story above illustrates, it is not always easy to figure out what is running, much less whether or not it is configured properly.
Fortunately, Robertson has been working on a solution to this problem in the form of the open source Assimilation Project. The Assimilation Project performs service discovery and inventory of your systems in great detail and stores the resulting data so that it can be queried. Once the data has been gathered, Assimilation compares the state of the system against a set of IT Security Best Practices. By default, Assimilation uses DISA/NIST STIGs, but you can define your own and/or opt out of Best Practices that are not applicable to your situation.
Conveniently, Robertson has written a series of blog posts to describe how to get up and running quickly with the Assimilation Project:
1. Fifteen Minutes to Better Security
2. An Hour Towards Better Security
3. A Half-Day to Better Security
The Fifteen Minute article leads you through the steps of downloading the automated install script to install the Assimilation Project and its dependencies. I will admit that this took me longer than fifteen minutes because I took the time to read the script before running it as root. I recommend that you do the same.
The Assimilation Project depends on Neo4j, so next you start the database, the central service, and the inventory agent. Once the discovery and collection is completed, which only takes a few minutes, you can produce a snapshot of a single system. My test system looked like this:
The thick red bar vividly indicates that this system does not adhere to the recommendations for secure configuration described by the DISA/NIST STIGs.
At this point, you can start to issue a variety of queries against the database to see what else you have discovered. The full list of queries is available by issuing the assimcli query list command. To see the full list of IPs that the system has interacted with, issue the command assimcli query allips. On my test system, that results in the following short list (tabularized for readability):
You can infer from t
he reference to CADMUS COMPUTER SYSTEMS that I am running the test instance on a VirtualBox instance. From the rest of the entries, you can infer that I have a very simple system which has few, if any, defined hostnames and that the nanoprobe agent has been running for a very short period of time. A production network will have a much longer list of IPs with a richer set of information associated with them. Any time a new IP is used on the network, it gets added to the list, so the list will grow over time. This is the beginning of discovering what all you have. The Assimilation Project can expand from this single system into monitoring all systems to which you have access.
In part three of Robertson’s series, he describes how to remotely install the nanoprobe agent onto other systems in your network. The nanoprobe sends the collected configuration data to the CMA server, so that you can continue to visualize the services offered in your network as described above. In short order, you can have complete visibility to not only the systems and services running on your network, but also their configuration and where it stands in accordance to your desired configuration.
I will leave you with another slightly mangled quote from Rumsfeld, “You go to war with the [systems] that you have, not the [systems] you might want or wish to have…” The Assimilation Project provides one way to make sure that you know what you actually do have.
