International Business Machines Corporation (IBM) Earnings Call Transcript & Summary

Hello, everybody. Welcome to the IBM Cybersecurity Services webinar today. We're going to be talking about using AI and automation in security to help mitigate the impact of data breaches as well as talking about -- well, let me get to the agenda slide, and I'll cover what we're going to cover today. But first, let me introduce myself. I'm John Velisaris. I'm in product management within the cybersecurity services threat management portfolio. And Chris is with me today. Chris, I'll let you give a shout out and introduce yourself.

Hey, Chris Thompson. I lead the X-Force Red team and part of that is to see if [Audio Gap] models and all that stuff. So excited to speak with you all today.

Very cool. So let me break down what we're going to cover. They always say, tell them what you're going to tell them before you tell them, right? So we're going to talk about AI, the intersection of AI and cybersecurity. There's 2 sides to every coin, right? So there's good things that can come of it. And of course, it's an opportunity for the bad guys as well, too. We're going to talk specifically about what we at IBM are doing to leverage AI in the security discipline as well as some other automation that we're coupling with AI. So we'll show you and talk about some of those assets that we're building, not only through IBM security research, but also with our clients that we're co-creating together as we explore what generative AI can do for security practitioners. Then Chris, with all his deep knowledge and expertise, is going to cover the security concerns around AI and what you should be doing to make sure that AI that's in your business covers the full scope of security concerns there from the model, the data, the infrastructure, end-to-end. And so Chris will cover that with much more depth. And then, obviously, there's -- as part of the platform here, there's a Q&A capability. [Operator Instructions] We will try and catch those as we go along. At the end, we'll circle back. If there were some top questions or common questions, maybe Chris and I will try and verbally expand on those [Audio Gap] IBM Institute for Business Value. And so yes, companies are using them for business process automation. Some are using virtual assistants, generative AI, conversational virtual assistants for things like customer service. There's fraud detection. But 29% of those that we polled and responded said that they're using AI at that intersection of security. And more specifically, we got a lot of responses back talking about threat detection, which you guys know, if you're a security practitioner, we've been using things like machine learning to do threat detection for years now. So anyway, the AI is being used across, and that's another reason why Chris needs to talk about how to secure that AI because it's more than just at the intersection of security. So business leaders are anticipating financial returns. And so I think from a business perspective, we've seen a lot of different approaches in our client base to AI. Some are saying, "Look, I don't want to build a data science team. I don't want to own an AI pipeline. I'm going to consume AI as a SaaS." [Audio Gap] Look, we need to take those foundational AI capabilities and build discrete capabilities ourselves, deliver those. And obviously, and Chris is going to cover some of this, as you move across those architectures, as the business says, yes, we expect a very large ROI coming from our AI capability that we're investing in, the risk increases as well, too, right, as with many things. So when you own everything end to end as opposed to consuming it SaaS, your risk profile changes. But those returns can stack up, and that's why the business is progressing on expanding AI capabilities throughout the enterprise. And we're seeing that. We're seeing with our clients that multiple functions -- that first slide that I covered, multiple functions are co-sharing AI capabilities, generative AI capabilities to build integrated business processes inside companies and serve their customers. So you know, and this is -- since AI -- a lot of AI is about data, we figured we'd grab the cost of the data breach report. You guys know, hopefully, that every year, IBM produces the cost of the data breach report, and it's out. If you missed it, it's out. You can go to ibm.com and download the cost of the data breach report from this year. But in lieu of the entire report, presenting the entire report to you today, let me cover some of the highlights [Audio Gap]

John, we're having quite a few audio issues on your side. You might want to go off video just to save bandwidth when you bring up the slides, just because it's pausing every couple of minutes here.

Oh, is it, Chris? Okay. Great. Let me see if I can -- how can I turn off my video? Gosh. I'm sorry, guys.

It's bottom right if you hover over the screen. While John gets his audio sorted out, we'll just...

