58. Jacob Berry, Field CISO at Clumio, On Balancing Security with Business Growth in the Cloud

Hello, everyone, and welcome to another episode of the security podcast in Silicon Valley, a wide security production. My name is John McLaughlin, and I'm joined with co-host Sasha, and we have an amazing guest to share with everybody. Jacob Berry, welcome to the show. Welcome, Jacob.

Hey, everyone. Thank you for having me. Jacob is the field CISO at Clumby, and you're absolutely a security person. You've got an amazing background.

Maybe you'd like to share with our listeners just a little snippet about yourself. Yeah, absolutely. So I've had an interesting, personally interesting to me career. I guess it depends on your perspective, right?

So I've started about 15 years of technology and security experience at this point. As part of way back, we can get into that if you guys want to go into like history, like how I got into this field and career, I'm happy to go there. But over my career, I've really focused on a couple different areas. So I started security operations.

I was a SOC guy when SOCs were a lot different than they were now. That's easy to say, though, in general, right? SOCs change every single year. Security Operations Center, huh?

Yeah, exactly. Security Operations Center for those not familiar with the acronym. And then I focused on consulting for a while with SecureWorks. That was interesting.

I was on a team that's large consulting for large enterprises that needed like StaffOG, but plus. So I did a lot of the strategic development for the initial security operations program at some larger organizations. That was a lot of fun. And then I've done a bunch of different things since everything from helping build security consulting practices to go to market and helping people that want to understand what do you build in technology?

What has value for security practitioners? What are the problem sets? How do you solve those problem sets? How do you bring a good product to market?

How do you not, if I can use the word pissed off, like how do you not piss off security people when you're building a company? And that's something a lot of people don't inherently understand is the type of personas and the type of individuals that get into security because it's people get into it often because they care about it, not because they want to make money. And so what about it that you cared about deeply that pulled you, that drew you into security? Is there a story that we have to be a little bit crazy to be into security?

You have to be insane to really, I think now you get a much different mix of personas because the salaries skyrocketed so massively in the last five years. So a lot of people did start viewing it as this is a career path that I can go that I'll successfully make money in. But for the first, let's say 20 years of the industry, that wasn't the case. Not that I was around for the first few years in the industry, but how I got into it was, do you want me to go all the way back?

I guess I'll go all the way back. I think listeners appreciate like- I love a full story. Yeah. So I started as a, what I describe affectionately as like a punk hacker in high school, right?

Like the people I hung out with were the technology people. We'd break goofy things like online games back before security was big and online games where you didn't even sanitize inputs type of thing when online gaming was first coming up. So we would do things like that. Like not, we weren't destructive.

We weren't like breaking into some IoT device that was controlling the power grid, right? That someone had a Windows XP box that someone had plugged into the internet because you just plugged it in because then I can get to it from home. Like we didn't do that type of stuff. I wasn't that type of hacker in other words, but I developed this mentality too at that age where everything was just kind of like a problem that could be solved and like technology could inherently be used any way that you could figure out how to use it.

And there's a bunch of fun stories I could tell about like how I got into that mentality, how I learned it, but I didn't know of cybersecurity as a practice or a field. There wasn't a phrase for it really, or it was just emerging as a phrase when I was learning this stuff. There wasn't content online that was like cyber branded content or cyber as an education or even books. It was all just, there was security, but it was security for mostly IT people, mostly network professionals.

I couldn't tell you how many CISOs there were then, but not many I imagine. And so I did that. And unfortunately I was very lucky that some other students in my high school had petitioned the guy who did like electronics, like home wiring electronics. And then he also offered a digital electronic class to offer Cisco networking classes as well.

So you could do Cisco networking, go be like an IT guy. And so I was able to learn the Cisco networking stuff like really young, fortunately. And then I was able to get a job in that even before I was out of high school. So like those two things of hanging out with these punks who didn't really have a place in the world that found their outlet through just whatever bizarre hacking of a video game or something similar, which is like breaking things in general.

That was your outlet, but you broke things through a keyboard instead of physically. Like that was their outlet for being a lot of these people are outcasts for being a social outcast in a lot of ways. And so I hung out with them and happened to get that exposure to the Cisco networking world. And then that led into a career.

I had a friend that ended up looking at a college, a Norwich University, which funded by the NSA. So the NSA has this program where they fund certain cybersecurity programs. And when they first started this program many years ago now, the idea was they could get some IT people to like take some math, some crypto, some other things, fund these programs, also do scholarships to get people into government service. And they would offer these scholarships in exchange.

I didn't do the scholarship side of it, but that's how these programs came to be at a lot of universities was through government funding and government direction, especially at private military institutions like Norwich University. So I didn't even know about it as like a career path, but a friend had gone, saw the program. So then I did a degree in cybersecurity as well. And I worked during that time as well.

