Security is a process

This is the Cloud Security Today podcast, where leaders learn how to get Cloud security done, and now, your host, Matt Chiodi.

[00:14] Matt Chiodi: What is process mining? Anytime I hear a new term, I'm always keen to learn just how could it be used from a cybersecurity perspective, and the term, process mining, was one that I was not at all familiar with. So, I had to have John Morello on the show. Now, some of you may not know John. John is the former VP of Product at Palo Alto Networks. I worked with him while we were there during the Prisma Cloud days, and before that, he was a CTO at Twistlock. Some of you may remember Twistlock. Twistlock was a company that was acquired by Palo Alto Networks, but they were the first to really bring container security to the world, and now, John is the CTO at a startup called Gutsy, and they are focused on bringing process mining to the world of cybersecurity. As always, I think you're going to enjoy this, and for me, I think one of the hallmarks that I have tried to go after in my career is just always being hungry to learn something new, and you'll hear me talk about this in the show, but one of my favorite quotes of all time is from Bruce Schneier. Bruce Schneier is famed in the industry. He was originally a cryptographer, but he had this quote, and it says that “security is a process, not a product,” and you'll hear me mention this in the show, but that quote has always stuck with me, because right now, I've been in security for over 20 years, and one of the things I have seen happen time and time again, is yes, cybersecurity budgets are often under-invested, but we always tend to think that means that it's tools that have been under-invested in, but if you go back to that quote, and you're talking about process, well, how much are we investing in discovering the actual processes that make up cybersecurity? And that's what we're going to talk about in today's podcast. I hope you enjoy it. John, thanks for joining us.

[02:07] John Morello: Thanks, Matt.

[02:08] Matt: And I know you mentioned to me, right before the show started, that you're not feeling great. So, I appreciate you doing this for the audience.

[02:15] John: No problem. Thanks for having me.

[02:17] Matt: Awesome. So, I've known you for a while. We worked together back at Palo Alto Networks, back in the Prisma Cloud days. You had come over from Twistlock as part of the acquisition, and you have been in cybersecurity for a number of years, and the one thing I love to ask people who have been doing cyber for, let's say, more than a decade, is to talk about your journey in cybersecurity. So, maybe for you, I know you spent some time at Microsoft. You've had a lot of different roles. Maybe starting from your early days at Microsoft, talk with us a little bit about your journey to your role now as CTO at Gutsy.

[02:58] John Yeah, sure. I would say it actually probably started before Microsoft. When I was a student at LSU, I was a student worker at, I guess, the IT department on campus that they call computing services, and this was in the late 90s, before computer security was really thought of as a discipline, I guess you'd say. Today, it's such a weird thing, but at the time, the school still, as far as I know, owns an entire Class B. 130.39, I remember very well, was LSU’s Class B, and literally every single device that was on the network, the Secretary's desktop in the physics department had a publicly-routed, non-filtered, non-firewalled IP address, and as you can imagine, all kinds of hilarity ensued. I remember, at the time, your PC had a physical light to indicate hard drive activity. You’d get these reports of people were trading pirated software or music, or whatever, you could literally walk into the room, and you could identify the machine by the light or by the sound of the hard drive just continuously spinning. So, I started doing all kinds of various incident response type stuff there, and universities unfortunately have a lot of problems with, not just with malicious trading of music and stuff, but all kinds of other computer-related crimes that we help gather evidence for and so forth, and then when I started at Microsoft, I did a lot of that same work when I was in the support organization at Microsoft.

When I first started, I supported customers who were on Windows 2000, at the time, and Windows 98, and helped with security issues they had with that, but I really got a lot more back into security when I went into consulting in about 2002 and did a lot of security projects all over the world, honestly, but particularly in US federal space. I deployed the first smart cards and PKI at the White House, did a bunch of other things across DOD and the intel community. That was really probably one of the things I've enjoyed most of my career. I got to do a bunch of cool things and go to a lot of really interesting places, and work on a bunch of secure things, and so forth, so it was good. Then I worked in the product team at Microsoft, and I was responsible for Active Directory Certificate Services, which is the PKI component in Windows, which is actually the federal root CA, runs on Windows Servers, as does a lot of the infrastructure in the world that's used to issue certificates for smart cards and for employee identification purposes, and then after that, I was the CISO at a S&P 500 chemical manufacturer for a couple of years. A company called Albemarle, who's the number one lithium provider in the world. So, Tesla was actually one of their biggest customers, and I think they were Tesla's largest supplier. So, I did that for a couple of years, and I learned that if you really like technology, you should probably not work at an old manufacturing company.

