In this article I give my view of how well the Assimilation System Management Suite CMDB meets the criteria of an security-oriented CMDB (SOCMDB) – answering the question – “How useful is the Assimilation CMDB for security?”.
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.
In a couple of earlier blog posts, I wrote an article about what characteristics would make a CMDB suitable for a “modern” DevOps-like environment. The first article talked about what characteristics one would like in such a CMDB. The second article evaluated the Assimilation Suite in terms of those characteristics. This article discusses how a CMDB can improve your security posture.
In today’s blog post, I’d like to do something similar – but looking at a CMDB from a security perspective. That is, this blog post is the first part of a discussion of what a security-oriented CMDB ought to look like and how it can improve your security posture.
About a year ago, we created a security roadmap for the Assimilation Project. It’s time to update it and see how we’ve progressed since then – hence our Assimilation 2016 Security Roadmap. The Assimilation Security software concentrates on low-noise automated security tools. We expect to enhance our capabilities in best practice analyses, checksum integrity analyses, patch […]
One of the keys to good software is good testing. There are well-known testing suites for back end code – things like junit and py.test. There are also good front-end testing tools – things like Selenium. But for testing distributed systems there aren’t so many well-known tools – because the problem is quite different, and harder. In this blog post we’ll cover the “Fuzzy Monkey” methodology used for testing three different successful distributed systems (including the Assimilation Suite) – its history and how and why it works.
I just got back from the 2016 DevOpsDaysRox conference last week. I’d like to talk a little about my presentation on the Assimilation suite from the cybersecurity perspective, and how what I learned and heard at the conference will influence future Assimilation development – particularly regarding Docker. After the conference, Docker even entered my dreams, morphing into how best to support it in Assimilation. It was a bit surreal, but so was giving my talk – which I’ll explain a bit later in this article.
Last Thursday, I had the privilege of speaking at DevOpsDaysRox (Rockies) at the Fortrust data center in Denver. A bit weird speaking in undeveloped space in a data center, but somehow fitting for a DevOps conference. The talk was about 10 minutes worth of talk (slides on speakerdeck), and about 20 minutes worth of live demonstration. The live demonstration covered some of the same things that I’ve covered in our blog before.
In this blog post, we’ll examine a few security best practices around group, password and shadow files – and evaluate the IT Best Practices rules and see why and how they have to be modified slightly for Debian-based systems when we implement them in the Assimilation suite.
In previous articles we gave some introductory material on how to get started with the Assimilation software for security. In this article, we go into more depth and suggest a good way to improve your security by spending a half-day with the Assimilation software. We cover setting up email alerts for security changes, fixing your security issues, and setting up the Assimilation software on more systems.
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.
According to Verizon, there’s an 71% chance that you are already out of compliance with your security guidelines – assuming you complied with security best practices in the first place. If not, the chances are higher. A few weeks ago, we did a security survey. I’ll share a little of that data, and how people’s perceptions seem to be out of line with the Verizon study.
