We just sent you a verification email. Please verify your account to gain access to
RSA Conference 2024. If you don’t think you received an email check your
spam folder.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open this link to automatically sign into the site.
Register For RSA Conference 2024
Please fill out the information below. You will recieve an email with a verification link confirming your registration. Click the link to automatically sign into the site.
You’re almost there!
We just sent you a verification email. Please click the verification button in the email. Once your email address is verified, you will have full access to all event content for RSA Conference 2024.
I want my badge and interests to be visible to all attendees.
Checking this box will display your presense on the attendees list, view your profile and allow other attendees to contact you via 1-1 chat. Read the Privacy Policy. At any time, you can choose to disable this preference.
Select your Interests!
add
Upload your photo
Uploading..
OR
Connect via Twitter
Connect via Linkedin
EDIT PASSWORD
Share
Forgot Password
Almost there!
We just sent you a verification email. Please verify your account to gain access to
RSA Conference 2024. If you don’t think you received an email check your
spam folder.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open this link to automatically sign into the site.
Sign in to gain access to RSA Conference 2024
Please sign in with LinkedIn to continue to RSA Conference 2024. Signing in with LinkedIn ensures a professional environment.
>> Hi, everybody. Welcome back to RSAC 2024. Come on inside theCUBE. We're here at Moscone West. Alicia Keys is just about to start. It's amazing. What time is it? 2:30, 2:50 in the afternoon. RSA Conference actually does it a little differently. Usually these shows are at night. Not here. It's novel. Jake King is here. He's the head of threat security intelligence at Elastic. Jake, welcome to theCUBE. Good to see you.>> Thanks for having us here. Excited to be here.>> Let me set up the premise because I love this that you guys shared with us. And this to me, Shelly, is one of the big themes that we're hearing this year that we didn't hear last year, generative AI and LLM implementations. As we all know, they become widely available over the past 18 months. A lot of companies pushing to implement them as quickly as possible, but this has expanded the attack surface and left developers and security teams without clear guidance on how to adopt emerging LLM technology safely. Last year, we were of course talking about LLMs, how the bad guys are going to be writing better phishing, how the good guys are going to be able to automate, but now we're talking about the threat surface expanding, how do we protect LLMs and large language models and all this new AI, generative AI.>> Absolutely. It's an emerging space and I think what's most exciting about it is we're on that wave. We're surfing the wave of LLMs and technology with AI. I think as practitioners gain experience and understanding of where their risks are in these systems, it's going to be important to keep up with the capabilities to monitor and observe those risks, be able to do something about it. It's pretty a interesting challenge.>> So what is the data telling you in terms of the techniques that hackers are using, that adversaries are using to exploit LLMs?>> There's a number of public bodies of research out there. At Elastic, we've authored some papers that are aligned with the OWASP Top Ten, released a great research paper last year. We've expanded upon that very recently to include a number of our thoughts and remediations and findings. But if you think about the LLM attack surface, it's everything from the way that someone might interact with the model through the prompts, the questions that you may ask of the model, all the way down to controls that you have to put in place on the hosts that are running those models. So think traditional endpoint security controls or risk mitigations around traditional threat actors. I think there's a lot of corollaries between what we see in LLM security and traditional detection engineering, but because so many security companies are now leveraging security for AI, getting those kind of controls in place, AI for security is one of those first use cases that we see going out there.>> Well, and the security industry has always had an affinity for machine learning and artificial intelligence, but this is new. So how should we think about gen AI versus traditional, legacy AI, if I can call it that?>> Yeah. In terms of artificial intelligence, standardized models trained, often very specifically trained, on particular parts of a problem within the enterprise. Generative AI allows us to ask generic questions of a system that can be used in multiple different cases. So this could be anything from attack discovery or writing cases or building insights from raw alert telemetry all the way to saying, "Hey. We've got a user trying to flood the LLM with a series of requests. How are we able to notify our security teams of those classes of abuse?" And so if we think what's slightly different, general, let's say the legacy models as you put it, could be specific tied to a feature in a product. LLM technology tends to be on the edge. It's a little bit closer to the user. It's able to provide follow-ups and feedbacks and context. So things like token usage, things like prompt injection, concepts around being able to gain confidential information from those systems becomes really critical to understand and obviously assign some controls around.>> So this LLM safety assessment, that's what you were talking about, the research that is a couple years old that you've continued to augment and add to and that sort of thing, right? So it looks like the goal here is to be able to publish this information broadly as a checklist, the how-to, you're struggling with this, that sort of thing. Is that correct assessment of the assessment?>> Yes. Certainly. So we drew a lot from the OWASP Top Ten research, public standards to organizations that's really built amazing research and controls around those core primitives that can be assigned or aligned with existing vendors. Really what the report covers is an expansion of some of those initial findings and some of the recommendations that we provided, but alongside that publication was a set of detection rules that customers can leverage as they start to bring this content in through partners like Amazon's Bedrock service to better understand what people are using those LLM interfaces for and potentially where some of those abuses may align to. And so we take the guidance from the Top Ten as the things operators of models or creators of models should think about and expand it upon that original OWASP research. And obviously applying some detection rules to it gives us the ability to allow practitioners to see those risks in their environment and potentially even address them if they're able to respond .>> Somebody said the other day that there's 2,400 LLMs. This is the other day. It was 800 a couple of weeks ago. Now it's 2,400 inside a hugging face. So how do you keep up with all the diversity using AI presumably to do some of that? But are you discerning, Jake, any patterns in all these LLMs? I got to believe some are more secure than others. So what's your point of view on that space?>> We're learning a lot about these new models as they come out. So everything from open-source models that can be self-hosted to vendors providing inference services and hosted models themselves that customers can directly interact with. And I think the power behind making sure we unify the system logs that are coming from these tools is probably the first port of call. So alongside the detection rules we released, we obviously shared a number of open standard rules that map to ECS. So ECS is our common schema. We take from disparate group of very inconsistent fields that multiple vendors send us and we unify those in the fields that we can write logic around and find common things. So every LLM's going to have things like the prompt message that the user might send. It'll likely have a response. When some models provide things like latency information, others may provide whether the question was potentially hitting a data set or meta-condition. So applying these kind of standards allows us to write generic rules that apply to multiple vendors. And as we add to integrations, I'm sure there's ways of using AI to help that integration process, not that we're doing that today, but certainly is an interesting premise and definitely a use case I can see bing used>> How secure is RAG, retrieval augmented generation? Obviously, the very popular or increasingly popular technique to take your own content, use a vector database and embed specific content and extract nuggets and people are doing it all over the place. How secure is RAG?>> RAG is the secret weapon when it comes to a defender's arsenal? When you think about providing your organization's context to a model, it can give you really interesting insights. So let's use an example of someone in a security operation center who wants to know how to respond to a particular attack. Leveraging capabilities such as RAG would allow you to provide to the playbook that engineer could follow to then follow your best practice as an organization when a condition is met. So you could ask the model, "Hey. Who do I need to speak to about this alert that's fired in my SIM?" Ask your AI assistant and you receive a response that could be tailor-made for your organization. And as to how secure this kind of technology is, it's very akin to the models themselves. It's mostly about making sure the controls of what you feed into the model meets what your organization expects to get out of it, so tokenizing important values, making sure fields are private, confidential fields that are private aren't added to the model yourself, and just making sure that the information provided to those models is obviously in line with best practice and standards.>> Are you seeing organizations say, "Okay. I want to build this stuff on-prem because I feel like it's more secure. I'm worried about LLM leakage or a token leakage if it's in the cloud and API creating more seams."? Is that a trend that you actually see?>> I see two arguments to that point, and I've heard a various amount of opinions on at the conference today and throughout the week. We hear people that say, "Hey. I want to use my own LLM and I'm going to build this in my infrastructure and I'm going to use these open source models and build the controls around it myself," all the way to vendors that say, "I want to trust experts that build these models themselves and host them and provide an API service." Different use cases for different conditions. There's no one right answer or wrong answer. Much like we've seen a massive amount of maturity and cloud-hosted security applications. So we now see Glove Cloud from all the major cloud vendors. It's likely that we'll see these capabilities move into very secure hosted or cloud-delivered solutions as well. But alongside that, just seeing standards like the NIST standard being drafted and obviously being released a couple of weeks ago, obviously being finalized in June through their feedback period, will be really interesting. And I think we'll start to see not necessarily perspectives, but actual opinions on why a customer may choose to run a model internally versus using a hosted model with a cloud provider.>> Don't you think that some of the reason that people want to do it on-prem right now anyways because they're just a little nervous? Maybe it's financial services. Maybe it's healthcare. Maybe it's whatever. I mean, and to me, it seems like walk before we can run maybe could be some of this approach here and that's understandable. Yeah.>> Yeah. Definitely. It's actually a really good perspective, because much like we saw with early AI, early machine learning implementations rather, people would host these models, they would run them on standardized compute. And then we saw GPU acceleration and capabilities that came alongside that, and then obviously hosting cloud services. To the point that you've made, I think there's a really interesting component of this. We're likely in the stage of infancy of how these models will need to scale, how these models will actually be used. And so a lot of companies, I feel are likely using models at a small scale now and planning for broad scale broader adoption as we go. And I can see that being advantageous in self-hosted models and obviously cloud-hosted models in different ways.>> Yeah. I mean, I think we're all wired differently and we're all willing to take X amount of risk, and we can't assume that everybody across the board is the same, right?>> 100%.>> So with search AI, you're really modernizing the SOC, right?>> Yeah.>> And what I really like... I was looking a little bit at your attack discovery functionality and the triage capabilities there. I mean, really what you're talking about is taking something that typically can take a bunch of time and shortening that significantly. So tell us a little bit more about attack discovery.>> Attack discovery at its core is... When we look at attack discovery, it's AI for security use cases in the enterprise. So it's applying models, feedback, statistics, analysis over events that happen inside of your SIM, correlating those into a sequence of events and presenting example, an authored example, of how an adversary may have attacked your environment. But as a counterpoint to that, it also explains to the analyst how to potentially understand what happened and the sequence of those events. Attack discovery is an incredible capability that I actually see being fundamental as we start to move into a very fast-paced mode of operations in the SOC. Being a SOC analyst in the past, and you wake up in the morning and you see 100s of alerts, getting that down to a sequence of events that you can actually know what to really look at first is just going to shorten the time to delivery, but really improve the value of how that engineer can respond to those kind of threats. At the same time though, I think it's about making sure that these kind of attack discovery components can be integrated well into workflows. So not only being able to action that at the incident or at the alert level, but being able to work with it in your case management systems and being able to pass that to other engineers to build a case, do an investigation and complete it is a huge part of it.>> Yeah. Much more organized.>> Yeah.>> Can you talk to SIM modernization? It's a topic we've heard a lot at this event. Shelly's sick of probably hearing me say this, but practitioners have told us, CISOs have said, "I'd love to get rid of my SIM, but I can't because it's in compliance.">> Or somebody told us earlier today that they had seven SIMs that were .>> Yeah. Yeah. About that.>> Seven SIMs, and said there was a reason for doing that, but it's like, "Oh, my gosh.">> Right. So->> I think building a broad set of defenses, centralizing security information is always going to be the best way of understanding the entire attack landscape for an organization. So I understand different environments grow over time. They grow through acquisition or scale or other things that bring us technology in interesting ways. SIM's always going to be core to the security operations experience, but it's about making sure that the SIM component that you've built is aware of where the future is going. We're moving to a world where models, artificial intelligence is going to assist us in discovering threats. It's going to be a platform that we need to understand the risks of itself, monitor the LLMs themselves in an environment, but also that last component, being able to make sure that the way we respond to threats and the way we respond to adversarial actors in an environment can be done rapidly and very effectively. And that's part of a broader strategy that every SOCA's got to look at. I think when you think about what is next, it's about building amazing capabilities that allow you to look across your data environment, provide results that matter, but do it with context. And I think that's really truly the value of future SIM.>> We see that->> Okay. Go ahead, please.>> No. Go right ahead. I didn't->> I just had one last question, but if you have another one, go for it.>> No, no, no. Go right ahead.>> Okay. 2023 was all about gen AI, gen AI for bad, gen AI for good. 2024, we just talked about security for AI. RSA 2025, what do you think we're going to be talking about?>> Ooh. I was talking to a number of folks about what they expected this year, and it was everyone from operators to investors in the space and practitioners that are building these platforms. And the common theme that I'm hearing is automation, bringing orchestration and automation to the response actions that LLMs are providing. Taking the next step by saying, "I trust the way the model's going to operate. I trust the engineer that can click that button to action their recommendations from my model." But more so than that, just really expanding upon the ways that we help defend models by understanding the way that adversaries are going to attack them. If we see last year as being the infancy stages of so many LLMs and so many environments, we see the next phase of this being those environments scaling, customers using them more, building more. So it's just a really incredible thing. And I think we're going to see more attacks. I think we're going to see more defenses, but likely see some very powerful capabilities come out of it too.>> You think we'll see a lot more LLMs?>> I think we'll see a lot more LLMs. I think they're around for a while. The first year is the hype cycle. The second year is, "Is it going to stay?" Third year's when it starts to .>> So the number of LLMs is growing. We saw Databricks announce. Snowflake has to announce an LLM. Okay. That's cool. Do you think at some point, it's going to peak and then consolidate? I mean, ultimately it will, but... I don't know. I'm going to ask you how long you think. I mean, it feels like it's got some legs.>> It's got some legs.>> It feels like the CapEx is there, the funding is there. Could be another couple of years before we see the peak of LLM introductions.>> I think we'll see excitement around capabilities. I think we'll see breakthroughs. We're at a phase of LLM development akin to the early phases of cloud. Amazing big companies building great technology, open source companies building additive capabilities, and then obviously the consolidation of a lot of those capabilities. It's going to be a really interesting time for LLMs. And crystal ball says that I think we've got one or two more peaks before we get to that.>> It's amazing the pace. I mean, Llama 3 comes out. LAMA 2, retire it. Just replace. Copy, replace, boom, done. It's over. And people just don't even use Llama 2 anymore. Why would you?>> The example that->> Why would you use the dumber model? We want the smart model.>> The example that I've used in the past has been thinking of LLMs not as an AI model that you can talk to as a SaaS product, but thinking of it as an operating system with inputs and outputs, with interpretations of code, with translations, with capabilities. If we think about it like that, maybe this is the start of where LLMs start to look. We see new operating systems every few years. Maybe it's new LLMs every few years.>> Jake King, thanks so much for coming on theCUBE.>> Thank you.>> Good luck to your Canucks. Go Bruins. Maybe we'll see you in the playoffs. That would be an awesome rematch.>> I think it'll be pretty good.>> Canucks-Bruins, 2024. We'd love to see it. All right. Thank you again. All right. For Shelley Kramer, this is Dave Vellante. You're watching theCUBE's coverage RSAC 2024. We'll be right back to wrap up day four right after this break.
>> Hi, everybody. Welcome back to RSAC 2024. Come on inside theCUBE. We're here at Moscone West. Alicia Keys is just about to start. It's amazing. What time is it? 2:30, 2:50 in the afternoon. RSA Conference actually does it a little differently. Usually these shows are at night. Not here. It's novel. Jake King is here. He's the head of threat security intelligence at Elastic. Jake, welcome to theCUBE. Good to see you.>> Thanks for having us here. Excited to be here.>> Let me set up the premise because I love this that you guys shared with us. And this to me, Shelly, is one of the big themes that we're hearing this year that we didn't hear last year, generative AI and LLM implementations. As we all know, they become widely available over the past 18 months. A lot of companies pushing to implement them as quickly as possible, but this has expanded the attack surface and left developers and security teams without clear guidance on how to adopt emerging LLM technology safely. Last year, we were of course talking about LLMs, how the bad guys are going to be writing better phishing, how the good guys are going to be able to automate, but now we're talking about the threat surface expanding, how do we protect LLMs and large language models and all this new AI, generative AI.>> Absolutely. It's an emerging space and I think what's most exciting about it is we're on that wave. We're surfing the wave of LLMs and technology with AI. I think as practitioners gain experience and understanding of where their risks are in these systems, it's going to be important to keep up with the capabilities to monitor and observe those risks, be able to do something about it. It's pretty a interesting challenge.>> So what is the data telling you in terms of the techniques that hackers are using, that adversaries are using to exploit LLMs?>> There's a number of public bodies of research out there. At Elastic, we've authored some papers that are aligned with the OWASP Top Ten, released a great research paper last year. We've expanded upon that very recently to include a number of our thoughts and remediations and findings. But if you think about the LLM attack surface, it's everything from the way that someone might interact with the model through the prompts, the questions that you may ask of the model, all the way down to controls that you have to put in place on the hosts that are running those models. So think traditional endpoint security controls or risk mitigations around traditional threat actors. I think there's a lot of corollaries between what we see in LLM security and traditional detection engineering, but because so many security companies are now leveraging security for AI, getting those kind of controls in place, AI for security is one of those first use cases that we see going out there.>> Well, and the security industry has always had an affinity for machine learning and artificial intelligence, but this is new. So how should we think about gen AI versus traditional, legacy AI, if I can call it that?>> Yeah. In terms of artificial intelligence, standardized models trained, often very specifically trained, on particular parts of a problem within the enterprise. Generative AI allows us to ask generic questions of a system that can be used in multiple different cases. So this could be anything from attack discovery or writing cases or building insights from raw alert telemetry all the way to saying, "Hey. We've got a user trying to flood the LLM with a series of requests. How are we able to notify our security teams of those classes of abuse?" And so if we think what's slightly different, general, let's say the legacy models as you put it, could be specific tied to a feature in a product. LLM technology tends to be on the edge. It's a little bit closer to the user. It's able to provide follow-ups and feedbacks and context. So things like token usage, things like prompt injection, concepts around being able to gain confidential information from those systems becomes really critical to understand and obviously assign some controls around.>> So this LLM safety assessment, that's what you were talking about, the research that is a couple years old that you've continued to augment and add to and that sort of thing, right? So it looks like the goal here is to be able to publish this information broadly as a checklist, the how-to, you're struggling with this, that sort of thing. Is that correct assessment of the assessment?>> Yes. Certainly. So we drew a lot from the OWASP Top Ten research, public standards to organizations that's really built amazing research and controls around those core primitives that can be assigned or aligned with existing vendors. Really what the report covers is an expansion of some of those initial findings and some of the recommendations that we provided, but alongside that publication was a set of detection rules that customers can leverage as they start to bring this content in through partners like Amazon's Bedrock service to better understand what people are using those LLM interfaces for and potentially where some of those abuses may align to. And so we take the guidance from the Top Ten as the things operators of models or creators of models should think about and expand it upon that original OWASP research. And obviously applying some detection rules to it gives us the ability to allow practitioners to see those risks in their environment and potentially even address them if they're able to respond .>> Somebody said the other day that there's 2,400 LLMs. This is the other day. It was 800 a couple of weeks ago. Now it's 2,400 inside a hugging face. So how do you keep up with all the diversity using AI presumably to do some of that? But are you discerning, Jake, any patterns in all these LLMs? I got to believe some are more secure than others. So what's your point of view on that space?>> We're learning a lot about these new models as they come out. So everything from open-source models that can be self-hosted to vendors providing inference services and hosted models themselves that customers can directly interact with. And I think the power behind making sure we unify the system logs that are coming from these tools is probably the first port of call. So alongside the detection rules we released, we obviously shared a number of open standard rules that map to ECS. So ECS is our common schema. We take from disparate group of very inconsistent fields that multiple vendors send us and we unify those in the fields that we can write logic around and find common things. So every LLM's going to have things like the prompt message that the user might send. It'll likely have a response. When some models provide things like latency information, others may provide whether the question was potentially hitting a data set or meta-condition. So applying these kind of standards allows us to write generic rules that apply to multiple vendors. And as we add to integrations, I'm sure there's ways of using AI to help that integration process, not that we're doing that today, but certainly is an interesting premise and definitely a use case I can see bing used>> How secure is RAG, retrieval augmented generation? Obviously, the very popular or increasingly popular technique to take your own content, use a vector database and embed specific content and extract nuggets and people are doing it all over the place. How secure is RAG?>> RAG is the secret weapon when it comes to a defender's arsenal? When you think about providing your organization's context to a model, it can give you really interesting insights. So let's use an example of someone in a security operation center who wants to know how to respond to a particular attack. Leveraging capabilities such as RAG would allow you to provide to the playbook that engineer could follow to then follow your best practice as an organization when a condition is met. So you could ask the model, "Hey. Who do I need to speak to about this alert that's fired in my SIM?" Ask your AI assistant and you receive a response that could be tailor-made for your organization. And as to how secure this kind of technology is, it's very akin to the models themselves. It's mostly about making sure the controls of what you feed into the model meets what your organization expects to get out of it, so tokenizing important values, making sure fields are private, confidential fields that are private aren't added to the model yourself, and just making sure that the information provided to those models is obviously in line with best practice and standards.>> Are you seeing organizations say, "Okay. I want to build this stuff on-prem because I feel like it's more secure. I'm worried about LLM leakage or a token leakage if it's in the cloud and API creating more seams."? Is that a trend that you actually see?>> I see two arguments to that point, and I've heard a various amount of opinions on at the conference today and throughout the week. We hear people that say, "Hey. I want to use my own LLM and I'm going to build this in my infrastructure and I'm going to use these open source models and build the controls around it myself," all the way to vendors that say, "I want to trust experts that build these models themselves and host them and provide an API service." Different use cases for different conditions. There's no one right answer or wrong answer. Much like we've seen a massive amount of maturity and cloud-hosted security applications. So we now see Glove Cloud from all the major cloud vendors. It's likely that we'll see these capabilities move into very secure hosted or cloud-delivered solutions as well. But alongside that, just seeing standards like the NIST standard being drafted and obviously being released a couple of weeks ago, obviously being finalized in June through their feedback period, will be really interesting. And I think we'll start to see not necessarily perspectives, but actual opinions on why a customer may choose to run a model internally versus using a hosted model with a cloud provider.>> Don't you think that some of the reason that people want to do it on-prem right now anyways because they're just a little nervous? Maybe it's financial services. Maybe it's healthcare. Maybe it's whatever. I mean, and to me, it seems like walk before we can run maybe could be some of this approach here and that's understandable. Yeah.>> Yeah. Definitely. It's actually a really good perspective, because much like we saw with early AI, early machine learning implementations rather, people would host these models, they would run them on standardized compute. And then we saw GPU acceleration and capabilities that came alongside that, and then obviously hosting cloud services. To the point that you've made, I think there's a really interesting component of this. We're likely in the stage of infancy of how these models will need to scale, how these models will actually be used. And so a lot of companies, I feel are likely using models at a small scale now and planning for broad scale broader adoption as we go. And I can see that being advantageous in self-hosted models and obviously cloud-hosted models in different ways.>> Yeah. I mean, I think we're all wired differently and we're all willing to take X amount of risk, and we can't assume that everybody across the board is the same, right?>> 100%.>> So with search AI, you're really modernizing the SOC, right?>> Yeah.>> And what I really like... I was looking a little bit at your attack discovery functionality and the triage capabilities there. I mean, really what you're talking about is taking something that typically can take a bunch of time and shortening that significantly. So tell us a little bit more about attack discovery.>> Attack discovery at its core is... When we look at attack discovery, it's AI for security use cases in the enterprise. So it's applying models, feedback, statistics, analysis over events that happen inside of your SIM, correlating those into a sequence of events and presenting example, an authored example, of how an adversary may have attacked your environment. But as a counterpoint to that, it also explains to the analyst how to potentially understand what happened and the sequence of those events. Attack discovery is an incredible capability that I actually see being fundamental as we start to move into a very fast-paced mode of operations in the SOC. Being a SOC analyst in the past, and you wake up in the morning and you see 100s of alerts, getting that down to a sequence of events that you can actually know what to really look at first is just going to shorten the time to delivery, but really improve the value of how that engineer can respond to those kind of threats. At the same time though, I think it's about making sure that these kind of attack discovery components can be integrated well into workflows. So not only being able to action that at the incident or at the alert level, but being able to work with it in your case management systems and being able to pass that to other engineers to build a case, do an investigation and complete it is a huge part of it.>> Yeah. Much more organized.>> Yeah.>> Can you talk to SIM modernization? It's a topic we've heard a lot at this event. Shelly's sick of probably hearing me say this, but practitioners have told us, CISOs have said, "I'd love to get rid of my SIM, but I can't because it's in compliance.">> Or somebody told us earlier today that they had seven SIMs that were .>> Yeah. Yeah. About that.>> Seven SIMs, and said there was a reason for doing that, but it's like, "Oh, my gosh.">> Right. So->> I think building a broad set of defenses, centralizing security information is always going to be the best way of understanding the entire attack landscape for an organization. So I understand different environments grow over time. They grow through acquisition or scale or other things that bring us technology in interesting ways. SIM's always going to be core to the security operations experience, but it's about making sure that the SIM component that you've built is aware of where the future is going. We're moving to a world where models, artificial intelligence is going to assist us in discovering threats. It's going to be a platform that we need to understand the risks of itself, monitor the LLMs themselves in an environment, but also that last component, being able to make sure that the way we respond to threats and the way we respond to adversarial actors in an environment can be done rapidly and very effectively. And that's part of a broader strategy that every SOCA's got to look at. I think when you think about what is next, it's about building amazing capabilities that allow you to look across your data environment, provide results that matter, but do it with context. And I think that's really truly the value of future SIM.>> We see that->> Okay. Go ahead, please.>> No. Go right ahead. I didn't->> I just had one last question, but if you have another one, go for it.>> No, no, no. Go right ahead.>> Okay. 2023 was all about gen AI, gen AI for bad, gen AI for good. 2024, we just talked about security for AI. RSA 2025, what do you think we're going to be talking about?>> Ooh. I was talking to a number of folks about what they expected this year, and it was everyone from operators to investors in the space and practitioners that are building these platforms. And the common theme that I'm hearing is automation, bringing orchestration and automation to the response actions that LLMs are providing. Taking the next step by saying, "I trust the way the model's going to operate. I trust the engineer that can click that button to action their recommendations from my model." But more so than that, just really expanding upon the ways that we help defend models by understanding the way that adversaries are going to attack them. If we see last year as being the infancy stages of so many LLMs and so many environments, we see the next phase of this being those environments scaling, customers using them more, building more. So it's just a really incredible thing. And I think we're going to see more attacks. I think we're going to see more defenses, but likely see some very powerful capabilities come out of it too.>> You think we'll see a lot more LLMs?>> I think we'll see a lot more LLMs. I think they're around for a while. The first year is the hype cycle. The second year is, "Is it going to stay?" Third year's when it starts to .>> So the number of LLMs is growing. We saw Databricks announce. Snowflake has to announce an LLM. Okay. That's cool. Do you think at some point, it's going to peak and then consolidate? I mean, ultimately it will, but... I don't know. I'm going to ask you how long you think. I mean, it feels like it's got some legs.>> It's got some legs.>> It feels like the CapEx is there, the funding is there. Could be another couple of years before we see the peak of LLM introductions.>> I think we'll see excitement around capabilities. I think we'll see breakthroughs. We're at a phase of LLM development akin to the early phases of cloud. Amazing big companies building great technology, open source companies building additive capabilities, and then obviously the consolidation of a lot of those capabilities. It's going to be a really interesting time for LLMs. And crystal ball says that I think we've got one or two more peaks before we get to that.>> It's amazing the pace. I mean, Llama 3 comes out. LAMA 2, retire it. Just replace. Copy, replace, boom, done. It's over. And people just don't even use Llama 2 anymore. Why would you?>> The example that->> Why would you use the dumber model? We want the smart model.>> The example that I've used in the past has been thinking of LLMs not as an AI model that you can talk to as a SaaS product, but thinking of it as an operating system with inputs and outputs, with interpretations of code, with translations, with capabilities. If we think about it like that, maybe this is the start of where LLMs start to look. We see new operating systems every few years. Maybe it's new LLMs every few years.>> Jake King, thanks so much for coming on theCUBE.>> Thank you.>> Good luck to your Canucks. Go Bruins. Maybe we'll see you in the playoffs. That would be an awesome rematch.>> I think it'll be pretty good.>> Canucks-Bruins, 2024. We'd love to see it. All right. Thank you again. All right. For Shelley Kramer, this is Dave Vellante. You're watching theCUBE's coverage RSAC 2024. We'll be right back to wrap up day four right after this break.