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.

Let’s get started.

Pieces of the AppSec Puzzle

Actually, let’s back up a bit first. There are some policies that cover multiple areas of the company or product: Infosec policy, risk assessment, vendor management and acceptable use (AUP). These will require full company interaction and arrangement. I want to focus on what you can do, starting today, to improve your product security.

Here are the policies to work on to put security into DevSecOps.

• Software development life cycle (SDLC)
• Incident response
• Access control
• Passwords
• Change management
• Logging and monitoring
• System backup and recovery

Each of these will require, for full effect, more people and departments than just you and your own. But these P&Ps can be directed internally toward your development and production teams; perhaps even IT and security.

Here’s a list of each policy and its purpose:

Software Development Life Cycle (SDLC)

This is one of the first P&Ps to develop. You’re already doing this – just because it’s unwritten doesn’t mean you don’t do it. In the world of customer assurance, if it isn’t written, it doesn’t exist. Make it real and purposeful by codifying what you already do and improving as you go. This is a primary tool for AppSec (which includes web applications and APIs) and is almost solely within the purview of devs, engineers and QA. The product or service provided needs to have this foundational level of control to prevent common forms of attack.

Incident Response

This is also high on the list of P&Ps on the list. This is separate from the corporate IR plan; DevOps should have its own plan for dealing with technical emergencies, incidents and breaches. And this plan can be part of the overall company plan.

Access Control

Access control includes how users are authenticated and authorized, and includes least-privilege access, multifactor authentication (MFA) and service accounts. Prospects need to know that access to your production environment is well controlled.

Company Passwords

Company passwords as a whole are managed by IT and security, and often have a minimum of eight characters, require a certain number of special characters and other industry-standard requirements. But your software environment can go beyond that to enforce more stringent controls.

Change Management

Customers need to be aware that the software they bought is changed in an orderly and authorized manner, not through an ad hoc and ad lib process.

Logging and Monitoring

This is important for ensuring that activities such as access control and change management in your company have been performed properly, in addition to providing information for forensics in case there’s a breach.

System Backup and Recovery

Document and ensure your capabilities to restore data in a timely manner. Things happen; not just attacks—user errors, natural disasters, provider outages and the like.

The process of each P&P looks something like this:

It’s a straightforward and natural process, but the simplicity of the ingredients (like cornstarch and water) makes it very easy to overlook its effectiveness.

Additionally, make these P&Ps available—whether in full or by using excerpts or summaries—to prospects and customers. A major part of driving security is opening oneself up to public scrutiny. This could be via a secure portal, a public-facing page or a ticket/request system.

BONUS Assessment for Transparency

Take a look at the Consensus Assessment Initiative Questionnaire (CAIQ) by Cloud Security Alliance (CSA). Level one, which is a free self-attestation, is an often-requested assessment. It’s fairly rigorous and may require you to level up security in your company, but it’s a well-respected and no-cost attestation and is available free for prospects and customers to view.

The Next Step

Inserting or improving security in the DevOps process is part of the true DevOps process. It’s a mindset and culture more than a title or official designation–and it’s possible.