So that's my loose starting. There's a bunch of different roads I can go if you guys are interested in a little more on the history of how I got into it. So you have an amazing prequel to your current position at Clumio. What would you say your biggest focus point at Clumio today?

Yeah. So I don't know. It's hard to say. I've kind of been opportunistic with the roles I've taken and where I've gotten into.

So if you're asking like, how did I get to the field CISO? Was it an intentional motion or did I stumble into it? Is that correct? Am I interpreting that question?

Yeah. Yeah. It was a stumble more than an intentional. There's a, say, external customer facing part of the business.

Oh, there's a shortage of people who both want to be in front of customers and talk to them and can inherently understand the security systems that you're building, right? Whether that's in our case at Clumio, it's very heavily around product security. What are we building? How are we architecting?

How are we detecting threats to secure the data that our customers are sending to us? And being the fact that I did security consulting, which is customer facing. And when I was at SecureWorks, that role also interacted with sales engineering and these other things. I built this skillset where I could talk to people about the state of security externally and have those conversations or about what you should do, how you do it, why you do it.

The intentionalism for decisions you make in a security roadmap. How do you make those decisions and how do you come to the right conclusion? Because people want to know that. And so I stumbled into that role sort of accidentally through my journey at Cyber Reason.

And a lot of the sales professionals and CROs that I worked with ended up really enjoying my participation in the field efforts and the ability to go and have conversations with customers about why you would make a decision and why you wouldn't make a decision. Or how do you build a security operations program? And that led to one thing or another and then inherently this role over time. Yeah.

Having this technical background and technical knowledge, as well as ability to speak externally, as well as connect business direction and business needs with engineering capacity is extremely important. We see it more and more as a requirement from leadership in the security space. Security is always a balance. You can go all out and build the most protected and secure system, but it often comes in at the expense of doing R&D.

And so we see, and what we hear from the industry is as a CISO or as a CSO, as a leader, you have to be able to connect the dots. You have to connect the compliance. You have to connect the business capacity. You have to connect the business direction, as well as engineering abilities and capacity into a single vector that will drive the business in a secure than trusted.

Right. So how do you strike that balance, Jacob? I don't think most people do, to be frank. I think a lot of people say they do and can, and there's a lot in our industry of sort of saying that we do it well.

I can share what I attempt to do, like my view of the world. No, nothing's ever perfect, right? And so all we can do is like. .

. Right. So yes, let me share how I think you strike it. And there's a little bit of politics in that as well, because inherently security and privacy is political.

And I think people try to avoid that a little bit. There's also the notion of political capital in the security. Yeah. Sure.

You have a line of credit, you get to use it, and then it's important not to max it out. It's always a balance. And so when I say political, I'm thinking at the root of it, security and privacy is a social aspect. Our expectation of privacy, our expectation of security is something that's social-based.

And you implement social standards through governing, right? And you through governing inherently, politics is there. And when we think about security, what really compels people to do something properly, well, typically that's privacy-oriented, like security is more of a privacy game than anything else. They're so intertwined, these concepts.

If you separate the business concept out, so set that aside. So operational uptime is one thing. There's one bucket there. Then you have societal expectations of privacy.

So that's another bucket of thought you have to think. How am I meeting these? So those are two things. So one's an operational risk.

I might have some sort of downtime or revenue loss associated with a technology incident. And that could be through compromise or something, remote code execution, whatever that could be. There's a bunch of different threat models. You have the societal expectation of what is privacy.

That doesn't really sell too much. It's selling more and more in the last five years. Like people care about privacy. They talk about a little more.

If you look at what Google runs for ads on podcasts, for instance, they try to be like, your data is going to be secure if you put it with Google, if you use Gmail, if you use these home suites. Is it not? We could get into that topic. So you have those two buckets.

Then you have like legal and compliance. It's like your third bucket of types of risk, more or less that you're managing. That's kind of roughly how I think about it. There's like legal and strategic risk.

There's societal and privacy expectation risks. There's rational risk. And all three of those come from different mentalities in total different buckets. But the societal and legal I'll talk about in a minute, operational very much is, am I making the money?

And I want to continue making the money. That's the easiest one for business to understand. And that's the language of most CEOs. And most is I produce a thing.

I do a thing. I get paid for doing the thing. I want to maximize profit on that. And I'm only going to spend the minimum amount of money to reduce the risks as in profitability.

I'm going to think about that. How do I pull that lever, the risk management lever to increase profit rationally? So I think about that as one. And this is going to be a long winded answer.

And I'll get there in the end to your final one. And why I'm going down this path on how you balance it. Then you have legal and compliance risk. So this one, this bucket over here is really, again, it's a codification of societal expectations.

At least that's my opinion of it. We've said this is the minimum baseline that we as individuals think a business should maintain or other individuals I share my information with should maintain. So we codify that into law. And then as a business, you have to meet expectation.