So, then we started Twistlock in 2015. We built the whole idea of container security that evolve later into, I guess, you’d call CNAPP today, Cloud Native Application Protection Platforms. So, we did Twistlock from 2015 to 2019, was really fortunate to have some more amazing experiences with that. I wrote the NIST Special pub book container security 801-90, we had cut with, I think 420-something customers when we sold the company. So, we had literally every level agency. If you've ever used in-flight Wi Fi, be that on GoGo, or on one of the other providers, that's all protected by Twistlock. Twistlock’s on the F-35. It's used when you buy a Starbucks coffee, you subscribe to Disney plus. So, really awesome to have had all those experiences. We sold Twistlock in 2019 for about half a billion dollars. So, it's a good exit, and stayed at Palo for a few years where I was the VP of Product for Prisma Cloud, and then in 2022, a little bit more than a year ago, we started Gutsy, and been Gutsy for about a year now, and hopefully we'll be able to have the same kinds of experiences that we were able to have a Twistlock.

[07:29] Matt: That's pretty awesome. So, you've done a lot of different roles in cyber. You've been on, so to say, both sides of the table. From a vendor perspective, but also on the industry side, as a user of security tools. I think that you gave us, let's call it, the 10,000-foot view of your career. Were there any pivotal moments or maybe key decisions that you made along the way that, now in retrospect, you can look back on and say, “Wow, that really helped get me to where I am, in terms of, obviously being in leadership?”

[08:06] John: Yeah, I mean, you're right. I've been at it for a long time. I used to always be the youngest person on teams, and so forth, and at some point in the past 10 years, I guess I looked around, I'm usually one of the oldest persons now. So, somehow, I guess I've been doing this for about 25 years at this point, but I mean, in all honesty, I've never been somebody that really sought out to become a leader, so to speak, in the sense of wanting to have a particular title or something. I've always really been much more motivated by doing interesting work, that I'm proud of the work that I'm doing, and so forth, and I’ve let that guide me. I mean, I think any time you look back and have any retrospective on whatever you've done in life, you're always going to find the things that led you to where you're at now. So, there's a little bit of self-selection bias with it, but I mean, for me, having the direct experience, working with customers, and as a customer, not just early in my career, but even to this day. I mean, I still work with customers to this very day, with Gutsy, all the time. I met with three different customers just today. That grounding in reality, I think, is so vital to build a security product that's actually practically useful and valuable to people. That, if you don't have it, I don't know that there's a substitute for it.

There's a lot of really smart guys that may have spent their entire careers building amazing technical achievements in software, or hardware, for that matter, but if you don't build them in a way that customers are going to be able to actually implement and operate, then it's not going to really make that much of a difference in the world, and I think unfortunately, in security, there's been a lot of that. There's been a lot of really interesting technical things that have been built, but that were not built with an understanding or an optimization for deployability and usability, and because of that, you might have this great idea that is just never actually able to be used.

[10:07] Matt: I love that. So, I know that one of the areas that we focus on a lot, back in Palo Alto Networks with Prisma Cloud was, there was always something specifically related to Cloud with governance. Governance was a huge topic for a lot of our customers. From your perspective, I think you said you left Palo Alto probably about a year ago.

[10:29] John: Yeah, a little bit more than a year ago.

[10:30] Matt: What do you see as maybe some of the most pressing challenges today in cybersecurity, maybe with respect to governance?

[10:38] John: Well, obviously, because that's what we do with Gutsy, I guess anything that I answer is going to sound a little bit sales-pitch, so forgive me for that, but really, when we thought about things that we could do for the new company, it's not like we woke up one day like, “Oh, my God. We need to do this process mining thing. We've been called by God to do this.” I think the reality for most startups is, you want to do something, and you try to think about all kinds of different things that could be viable products and make viable companies, and we thought of all kinds of things, both things that seem very obvious, maybe there's a new way to do runtime that would be better for Cloud than traditional approaches, and all kinds of esoteric things that you could build that would defend against a particular attack, and so forth. Those things are important. There's a place for all that stuff, but if you really try to reflect back on the long arc of your career at this point, you think about what are the real problems that prevented people from getting the security outcomes they want? Which is basically not get compromise, not lose people's data, be able to be a partner to the business instead of an adversary to your own organization. Those kinds of things.

