Helen Beal | The Blog Pros

January 14, 2020

DevSecOps, SecDevOps, or RainbowMonkeyUnicornPony? [Interview with DJ Schleen]

While DevOps is forging boldly into the future, security is still trailing those advances in many organizations. So it’s important that we understand how to apply notions of (traditionally static) security into environments that are built to foster continuous development. I, for one, would like to raise the torch to the fledgling category of DevSecOps and learn how it is successfully implemented by industry leaders. In the first of a series of interviews with DevSecOps community leaders, I chat with DJ Schleen, DevSecOps Advocate at Sonatype.

Helen: I think that the market is light on shared DevSecOps reference architectures to help the community learn and grow. Do you agree and what can we do about it?

DJ: There are a lot of missing pieces out there and I think it's because nobody really knows where to go with it. If you do a search for DevSecOps reference architectures, you're going to see that infinity logo with a bunch of locks around it which doesn't really tell you much. I’ve created this one, but the community does need to share. I think it's because people don't really know which community they're part of; are they part of Secure DevOps, SecDevOps, OpsSecDev? I think there's confusion. So you might see some security reference architectures, but I don't know if they're really taking into consideration flow across the whole technology value stream.

October 8, 2019

DevOps and the Proliferation of Secrets

Make sure that your DevOps secrets don't get in front of the wrong eyes.

"Secrets", in the context of cybersecurity and DevSecOps, describes the digital authentication credentials used in applications and services; anything you don’t want to share. The secrets you need to keep safe may include:

July 30, 2019

CALMS for DevSecOps: Part 3—How Lean Improves Performance

This is the third of my blog posts investigating DevSecOps through the CALMS lenses—we’ve looked at Culture and Automation already now it's time for:

Lean

In the previous blog post, I looked at some DevSecOps tools I particularly like and introduced you to TaskTop. TaskTop is the ultimate tool for optimizing your flow from idea to realization—a connectivity framework that takes the pain away from writing and managing integrations and visualizing your lead and cycle times. It’ll show you where your bottlenecks are.

June 25, 2019

CALMS for DevOps: Part 1—Why Culture Is Critical

DevSecOps is the principle that all technology teams have accountability for cybersecurity in an organization—ownership is not solely at the door of the security professionals and teams. The idea that cybersecurity is everyone’s job has come about partly because cybersecurity skills are constrained—within the market as a whole and within an organization specifically. A recent report from (ISC)2 claims there is a global cybersecurity staffing shortage of three million and that this is increasing. This is certainly my own experience with the organizations I work with in Europe and the Middle East.

This constraint manifests itself through:

May 9, 2019

When Machine Identities Go Bad

Managing machine identities, such as SSL/TLS certificates is boring, right? It’s not inspiring work and it’s easily overlooked or forgotten in the day to day onslaught of changes and incidents in a typical enterprise technology department. And they seem like such little things… but when certificates go bad, well, life can turn pretty dark. Here are some real-life nightmares that happened as the result of mismanagement of machine identities.

1. Expired Certificates Delayed Breach Detection

The notorious breach at Equifax — talk about reputational damage, right? Nearly 150 million customer records stolen including date of birth and social security numbers. That’s a lot of people having sleepless nights about ID fraud thanks to an error somewhere in Equifax’s approach to cybersecurity. While the initial attack was performed via a Struts vulnerability (a common one I still frequently see during application scanning), the detection of the breach took 76 days. The reason it took 76 days to detect: misconfiguration of the device inspecting encrypted traffic on the network. The reason for the misconfiguration of the device: a digital certificate that had expired ten months previously.