You have to meet that bar because we've said there's financial penalties or operational penalties for that, although we don't see that very often in the US. And then there's the non-codified part of the societal expectations of how things are active. So when you talk about balancing things, as security people, we often focus heavily on that societal expectation because within our industry, we talk about this is the expectation of security and privacy. This data cannot be, the confidentiality of this data cannot be compromised.

But the confidentiality often doesn't have too much operational impact. And CEOs over here think about operational impact almost all the time. So how do you get them to care about these other buckets of things and strike a balance? And that's when I say, I don't think we succeed at that very well because we don't translate why societal impact will have operational benefits or revenue-based benefits.

And often it's not tangible because you're measuring those things in brand equity. You're measuring that in, I've built trust with my consumer base or the customers, the people I want to do business with. And therefore, that leads to a higher purchase rate. And how do you go and measure that and say, the things that I'm spending money on in my security program are then tied to that, that I want to do.

Very easy if you're operational. I'll stop there because that's how I tie it all together there, how I balance these things. That's what I'm focused on. What does the CEO care about?

Why is the CFO going to spend money on this? Those are the conversations I'd typically like to focus on. Yeah, I know. It makes sense.

Well, with Lumio, it's a B2B play, right? You're selling to other businesses. So I bet, I mean, being a field CISO, you're probably jumping on sales calls all the time. You're representing the security posture of Lumio.

So you can measure, you could have win-loss reports based on just the security. That's our biggest driver for security here is impact on revenue. And all of that great information that you gather up on that most customer facing and very visible engagements, you can bring back internally to the team and be like, hey, PMs, hey, engineers, here's what we got to build to hit this one vertical. And it could be a whole slew of companies that are waiting for one feature or one compliance thingy or whatever.

Yeah, it takes a lot to sort of peel the onion back sometimes on those like feature requests. So on the engineering side of the business, you have to make very intelligent decisions on which resources you invest in. So if I'm going to go and build a security-based feature for a vertical play, like you're saying, so a financial vertical, healthcare vertical, and they might have different requirements, you have to be able to spend a lot of time peeling the onion back on like, why are they making this requirement? A great example is you'll often hear misconstrued in this type of industry from finance if we want to keep our data in our accounts, right?

We don't want to transfer out to other third parties. If you really pull back the layer of what risk are they trying to manage there, you'll hear the first person will say, oh, it's a privacy or security concern of sending data. Is it like, well, what is the thing? Like you send data out in and out all the time of different types, but it's more on the financial risk side of the business and responsibility over managing uptime or managing, if you're doing a, I use this example all the time, you're doing like a $10 million transfer and you miss that transfer, there may be very significant financial penalties or you could be even larger.

One example I do is payroll. So payroll happens for a lot of companies, maybe the second week and all companies really have their payroll typically in a market money account until payroll time. And then they're transferring that into something which can service the payroll needs. So imagine all this money moving all the time on the financial side of the business.

If you miss one of those transactions or miss multiple of them, there's a massive financial penalty for a lot of these businesses on that. And they don't want to entrust that you're managing the data for something critical in your account, which they have no visibility. So it's, again, it goes back to an operational risk and you have to pull these layers back and this is what they need in the financial vertical and why they need it and that type of thing. This is what contractually they want us to commit to.

So this is why we have to build this security feature of supporting this type of model or this like in account or not transferring certain data. It goes really deep when you have to answer the question. But if you take that first level, what you hear from someone of just like, we need an account because privacy or security, is that really what you need? No, we really need to hedge risks against if there is, we're missing this financial transaction, what the penalties might be in the past through contracts.

It's a very murky world when you get into these vertical solutions. Healthcare is different as well because that's a highly regulated. People say finance is not highly regulated. It's not really when it comes to security, which I'm opinionated on.

I mean, you get a bunch of tinfoil hat people in the financial space. So not a bad thing, but they have a lot at stake. They have the money to pay for them to have a hundred quack ideas and one good one. Like, I wear a tinfoil hat all the time.

I'm not, it's not a negative comment, but it's like, ideas are bad around. I have a bunch of quack ideas myself that aren't where someone should go implement in a capitalist business. That's very important. Yeah.

Given the line of business, Columbia is engaged in, you help businesses to ensure that there's always a backup of data and please correct me if I'm oversimplifying. Yeah. Oversimplifying is easy for people. That's perfect.

Fantastic. We provide SaaS backups for ADA primarily a loop of M365 types, but yeah, we're focused on resiliency in AWS and solving those business problems. Given the line of business, what would you say the most important triad in the CIA? What is the most important component in the CAA triad that Columbia is engaged in?

Would it be the integrity, availability of the data, or these two combined? Yeah. So from a external facing perspective, people purchase us because of integrity and availability. That's what we're helping protect.

