The idea of a configuration management database (CMDB) is that it should be able to tell you all the interesting attributes of your environment. It’s not hard to imagine that just the right CMDB could be a great help in securing your systems and improving your security posture. In this article we’ll look in more detail at what a Security-Oriented CMDB (SOCMDB) should look like – and why you should care.
If you manage, secure, or plan for IT environments or DevOps, we’d love for you to take our System Management survey. Right now, we’re busy planning on how to make the Assimilation Suite better in 2016. Your responses will be a huge help in giving us a sharp focus on how best to improve IT management for you and others in the IT community. If you can help us out, we’ll send you a small token of our appreciation
On January 2nd we put out version 1.1.2 of the Assimilation System Management Suite – the Happy 2016 release. This release adds enhancements related to best practice analyses and adds support for openSUSE, Scientific, and ScientificFermi Linux – along with a few bug fixes. We also have some surveys that we’d love for people to take – to help direct us in our future work.
As we have in the past, we offer supported free trials of the Linux version of our system management suite – just follow the download link and the instructions you’ll find there.
Those of you who’ve been following my blog for a while know something about the Assimilation System Management Suite – how it provides an always up-to-date CMDB, integrated monitoring, continuous security monitoring, and an up-to-date network map – in an incredibly scalable way with near-zero configuration – and how it does all this without setting of network security alarms.
If you haven’t given it a try yet, now is the perfect time – because we just announced version 1.1.0 of the Assimilation Suite, and to celebrate we’re offering a limited number of supported free trials.
I just got an email from Bernd Erk, saying that the 2015 Open Source Monitoring Conference is filling up. From my perspective, that’s a good thing, because we have a great talk and demo to give there and are excited to be speaking there again. From your perspective, this may be a good thing only if you hurry up and register – since this is the only conference we’ve spoken at outside the US this year.
CMDBs have a bad reputation in many circles. They are seen as expensive, have been associated with costly IT failures, high overhead clumsy processes, are reviled by some, and are thought to be incompatible with DevOps. In my opinion, they don’t have to be that way. The idea of a database that knows everything about your IT environment, replaces manual documentation and springboards automation is incredibly attractive. What would a CMDB look like that is easy to install, and easier to maintain – one that followed the DevOps mantra of automating everything? This post explores that question.
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.
After a few mental missteps documented by previous blog posts (here and there), this is what I think of as a pretty reasonable approach to packet encryption in the Assimilation Project. Although those two posts are now obsolete, the background post I wrote is still relevant. I’ve learned a lot about crypto in the process […]