Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
You might already know them from theagileadmin.com, but let me introduce you to two of the leading minds in the Rugged DevOps movement: James Wickett and Ernest Mueller. Both James and Ernest are active leaders in the DevOps space, in addition to helping organize events such as DevOpsDays Austin and LASCON. Our conversation covered a lot of bases from the founding of Rugged DevOps to aligning organizational silos to lessons learned from W. Edwards Demings.
Wickett: Hi, I’m James Wickett. I work over at Signal Sciences. I’ve been doing stuff in the DevOps space for quite a while and am interested in security as well.
Mueller: Hello, I’m Ernest Mueller. I work at AlienVault. I’ve also been in the DevOps world for a long time. James and I have worked together a lot in the past, and we blog together at the agile admin.com.
Weeks: There is a lot of conversation going on around Rugged DevOps. Is this the end of traditional security as we know it, or is there a place for what security has been doing all along to coexist with some new ways?
Mueller: Certainly. Every field has to continue to innovate to survive. And InfoSec is no exception. IT operations is no exception. The reason that we attend the RSA Conference and that there is a DevOps track is because IT infrastructure operations and systems professionals have the same issues. Right? The long lead times, bottlenecks, not being well-aligned with your customers. And we managed to find a way out of that using leading principles, using agile principles, to where we could improve the state of things.
Can the old coexist with the new? It certainly can for a time. I think, though, there is an extent to which the new modes of thinking in the end have to be adopted or you die out, right. You’re still doing your core thing. You are providing IT operations or you are providing security, but the way you do that has to change and keep pace with business demands.
___
Every field has to continue to innovate to survive. And InfoSec is no exception. IT operations is no exception.
___
Wickett: We talk about this in our presentation on lean security here at the conference. It is not so much of a question of “replacement” or “is traditional security going to be around longer?” It is just going to look a lot different.
The really cool thing (and what Ernest mentioned as well) is we both worked together in operations shops in the past. That was five or eight years ago when operations was then where security is now. Operations today looks dramatically different than it did 10 years ago. I think the same thing is going be true about security. (See slides from Ernest and James.)
Weeks: When I talk to a security audience about how they interact with development, they are like, “Ah, we have no access to development.” When I speak to development communities about security they are like, “Ah, don’t let those guys in the room.”
Part of the Rugged DevOps conversations is not only how do you bring security into development, but how do you bring it in early enough into the development life cycles. How have you been able to bring security in and bring it in early?
___
Operations today looks dramatically different than it did 10 years ago. I think the same thing is going be true about security.
___
Mueller: Again, this is one of the core problems that DevOps faced at its initiation, where that exact same dialog occurred between developers and operations.
There are a number of techniques you can use. But what you have to understand is that you are looking at an underlying culture change. There is no silver bullet for that, and so it can take years. But aligning both the people that are trying to do the work and the management that is trying to organize it to understand—that sort of close collaboration throughout the entire pipeline is what’s important.
And there are some times where you have to power through it. I remember early on in our DevOps implementation at National Instruments. We had started having design reviews with developers and operations personnel that were in the same room. The application architect approached me and said, “These guys keep asking us questions that we don’t really even understand or know the answers to about capacity or about reliability. Maybe we should just have separate reviews.” I said to him, “Well, you have two options. We can continue to do them separately, and we can continue to not understand each other. Or, we can do it together and power through it. And it really shouldn’t take all that long before we do start to understand each other because we all have the same goal, which is to ship these products.”
___
I said to him, “Well you have two options. We can continue to do them separately, and we can continue to not understand each other. Or, we can do it together and power through it.”
___
So we powered through it, and it really didn’t take that long for everybody to finally get to a good point where they could understand and collaborate with each other. But it took determination to get there.
Wickett: I think that was really, really well said. We are having that conversation where we’re saying we do need to shift left. We are saying we do need to make it earlier. We’ve kind of seen the writing on the wall. How do we get there?
I think there are some practical approaches. We are just taking small steps. I have seen people do this at different organizations. There have been a lot of talks on this. But when putting security into your continuous integration in your delivery chain, I think there is a huge gap.
I work at Signal Sciences so it is one of the things we do. But there is a huge gap in the operations knowing whether we are under attack, why are they attacking and what are they trying to do. Right? And I am not saying you need to buy our product to get that done but there is …
Weeks: I’ll say it. You do need to buy his product.
Wickett: Good, please, say that.
But it’s amazed me how often shops have no idea what’s actually going on. They don’t really know what parts are being attacked. They don’t know what’s happening on their site. They don’t have any sort of security operational telemetry coming back to developers or to management.
As we’ve seen in lean, those are the invisible things. You’ve got to make them visible. I don’t know what that’s going to mean for people’s organizations. I could make a bunch of random recommendations, but take the principle of making those invisible things visible and start trying to apply it.
___
Take the principle of making those invisible things visible and start trying to apply it.
___
Weeks: Building on that: Part of the whole discussion around DevOps is rapid feedback loops. How do you get information from people as quickly as possible so that they can be informed and take action on that?
Mueller: Absolutely. Well, I think we’ve seen a lot of fledgling successes in that area. James is the core contributor to an open source product called Gauntlet that introduces security testing into continuous integration processes. We’ve seen presentations at other conferences, from Twitter and from Etsy, where they’ve built these security warning systems very, very early on that notify the people that are actually creating the flaw as they are creating it.
W. Edwards Deming said that we can’t ensure quality by mass inspection after the fact. We have to build integrity into the product as we create it. Unfortunately, a lot of security thinking today is built around mass inspection after all of the mistakes have already been made and then trying to go back and get somebody to do rework of a product that has already shipped, that’s already making money, that’s already out there in customer deployments, whatever. That’s always inherently going to be a much more difficult route at ensuring actual security.
___
We can’t ensure quality by mass inspection after the fact. We have to build integrity into the product as we create it.
___
Wickett: In some ways, we’ve built this problem ourselves. We do compliance on an annual basis. Compliance is built around the waterfall mechanism, and security is a function of compliance or something that they try to accomplish. It’s very antithetical to fast feedback loops. It’s very antithetical to rapid cycles. So we need to find ways to break that down into more discrete chunks that can happen on a daily or weekly or hourly or per-code-commit basis.
Weeks: How did the rugged DevOps movement originate?
Wickett: Rewind to 2009 or so, and there are the first signs of DevOps kind of coming through. There is the agile operations thing. People were talking about velocity that year. The first DevOpsDays by Patrick Dubois happened. Flickr says that we’re doing 10 deploys a day. And just everybody loses it.
At the same time, Josh Corman came out with the Rugged Software Manifesto in 2010. I read that. And Ernest and I were both latching onto DevOps at that time, and we were trying to do some cloud-based implementations but really focused on the DevOps-centric vision around that.
We told ourselves, “We can’t just stop at Dev and Ops. We have got to have security.” And this is while we were taking a lot of telemetry data from Internet of Things (IoT) types of devices and thinking that’s going to need to be secure if we ever wanted to get a customer on that. So we really started to try to put that together.
___
We can’t just stop at Dev and Ops. We have got to have security.
___
We stumbled across the rugged stuff, and at the same time, we just really felt like rugged and DevOps were two things that were moving in different tribes. They were both trying to accomplish very similar-type missions. In Austin, we run the DevOpsDays event there. We have a lot of security folks in the Austin area. It’s the capital of Texas, so there are a lot of folks related to that.
It seems like the DevOpsDays we’ve had there have a very security-focused push every year, and the rugged language really struck more of a cord than security. To me, that’s a rough brief history of how that’s come about.
Weeks: James, you also run LASCON in Austin, which is a great security conference. It has a DevOps track where security and development or DevOps come together.
You are both thought leaders yourselves. But who else do you listen to? If you could tell someone reading this, “Here is someone that you should see at a conference or look for their video on YouTube,” who would you recommend?
Mueller: Obviously, the list of presenters here at the Rugged DevOps Summit is a litany of many of the best-in-class people to hear speak, whether it’s Josh Corman, John Willis or Damon Edwards. I could list the entire set. People that aren’t here, like Pete Cheslock, have done a lot in merging both DevOps and security.
Wickett: Throw in Nick Galbreath who I work with now. I really kind of saw him doing some of the same stuff, and I really dig that. Gene Kim, of course, would be a good fit.
I love learning from Patrick Dubois. When he speaks on anything, I am really interested in what it is. He is doing more mobile stuff these days but always good stuff there. Anybody else?
Zane Lackey, too. I also work with Zane.
Weeks: That’s a great list. Thanks!
Hey, DevOps Austin is coming up in the beginning of May. Is the call for papers still open?
Mueller: That’s right, the 2nd and 3rd of May this year.
The DevOpsDays Austin call for papers is open, call for sponsors is open, and tickets are being sold, although early birds are sold out already, so I recommend that people move quickly.
We’re in our fifth year. The last couple of years, we have been filling up our venue at 500 people. We have actually moved venues to the University of Texas Darrell K. Royal-Texas Memorial Stadium this year, so we have a little bit more space, and we’re riding on more tracks. We’re riding on a hack-a-thon actually.
It’s interesting. One of the things you have to be careful about in this whole thing is not losing the developers.
___
One of the things you have to be careful about in this whole thing is not losing the developers.
___
People that were very involved in OWASP for a long time saw that started off as a developers and security sort of thing. And over time, unfortunately, that relationship was lost a little bit, and they’ve had challenges as a result.
Now we are like, “How do we get the developers back collaborating with security?” We’re trying to make really sure that there is a lot of interest in DevOps out of the operations space, and so that can sometimes start to push out the content the developers find compelling.
We’ve added a content tract and a hack-a-thon to try to make it super compelling to developers this year.
Weeks: Excellent. James, I think you guys just secured a Series A. Is that right? Should we tell people you are hiring at Signal Sciences? Is AlienVault hiring too?
Wickett: Yes, I think Signal Sciences is hiring both in the L.A. area and across a lot of remote positions. The engineering team has a number of remote members.
Mueller: Absolutely, we are hiring too. We have teams in Austin, out here on the West Coast and in Ireland. Our original office was in Madrid, Spain. So we have a lot of folks there if we have any international readers on the blog.
Weeks: Excellent. Perfect. I appreciate you guys spending time with me. Absolutely enjoy the conference, and we’ll point people to the recording of your session as well.
Wickett: Cool.
Mueller: Super.
Wickett: Thanks, Derek.
Weeks: Thank you very much.
If you loved this interview and are looking for more great stuff on Rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The Seven Habits of Rugged DevOps.”
As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”
