Securing your systems is a daunting task – it feels like eating an elephant. When compared to hardening guidelines like the DISA/NIST STIGs, a single out-of-the-box system can have a hundred or more issues. When you multiply that by a large number of systems, despair and paralysis can easily set in. This article (fifteen minutes to better security) is first in a series which outline a process for efficiently measuring, triaging, and managing your journey towards a better security posture for your servers.

No matter your threat model, you need to understand what you have (“know yourself“). We help you begin this journey with activities which will teach you a surprising amount about your current status and the work ahead of you in 15 minutes. This article is not designed to teach you about security – I assume you know why you want to secure your servers, and have general background in system hardening.

Fifteen Minutes To Better Security

The First Six Minutes – Installing the Software

All of the activities are based on the Cybersecurity component of the open source Assimilation Suite. Unsurprisingly, the first step in our fifteen minutes to better security is to install the software. To get started, I recommend starting with a system with Internet access which has a recent version of Debian, Ubuntu, CentOS, Redhat or Fedora Linux. For CentOS or Redhat, I recommend you start this exercise with version 7. Although CentOS 6 will work, some things are trickier later on. Although the Assimilation code scales into the 100K server range, because of the 15 minute time constraint, everything we do will be on a single server. For these examples, I’ll use CentOS7.

The easiest way to do that is to use our installer script on a suitable test machine. We can typically get more information from bare metal than we can in a virtual or cloud environment – but it will work fine in any of them. During these exercises, I opt for getting it going quickly over doing it the right way for production – because the purpose is to have you quickly see what you can learn from these tools. Over time, you’ll want to use your normal installation system for production use. The first step is to download the installer like this:

wget https://github.com/assimilation/assimilation-official/raw/master/buildtools/installme 
chmod 755 ./installme 
sudo ./installme cma

The Next Few Minutes – Starting it Up

The next step in fifteen minutes to better security is to start the software and let it collect data. There are three pieces to start – the Neo4j database, the central (CMA) server, and the nanoprobe client process. I’ll start them here the same way I do for a demo – so you can see more of what’s happening than a normal startup.

Starting services

sudo systemctl start neo4j # start the database
sudo cma --foreground &    # start collective management authority
sudo nanoprobe --dynamic   # Use an ephemeral port

Once you’ve done these commands, the CMA should start printing a variety of output to the screen – indicating what it’s doing.

At this point the output will look a lot like the annotated demo that you can find on our web site. The annotations on that page cover what’s happening in great detail. A summary of what will be happening:

• The nanoprobe connects to the CMA, and provides it a small bit of discovery information.
• The CMA tells the nanoprobe to discover certain things about the system.
• The nanoprobe runs the discovery actions the CMA gave it and sends the results back
• The CMA puts the data in the database, and sends back additional discovery actions for at least two things:
  • checksums of network-facing binaries, libraries and JARs
  • the permissions of the audit log directory (typically /var/log/audit) and the files in that directory.
• The CMA matches the services against templates for monitoring and sends the nanoprobe commands to monitor services
• The CMA compares incoming discovery data against best practice data and prints out the failures and scoring updates
• The last messages before going quiet typically look like this:
• UPDATING CHECKSUM DATA for nnn files, followed by some output indicating that the monitored services are up that typically includes something like this: MESSAGE: Service servidor:nagios:check_load::xxxx is now operational.

Once you see these messages, your Neo4j database (CMDB) has an incredible amount of information about this system. Some additional network data will arrive over time, so we’ll look at that data last.

Quick Data Examination – 5 minutes.

The steps above should have taken right around five minutes, so we now have 10 minutes to actually get value out of the security date in our database. At this point we now have collected and organized a lot of data from this system. For our purposes today, we’ll just do a cursory examination of the data – which will you can do in 10 minutes or so.

Visualizing the Attack Surface

In an earlier blog post, I went through some detail about visualizing your attack surface. Here’s how to do that for yourself. Our drawwithdot command can draw several kinds of illustrations from the information in the database. For all of these kinds of illustrations it needs to use the dot command to do the actual drawing. The dot command comes from the graphviz package. If you don’t already have dot on your system, you’ll have to install the graphviz package now. To create and view the image all at once, this command line works well:

sudo drawwithdot --dpi 60 -d service | dot -Tpng | display

If you don’t have the display command installed, you can either install it, or save the output of dot in a file, then view the resulting PNG image with your favorite image viewing tool. Changing the –dpi setting will change the overall size of the image. Setting it smaller than 60 makes the text difficult to read. Creating this image only takes a few seconds. Studying and understanding this diagram may take you a few minutes. The meaning of all the symbols in the visualization was covered pretty well in the blog post I mentioned earlier. If you’re like me, you may wonder why some are running as root that don’t need to, or why some services are running at all.

Checking Your System Against Security Best Practices

The next thing we’ll do is to compare your system against a set of security best practices from the IT Best Practices project – which we’ve talked about before. This will help you see how to better harden your individual systems. You could view this as basic security hygiene. The IT Best Practices project takes many of its best practices from US government security best practices called STIGs. Although the ITBP project takes advantage of these freely available rules, it is more agile and less bureaucratic than the US government. Our goal here is to help your secure your systems while avoiding additional bureaucracy. As an additional disclaimer, we’ve only implemented about 70 rules as of the time I wrote this article. Eventually we’ll get to all of them.

Having issued that disclaimer, let’s get back to work ;-). To find out what all the best practices scores for the systems are, issue this command:

sudo assimcli allbpscores

This command will output a line which looks like this
 security=31.0   networking=1.0  <your-system-name-here>

This outputs both the security and network best practice scores for your machine. The security score can be thought of as a risk score. In other words, lower numbers are better than higher numbers. If the system is following all the best practices that we know about, then it’s risk score would be zero. Of course, that doesn’t mean it has zero risk.

Here’s an analogy about hardening and the risk score that you may find helpful. What we’re doing here is making sure all the doors and windows of your house that we know about are closed and locked. We’re not telling you that they will keep out a determined burglar.

Of course, overall security scores are nice, and one over the whole site is really helpful to see how you are improving over time, but they don’t tell you where the problems really are. For that, we’ll drill down with some other tools in our next installment.

By the time you explore your attack surface, and perhaps play around with the Neo4j browser (localhost:7474), you’ll likely be over the 15 minute mark, and you’ll be ready for the next exciting article in the series: An Hour Towards Better Security.