Questions? Contact Sales: 888-558-3645 Live Chat Email
21
Feb
2019

How a DevSecOps Mindset Promotes Better Security and Productivity

By vmradmin, VM Racks

Changing a company’s security culture is hard sometimes. Consider the techy world of applications development, if you will. (Even if this doesn’t apply strictly to you, the lessons are helpful).

Typically, as one network security expert points out, the old ways of bringing usable software to market involved “every man to his island.” You had an IT island, a DevOps island, and last but not least, a Security island.

The Devops island had its goal: do continuous deployment and continuous release of code, with automation being a driving force wherever possible. Sure, you employed a Source Code scanner or similar tool to check yourself, but Security was over on that other island, inhabited by the people who typically say “no.”

In other words, out of the gate, the Security team was viewed with suspicion – the “gatekeepers” to slow or at least negatively impact the process. To DevOps, they represented an impediment to their end goal; anything that slowed their process down was unlikely to be welcomed or adopted.

A Seismic Shift

But then a series of massive earthquakes with multiple aftershocks – in the form of significant breaches (think Target, Equifax, etc.) comes along, and someone wisely decides to ask the right questions: How can we build in security from the start? In essence, what would it look like if there were no more islands?

It will take a significant change in culture to be sure – instituted top-down by the CTO. But the result will be encouraging: No standing off at a distance, each on his own island, pointing fingers.

Instead, a team approach will be utilized, in which communication of needs and listening to each other is prized, from the beginning. An accepted process of learning, failing, and trying again will become the new norm; this time, with the benefit of greater insight, shared tools, and camaraderie. And so DevSecOps is birthed.

One writer describes getting off the island(s) in this way: “Security [is no longer] about building a wall around applications after the fact; it is about developers writing code that is inherently difficult to attack and testers finding potential flaws before a software release.” See How DevSecOps gives Security a Voice

Improving Culture, Security, Productivity

With DevSecOps in play, the DevOps part of the team is now viewed by Security as a consumer with needs – primarily efficiency, & deploying rapidly. In turn, DevOps takes Security seriously, as a valued partner in the relationship – a consumer with significant needs and contributions as well. As in any healthy relationship, working together toward a well-defined series of goals is a shared vision. Security is listened to early on, and testing is welcomed all along the process,  utilizing ongoing, open communication and feedback.

The benefit of this can be seen, for example, in greater network security as the software travels through each phase of the journey. It may be development in a private cloud, followed by deployment in a hybrid cloud, and ultimately deployment in the public cloud as well. At any rate, the result should be safer, more efficient software.

So here’s a summary of the lessons learned in DevSecOps:

  • From top-down, get rid of the islands that separate teams. Get all the players in the same room, and reinforce that “We’re all on the same team, with a common goal. No part is inferior, and security is now a shared responsibility.”
  • Communication is not to be stifled but prized. Empathy and appreciation for the challenges and contributions each part brings to the table should be encouraged.
  • Technology is a valued friend. Can we automate for both productivity and security, using new tools?
  • Don’t be afraid to fail, and nothing is set in stone. You may fail ten more times, but the process is iterative. Dive in, learn, adapt, fail, learn more, and so on.

A Process Mindset

Finally, DevSecOps must be viewed as an evolving, ongoing process – in part, because the need for new security tools are always changing. The fact is, malicious actors are also evolving, coming up with new ways to compromise networks every day.

This means too that cybersecurity expenditures can no longer be viewed as a one-time cost, acquiring security products with limited effectiveness (eg, a new firewall or anti-virus subscription). Protecting data, with all the implications inherent in that goal, must now be seen as an ongoing process, an investment that companies must be committed to for the long-term.

In summary, DevSecOps describes a collaborative approach, where each part of the team learns from and appreciates the other, and is better for it. Leaving the island mentality behind, companies will actually find they can be more productive, and better equipped at the start to meet the ever-changing needs of security.  

Changing a company’s security culture is hard sometimes. Consider the techy world of applications development, if you will. (Even if this doesn’t apply strictly to you, the lessons are helpful).

Typically, as one network security expert points out, the old ways of bringing usable software to market involved “every man to his island.” You had an IT island, a DevOps island, and last but not least, a Security Island.

 
The Devops island had its goal: do continuous deployment and continous release of code, with automation being a driving force wherever possible. Sure, you employed a Source Code scanner or similar tool to check yourself, but Security was over on that other island, inhabited by the people who typically say “no.”

In other words, out of the gate, the Security team was viewed with  uspicion – the “gatekeepers” to slow or at least negatively impact the process. To DevOps, they represented an impediment to their end goal; anything that slowed their process down was unlikely to be welcomed or adopted.

A Seismic Shift

But then a series of massive earthquakes with multiple aftershocks – in the form of significant breaches (think Target, Equifax, etc.) comes along, and someone looks down upon these islands asks a good question: How can we build in security from the start? In essence, what would it look like if there were no more islands?

It would take a significant change in culture to be sure – instituted top-down by the CTO. But the result would be encouraging: No standing off at a distance, each man on his own island, pointing fingers.

Instead, a team approach would be utilized, in which communication of needs and listening to each other would be prized, from the beginning. An accepted process of learning, failing, and trying again would become the new norm, this time, with the benefit of greater insight, shared tools, and comraderie. And so DevSecOps was birthed.

One writer describes getting off the island(s) in this way:

“Security [is no longer] about building a wall around applications after the fact; it is about developers writing code that is inherently difficult to attack and testers finding potential flaws before a software release.”

See How DevSecOps gives Security a Voice

Improving Culture, Security, Productivity

With DevSecOps in play, the DevOps part of the team is now viewed by Security as a consumer, with needs – primarily efficiency & deploying rapidly. In turn, DevOps takes Security seriously, as a valued partner in the relationship – a consumer with significant needs and contributions as well. As in any healthy relationship, working together toward a well-defined series of goals is a shared vision. Security is listened to early on, and testing is welcomed all along the process,  utilizing ongoing, open communication.

They benefit of this can be seen, for example, in greater network security as the software travels through each phase of the journey. It may be development in a private cloud, followed by deployment in a hybrid cloud, and ultimately deployment in the public cloud as well. The result can be safer software

So here’s a summary of the lessons learned in DevSecOps:

  • From top-down, get rid of the islands. Get all the players in the same room, and reinforce that “we’re all on the same team, and each plays a valued role.” Communication is not to be stifled but prized, and security is now a shared responsibility. Empathy and appreciation for what each part brings to the table should be modeled and encouraged.
  • Technology is a valued friend. Can we automate for both productivity and security, using new tools?
  • Don’t be afraid to fail – nothing is set in stone. You may fail ten more times, but the process is iterative. Dive in, learn, adapt, fail, learn more, and so on.

A Process Mindset

Finally, DevSecOps must be viewed as an evolving, ongoing process – in part, because the need for new security tools are always changing. The fact is, malicious actors are also evolving, coming up with new ways to compromise networks every day. This means too that cybersecurity spending can no longer be viewed as a one-time cost, spending money on security products with limited effectiveness (eg, a new firewall or anti-virus subscription). Protecting data, with all the implications inherent in that goal, must now be seen as an ongoing process, an investment that companies must be committed to long-term.

DevSecOps describes a shared collaborative approach, where each part of the team learns from and appreciates the other, and is better for it. Leaving the island mentality behind, companies will actually find they can be more productive, and better equipped to meet the ever-changing needs of security.

Our certifications