Scroll

The Compliance Episode - History, Theater & Industry-Reshaping Impact

First, a confession: this is the last episode we would have envisioned when we started Security Voices. Compliance was as mundane as it is mandatory– where’s the fun in that? Where’s the untold, fascinating story of the person who summited the tallest mountain? Rose from ashes to improbable success? 

In the short years that have passed since we started in early 2019, the world has changed dramatically. And so has compliance. From driving cyberinsurance premiums to becoming the security baseline for even startups to achieve in their early days, compliance is now an undeniable juggernaut. While SOC2 defines the scope of many companies’ security gameplans, GDPR and its kin drives how we respond to breaches whereas industry specific mandates influence what data we have, how we defend it and even where we store it. 

In this episode, Jack and Dave welcome both Abby Kearns and Shrav Mehta to demystify exactly what’s happening in the world of compliance from 2 unique perspectives. Abby speaks from her work on software assurance as CTO at Puppet (and beyond) whereas Shrav’s angle is that of a compliance startup CEO. Plainly stated: code on one side, standards and certifications on the other. Both increasingly important and horribly complex. 

This 4 person dialogue traces the roots of compliance back to the early days of security and the inception of PCI DSS, one of the first widely impactful compliance initiatives to hit the industry. We chart the course of compliance to today and unpack where it has had meaningful impact… and where it is mere box-checking theater we could do without. 

In a similar fashion, we examine the path to software compliance today and the inevitability of automation given the dramatic changes in release speed and frequency. Abby provides a sober take on where we are today including a dialogue on what it means for response to threats such as Log4shell. 

If you’re a longtime listener, this episode connects back to so many of our past interviews, from Carey Nachenberg (supply chain security) to Andy Ellis (compliance perspective) and Nand Mulchandani who recently became CTO of the CIA. We hope you appreciate the references if you already heard this episodes, and if you haven’t, consider giving them a listen as they’re some of our favorites and pass the test of time with flying colors.

About this episode

First, a confession: this is the last episode we would have envisioned when we started Security Voices. Compliance was as mundane as it is mandatory– where’s the fun in that? Where’s the untold, fascinating story of the person who summited the tallest mountain? Rose from ashes to improbable success? 

In the short years that have passed since we started in early 2019, the world has changed dramatically. And so has compliance. From driving cyberinsurance premiums to becoming the security baseline for even startups to achieve in their early days, compliance is now an undeniable juggernaut. While SOC2 defines the scope of many companies’ security gameplans, GDPR and its kin drives how we respond to breaches whereas industry specific mandates influence what data we have, how we defend it and even where we store it. 

In this episode, Jack and Dave welcome both Abby Kearns and Shrav Mehta to demystify exactly what’s happening in the world of compliance from 2 unique perspectives. Abby speaks from her work on software assurance as CTO at Puppet (and beyond) whereas Shrav’s angle is that of a compliance startup CEO. Plainly stated: code on one side, standards and certifications on the other. Both increasingly important and horribly complex. 

This 4 person dialogue traces the roots of compliance back to the early days of security and the inception of PCI DSS, one of the first widely impactful compliance initiatives to hit the industry. We chart the course of compliance to today and unpack where it has had meaningful impact… and where it is mere box-checking theater we could do without. 

In a similar fashion, we examine the path to software compliance today and the inevitability of automation given the dramatic changes in release speed and frequency. Abby provides a sober take on where we are today including a dialogue on what it means for response to threats such as Log4shell. 

If you’re a longtime listener, this episode connects back to so many of our past interviews, from Carey Nachenberg (supply chain security) to Andy Ellis (compliance perspective) and Nand Mulchandani who recently became CTO of the CIA. We hope you appreciate the references if you already heard this episodes, and if you haven’t, consider giving them a listen as they’re some of our favorites and pass the test of time with flying colors.

Meet our guest

Abby Kearns and Shrav Mehta

Abby Kearns: Tech Executive, Shrav Mehta: Founder and CEO of Secureframe

Abby 
Abby Kearns is a tech executive as well as a board director and angel investor. Her career has spanned executive leadership, product marketing, product management, and consulting across Fortune 500 companies and startups alike, including Puppet, Cloud Foundry Foundation, Pivotal Software, Verizon, and Totality. 

Shrav 
Shrav Mehta is the Founder and CEO of Secureframe, a provider of security and compliance software to help streamline SOC 2 and ISO 27001 compliance, and backed by Accomplice Ventures, Kleiner Perkins and Gradient Ventures (Google’s AI fund).

Transcript

[00:00:00] Shrav: There's just a lot of weird things about this industry.

[00:00:10] Abby: I think a lot of companies aspire to that.

[00:00:16] Shrav: Here's my controversial opinion. Maybe it's not that controversial, but in 10 years, SOC two, won't be around.

[00:00:24] Abby: You always have those rogue dev environments that someone spun up on easy two instances, and then forgot about six months later. And, oh, we actually have real production data sitting there too, but we completely forgot about

[00:00:40] Shrav: we've had encryption in different forms like cryptography since like you a hundred BC,

[00:00:48] Abby: uh, supply chain really needs to be top of mind. As we think about security,

[00:00:54] Shrav: a lot of this feels like security questionnaire theater.

[00:01:00] Abby: Does this podcast count as fun?

[00:01:11] Jack: Hello, and welcome back to security voices. Dave, we've got a couple of people on this 

[00:01:16] Dave: month show. Yeah, the rare but not unique four person show today and topical. I think the last time we did this was with the hysterical material security crew, where literally we just wallowed in the randomness and intellectual horsepower of Ryan and Novacek were freaking brilliant and just raised a big round of money in.

[00:01:37] Jack: I saw that as I recall, there might've been an explicit tag on that episode. 

[00:01:42] Dave: Yes. And a well-deserved one. So come on security voices and you'll raise a massive series B round. It's not mulching. Donnie has ended up being the CTO of the CIA since then. So, you know, very quietly, you know, Abby and traveling.

Good things lie ahead of you. We have no clue how the hell we're correlated to it, but somehow I don't think we're. Kingmakers as much as we are like a lucky rabbit's foot 

[00:02:08] Shrav: or maybe like a magic eight ball. I don't know. I mean, at this point it must be directly correlated. Like you go on the podcast and you know, you become CTO, right?

Yeah. Yeah. 

[00:02:18] Dave: You'll end up in the intelligence community and a huge position that happens to everybody on the show. 

[00:02:23] Shrav: I'm credible, 

[00:02:23] Dave: straight, straight through, came onto the talk about robots and human interaction is 

[00:02:28] Shrav: destined for the NSA. 

[00:02:31] Abby: That's good to know. I'll update my LinkedIn right after this. 

[00:02:33] Shrav: Yeah. Be 

[00:02:34] Dave: careful Jack how's retirement.

This is the first one we've had you want since you were tired a few months ago. How's it been so far? Give us a quick retirement. 

[00:02:44] Jack: Well, let's see, I've taken a few classes, one maintenance thing for stuff I use, but also I spent a week up at the John C. Campbell folk school in the mountains of North Carolina and did jump-started my blacksmithing, which I haven't done in years.

I've already signed up to go back to the folk school and build a guitar in September and find up to be a tales with a cocktail in a few months, officiating friend's weddings later this summer running up to. A little local festival, the white squirrel festival in Bravard, North Carolina next week, building things around the house, taking the second house and updating it.

