 Hello everyone. My name is Jung Lu. I lead the product marketing and strategy team at Wiz, where we help over 40% of the Fortune 100 secure their cloud environments. And I'm really excited to be speaking today about securing multi-cluster Cassandra and Geni AI deployments. So a little bit about the problem that we consistently hear from our customers from a security standpoint. We'll cover a little bit about the anatomy of what a cloud attack looks like these days, how organizations can detect those types of attacks and prioritize those risks ahead of time. So they're proactively removing those attack paths into the cloud environment. And then we'll move into my favorite time, which is actually demo time. And then we'll close with a few best practices for how organizations can think about building security earlier into the development pipeline, as well as cloud operations. All right. So a little bit about the challenge. So what we consistently hear from our customers is that cloud has represented a fundamental transformation for their security teams in three key ways. The first is that the environment is very different, right? It's incredibly decentralized these days. And organizations very quickly find themselves in a multi-cloud, multi-architecture environment with thousands of technologies running in it. And there's a very simple question, what do I have running in my cloud environment? And unfortunately, it's a very complex question to answer simply. The second key thing is the risks themselves. What we hear routinely is I have all of these different tools and technologies that are in place, but they show me siloed views of my cloud and siloed views of risk. I'm getting thousands of alerts coming at me from all of these different tools. How do I prioritize what's actually real and eliminate the noise from these alerts that are meaningless? And lastly, what is actually I think the most important change is that the ownership model is very different, right? It's no longer security teams or infrastructure teams themselves that are making technology choices. It is the business units. It's the development teams themselves. And so how do we actually ingrain a security culture into those teams? And how do we bring them in so that when we find an issue in our cloud environment, they are willing to help us fix it quickly? Now, this is one example coming out of AWS re-invent a couple of weeks ago that really articulates the problem statement. AWS is releasing all of these new incredible APIs all of the time, right? It's an explosion of features that allow us to build faster and build more innovative solutions for our customers. But all of that introduces more attack surface as well. And nowhere do we see this more right now than when it comes to cloud AI services. Based on the Wiz research team's analyses, over 70% of cloud environments are already using some flavor of AI in their cloud already. Oftentimes, it's a lot of R&D teams, a lot of innovation teams that are testing out new solutions, right? New use cases that they can roll out to customers. But what we also consistently hear is that security is oftentimes the main AI adoption blocker from bringing those new solutions to market, to actual productization. And again, it's the same themes. The technology itself is rapidly innovating. AWS just announced a whole slew of new innovations for bedrock their service for this. There's a lot of new risks, right? This was, I think, the fastest that an OWAS top 10 has been created for this area. And a lot of this is unknown risks as well. There's a lot we have yet to learn. And lastly, there's a security knowledge gap because now we're not just talking about our usual teams that are building in the cloud. We may have new teams, data scientists, AI engineers, that they themselves are new to this space as well. And we need to help make security very, very simple for them. So let's talk a little bit about the anatomy of a cloud attack. Exposure is still the key risk in cloud, right? In cloud, everything is born with an IP address. And so exposure is incredibly simple. And there's a lot of different ways that it can happen. A publicly exposed bucket, for example. What we found via our research is that if you expose an S3 bucket, and you reference it in a GitHub repo, from the time that that gets published and it's exposed, it's really a matter of seven hours until that's taken advantage of. A little longer if you don't expose it via GitHub with 13 hours, but still incredibly short. And these are not just, you know, small names of organizations that are getting hit with this. It's really large organizations, the cloud providers themselves. You can see that with Amazon, you can see that with Microsoft here. And on the topic of AI, there was a fairly large accidental exposure recently by the Microsoft AI team, really showcasing the fact that all of this is very new. And yet a simple misconfiguration can lead to the exposure of 38 terabytes of data. Now, when we look at attacks, there's the simple ones, right? Simple exposure. But why is it so difficult for us to find these ahead of time? The reality is that oftentimes, a lot of the attacks are a combination of different risk factors. And what we see is first, when an attacker gains a foothold into the cloud environment, they then look for ways to break out of it, right? How do I expand what I have access to? How do I find where your crown jewels are, so that I can exploit them or steal them? And so there's a lot of different initial entry points into the cloud environment. There's, of course, remote code execution that we all know about. Log4Shell is one of the most painful recent examples of that. But we also see other factors as well, right? Misconfiguration of resources, which was the AI example that we just looked at. There's, of course, end user compromise, oftentimes one of the weakest links in the chain. And we saw this with lapsis, a group of really high school students targeting the likes of Okta and Microsoft and succeeding. And then, of course, there's also what we may unintentionally see in our attack surface, which is things that are introduced via our software supply chain. SolarWinds is a great example here. And also through the identity side, when we make identities available to third parties, as we saw with Nobellium. But once attackers get that initial foothold, what else can they exploit? And there's other different risk factors that they're looking at, right? So there may be secrets that are leaked that allow them to move laterally in the environment. It could be internal network connectivity or identity routes. We see a lot of excessive permissions that are out there, and unfortunately, weak authentication as well. So the combination of these two factors really enables attackers to gain that initial foothold and then grow their presence in the environment until they find what truly matters to an organization. Now, I wanted to walk through an example of what this looks like in real life. This is an attack that our research team looked at, which we call QuickCow. And what we have here is a PatientZero. This is an EC2 instance, so it's our virtual machine, and it's vulnerable. So it's got a vulnerability on it, and it's publicly exposed to the internet. And attackers are scanning cloud environments now, looking for this type of initial entry point. Now, once the attacker is in, right, they've gained that foothold, what do they do? So they immediately run a reverse shell. They deploy DirtyCal, which is a known piece of malware. And from there, they see that there are four keys on this virtual machine, and they start testing them. What does it get me access into? And so the first three, right, doesn't go anywhere. But then the last key they find actually allows them significant access into the environment. It actually gives them the permissions to create an IAM user. Now, this is like hitting jackpot for the attacker, because this is what allows them to actually move outside of our PatientZero, to escape, if you will. And this is what we mean by that internal exposure, that lateral movement. Because from there, they can move very freely within the cloud environment, based on the permissions of that particular user. And in this case, again, they're making those enumeration calls out to the cloud provider to see, hey, what does this IAM user get me access to? And in this case, they find actually an RDS, right, to a data store that has sensitive customer information, and they exfiltrate it. Now, this attack really takes only just a matter of minutes. The attacker gains that initial foothold at about 8 p.m. at night. They start exfiltrating in the wee hours of the morning. And by, I believe it was 6 a.m. in the morning, the attacker has already posted on Twitter evidence of the database that they have now exfiltrated. So this is really rapid, right? And the key question is, why is this so difficult for security teams to find? And it's because it is that combination of risk factors that traditionally takes many different security tools to uncover. So what we want to do here is really think about how do we address this holistically in our environments? The first is to start thinking about attack paths, right? That full attack vector from that initial point of entry into the critical crown jewels of an organization and the lateral movement paths that enable that. And security goals in themselves are to first be proactive. Let's identify these attack paths before they can be exploited and close them down. Let's remove them as paths that an attacker can exploit. Now, because the cloud is filled with these types of risks and filled with these types of attack paths, it's nearly impossible to remove all of them from an environment, especially as you think about all of the different layers of the cloud, the cloud, the orchestration layer, and the workload layer itself. And therefore, the other piece is we need to ensure we have the right level of monitoring in place so that we can detect when this attack is happening and actually limit the blast radius before the attacker gets to the crown jewels. Now, it's not just a technology problem. It never is. It's actually more importantly a people and processes problem. For too long, securing the cloud environment has really been seen as the purview of the security team itself. And that doesn't work for the speed and scale of the cloud, especially with that change in ownership model. And so what we believe is that not only do you have to have a transformation in how you think about risk, but you also have to think about how this new operating model that spans teams, one where the security team is really looking for visibility into what's in my environment. But the ownership and responsibility for risk itself ultimately lands on the development teams, right? So a dev team A that's responsible for one application, another dev team that's maybe responsible for a different environment, and then an AI team that's innovating rapidly which NAI. So how do you want to do this, right? There's a few key steps, four key steps that we want to make sure we put in place. The first is we want to identify risks with cloud context. That means really understanding, layered on top of our cloud environment, where we have misconfigurations, where do we have vulnerabilities, right? Combination of which can create that initial access point into the cloud. But beyond that, where do we have things like excessive permissions, exposed secrets, things that enable that lateral movement to the things that really matter in the environment? So in this example here, we've got our Cassandra cluster here in the center, and we can see it's got a public routing to the internet via this network interface, this virtual network, and this internet gateway. And in addition to that, it has a critical network vulnerability with a known exploit. So those two things in combination mean that this is a high probability of being compromised, right? That's that initial access point. But beyond that, we can see this cluster can be accessed by this role, which has excessive access, which also has access to a data store that's used for AI training that we know has actually sensitive data on it with personally identifiable information. So this second piece is that lateral movement path that gets you to those crown jewels. Now once you have all of that information, you can really understand that this is a full attack path. And this is something that your teams can prioritize, right? There's no question that this is something you want to result before an attacker takes advantage of it. Now the next key step, and again, one of the very complex questions around cloud security is who is responsible for this part of my environment? And you have to understand in many organizations, this can be extraordinarily difficult, especially if you are a large global organization, right? You have different teams that have different environmental ownership, that have different application ownership, that have different data ownership. So you need to understand, how do I get this issue, this security risk that I found to the team that is responsible for remediating it as quickly as I can? And from there, we need to automate the workflows. So working directly with the technologies that that team is already used to using. So if they might want a JIRA ticket open, they might want a Slack message, right? Whatever it is that they use, you want to push it into that workflow so that that enables them to be armed with the information to take that immediate fast action. All right, so with that, we're going to move into actually a demo of the solution. So what I have here is that full attack path that looks at a Cassandra cluster here in the center. And we can see that it is actually publicly exposed to the internet if we zoom in, got this network interface, this load balancer, and we can actually validate that in fact there are these endpoints that are exposed to confirm it is publicly exposed. And we can see on this cluster, there is a couple of CVEs that are associated with it, right? So CVE 2023, this has to do with vulnerabilities and misconfigurations. And then also this 2021 one, which looks at privilege escalation from Cassandra itself. So again, this combination of factors means that this is a potential entry point into the cloud into this Cassandra cluster. But it's not just that. In this case, we can also see we have a identity or this role that has access to Cassandra. And in many organizations with typical setup that we see, which is unfortunately a misconfiguration, is to have that same role also have access to the bucket, which is actually the backup for Cassandra or for the production environment. Now, what I also want to show you here is the full lateral movement path. So building this out further, if we look at this bucket itself, we can see that we are finding sensitive data on it in the form of credit card information. And we can take a look and see exactly where it is in that bucket that we're finding it. But what's important is also that this bucket is actually can also be accessed by these three admin accounts over here. So if someone were to compromise this Cassandra cluster that we started with, they would be able to move laterally in the environment through to this bucket, and then into these admin roles for our cloud environment. So there's lots of different crown jewels that are now at risk. And what's also interesting is there's a second attack path here, which is we have this bucket. It's actually also misconfigured. It's available to the internet because it was misconfigured with the all users group, which in this case actually means all users that are logged into AWS, not just the users that are part of your organization that are logged into AWS. And so if someone actually breached this bucket, they would find a key to AWS, which allow them to assume this Octa SSO user in your environment, which can assume this IAM role, which can then get them also to these admin accounts. And as we saw earlier, these admin accounts can get to that Cassandra backup data. So now you have two routes into Cassandra, right? The one where Cassandra was your initial cloud entry point, and another one where something completely unrelated to what you're working on is actually the initial entry point. So it's really important to understand all these dynamics because these are different teams that own these different parts of the infrastructure that may not even be aware that these relationships and interconnections are in place. And that's what we mean by really understanding those full attack paths so you can prioritize removing them from the environment. All right. So I'm going to move into AI because AI is top of mind for everyone. What we believe, again, is very similar to cloud. It all starts with visibility, knowing what you have in your environment, right? So here you can see all of the different services. We've got AWS bedrocks, GCP vertex, right? Those are the latest AI innovations from the cloud providers themselves that are hosted. And then of course, you may be using the underlying components as well. We've got hugging phase, llama index, phenomenal naming by those folks. But again, what we really want to understand is actually where do I have the greatest risk in my environment? And this is one example for AI and specifically for AWS bedrock where we're looking at a S3 bucket that holds AI training data. And you can see that an AWS bedrock model is running on top of or is reading the data from this bucket in order to run your model. Now, what we're also seeing is that this bucket is publicly exposed to the internet. And you can see the application endpoints and what is actually being shown when an attacker comes in. And again, what we see is not only can an attacker gain access to this because it's publicly exposed to the internet, but because of the way the identities are configured, which is actually a fairly complex exercise in AWS with these IAM bindings, the ability, if an attacker got into this first bucket, they would be able to move laterally in the environment to get to another bucket. And again, canonical issue where you have a bucket that has a secret key that enables access into an IAM user that can assume a role that can then get to some really critical keys to the kingdom admin accounts in the environment. So this is what we mean by again, really showcasing the full attack path into your gen AI deployment, something that you may not be aware of. And what's really important when it comes to gen AI is in many ways, we can learn from what we learn from cloud where security was really a backseat passenger into the innovation that was happening. With gen AI, we need the seat belts now and we can co develop it in collaboration with each other by adopting that new operating model. All right. So with that, I wanted to close on a few best practices that we've learned from our customers. The first is that you really need to think about how do we make cloud security self serve to all the teams, right? To our data teams, to our teams running Cassandra, to our teams building AI applications. And the first step is it all starts with visibility. It has to be the same visibility across all teams and across the entire environment. So whether you're deploying on AWS or Azure, whether you're using bedrock or open AI, we need to normalize it and make sure that everyone has the same visibility. As part of that visibility, we need to have full understanding of what applications are there. What are the pipelines? Where is the data? What data of that is sensitive? And most importantly, who owns each of those, right? Who owns that part of the infrastructure, that part of the pipeline and that part of the data. From there, once we understand the risks to the environment, we have to use context, right? Context about the teams that own it, about the cloud environment in order to prioritize ruthlessly. And from there, it's a group effort to remove that risk proactively from the production environment to get to zero criticals. It's actually possible when you focus on what truly matters and not the thousands of meaningless alerts that most organizations get. And in that process, what we find is that we start to see the trust form between the security team and the dev teams. And this empowers developers to actually be proactive, right? When they see an issue, when they see a risk in the context of the cloud, they know that it matters. They feel the ownership and they want to remediate it and take the right action. And lastly, the key is all about knowing what controls matter for your production environment. As you clean that up, you establish that. And through the trust that you have with all of the teams, you can get everyone on the same page about now extending those same policies, those same controls that work in production into the pipeline. So you're not just playing whack-a-mole in production, but rather removing entire classes of issues in the pipeline when it's much cheaper and easier for it to be resolved. Now, one of my favorite stories is from Price Line. They are a heavy Cassandra user, right? They have a lot of data that they need to process in real time. And I love the way that their cloud security architect frames it, right? It's guardrails. I like to think about guardrails in the same way as F1 races, right? Developers are our F1 drivers. We don't want to slow them down. We want to put seatbelts on them. We want to put the railings on in case something catastrophic happens. And this is really how we think about security done right for multi-cluster Cassandra, but also Gen AI, right? How do we give these teams autonomy to deploy securely and move faster in what it is that they're doing? Because ultimately, that has the largest impact for the business. All right. Thank you very much for the time. I really appreciate it and hope this is useful. Thanks.