Welcome to Cybersecurity Insights, the podcast with the cyber ed.io learning community. Our goal is to have been cyber security practitioners, the latest and most relevant education and training to up seal and dive deeper into topics that matter in today's modern cyber security world. Good day, everyone. This is Steve King.
I'm the managing director at cyber ed.io. And with me today on the podcast, I'm lucky enough to have Brian Dye, who is the CEO for CoreLite. And we're going to talk a little bit about CoreLite today and what solutions they bring to this crazy party we're having here in cyber security. Brian's background is served in product management roles for McAfee and Citrix and Symantec earned his undergrad bachelor's degree in chemical engineering from MIT and his MBA from Stanford.
So welcome, Brian. We're happy to have you here. Steve, thanks for the time. I really appreciate it.
I think I'm a steal your line of the party that we're all having. I think it's a great frame for the industry at the moment. Yeah, you're welcome to it. Let's talk about protection, detection and resilience.
In particular, resilience has turned into kind of a buzzword that I'm not sure anybody understands. So maybe we could start there and talk about, let's define resilience and why we think that's so important. Yeah, and I'm 100% with you that this is one of those words like zero trust that a lot of people are using, but they mean different things and how they use them. And you know, the organizations we work with and that I'm learning from, I tend to hear kind of a three part definition around resilience.
Number one is it's about buying time, right? We've got kind of a bifurcation to attack landscape where you've got some incredibly fast attacks and you've got some really stealthy long run insidious attacks. So buying time to kind of find those and deal with those long run attacks is a big one. The second one kind of closely related is the ability to disrupt those attacks because if you're simply buying time and can't do anything with it, that's not a contested trade.
And third of course is the ability to really put a premium on the response capability because just like, you know, the wave of detection for the industry that's been super constructed was kind of compensating for the attacker evasion of the protection approaches, right? So protection, detection, resilience is this next category. It's really helping folks understand and create mental models for how do you how do you deal with the attacks that have bypassed detection technologies. You know, if I think about probably the most compelling example I heard from a customer in the last year is one organization we worked with was in a wonderful position of being under a $10 million plus ransomware demand.
But because they had really embraced this strategy of resilience, they could prove that while the attacker had claimed that they stole X, right, a certain volume of data with certain criticality of that data, they could actually prove internally that they'd only stolen about five to eight percent of that. And as a result, they were willing to, with the support of the board and the audit committee, actually turned down that ransomware demand. And that to me is just a great example of what resilience can mean when it all comes together. Yeah, so how did they do that?
That's kind of a data-centric issue, I guess, relative to cybersecurity defense. How did they manage that? You know, I can't do justice to the entire program, so I wouldn't presume to do so. But I think the biggest thing that they invested in as part of their resilience strategy was getting real ground truth of what has happened.
In treating telemetry logging invisibility as a first-class citizen, as part of their security strategy, because what they saw was this pattern of sunburst and log for shell and things like that, not to mention the current trend towards kind of, unfortunately, an increase in network device vulnerabilities that are giving more attackers a way in that they can't detect. And again, once you bypass those traditional detection technologies, you just need a historical record, a lot like the NTSB flight data recorder, right? You need something that lets you look back in time so that you get ground truth of what reality was, and that gave them the evidence and the context to be able to piece together what really happened in separating the attacker's claims from the actual attack reality. Yeah, and the attacks last week on Caesars and MGM are interesting in that the two companies took entirely different approaches to the ransomware demand.
And while Caesars happily or on happily fork over $15 million, they were back up and running in whatever was under 10 days where MGM tried and failed and spent at least 10 days in trying to recover and get back up and running. And so maybe the Caesars look like the more successful approach, yet on the other hand, this is a board level problem that we in the community have, is that we rarely understand the balance sheet issues that drive board behavior. So I work with Caesars all the time, most of them complain that the board doesn't understand what they're doing, they're not listening, blah, blah, blah. But, yeah, the board makes risk decisions all day long, and here's a case where I think it was less than a tenth of a percent of last year's revenue is what it costs them in operating losses.
So, who did the right thing there? Boy, that's a great question, and I wish I had a clear answer for it. I don't know what I presume to judge kind of the actions of any of the folks involved there. I think to your point about the boards, though, one of the things that I've seen from a number of different kind of CISO-level advisory boards I've been a part of is there's a real journey and a challenge that every CISO takes on of how to educate their board and how to assess their board's level of expertise in cyber decisions so that they understand the program, the actual, the addressable versus the non-aggressable risk, what remaining residual risk is being held, and translate that really into a language that that particular board can understand.
And I've heard a wide variety of that, right? One manufacturer literally had this technique of translating their vulnerabilities into defects per million, because as a manufacturing work, that's something that the board can understand. Yeah, but I do think the particular challenge boards have is, as you said, they make risk-based decisions all the time, but those risk-based decisions are in tend to be in business domains that they understand. They have deep institutional knowledge built up over the course of the careers of kind of what the relative, the game theory and the risk versus reward of those decisions.
And to say that there's advanced game theory in negotiating with a ransomware attacker, especially when it's a $10 million plus payment that's on the line, I think it would be an understatement. And I think that's a challenge where you've got boards probably are overestimating their knowledge of the game theory, the trust or lack of trust of the various actors involved, and that I would really encourage them to rely on not just their CISO and their security leadership team, but frankly, the expert advice of some of the pretty advanced folks in the IR community. I think of not picking any one kind of partner in particular, but if you look at Mandy and CrowdStrike, Deloitte, there's a number of these firms that have a lot of day-to-day experience dealing with ransomware actors, understanding reputation, seeing how the game theory goes back and forth here. I think that something boards probably aren't realizing that they need to take advantage of, because that discussion is a different type of risk-based analysis than maybe the traditional business decisions they're used to making.
Yeah, right. At the risk of going down a rabbit hole here, at this point, I want to ask you your opinion about the role of the CIO versus the role of the CISO in today's world. One way to look at this, I think, is that CIO has accountability and responsibility for the information domain for a company, and she would have a data center operations person reporting to him or her. He could easily have a security person reporting to him or it's more of a functional, in my mind, it's more of a functional distinction than it is like a separate entity that's kind of hanging out here on the side.
But that's the way we've evolved this. What's your opinion about where that function should truly report and whether today's CIO has the background skills and understanding necessary to run a secured information systems organization? Oh, it's a wonderful and rich topic. And I'm a big believer that there's actually no one right answer to the question that you're proposing, because different sectors, like if you think about both the scale of companies and how critical the risk is that they're managing, ultimately have a very different view of what their risk tolerance is.
You can look at this very simply by asking, looking at any given public company, what percentage of their revenue do they spend on IT and what percentage of their IT spend on security? And you can kind of see that math play out in different classes of companies. So if you look at what I see, you see some sectors that have very developed risk management offices that will often have or increasingly are having the InfoSec team actually report into their risk office. That has its own potential side effects, right?
Because there's a very low level technical knowledge, usually on account of the risk office. So there's no one perfect answer there. But it represents at least a recognition that the risk is so material to the fundamental operations of the company that it is more than just one part of how IT operates, right? It's its own pillar.
So I do see some folks kind of adopting that work structure. The much more common work structure of the CISO reporting up to the CIO. Actually, if you don't have a massive risk footprint, I think it can make sense. And to your point, it's really interesting to look at, as you will with any executive leadership role, you've got the structure based on the risk that you're trying to execute on.
And then what is the actual skill set and bias of the individual, right? That's actually leading that function. So if you've got a CIO that is really, really great on on business applications, but doesn't really understand the InfoSec world that well, but they've gotten incredibly strong CISO that they trust and truly empower, that can be a wonderful operating model. And I know a number of CISOs that are in that type of relationship, and it's earned a trust that involves the right access to the board, the right access to the audit committee, and everything else that goes with it.
I think as you go into organizations that perceive they have a much, much lower risk where you can run into a problem where InfoSec is this kind of annoyance as perceived by the CIO. And then you don't get the level of trust, you don't get the level of budgetary support. And then the board winds up carrying a lot more risk than they realize they're carrying. That's I think where things tend to go south.
But the reason I don't think there's any one answer to this is that the skill set and expertise of the CIO, the trust and the board access relationship with the CISO, and just the raw level of risk that that organization is actually trying to manage, those three things all vary quite a bit. And you can get different org structures that result from it. Yeah. So that's very different than like functionally then like the role of the Chief Financial Officer, right, who does not live in a world full of unknown unknowns.
And it is that in your mind that differentiation or distinction between those two roles, because there's hardly any science that all involved in information systems or InfoSec. Well, you know, whether there's science involved, we can have all rich conversation over a drink of our choice. But I think the question of the CFO's expertise and kind of whether implicitly whether the CIO and the CISO report up to the CFO is a great question. I think it's very similar to the previous discussion of how critical is InfoSec.
Increasingly, I see that the CIOs are reporting to the CFO only in the orgs that perceive they have a low risk tolerance, right? They tend to have a much smaller percentage of money spent on IT. IT is more of a supporting function than a business enabler. That's where you'll tend to see that org structure of the CIO report in the CFO.
And then as IT becomes more material like larger development teams, real business leverage, business acceleration, often the CIO is a direct report to the CIO. I mean, for like, obviously as a cybersecurity provider, we view actually InfoSec being dramatically more important than IT actually. So for me, I actually do the inverse. I have my IT function reporting to my CISO and my CISO reports to me, right?
Because that's obviously, we're kind of at the very risk intolerant and very security prioritized view of this whole discussion. Isn't everybody big though? Well, look, in a mission-oriented world, especially with your my kind of shared backgrounds, that's I think where we would start. But you know, imagine if you are a large-scale manufacturer of commodity goods, right?
And you're trying to drive as much, you know, if you're trying to drive your second digit of operating margin, and that's really kind of what's going to make or break your company in the financial market, it can be a unfortunate but rational decision to take on more risk from an IT at InfoSec standpoint. In that case, then you would say maybe you were a piece of a provider of critical infrastructure or financial institution or a mission-driven kind of government agency. So as tempting as it is to say, of course, we should mitigate all risks. I think if you're at the board level, that's not necessarily how they would look at it.
And in some cases, I think it's rational because the folks will have a different risk appetite based on the profile of their business. Yeah. So we have OT clients who will make similar arguments about why they, you know, will never shut the plant down for more than 10 minutes and did a deep part of my former life. I was a CIO at Memorex and I had responsibility for both IT and OT and we had, you know, three different manufacturing facilities.
And I used to have the same conversations with all of those my managers as well. And on the other hand, however, if any of these companies get hit with a cyber attack, that plant will be shut down for a long time. You know, so that's why it might lead your reaction to all of this as well. That should be the first thing that you do, you know, is protect that asset class.
Well, yes. And look, this is the challenge I think a lot of organizations face is how do you want to find and compare that risk to a number of the other risks that your organization faces? It was, it was many years ago, it was probably 10 plus years ago now where I was meeting with a mining company in a country outside the U.S. I'm going to be vague for obvious reasons here.
And the mining company was convinced that they were, they were kind of following this path that you and I are concerned about and were describing. But I said, look, we understand that there is a cyber issue, but frankly, we don't think that any of the assets we have really matter. So we're non-attractive target. And as a result, we're willing to take a lot more risk in our operations.
That mining company was attacked, I think, six months after I visited. Unfortunately. And so it's a really challenging thing to understand, you know, really from a creative and unfortunate destructive standpoint, what unusual asset do you have that someone else could monetize that? That you haven't correctly reflected your risk prioritization?
And then how do you get that business insight into the mind of the CISO and then correctly communicate up to the board level? That's a real challenge, right? Because you have to think in the level of not just the technical attacker but the financial attacker and kind of think about their incentives and then communicate, you know, translate that into the language of what the board can actually understand and then deal with whatever decision, either to address or accept that risk kind of the end of that conversation. That is a job I don't envy because it is a hard business risk assessment and communication challenge.
Yeah. Well, that is the job though. So you're right. So let's tell me a little bit about and our audience a little bit about CoreLight and what you guys do and you're in San Francisco, you know?
Yeah, we are in San Francisco. We're really distributing company though. So we've hired folks kind of all across, predominantly across the US, certainly in some kind of European countries as well. But you know, we're real simply, we try to provide folks ground truth of what's happening on their network.
And hence the visibility we have into this kind of overall theme of resilience because we tend to get brought in on programs like that. And I think there's a couple things that are unusual about the company. One is that we're actually open source based. So there's a open source project that's been around for 20 plus years, originally called Broke, now called Zeke, had to be renamed for fairly obvious reasons.
That's used by incredibly elite defensive organizations kind of in response consultant firms, kind of things like that. And as a result, we've been learning from the design patterns of these elite defenders of what are the combination of tools and techniques. They used to kind of drive that ground truth, both kind of data and detections of what's going on. And then we tried to take that insight and build that into the right form factors to meet the needs of different classes of defenders because it turns out that the software architecture and the defensive mode you have, if you have, you know, 500 to 1000 or 2000 folks within your security team.
It's very different than if you're running an organization that has maybe five or 10 or 20 folks in your security team. And so we really think about how to meet that same defensive challenge at those different kind of customer scales. But it all anchors around really providing folks ground truth, kind of the data and detections of what's going on in their network as a complement to your other technologies, right? So the network gives you breadth.
The endpoint gives you depth. Identity gives you some insight to tie that all together, right? We really view ourselves as part of the triangle of insight you need to run this off. And why wouldn't everybody do this?
You know, a lot of what we see is it's about maturity and adoption and what the best next move is for a defensive organization. And, you know, to kind of paint it broadly, I think it really mirrors this evolution of strategies, right, of protection to detection to resilience that we started out with. Because we find that when folks bring us in, what they've generally gotten done with right before us is a they made sure that they're on a modern effective Sim, right? You know, Splunk or something more modern, right?
Is a fair question. Just because there's so many waves of competition kind of happening at that altitude. And then they've done and generally been successful with a healthy EDR rollout. So CrowdStrike, Microsoft Defender, Sentinels, again, something that's a modern effective EDR.
And they've realized because look, there's a ton of value and a ton of yield in those two initiatives, right? They're going to enable effective detections, effective response to those detections, automation around your sock. There's a tremendous amount of value in those two categories. But then they get faced with the reality that, you know, like everything else in security, nothing's perfect.
And then as you move around where the weak spot in the organization is, you know, this evasion of your current detection technologies leads folks to resilience, right? They'll often be tracking things like, you know, what are the number of unresolved cases I have, right? Because that will tend to tell you where the holes in your defensive coverage are. That leads them to needing better visibility, that leads them to needing kind of ground truth on the network.
And then kind of we tend to get brought in at that point. And your network visibility is that extend beyond the physical network into the worldwide web as well? Well, we think of ourselves as providing visibility to the customer's networks, which could be in cloud environments, remote offices. We actually do have some folks looking at industrial controls and kind of manufacturing environments, as well as traditional kind of an on-premise or coload kind of data-side network.
But it really is where the customer's own network is, is where we tend to get deployed. And folks tend to kind of do three kind of different altitudes, if you will, of visibility, right? Folks will start with North-South, right? Ingress, egress, great place to find command control traffic, exfiltration, reconnaissance.
Then folks tend to look at kind of high-value enclaves during VPN subnets, DNS subnets, things like that. And then the folks that are the most advanced tend to look for lateral movement, right? They want to look at East-West movement within their own environments. So it tends to be kind of those three different altitudes.
Speaking of DNS, do you provide visibility into DNS vulnerabilities as well? We generally don't track vulnerabilities, but one of the things that we do, and again, this is learned from those elite defenders that we're following, is we think a lot about how do you make the evidence as compelling and complete as possible, so that the instant responder has the least amount of time to connect the dots. So one of the things that some of our customers will do is they'll take the results of vulnerability scans, or they'll take their asset information from their CMB, and they'll actually plug that into us so we can actually annotate what we see in the network with the vulnerability and the asset information. So you get all that in one kind of interconnected data set, which tends to make the analyst experience easier, the answer response process faster, and your downstream kind of in-house detection engineering, or your in-house kind of SOC automation more effective.
So that's really where that linkage tends to show up. What do you think, or what do you expect the impact of generative AI to be on the environments that shit your product the best? Yeah, look, I think it'd be a shame if we didn't kind of touch on JNI almost every week, right? I am a huge fan of the technology.
I think it is going to help defenders all around the world. I think it helps most defenders click up half an elevation of expertise, if you will. I think you see this with not just what we've done in the technology, which I'll talk about in a second, but just in the last week, you saw announcements from both CrowdStrike and Southawon of kind of what they're embedding into their technology. I think, frankly, every security provider should be using the large language models to help accelerate SOC workflows.
And if they're not doing it by the end of this calendar year, I think they're either drunk or asleep at the wheel. Yeah, exactly. And we had a really unusual path into this, because, again, being open source base, we were on an advisory board back in March, kind of right after 3.5, GPT 3.5, kind of hit the airwaves. And we heard from a number of our customers who are, again, pretty elite defenders themselves, that they were using chat GPT with our product.
We hadn't done a thing, by the way, but they were using chat GPT with our product to help do things like, what does this alert mean, and where should I start investigations of this type of alerts? And then it hit us, like, oh, wait, because the large language models are trained on the public internet, they're aware of the open source tech that we're based on, and they're already fluent in the data model and the tech. So you can use chat GPT out of the box with our technology before we put a calorie effort into it, which is just kind of a wonderful byproduct of the distributed innovation that comes from being open source base. But the moment we saw that, when we saw these elite defenders doing this, seeing really tactical and practical value out of it, that's when the bit flipped for us that, oh my gosh, we should absolutely be doing this.
We embedded, in our case, chat GPT into the product a few months ago. We've gotten some really good feedback on it, but I think it's an unqualified positive. So long as you mitigate the two key risks, you've got to mitigate the hallucination problem. You've got to know when to stop trusting the large language models.
And two, you've got to really mitigate the data transfer problem. You've got to make darn sure that customer data isn't flowing into any place it can leak or get exposed in the model. So that's an important disclaimer that's worth calling out. Yeah, sure.
And so in your view, I guess disruption is a key part of somebody's security strategy then, right? Yeah, I think it's, I mean, A, look, we need to take advantage of the large language models because they are they are productively disrupting the whole industry. I mean, look, the cost of labor has gone down for all of us are setting a more favorable way. The productivity of our team should go up, right?
Which is a wonderful thing because almost every security team, everyone that I've ever met, feels like they're underwater. So I think that's incredibly positive. And then look, we've got to recognize that the attackers themselves, especially those advanced attacks, are going to be low and slow long dwell time, often evasive. And so the ability to go and disrupt those attackers and kind of embrace the strategy resilience, I think it's got to be part of the next gen of all of our strategy thinking.
Yeah, I'm sure it does. I'm conscious of the time here. Maybe one last question or so. Most security models, and I think you agree are pretty much focused on.
And this is kind of, maybe Cesar is a good example of this. We're focused on protection and detection. You were a bad guy when you come right back to Cesar's because they didn't fix anything. I'm pretty sure.
At least one of the legs of that three leg, it's through with people processing technology. They didn't fix anything in a 10-day period. Aren't they just as exposed as they were pre-breach? That is one of several things I'd be very worried about.
And one of my first conversations when I joined Corlide over five years ago was with an Insta response consultant that I said, look, let's treat me like an idiot. Why does this kind of ground truth really matter? And what's the role of networking in really how you do these investigations? And he started off with the things you would expect, right?
You know, the ability to really successfully and quickly resolve investigations by providing the right context around alerts, the right connectivity across the kill chain. But then he bookended it with the two things that you're alluding to, right? Number one is you've got the breadth that you get from the network. It allows you to prioritize the Insta response activities when you can't boil the ocean, right?
So there's a really important value prop in the front end of that process. And at the back end of that process, the ability to have ground truths that you have confirmed successful remediation and that you can now prove the scope of defensible disclosure is really, really important. The specific example you'd walk me through is, look, you know, everyone thinks about the sheer number of buyer consultants that are going in to help, you know, anybody who's in that unfortunate kind of breach situation. This is never forget that once those people, right, which could be 10, 20 people easily, have believed they have found the issue, believed they've contained it and have proven to themselves that they've actually got the attacker kind of removed from the environment, which again, in the case of those recent vagusary breaches are still a question.
Once they leave, a handful of those consultants say, and then the lawyers show up. Because now you've got to prove to the lawyers what your scope of disclosure is. And that really puts a lot of pressure around proving containment, proving remediation kind of beyond the shadow of it out, because otherwise you have to, you know, especially with the C disclosure rules, you've got to go err on the side of a broader disclosure, which, you know, just ripples through the negative impacts we're all trying to avoid. Yeah, they're kidding.
Great answer. Thank you. We're probably out of time. But I've enjoyed this immensely.
It's been great talking with you. We'll have to do this again sooner or later if that's okay with you, because we could probably talk for days about all of these topics. And they're important. You know, that our little contribution here at CyberEd is trying to, you know, get people smarter about cyber security.
And we don't have enough skilled engineers or support staff to provide the level of security that we need. And, you know, I know of only one way to get there, and that's what we're trying to do. So anyway, thank you for taking time out today. And as I said, I enjoyed the heck out of it.
And once again to our audience, this is Brian Dye, and with the Chief Executive Officer of Corlight. And I'm going to invite him back in a couple of months so we can do this again. Thanks, guys. We really appreciate you.
Yeah, it was great. And thank you to our audience for spending a half an hour with us today. And we hope you enjoyed this as well. Until next time, I'm Steve King, your host, signing up.
Thank you for joining us for another episode of Cyber Security Insights. You can connect with us on LinkedIn or Facebook or send us an email at social at cybered.io. For more information about the podcast, visit cybered.io or slash podcast. Until next week, stay safe and secure, and we'll see you on the next episode of Cyber Security Insights.