Zscaler is a cybersecurity company that provides cloud-based security solutions, zero trust architecture, and TLS inspection to help organizations securely operate in multi-tenant environments.
This episode was recorded at the Ai4 conference. Listen to our other Ai4 conversation with Anaconda’s Greg Jennings and Paypal’s Srini Venkatesan.
Connect with Sam Curry on LinkedIn or reach out via email at sam@zscaler.com.
TRANSCRIPT
[intro music]
Ryan Donovan: Hello and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are recording live from AI4. We are talking right now about the new security landscape with AI. And my guest for that is a rogue player coming over from Black Hat, the CISO for Zscaler, Sam Curry. So welcome to the show, Sam.
Sam Curry: Thanks for having me.
RD: Yeah, my pleasure.
SC: I like the label rogue player, especially in the context of Black Hat. So that's kind of fun.
RD: You know, everybody is getting into the AI, AI coding, integrating it into whatever products they have. It's everywhere, for good or ill. And one of the big issues people have talked about, I get pitches about it every day, is the AI security issue. From your perspective, what are the sort of button issues we're going to talk about AI? I mean, broad topic, right?
SC: Yeah, there's a ton of them. As with, I think, all of engineering and with many jobs, the question is, so what does it do to our job? What does it do to the need for us? And I would say some jobs are compressible, meaning efficiencies, meaning we don't need people doing those tasks anymore. And others are what Jeffrey Hinton calls elastic, meaning we actually need more people in some cases. In some cases, the job of engineers in DevOps is no longer as coders primarily, it's to produce high quality code at scale, which is more of a computer science function. And it's about architecture, infrastructure, supportability, deep conversations. And nobody yet has shown me a product where they said, oh, you know, all the enhancement requests are done and the competition has given up, and we finally reach the end of what's needed. Instead, I think, especially with code assist use cases, we're going to wind up in a world where we have to produce much higher quality faster. And so if we understand that distinction, I think it means that being AI-enabled may mean we need more carbon intelligence to go with the silicon. And so then you get to security, and we have a further dimension. I think we may get a SecOps revolution like the DevOps revolution. We have a further dimension of the opponent is asymmetric, is not... as it is say in engineering where you have other engineers building competitive products, they're actually using it asymmetrically and they're creating more noise for us to sift through, and they're also creating more signal for us to find. So where before we would find a signal in security operations every four or five hours, we're finding every four or five minutes. And it's harder to find it with more investigation, more consequences, more accountability issues. So that's a lot for any job to absorb. But having said that, given that engineering is now using these sort of intermediaries with CodeAssist, we have the opportunity to start, I think, embedding security more natively in applications as part of that
expanded demand on engineering. Say, let's get the signal closer to applications. Let's not just be over in the security land. We worry about logs. We're correlation monkeys who pour through logs, oceans and oceans of them. Instead, we can get better logs out of the systems. That's the first. What does it do to the job? What does it do to process? Then there's, what is it doing to the code integrity issue? And Mythos, I think, as Project Glasswing people have heard about, has really changed how people think about frontier models and some of the upcoming open-weight models and how they're going to be used for things like vulnerability operations and weakness detection. But also then you get the SSDLC. And how do we change the trade-offs we've taken for granted with our peers over the years? So how do we use it in making more robust and resilient code infrastructure, and then we get how do we use it in offense? How do we use it for things like what's called red teaming, continuous red teaming? And then how do we actually, perhaps given it, it's still non-deterministic, and that means it doesn't always produce the same result for the same prompts. How do we actually use it to do better security? Because the potential exists to improve what we've been using machine learning for what we've been doing with algorithmically, but maybe even some entirely new functions that we never considered. So there's a huge array, which is more than you probably asked.
RD: That is a whole lot to start with. Yeah, yeah. So let's start with the sort of SecDef problem of identifying threats. You talked about signal and noise, and the old way was to sort of spot patterns, spot noticeable behaviors, right? They're trying this, but there's a forward slash at the end. And now the patterns that are coming in are adaptable, but the AI makes us also adaptable. What's the sort of change in the cat-and-mouse game there?
SC: Pretty much everything at some level seems to be all layers of abstraction, whether we're talking language, computer language, even in physics, seems to follow some linguistic patterns, which means many of the AI breakthroughs apply. And I would say that with most breakthroughs that we've had in security over the years, information security, and specifically cybersecurity, there's ways of looking for patterns, and then there's ways of using this technology to hide better. And so, yeah, cat-and-mouse game is the way to look at it. So we're left with a few things to remark on. It isn't just a whack-a-mole game. So everyone says, well, if Mythos or OpenAI's Daybreak fill-in-the-brank model, right, to be fair, there's many companies doing this. Mythos has had most of the attention, rightly so recently, but rather than just the whack-a-mole game of just keep applying more of it in defense and more of it in offense, I think what we should be doing is thinking about how do we reduce the attack surface? How do we provide less opportunity for attackers to, whether it's carbon or silicon based, to actually have purchase, to have options? So mentioned the forward slash, right? So how do we prevent, we can do a shift right as opposed to shift left. We all talk about how do we do virtual patching, virtual shielding, runtime protection. So hybrid shellcode, buffer overflow, those things simply can't get through to applications. For probing and for actual exploitation.
RD: And by shift right you mean putting the security protections in the production system itself?
SC: In the actual– so if the application is running and you don't even know if a vulnerability exists yet, limit the ability for it to be enumerated, limit the ability for it to be done and for it to be probed and then limit the ability for certain kinds of attack methodologies to be used against it. We used to have a term called CHAM, common hacking attack methodologies, which most people don't remember anymore. But this is where the idea of WAF came from. The notion of web application firewalls. And at the same time, we can apply zero trust principles, which is not just least privilege, which is what most people go to. It's also least function. If you don't need a listener, don't have it. If you don't need an application or a feature, don't have it. If you can reduce the API calls, do that. And also limit the opportunity for lateral movement. But there's also least data sprawl and then maximize entropy, right? So if you have data at rest and you must have it, then make sure that it's encrypted or tokenized. Do not give opportunities for living off the land and for lateral movement. These attacks take time. And we can also start to do deception better. So we could do things like honey pot, sure, but we can honey net. Because once one of these advanced models gets past the crunchy exterior, which we should make less crunchy and less visible, then we can actually say, well, let's lure it in and waste its time with the creation of real-time rendered virtual networks. We have hypervisors. We can build them to go. And so that gives us an opportunity to buy time, waste their tokens, identify them, get true signals into ops because it is a race, even if it's an asymmetric one. So in other words, AI can help with all of that. It can help us render them more believably in a more appealing way with the baits and lures and decoys, rather than just whack them all faster on both sides. For us to actually ship, as I said earlier, better quality, faster code, but also more secure code than we've ever thought before. Just two years ago, the idea we could ship effectively bug-free code and defect-free code for a period of time, I think that was beyond our ken. And now that possibility really exists.
RD: Yeah, you mentioned the Mythos news. And I remember mentioning that to a guest who she now works for OWASP. And she had worked at the Canadian election securing that. And she was like, yeah, I'm not surprised. People are bad at security coding. So the fact that it found a ton of bugs everywhere, it's like, yeah, man.
SC: Yeah, it finds a ton of bugs. It also chains vulnerabilities, lows and mediums and highs into mediums, highs and criticals. It also writes real-time exploit code because we were Glasswing partners at Zscaler, one of the first three cyber companies, one of the first 40 companies in it. And it has a very high true positive rate. This is game-changing for how we do vulnerability management, vulnerability assessment. So I'm not surprised. In fact, I think going a step further, many of the abstraction layers we use for coding are really meant for human convenience within efficiencies for each one. What we found in our testing is that some of the languages suggested by NSA and NISC, but CSE, if you want to go Canadian, things like Rust and Go and Swift, have less vulnerabilities or a similar body of code.
RD: There was a White House report that was saying, you know, stop using C and C++ because of the memory safety issues.
SC: C Sharp is better than those two. And we've found that to be the case. But we can also write better code, better commented, more modularized. I used to think re-architecture was a dirty word in engineering. I was a CTO for years as well as a CISO. But not so much anymore. And if we go a step further, we can also start to get post-quantum ready. I think... the advice that I gave if we throw the AI out of that conversation is about being as future proof for all disruptions as we can be whether they're AI or not yeah so you know, quantum computing is going to be a big disruptor that one of the next ones. So how do we make sure we're as ready as we can be? Well those are zero trust principles things that might help the attacker can also help the defender in terms of you know, future proofing and quantum specifically.
RD: Is there a point where it's too much Future-proofing is a thing?
SC: Yeah. Look, I mean, in the end, we don't just do everything for the sake of doing it. It is about risk trade-offs and other business trade-offs. Specific ones are revenue. Are we doing this because it opens up new business opportunities and margin, but also customer satisfaction, employee efficiency? Does it serve a strategic purpose? If it doesn't meaningfully either reduce risk or open one of those up, now or in the foreseeable future, it's probably a waste of time. And so, you know, one of the things I ask people when I interview them for security positions is, tell me in a time when you've actually ignored a critical fix and why? And why is hard because otherwise that sounds like an anathema. I mean, I've suggested like, hey, tell me you've done something horrible you've done to a small animal, right? But no, the fact is that there's often things that sound like motherhood or apple pie if you just look at risk and abstraction, where business is about acceptable risk for acceptable return. And CISOs and security personnel, we have to remind ourselves, and this is important, we're business people first. We're actually risk managers first. And most CISOs don't grow up thinking, I'm business first, my expertise is in cyber. And that's how we're seen. We're seen as, hey, you're a hobbyist when it comes to the business. And frankly, we should be business first in all things.
RD: So tell me about a time you ignored a critical fix and why?
SC: Well, there are times where it's not just critical. Phones. Sometimes they're not reachable. Sometimes you can get to them at a later date. But if you've got to, let's say, launch something that is absolutely essential to deliver services to a customer, there have been features that I've rolled out where we've had to say, well, you know what? There is a critical fix, but it's not actually attainable. It's not something that's exposed. We can get to it at a later date. It will take time to do so. And it's more important for the customer's sake to get something else out. And that sort of thing happens.
RD: I mean, I think when I first started seeing security research stuff, there were wild research things that came out. Like you could upload a video file and gain control of the hypervisor. Or you could attach a fake I.O. port to a VM and gain access to everything. Those always seemed like it took a lot of effort to do. Are those more reachable for attackers now?
SC: Well, in some cases, you have to think about the scenario of the most reachable things are usually things further to the left in the attack matrix or the kill chain. They can bring the full bear of their engines to the attack, right? And there's usually enough noise that they can either hide in or create noise. You'll see a DDoS attack, for instance, or you'll see just overwhelming amounts of attacks. Once they start to penetrate and get into the quieter interior, then it becomes harder both to bring the resources to bear and there's less noise to hide in. But your questions are spot on. If you're running something in an inherently noisy environment or a multi-tenanted environment like a hypervisor, like a cloud environment, then there's more to hide in. And there's more places. There's a lot of traffic. There's a lot of activity happening. And so how you instrument it, how you work, and if you think about it, any organization that has silos is going to have communications issues sharing signal. And that's inherent in some cloud environments. So you've got to have a really good relationship with the people that you are working with who are hosting, right? For the people that you are working with who are your partners in that info stack. So it can be, but I think the way to think about this is now the body of code itself has got a few dimensions that are going to lend itself to finding these things more readily. Some of it is what you program in the compilers. What is the memory management like? What is the stack like? But some of it is also just the size of the code. You get an increase in complexity, an exponential increase in complexity with the body increasing linearly. So how do you modularize it, shrink it down, and reduce that inherent complexity? I should say, how do you make it less complicated and still support complexity? Because we want to leave as many options open with as simple an infrastructure as you can get.
RD: Do you have ways to spot that or protect that as a security CISO?
SC: Those are really emerging next practices. I've been asked, like, so what should we be measuring? What should the metrics be? And I think most of those are going to start to emerge right now because the new frontier models, the new ways we're coding are being done now. I think we're going to go through a period of, we'll call it chaos, with massive numbers of patches. And Y2K was one of these things where we knew the date and everybody could work on it. And so it became a relative non-event. With something like Mythos as a frontier model and peer models coming out, weaponized versions of them, we don't know what I’ll call it M-Day is.
RD: Yeah, I mean, it's Y2K all the time.
SC: Well, that and Glasswing only has a finite, relatively small number of companies in it. The more companies who are in it for longer, and the longer it takes to reach a day when that type of frontier caliber model is generally available as a weaponized version, the more like Y2K it starts to look. Because once those criticals and the critical path chains are addressed, we get into a zone where it becomes more predictable, gives the chance to update our best practices. We can change the way we do our SSDLC. We can do the shift right. We can code in better languages, get signal deeper in the application. All that stuff is really critical.
RD: But for all of these, you have to have those protections in place, right? Like hearing about the OpenAMI model escaping a sandbox and hacking Hugging Face. Like you have to have the production in place, you can't have a stale credential around, you have a open browser with a session that can pull.
SC: Yeah, there's a number of best practices that I think are going to emerge. We recently joined the open security AI alliance with some colleagues at NVIDIA's involved in it and others– objective is really to start to define some of these. What are the best practices for isolation? What are the best practices for harnesses? Those sorts of things. And they're meeting here this week, right, around Black Cat. So you'll see more publications around that. But rather than have each of us go and discover these on our own, it makes sense for us to come up with what are the best ways to measure these things and to put the ethics around it and to share that.
RD: And this is the same problem for everybody. And it should not be differentiating, right?
SC: There's two kinds of standards, right? There's the de facto ones where a standard just exists because somebody's gone and got market clout. And then there's de jure where we all sit around and go, well, how should we do this? And this is best done when it's compelling and we all go, who cares if we compete or not? Let's sit and do it. And that's one of these circumstances where we don't want to see something like a Hugging Face happen. And I don't really care about the politics or how it happened. It happened. So if it didn't happen, it could happen. So let's make sure that we actually establish what the guidelines are to do that. This is what happens with, say, children's products in retail. If a child gets hurt, they do a recall, figure out what happened, and never make that mistake again. And that's what we should be doing here.
RD: We're a customer of Zscaler. And in the early days, it has blocked legitimate things of mine. One of my colleagues called it a man-in-the-middle attack you pay for.
SC: And by the way, for those who don't know, that's because we do TLS inspection. We actually look at the traffic in transit. But one of the big hobbies people have at Black Hat, by the way, is lock picking. And you could say lock picking is just training people to break open vaults. But a practice that's used on the dark side has an entirely different purpose when used on the light side. And so once we can actually look at the traffic, we can do things like look for malware. We can start to look for harmful content. We can start to score risk and actually tease that traffic apart and say, is it doing what should be done? And with us, every single customer, every tenant has control over those policies. And in some cases, especially in places like Europe, where there's very specific regulations about privacy, it's used for the opposite. It's actually used to ensure that companies can't look at things like personal banking. So we sort that traffic out and it's used to enforce that because it's an audit trail. So you could look at it as the technical practice is used by the bad guys, but how it's implemented actually matters.
RD: And a lot of that pattern matching, right? AIs are pattern matching machines. How does that sort of CLS inspection process change with AI?
SC: I would say that, first of all, there's some algorithmic ways that this is done. Secondly, there's some machine learning based ways. And machine learning is really the first non-deterministic ways in which we did things like naive Bayes analysis or boosted random forest. There's a ton of these algorithms that have been used over the years. Some are better suited to things like fraud pattern detection and neural network stuff. Some to looking for rogue traffic or looking at rogue files and, you know, how to even integrity in files. But now what we're looking at is what more nuanced types of changes could we see? What more fuzzy logic might we be able to bring to bear? So I don't necessarily– I think what we might be able to do is to push the precision and accuracy further for some of the classic use cases, but now we can start to look for even more use cases, we can start to apply it for things like risk. Say, is something inherently risky or not? And then put someone, for instance, in a browser isolation session so that they're protected. Maybe somebody is phishing them. Maybe they're interacting with something they think is an AI service and isn't the one they think it is. Maybe they're about to put source code in there and they shouldn't, thinking that they're working with a code assist application in a web UI and it needs to actually be verified, right? Or maybe there's a customer information that they're sharing with what they think is a CRM application and it's not. And so this kind of understanding at scale can actually help us to get much more nuanced those rather than the black and white decisions those shades of gray with a higher yield at the same time. And done at scale, this can be done in a way that's also privacy protecting. So we're very careful about what do we do from a pattern recognition on anonymize a very few variables traffic, I'd say, outside of a tenant's domain versus within it, where the patterns are used for the benefit of that tenant. And then within that, there are best practices for policies to protect employees' privacy and how to communicate that to the employees. It also varies enormously by geography. I would say the United States, where we're recording this, is probably somewhere in the middle. Some countries have far less expectation of privacy and some have far more. And all of that can be serviced. And so then we get into also data sovereignty issues and who has the right to see it and who has the right to operate it and who has the right to work on it. And all of those can be done if it's architected correctly. As with most things, I would say that Zscalers is, but of course I wouldn't say that. I would invite anybody listening to check it out and also to do the same with my competitors. But I would say that these things can be architected well or poorly. And what we've tried to do is to design our architecture to be able to be future ready, not just for disruptions, which is what we hinted at earlier, but also for future compliance and regulatory needs. Things are never written to disk. Things only exist in memory. They're parallel processed, and the policies are actually interpreted in close to real time, but parallel, and each of the policy stacks is orthogonal to each other. And then the audit trail for that is available to the client itself, the user. That sort of thing has to be architected years in advance. You don't just bolt it on and worry, hey, I'll sort the tech debt out later.
RD: So a lot of the applications used in daily business life are SaaS applications that live in a browser. Does that make security harder? Like you mentioned faking a website, putting your source code in there, thinking it's like your code, your ID.
SC: It can. I never do a security review unless I can actually see the architecture. Let's take your typical AI application. You can implement it through a web browser. You can implement it through a thick client. You can look at it in transit. So you can look at it on the endpoint. You can look at it in the browser, which is really another platform. You can look at it in transit. Then you could host it, let's say, someone like Amazon Bedrock. And then you can control the back end. Or it could be going straight to the SaaS provider itself. And yeah, most of them are also SaaS providers, despite the SaaSpocalypse language. And what are they doing on the back end? Is it auditable? Have they limited provisioning capability? Is there a CLI for instance and because I'll tell you if there's a CLI and they have a limited provisioning, what happens when they have an insider incident and there's no audit trail? Right, so not to pick on any of them, when you do it the architecture matters, right? You've got to look at all these interfaces all the components and ask these same basic questions from a security perspective and so then you say well where's the acceptable risk for the acceptable return?
RD: And that's the security freedom trade-off, right?
SC: That's right.
RD: So for, you know, with AI becoming more prominent in all sides of it, what are you most worried about as a problem to solve?
SC: I'm worried at the moment about after what I've called M-Day, but that's not meant to be dramatic. I'm worried if it comes soon or generally, what happens when there's all the folks that weren't part of having time to prepare, thousands of vendors suddenly have to put out onesie twosie patches and fixes. So I'm not so much worried about what the bad guys do as the instability that could be called the data center that has to do hundreds if not thousands of updates per week for a while. And so my emphasis to people would be, do your TPRM, your third party risk management surveys, not debate at the wounded to make sure people are getting ready. Because you can get ready without access to say, Mythos or Daybreak or what have you. It would be beyond elevated alert because attackers are stepping it up to get ready for when they have copies of a weaponized version. But then in particular, get good at availability and resilience. Jen Easterly, who used to run CISA, spoke at Black Hat about resilience. We emphasize it, but everybody should be thinking, how do I make sure I can do a rollback? Have I tested my backup and my recovery? Am I thinking about disaster recovery and business continuity? These aren't even cyber questions. This is just basic hygiene. And do I need a code freeze if this happens or a production freeze in order to make sure I can handle some cadence of uptime maintenance, right? So emphasize that for the short term worries me the most. Longer term, I want to make sure that people are thinking about how to become more resilient to not just AI, because AI is one track of disruption with more frequent milestones coming on it. But there's many and each of them challenges us societally, and in, in our industry
there's quantum computing, we mentioned, but there's nanotechnology, and robotics, and synthetic manufacturing, and synthetic biology, and each of these is its own track with it and they all seem to be accelerating and we could get a comorbidity of some of these. So if people listen to the list that I gave, each of those things makes you generally more resilient to disruption. So things like zero trust matter, things like deception matter and better coding matter.
RD: And I think in the engineering world, you know, we all see those and we're like, ah, problems to solve. We can control this. We can do problems. In the larger world as a whole, they can't engineer their way out of it. Nobody really tackling those problems. Wendy and Heather used to refer to something called the security poverty line. And there's probably something similar in engineering and IT, which is below a certain point, there's no cavalry coming. There aren't many people and there may not even be a budget. And security that sometimes aren't named security folks or there's people who are on call with a part time role that come to come in and help the best. And so we need to use peacetime to prepare. We need to use now to prepare and not say, well, one day this is the day. And it's not about a vendor. It's about having some conversations with our peers and other people in our industry or in our region. If you know someone like a CISO or if you know an architect or somebody who's in who does this for a living, bring them in and have a chat. Ask what you should be doing because very simple readiness will help. Now, another general observation is in peacetime, we tend to go to less suppliers. We want five vendors, save some money. But what happens is those are called single points of failure. If one of them goes down, you go down. In wartime, we tend to diversify. We get more. That means you have redundancy. If one goes down, you've got failover. Start thinking about where your single points of failure are and say who if they go down. And when you do your TPRM check. Make sure that if you have single points of failure, you're talking to them and making sure they're getting ready. And if they're not, have a backup and test that backup. And this is just simple resilience. But if you do it now, you'll be far less panicked and far less at risk if something bad happens.
[music]
RD: Thank you for listening, everyone. I've been Ryan Donovan. I host the podcast and edit the blog here at Stack Overflow. If you want to reach out to me with questions, comments, topics, complaints, you can email me at podcast@stackoverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn.
SC: My name is Sam Curry. I am Chief Information Security Officer for Zscaler at zscaler.com. If you want to reach out to me, you can contact me on LinkedIn. Or actually, I don't mind emailing either. That's sam@zscaler.com.
RD: Thank you for listening, everyone. And we'll talk to you next time.
[outro music]