Basically, I am busier than I've been in years and years and years. If I need spare time, I'm gonna have to get a job so that I can slack off and have spare time because this is running me ragged, but it's a blast. Do 

[00:03:34] Dave: you have more 

[00:03:34] Jack: Headspace? Yeah. I don't know if it's unique, but there's a lot of stuff that I have done off and on through the years and wanted to get back into woodcarving and blacksmithing particularly, and I have the time to do it.

And so it is some of the things I want to do have goldfish to fill the bowl. And also I have I'm down here in coastal Georgia, where things grow year round. And at this time of year they grow insanely. So I spend it just a ridiculous amount of time wandering around hacking shrubberies back and mowing lawns and things like that.

But it's all good. It's all good. Yeah. I've been trying to do everything at once. I may settle into a rhythm or it may just continue to run wild, but it's great. And I'll, I'll stop sending you emails, Dave, with all of the awesome things I'm doing while you're trying to just keep your head slightly above water.

It opened Raven, you almost 

[00:04:23] Dave: succeeded in hurting my feelings at one point. Yeah. 

[00:04:30] Jack: Yeah. Well, you know, your, after you run your course at open Raven and do your time at NSA or CIA, wherever you land after the podcast, you can, you can retire to 

[00:04:42] Dave: sandwiches for non at the CIA. I think, I think his, his executive assistant is, is my, my future after this.

Well, we'll see. So our guest today are Abby Kurds and Schroff Metta. And oddly enough, how this episode came together is I was driving down. To San Diego, actually the morning after the famous Dave Chappelle Hollywood bowl incident. So my wife Jane had gotten us tickets to go see that. And I drove up from San Diego and back because I wanted to see it.

It was amazing. And I was talking to Abby and we were catching up and Abby, you and I met a few years back when people still did conferences and that sort of thing at Vail through the amazing Amy Hermes, I think the mosaic program. Yeah. And we were talking on a number of things. And Shabbat at the topic of compliance.

And I was headed down to a conference in San Diego, which shall remain nameless. I ended up sitting right next to Shroff for lunch, who happens to head up a Kleiner Perkins portfolio company. We're poor CO's, as they say, he does nothing less than lead up secure frame, which also does compliance. So in my head, my little synopsis fired and mash these things together and thought it'd be amazing episode, just to talk about the different nature of compliance.

I mean, there are two very different things. You know, one you can think of as, as, as words, the other one is more technology and both conversations could have sparked in different direction, but the overarching theme, the ligaments behind it were clear. But before we get into this thing, it's important that everybody understands your individual perspective.

So Abby, why don't we start with you? Can you give us the Abby current story and two minutes. 

[00:06:26] Abby: So today I am CTO at puppet. So I run product and engineering here. We obviously grew up at and through automation spent a lot of time thinking about compliance. We even have a compliance product. I am also a active angel investor and a lot of the startups I invest in are in the security space.

And I sit on the board of a company. And so I spend a lot of time through a variety of different ways, thinking about security and compliance in terms of both product, but also as a user and a consumer of those. So it's a it's top of mind for me on a lot of different levels. 

[00:06:59] Dave: Cool. And give us one fun thing.

Like what do you do when you're not parenting? When you're not working? Give us something outside of. 

[00:07:07] Abby: Does this podcast count as fun? Like it's connected to all 

[00:07:10] Dave: this, this, so it's fun for us, but it's not really a hobby. Like if your hobby is being on people's podcast, your hobby probably sucks. 

[00:07:19] Shrav: It's true.

[00:07:20] Abby: My husband's mad at me cause I actually don't have any hobbies. So I usually tell people because I like to eat and drink good food and good wine. So I was like, that's my hobby is eating and drinking. So I don't know if that's something that could be a hobby. 

[00:07:32] Shrav: All right. Yeah. Yeah. 

[00:07:33] Dave: That's your Epicurean.

Isn't that the fancy name for it? We just need to gussy it up a little bit. Like I'm actually at an accomplished Epicurean that there you go. 

[00:07:44] Abby: And we'll use that. Thanks for class and me updates would have just gone with, I like to eat. 

[00:07:50] Dave: I'm here for you. All right. SRE safe. 

[00:07:54] Shrav: Right now I am the CEO of secure frame.

We started secure frame almost three years ago to basically solve this problem of helping companies get secure and, you know, get compliant with these certifications and standards like SOC two ISO 27,001 HIPAA PCI. And, you know, we worked with over a thousand customers today to help with all this. 

[00:08:13] Dave: Got it.

Your background was not insecurity whatsoever. 

[00:08:16] Shrav: Was it? My background's pretty varied. I always knew I wanted to start a company and I spent a lot of time like doing engineering and product early on, but I never really understood the business side of companies. And like, how do you get all this stuff to work?

So, you know, I spent about four or five years really just understanding the inner workings of like finance, legal sales marketing. And, you know, I ended up really, really liking it today. It's helped a ton in, you know, building secure frame, 

[00:08:44] Dave: but what was the idea behind the company? Like what was the moment where you're like, this is what we're going to do.

We can automate compliance for. 

[00:08:51] Shrav: So I was exploring, you know, a lot of different ideas, you know, in the security space. Some actually like, um, you know, in the recruiting space as well, both spaces that, you know, have just fascinated me for, you know, as long as I can remember, I had gone through these like compliance certifications, you know, at previous startups I had worked at and, you know, as like kind of the business person with like the engineering background and these like security reviews and stuff kind of always fell on me.

So when we had gotten our first, like SOC two and you know, this company law that I'd worked at ages ago, it was a very complex process. Like we just couldn't really figure it out. We had spent like a hundred grand and consultants and security people and really like, we had gotten nowhere. So I read like the 400 page manual.

Myself to figure all this stuff out. And I was like, okay, this isn't actually that bad. And you know, we got through the process. And after that, you know, I had a ton of people kind of asking, how'd you do it? Like, what is this like, magic that you've like, discovered to like, get this thing that's called a SOC two by about 20 18, 20, 19.

I just had a lot of people coming to me asking for advice. And I started asking them like, Hey, if I, you know, built a product to automate this, you know, would you use it? And I think like, just really asking around exploring, and a month later someone called me and they're like, okay, so do you have it ready?

Where is it? And I was like, oh no, I don't have it ready. I'm just exploring it. But, you know, I basically quit my job at that moment and, you know, started building out like the full MVP and, you know, by the time we'd launched, we had like 30 to 40 customers or I think a lot more than that, ready to use the platform.

And that's kind of what I knew, like, okay, there's something like here that people really, really need, and we just have to. 

[00:10:23] Dave: Yeah. If you're willing to read a 400 page manual, you probably should start a compliance company. Like your that's in your DNA, man. Like, I don't know what it would take to get me to read a 400 page manual.

It's more than a bottle of Cabernet. 

[00:10:37] Shrav: That's for sure. Once you lose a hundred thousand dollars and you have like a very demanding boss, I was like, where is this? You're just like, okay, I'm going to read that manual right now. All right. 

[00:10:46] Dave: A little bit. I should've mentioned this before, so sorry to jump this on you, but I got it.

This hysterical message this morning from a person named hunter Moore, which I suspect is not a real human, but he said, hi, Dave, reaching out about a search for VP of product, that secure frame, a series B company backed by Kleiner, Perkins and so on. So I'm wondering like, what do you think shrub? Do I have a chance?

Should I put my name in for it? 

[00:11:12] Shrav: I think we will. We'll take you any day. 

