I’ve been immersed in cybersecurity for a good stretch, since it was known as just “infosec” and “security.” Over time, I’ve had opportunities to work with some brilliant minds and young-gun “hackers” (I’m not a name dropper, so I’ll refrain from using them as SEO-bait). I’ve watched attackers transition from being basement-dwelling teenagers to organized intruders to APTs. At one point or another, I’ve met all of Five Horsemen of the Internet Apocalypse: Scam, Extortion, Embarrassment, Theft and Death.
The biggest cybersecurity news story of all time is still Edward Snowden. Fancying himself a “whistleblower,” champion of the Constitution and privacy rights expert, this fugitive data thief accused of espionage by the United States government has done more to force businesses and individuals to think about digital security and privacy than anyone or incident before him.
Snowden aside, there are thousands of other stories about just how fragile our online lives and businesses are. If you were at the devopsy.kinsta.cloud Rugged DevOps event at RSA 2015 and caught the presentation by Wired cybersecurity and privacy writer Kim Zetter, “2015 — The Year in Hacks,” then you had a chance to get a great overview of some of 2015’s biggest digital crimes. You might have even noticed the Internet Apocalypse Horsemen riding through.
With an ear to the ground on everything the NSA and APT-using hackers are guilty of, @KimZetter never fails to intrigue readers and live audiences. Whenever you read her stories or listen to her speak, you always walk away reassured that when all the smoke and headlines have cleared, the great deep-down reality is that everything we digitize is subject to the whim of Scam, Extortion, Embarrassment, Theft and Death. If you didn’t have a chance to attend, please enjoy some of the highlights listed below.
China vs. U.S., Spy vs. Spy
She kicked off with the biggest hack of 2015: the one that penetrated the U.S. Office of Personnel Management (OPM). The full extent of the damage done and who the actual attackers were may never be fully realized. Were they Chinese spies, rogue hackers or a combination of both? What we do know is that it exposed millions of identities tied to covert U.S. operatives and their family members listed on security clearance forms. It may have even exposed personal information on everyone who has ever applied for a job with the federal government. One for-sure lesson is that even after several decades of security product development (with more than 800 available for review at RSA), the world is still in need of innovation in the space.
Men Behaving Badly …
Some might argue that Embarrassment made a special appearance at Ashley Madison, but the fact that suicide was part of that hack leaves me to think that Death was the lead actor there. @KimZetter pegged the data theft as the most brazen hack of 2015. With 30+GB of account information stolen and dumped, login credentials for 32 million accounts purloined, credit card transaction information accessed and even several suicides tied to the incident, the hack again reminded the world that the great deep-down reality is that everything we digitize can be used by attackers to scam, extort, embarrass, steal and even kill us.
From the Keyboards of Babes …
Anyone at the presentation must agree that Embarrassment really stole the show in the hack of CIA Director John Brennan’s AOL email account. Allegedly perpetrated by a teenager, Zetter describes the incident more deeply in her October story: Teen Who Hacked CIA Director’s Email Tells How He Did It
Keep Calm and Internet On
Anyone reading this may be walking away with a rather pessimistic view of our chances of remaining secure online. The truth, however, is that the existence of determined hackers should do no more to stop individuals or businesses from going online than road rage should to prevent anyone from getting behind the wheel of a car.
If any lesson can be learned from news articles pumped out by @KimZetter and her peers, it’s that the world should continue to take full advantage of the Internet but to also take the time needed to apply effective security. Quite simply, we all should keep calm and Internet on …
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.)
https://www.youtube.com/watch?v=D6TnKUWPqvg
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?
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.”
Carwash is a Rugged DevOps SaaS solution developed by Blackstone Technology Group and the Department of Homeland Security. The new DHS policy requires all mobile application developers to use Carwash when proposing, developing, implementing or changing any OHS Mobile Apps
Arlington, VA (PRWEB) April 13, 2016
Blackstone Technology Group (Blackstone), in partnership with the Department of Homeland Security (DHS), is proud to announce that Carwash has received the DHS Chief Privacy Officer’s seal of approval and is now required for all mobile application development.
Carwash provides a standardization of mobile application security across DHS. Blackstone and DHS’ partnership to design and build the application security framework has resulted in a valuable shared service to the DHS Enterprise that focuses on delivering secure and compliant applications to the Federal government and saves individual DHS agency components the time and expense of running their own security testing environment.
Carwash was initially developed in 2013 by Blackstone Technology Group in partnership with DHS to serve as a cloud-enabled framework for developers and teams to deploy safer applications. The solution reduces time to market and increases the security of applications by providing scan results to development teams throughout the SELC lifecycle. Identifying application vulnerabilities and issues early in the lifecycle reduces the risk of deployment delays and costly re-work.
“This is the first centralized mobile application scanning resource across DHS. There is a huge opportunity for security teams to use Carwash, and to share evaluations across organizations through the reciprocity report,” says Chris Drew, Senior Manager at Blackstone.
According to the new DHS policy, mobile app developers are responsible for, “Engaging and coordinating with the OCIO Carwash team to ensure that OHS Mobile Apps are sent through OHS Carwash process when proposing, developing, implementing or changing any OHS Mobile Apps.”
The Rugged DevOps solution Carwash is built on is capable of scanning more than just mobile apps and continues to evolve to include the latest technology and potential threats. Blackstone can tailor the framework to any app and just rolled out the ability to scan 3rd party Java libraries. “We have recently integrated this scanning solution within a pre-existing development process for two DHS agency teams,” says Anthony Glynn, Blackstone Architect and Carwash lead. “This empowers development teams to modify the version of their libraries to reduce vulnerabilities of the application and risk to the enterprise.”
Blackstone Technology Group (http://www.bstonetech.com) is a privately-held, global IT services and solutions firm founded in 1998 and headquartered in San Francisco, California. Influenced by disruptive technology of Silicon Valley, Blackstone Federal Services helps clients adapt to the demands of a digital world.
Established in Arlington, Virginia in 2002, Blackstone Federal Services has grown to over 100+ employees. With a specialization in Cloud, Cyber Security, Agile and DevOps, our experienced technologists bring digital expertise and innovative technologies to clients, faster.
Blackstone Federal has a proven track record of delivering results for many U.S. Federal Agencies such as Homeland Security, civilian and healthcare agencies. Our team members have received the Industry’s top certifications including AWS, CISSP, SAFe, PMI-ACT and PMP.
The unfortunate reality for today’s organizations is the fact that a security breach is bound to happen. Major breaches are happening with alarming frequency and fill the news headlines almost daily. And behind many of these major breach stories is a software vulnerability that has been exploited. There is a silver lining, however. Addressing security at the development stage can help organizations “get upstream” of certain issues, which goes a long way toward alleviating potential breaches.
Now there are always two sides to every coin, and this is where companies need to weigh the costs of not taking a proactive approach to making security a key part of their software development process. Is the upfront time and effort worth it when it comes to developing software and ensuring bugs and vulnerabilities are addressed before it is put into the wild? The simple answer is, yes! We are already seeing this in certain industries such as financial services, which learned the hard way that it is a critical component of software development—mitigating risks and significantly lowering the financial burden associated with a major breach.
In fact, security should have been more central to software development a long time ago. As software, and more broadly technology, continues to evolve and permeate our lives from more angles, it is crucial that security be a consideration—a “use case” as developers call it—from the earliest conceptual stages of a project. The costs of not doing so are simply too painful to imagine otherwise.
Shifting to Security-First
To build more secure software, organizations typically must implement a software security initiative. You can break it down into four steps:
Assess your current software assurance posture
Define the strategy your organization should take to ensure a viable posture
Formulate a road map of how to achieve that posture
Implement your strategy
The above steps are simple and when you think of the alternative to not doing this, adding security as a pivotal part of the software development process seems like a no-brainer. To better understand what I mean, you need only look at the cost the average breach has on an organization. According to the 10th annual “Cost of Data Breach Study” independently conducted by Ponemon Institute, the average consolidated total cost of a data breach in 2015 was $3.8 million, an increase of 23 percent from 2013. The study also reported that the cost incurred for each lost or stolen record containing sensitive and confidential information increased 6 percent, to a consolidated average of $154 from $145. Depending on how much data has been compromised, the financial fallout can be staggering, if not crippling, to an organization.
Conversely, the cost to repair a single vulnerability in an application during the design phase is less than $500, according to the IEEE Computer Society. The fact that the financial impact of not addressing security during the development process can quickly become cost prohibitive, is a clear indication that secure software development practices can no longer be overlooked. Breaches are now a boardroom issue and require a seat at the development table.
As we can see from the stats above, the economic fallout for organizations is obvious, but with the Internet of Things coming to a house near you, this issue is suddenly becoming more personal and painful for the average person. Whether an attacker takes over your thermostat from Russia or finds a way to monitor your home via your baby camera, vulnerabilities are making it easier for malicious actors to corrupt corporate, government and now individual networks like never before.
We are well beyond the “it will never happen to me” phase. Breach stories that used to happen to so called “other” people are more likely to happen to you if software defects continue to be ignored and are not fixed when they should be. No matter how you crunch the numbers, if security isn’t addressed at the software development level, the result will always end in a costly lesson learned.
About the Author/John Dickson
John B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.
Dickson is a popular speaker on security at industry venues including the RSA Security Conference, the SANS Institute, the Open Web Application Security Project (OWASP) and at other international conferences. He is a sought-after expert and regularly contributes to Dark Reading and other publications. A Distinguished Fellow of the International Systems Security Association, he has been a Certified Information Systems Security Professional (CISSP) since 1998.
As a Denim Group Principal, he helps executives and Chief Security Officers (CSOs) of Fortune 500 companies and government organizations launch and expand their critical application security initiatives.
If you ever wanted to learn about Rugged DevOps (some call it DevSecOps), sit down for a spell with Shannon Lietz, Ian Allison and Scott Kennedy from Intuit. We discussed a number of important topics including internal war games, culture hacking, gamification of Rugged DevOps and starting as a small team. There are 100 gold nuggets in this conversation for novices and experts alike.
Derek Weeks: I have some of the Intuit DevSecOps team here with me today. We’re going to talk to them a little bit about Rugged DevOps and how things work over at Intuit. Let’s start with some introductions.
Allison: I’m Ian Allison. I help run the Red Team at Intuit, which is, I guess you’d say, an interesting way of taking control of security at our company. We try to get ahead of the attackers by basically being the attackers. We’re essentially ethical hackers. We go after all of our own stuff to make sure we can find where the deficiencies lie in all of our software.
Lietz: I’m Shannon Lietz. I’ve been working at Intuit 3 1/2 years and helped to found the 24×7 DevSecOps capability at Intuit, leading the Red Team, our security operations capability, our cyber SOC, and what we also consider “blue teaming”: being able to hunt for defects.
The organization has really had to transform how we do software development because we’re a 30-year-old software company. We are now seeing the traditional way of putting together software really embracing DevOps. For us, it’s been exciting to really work in the industry with Rugged DevOps, trying to help build security into the DevOps movement.
Kennedy: I’m Scott Kennedy. I run the forensics and threat intelligence part of cyber work.
Weeks: Shannon (@devsecops), tell me a little bit about software supply chains and how that vision of software development has impacted the way you see things at Intuit.
Lietz: That’s really a great question. It was interesting when Josh Corman and I first talked; we had a lot in common. One of those things was the software supply chain. What I really love about the concept is being able to have processes driven a certain way so that you can reduce defects.
Having worked for Toyota in the past and understanding the supply chain mentality, you get a sense of how you could put something together better, incrementing on it, figuring out how to share that process, and then really figuring out what things are important. Having that notion of fewer, better suppliers was really a core concept.
I love the idea of transparency, building things a certain way, and really getting into continuous improvement. You need to look at things from an opportunities perspective—making sure you’re not just looking to make things perfect. You’re looking for those opportunities to improve over time.
https://www.youtube.com/watch?v=nRaURhaTH9o
Weeks: As we think about Rugged DevOps within your security team, how do you measure the success of what you’re doing? What kind of metrics are you looking at that matter to the business?
Lietz: We measure everything. For example, mean time to remediation (MTTR). Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved. We track everything from mean time to remediation to when the ticket was created, to being able to look at when the code actually got published, to when it actually got found, and then we work on those things over time. We really try to uplift.
____
Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved.
____
We leverage JIRA [Software] just like a software development team does. We register our defects and figure out how to get development teams to take responsibility for those ideas. It goes through their process of release and regression testing. As part of that, we look back to see where our opportunities are.
As an example, we started out where things may have taken weeks. We then reduced it down to days and ultimately got it down to hours. We’ve seen defect resolution where it’s now minutes. When it’s something we’ve discovered that was just a mistake by an engineer, we realize “mistakes do happen.” We found that our cycle times also help us to find fault stack vulnerabilities in real time because we get to do end-to-end testing more aggressively utilizing this method.
Weeks: How has consistency in your operations helped with Rugged DevOps and has it fragility within the organization?
Allison: One of the things we do is to utilize a golden image for all of the AMIs (Amazon Machine Image) we use, for all of our customers, and we require everybody to use these AMIs. We’ve also built some really interesting automation around scanning these AMIs. So one thing we realized quickly when we first started native U.S., when we try to do full vulnerability scans against another system, if it’s set up to autoscale, we all of a sudden have 50 systems. Right? We can’t … it’s really hard to do a full vulnerability scan right against the system, so we came up with a way to share back all of the AMIs with a special account. Then we bring those up and we scan them. Then we grade them.
Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F, based upon the system you have. While we always strive to have our base image be an A, people continue to run on older images. But they get graded, and those grades get pushed up, so everybody in their org structure gets to see what the grade is for their account. I think by being a little standardized, basically with these images, lets us know what’s in everything, and we have a grade for everyone. It helps everyone have a really good idea of where they stand when it comes to a security standpoint.
____
Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F … so everybody in their org structure gets to see what the grade is for their account.
____
Weeks: That’s not only a grading but a policy enforcement governance kind of role that grading plays. How rapid is the feedback loop in that grading system for the teams that you’re working with?
Lietz: It’s really quick, and we’ve discovered through some science that having component-based resources like AMIs provides us with an advantage when doing things like remediating vulnerabilities. Using AMI-based resources, we have seen that when there’s a defect in it, we can find and remediate all of the defective AMIs quickly. That improves everyone’s security across the company.
So if you’re just picking out really good components, keeping track of those components and adding security into them, then you’ll actually see a different effect across our pipeline. A single change can actually have a dramatic effect on reducing the problems within the pipeline.
Allison: It’s really interesting. This morning I got an email from somebody that said, “Why did our baseline AMI go from an A to a C today?”
We had just received notice of a new vulnerability. Our stuff caught it, we scanned it, and we pushed the grade out to our portal where all our customers go to look at the grades. Our customers were able to see that change quickly.
They could now say, “Wow, it changed from an A to a C in less than 12 hours.” I think the feedback is really important. The other important thing is that we have people going and looking. I wouldn’t be getting emails about why has this changed if people aren’t actually looking and wanting to make their grades better.
Weeks: You mentioned customers. Are these internal customers?
Allison: Internal.
Lietz: Yeah, for our development teams, we as a security team really have changed how we think about things. It used to be that the security team would go out and govern. Basically, you got the fear of the security team coming in, descending upon you.
We’ve really changed how that happens within our organization. We grade our resource components, and we grade the way in which our applications come together. That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.
___
That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.
___
Weeks: Does it create a competitiveness or gamification of who has better grades?
Lietz: Absolutely, which is why we did it in the first place. To your point there, gamification is something where when you start to grade components like that, you can actually start to leverage a leaderboard concept. We do have leaderboards as part of this. We have APIs where you can actually pull down your grades and include them in your automation. With these, you can make governance decisions.
If you sort of have that “game afoot,” right, your leaders can then ask for specific grades within their pipeline. That up-levels the system, and you just see a continuous improvement lifecycle come to bear. Ultimately, you see fewer defects, and ultimately, you get to the notion of Six Sigma in our way of thinking. DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.
___
DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.
___
Weeks: As you embraced continuous practices and DevOps practices, were there points when you realized certain old ways of doing things weren’t going to enable you to move forward?
Kennedy: In looking at the progression of what we’ve been doing, one of the decisions that was made in Intuit and one of the things that I saw was really unique was the way they decided we were going to migrate into AWS. Our idea was to have the chaos team be the first people out, and that’s the security team. So the security team was the one that was going out and finding out how to use each of the products that AWS has and creating the concept of whitelisting. Each product was rated as to whether or not it met security’s requirement.
Therefore, no team can go ahead and pull down this new cool tool that AWS released yesterday and use it in production because it’s not been “whitelisted.” That can go into their scoring. Their scoring is not only used by the development teams but also is useful when reporting to the board. When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”
___
When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”
___
We decided to not rush into the cloud but to take a careful, considered approach and migrate in a very intelligent and well-thought-out way. At the same time, we gave the chaos team the ability to make the mistakes and grow and learn, so they can immediately turn around and share the mistakes with everyone else. They could say, “Hey, these are the things that didn’t work for us. We came across a lot of problems, especially when you look at things like accounts and account roles.”
How do you control when you have thousands of accounts and you need to have some sort of administrative control?
You can either have a gigantic effort to force your namespace and your Active Directory to be the source of control. Or you can use the vendor-specific tools like IAM and have each account have their own separate islands, but with the concept of cross-account roles, you can then do remote administration from a centralized account. You have it locked down. You have the capability to have a restricted group and be able to remotely go in and do the necessary actions.
That also gives you an audit trail. That also gives you multifactor built in because the AWS products get those things added to them.
Lietz: I think when it comes down to it, I think culture-hacking your environment can have a profound effect, especially when you’re going through a DevOps transformation.
Weeks: What is culture hacking?
Lietz: That’s a great question. We use it when really trying to figure out how we as a security team can change and transform. A lot of the things that take place in a company are really based on traditional processes: What has worked before, and why would we change something that is working, right? If you’re really going to go into an innovative frame; if you’re really going to get into that next-generation innovation; if you are trying to figure out what’s going to work in that … it’s never going to be the thing that is working. It’s going to be the thing that you’re going to learn as you go to that next step.
Culture hacking is really about looking at the people who are operating right now and trying to figure out how you’re going to help them go from A to B, making that change. What is that the experience going to be like?
What we have done, to Scott’s point, is we’ve forced our security team to have empathy for the DevOps teams. We go through the process of developing something in the cloud, utilizing it as a method of taking their paranoia and trying to balance the notion of getting something done within a specific time frame. We try to really wrangle what it takes to do those things securely and safely but, ultimately, still be able to deliver for the business.
I think that culture hacking really comes into play when you’re trying to figure out how to move somebody from the rock they’re on to the rock you need them to be on and trying to figure out what those mechanisms are.
___
Culture hacking really comes into play when you’re figuring out how to move somebody from the rock they’re on to the rock you need them to be on.
___
Weeks: Part of your security practice is looking at open source and third-party components and your own binaries. Can you shed some light on how Intuit is using Sonatype solutions to better manage those vulnerabilities?
Lietz: Yeah, Sonatype Nexus is a fantastic platform. We love the Nexus repositories. We love how you guys put together a community. We learn a lot.
A lot of our DevOps practice is working together with it. We’ve put together our Nexus repositories to do code signing and figuring out how to really secure our pipelines a certain way. We are taking advantage of the fact that we can pick up components, track them and then scan them [for known vulnerabilities].
That’s allowed us to reduce the defect count that goes to production. Actually scanning and looking for vulnerabilities within our components and our open source libraries allows us to make better decisions about what we’re including in our software.
Weeks: When you govern what open source, third-party or proprietary components are being used by developers, is there any kind of feedback from the teams saying, “Hey, you’re restricting my behavior, not improving my innovation”?
Lietz: What we’ve found is that the notion of security approvals, exceptions and gates really doesn’t work. Quite often, you just create a culture where developers are going to go out and do it, and then you’re going to find out about it. When it comes to really partnering and being boundary-less about how you think about security in your business, it’s all about transparency. It’s all about benefits. It’s creating things like a security markdown file within your repository manager. It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process. It’s ultimately having an attacks.md file, keeping track of what’s out there, keeping track of your open source, understanding what components you’re leveraging, and why you made the decisions that you made to bring those things into your project.
___
It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process.
___
At a top level, all of those things work. But really having tools that can help the decisions that were made by some of the other open source programmers that you’re getting contributions from is really necessary. All of the things that they might be deciding are also part of your decision tree, and ultimately, you’re rolling all of that and bundling it together. The attack surface is not just the decisions that your team is making, but the ones that you share across the code base that you’ve got.
Weeks: Your practices are very mature. You’ve clearly developed them over a long time, and some people watching this might think, “Well, Intuit’s a huge organization,” and it may be daunting to them if they haven’t started down the path of Rugged DevOps. Can you be a small team and have success in these kind of practices?
Lietz: We’re not exactly a huge organization, but we are relatively large in size now. When we got started, I believe I was one of maybe three people that started this, only a couple years ago. We have hired into our group pretty extensively to help grow it, and some of the things that we’ve done have really allowed us to operate differently, to bring in people and have them immediately be successful. Our practices allow someone “day one” to be able to work with the environment, to be able to develop code, to be able to contribute code that week.
We do things like weekly demos, where we actually do video demos. A person has to come in, program something, secure something, operate it and create a demo, all within their first week. So having the right bar for those folks is really important, but more importantly, our Red Team leader here (points to Ian), he came in and just is amazing, has created a Red Team pretty much out of thin air. So is having somebody from forensics, who’s just done an incredible job to help us, to make it so that we have a life cycle where we can snapshot something and be able to learn from it when it’s actually offline.
___
A person has to come in, program something, secure something, operate it and create a demo, all within their first week.
___
Those are the types of practices where you start to extend yourself past the normal baseline practices of processes today and really think past that about how you’re going to support innovation. You get into it very quickly. You get a learning culture. You get people who know that making mistakes—and figuring out how to learn from them—is okay. That’s a really important part of that actual culture that you’re putting in place.
Allison: Yeah, I was going to say, it’s all about iteration, right? We started small, and we just continually iterate on what we’re doing to try to get better and be better at what we all do.
When I first started this journey, I was a security guy—a pen tester. It was always the developer’s fault. Developers always made the mistakes. I always had to clean up after them. But after six months of developing Ruby APIs and Ruby and working my butt off in code, the empathy was there.
I really understand what the developers are going through and why they make the choices they do. But I think by allowing us to help them, by creating tooling that allows them to self-serve, to understand it without making them … helps them make themselves more secure without them having to become a security professional. I think that’s kind of our ultimate goal.
Shannon: Being friendly hackers, right? Basically going out and attacking them so their applications don’t get attacked by external attackers is really part of that frame.
Kennedy: The Red Team shift at the company has been profound because you see how people react. When the Red Team started, it was not as well shared, and a lot of people suddenly were very upset that they were attacked by the Red Team. But when it was pointed out, “Well, what would you rather have happen? Would you rather have somebody in China do this to you, that didn’t work with you, didn’t sit next to you and help you fix the product, or would you like to have a friend who, by the way, their job is to attack?”
When we went through several drills and actually practiced the muscle of defending the company against an attack, people were upset. “Oh, I had to do all this work.”
My response to them: “Well, you did the right work.”
“You did the right thing. You saw something bad. You did it. You did good. You practiced the muscle. Now when it happens again and it’s not the Red Team, I know that you’ll know what to do. You know that the process works, and we can actually defend the company faster and more securely.”
___
You know that the process works, and we can actually defend the company faster and more securely.
___
Weeks: Yeah. That’s an incredible story. Thank you for sharing it.
My final question: If you could pick a superpower in dev, security or ops that you would have in the organization, what would it be?
Allison: To me, they’re all alike; they’re the same, right? That’s what we do, DevSecOps, right? We try not to actually separate them out because I think once you start to separate them out, you start to lose perspective.
Kennedy: Yep.
Allison: There’s a good thing about having them all be one thing, so I’d choose them all.
Kennedy: It’s been pretty consistent. DevSecOps is the answer. What was the question? (Laughter)
Lietz: I think the reason we went out and created DevSecOps was just simply to change how we thought about doing development and technology—and to really to get ahead of it, to realize that attackers weren’t setting up appointments or meetings to help you figure out how they were going to attack your software, and so then why were we? Why were we operating at a fragile level?
I think that the superpower that I would like to have is DevSecOps because I know that we are going through the process of creating a less-fragile capability in security that will allow us to get ahead of attackers, make it much harder for them to go after the software that gets built, and we’re seeing those improvements. That’s actually a great thing.
Weeks: It sounds really exciting, and it’s very cool, so thank you all very much. I really appreciate it.
All: Thank you.
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 7 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.”
Attendees of Rugged DevOps Connect at RSA packed Moscone West’s second floor Feb. 29 to immerse themselves in security. Among the presenters of the daylong event was Forrester analyst Amy DeMartine, who provided a tutorial on how security, developers and operations folks can work together better in the new DevOps world.
Through a slide show, DeMartine laid out her Seven Habits of Rugged DevOps, three of which are discussed in this column:
1: Increase Trust and Transparency Between Dev, Sec and Ops
We live in a world where technology’s goal increasingly is to automate everything, with less reliance on humans—at least, that’s what many marketers would have us believe. However, DeMartine emphasized that Security and Risk groups, if they are going to play a key role in DevOps, need to speak to the practice’s true owners—App Dev and Infrastructure and Ops—in a language they can understand. Here, it’s not automation that matters most. It’s communication—among actual human beings—that’s paramount.
She emphasized a real disconnect between these groups, with AppDev being perceived as the department of “Anything Goes,” Infrastructure and Ops thought of as the division of “No,” and Security and Risk seen as the “Persistent Nagging” sector.
Imagine for a minute, a family unit comprised of Mom, Dad and a highly motivated teenager. The teenager is fast, full of energy and always pulling the trigger; Mom is pragmatic, a disciplinarian always having to tug at the teenager’s reins; and Dad is constantly frustrated that no one listens to his determined warnings. The family’s living room is the scene of many “heated” debates, where each side scores its share of wins but there are really no common agreements that satisfy everyone’s needs. When the teenager wins, it’s because Mom simply doesn’t have the energy to resist any further. When Mom wins, the teenager turns on the iTunes, plugs in the headphones, withdraws and possibly even starts searching for a new family. Dad’s victories are often followed by a series of door slams and the silent treatment.
Now imagine if the three sides found a common language? One that not only got each to see the others’ viewpoints but also developed a system where the teenager was set free to operate within defined boundaries, and where he or she even wore enough safety gear to keep risk to a minimum. We’d have a much more harmonious place, one where the teenager continued to grow without risking the family ship.
Interestingly enough, there really isn’t any technology available that addresses this very real human communication challenge. No mater how counter intuitive it may seem, an effective Rugged DevOps environment is highly dependent on human-to-human relations.
3: Discard Detailed Security Road Maps in Favor of Incremental Improvements
The U.S. Office of Personnel Management (OPM), Sony, Hollywood Presbyterian, Anthem—each of these organizations experienced a security breach of massive scale. If these breaches all shared a word in common it would be PANIC—or at least headlines would have us believe this. The OPM breach was the ultimate example, wherein almost as soon as the alarm bell rang the government announced an elaborate plan followed by the big “Sprint.” Although, it might have been wiser just to beef up phishing defenses (smiley face).*
It turns out that a detailed long-term plan may not be the answer to data breaches, ransoms and system shut-downs.
DeMartine said outright that a comprehensive road map for addressing threats should be discarded in favor of a vision for real-time measurement and incremental improvements. Below is the “circle of life in security and DevOps,” as envisioned by DeMartine:
7: Test Preparedness with Security Games
Who doesn’t like competition? Not many. I think security folks and hackers are probably some of the most competitive people around; visit a Black Hat conference and watch as attendees intently capture flags, break out of handcuffs and hack signs.
With that in mind, it makes sense that this is one of the seven habits. There’s little doubt that simulations will do more to prepare people for real-life situations—after all, practice makes perfect.
Communication is a Rugged DevOps Essential Tool
Increasing trust between Dev, Sec and Ops mandates effective and, likely, improved communication. Perhaps one of the biggest takeaways is that, for all the technological bells and whistles the industry throws at combating cybercrime, in the end an age-old skill—communication—is at the foundation of the most-effective security.
*Phishing is assumed the most likely cause of the OPM breach; it is important to disclose that one of my clients, PhishMe, is a phishing defense solutions provider.
Distributed denial of service (DDoS) attacks are some of the most pervasive and difficult attacks to prevent. The attack uses many distributed endpoints and/or systems to flood a web domain, application or service with excessive service requests or application calls. There are limits to the amount of bandwidth or the number of service requests or application calls that the associated web-based resource can handle at any given time, and when attackers using these requests or calls overwhelm these Internet resources, service is denied to genuine users who need legitimate access.
“These attacks are designed to either melt down your network or squash your applications and servers. Industry experts identify them as L3/L4 attacks and L7 attacks accordingly,” says Stephen Gates, principal SE and senior technical expert at NSFOCUS IB, a global provider of network security and advanced analytics. L3/L4 and L7 refer to three of the seven layers in the Open Systems Interconnect (OSI) reference model: L3/L4 refers to the network and transport layers, respectively, while L7 refers to the application layer.
These DDoS attacks are a big concern because they prevent users from accessing services and websites to conduct their business, which impacts user experience, employee productivity and a company’s bottom line. “The largest L3/L4 DDoS attacks on record exceeded 400Gbps in size,” says Gates. “Organizations all over the world regularly feel the effects of L7 attacks,” amounting to a lot of service disruption for a lot of businesses.
Handling DDoS Attacks with Rugged DevOps
Although Rugged DevOps can’t defend against L3/L4 attacks, it could help mitigate L7 attacks, Gates notes. Since L7 attacks are so common, a Rugged DevOps approach that fixes many—if not most—of them is an important tool can be an enterprise’s arsenal against DDoS. For it to work, Rugged DevOps must address the several types of vulnerabilities that appear in development of applications that make successful L7 DDoS attacks possible.
Most of the vulnerabilities susceptible to L7 DDoS attacks unfortunately permit unwanted user behavior in or in conjunction with applications that are accessible via the Internet. “For example, if a client machine continues to do the same thing over and over again (repetitive HTTP GET), this would be indicative of an unusual client behavior,” explains Gates. An HTTP GET is a request to the HTTP (web) server for data. Applications must apply methods for disregarding the several forms of unwanted behaviors.
Attackers can also send DDoS attacks against the application layer by using malformed packets to leverage weaknesses in ill-coded software. Packets are a means for encapsulating data into packages or units for transfer across packet-switched networks. “For example, if an attacker launched the ApacheKiller script against a vulnerable version of Apache, the application would completely fail to operate,” illustrates Gates. Applications frequently display these and other vulnerabilities to specially crafted attack packets.
How Rugged DevOps Can Help
Developers could avoid many of these kinds of application coding errors and vulnerabilities early in development by applying Rugged DevOps, which can catch and fix security holes early in the software life cycle. “Then they will likely not propagate into later versions of the application or the plugins riding on top of these applications,” says Gates.
Running penetration tests on software early in the development process is one way to thwart holes that enable L7 DDoS attacks. When coding missteps are uncovered early in the process, developers can fix them early, before they become part of the software. Tools such as Gauntlt, Mittn and BDD Security are examples of software testing tools that developers can use inside the DevOps shop.
Failed tests require a response. One such response is to automatically fail to build the software when the software fails the test(s). If development can’t move forward without fixing the security holes, the security holes will be fixed.
There are well-worn methods that developers can rely on to fix the most common, most threatening application security vulnerabilities. Developers should not have to do a lot of digging to uncover these methods. Many organizations and resources such as the Open Web Application Security Project (OWASP) clearly set these approaches apart and label each of them on their own distinct Web pages. This SQL Injection Prevention Cheat Sheet is only one example.
DDoS and other forms of attacks are, unfortunately, a part of life. Being able to mitigate an attack before it can occur is a goal. Rugged DevOps is one way to help make that goal a reality.
“Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.
There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.
This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.
Security Questions to Ponder
Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?
Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.
There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.
It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.
A week from today, February 29th, we gather in San Fransisco for DevOps Connect: Rugged DevOps @ RSA Conference at the Moscone Center. This is the 2nd year we are holding this conference and the line up is I think even stronger than last year! I am really happy and proud of the group that Mark Miller and Josh Corman have put together.
Best of all, if you are in San Fransisco we have free RSA passes that will allow you to join us all day at the conference and can also get you into the Expo all week if you like. Check out the website for full details. If you don’t want to get all the details just register for a free ticket, go here and use code 1U6DEVXPO for a free expo pass which will get you into our event on Monday.
In the meantime, here are some of my very best picks for the day:
Josh Corman & John Willis kicking things off with, Guns , Germs and Steel of the Software Age
Jez Humble & Nicole Forsgren presenting, What We Learned from Three Years Sciencing the Crap Out of Devops
Rich Mogull of Securosis on, Architectures, Design Patterns, and Coding for Rugged DevOps at Scale
Dan Glass presents The R.O.A.D. to Rugged DevOps for a Major Airline
Amy DeMartine of Forrester on Seven Habits of Rugged DevOps
Shannon Lietz presents The Journey to DevSecOps
Justin Arbuckle of Chef will be speaking on Transformation by Compliance
and rounding out my top picks, two of the leaders of the Austin DevOps community:
Ernest Mueller and James Wickett presenting Lean Security: Add Business Value without Bringing Waste
Of course these are just some of my picks. I can honestly say that there isn’t a bad session in the whole day. I think looking back people will review this lineup and be amazed at the blending of the DevOps tribe and security tribe into one great day of learning and sharing.
Also did I mention the DevOps (no) Wining cocktail party afterwards?
So what are you waiting for? Click on over, register for your free RSA Expo pass and be sure to click off that you will be joining us on Monday. Seating is first come, first serve and people come and go through they day. If you are in San Fran, hope to see you Monday!
Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.
This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.
Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”
It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.
But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.
After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.
Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.
As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.
The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.
Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.
For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.
Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).
In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.
Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.
Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.
For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.
There are definitely worse fates out there. But, just when you think you’re out …
John B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.