And it's a really interesting conversation with customers because so much energy and time is spent on confidentiality. You often, integrity and availability almost fall down the stack. People inherently believe in the shared responsibility model in the cloud that availability has been solved. It's like infrastructure availability has been solved, not data availability.

And those are two different problems. You can still go and mess up as much as you want in your own account and impact your data availability. Now, switching hats from the external facing, problems are solving for customers, which is around integrity and availability, less so than confidentiality. It's the inverse internally.

When people send us their data, they're concerned about availability highly because if there's a DR incident, some sort of downtime, they want to use us to come back online. So they care about availability. That one's a lot easier to answer with the way we've built our product, but they really care about confidentiality and how our security program manages confidentiality of the data they're sending us. There's a bunch of weird things with the way AWS works on how we have to access data and work within those bounds, which means we get higher visibility and higher access rights to some types of data than people want inherently a vendor to have.

And that makes them very uncomfortable. And so we have to at least, at minimum, be meeting the same confidentiality, both controls, processes, and have the right people to execute on those that someone else out there might. So we get a customer that's absolutely massive that comes to us. And they expect our security program as a startup to be as good as a fortune 500.

And that's really tough to do. To be on par with their internal standards. Yeah, right. Exactly.

To be on par with how they would protect the confidentiality of their data. And you're like, well, you guys have 10, 000 employees and we have 200. And so like, how am I going to make that gap where you have entire team just focused on this stuff versus we have a handful of people at 200 employees? And so we have to really be conscious about how we're doing system design and architecture, how we do key management, how we do credential management, and what's it take to access things within the company.

We have to be extremely intentional in our design choices. So actually, it's a very interesting space. How do you bring your security posture? Because you need to prove to your potential customer, to the prospect, that we as a business provider, as a service provider, we guarantee our internal security is of high standard and we can handle your data as well as you can handle your own data.

How do you make sure that with a smaller amount of resources, you can get to that level? I say it's transparency is the way that I approach it. So we have our SOC 2, 27001, 27701 for GDPR, we have our SOC 2 reports, we have our PCI audits, our HIPAA audits. Those are all great.

If you're a vendor that's managing risk through those tools, you're not getting the real answers, in my opinion. And the customers who really care go, okay, great, you have ISO. But I want to actually understand what you're doing and how you're doing it. And I want to build a relationship with you.

That's how I find the most sensitive companies are succeeding with us. Because I'll sit down with you and walk through how we're designing things architecturally, where the data is stored, how it's stored, how we're doing key management and rights management. One of the things that makes it easy from a technical perspective is that we're building in the cloud. So with identity and access management tools that AWS provides, that gives us actually a lot of ability to show our customers very transparently how that data is managed.

So we can show them the IAM policies, we can show them what we've built and architected if it comes to it, which it has in some cases. We'll share our screens and go through, here's how we're going to go and show all these policies. And here's how we prevent developers from having access to this data, because they're just pushing through a CI CD pipeline. And those have five different checks, including human checks, including tooling and all these other things.

So they can't inherently just push bad code, right? There's these checks that we have. Insider threat's my biggest concern. And organization like this followed by a second one, actually, I'm not going to mention because it's, I don't want to give threat actors ideas on how to go and operate it.

But supply chain related is the really the one and how you manage supply chain. Again, we're managing that through some of the ways we're handling developers. So if I think of those two as my biggest risks, those two are the ones that I want to have conversations with the customer and how I'm handling them, because they agree, typically, that those are our biggest risks. So yeah, those are the things.

Technically, we're really using some fundamental things around security controls, which is authorization and access. And how do you manage authorization versus access? How do you do that securely and provable? And right now, this is the journey I want to take us on to as a startup is going from we manually prove that to customers today.

How can I have automated provability in that? So automated provability, when you're talking about hundreds, it's actually thousands now with our customer base, thousands of AWS accounts that we manage to build this infrastructure, because we're doing things very segmented in our infrastructure. How do you now bring this to automated from manual so we can scale faster and easier? How do I free up my sales team to be able to go and sell more?

Because right now, security is almost a blocker to that, right? Because we have to sit with these people all the time, schedule this, try to get everyone's calendars aligned. Then you do the first level of security review with maybe an engineering, a DevOps engineering team. And then DevOps says, hey, here's all the information security team that I gathered for you and the security team.

I want to have that conversation. So yeah, it's a great question overall. Thank you for asking it too. Yeah, of course.

The intelligent automation is very important. Why do I say intelligence? There are so many manual processes in the cybersecurity space today, but it's important to identify what are the most critical friction points that potentially block sales? And how do you automate the most critical friction points first?

Because automation still involves manual work. Someone on your team needs to go in and automate the process. But once you've done, it will serve you well in the long term. Yeah, a hundred percent.