[00:11:15] Dave: Um, so good to know. It's a backup plan. I I'm planning to make sandwiches for non, but if I don't after open Raven, I'll give you a call who put out a book, what timing. The universe has spoken. All right. So we're going to step in the way back machine here.

And as often, so I was doing show prep over the weekend and kind of musing as one does in the shower this morning about compliance and the origins of security. And I realized that a lot of my perceptions of why people use security come from my own bias and early days of security. When we were seeing things like Dan farmer and Mitzi Venema came out with the Satan tool where, and people were losing their minds because they felt like, you know, Satan was going to be the downfall of all of our networks.

As people used it to break into things my time with internet security systems and even Deloitte and Touche, like people were doing security because they realized in, in my experience that it was better use of their time to do that than to try and clean up and deal with the aftermath. There really wasn't any compliance angle that was driving people at that time.

And I think in getting ready for this episode, and this is one of the reasons why I enjoy it, even the prep work is it forces me to think in a different way. And just how much things have changed in the landscape as security has grown up. Oh, throw this to Jack first, like in your estimation, Why did you see people and why were you doing security work in the early days?

Was it compulsory or was it really driven just by people trying, looking at this and saying, if I don't do this, the pound of cure is going to be a hell of a lot more than the ounce of. 

[00:13:00] Jack: Personally, it was, I ended up doing more and more it stuff through the nineties and nothing was secure. And so you learned about security, whether you want it to, or not.

If you were running particularly windows in T4 environments and the vendors that were selling you, stuff didn't know what they were doing either. And as soon as you connected things to the internet, you were screwed and you either figured out how to secure things and found the challenge. Interesting, which is my story, or they didn't, and probably found other people to do it for you.

We go back to why people do security in my history project, the shoulders of InfoSec, the early stuff was largely out of government and military, the intelligence community, the military community. They knew what they were protecting. Right. And they had to do it because it, the consequences were well, they were worse than failing your PCI assessment.

Let's just say that. Yeah. Yeah. And as people left that field or left government left military and intelligence, they took that into industry, knowing the value of what they were doing, I think was part of it. And so there was that sort of history. And that's why, when you look at the history of security, it's interwoven with encryption, with cryptology, because it was privacy and security were kind of interwoven.

And that led us to some of the folks like Diffie and Hellman and roughest engineer and Edelman and others, Merkel and crew who were concerned about personal privacy. And that led us into, you know, the modern, personal encryption. There was another angle. And then as you mentioned, uh, Dan and Satan and all of those pesky hacker kids, many of them own companies now, or have retired from companies, you know, there were coconut things and there were a lot of people who didn't want to do security.

But we're publicly embarrassed and maybe humiliated, but certainly publicly embarrassed and we're, we're forced into doing it. And so I think there's a whole bunch of stuff. And then, you know, somewhere along the lines, people started saying we should do these things. And then as much as I've had frustrations with PCI, the externalities there of, if I'm an irresponsible merchant and somebody comes to you with the card that I've let the lost Dave, you as the, as the responsible merchant, get a charge back because somebody, if I lose a customer's data and then they use the credit card elsewhere, it's not me.

That takes the hit. So that externality, of course, you know, the card brands could have done a whole lot more. Minimize that, but that's another rant. And, but anyway, yeah, so there's all sorts of stuff that's going on. And then once the costs of failure, once the cost of compromise started going up, then it starts to become a board issue.

It becomes a compliance issue for a whole bunch of reasons. Now there's this very simple, easy to understand landscape of compliance requirements that everybody faces. And it's just really easy to understand there's snow, right? It's an overwhelming nightmare, but it's also, it may be a business opportunity for some folks too.

So I'll hand it off at that point. 

[00:16:10] Dave: My first experience was really with PCI DSS, where we looked at it. And at the time I was at ISS home of internet scanner, we were trying to get a relationship going with marsh McLennan and cyber insurance. This is like the late nineties. And it was kind of funny when, when cyber insurance finally became a thing last decade, it was, it was like it, like we'd been waiting for a good dough.

It's like, oh God, I it's, it's a thing now because we were trying to do that. But the thing that actually stuck was PCI DSS because people at the time were just doing vulnerability scanning when the consultants came in and all of a sudden PCI DSS made it a mandatory thing on a quarterly basis for anybody who was handling payment cards and so on.

And as a consultant and someone who is out doing a lot of scanning, I went on to fountain stone from there, you could see the power of it. It was one of those moments where it's like, oh, I get this. Like you should, these companies be doing this already. They absolutely should. And it kind of sucks that they're forced into it, but you look into.

This had a real impact in making people do the right things. And I still to this day have not excited about it because you look into your leg that is so men bar, like, what the hell are you doing if like, if you were compelled to do this, and this is the foundation of your security program, like shame on you.

But having said that, you know, I sit back from a greater, good perspective and say, thank God it's there. You know, I think what's happened over time is I step back and I'll open up the floor after this, to, to Abby shrub and so forth. But what's happened over time as technologies become more complex and things started moving so fast is I've come to grips, kind of with compliance.

I still don't want to build a compliance product. Like we have compliance use cases. We hit, I just, I don't get excited about checking the box for someone like high five, Dave, you know, you check the hell out of that box, but having said that. The GDPR when GDPR hit, when we were at CrowdStrike, all of these questions started coming in on data retention and where the data was and so forth.

And honestly that influenced us, you know, starting open Raman and part of that direction because they were hard questions to answer. And I realized shit, we haven't done anything on the retention side for this. And all those people who think the big data just expires itself out. Like that was one of my first revelations.

It's like, oh, we actually have to build data exploration into Cassandra. Ain't that a thing? Yeah. I just, I, I think from my perspective, it's a God awful mess as Jack was saying, but the big compliance, these, these words based policy standards for the industry they're beyond necessary evil, which I think was my original thinking.

And even me coming into this and they're just necessary. At this point, 

[00:19:02] Abby: agreed. I also started on the PCI front. I started many over two decades ago. I started my tech career in doing large e-commerce installs. And the early days credit card information was stored in clear text and databases. There were not a ton of requirements on how that data was protected or accessible and who was accessible to.

And when PCI DSS came through, it allowed me as a consultant for these large installs to be able to tell you, okay, we can't actually store credit card information and clear tax on a database. We have to be careful who has access to that credit card information because your brand is now affiliated with a risky situation.

Because at the time this was 2000, 2001 people still weren't comfortable putting their credit card in a website for companies that were making the shift to starting to. For e-commerce to be a major channel of revenue and a shift digitization of the business. This was a big leap. And I think PCI DSS was a really great forcing function to say, this is now a requirement.

You have to do this. It is no longer a, you know, you should do this, which I agree, David, it's sad that we required, but I do think it's a necessary evil. 

[00:20:18] Dave: All right. So we, if we step back here a little bit, and then I want to tag you in for your perspective on where we are shroud, but I'll tease it out just a little bit more.

So SOC two's become a huge thing. Now we have GDPR and data privacy standards. We have, I think it's ISO 2 7, 7 0 1, uh, kind of a global privacy standard that you can ascribe to. So the Europeans. Doing business with us a little less. My description of it, I'm pretty sure that's not the standard. There's all sorts of certifications.

And of course we have to mention FedRAMP as well. You know, these things play into stuff like, Hey, if you do the certification, your cyber insurance premium goes down. It's easier to do business. You can sell to a big company. Now, even if you're a small company, if you have your SOC two type one type two, and so on, it's such part of the fabric of what we're doing.

