"Defense In Depth" with DevOps--make that SecOps

 SecOps

I think (I hope!) we all know by now that Security failures are legion. An ad hoc or reactive stance on behalf of security is risky--not only in business terms and costs of operating, but increasingly executives are being held to account in civil and criminal courts for security failures. Business leaders that take a lax attitude toward security are going to get burned. A weak security posture will be exploited. It's a certainty. 

 

Effective security measures require Defense in Depth. Multiple people, processes and applications dedicated (in whole or in part) to security are needed in order to maintain a reasonable position to defend, detect and investigate attacks. As environments grow the number of systems that need to be protected grows. The only way to keep up your defenses in a large and/or growing environment is automation. In 2015 the term SecOps began to get wide use. Like DevOps, SecOps is concerned with Configuration Management, Monitoring and Communication. And as with DevOps, SecOps requires a high degree of automation. Many of the automation tools of DevOps can serve a dual-role and help achieve the objectives of SecOps. 

A comprehensive list of security domains that need attention for an adequate Defense in Depth includes:

• Firewalls
• Access Management
• Encryption and Key Management
• Anti-virus
• Scanning
• Maintain Secure Systems and Applications
• Logging
• Policies and Procedures

DevOps can take a primary role or assist in many of these concerns. Principally, Server Configuration Management (SCM) plays a key role in both DevOps and SecOps.  From a SecOps perspective, SCM will help deliver on they key requirements of maintaining secure systems.  The goals are different for SecOps, but all of the benefits of SCM as described for Automation are also benefits for SecOps:

• Central Management
• Homogenous System Configuration
• Homogenous Configuration of Firewalls and Network Devices
• Systems Patched with the Latest Updates

Specifically, these benefits contribute to the security objective to “Maintain Secure Systems and Applications.” In fact, as environments grow, the only way to securely management is with an SCM. So how do these SCM benefits impact security? The unabridged explanation covers all the same ground as the benefits of SCM for managing server farms and clusters. The same problems of time-consuming system management environment complexity, system drift and non-homogeneity of systems, and systems that are not patched consistently all effect security. Getting all of your systems (and networks) under one umbrella with the ability to quickly and consistently update them via automation is key to holding the security line against attackers.

Additionally, SCM will assist in these other objectives for a secure environment:

• Access Management
• Anti-Virus Installation and Configuration
• Encryption and Key Management
• Logging Installation and Configuration

In the case of Access Management, an SCM might provide direct support for the management of accounts and keys, or it may only be providing a supporting role. For the other cases, SCM will aid in the deployment and configuration of these applications and tools. SCM will deliver anti-virus software, encryption keys, and logging configurations. Logging is critical for investigating security breaches. Maintaining backups of logs for one year is a requirement for PCI. 

Automation will increasingly address the concerns of policies and procedures. An SCM system will assist in the auditing of policies and procedures. Security must be continually evaluated at all levels of the organization including automation. Auditing is part of a continual feedback look designed to maintain and improve security. It is a significant part of regulatory compliance, certifications and direct customer or vendor inspection. Increasingly companies are being held accountable and incurring downstream liability for companies that interact with them as partners or providers. This is increasing the frequency and comprehensiveness of audits being performed by customers or partners. 

Inspiration: Why finish that book about DevOps?

Eight years ago, I had a burst of creative energy and wrote a draft of a book about DevOps. Here I am now, eight years later, looking at the remnants of the book that I didn't quite finish. A lot went into getting a draft of a book written, and it turns out that a lot went into putting off finishing that draft. Here are a few things that went wrong:

• I listened to advice

At a certain point in my book writing, I heard from friends suggesting I should talk to people who had already published a book or were professional writers. You'd think this advice from experienced people in your extended circle would be helpful, but that wasn't the case for me. Looking back, all I really needed was some encouragement to finish writing. What I got was worries about all the things I "should" do. I should "build a platform." They also told me things to "don't" do. "Don't self-publish!" "I should sell my book to a publisher."  The best (worst) advice I got was, "Don't write a book. Package your content in bite size chunks for digital media." 

