Putting the Security Into DevSecOps


The non-Newtonian fluid that’s composed of cornstarch and water has been around a long time, but Dr. Seuss’ 1949 book was the impetus for what it’s often called today – Oobleck, from “Bartholomew and the Oobleck.” When not under pressure, Oobleck is a thin liquid; when pressure is applied, its resistance increases to the point of being solid. A couple of other examples are quicksand and Silly Putty ™ (for fun, this video shows how resistant Oobleck is against Thor’s Hammer). Company application security is much like Oobleck. When not put under stress, security appears to be a fluid mess of policies, procedures, guidelines and a host of other controls that seem to have no real connection. But when there’s an event of interest, incident or even a breach, those policies and procedures (P&Ps) come together to make their worth known.

DevOps—What’s in a Name?

DevOps has been around for a while now, and its definition is akin to a Newtonian fluid: Not well-defined except within each company or organization. This lack of a standard definition has its merits, though; giving each company flexibility in determining what it means for them, and the benefit of maintaining the best of development, security and operations no matter what it is called. Attempts at bringing all aspects of these disciplines together, regardless of the nomenclature used, are both old and recent. It’s a reframe of Shakespeare’s line, “What’s in a name?”

Security has to be part of the DevOps culture, whether it’s called DevSecOps, SecDevOps, SecOpsDev or just simply DevOps. Creators of software need to go beyond the desire to have a good process and move to understand that customers need the software to be secure in addition to being useful, delivered on time and with a good UX and that the business needs to develop and maintain a positive reputation and avoid breaches to the best of its ability.

How does one put security into the DevOps process? One approach is to proceed as if the goal is to attain SOC 2. SOC 2 reports hold great value. While not universally recognized (SOC 2 is a US-focused security controls examination), they give useful details about the controls used. While SOC 2 is not on the level of ISO 27001, for international (to the USA, that is) prospects, it still divulges security control details that aren’t present in other standards.

What if Attestations Are too Expensive?

AppSec transparency is not only good for improving sales but for mitigating the problems caused by third-party breaches.

For some vendors, especially newer or smaller ones, something like SOC 2 is on their radar but not yet feasible. Why? Cost–those and other attestations are often expensive. Is it worth it? Yes, but not if the financial expense will put the company at risk. Whether one has achieved SOC 2 or not, potential customers want to see transparency in a company’s security controls.

In the process of going for SOC 2, there are two advantages: 

  • You’ll improve your security posture.
  • You’ll be ready for when those opportunities roll around.



Source link

Leave a Reply

Your email address will not be published.

Previous Article

Acre | Increased Job Security as Green Auto Tech Receives £43.7M Funding

Next Article

International WELL Building Institute | First in the World: Irish-Owned Ethos Engineering Earns Well Performance Rating for Dublin HQ "Living Lab"

Related Posts