 All right. Thank you very much for coming to taking your time to come and see us. Like he said, my name is Rod Soto and he's Jose Hernandez. And we're going to talk about today about some of the research that we've been doing about trying to achieve a unified cloud security posture. So let's get started. Who am I? I am a principal research engineer Splunk. I worked with this gentleman at Prolexic Technologies, which is now Akamai. I also worked at Caspita at one point. I co-founded Hack Miami and the Pacific Hackers Meetups and Conferences. You can find it at meetup.com. And I created a command and control in all quarter CTFs. I like to do a lot of CTFs. He is Jose Hernandez. He's my peer at the Splunk research team. Worked at Prolexic as well. And we do have quite a bit of experience fighting DDoS. And one of the, I guess, the adversaries we had to fight was Anonymous and Lorsic. So let's get started pretty quick. So one of the things that we try to address with this presentation is that we obviously, in the industry, we can understand and we perceive that many enterprises, many corporations are basically struggling with achieving a unified cloud security posture. There's sort of a mix, an attempt to sort of, there's a difference between perimeter security and the way we're going to expose this. There's perimeter security. There's cloud security. So you just can, even though you can try, for example, but for example, active directory logs with maybe Stackdriver, that may not make a lot of sense. But we're going to give you the tools that we actually use. The tool that we actually, that you're going to see today is the cloud security suite. We did some modifications to make it sim friendly. And you're going to see basically some examples of EOK and Splunkle course. So the reason why we're looking at this is because the cloud has become prevalent. At times, there's a blurry line, a blurry line when it comes to liability, right? Because at the end of the day, the cloud provider has his limits. And many times, we're not aware of it. And I will touch on it. The cloud adoption is expanding. Cloud security is not an exact translation on inside the perimeter. You're going to see that in a minute. Every provider has a set of technologies, feature security items. And even though there are several cloud security initiatives, it's still an ongoing effort. So what you're going to see today is an ongoing effort. Some of these categories that you're going to see today may change in the future or may include another. But it's definitely what we agreed that was the most comprehensive one as of now. And of course, we chose the CS security suite because it basically helps you assess the three major vendors. Of course, there's OpenStack. And we're not going to show anything about OpenStack, but definitely we believe you could probably fit it in the categories that you're going to see today. So this is just an example of how prevalent the cloud is becoming. Like I said, they manageinary, which is not really that imaginary when it comes for you and your responsibilities. Obviously, the responsibilities change depending on the cloud service provided module, if it's infrastructure as a service, there's a platform as a service, or it's a software as a service. So as you can see, basically, you go up to physical security, and then once you get on application security, and most, for example, of the type of services, you are responsible for it, right? The imaginary line is not that imaginary. What you have, what you see here is basically AWS. They do actually come up from and tell you this is why you are responsible for. Sometimes what we, the challenge that we face here is that when you are presented with this number of services, challenges, putting together all these locks, I'll give you an example, GCP has over 200 or more that I counted the roles for security. So when you're dealing with stuff that basically is incredibly challenging for a single operator to put together, we had to use either a criteria that groups many of this single items, and some sort of automation that will provide us a view when we're trying to assess security. And that's what we're going to, that's what you're going to see today. So here's the Azure, for example, so I try to show all the three providers. This is something that you, if you are using any of these providers, I suggest you that you really review and sort of establish an inventory and identification of where your line is, right? What is their responsibility? What's your responsibility? So obviously, this is part of reinforcing our point of view. We have this major cloud attacks from the Sony, the Fappening, the Cloud Hopper, the Ashley Madison, just being said that there were suicides about it, Equifax, HBO, IB, largely stolen, Mario, Kubernetes. And of course, we just had the recent one, which is Capital One, which was an inside, a rogue inside. So here's an example of what can happen. And here's an example of some of the challenges that we are facing when we deal with cloud providers at times, even though they, for example, certain vendors seem to be very secure. Then we have a case like that rogue insider comes in and exposes all this information or steals this information. It's not known yet what, if that data was shared either in the dark web or if it was sold. I use, when I started researching this, I looked at the cloud security alliance, which is called the Three Shares 12, which is basically includes data breaches, insufficient identity, insecure interfaces, system vulnerabilities, account hijacking, malicious insiders, which is the sample we're just talking about, advanced persistent threat, which is nation-state or highly organized crime, data loss, lack of diligence. I've used on the various or use of cloud services, denial of service, and shared technology vulnerabilities. This has to do usually with multi-tenancy. We actually saw that when we were working at the company that basically seized 30% of the internet, a very famous airline who was, they lost an airplane. Don Lemon said there was a black hole that took that airplane. Well, that brought a lot of resentment. So guess what? Somebody wanted to hack that airline. And the administrator had the same passwords and many other panels. So we were affected at that point. This one attack vector of many people you don't realize that multi-tenancy and third body will affect you for sure. So here's some of the main targets of the cloud attacks. ATO, which is account takeover, key excretion, phishing, you can attack obviously the provider, AC AWS, UCP, you can attack the admins because once you get admin access in any of these consoles, it's pretty much having domain admin. You can use the cloud resources for things like crypto mining or DDoS for rent, data, everybody's life, private work information is in the cloud, I mean, it's getting there pretty much. And we're still not counting what I will call the AI leaks, which I'm sure they will come soon. We're already getting little trips of it, you know, like we have operators listening to Siri, Alexa, so we don't know yet. We don't know how this is stored. We know it's in the cloud, but I would caution that we need to be prepared for those type of leaks and they will probably be devastating. So be careful what you said at home if you have one of these devices. Third bodies, like I said before, co-tenants, multi-tenancy and attacks that affect the identity provider. So here's also an expansion of the attack surface, what I call the DevOps attack surface, the CI-CD pipeline, source code repository, BitBucket, GitHub, as VNS3 buckets, CI-CD platform, we know about Jenkins vulnerabilities, for example, CircleCI, Travis CI, container repositories, we've seen some of those recently, Docker, Begrin, the provider, depending what the Kubernetes flavor or OpenStack in infrastructure as code. So basically, vulnerabilities of use of exploitation of things such as Terraform, Ansible, Chef or CloudFormation. So if we were to reduce this, right, in general view, this is pretty much how you will look at the attack surface segments. You have the internet, right, or the internet. You have some sort of a web service, API, HTTP service. Behind that, there's a compute backend that's usually distributed. Behind that, there's usually what I call a cloud LAN or a cloud WAN. And then usually in that backend, you're going to have the big database engine. So you have SQL, SQL storage, block, object or file type of storage. So can we create a common criteria for cloud security? The answer is yes. And we're about to show that. These are the categories that we decided to settle for at this point. So basically, there's six categories, Network, which is the standard access, VLAN, V1, VPN, and routing, security, which obviously includes the CIA, confidentiality, integrity availability. Although in the cloud, there's heavy emphasis in the AIM portion, encryption and firewalls. Then you have compute. In compute, we had artifacts, such as virtual machines, containers, apps, microservices. And then we have databases, which can be SQL or not SQL. Storage, which basically buckets in file type of storage, as I just commented. And then management. So it could be Kubernetes flavor, logging setup and management access. So here's some of the examples of things that we put together. For AWS, for example, in compute, you can see that we include EC2, Lambda, Elastic Beanstalk, ECS. In Azure, we put there the machines, load balancers, app services, disks, Kubernetes, and GCP. We included instances, disks, snapshots, images, zones, Kubernetes. The reason why we put this is because we're about to show you the example, how it looks together with the checks. And then you can get very granular. So it will make sense in just a few seconds. So here's another example of management, the things that we were able to encompass the three vendors, the storage, security. And again, this is an ongoing effort. Many of these vendors, they are adding stuff or they're changing it or they're eliminating it. So it's hard. In the sense of we can say that this is written in stone, this is variable, this is ongoing. But as of now, it gives us that unified posture when we're looking at the three major vendors. Then we have the network part. Sure, if you want to take a picture of it. And then the databases. And then finally, we found a open source tool called Cloud Security Suite, which is a one-stop tool for auditing the security posture of these three vendors. The vendor checks are different. Different because of the service or difference, infrastructure, the name of the services. Jose is going to talk a little bit about how difficult it can be to normalize this data. Because basically, I'll give you an example. For example, GCP, yeah, the output is JSON. But the way they output the JSON, the AIM is not nearly equal to the nomenclature that Azure or AWS may have. So that presents a challenge for a security operator. That presents a challenge when we're trying to normalize the data. We were able to do that. And we're going to show an example. We actually modify the code. We modify the code to make it SIM-friendly. With this, you are going to be able to output and then pipe it to either an EOK or Splunk. You're about to see the examples of how the categories look together and how you can deeply research and look at it from the operator's perspective. And then obviously, if you want to go and dig deeper into this, obviously, you have to do that in your analytics or preference. Obviously, we worked for Splunk. We did quite a bit of work in Splunk. But we also show you, actually show you even the configuration file on Elk. So you can do it too. So some of the things that I wanted to share about this, the original project was modified. Are you ready to jump? Okay. Let me get you, Jose, now. Yeah. Rod, thank you. Thank you for giving us that basis of why this is important for us. And again, just a quick resum rake up here. We're trying to distill down all these checks, the CS Suite, the tools doing into common categories. And with the end goal of being able to audit in one common language, all these cloud providers, right? And to dig deeper, a bit deeper, and I'm just going to go back one slide if you don't mind, CS Suite today uses under the hood a set of tools that are actually cloud auditing tools. And each of them are kind of a bit more specific for what the audit that they're trying to do. For example, G Scout, it's only a tool that audits GCP. Meanwhile, Scout 2 is an AWS tool, Prouler only audits AWS, and so on and so forth. But what we really liked about CS Suite as a project was it brought all these tools together and generated one common report. The thing with CS Suite for us, and again, I think I'm just recanting this for a second, was CS Suite is built to generate a report, not necessarily an audit log for a SIM or something similar like that. And so I'll go back to Rod's point, there's some modification that was made in order to support that function. But for the most part, CS Suite is really straightforward to get started with. You just need really read privileges or an API, a service API token and something like GCP or Azure in order to scan for that to go better with your cloud provider. And again, the one thing to watch out for is your visibility into the scans may vary based on the rights you have on those keys, especially if your cloud deployment is segmented, you got to account for that when you're setting up your keys. So this is what CS Suite looks like when you run it, of what a report basically generates a kind of shape of report. In this case, I believe this one is for Azure. So it's giving you the results sets for security center, what checks, what things failed for the storage accounts, logging, so on and so forth. And you get this, we also get this for things like Azure. So this is, for example, sorry, for GCP, this is the GCP benchmarks. Did you leave a network open mistakenly or maybe it wasn't mistaken, but it'll still report, you know, you have all traffic coming into this specific instance. Do you really want this publicly open or not? There's another example for AWS. Again, there are individually different reports, but they're looking at all the checks for that specific cloud provider. Now, before I jump into what the data looks like, I really want to walk everyone through some of the challenges into getting this set up on your own. And again, just to highlight potential like gotchas and hopefully you can get through them really fast and especially after this talk. So like one thing to watch out first is logging in any cloud provider costs money. Watch out for that. Like just make sure you get a budget calculator before you start turning everything on because your bill is going to rank up really fast. And it requires time for setup. And what I mean by time for setup, for example, in GCP is not just a matter of like, you know, I click a button and I'm logging everything. But you know, you need to walk through configuration in there. There, you know, you need to have a platform that can, in that cloud provider, you need to have the inner workings to index and stream the data into some sort of sim, right? So something to account for that's not native in cloud providers. So you need an architecture for streaming and storage and some analysis framework, right? In this case, we're using Splunk and Elk as examples, but you're also going to need some sort of analysis framework to analyze the logs coming out of those cloud providers. Good saving grace years, most providers are using JSON as output. The bad thing about that is to Rod's point earlier, they're not normalized. So we have to normalize a lot of that coming in. If you were tomorrow training on logging for a cloud provider, this is roughly what the architecture would look like. You have your service, you have your individual cloud providers, you have the services inside that provider, and most likely you're going to use a message bus. And this is best practice, right? And what I mean by message bus is in AWS world is SQS and GCP roles is PubSub and Azure, they have this whole own logging thing called Azure log integration. And optionally, you may or may not want to, so each of the services are generating their own logs into a message bus. And then you may or may not store that into a storage bucket for retention. And again, may or may not, it depends on a lot of things, costs or what you're going to do, whether you need it to store it or not. And then you're going to have some sort of agent pick that up from either the storage bucket or the actual message bus itself and send it to your actual indexing system, like your analysis engine. And CS Suite sits somewhere in the same place where the agent would sit to pull stuff off, but instead of pulling data out, it's scanning for what's incorrect in that cloud provider, what's not really up to part security-wise. Again, big values of integrating popular systems is you get knowledge objects out of it, right? So you get like fuels extracted out of it. You can do a proactive alerting when a check fails or a bunch of checks fails. You can do automation around, like for example, if something is failing, you can quarantine it immediately with something like a Phantom, for example, in the Splunk world, store-based applications. Let's dig now into the reports. Elk. Elk is really, to get the events to work with, to bring CS Suite events into Elk, it's pretty straightforward. You just File Beat Config, and there's nothing real unique here in this File Beat Config, besides the fact that I'm telling you there's JSON, so JSON keys on the root. And here's what the data looks like. Again, pretty much you get different things like category fields that natively, for example, CS Suite doesn't give you, and the categories are broken down again, like what Rod just explained, which is management, service, compute, storage, et cetera, et cetera. The name of the check. So in this case, in the picture, we're saying, sure, log metric filter and alarm access for management console. Sign in, right? So like, are you logging, do you have a filter for logging, for logging management logins? Oh, that's a tongue twister. And this is just an example. And clearly, because again, this is already logged in, right here, I'm showing you just a quick, really dirty graph of like other checks that failed, or in this case, they set us warning for all the cloud providers for us, and then they broke in, it looks like most of it was management, and some of it was the security, under the security category. I want to show you what Splunk looks like really quickly now. And again, this is the same data set. It's all JSON, or CSV outputs JSON, and we're just bringing it into one provider in the next way. Again, you'll see here in the Splunk side of the house, it's a bit more of a more, I guess, known as a more complex search, just because I added things like, you know, what does, you have like a service field, like who the service provider was, if you want to break it down. Here's a good like a view of like what the different checks for Azure would look like, like that you'll get back, right? So like manual extensions, like a VM does not have the, you know, the data that's encrypted, the retention policy is not set, so on and so forth. Here's a quick dashboard we threw together for Splunk, of like all the checks we were running across. We set up three different dev clouds, made them purposely vulnerable, right? And then so we've set a cron job to run CSV, put the logs and then index that to us, and we built this dashboard with that. And again, just trying to give you a flavor of what data you can get out of it. But things like, you know, hey, roughly there's about 100 and something individual checks for each cloud provider. And so you get, okay, what checks are passing, which ones are failing, clearly you want the red to be zero. At some point, if you have like a sock and you're working the sock and you're working this down, each of these are essentially should be a ticket to either make a change or to remediate, right? You know, breaking down my category, but which provider is failing the most, in this case, Azure is I think our worst perpetrator in this case. And under this, you get a very, very good detailed table of like, who, you know, which category, what provider, what the specific check was. And basically the value in this case was what's actually failing, like in this case, for example, the EC2 audit failed list of servers, which are not associated with IAM instance profile, blah, blah, blah, blah, blah, right? And it's giving you all the instances that for us, we're not associated with a standard profile that we spun up, right? I'm going to be completely transparent with you guys. The first time we ran this against our own development clouds, we found stuff that we didn't know we had left open. That was almost like a stamp of validation, like this stuff kind of works. The beauty, and again, I think I couldn't speak highly enough, the beauty of CSC is the fact that it encompasses so many checks that it, I'll give you, I'll give you another, again, another like story, like recently, I spun up Cloudsploit, if you never use it, it does something very similar to this. And I ran it against all of this same dev clouds, and I got the exact same result checks that Cloudsploit gives me almost by the name, right? It's very thorough. It's where I'm getting it, and it's free. And you can run it operationally 24-7. Like I mentioned earlier, it's very like in Splunk or Elk, right? Elk, you can use Watcher, it's Splunk, you can use just to save as an alert to invoke some sort of automation to either remediate it immediately or send an alert or create a ticket. So again, it's easy to take this and then put it into your SOC and operationalize it ideally. That's all. Thank you.