Shannon Lietz, ThirdScore | RSA Conference 2023

This is texturung TV. Hi, we're live back here at RSA. It's our it's our final day of coverage.

Actually, I think we only have two or three more interviews. So stay with us. Are there two three good ones?

Actually, there's gonna be one of the best ones. org. And we're going to tell the story about that in a second shining was also long time and Intuit running running a Dev team and into it as well.

Was it red team as well? I had read team Cloud security Dev. You name it?

You name it that she moved over there to Adobe and then recently Shannon has emerged into her own world again, and we're happy to have her here. If you've been following our coverage Monday was our devops connective SEC Ops event and Shannon was one of our keynote presenters there talking about some new research and new. Studies and communities she's been working on around metrics.

Did I embarrass you enough yet? Do you want me to just keep going, you know you? Shannon Lietz hey Shannon, how are you?

I'm so good Alan. It's great to be here with you. Thank you.

org for a second. So as I think I I said it Monday at the show. This was the ninth year.

We've put on SecOps or devops connect SecOps. But in the beginning we weren't gonna call it SecOps. We would call devops connect.

But if you remember James Wicked who I saw yesterday. Rugged devops was a word there were several words because people were moaning and groaning about putting second devops. My devops friends heads were gonna explode because there is only one devops, right?

We can't it is Securities part of it. org and we said you know what it It's good enough for her. It's good enough for us.

Here. We and now it it's a thing right devops is SecOps. Yeah.

org and why you did it? Yeah absolutely have that came about. Oh, yeah.

I can tell you a whole bunch of fun stuff. I know all of the No, we're all the bodies that buried let's not get sued though. But yeah, so, you know back in the day.

I remember pulling everybody together. We were doing Cloud security Cloud security was like in its infancy. Yep, and it was pretty clear that with Cloud we were gonna have to start doing security as code.

No one was talking about security as code and I went around and started looking at all the devops communities and I'm like, well who's doing some security stuff and can we learn from them? Because Reinventing the wheel seems kind of not fun, right and they're really wasn't any guidance in the industry at the time. They really wasn't.

Yeah and even the cloud providers really didn't have security features. I tried to find threat models and things like that just did not exist. And at the time, you know, I worked for a corporation.

It was a lot of fun. I think it just became really apparent that the industry needed to evolve. And so, you know you either follow somebody or you lead and wait, I'm gonna tell you leading is really challenging when there isn't a path yet and you know pulling out the machete in the middle of a jungle and trying to figure out a path is you know, no small feat and I think I just had a really I had a great crew.

I had a great set of friends that wanted to make it all kind of come together and I remember sitting around a flat table with a bunch of folks and us talking about how it had to change security had to change because devops folks were basically moving without security and then you would test and things would come up and essentially that sort of started it it needed to be branded. It wasn't devops at the time went to go. You know, what you did devops Deb the devops teams were like pushing it away.

They didn't they didn't want it. Yeah. No, I was very A parent I went to several devops functions asked some security questions.

It was not very polite apparently no, and so just decided. You know what we want to break into this devops thing. so we're gonna write a manifestor because all things start with the manifesto and just like rugged devops which by the way the manifesto to the to the the Illuminati which is what I call the original sort of devops people and they're all my friends now but back then the idea of having a Manifesto was so anti devops.

Yeah, because devops jet not just excuse me Patrick duboir and they're yeah, they refuse to write a man if they were asked many times refuse to do a Manifesto refuse to even write a definition. Yeah of what devops was. Yeah.

So having a Manifesto for something was was sacrilegious. Oh absolutely. But how are you going to explain it to people right?

I went around and said hey, so what is this? And everybody said, well, what do you think it is? Oh goodness.

com by the way. What is devops? Yeah.

Yeah, so and asking everybody and everyone had an opinion I I hear you. Say to people together. They sort of Define they create their Community expectation.

I remember sitting around the table and we all throughout some things. We wrote it down about an eight dollar website. Aggressive history.

Yeah, right. It really is rugged devops was the beginning I think for me. I you know, I don't really care what you call something.