It's unsurprising to see companies like secure frame and the others in this space doing well because it's time consuming as well. The entire process. So it's interesting where we find ourselves today. And I think also the other piece of this that was interesting to me is when Obama came out and basically Christen the NIST CSF and said, this will be the standard for the country's critical infrastructure.

It also became the standard of due diligence for companies that go into. When they're graded effectively on how well they've done and how well they protected things and whether they've been negligent. So on, it's just permeated so many aspects of what we're doing, but let's step back for a moment. And they're like, you're right in the middle of this shrub.

What do you see today? If you were to like, give us a two to three minute or, you know, take as long as you need, give us kind of zeitgeists like, where are we at right now with respect to industry standards and compliance. And so. 

[00:22:17] Shrav: I mean, there's kind of a long history of these certifications. So, you know what we now know as SOC two actually had a look, a couple of different names and, you know, the requirements were different over the past decade or so.

And it used to be called SAS 70. And before that it was called something else. And we have standards like ISO 27,001, which is kind of like what I call soft twos, international equivalent. You know, if you're selling, you know, outside the us or Canada, you know, typically, you know, into Europe or Australia, like that's where ISO 27,001, you know, tends to be, you know, more common and more.

But you guys brought up a good point. Like these, you know, just because someone has a SOC two or these ISO 27,001 certifications, like, doesn't mean you're secure. You know, I have companies that come to me and they're like, oh, I have a SOC two. That means we're secure. We're totally good. And I'm like, well, you know, as, as much as I'd love for that to be true, it really isn't the case.

I really see like SOC two and some of these certifications as like the base layer, you know, for your security program, you know, you kind of brought up some of the reasons like, you know, why, you know, where people implementing security and stuff in the past. And I think, you know, one of the reasons why people end up getting their SOC two so early on in a company's life cycle, you know, before you would be crazy to be getting and investing the effort to get us off too, if you're like under a hundred employees, just from like the pure resourcing constraints, like, you know, is it really worth it?

Are you going after the type of customers that will expect this? Now it's something that I see companies that are just like two to three employees, you know, getting a headstart on because they can't even sell to another startup or SMB or mid-market. Not just the enterprise without having one of these certifications.

I mean, when I talk with, you know, a lot of these customers, you know, this is the first time, like they're kind of doing anything security related and you know, many of these software engineers, technical founders, like, you know, they don't have a security background. They don't exactly know all the right things to be doing.

Like, you know, if you tell them what to do, they can usually figure it out. But there's just such a giant laundry list then. And it can change depending on like the framework that you're using, the product that you're building, the type of risks that you might be exposed to. So when we talked to a lot of these customers, like they have nothing and now getting like a soft two in place gets them that like, you know, simple base layer for those folks who are like less familiar with like, you know, what these compliance standards actually are, you know, even security folks don't really understand them.

Cause it is a little bit of a different world. They're just giant lists of things that you have to do in order to secure your business. There's 

[00:24:35] Dave: some surprising stuff in it to your point, like we're a small team. And all of a sudden they're like, Hey, your SOC two requires you to do performance reviews.

It's like, what the hell? Like, suck really like, really like come on now. But it makes sense. Like when you get into it, there are things that are kind of, they're pretty tough to argue with. And the one thing is you were talking about that, that I think really bears mentioning that you kind of apply, but let's just state it explicitly.

Part of this is absolutely supply chain too. And it's perhaps not even so much that it provides real help. I mean, doing your SOC two is not going to prevent a whole bunch of supply chain issues. I mean, those are actually almost the domain of the stuff we'll talk about with Abby, with respect to software compliance and kind of making sure that you have the right technical policy in place.

So less words, more code and that angle of compliance. But having said that, nonetheless, if somebody gets hacked. And they didn't have a SOC two type one. And you get asked like, well, did they fill out the SAQ? Did they have their SOC two type two? Did you do that? You've got egg on your face as the company that got hacked by transitive properties.

Right? So I think the supply chain issues we had and just how interconnected we are, because we all use it, the Jillian SAS services, and, you know, our applications are a collection of services, some of which are owned, some of which are others. I, we almost don't have a choice at this point. 

[00:26:06] Shrav: Yeah, 100% today, you know, we haven't had any of these issues.

We have had, you know, actually companies come to us like after a security breach saying like, Hey, we actually like need to get some of this stuff in place. And like, let's have an auditor, you know, verify that we're doing all these things. But you know, what's interesting about this compliance aspect of security is we've had encryption in different forms like cryptography since like 1900 BC and AWS, you know, all the different cloud services that we're using have amazing products around this, but half the time we just haven't flipped on the switch to turn on the encryption.

And, you know, if you have thousands of servers and different resources that you're managing, it's super easy to let something slip up. And that's kind of the problem that companies like secure frame, you know, we're here to solve like, Hey, did you actually turn on the encryption that was readily available to you?

And I'll tell you, you know, most companies don't actually even know that these features are available to them or that they should be turning these on. And this is like the first time that, you know, they're going through it and getting all this stuff done. So. Someone gets like a sock two with secure frame.

And we have like scoped out specific resources in that audit. We have verified that they have encrypted it, and that is not like a way for an attacker to get in. But you know, of course there are like thousands of things that aren't codified in like the software requirements or really any security guides that, you know, someone can come into or someone can use to break in.

And yeah, we can't cover all those cases. So when someone tells me again, they have a SOC two, you know, it doesn't necessarily mean you're protected from all breaches. It's kind of just like a layer of protection. You've 

[00:27:33] Dave: no doubt had to do SOC too at puppet. Yeah. 

[00:27:37] Abby: We're starting down the process, but 

[00:27:40] Shrav: a little open 

[00:27:41] Dave: Raven.

Got it. SOC two before, before y'all 

[00:27:44] Abby: we are mostly there. I will say that I liked shove your point on it. Doesn't guarantee security, but there are some like table stakes things that you should always do. And I do think stock too is a good reminders. Like, Hey, MFA, you got that in place. Hey, you know, I think it's a good reminder about certain things, brands, protection, things like that, that I think are table stakes.

And it's always a good reminder to have done, which is not always, you know, things we often think about out of the gate, right? 

[00:28:16] Dave: Tug at this a little bit here, how much of this has gut feeling? And I think it changes on the organization, but how much do you think the certifications are actually driving security improvements versus.

I know, creating a bit of theater. I think it might be interesting to see which areas we think actually drive the biggest improvements in which areas we think are really just fluff. Any opinions from you all on 

[00:28:44] Shrav: that. 

[00:28:44] Abby: I'm sure Strava Chavez a lot of opinions. I will say, I'd say 50 50 is theater and 50 it's actual good reminders.

Like, you know, I say having something remind you to do MFA everywhere or all the pain in the ass stuff that, you know, you need to do, but you haven't quite implemented because you're like, well, you know what? Let's not make our lives too complicated. At this point in time, there are aspects of it that are a really great reminder for us to all do the right hygiene that we know we should be doing.

We just haven't gotten around to doing, but then there's a lot of it that is, I mean, it is theater, but I also think it's part of, you know, risk mitigation, like covering your ass too and say, well, we did all the things, so we're good here. Right? We're not going to be liable here, which I think is really where the point we were making about the difference in the last two decades, with the way we think about security in the class or the way we think about it.

