The Assimilation System Management Suite (ASMS) provides integrated capabilities in monitoring, general system management, network management, and cybersecurity. The next few releases will concentrate on strengthening our cybersecurity portfolio of low-noise automated security tools. The new capabilities include security best practice analyses, checksum integrity analyses, and patch tracking and management and integration with a few SIEM products. This post talks about our plans for those releases in more detail.
Getting into security compliance is a big effort. Worse yet, Verizon says 80% of those who get in compliance have trouble staying there. When you discover you’re out of security compliance, there’s typically high drama if an auditor notices, or even higher drama if your security team discovers you’ve let an intruder in. Too much drama and too much elapsed time reduces security and impairs organizational learning.
What’s needed is a way to find these problems right after they’re created – while the people involved still remember what they did and why they did it. This changes the whole dynamic and creates teachable moments instead of high stress drama – before an intruder or auditor finds the weakness.
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.
Getting your organization into security compliance is a lot like eating an elephant. It’s a daunting task, but there’s really not much you can do but eat it one bite at a time. A recent Verizon survey indicated that 80% of all organizations surveyed indicated they have trouble staying in compliance. For these organizations, they get to eat that elephant again and again – and worse yet, under the critical eye of an auditor. Once you eaten the elephant, you don’t want it to become an annual event.
Computer security is problematic today, is expected to get worse for years to come. The security field is widely acknowledged to be suffering from a shortage of qualified security experts. Many people believe that significant improvements in automation are the only way to address this growing problem. Compared to the level of automation that system management has experienced in recent years, security has been estimated to be at least a decade behind.
Our IT Best Practices community was created to help support security automation efforts. We aim to collect, categorize and curate mechanically-verifiable best practices for servers, services and networking, in support of the idea of “best practices as code”.
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 […]
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.