This advice exacerbated a problem I already had--I was trying to do too much in one book. Ultimately:

• My narrative lost focus

An excerpt from the abstract for my book will demonstrate what I mean:

DevOps is the convergence between Development and Operations, making the Internet, how it is developed, and how it operates, more efficient, effective, and secure. Amazing convergences are emerging between science, business, culture, and politics; DevOps is one of them. “Talking about music is like dancing about architecture” will no longer be a hallmark of inane comparisons, but a harbinger of new ways of seeing and doing.

I like how it starts with a definition of DevOps. But, there's too much going on in this paragraph. It's a big jump from Development and Operations to "convergences" across the entire spectrum of our collective experience. And what about this bit, “Talking about music is like dancing about architecture?” Here's how far I stretched for that. Around 1991 at the University of Kansas, Laurie Anderson gave a lecture (attended by William Burroughs). I was an AV guy in the theater where she gave this lecture, and in truth, I ran the AV for her lecture. Laurie Anderson made the comparison, “Talking about music is like dancing about architecture.” It stuck with me. But maybe including it here was an inane comparison? 😔

Meanwhile: 

• DevOps was changing in real time

The novelty of DevOps was wearing off. A lot of work was coming out about DevOps, and books were being released that were filling the same niche I was targeting. DevOps, as a phenomenon, changed significantly in the course of my writing. New constructions of DevOps emerged: DevQAOps, DevSecOps, or even this mouthful, DevQASecAuditOps. I tried to incorporate some of these emerging variations, but ultimately, I fell behind the eight ball, and: 

• I gave up

So here we are, eight years hence from a failed book writing attempt and I'm ready to give this another go. And why would I pick this project back up? Well, maybe I'm just a glutton for punishment, and I'm setting myself up for giving up (again!) on a project. But, I think there are good reasons to give this another go. Firstly: 

• The DevOps phenomenon continues

DevOps is no longer a new buzzword. It has evolved into a lot more than a nifty idea: it's processes, tools, skills, business functions, jobs, in short, a market. It's also become an important aspect other activities and goals, like QA and Security. The DevOps impact will expand and include other business functions, like Governance, Risk and Compliance (sooner than some may realize).

And in some cases, expected (or wishfully hoped for) outcomes, never happened. Some thought making Ops more like development would bring about the end of Ops (i.e. NoOps) . And while it is true that these days a developer can do more with less need for dedicated Ops, Ops has not gone away. On the contrary, the need for constant operations in application service (SaaS) environments and complex interactions with 3rd party systems has expanded the surface of Operations. On the Dev side, things are also changing. Advances in software development and tools like GenerativeAI, are actually lowering the barrier of entry for an increasing number of  Development activities. Instead of DevOps becoming synonymous with NoOps, maybe DevOps is becoming synonymous with NoDev! 

Finally, I've changed:

• I know more about myself

I have a better sense of myself and my purpose in writing this book. I always had a good idea about my intentions, and I think I captured it well:

The Internet has been the engine of my professional career. I have 20 years of experience in San Francisco and Cambridge at software companies that have helped make the Internet what it is. This book, my story, my DevOps trip, is a microcosm of the Internet during this epoch of the Information Revolution.

But expectations got in the way, and I didn't finish telling my story. I'm ready to pick myself back up, shake off other people's ideas about what I should be writing, and finish this book. And while I am at it, I will take the opportunity to make it better. In my first effort, I spent too much time trying to write to someone else's idea of my audience. I struggled with how technical to make it. I shied away from including old work controversies because I imagined they might offend friends and former colleagues. On the other hand, my past companies:

WebLogic

BEA

Kenamea

Banta Integrated Systems

RR Donnelley

Axeda

International Data Group (IDG)

gave me stories to tell. Now with a little more wisdom (I hope!), I'm ready to just tell my story, and let any reactions that may (or may not) come fall where they may. So, here's to 2024 and new (old) goals! Stay tuned!

DevOps weighs more than Dev and Ops

Time flies and some things remain--including old blog posts. From eight years ago:

Why write a book about DevOps?