What I care about is that you define it you can follow it. It has someplace that it's gonna be purposeful and that there's a vision for it. And so, you know, the vision for SecOps is much larger than I think the industry has adopted for it.

Yeah, so CI/CD security is is not to have sex ops, you know, really if you think about it. The feedback loop is super critical. There should be measurement associated with it.

We should ultimately get safer software if we're doing it, right and it should become something less burdensome. So, you know to me until folks really kind of get to the point where Dev sick ops is the I think Norm if you will in the development community and operations insecurity, you know, we effectively have three siled pillars and in some cases no land bridges and I think we've really got to work on our land bridges and our collaboration. effectively You know.

I don't disagree. I mean look shift left if we sure let's let's talk about Chef left. It's popular and I get it and I but again I was in kubecon last week and Amsterdam and I came to realize that we need less shift left and more pull, right?

Maybe I I think So here's this is me now. Yeah, let's debate, you know, well I think for too much of the devops crowd. The answer to every question is let's let the developer.

Do it. Mmm. We got to do better testing and we need better test coverage developers should be handling testing.

You know what? We want more secure code. We want, you know security ads code.

We got to make these developers do better secure code. We got to make them more security conscious. We got to make them better security people.

We got to give them more security tools throw it on that developer and you know, we did testing it. Oh the CI/CD thing they got to understand what the CDs about David just been working in the get stuff and CDs on there too. And you know, we're giving a lot to the developer.

I screw them. They're the highest paid people here. They're the most in demand.

They're primadonna's anyway, and and why should I give it to them? And I'm not you know, I'm being facetious. Oh, yeah a little but the fact is Is I don't think it's realistic to think that our developers are gonna become security people.

Could they be security Champions as our friend and I'm missing his name with second, but he presented. Well his last name starts with it now. Is it Dylan Donovan?

Or just that's it? That's it. I loved his security Champions thing because I think that is realistically what we can expect from developers.

I think developers have to have a brief understanding of security. I don't actually believe that developers should do everything. So my hypothesis is if the security practitioner is doing their job security is more accessible for developer.

So during my keynote I focused on three things for the future accessibility transparency and accountability. My belief is that developers make decisions. But there is work to be done by a security professional to provide open test plans.

solutions that have already been thought about maybe even hardening guidelines making it easier for a developer to confuse of this that was that is the conscious but it is I'm gonna tell you I think this is unconscious. I'll help. Okay, I debit night.

Right and I publish right and I security during the day because that's just kind of how I've broken up. My little SecOps for me. If only the world were full of Shannon's though.

Yeah. Well, that's a whole another story. Yeah.

I think they broke the mold. Um, so, you know debit might and I think that one of the things that's really hard is a developer is going and finding amazing baked in Easy already secured things. Yeah, we're security is part of each of the components and and really those things are becoming more mindful themselves because otherwise you're left with this gift of I borrow this library and now I have to secure it and I don't have a hardening guideline and I don't know what I need to know and there isn't a threat model or an attack map or anything to give me a clue as to what was already considered for securing that particular component.

And so I think that you know, in essence if every developer, we're mindful about adversar. The start to me shift left is start with your adversaries and your customers. You know, so if you look your total population of who's going to use your product is mostly customers, right?

And some adversaries and the problem is that when you go to Envision what you're going to build that adversary component is super black box hard to understand. Okay. It's very opaque and I think transparency has to kind of come together so that you can get to the point where as a developer.

You can know. Hey am I getting rid of potential fishing or is there a possibility for this to be used by a researcher of some sort? How do you actually grasp that adversary segment in addition to what you do for features and things like that?

And so my belief is that that is the core area where there is actually still a large problem and in particular You know as you're building features, we always talk about we don't want to have customer friction and our pipeline, but we're really trying to put friction in for the adversary. And so when we make decisions and we're actually only considering customer friction versus adversary friction, and we're not really having that discussion around adversaries. My belief is not making a very good decision between the two Let me throw something else out at you.