Now, as it turns out, you can be liable. It turns out you will be held accountable. And by the way, they want real transparency around breaches and exposures that I think has fundamentally changed the dialogue. Whereas 15 years ago you reported it and you didn't report it. 

[00:29:52] Dave: That's a good point. And I can think of another area where I think it really does help is the rules around basically people trying to manage the scope of HIPAA or PCI DSS by keeping sensitive data only in one place just by limiting the many places it can go, which of course is helpful for our business.

But also that there's real value in that if the data is not there, if it's in fewer places that are better controlled, that's real security. You contrast that with like some of the stuff in there about disaster recovery. I can tell you, like, I'm not going wait up, wake up at night, worrying about disaster recovery for like a young company.

You know, we're not doing tabletop exercises on what if, what if there's a catastrophic failure at Amazon? We're not powering NASDAQ today. Right? I mean, people don't die. Some of that stuff is a little fluffy and even a little over done. But having said that, yeah, I can think of a few areas. And I think also the discipline round pen testing too, like it does put you on the clock.

Like every company, even security companies need to do that. There's always value in it, but it does put you on the clock for it in a way that I think is helpful to the organizations. All right. How bad it, man, where's the fluff, where's the fluff and where's the good stuff. So usually 

[00:31:12] Shrav: the way I like break this down to companies, they'll say something like, oh my God, this is going to take like five engineers, like months to like figure this out.

And it's really like, not super, super complicated, especially for like a smaller company that doesn't necessarily have all these processes in place. But what surprises a lot of people is, it's like 50, 60%. Like non-technical, you know, things like, Hey, we gotta make sure that all our employees get background checks that we have like confidentiality agreement signed with everyone.

And this stuff is like important. What bothers me is like a lot of this stuff is like, it doesn't feel like true security. I think this stuff is important, but it should probably be like two different certifications. Like, Hey, this is some of the legal compliance, operational security is maybe what I would call it.

And then here's like the actual, like hardcore web application security pen testing and all this stuff in like a separate certification, like both are important, but for different reasons. And I think that confuses a lot of people. Now there's definitely things that in SOC two that I think come off more as like security theater.

And, you know, you have to kind of think about the history of like, where are these certifications came from? And who's, you know, designing these certifications, like the ISO 27,001, right? This is created by the international standards organizations, like the people who create like your date, timestamp and standards for like manufacturing facilities, like ISO 9,001.

And there's all sorts of different things that they're doing. And the SOC two certification or, sorry, technically it's a report, not a certification. If people are going to nitpick on this podcast, But the SOC two report was created by the AI PA you know, the association of certified public accountants.

These folks, you know, mostly focus on like, you know, financial rules and things in that nature. So this is kind of like one of the few certifications that they have that's, you know, more related to security. And my assumption is that's why we see a lot of these more operational practices in there.

There's also like just a lot of old stuff that doesn't really apply today. These tabletop exercises, disaster recovery plans, like this was stuff that it feels like it was invented for the modern role of cloud computing, where a lot of this stuff is just a couple of button clicks. It's really not as bad as it once used to be.

Here's my controversial opinion. Maybe it's not that controversial, but in 10 years, SOC two, won't be around. There'll be a new set of standards and certifications that I think are more aligned with like modern. 

[00:33:26] Dave: Ooh, that's intriguing. So there won't be 

[00:33:30] Shrav: a SOC three. There is technically a SOC three. It's just one of your SOC two report.

Yep. There's like a soft one to that. 

[00:33:38] Dave: Yeah. 

[00:33:39] Shrav: Here's another thing that, you know, I, I talked to a lot of audit firms and like now some of them are doing this and SOC two is a report that's typically given out under NDA because it might have like some potential like security information in it just really depends report to report.

And the SOC three is like the public version of your SOC two report that supposedly removes all this like potentially confidential information or something that could give attackers information maybe about how you operate from the security perspective. What's interesting is like, this is just a word doc that auditors are generating.

Why don't they just like click print on it a second time and give you the non-confidential version like that would, you know, make everything way easier for everyone. There's just a lot of weird things about this industry. I mean, speaking 

[00:34:21] Dave: of making it easier for everyone, I'll tell you one thing that I kind of personally find it annoying, but it is what it is.

And I think we're stuck with it is so you've got your do SOC two type one type two, whatever you do, and the rest of the standards, your still getting company-specific specific essay cues. And to a degree, many times they're asking the same questions. How do we get out of doing the double work here? You know, how do we, how do we step past this moment where like, we're just constantly filling out paperwork about some of the same controls that we've either already done, because they made a lot of sense or there's stuff that like, we've just created language around because it just wasn't, it simply wasn't that important.

[00:35:06] Shrav: That's a good question. In theory, like things like SOC two were meant to replace security questionnaires. If you look at a lot of these security questionnaires, they have a lot of the questions that SOC two kind of answers with the controls that are written. So you're kind of seeing like, Hey, why are people still sending these same security questionnaires?

Like I gave you my SOC two and you know, the SOC two, I almost think of it as like your first line of defense. And it gets you all the things to answer the security questionnaires in a way that doesn't, you know, trigger a lot of alarms at the company. That's sending you the security questionnaire at the end of the day.

I think what it really comes down to is like the it manager at that company who wants the questionnaire in their very specific format. Maybe there's a couple additional questions or the ways they like to ask the question, but boggles me. Why we still have so many security questionnaires. There is the VSA vendor security Alliance that is kind of aligned on a standardized security questionnaire, which is like a step in the right direction, still a security questionnaire.

But at least now a lot of companies like square and Dropbox are at least using the same security question. 

[00:36:03] Dave: And how different is it from a SOC two? I, I'm not sure if we filled out that one, what are they getting that they're not getting in a SOC two 

[00:36:11] Shrav: report? I mean, it really depends. Like, you know, some of these questionnaires can have all sorts of random stuff in there.

Some of them might ask, Hey, what MDM solution to use? Some of them might not, you know, I've seen questionnaires that are like, you know, a thousand lines in an Excel sheet long. And I'm just like, well, no one could possibly be reading this and actually care about every response in here. A lot of this feels like security questionnaire theater to me.

But for the average security questionnaire, a lot of it does get answered by soft to Jack. I 

[00:36:38] Dave: think it was Andy Ellis. I forget who it was, but someone made the comment. They're like, screw these questionnaires. He's like, if I want to find out about somebody's security, I sit down and talk to them and I ask them questions and we talk through it.

It might've been Andy, but, well, let's give him credit because brilliant. 

[00:36:59] Jack: That sounds like Andy. The flip and also actually accurate answer about what they get out of these specific questionnaires that people insist on. Even if you share SOC two SOC three or whatever, you've got a, what they get is to feel special, that's it.

They want to feel special. Luckily, I haven't been in the middle of that, but it's the idea of this. I mean, it goes back to the jokes about standards. You know, if somebody tries to pull four or five standards together into one comprehensive when you've now incremented to six or seven standards, and then repeat until you have an entire industry of compliance, but it's.

Probably out of place here, but since you mentioned Andy, one of the comments he made years ago about compliance was that in the early days, when there was a security incident, somebody in it usually got roped in who understood exchange or whatever it was that was part of this and that they became a junior security person.

And then if they showed aptitude and willing and interest, they would end up in. And what we did particularly in PCI in the earlier days. And I think it's still true. That path has gone. The junior security person is handed a clipboard. It's a digital clipboard. It's not an actual clipboard and it's not just an Excel spreadsheet, but sooner or later, it is an Excel spreadsheet.