Fundamentally, it's almost always about governance, and when I say governance, governance is this weird idea where people think it's about auditing, and their experience with Archer back in 2002. I mean, to me, when I think of governance, I really think of it as, if you think of what a CISO is supposed to do, that's what governance is, and what I mean by that is, it's about saying, “what are my priorities? What are the goals that I have for each of those priority areas? How do I measure performance towards those goals? How do I find out the things that are delaying or preventing me from reaching those goals? And how do I communicate about my progress and those impediments to myself, to my stakeholders, to my boss, to my peers, that are part of those those goals? How do I do all of that in a way that's effective and data-driven, and that allows me to actually make good decisions?”

It's weird if you think about it, but historically, something like that, that's that fundamental, people not really had any software that assisted them with it. It was something that we just assumed you did that, and people would bring in the McKinsey's and Big Four, and people like that, and I'm not saying that there's not value or there's not a place for that, but even if you've got really great people that you can bring in to consult, they’re people. They're not infinitely scalable. They can't work with infinite amounts of data. They don't give you a real time view. They give you perspective in places, but that's the fundamental approach with Gutsy, is that, not saying that we're replacing those people necessarily, but at least if you can augment them, and you can give people a clear data-driven understanding of how their organization actually works, what are the impediments, or the friction points that are preventing them from getting the results that they want, to be able to communicate that in an objective, clear fashion to others, and thus, jointly to be able to improve the overall security posture of the organization. I mean, that's what we're trying to do. Obviously, we've got to do a lot more work to get to that point and prove ourselves, and make sure it's a product, again, that people can deploy, use, and get value out of, but that's the idea, and if we actually are able to execute on that, that can have a really meaningful impact on the overall security for our customers.

[14:07] Matt: So, I think right now, you mentioned the term, process mining. So, before you and I had spoke, I was not familiar with this. Maybe take a minute or two just to explain to the audience, what is process mining? And what is it typically used for? How could it be of use to a cybersecurity leader or a cybersecurity team?

[14:29] John: It's honestly not that complicated of an idea. It's a fancy term or new term, but when I explain it, the idea will make sense, which is, imagine that you have a complex business process. Doesn't have to even be security, because process mining has been used now for over a decade in non-security use cases, especially in the ERP manufacturing worlds. It's been used for a while to help organizations increase their profitability, operate more efficiently, be able to deliver the results better. Basically, the idea of process mining is that, in one of these complex processes, you've got lots of individual systems, and each one of those individual systems sees its own myopic or narrow view of what that process actually is. It's, what's that analogy with the people touching the elephant? Each tell you “Oh, it's a trunk, or it's a leg,” wherever. They all see their own little piece of it. The idea of process mining is that if you can connect to each one of those individual systems, and you can pull out the data about what they're doing individually, you can build a software data model that represents those relationships between the individual systems, as parts of an overall system, parts of an overall process that deliver some outcome, and that once you get that perspective, from the process into perspective, you can begin to identify the things that are causing you problems within that process or delaying, or preventing you from getting the outcomes that you want.

So, let me give you an example, and I'll use, well, that's not even security, back to when a Albemarle days. Let's say that you're a chemical manufacturer. So, you've got some ERP tool, like Salesforce, that you use to manage opportunities for people to buy your lithium or whatever it might be. So, you're managing that in a CRM. Well, somebody places an order. Maybe that goes into Oracle NetSuite, is what you use for that side of it, and then in SAP is how you manage the whole supply chain, the manufacturing process you have, and then maybe the backend, when you send them an invoice, it goes through Microsoft Dynamics, and then in the next step, there's something else you use for delivery, and in between each one of those, there's emails, and there's spreadsheets that people create and move, and so forth. All of those things are part of a process, the end result of which is somebody places an order, you ship them a product, and you receive a check from them. If you can connect to each one of those systems and extract the data about what they do individually, now you can start representing what that looks like, not as just saying, “Hey, I got an order on August 1, I shipped it on December 20, and I receive the revenue on March 2. I don't really know why. Is that good? Is that bad? Should I be able to do it fast or whatever?”