For us, I think we prioritized, rightly or wrongly, I guess time will show, automation on the developer front in DevOps and how we're doing that CICD pipeline and product security. Because as a startup, really, that's where a lot of, you're focused mostly on energy and engineering and freeing that up because innovation is really the differentiator. Why do startups always go in stealth? Because that way they can innovate in the shadows and try to out-innovate other people in the marketplace.

So we spent a lot of time, and I'll shout out some of the other people on the team. So Glenn runs security internally. He's the VP of InfoSec internally. So if he manages in, I manage out.

That's kind of our breakup of responsibilities. They spend a lot of time thinking about automation and how we use just basic SOAR-like platforms and automation platforms to carry out some of these tasks automatically. So that way, our smaller staff only get flagged when something goes wrong. Only when a developer maybe goes and says, I'm going to commit this anyway to the code base, even though it had a flag on this code check, right?

That way they would get the alert for that instead of having, say, an entire list of, okay, I have 400 commits I have to go through and try to read. So it's like, how do we get that number down? And then we try to do security reviews upfront manually too, because if we free up everything to automation with security reviews, something will make it through the process. But if you're doing it with your product team and before you go and have engineering start something, you can put it into the PRD.

You're going to get a lot better output. So automation kind of downtrend and try to manage human efforts up chain, if that makes sense. That gets you the scalability that you want to build towards. But we have a lot to learn too, a lot to go build.

Like this area is constantly changing. There's a few who went to RSA or any of the shows recently this year, 50% of the floor felt like that to me was like developer security tools. Yeah. Yeah.

It was a lot. It's a good show though. I'm super curious when you're thinking about the confidentiality internally, do you get any asks for, of course there's encryption and everything, but do you get any asks for bring your own key BYOK or? Yeah, we support, we support BYOK.

Yeah. So you can provide a key and make your data with that key. Again, on AWS, there's a bunch of nuances of what that means. Again, we're backing up AWS and we built an AWS.

So key management's a little different and depends on the data source. Like an RDS, relational database service, managed database service for those not big in the AWS world. AWS offers typically fundamentals and then they offer on top of fundamentals. When I say fundamentals, compute, storage, databases, networking, that's fundamentals.

And then they offer managed fundamentals. And then they offer typically a next layer up is like managed fundamentals as I think about it, which is like the, you don't build anything yourself. You kind of just describe what you want and you get it. So each of those things all has different techniques for how you manage encryption keys in those and what types of encryption they support and how.

And so there's all this weird nuance, but yeah, we do support bring your own key today. And we're constantly looking at how we can make enhancements to that process on the key management front. Oh, that's awesome. That's awesome.

And your data residency questions that might come up or data sovereignty sometimes it's called. Those are fun topics too. Yeah. Somewhat challenging and it's somewhat not challenging.

But when I say it's somewhat challenging because laws are constantly changing and we have to constantly put engineering efforts to meet those laws. The good thing is we are built in a modern application with a control plane and a full modern cloud stack, which really just means we can kind of press a button in our CICD pipeline and redeploy our stack to any other region. So if someone says, I need to keep my data in this country, as long as AWS has a data center in that country, a region in that country, we can just push our code to it with like a weeks of effort. That automation paying off right there.

That's the automation paying off. So if you build things in that manner, things are a lot easier to manage from that. The other thing is there's a bit of a loophole for us particularly, and we're unique in this, is that we're a backup vendor and GDPR service requests for our customers, you don't have to service backups. So most countries rule on backups separately from the, it's not clearly spelled out in GDPR.

You can go read about these rulings that each enforcement body makes. So anything that's not cleared, clearly spelled out in GDPR for those unfamiliar, the enforcement body in a local region makes that calling or that ruling. And most of them typically just cheat off of whoever says it first. So whatever the first guy says, the rest of them can do.

And for backups, you don't have, if it's not technically feasible to do a, some sort of GDPR data deletion or lookup request for a person, you'll have to service it in backups or other archived data structures. If the data comes back in to the production system again, so you restore, someone has to actually make a new service request to then have that data deleted again. So those of you on the inverse side that care about your privacy and are doing GDPR data requests, personally, you should know that as well. You should make a list of everything that you make service requests against and then go back and do it in another year or so.

How would you know that the backup was restored into production in the first place? Because companies are not required. You won't. From an end user perspective, you won't.

You have to send that request every day for the rest of your life. So you were doing, maybe there is a service, a new startup idea. A new startup idea. DeleteMe.

I think there's some that do something similar, manage data deletion requests. Is that also the case for the CCPA? CCPA is typically similar there. I haven't seen, just could have missed it or haven't looked.

I haven't seen any particular rulings from CCPA stating how you manage that, but they pretty much copy and paste typically off of GDPRs. So it's, yeah, similar is typically my advisement or just wait until you see whatever lawsuit Facebook decides to go and argue with. No, I really appreciate all of the shares. It's most interesting to dig into all of those requirements and how you navigate them there at Lumio.