Chris, do you want to hop to Section 3 and do your part, and then we'll double back to me while I work on the audio and video issue?

Yes. Sounds good. You might need to reboot or whatnot, so let me just share here. Thanks for the patience, folks. All right. There you go. Let me get the slide show going here and swap those. All right. So John is going to work on his audio. I'm going to focus on the later part of the presentation around offensive testing of AI and where automation comes in or manual testing comes in. First, some background. The X-Force Red team has a lot of experience around offensive security. We spoke at Black Hat 6 times in the last year alone. And we're constantly researching emerging technology and the impact to the attack surface of the organization and whatnot. That's no different when we talk about AI. And we've been leveraging AI internally as well as developing extensive tooling and methodology for testing of AI over the years. And typically, what we see in customer environments, as customers start to leverage AI and they start to slap AI on every traditional and new application, this is typically what it looks like. So you have, on the far left, an MLSecOps pipeline. And that could be something as basic as just an existing model that hasn't been tuned that you're just leveraging a little retrievable augmented generation to call internal documents like an internal knowledge base, for example, or it could be something a little more complex, where you've tuned an existing model to focus it on your enterprise knowledge and the area that the app is focused on. So if it's a banking application, limiting its responses and its focus to calling your back-end APIs to make certain transactions happen, or could be something as complex as a model training and tuning environment where you're building your own small 1B, 3B models and leveraging your infrastructure for training. But typically, these MLSecOps environments, they've been readily connected into enterprise data lakes and more sensitive data sets, so financial data, customer data, internal intellectual property. They can reference more complex or sensitive procedures in terms of if it's a banking application, how the procedures for setting up a new account or typically lots of different enterprise data sets that get called. And it doesn't necessarily have to be a customer-facing application. By any means, it could be an internal application, which is intended to automate some HR functionality or a help desk functionality. And the second piece of the pie is we have the model itself. So the model, whether it's a Llama model or a custom model or an OpenAI model, how do we ensure that the model itself is -- doesn't have vulnerabilities within it and how do we test it for safety and security. One key thing I missed on the MLSecOps pipeline is typically, data scientists are downloading a couple hundred models throughout the course of the year to evaluate their effectiveness and their efficiency and their fit for the solution. So normally, they'd be downloading these models from sources such as Hugging Face, and there's always the potential that somebody backdoors a model, and a malicious model could be detonated in this environment. So I want to make sure that we're scanning those models for malware automatically, but we're not fully reliant on model scanning to be that silver bullet because just like any antivirus or EDR, there's going to be a lot of false negatives and misses. And we want to make sure that, that environment is prepared and ready for the event that the malware detonates within it. So how do we ensure that the incident responders know where the logs are? How do we ensure that we've locked down that environment properly? And I'll talk about -- a lot more about that in a minute. Beyond model safety and security testing for prompt injection and the ability to produce content based on copyrighted works or worrying specifically about bias, which is extremely important when it comes to any application, especially those that make decisions based potentially on somebody's marital status, based on their ethnicity, based on any number of sensitive data sets that should not play into a factor if somebody gets approved for a loan, for example. So very important that, that safety and that model ethics testing is performed. Third piece is these platforms that these models are being run on top of with generative applications built on top of them. So think of your big ML, your Azure ML, your SageMakers, your watsonx. How do we ensure that the platform has been configured securely by your team or by a third party? And how do we make sure that the connections between that AI-as-a-service platform and your internal data lakes and any internal APIs that are being called has been provisioned securely, the identity and access management for that cloud environment is properly configured? All those different expanded attack surfaces that come up rolling out a new cloud solution essentially. And then the -- how do we ensure that the gen AI apps or ML apps that are built on top of these platforms leveraging those models are secured? And how do we know that these models or these applications are securely calling APIs? How do we ensure that they're not subject to prompt injection, which could result in code execution in your back-end platforms? All that sort of thing. So these are the areas that we're most concerned about with AI. Typically, when you hear about AI red teaming, it's focused purely on number two here, the safety and security testing of the model. But in reality, there's a much wider ecosystem that we need to consider, especially those models being run in a production application. So securing the MLSecOps pipeline. How do we ensure that, that environment is secure? So in addition to the model training and tuning tools, how do we ensure the deployment orchestrators are secure? How do we see that logging is in place? All that sort of thing. So we can take into consideration a number of frameworks that have been started like the OAuth and MITRE ATLAS and whatnot. OAuth has got 2 projects specific to LLMs and ML, for example. And they've started to categorize some of these attacks. But obviously, as we know with MITRE, MITRE attack and any great industry effort, there's going to be gaps in how the attack actually happens practically at the procedural level. There's going to be a lot of solutions that aren't just limited to, say, supply chain attacks. So when we're testing an MLSecOps pipeline as a red team, we're focused on it much like any DevOps pipeline because those pipelines have the ability to spin up new boxes. They have a lot of secrets built into them. They can be potentially abused for lateral movement or privilege escalation. And different with MLSecOps versus just DevOps is a lot of these environments are, A, built on top of very new code that's built by smaller data scientists that wasn't intended to be used in an enterprise environment. And B, a lot of these MLSecOps pipelines are adjacent or readily connected into sensitive enterprise data lakes, which you just don't see on the DevOps side. So it makes for a very attractive target as a threat actor, as a red teamer for targeting ways into this MLSecOps pipeline. So if I manage to phish my way into your org, the first place I'm probably going to go now is after your data scientists and after your MLSecOps pipeline because I know that red -- blue teams don't have a lot of experience monitoring these environments. I know that the tools within them don't have good security logging enabled or at all. I know that a lot of these tools allow for Python de-serialization and code execution. And I know that the blue teams don't have experience performing incident response or threat hunting in these environments yet. So definitely a juicy target. On the flip side, within this environment, we hinted earlier at the potential for malicious models being downloaded. Most of the models, I think, if not all, to date in Hugging Face, that are malicious are probably set up by one or 2 big researchers. And they're just demonstrating the potential impact. At least a few months ago, that was the case. Where really smart folks, I won't name them because I don't know if they want it [ mentioned ] publicly, they backdoor-ed quite a few models for different companies to demonstrate the impact of supply chain attacks but in a safe way. So they're not actually fully establishing C2 and being leveraged to attack the companies. They're just demonstrating that a lot of these companies are just downloading and executing models and not checking them for malware or not verifying the author of the model, for example. So in the future, we obviously see a lot of these attacks expanding to where actual malicious threat actors are starting to backdoor some of these pickle models. So we want to make sure that the environment is set up in a way that you have an opportunity to spot those malicious models. So your frontline controls around leveraging something like HiddenLayer or another solution to scan these models statically and as they're being run dynamically. And as that serialization happens, can we spot a C2 being established, for example? But because antivirus isn't a silver bullet, as I mentioned, you want to make sure that you have compensating controls as well. So we want to evaluate the logging that's in place. We want to evaluate can C2 be established. A lot of these environments allow outbound Internet access because they have to call a lot of packages from different pipeline packages or they're being used to connect directly to Hugging Face. So just blocking them from the Internet isn't always feasible. So we want to evaluate what are different compensating controls that we can have in place from a logging and hardening perspective to prevent an attack like this happening in the future. So we want to assess the ability to detect malicious model code execution in notebooks. We want to assess the impact of a data scientist's or a developer's workstation being compromised. We want to evaluate the potential to access that crown jewel data within enterprise data lakes that are connected to these environments. And we want to proactively harden the virtualization infrastructure and any shared services or identity infrastructure that's being leveraged in this environment. One of my...

Hey, Chris. Before you roll on there, do you want to advance the slides that you're sharing? Or do you want to toggle back to the platform slides?

Sorry, could you clarify?

Your screen has been static for what you're sharing. It's not advancing on the platform.