Over the years I’ve watched how security professionals have adjusted their messaging and general approach. I know there are still plenty of DoD-style security professionals out there but there is, dare I say, a softer side that is growing and, you know what? I love it!
These professionals know that the most secure system is one where you dig a ditch, toss in all your tech, cover it with cement, and just…walk away. But that doesn’t really pay the bills, feed people, entertain people, or help grow the company. After all, security folks know that there are governments that are trying to hack into other governments. I don’t mean the balloon, I mean secrets, ALL THE SECRETS.
I remember when I started to touch my toes in the world of security. I came in with very clear notions of good vs. bad. Wonderful folks educated me on how everything is closer to shades of grey. Surprisingly, this made sense once I was able to see it through a security lens.
With this understanding, I’ve watched as security teams struggle with systems that are getting more and more complex. We can’t just walk around from candy dish to candy dish talking to each other and humanizing ourselves. At least not in the same way.
The most important thing I’ve learned about this new crew of security folks is that they approach their teammates with kindness and compassion.
They want to remove the notion of being the Big Bad. I especially love Esteban Gutierrez's approach to Security as Nurturance. He’s amazing, if you don’t know his work, I’d highly recommend the watch.
Plenty of other talks have happened over the years that relate to folks working with each other. Hands across teams if you will. I love this one by Chris Barker, Adrien Thebo, and Bill Weiss called Everything is terrible: Three Perspectives on Building, Configuring, and Securing Software
Even going so far as looking at Snyk’s approach to security. Who is it that security folks need to engage with the most? Developers? Welp, what if we made the product easy for that doer to understand the problem, how to consult, and remediate? Brilliant! I think we need more and more of this kind of thinking.
The industry is ever-changing and evolving. As it does this it’s also getting more connected and more complex. Systems aren’t going back to “100 lines of code and it just works.” We borrow code, shape it, and mold it to do something it wasn’t entirely meant to do because it’s easier to get started with those Open Source Projects, with existing code, with those templates. No one claims to love the idea but we keep doing it.
As this progression happens we have these great tools available to handle complexity, to automate those known transactions within the code and infrastructure. This is where we ended up with DevOps, DevSecOps, and Shift Left. I’m confident there are new ones out there and I just haven’t read enough.
One thing that remains constant in these movements is people want to know who to talk to. Devs and Ops folks want to know who owns a code path or a piece of infrastructure. Security folks want to know how to help and educate.
But we’re busy.
We are understaffed and fully under duress. So… it’s hard and we react. We do the same things over and over because we haven’t had the time or brain space to think about a new way.
This is where OpenContext comes in, we are lucky enough to have the time and the brain space to solve this problem for our DevOps and Security friends. In a past blog post, Six Days and Seven Nights: An Outage Tale, I talked about an incident on-call. I walk you through the experience of so many of my friends who simply can’t figure out who did the thing and why it broke. It really is a proper horror story when you think about it. But it’s not unique to DevOps.
Security struggles with wanting to know who to partner with, what new language is being used, or what old template is STILL being used. OpenContext lets Security look up which team owns a code path, WHO the contributors are, when and what they released, and so on. We don’t care if you have a monolith or services either.
This is why OpenContext makes it easy to understand and identify the right people based on auto-discovery, not that manager spreadsheet that’s updated once a quarter.
Security needs to know if Johnny contributed to another team’s project and inadvertently added some kind of security risk. Or if he created a template that now has a vulnerability and impacts critical pieces of code, product, or infrastructure.
It’s not Johnny’s fault, that’s just tech. But wouldn’t it be great if security knew to talk to Johnny instead of sounding the alarm for the entire engineering org? Security doesn’t want to do that, no one wants to do that.
They just want context.
My Security friends want to know who they should talk to. They want to do Security through Nurturance. So they can say, “hey, we are here to help.” Security folks know this is weird and hard. They know you are moving fast and trying to keep things up and keep money coming in.
We have a few new features we are rolling out and some that are out. If you haven’t heard Alice, our CTO, and Brian, our CEO, talking about the features, you can check it out here. We’ve been putting a lot of thought into these features and views. Which is why the next release will include Dependabot vulnerability data.
We know that Devs are best at developing software, maintaining, and growing it. Ops and SREs are best at keeping things up and running, and architecting complex systems. SREs are amazing at creating automation so the Security and Ops best practices are built-in and handed off to our Dev friends. OpenContext makes these steps easier, centralizing where you store your best practices. But at our core, we know that the most important thing to automate is WHO is working on what. THAT doesn’t need to be a secret.