And they're not necessarily hands-on, they're, they're coming at it from more of an audit approach that leads to where we get the scope creep of audit questions in a security standard, I think is, well, as long as we're doing all of this, why don't we add in the stuff I know, right? As, as an auditor, we're going to add in what I know.

Cause I don't understand this tech stuff. There's a prediction. I hate making predictions cause I'm terrible at it. But whatever comes next, as far as compliance and standards, it will suffer from scope creep. I guarantee this. 

[00:38:50] Dave: If only there was a company that automated compliance and made it easy for us.

Oh, 

[00:38:58] Shrav: that's it. Trav, I'm going to be happy to come back to any time I'm gone. 

[00:39:01] Dave: I'm gone for that VPP 

[00:39:04] Shrav: secure frame.com. Check it out. Okay. So I'd have to check with our marketing team. So we might have to edit this part out, but because this is just so relevant, I have to show you guys. So you brought up a good point with SOC two is answering a lot of the same things that you like see in questionnaires and like secure frame, you know, automates, you know, a lot of this stuff, we gather data from your AWS integrations, your HR, or sorry, from your AWS instance, from your HR systems and all these various places.

So, you know, we thought, Hey, like why can't we answer questionnaires using the same. A bunch of our customers are kind of already using this in beta, but what we can actually now do, I don't have everything fully loaded up, but I had to sh share something. We can actually allow our customers to like upload questionnaires, but insecure frame.

They can upload ones that are previously completed so we can kind of see, you know, how are they answering questions? They might've already answered before and they can insert, you know, of course, incomplete ones that we can help them to fill out. And there's actually like two kind of interesting components to this one is.

I actually like uploading the questionnaire and like tagging the document. So we'll, you can actually do with insecure frame is like, you can select, Hey, this is the question. This is the response. It's like free text and it'll automatically start to attack, you know, the documents format and determine like, Hey, these are all the questions.

These are the answers, the format that needs to be in. And it'll do things like automatically skip editors. And, you know, it's very smart in that way. And once we get it into a standardized format, the second part that I don't have, you know, quite loaded up here is we can actually answer, you know, all the questions, you know, with about 80 to 90% accuracy, depending on the customer, using all the data that we use to help people get SOC two compliant, the remaining questions we can actually generate suggestions for that.

You'll have to like, you know, of course, double check and verify, but about 95% of the time, we have a suggestion. The first three suggestions we generate that, you know, you could use in a questionnaire. So I'm hoping we can kind of disrupt this category a little bit. And by that, you 

[00:40:55] Dave: mean 

[00:40:56] Shrav: make it suck less, make it suck less, make it SOC two less.

Oh yes. Oh, 

[00:41:04] Dave: we're not paying for that job. That's gotta be free today. All right. Let's switch gears. That was great. And it's initially the first product demo we've ever had on security voices. I mean, where we're like three or four years and it had to happen. So here we are. So switching gears, if that's the words based kind of policy and the industry standards and so forth, the other side of compliance is the actual technical compliance.

It's interesting as in part of getting ready for this, someone made the point that like, look, we used to tell developers and engineers or even security professionals take a screenshot all these eight times last year, where you released new software, you know, do you have artifacts for that? And it's just comical.

When you think of where we are today with software defined infrastructure and. Everything else that's going on. How many times are you pushing? Are you pushing code deploying on a weekly basis now? Like that type of, of kind of gathering evidence is just ludicrous. It's silly. We were in this place before where I had literally never seen anyone do a good job of kind of software compliance, you know, outside of like, probably like aerospace in places where people, it was truly life and death and probably in financials too.

There's there definitely had made some progress that, but like the state of software compliance. Testing proactive assurance with respect to security and quality has been pretty awful. And now we end up in a space where we can do it, and we kind of have to, if we want to get control over because it's moving so fast, but the question becomes like, are we doing it?

So similar question for Abby that we asked for shrub, what's the state of software compliance going from words to code? Well, I think 

[00:42:52] Abby: you hit the nail on the head is we're moving to, you have to automate it. Like if you're deploying code even some companies every hour, right? There's no way that you can go back and retroactively do that manually.

If you're having to manage compliance over in a state that now spans a couple of public clouds, a couple of colo or on-premise states. And now you're talking about quarter million applications, the ability to go and do that manually is not, does not exist. You can't apply enough people. Particularly if you're trying to do with any kind of thoroughness, right?

And so we're slowly moving into the states, uh, where you need to both automate it. And frankly, out of all the things we decided to automate in tech, realistically manually checking assets against a spreadsheet, seems like pretty good, low hanging fruit for us as a technology industry. Like we should definitely automate that.

But secondarily is we're moving into a state of continuous compliance, which is, it's not just enough to be able to say, let's do this once a year or once a quarter. The expectation is you're now constantly doing this. You're constantly validating the state of your environment, your assets against what you expect them to be from a compliance standpoint.

And so we're seeing a huge shift in terms of more and more companies baking the practice in and automating it. But we're also seeing more companies wanting to apply these practices in the contiguous basis, both on the known estates that they have, as well as, as new things come online, which for most organizations, particularly those that are digitizing or migrating assets or developing new assets to move to the cloud, they've got new containers, new servers coming online constantly.

And so you have to figure out a way to apply that in a, not only just a continuous basis, but automatically so that it automatically applies as these things come up. Because otherwise you're having to retroactively go and look for these devices, make sure they're up to the level. You expect them to be both from a security and a compliance standpoint.

I E who has access to them? Where do they sit? What data do they have access to? Who's got the oversight there. And I think all of that has to happen now automatically, or it isn't going to work. It's not only is it not scalable. You're never going to get ahead of the number of assets you have across the estate that you haven't 

[00:45:10] Dave: deployed.

But what state of play right now, what's just the reality check of what you see, like how many people are actually doing that. How many organizations have adequate guardrails in place to where they're able to catch things like that? Is it almost no one, is it the future's unevenly distributed? Is it more than you think what's your.

[00:45:32] Shrav: think a 

[00:45:33] Abby: lot of companies aspire to that, the number of companies that haven't deployed in any kind of rigorous way, small, because it's hard. Automation is really, really, really hard to do at scale. And I think we're not enough of us. I know myself, I try to approach this with a deep amount of empathy with customers, which is I recognize the challenges they have to overcome both culturally in terms of practice and process are huge in order to get people to the idea that we can fully automate the entirety of a pipeline like that is really, really hard to do well and getting people comfortable with that.

And the amount of change that has to happen is hard. And I'd say this, this isn't just for a fortune 100 company. I'm talking about companies that have only been around 10 years. This is a hard battle to do so really understanding that the intent of there, but the number of companies that are fully there are probably less than.

[00:46:30] Dave: So what you're saying makes sense to me in kind of matches what I hear. And even organizations who think that they have it, you're like one acquisition away from it trashing your beautiful world. It was funny. I was on a call with a company and I'm going to keep this very abstract. But the person that was on the call was very technical.

And I think probably very good at their job, but it was explaining what they do. And I was saying, that's pretty impressive. Like it was looking at like, dude, you're pre production, your preflight checks and how you guys manage production, like high five, like that's way better than anybody else ever seen.

And then got on the acquisition. I mean, this is a really big company and you can just see his head explode a little bit. It was just like, they couldn't no, they all told the line immediately, like transition period incubation. And now it's like, this is how we do things. I walked away thinking like, that's how you get hacked.