Imagine now, though, what you can see is every one of those those orders, you can look at basically as a Google Map, where you can see, what is the flow that it took? Where was the traffic jam? Did it sit waiting for raw materials for three weeks, and if we'd have had that in our warehouse, could we have recognized revenue the prior month than we did? Do we always have this big delay when it has to go through this approval because this approver person is really backed up? Whatever those problems and inefficiencies are, you can identify those, and thus, you can work to remove those or reduce those in the system, increasing your profitability, lowering your risk, and/or at least, lowering the amount of cost that you have.

Now, take that same approach and apply that to cybersecurity. Of course, lowering cost is always good. I mean, everybody's trying to operate more efficiently in general, but there's a really fundamental thing to keep in mind with security, which is that in security, inefficiency, and inconsistency are highly correlated with risk. In other words, for any given security process, you have patching vulnerabilities, off-boarding users, how your SOC responds to incidents. The less efficient the processes, or the less consistently you follow it, the greater the risk in the process. Normally, if it takes you, whatever, 30 days to patch a critical CVE, but sometimes it takes you four months, well, that additional three months of time is not just wasted effort or delay. That's three months that you're exposed to that vulnerability, and maybe that's an obvious thing, but if you think about it, again, from that process-centric standpoint, it becomes clear that if you can remove or reduce the inefficiency in the process, even if all the other tools and all the threats stay the same, stay constant, your overall risk can be reduced, and that's really the fundamental essence of what we're trying to do, which is help you really get more out of those resources that you've already got.

[19:03] Matt: So, cybersecurity has evolved a lot over the last decade. There's so much specialization that happens now. Are there certain, let's call it, functions within cybersecurity, where you feel that process mining could have a greater benefit than, let's say, another?

[19:23] John: I think in general, almost everything in security is ultimately a process. Think about anything from identity management. Identity management is about, you onboard somebody in your HR system, you need to create accounts for them, you need to enable MFA for them, you need to make sure they get provisioned to the right resources, they move jobs, you need to make sure they remove the prior access they had, and add that new access to the new role they leave. You need to do all those things in reverse. Vulnerabilities. You detect a vulnerability, you triage it, you assign it somebody to fix it, build the fix. Really, when you think about security, it's almost all about process. So, I think it's less saying that it's better or more suited for one particular area of practice than another, and more so, just recognize that almost everything in security is about process, and if you can apply this same discipline to everything that you're doing, then you can really improve the results that you have.

Now, that said, obviously, there's some things that are probably going to have a quicker or more visible ROI than others for most organizations. What we found at the beginning is the things that people tell us that they struggle the most with are things like vulnerability management, identity management, specifically the off-boarding scenario is something that people almost universally say that they struggle with, and then optimizing the way that they do incident response. So, by the time the SOC gets an incident, what do they do with it from that point forward? Now, the same ideas are applicable to things like data security. How do you do classification and sanitization and things of that nature? But those three areas that I just mentioned, around identities and vulnerabilities and incidents, that seems to be the ones that we're starting with, because we see the most common identification by customers about.

[21:09] Matt: One of my favorite quotes is from Bruce Schneier, and I think this was back in either 1999, somewhere, a long time ago, and he said, “security is a process, not a product.” Have you read that before?

[21:23] John: He wrote a great essay in 2000. The title is The Process of Security, and, in fact, that motivated me, that article. We talked with Bruce, and he's actually an advisor for us. He’s an officially-invested advisor. In fact, I’m going out to shoot some video content with him next month, so he's a really great guy in the industry. Somebody I've long admired, and very honored to work with him.

[21:55] Matt: I love it, and I did not know that. That was not a planted question. I go back and find blogs where I've quoted that five years ago.

[22:05] John: It's because it's so true, and the sad part about it, I guess, is that, it was true in 2000, it's still true today, and it just shows you that in that area of security, the operational aspects of security, there's really been almost no maturation or improvement over those past 25 years. There's just been so much focus on tools, and again our messages and our relief. It's not like, “well, tools are bad. You don't need tools. You don't need firewalls.” Obviously not true, but I also think there's way too much time that security leaders spend just trying to chase the latest tech tool or trend, or “well, I've got product X and vendor Y just came out, they say they do this a better way,” when in reality, you've seen this, Matt, with the Cloud security reports that we did at Palo, the majority of stuff that people fall victim to is not some esoteric nation state attack with an 0 Day. They haven't patched a CVE that's been known about for three years, and why haven't they? Probably some process failure. You don't need to have the best tool in the world, the most advanced tool, to tell you that. If you're not even doing the basic stuff well, well, the attacker is going to find the easiest path and they're not going to burn some amazing exploit on you if you've got a struts vulnerability from 2007 on your website, I mean, there's no reason to do that.

