Last weekend, I had the honor of giving the opening keynote on Friday at the 2015 Ohio LinuxFest and a session presentation on the Assimilation project the next day. Both talks were very well-received, but the reception the Assimilation project talk received from the standing-room audience was extraordinary. So it seems good to give a summary of the talk and why I think they resonated so strongly to it.
Over time I’ve had a number of people ask me why I wrote the Assimilation System Management Suite. I wrote this blog post to answer that question. Since I’m a techie at heart, this is a story told through a technical lens.
Although this article and title are a bit tongue-in-cheek, the reality behind the title is serious. In the average data center, 30% of their servers are mainly space heaters [they had their brains eaten ;-)]. Given that many data centers are strictly limited on power, cooling and floor space, and that power and maintenance are significant costs, this is a big deal. This happens primarily because the staff managing those servers have don’t have a clear idea of what all their servers are doing.
One of the key things that make DevOps deployments possible is more automation to make things more reliable. These tools include things like Jenkins, Ansible, Chef, Puppet, SaltStack, and even tools like Hubot, and concepts like Infrastructure as Code, Test Automation, and Test Driven Development, Continuous Integration, Continuous Delivery, and ChatOps. These tools have changed the face of system administration in the last decade. Unfortunately, security automation has lagged significantly behind the DevOps movement.
There is incredible power in asking the right questions, and following the answers where they lead – especially when they lead to uncomfortable places.
As you probably remember, in March, 2011, a magnitude 9.0 earthquake hit Japan resulting in a massive tsunami which damaged the Fukushima nuclear power plant. Some of the most serious damage occurred because there was no power to cool the reactor.
We fill our lives with things designed to make them easier… In many cases, these things we get to make our lives easier wind up making it more complex. Nowhere is this more apparent than in IT. We have so many choices of ways to create services, to deploy them, and to manage them. I’ve been extensively involved with high-availability work since 1998. One of my mantras in high-availability is “Complexity is the Enemy of Reliability” – and so it is. If you add parts to a thing, more things will fail – period. In high-availability, we add high-availability software – which makes it more complex, and hence less reliable. But we get something back instead – improved availability.
In this article, we talk in more detail about the Assimilation Project’s reliable UDP protocol, our decision to avoid session keys, factors influencing our initial choice of crypto libraries, and touch on key revocation. So, like before we’re looking forward to your comments on our design choices. Like before, grab your thinking cap, sit down with your crypto buddies and think hard about what we’ve done.
This article outlines our approach to keys and key management given our unique problems in a pragmatic and effective way. Although we will use crypto libraries with well-proven algorithms, we will use them in slightly unconventional ways. So, get your crypto buddies, grab a beverage (adult or otherwise), put on your thinking cap, and think hard about how we’re planning on approaching these challenges. Although I’ve tried to think all this through, I’m not a crypto expert – which is why I’m asking for your help.
Since its inception, the open source Assimilation project has been concerned with security, and paranoid at every opportunity. Like a lot of software, it has serious security concerns. On the one hand, our nanoprobes run on every server in the enterprise and exercise root privileges – creating a potentially dangerous attack surface. On the other hand, we incrementally create a high-value database which has fine-grained and up-to-date information about everything in the environment – software versions, ports, services, IP addresses and MAC addresses, known security vulnerabilities – a veritable treasure map for an attacker. This article details why cryptography is essential for communication in this environment, and some unique aspects of the problem we’re solving that affect how we use it. It is our hope our readers (this means you!) will give us a thorough flogging^H^H^H^H^H^H^H review of how we use cryptography in our software in this article and the next.
We are proud to announce the latest in our series of releases of the Assimilation software which will culminate in an incredibly useful production release. This release is eminently suitable for trials in an environment where the caveats are acceptable. We have quite a few pre-built Ubuntu packages, and a few CentOS/RHEL packages – so go forth, download and subdue the galaxy!