Sure platform engineering. Mmm. All the rage over in kubecon last week.

Can we can we get platform Engineers to try to Define this environment for developers so that they do have. The kinds of things you're talking about. Um, yeah platform engineering is always been a friend.

I think if you think about what they can do in a platform they can bake in some logging capabilities. They can deal with things like authentication. They can start to harden some of the component parts.

They can make it easier to be a developer that does something specific on that platform and that'll take out a good portion of the problems. I think that but they can't do it all and that's the real that's the real Rob is you're still going to be bringing on core libraries and some of those things that are not going to go into the platform and I still believe that shift left as to find and continue to evolve into Sort of pseudo marketing capability really hasn't gone the direction that I've hoped it would go which is we're effectively coming together to help developers have accessible component parts that libraries are getting tested more frequently and you are seeing some of that now as an example, there are open source libraries out there that are actually getting bug Bounty and those open source libraries are getting CVS now. Yeah pretty incredible stuff.

The community is actually stepping up to start to rationalize people are getting paid to maintain their really critical libraries. I think that's a again altruistically fabulous out. Right?

No that was thinkable 10 years ago. Yeah, I don't disagree. but All good, right.

It's all that's all good. I'm not I'm not saying it's not gonna and that's a problem. I get into here at RSA.

We tend to focus on the negative sure and not on like really good things that are happening like that, but All right. we Here's another program. I don't need to go negative but they're softball.

Yeah. No, here's another problem. How it's come down the park is all of these things are fine and dandy and developers are willing to embrace it not willing.

We'll embrace it. But the security team has to pay for it and then the guy who's holding the person the security team. This is I they don't give me enough money.

Ah, and I got to buy tools for my security team not. for the developers and and so it becomes you know, there's two Eagles in the nest and only one of those two eaglets in the nest and only one of those eaglets are gonna make it and the one the little one that gets pushed out. Is the developer one, right?

It's common. I'll tell you yeah product security for quite a bit of my career. Yeah, it's very common for incident response to get the big bucks.

And the development side to get much smaller bucks. If you will also think that what we call cyber security these days is just Over it's over Broad. And so Ed's 40,000 people.

Well, no, this is amazing. I I will tell you I am the biggest fan of people getting together collaborative. But what I will say about it is my belief is that product security really belongs with Dev Okay and fair enough if you look at the cyber security office the most companies.

Sometimes it's included in and the conversation between product security and cybersecurity is so Divergent. and the conversation is so You know bookended if you will that my belief is that becomes even challenging inside of an organization to to bring those together. And so now, you know product security sitting inside of a cyber security office.

You're not close enough to the devs. So you're not on their Island and you're not really speaking the language of cybersecurity. So you're not on that their Island, so it's it's been challenging and I've actually done a lot of studying around this I've seen companies put it into Dev And then there's something that happens and cybersecurity challenges and again, no land bridge and then I've seen it inside of the cybersecurity groups and and then devically doesn't have what they need.

So they start to go Rogue and they buy their own products and then you've got sort of a Frankenstein product security organization. Yeah. Yeah, it's worth you have Night of the Living Dead but some zombies apocalypse going on there.

I would admit admit. So I do think you know Alan that organizational structure if you look at what caesa said in the last few weeks about organizational structure and what needs to happen within companies and the escalation of issues within those companies, you know, my belief is that we still haven't seen the best options of organizational design that really allow for security to be part of product development and having just been a product security. professional at the last couple of companies I would say there was always a balance to try and figure out how do I speak the language of one but focus on the other and you just get split apart on it.

Well that and that there is that's in it. That's I think part of the issue, right? We can't.

And it's funny you talk to the one one, you know the dev side of it. They're like no. No you the Mohammed has to come to this mountain and you speak to this side and they say no the mountain has to come here to Muhammad.

Yeah, and they probably got to meet in between midway somewhere but it's hard. It's a hard thing. Well one of the best options and I'll just say this out loud is that accountability thing I mentioned my belief is that if VPS of engineering sign their secure ability reports or their pen testing reports are they they actually have to submit something that has nav testation right for all the work.