[23:31] Matt: Yeah. One of the statistics from, I think this was a Cloud threat report that was done in the last 18 months by Palo, and I think it was 99% of granted IAM permissions are never used. 99%.

[23:46] John: That's a great example.

[24:36] Matt: I love this, and I want to, I guess, dig into a little bit. I'm not sure how much research you guys have done on this, but the reason I've always loved that quote, “security is a process, not a product.“ The reason I've always loved that quote is because I think that, again, like you said, I did this research, I think it was probably about two years ago, where I looked at what were the vulnerabilities that we were talking about a decade ago and what are we talking to about today? Looking at a DVIR from 10 years ago versus today, things haven't really changed that much, and we've had an exponential growth of security tools. We've had exponential growth in the number of cybersecurity practitioners, there's been exponential growth in the amount of investment, and you can argue that it's still under-invested. We won't get into that right now, but why is it that you think, when we look at other disciplines, let's say we talk about accounting. If we talk about engineering of some certain sort, where there is professional certifications, a CPA or something like that, have you guys uncovered, why, or maybe some of the reasons behind why there hasn't been more of a focus in cyber around process?

[25:45] John: It's a very profound philosophical question. I've actually thought about that same thing a lot, and to me, I guess, probably the most relevant answer, there's probably a lot of different answers from here, but the most relevant answer to me is that in a lot of those other disciplines that you mentioned, it's because the practitioners are working within an established framework where there are rules that can't be violated, if you're an accountant, I guess, unless your company's doing something illegal, they're not going to be, “this thing should be accounted for as a credit, not a debit.” I guess, it could be illegal, but I mean, in general, there is a rule with the way that you do accounting. If you're talking about how do you do civil engineering? Well, there's rules of physics. If the bridge is heavier than the supports are going to support, they're going to fall. I think one of the challenges that we have in security is that you've got a bunch of best practices. It's not like we lack for best practices. NIST, and CIS, there's endless best practices, but the problem that we that we end up with is, security is always looked at as this cost, in many cases this barrier that is constantly at friction to what “the business wants,” because usually what the business wants is many times pretty much at odds, in terms of what's a good security practice.

I mean, you were around during the days, if you remember, BYOD was the big thing that everybody wanted, because they got sick of dealing with corporate laptops. Well, why did they hate corporate laptops? Because they were locked down, and you couldn't play your music on it and watch Netflix, but there was good reasons for that thing, and I think there's always a trade off. I think if you're in a security role, and you look at yourself primarily as the person that's saying no to everything, that's also not the right approach to take, but it's also not really fair to tell security people “look, we're going to make all these demands to give you all these contradictory signals. Security is the most important thing. Oh, by the way, I'm the CEO and only be bothered with using multi factor authentication. I just want to type in my wife's birthday as a password.” Well, you can't have both. There's trade offs that are going to be made in either case, and I think the relative youth of the security industry, it hasn't established some of those things as clear best practices, beyond the security organization.

Now, I will say, I'm not super hopeful about it in the near term, but over time, I do think things like this recent SEC ruling or regulation with reporting, the Uber CISO situation, and some of these things where it's becoming more obvious that there is a personal legal liability, is going to change some of that mindset with it, where it's not just like, “well, we got compromised, and it's going to look bad on my resume, maybe if somebody does some research for my next job, but now I might do time” or if you're what a risk committee of a corporation's board, maybe you're personally liable for making some decision that was clearly a poor choice. I think that may drive different behaviors, just as you saw with other regulatory things, like Sarbanes Oxley and so forth in the past. So, I have a little bit of hoping that. Not a tremendous amount, but I think that's the best thing that I've seen in recent time, at least.

[29:18] Matt: I was just talking with someone earlier today about the upcoming SEC cybersecurity rules, obviously. A guest I had on my podcast earlier. I had talked a little bit about that as well, and I do think that these rules go into effect, December 15, 2023. This episode will probably come out after that, but I do think that those things are going to cause a massive ripple effect through security over the next probably three to five years, and when you think about a process, when you think about, you mentioned optimizing IR or IM off-boarding, IM is a space that I've been focused on over the last few years, and I can tell you clearly, and I can validate that most organizations will say, “hey, we do a pretty good job with onboarding. People get into our PeopleSoft or our Workday system, and we have a pretty good way of getting them in the door, but then when they're here for a year, three years, five years, they start to get more and more access.” That's not always centralized. A lot of times it's decentralized. They're getting access to some system that's not plugged in.