And it sounds like, just to be totally honest, it sounds like they're very lucky to have you to help navigate and connect the dots between what's happening out there in the market, what's happening there in terms of regulation, societal expectations, brand awareness, and then on top of that, like to the growth of the business. So I'm sure that you talked a little bit about seeing security as a way to control costs and to increase profitability, but it sounds like you're absolutely part of the growth formula that all of security is, especially if someone's going to hand you their data. It's hard to imagine something more valuable when it comes to. .

. Yeah, it's 100%. It's fortunately our CEO and investors, all our Snowflake people. So all from the Snowflake world and Snowflake had to deal with a lot of that in their growth structure.

And so inherently they understand that if you're going to go and win a certain market segment, especially a larger enterprise, there's things you have to do from a security perspective because people aren't going to give you their intellectual property unless you're meeting a very high standard. And I think that's for anyone who's worked in SaaS business in which you're storing intellectual property for customers.

You either don't understand it when you start that business and you have to learn it real quick when you go to sign a customer and they say, nope, or you've already done it and you've learned from the SaaS world that you have to do it because you're not going to sign customers up otherwise. Yeah, it's very interesting in general, the shift that we see. Regardless of the service that company builds, you will likely handle data of your customers either directly or indirectly, very likely directly. And data security is becoming a foundational component of doing the business.

You just have to have fundamentals in the data security implemented in order to engage in doing business in the first place. That's quite fascinating. So what's the best day that you've had in your journey so far at Lumio? Yeah, that's a good question.

It's a tough question. I don't know if your audience is mostly startup people or if it's a lot of startup founders and entrepreneurs. So as a startup, okay, so there's the audience probably very much knows startups are you have really good days and you have really bad days and it's this up and down. Wild roller coaster.

Wild roller coaster. And you will be angry half the days and you'll be on top of the world the other half of the days. It's not. It's almost like being bipolar.

It's working for a startup. It's a lot of emotional flipping. I had a CEO previously, not at this company, previous one. He would draw this graph and it was this line like that.

It means you're trying to get up to the right, but you just have to do this the whole way you're going up to the right. And he's very much right. So good days are typically ones where we're solving something complex for a customer. Like there's a hurdle that we didn't expect or a customer wants something greater than what we did today or how we manage something.

And so we've had some of those days where we just sit down with a customer and we think it's going to be the really challenging conversation or they're going to just be mean because sometimes people are just mean. They're mean to vendors. Like it's one of the things that we're really bad as a security industry. People are very mean to vendors, even though everyone's a vendor for someone.

Like it's always bigger fish in the. . . Why do you think that is the case?

Yeah. I'll answer that question. I'll come back to that. So why people are mean to vendors.

Yeah. I have some colorful and not nice things to maybe say about the industry in that case, but yeah, we'll come back to in a second. Sounds good. The.

. . So the best days I have are when I sit down with a customer and maybe the sales team or the customer success team has been like, this customer's really upset. Like they're really.

. . They knew this. They're not going to do business with us or they're not going to do this renewal or whatever it is because something's security.

Insert whatever you want. And then I get on the call with them and they just ask a very logical, very intelligent question about how we're doing something. And we get to have a very deep conversation about what we're doing today, how we do it. They give us feedback on it and how we can change something.

And we almost. . . I never say no to a customer in those cases either.

I'm going to go back and find a way to solve your problem. And then I'll give you a realistic answer. If that's a six month or five year problem, we can go and solve it. I just don't know if I have one engineer with one hour for the next five years to solve that, or do I get 20 engineers tomorrow to solve that problem?

We'll find out. It's never no. And I get to sit down and have those conversations on something people think is like a really going to be a horrible conversation that's business ending for us or whatever it is. Like this massive customer is going to be very upset.

And they often are upset. But when you sit down and you have an honest conversation conversation and you listen to what people have to say and you ask why, and then you're like, why does that matter to you? What can we do to go and build the right thing for you? Typically people will then describe what they want and you say, well, we can't do that, but I can do this.

And like have those, everyone leaves happy at the end of the call. Cause you sat down, you listened, you intellectually responded, you asked them why, or why do they care? How do you feel? Like just listen to people and talk to people and have a conversation.

That's what people really want at the end of the day, isn't it? Is to be listened to and felt heard more than anything else. They want to be heard. Yeah.

And so those are the best days is when I go into those conversations that people think are going to be insanely tough. And then you really just have a great conversation with other great humans. And sometimes it's just, I share what we're already doing from a security practice perspective and people are really happy. Like, oh, okay.

You already thought about this. Or they say, I wish this was done different. I go, that's a really good idea. Let's go and build that.

Those are the best days. So back to your question, why do people hate vendors? There's a lot of reasons. Well, hate vendors.