They've put in to cyber security for their products you get the best Outcome and here's why because now there's incentive for that VP of engineering to go find their friends to help them to be able to make those products as safe as possible and that can start to create the Consulting environment the tooling environment all of the ways in which that can come together. So my belief is we're gonna see this Forefront especially with sea starting to push s bombs coming to life all of these things that really the VP of engineering the SVP of engineering whoever the product capabilities are within a company or the digital transformation or whichever on the engineering side that as they take on that accountability responsibility. It will actually invoke the right model for being able to create better safe or software.

cool well It's time for us to Pivot. Yes, okay. We're gonna pivot now over and let's talk about what you doing now.

Rave Community. Yep. Yep metrics.

Oh and I'm excited. Okay, many many years ago. Maybe not say how many?

I started a metrics company. It was a little bit of ahead of its time and I'm a big fan of measurement. My belief is that where language within companies creates cultural divide numbers can bring you closer together because it's the ability to transcend right?

It's the ability to create that land bridge if you will. So this last few years. I've done a lot of research started to build a metrics framework not trying to replace metrics out there already, but simply bound them to something that's gonna allow you to create some sort of sure mechanic My belief is that when we say security that's the quote sees those job when we say engineering.

That's the development managers job. Right? And my belief is that software trust is all of our job and that really customers want trustable software.

And so what I'm doing now is essentially establishing a community called Rave Community Rave dot Community if you're looking for it, there's a survey and in there. I've bounded the metrics. So what is Rave resilience adoption velocity and errors and my belief is that those are the four pillars of establishing a trust relationship.

Can you do me a favor? Sure. Can you look into this camera and give me that again?

What is Rave stamp? Yes, so Rave stands for resilience adoption velocity and errors and in combination and balance to cross Rave is essentially the four pillars about creates a trust relationship. Allows you to create trust among customers among your engineering teams.

And my belief is that that's something that has to happen. actually so How do we out here in TV Lance? Help help grow this community help get you the kind of metrics.

You need to start. You know churning this and and making sense of things. Yep.

Absolutely. So if you go to Rave dot Community, you can take the survey you can put yourself into the newsletter. We're just getting started one really cool thing.

We're gonna be doing over the summer is starting a bracket league and we're gonna be debating about metrics. So I'm inviting anybody who's got a strong passion for metrics debate to show up and be part of the Throwdown eventually. Well, we're thinking about having a cage match if you will.

Oh and really kind of retirement but good. Exactly. So Allen, which metric are you thinking about?

Oh you I almost stepped in this the other night, but I'm gonna let develop a little bit and then pick my metric that I really feel strongly about it fabulous fabulous idea. So yeah, this is just getting just that morning. org where taking some of the community members that are out there and starting to build standards that are necessary for product developers because it's really hard to find great advice that's actually develop or accessible.

So we're spending some energy on what things do you need to know for pen tests that might be coming up what types of testing do you want run on your products? org. That's right.

Neither of these are well Rave doc communities up and running the software trust is just getting started just getting started and that's really aimed at product development. It's very aimed at product development to provide guidance around what you should do to create that accountability and self-ass station. I love it.

Yeah, lots of fun. You know what Shannon? What are you gonna do in your spare time?

You know, I'm gonna go sit by the beach and take long walks and no s*** has a lot. You're a mom I do. Yeah, you know what, you've got a family and a career and you're like a superwoman.

So I'm having fun zero. org revamp. Got up here.

Nice. Yep adding some horses that yeah, I was dormant for quite some time. No.

com would we'd love to be involved in that leave. Let me know what we'll talk. Well, yeah people call my people.

Will that sounds amazing? All right. This was a nice 15-minute interview.

Thank you. You're welcome. Hey, I hope you enjoyed this because it's not often.

You can get that much of This Woman's time. So Consider yourselves lucky, we're gonna take a break. We've got time maybe one or two more interviews here at RSA before we wrap.

Thank you for joining in we'll be back in a minute.