[30:28] John: Not into the corporate directory, or whatever. It's just this little side thing that exists out there. Yeah, absolutely.

[30:35] John: and then you think about bringing this back to the the new SEC rules, with this four-day disclosure requirement. When you think about it, I know I did a poll on LinkedIn, and a number of people participated, and probably their biggest challenge that they identified was the timing around that four-day rule, and if you think about it, why would it take someone so long? If there's a nation state or somebody that's advanced that's in your system, obviously, they're not going to be in there doing a DDoS. It's going to be some low and slow attack. One of the things I didn't spend a lot of time in was IR in my career, but I would imagine that one of the reasons why finding an attacker in your system may take longer than four days, may take a long time, is because, A, that data is spread out across many different systems that may give you that indicator of compromise, and B, there are so many different people that are potentially involved, even across just a single cybersecurity Department, not including even the business, the marketing, the sales teams, the engineering, etc. So, I'm curious, from your perspective, in what you see, how does all that tie back to the concept with process mining?

So, I want to dig into it a little bit. I think I understand, generally, what process mining is, but let's contextualize this. Let's talk about, specifically, IM off-boarding. How would someone apply process mining to IM off-boarding? If they're like, “yes, that's an issue.” If someone wanted to do it, how would they apply it?

[32:16] John: So, first of all, I think your example is a really good one, because people think about identity management, in terms of off-boarding and onboarding, but one of the things we always tell people is that, what are the bigger risks that's oftentimes completely on people are unaware of is moving. People go from job A to job B, to Job C. Not as common these days, but if you're at a place 10/12/15 years or whatever, you might have responsibilities and access to things that you haven't worked on in a decade, something that you don't need any access to because people are afraid, if you take it away, it will break or there's not a process that's built for that, but to answer your question more directly about how do you think of incident response as a process or how process mining be applied to it, well, if you think about incident response, there's a series of individual systems that comprise what that incident response workflow looks like. You probably have some employee product, or CrowdStrike, or something similar, that's designed to find that anomaly. So, it's going to find it, and it's probably going to create an alert in something, maybe that goes to a sub, maybe that's inside of their own product, but there'll be some log that's created about it. The next thing is, there's probably going to be some ticket created for somebody to go and analyze it, if it's beyond something that can be auto remediated or there's a playbook that can be run and can be turned off automatically.

If there needs to be a human in the loop to look at it, there will probably be a ticket created. Something like Jira or a lot of customers might use ServiceNow for that, or something. There's going to be some work that a human being does to triage that. They're going to go with her through some analysis, they might gather data from a system. In many cases, today, that work that they're doing is something that's done through some programmatically accessible surface of the environment that you're working in. If you're talking about doing forensics in AWS, you're using a lot of Ec2 capabilities to do that, to take snapshots and gather data, and so forth, and so, because of that, you even have those artifacts of what people are doing as they do the forensics themselves. That can be mined. It can be taken into what happened when and who did it, and what times, and then there's hopefully some resolution to take it as updated as this was determined or this was taken, or maybe it's determined to be a compromise and the action that's taken is you remove that EC two instance, you terminate the instance and you redeploy a new one without the vulnerability, or whatever it was that led to the compromise.

So, there's, whatever, 5/6/8 different systems. Some of those things can be outsourced. As a lot of people these days are trying to utilize MDR providers for doing their SOC because they can't keep up with the staffing demands of that. Maybe they've got some managed service provider that actually operates the firewall that did the initial detection or whatever it might be. So, it's not even just different tools, but in many cases, is entirely different organizations. It may not even be your own staff members that are going to be that. You're depending on a service provider for it. So, what process mining can do is pull you into all those different systems, again, pulling data from all that, and to be able to show you visually what those different process variations look like. Again, imagine Google Maps with different routes to the destination, maybe even different destinations, showing you the traffic, showing you the detours, where you can see all that. You can zoom in and out and basically saying, “we want to look at maybe the most common variants, or I want to look at the three most common things together and compare them, and so forth,” all of which are backed by data. So, it's not like, “hey, here's this visualization and trust that it's right,” but literally, you can go and trace down the exact steps that this variant had, and you can see, “Matt, at this timestamp, did this activity,” and so it's all objective, in terms of how it's developed.