I make this joke all the time about people like pointing fingers and third-party risk programs. Everyone thinks their security program's better than the next guys. Well, that can't be the case that everyone's better than everyone. Sometimes it's just convenient.

It's yeah. So there's that, right? Like people always, there's a lot of ego insecurity. And I think it's because a lot of intelligent people are in security and it does build this, I get this and other people don't mentality.

And unless you've built a personal relationship with someone, often industry, you think, oh, this person's probably doesn't do this as well as me or they don't know or something. So there's that. There's a lot of that in industry that I've seen. And typically it goes away as soon as you sit down and have that nice conversation with someone.

You're like, oh, these, everyone's a normal person trying to do their best. And then occasionally on the rare occurrence, you run into someone who's not a normal, nice person trying to do their best. And they're just trying to skate out of it. That's pretty rare in my experience, if you're willing to actually have a conversation.

So there's that, right? There's the ego thing in the industry that exists. There's the fact that in the last 10 years, people put a ton of money into security startups. Now, maybe fortunately that's shifting to AI branded startups and a lot more investment in that.

Maybe not. I don't know. We'll see. That's fortunate or not.

And that's created a massive influx in sales teams, in security. And that security people often want substance to their conversation. And salespeople are not the ones prepared to have substance conversation security. They're there to try to just tell you they exist.

Like the noise volume, they're there to raise the noise volume. And the noise volume is so high now, people are just frustrated with the industry overall. And then the third thing I think contributes, and this is a larger issue, is a lot of security people don't feel heard in the industry or don't feel like the business cares about them, which I say all the time, business doesn't care about security because often they don't. They care about, they don't care about security.

They care about the outcome you're giving them, which is typically increased sales again. And so if you combine those three things, you're like, you already kind of have an ego that you're doing security better than the next guy. I shared this, the Spider-Man meme where there's two Spider-Mans pointing at each other, which of you is the real Spider-Man. Oh yeah.

I shared that the other day when we were doing a third-party risk review, because it's like someone asked for all of our internal documentation on security, because essentially we don't trust you. Show us all your internal documentation. I'm like, well, this details procedures on what we do, what systems you log into. Like, I don't trust you to have that data.

Like I'm going to send all my security practices and information on how we do things internally. That would be a treasure trove for someone who wants to break into us. And so where are you storing that third-party risk data? So it's like the two Spider-Men pointing at each other.

I don't trust you. I don't trust you. And typically why I prefer Zoom calls to walk through security practices. So there's a lot of that.

And then you have ego on top of that. Like I'm doing this better than anyone else could have done it. I've thought of all these, and I see a lot of that in industry and it's unfortunate. Then you combine that with the fact that security is not taken seriously at the C level.

And then on top of that, you have the startup noise. That's really just made people very frustrated in the industry because it's hard to talk to someone that can go deep on security in the sales department. And also as a company brings a new vendor on board, there is an increased risk profile for the company. And maybe this is just a reaction to trying to mitigate that risk and make sure that the risk is minimal.

Yeah. And so it's understandable, but it also sounds like having that human conversation, because at the end of the day, humans are heavily involved in making that decision what the vendor should be part of the business or doing business for the company. So it all boils down to a conversation, human conversation. Human conversation.

Yeah, exactly. I agree. Well, Jacob, this has been absolutely spectacular. Thank you so much for all of the shares.

I'm super curious if you could go back in time, meet your younger self, would you? And would you have any advice for your younger self? Would you? If we're not getting into sci-fi time paradoxes?

We'll go with whatever you think is like. Yeah. Would I? It's very philosophical.

Yeah. The joke online always is you go back in time, you're like, put $10 into Bitcoin. Would you go back in time and tell yourself that? Probably.

That's not bad advice. Right? Yeah. Or a hundred bucks.

Or into whatever, Amazon or Apple stock or Microsoft stock, right? And it explodes. Yeah. So would I go back in time?

Probably. And that's what I'd tell myself is then I wouldn't have to worry about what I was doing in my career overall. But no, I don't think I'd actually go back in time because a lot of the ways I feel like I've succeeded have been somewhat accidental or even at times naive choices or just like letting the, kind of just following the life path as it has come. Of course.

Yeah. And so if you go back in time and you try to push something one direction or another, I don't know. Would it get me back to where I am? Would I go make the same silly choice that led to an accident that led to a happy outcome with advice?

Probably not. So I almost like the journey. And I think I look forward to that a lot in career in general. I don't know exactly where I'll end up.

Like I have ideas of all the different things that could happen, but I don't. You are the first person who has shared that. Yeah. They probably wouldn't go back and meet themselves.

Really? The first. You are the first. Interesting.

So that you're incredibly grounded resident individual. I think that everything except our reactions to what's happening around us are completely out of our control. Accepting that is a beautiful thing. Yeah.