It's like your rigidity and discipline is taking you to a certain place over here. But the problem is not that like, you can't get that area in order. The problem is the world is incredibly dynamic and there's all these other things. It's like clearly that environment, no one would even bother with because it'd be a pain in the ass, but you're going to get pop from the crap that somebody just left up from the acquisition that you had the other day.

And it was like, you know, failure to like just recognize modern entropy was the thing I walked away and thinking you're going to still have the same problems, but it's just going to be out of review because you managed to get things so tight. You can't intellectually like grasp this other world that exists that everybody has.

You 

[00:48:10] Abby: always have those rogue dev environments that someone spun up an ECE two instances and then forgot about six months later. And, oh, we actually have real production data sitting there too, that we completely forgot about. You know, that's the new modern version of, oh, we downloaded all of the information to some dudes laptop and he forgot it in his rental car and it got stolen.

Like, it's like, it's just a new version of that, but it's, it's the state of play right now. And the ability to put guard rails in place fast enough. Like I said, right now, if you don't automate that, there's no way you cannot manually go and apply those guard rails. And someone is always going to forget and create an environment and forget about it.

It will 

[00:48:52] Dave: happen. Trump, what do you guys see at to secure frame and Jack of course, you know, jump in any time, although I know this is a little far field from what you were doing at tenable and, and I'd wait your visa. 

[00:49:03] Shrav: Yeah. I mean, I think Abby hit the nail on the head there. A lot of this stuff is like very, very difficult to automate.

And there is this kind of new world of continuous compliance. When you look at auditor testing methodologies, like they sometimes just sample things randomly. They're not checking every single instance you have on AWS or anything like that. So there's a lot of stuff that can even slip through the cracks in some of these audits.

Now, with secure frame, that doesn't happen the same way because you know, we could scan your entire AWS instance and we could just very quickly check, Hey, is all this stuff encrypted? So in many ways we're doing these audits much more thoroughly than they could have ever been done manually. And if you have, you know, 20 different regions in AWS or your multi-cloud and have stuff in Google cloud and Azure and Heroku and DigitalOcean and all these like different environments, you know, it's very difficult to keep track of and manage.

There are teams of engineers working on these kinds of products. So it's really difficult to automate every single piece. Now, with secure frame, we just take, read only access to monitor all this stuff. So if you were using secure frame, you would be able to tell, Hey, we don't have this encrypted, or we're not meeting these kinds of basic security controls, but we don't actually help you provision and make those changes.

That's a lot more complicated because we don't really want to be hands on keyboard. Do something like automatically encrypt a service that you're using and then maybe another microservice that's connected to it is not expecting the data to be encrypted in your site goes down, right? Like we don't want to be responsible for, you know, an error like that, but there is just a lot of complexity in managing your compliance automation like this, the 

[00:50:31] Dave: organization I was talking about actually like they would tell you, even if the encryptions audits useless, if you're using the same, the key that's associated with the account you get, where I'm going with it.

And I think that's where some of the rubber hits the road. And speaking of let's do a little intellectual exercise here. So let's say Abby, that you've got really good guard rails and all of a sudden. You're hit by log for J or log for shell as the attack comes out. Like, let's say you got bad-ass guardrails, you invested a lot in it.

How does it apply to that situation or any really kind of any threat that comes through? Do you feel can, maybe this might be an unfair question as I'm fumbling through this, but let's take a real world example. I'm sure there's some instances where you feel pretty good about like configuration related things, but where does it kind of stop?

And I'd imagine a lot of it stops with some of these supply chain attacks where no matter how many guard rails you have, that might make it easier. It's a control point. But how far back are you going to be able to reach into 

[00:51:32] Shrav: the 

[00:51:33] Abby: stack? I'll answer it in two ways versus, oh, I could fix that. It was easy, like for us lock for J granted, everyone that had responsibility for any technology, but everyone got like real tense, real fast.

But for us, I puppet we dog food in our own products. So we were able to identify what assets were out of compliance. Great. Which ones were at risk, update them immediately. And it's done. And that's really where automation comes in is like, oh, we know there's a known vulnerability. We can identify that are areas of risk in our environment and we can fix it immediately.

That's really where you have to rely on automation or otherwise you're back to our right, which ones in our environment, let's go through all of our asset lists. Let's manually look at what version they're running. Okay. Now somebody needs to go out and update each of these independently. Like you're now looking at a, you know, a nine month project to address a pretty critical vulnerability.

On the flip side, on the supply chain, I will say this last year has caused me to think really deeply about the importance and criticality of security as a software provider to enable. And I think for all of us that are in the enterprise infrastructure space, if we're not thinking really, really hard about security right now and supply chain, then we better.

I think for me, solar winds was definitely that wake up call. You're like, oh shit, we need, we need to check, check what we're doing here because we are, we can now be a vector for access to enterprises. And what I don't want to do is have my company's name listed as oh well so-and-so was hacked because they went through this software to get entry to the product or entry to an environment.

And now they've, you know, they've shut down this company. And so I think for all of us supply chain really needs to be top of mind, as we think about security this year with the unfortunate invasion of Ukraine by Russia, we instituted shields up and went through and said, okay, here's the things we're already doing.

What else should we be doing? How do we pay just a little bit more attention to things? And we actually moved into a. You know, where we would work with things that were out of bounds. We now said we now instituted a zero tolerance policy. If you've got something weird happening in a weird staging or demo environment, just shut it down.

Like, don't go ask someone to come in and fix it, just shut it down. Then we'll go and figure it out. But we moved into a very aggressive defensive posture this year to really make sure that we were identifying any threats as soon as we possibly 

[00:54:06] Dave: could. The supply chain. I mean, solar winds was a wake-up call for so many people.

If we go back Jack, if you remember Carrie notch Lindbergh, and we had him on the show and this was positive by a lot of people, but Kerry put it in his book, the Florentine deception. And it was the classic thing of like someone hacked Microsoft update. That was going to be the one that got everyone. I don't think any of us would have posited.

It was freaking solar winds. I think all of us had actually forgotten that solar winds was a thing. And somehow that became, that became the thing that, that really woke everyone up. Didn't see that. That's 

[00:54:41] Jack: interesting because solar wins. You don't think about it in the enterprise, but, you know, I ran into it all the time when I was at a Starro because that's an SMB play.

You know, that that UTM space is an SMB play and it had, it had fallen off my radar. But again, that's the focusing on the enterprise myopia. And, you know, obviously the enterprise vulnerability is that if somebody you work with in whatever relationship uses is an SMB and everybody, no matter who you are, you're working with SMBs.

Even if you're a fortune five company there's. The entry point into your world and the entry point into your uncomfortable conversations in the boardroom, if you overlook that sort of supply chain thing. 

[00:55:23] Dave: Yeah. I think coming back to what you were saying, Abby, is it wasn't necessarily that you can prevent issues like that because nobody can, at the end of the day, it's just the world we're in right now, the right mindset with respect to kind of zero tolerance.

When you see something like that, knowing when to shift up in the shields up mode. And also the, I think the bigger thing that you were at is like, look, we had these choke points. We had these places where we knew we could do centralized inventory and controls. And since you can't necessarily prevent the problem, you can at least react to it, decisively in a centralized weight.

If you've done that work and have the discipline. And I 