Well, the value for you in that is, now, when you look at that process map, you can see, “okay, look, if my SLA is that I want to close out a critical incident within 24 hours. I want to feel like I've remediated a critical incident within 24 hours, or maybe within four days. I've investigated that.” One of those steps in that process might be, if I determined that this is a valid incident, that meets the bar for notification, that I have a notification process that I also follow as part of that workflow, and I can look at that variant and say, “if I didn't do that within four days, which is what I'm obligated to do, why not? Was there a delay from the time it was detected until the time that we looked at it? Was there a delay that, the user that was supposed to be doing that analysis didn't take action in a rapid enough fashion? Was there a problem with maybe a tool that detects something that it should have? Whatever those root causes are, you can see those, and you can hold the people that are responsible, accountable. You could say, “Look, if I'm paying this MDR provider to be able to notify me of that incident within two hours, but it's taking them usually a day or two to do that, well, that's half my notification window that I've eaten up because the vendor hasn't met their obligations,” and so again, the governance capability with process mining gives you that objective, data-driven view of where are those friction points? Where are those delays? So, you can hold people accountable, you communicate about progress, and you can really get more out of what that process is supposed to be delivering.

[37:28] Matt: It sounds like process mining, cybersecurity itself, when you look at those long chain of events, even the scenario we just went through, it's extremely complex, and you're only touching on probably 2% of the actual tasks that are happening. So, I think I get that from a technology perspective, but if someone wanted to apply process mining to whatever it might be, they're trying to secure their Cloud presence. There are things that humans are going to do that aren't going to be captured in a system. So, I know a lot of this is obviously driven by multiple different systems. How do you fill in the gaps when humans are doing something that may not be captured in a system?

[38:11] John: It's a good question, and it's one of those things that seems almost magical or impossible to be able to do it, and of course, if there's absolutely no record of something, well, there'd be no way that we could do anything with it. Nobody could. It's not magic. There are limits within the system that you have to deal with. What we found, though, in practice, is that even when there is an activity that's being done by a human, there's almost always some of digital artifact or event that's created about that, and that could be based on being able to diff the state of some setting or system or something from before and after, and say “this used to be set to true and now it's set to false or this used to be setting X and now it’s setting Y or something.” You can see that there was an action that was taken, and in many cases, actually see that it was user Matt that made this change from one thing to another, even if there's not something that Matt specifically changed the value to ticket for, but we also have the ability to go and collect data in unstructured sources.

Imagine a Slack channel, where you and your colleagues of the SOC team are just collaborating about some incident. You would think of that normally, you can't really collect that data, because there's no structure to it, but that's one of the places we actually utilize AI in the product. Specifically, we use Google's Bert model, which gives us this ability to have a fully offline way of being able to look at unstructured data and extract from that unstructured data specific security event details, but to do so completely offline. We don't have to send our customers data to any third party. We're not going to ChatGPT or OpenAI or whatever. It's entirely internal, and we could build a model expressly to be able to to pull that information out of these unstructured sources, like Slack, like email, the body of a Jira ticket, where it might just be freeform communications.

As I said, there's a lot that you can do simply by diffing settings and the state of different systems, but we can also augment that by pulling in this information from unstructured sources, and the thing with process mining as a data science, is that there's generally not ever just one way to do something. There's lots of different ways, and you're not saying we always depend on seeing X in this system and Y in that system. There's a whole bunch of heuristics and different approaches we can take to try to structure the knowledge that we have in this inherently messy, real universe that we live in, to be able to get that information, to make some sense out of it, and ultimately, that's what people are buying with the product. You could fundamentally sit down and say, “I could pull all these event logs for all these different systems, and I could put it in Tableau or Power BI, and I could try and create all these relationships.” If you had infinite time and intelligence, you could build something like that, but that's the value of buying our product is, it will do that for you, and you could take advantage of all the knowledge that we've gained, having built this for other customers and seeing how other customers environments also at work.

[41:12] Matt: That's interesting. Well, John, I think this has been pretty interesting, and I'm always looking for new ideas, and when I saw that you were working on this, I was like, “I’ve got to talk to John,” because process mining, the Bruce Schneier quote that we already talked about, I'm like, “maybe they're onto something here. Maybe this is going to be the thing that changes the trajectory of cybersecurity, so that in another 10 years from now, we're not talking about some national security system that got breached because it had a vulnerability that could have been patched 10 years ago.”