Finding a path forward is what it's all. That's part of the fun. That is the fun. Part of the discovery, right?

Yes. Before the show, Jacob, you have shared with us, you like riding motorcycles and it just connects super well. I just had to disclose this information. Part of discovery, riding out in the wilderness is also part of discovery.

And it's important to stay present in a moment. But as you ride through that nice corner and you can see into the future, what do you see into the future in terms of the security product? And let me be more specific. What do you think the next successful security product will look like?

I'm going to give away some of my secrets here. So I'll give a general answer. I have some interesting ideas in this front of me. I'm happy to talk about it.

So I think there's a rejection of this. Security people are very skeptical and rightfully so. I have part of what makes you a good security person. What makes you a great security person is that you can balance the skepticism with the realism.

But what makes a good one is skepticism. There's skepticism of what's happening with the proliferation of AI. And I don't think Gen AI is going to solve security. I don't.

Gen AI is really cool. If you spend a lot of time with it, if you've done some coding, actually go and dive into what it can do and what it can't do. It sucks at a ton of things. And there's a ton of startups out there that are going to fail because they think it can do things that it can't.

But the things it's really good at are really cool too. But take another step back. Gen AI is just interesting to the masses because it's very tangible implementation of machine learning. It's very easy for people to use it and understand it and see it.

And one area that I think we're not great at as a security industry, and some people take issue with this, is the adoption of machine learning in general. There's a ton of great implementations of it in identity products. Obviously, Endpoint is a great success story where we went from traditional antivirus to machine learning driven or next generation antivirus. In the space, great implementation.

But we do so much data analytics and so much by hand in our security. And the industry, in my opinion, has really struggled in the last five years with figuring out what's next. How do we stop that struggle with the volume of data that we have to make decisions on? And we've seen a lot of products that add to that, that I think solve a lot of good problems, but they also add to the noise.

And I think that's a huge opportunity for us. And I think a lot of people are skeptical to uptake those. A lot of people are skeptical to go build on them. I can tell a small story there in a minute.

So I think there's a lot of opportunity in the security market for really good implementations of data analytics and data science tools. And there's been an emergence of smaller vendors over the last few years that get some buzzwords associated with them, like Data Fabric, right? Security Data Fabric, which is really ETL tools if you're a data person, ETL being extract, transform, load that you use in data science, whether that's machine learning or just normal statistics, non-machine learning statistics. I think there's a lot of future in that.

And we've seen a lot of challenges in the industry. There's a lot of great successes too, but there's a lot of, a lot more we can be doing. Go talk to someone doing some sort of scientific research in cancer or these other areas. They also have this big data problem and they use machine learning massively.

And then they have to process those results. And it takes obviously people doing doctorate degrees, eight years to do that. And that's a very, and you get this little niche area. That's, we're not applying a lot of those principles that I see broadly in the industry.

And I think that's an area where we can go succeed more. And I guess some people will take issue with me saying that we're not adopting machine learning very heavily because they're like, oh, we do that in our product. We do this, but to a degree, but we need to bring that to the masses in mind. The future is promising all intersection in AI and security.

Yeah. But it will take some work, some decent amount of work to get there. It'd take a massive amount of work and be skeptical on Gen. AI products, but be intellectually curious on them is my advice to people.

Go ask questions about how it works and what does it do? And then go to try to reproduce it because you'll find interesting use cases for your own uses. And you'll find a bunch of places that you shouldn't use it, that it does really bad, but don't dismiss it outright. I think a lot of people are dismissing it outright.

Thank you for that chair. Yeah, absolutely. And thank you for joining for another episode of the Security Podcast in Silicon Valley. I'm your co-host, John McLaughlin.

I'm joined with co-host Sasha Sink, Jacob Berry. Gary, it's been amazing to have you on the show. Again, the field seesaw at Kumlio. Would you like to leave our listeners with any final words of wisdom?

I don't know if I have words of wisdom, but maybe we'll just go back to that conversation we had about the journey. Just enjoy the journey in security. Don't get caught up too much on the stress of the outcome that you're going to drive every single day. Security can be extremely stressful.

Am I doing the right thing to stop a breach? And I think the blood pressure level of the industry as a whole needs to come down probably a few points. Everything's going to be okay out there. Take a deep breath.

Just step back. Not every single decision we make is going to be the end of the world or the end of privacy or everything as an industry. I've never seen a perfect road. There is a pothole somewhere along the journey.

I can promise you that. But as long as you look forward, that's all that matters. Great. Keep on riding.

Keep on riding. Definitely. Thank you to all of our listeners for tuning into another episode of Security Podcasts in Silicon Valley, a wide security production. Thank you, everyone.

Jacob, thank you for your time. Thank you for being part of the show. Absolutely. Thanks.

Thanks, guys.