I attended the DevOpsDaysRox (Rockies) conference last year, and it was a great conference – great speakers, interesting people at the conference in a good venue. This year, I’ll be giving a talk at DevOpsDaysRox 2016 – about the intersection of DevOps and security. This is a challenging space, since security has trouble keeping up with “normal” IT, […]
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
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.
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.
I’ve been asked to give the keynote address at the 2015 Cascadia IT conference. For my keynote, I’d like to tell stories of their contributions – large and small – and how they helped and how they were uniquely valuable. Although I have a number of stories of how various IT admins (system, network, security, etc.) have contributed to my projects (Linux-HA/Pacemaker and the Assimilation Project), I’m looking for more. This post is a request to send me your stories of how IT admins have contributed to open source projects in large or small ways.
Share a link to this post to your friends and your favorite social media sites!!