[41:45] John: Oh, well, we certainly hope so. It's up to us to earn that, and we don’t take anything for granted or feel like that's in the bag or anything. There's a lot of hard work to do to get to that point, but we do think that if it's something that we execute on, we do a good job with it, and do what we believe is possible with that, it really can't have a meaningful impact.

[42:02] Matt: So, I've got a ton of respect for you. I knew that, from our time working together at Palo Alto, in our meetings internally, externally, I was always impressed with how sharp you were and how well educated you were on whatever the topic was. How do you stay sharp? What's your method for learning? What are you reading or listening to?

[42:21] John: I actually still use RSS if you remember that old thing. I loved RSS. I hate the fact that it cut out and became a lot less cool. The only thing that I found that it still does, RSS, is Feedly. So, I still look at Feedly for, I don't know, I've got probably a couple 100 RSS feeds that I scan through, more or less on a daily basis. So, that's to stay up with tech news and so forth, but, just general reading, I guess I don't read any books about business or security for that. I tend to read history or fiction or whatever, but, I mean, I guess, just trying to stay well-versed in the world versus being always focused on my own particular discipline.

[43:08] Matt: It’s interesting. It sounds like you're like me. If you could see my bookshelf, I have probably two or three, maybe four cybersecurity books, but the rest of them have nothing to do with cybersecurity, and as I read something about history, I find I can make more connections with things that have maybe nothing initially to do with cybersecurity, but I'll be like, “Whoa, that has a parallel and I know the author didn't intend that.” Do you find that as well, when you read things that are outside cyber?

[43:35] John: Absolutely. I mean, I've always been someone who's read a lot, I’ve just been really interested in the Second World War, as an example. There's lots of parallels towards Battlefield tactics that maybe is obvious, but some of the societal trends that continue to repeat themselves in human history and within organizations, not necessarily the nation state level, but even just within large organizations, the power of personality among certain leaders, and the inability for people at a certain point to question what seems obviously like poor strategic decisions by leaders because of that power of personality that they have, and I think we've all seen that just in our own little meaningless corporate lives. You see situations, like we were talking about earlier, where the CEO tells everybody how important it is that they go through the cybersecurity training, and then they refuse to do it themselves, or they don't want to be bothered by having a password on their iPad, because it's an annoyance to them or something, and they get their way. I've never seen a situation where the CEO was told no when they didn't want to have something like that. So, yeah, I mean, there's certainly a lot of parallels to that and life in general. I go to conferences and things.

Actually, I remember, one of the most memorable things that I've ever heard in our world was at a BlackHat. Michael Aiden, who was a creator of NSA and four star general in the Air Force, he had his quote talking about, basically, in typical military campaigns, battle spaces, the defenders and the attackers, they each have relative strengths and weaknesses. There's some things that favor one, some things that favor the other. May not be balanced all the time, but over time, it's generally balanced between two, but then in cyber, the difference is that almost all of the advantages favor the defender, they can basically attack at any time, there's limitless resources, there's very little accountability or responsibility that can be associated with them, and the disadvantages are all on the defender. Even if you do your job right 99.99% of the time, there's that .01% of the time where it fails. While it can be this huge incident, there's really no way to quantify the return on a particular investment of the fits versus what you might get, in terms of a benefit, and I've always found that to be a really helpful way to think about our jobs and the difficulty that we have.

That's one of the things that we hope that we could do with Gutsy is because today, there's so much of what you do as a CISO, or as a security leader that ends up becoming anecdotal because of that. You're just like, “well, if you don't give me more money for this, there's all these really bad things that could happen,” and we want to really be able to show “hey, we made all these investments. These are some things that aren't working, and we're waiting a long time for the business leader to approve deploying a patch to a vulnerability. We have our firewall telling us all these risks that are there, and yet, we're not going to block access to this group of people that, clearly, are not going through their training or don't know what they're doing when they’re clicking on malware, or whatever.” Those are the kinds of things that we hope we can surface so that there's a more objective, data-driven view to understand what that return on investment is for those security investments that you're making.

[46:53] Matt: It's awesome. I love it. So, something I definitely need to read more up on, process mining. I'll be excited to watch you guys in your journey as you build out Gutsy over the course of 2024 and beyond. Thanks for coming.

[47:05] John: Thanks, Matt. Appreciate you all.

Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.