[00:56:04] Abby: want to know about it. And I think that is like, like it's not a matter of if it's when, and I think the biggest thing we've learned over the last couple of years, Is, you know, nobody breaches your environment and exposures you the next day. They breach your environment and they hang out for awhile.

And more often than not, you don't know for me, what was important is putting the controls in place that we could detect if we were breached. But the second is okay, what actions can we take? And how fast can we take them? Cause that's really, the important thing is how fast can you respond when you wouldn't do whatever.

[00:56:37] Dave: Yeah, it's, it's the dwell time that that's such a big deal and you see this in breaches all the time. It's very much how you handle it and how you respond to it. And I'm not going to pick on Octa here, but I'll use an example of like how Kevin Mandia and how, um, FireEye handled it in that instance, clear decisive.

Here's what we did. Here's what happened. It was awesome. Nobody was dunking on them for that because of the clarity and the speed of the response and so decisiveness. So yeah, it makes, it makes a ton of sense. And I think as an industry, we've gotten to a place thankfully, where we respect. I think at this point, that's been kind of neat to see.

[00:57:16] Abby: I think one of the things that I, not everybody has gotten the memo on is that you have to be, I don't want to say transparent, but you need to, you need to own up real fast. You can't obvious skate your way out of it. And I do think that has become, we've started to see that more aggressive shift away from that where that used to be the case everyone's default response would be obfuscate or it's not as bad, or maybe it's not as impactful or, you know, to soft play it so that we, now we re recognize the full impact and we recognize what could potentially be the downstream ramifications as an industry.

And so the expectation of the bar is much higher. We expect you to be transparent. We expect you to be clear and we expect you to own up to it. We can figure out how we'll deal with it later, but that is the expectation. And I do think that is that's changed this in the last probably 24 months. And I don't know that every company has really understood that they need to be real aggressive about how they handle comms around any, any breach.

No, 

[00:58:15] Jack: I think they are, I'm not defending them, but part of the reason a lot of organizations have not been great in the past. And some still are not now in telling us what happened is, cause they don't know, that's not a new story, but it's good. Again with my history stuff, go back to the Morris worm, paying attention to your environment and acting quickly.

Bell labs wasn't hit by the Morris worm. Steven Bellovin ran the firewalls and he's like that doesn't look right and stopped it. You know, it's like, oh, all right. Well, here we are many decades later. And there are a lot of folks that still haven't gotten that message. It's like, eh, I have a friend at Okta and I've never been fond of the product myself, but that's just a personal pettiness on my part that I think that people inside Okta entrenched level and security roles did things well.

The rest of the company could have used some consulting with Melanie Anson. Let's just put it that way. 

[00:59:11] Dave: Yeah, it's funny Jack. But I was literally yesterday, I was with someone and they said the exact same thing. They said, we screwed up the communications. They're like, look, the response was actually good.

The communications, we just flubbed it and dramatic fashion, which that's not to like be littlest. Like that's hugely important in these situations. That communication is like, that's the narrative we're all buying into for what happened. And it's just a shame that it came out the way that. All right.

We've got a few minutes left here. Let's gaze in our respective crystal balls here. Shroff I'm going to go back to you for a moment here. You gave us one tantalizing, a statement previously, Ethan sink, SOC two will be replaced. What else do you have in your crystal ball ban? What's your prediction for let's go three, five years out.

What should we be thinking about? What are the insiders know that we 

[01:00:07] Shrav: don't today? Maybe all of us here kind of already know a lot of this stuff, but you know, there's just an increasing number of security breaches. Like this is going to be top of mind, especially with everything we've seen in the last year.

I just see us having a lot more security breaches and it's going to be something that people regularly have to stay in tune with. And we're going to need better software to manage all this. I think that's like the biggest. Not 

[01:00:31] Dave: necessarily a hot take, but the hard too hard to disagree with either, man.

Yeah. It's I think what we're seeing now is these bigger breaches that w that are hitting so many people like an Okta. I mean, hell how many of us were impacted by Octa getting hacked? Yeah, I mean, it's just massive. So I think that what you're saying a hundred percent true, and they're going to hit on the Richter scale a hell of a lot heavier than what 

[01:00:56] Shrav: they used to.

Also, I think where people are seeing this, that we didn't really go into today is like crypto that's where I think people are getting hit the hardest with all these breaches and scams and security vulnerabilities. And it's kind of all out there in the open for everyone to see, which is why we see it so much more.

There's just going to be so much more increased scrutiny around security because of everything that's happening in cryptocurrency. I mean, in crypto, but just generally I think crypto is an area where we just see it way more publicly because of like the level of some of these scams and vulnerabilities and how much it really affects, like people around you.

[01:01:30] Dave: I wish I could blame the performance of my cryptocurrency portfolio on a scam. Actually, I can wait a minute. All right, well, we'll leave. We'll leave that right there. Abby software compliance. Where, where do you think it's going to 

[01:01:46] Abby: have? I think that, you know, we just talked a lot about automation. I think automation is going to become table stakes.

You're just going to have to either you're automating or you're not in compliance. I don't know how fast the regulatory requirements will map to that. But I do think. It's going to become your, you, you have to automate, there's no other way to solve the problem. I think we're going to see probably over the next three or four years, we're going to see big steps in making that easier.

I do think automation today is really, really hard, and I think there needs to be steps to really democratize access and make it easier. And I think we'll also see a stronger push. We talk about chef left a day, but it's really not. So I think we're going to start to see a stronger push to really integrate security and compliance directly into the pipeline and make it easier for developers to an environments to be secure and compliant day one, rather than trying to apply these things after the fact that I think we talk a lot about that today, but as we talked about companies on that maturity cycle, aren't quite there yet, but I do think in the next three to four years, it's going to become more of the standard practice rather than a nice.

[01:02:52] Dave: Yeah, it makes sense. I mean, we're all slogging through this stuff now. And how many times are we going to do this crap before we realize, okay. Hey, if I just make it easy to produce the evidence, like I won't have to input all this stuff into Shroffs product, kinda Jack Eddy 

[01:03:11] Jack: concluding remarks. Nothing for me, but as I observed this, isn't my world.

Certainly not anymore. I'm enjoying not having to think about it. 

[01:03:21] Shrav: Yeah. Yeah. I mean, it's, 

[01:03:23] Dave: you know, you see how much of the world is it's coming, is being compliance, driven with things and compliance, given us the frameworks for things. And I'm not going to go so far as to where I think. And compliance is never going to give us security, but I will say it's making our hygiene a whole lot better.

And even those of us who really want to do a good job, it's covering off some things we didn't have before. So I've come around on it. I have a reformed opinion on it, but I'm still gonna leave the compliance products to the Schwab and Abby. So anytime I can plan. All right, well, thanks for joining us. And off we go, we'll be back soon when we can get Jack off of the road from black smithing and other things we'll rejoin probably a little later this summer.

So thanks again for joining us savvy and trough. Thank you. 

[01:04:13] Shrav: Thank 

[01:04:13] Jack: you. Thanks for joining us for this episode of security voices. If you have comments, questions, or feedback, please reach out to us@infoatsecurityvoices.org, or reach out to security voices on Twitter. Or you can always contact either Dave or me directly.

If you'd like to hear other episodes of security voices, see transcripts of the shows or learn more about our guests. Check out our website@securityvoices.org. We'll be back in a few weeks with another great conversation.

[01:04:50] Dave: If your hobby is being on people's podcasts, your hobby probably sucks.