Avoid Buzzwords: There Is No DevSecOps

Could you imagine a civil engineer designing a bridge without considering the safety features and requirements of their project? Or a mining company that doesn’t start every work day talking and acting on potential health and safety hazards? Of course not.

So why are organizations still talking about adding cybersecurity into DevOps, the process that is transforming how they do their most fundamental business operations?

I’m talking about that new buzzword, DevSecOps. Actually, when I hear the term DevSecOps, I instinctively cringe, like I’m hearing fingernails grating on a blackboard. But it’s clear that DevSecOps is a “thing.” It’s not just that it’s being written about in blogs, talked about in podcasts, and debated at conferences and seminars. The term has only been around for a few short years, and the industry analysts are already writing reports that it’s a multibillion-dollar industry growing at double-digital rates annually. And when analysts start throwing around numbers like that, business leaders in the C-suite and the boardroom sit up and take notice.

But take it from this CISO: Maybe you don’t need DevSecOps.

I know what you’re thinking: Blasphemy! How can any responsible security professional question the need for integrating security into the process of agile, continuous development and release of software designed specifically to improve business processes?

Of course, the idea that security must be an integral part of DevOps is not up for debate. But what I am suggesting is that the mere introduction of this new term sends the wrong message to engineers, software developers, business stakeholders, and executives. “Yeah, let’s be sure we add some security to that new release.” That’s the wrong philosophy; cybersecurity must be embedded into the mindsets, priorities, and processes employed by everyone. Simply expanding DevOps into DevSecOps is an admission that it wasn’t a prime consideration in the first place.

Look, I’m not trying to set fire to this phrase, even though I view it as marketing terminology rather than as a groundbreaking operational discipline. Maybe your organization’s CISO has had difficulties getting the CFO or CEO to open up to the critical need of making cybersecurity “job one” from the start of any new business effort. If so, and if the introduction of this new buzzword makes executives listen a bit more attentively when the CISO talks, then I’m all for it.

But it’s important for executives to understand that cybersecurity is much more than just a battle against digital adversaries. It’s not something you “win” or where you think primarily in terms of competitive strategies against the bad guys. No, cybersecurity is something you live and breathe every single day. It’s a lifelong condition to be continually managed, like personal wellness, responsible driving, or respecting people. Let’s call it your cyber health and wellbeing programme.

The simple act of tacking on “Sec” to DevOps means that it wasn’t a priority in the first place. That is an undisciplined approach to conducting business in an era of digital transformation and technology-led continuous improvement.

Our organization, REA Group, is a large, successful organization in real estate digital advertising. We think of ourselves as a tech company, in much the same way that Netflix sees itself as a tech company rather than as a movie rental company. Our Tech community has around 450 engineers and developers, and we are fully bought into the DevOps philosophy of frequent software releases for continuous operational improvements. I also lead a small team of security specialists, and I am certainly more than aware of the always-present cybersecurity threats that can undermine our business’ success. However, I can’t continually go to my CEO or board and ask for approval to hire an army of new security engineers to meet new and anticipated threats.

Fortunately, I don’t have to. That’s because I have a cadre of 450 potential cybersecurity specialists already employed–the engineers and developers who are considering and architecting security into their new software throughout every day. I don’t need DevSecOps because our DevOps team understand that security is a priority.

My group acts as a trusted advisor to the engineers and developers, who also work in lockstep with their business teams, turning out new software multiple times a day. We provide support through education and awareness about what to look for, measuring and monitoring, and we give them tools to help – just a like your GP provides health guidance, tests and recommendations. We’re already part of DevOps–no need for DevSecOps, because the “Sec” is implied and understood. In the future, it’s even conceivable that security teams may not exist in their current form; our security team might be a very light governance staff for testing and monitoring, ensuring good practices are being followed. Automation and workflow within existing teams will take care of their security hygiene.

In this model, we don’t need to build a large centralized command and control security team; we have a federated model, and your organization can probably do the same too. You’re just not leveraging it. Now, I’m not saying we’re 100% nailing it – yet – but we’re changing our approach to better meet business outcomes and security objectives in a cost-effective way. In our model, security services are predominately self-service so teams can decide when and how to incorporate them into their development lifecycle.  Security is still seen as a grudge purchase and a potential blocker so lowering the barrier to entry is a priority. Adoption is everything.

So, what’s the takeaway for business leaders for those of you reading this article? First, you play a crucial–perhaps the most vital–role in the organization: establish, mold, and ensure a company philosophy and culture that security is everyone’s job, and it must be done well. And it shouldn’t take the risk of a bad compliance audit or an embarrassing data breach to hammer this home. It’s a leadership commitment. Funnily enough – people tend to follow the leader.  As a dear friend of mine used to say, “what my boss finds interesting, I find fascinating”!

Second, you need to support your existing DevOps efforts with more developer training that reinforces the security aspect from the very start – basic input validation is very much “a thing” in 2018!  I realize that budget responsibility probably exists elsewhere in your organization, but you need to show the organization it is not an option.

Finally, when the head of your existing DevOps program comes to you and tells you they’re adopting a DevSecOps program, just ask them:

“Why? Hasn’t security been part of DevOps all along?”

share: