Alright, great. Thanks everyone again. My name is Shailesh Rao. If you need an easy pneumonic stylish brow, you see that very stylish takes a lot of effort but helps people remember my name. I want to go to market for cortex and, thank you all for being here really appreciate you all spending the afternoon with us. I know there's been a lot of information what I wanted to do and with my colleague Kyra. Who is a product management for cortex. We wanted to spend the next 15 minutes talking about cortex at a high level, but gear I will also dive deep into it a little bit more give you a quick demo. Not enough time, but hopefully we can give you just a quick flavor of what it is that cortex all about. Most of us spend a lot of time preventing attacks. And that's clearly where 99% of the efforts should be, because we can prevent everything, obviously that's a great start. The problem is, there's still that one in some cases less than 1%. But there's that piece which we cannot prevent and that's where most of the danger lurks. And we talked to customers. And they say anywhere between 20-40% of the alerts are the maximum that they can get to. This is with great technology, great people at best they can get to maybe 40%. So what about all the others that, they don't track that they don't know about. And I'd love to be tell my team. I tell these people I'd love to be an industry where we're just talking about unicorns and rainbows unfortunately, we live in an industry where there are bad guys out there. And so we have to focus all our efforts on preventing. But we can't ignore that piece, which we can prevent them. Therefore, we've got to figure out how to detect and respond to it. Now, what the state of the art is and you're listening to near before. He said, what this industry has done is we've created more tools and all they've done is created more alerts. So this is typically what a sock analyst deals with. They have a lot of screens in front of them. And each one promises to take care of one point solution or offers one point solution, puts it in a silo and what they end up with is more and more alerts. So at the end of the day, most socks are facing more alerts from more systems by itself that's a problem. But what makes it worse, is that there aren't enough people in the industry to handle all those alerts depending on various. whichever source you want to look, they all point to the same direction anywhere between one million to three million cybersecurity professionals that are needed that aren't present. I think you all live this everyday. I'm sure you believe, you see that everyday. So what we end up with is a situation where there's way too many alerts and not enough people to handle them. So what do we need to do? We need to obviously take, we believe is the right approach, which is spending all the effort you can in preventing, provide the best prevention that's possible. And then what do you need to do with the stuff that isn't preventable? You have to be able to detect attacks. But in an industry that suffers from a chronic shortage of skilled people, trying to solve that problem with more people are better people is not the answer. Because the bad guys out there are, not restricting themselves to just what they can do individually. They're using every bit of technology out there. They're using compute which is more or less free storage, more or less free. And they are looking to target a specific company, a lot of times, they're not looking for a specific thing. They're just out there and saying, well whatever sticks, we'll see what I get out of it. So you can take a problem that has been created through automation and try to solve it by using people. Which means you've got to use automation, you've got to try to understand what these attacks are. And then investigation and response to them has to also be as automated as possible. And then you heard me talk about this, it's not enough if you do it just across the endpoint. Because then again, what you're doing, is there any other silo you gotta do it across network endpoint and cloud and that's what cortex really does. So what we bring together with cortex is the ability to take very rich information across your network across your endpoint across your cloud. And the real value is in a rich data that we take. We put them all into the cortex data lake highly normalized has all of the all of the analytics, all of the intelligence that's built in. And it's able to stitch together information across all of these three areas of your infrastructure. And then identify the root cause of these threats, prevent as many of them as possible. And where we can prevent them present them to you in an application called XDR. Which gives you better context, better visibility, better integration than anything else we've seen the market. And so, the ability to integrate and stitch all of that data together and provide the intelligence that an analyst needs is really what the magic of cortex is all about, okay. So we want to prevent everything that we can, detect automatically what we cannot prevent. Because again, trying to solve this problem with people is going to do, not only is it not going to scale, we don't think it's even going to work. Because there's way too many alerts, not enough people and you have to be able to investigate this rapidly as quickly as possible. Again using as much automation as you can and then respond and adapt as your needs grow. So what cortex brings together is the ability to take all of this information together across network and point and cloud. Put it into a highly normalized and very intelligent data lake. And then bring that intelligence to the stock analyst or to the sock. So that they can then identify, first of all, we reduce the number of alerts so they get a very small number of alerts which are highly curated. We give them all the visibility that they need and they can quickly the respond to them. And if it's a one time response then they can automate that. And you will see not just from Vera's demo, how we do that. And also after me, my colleague from which we will talk about how domestic and even orchestrate and automate that even further. So with that gear to take it away. >> Thanks. So maybe I'll see because I'll do the demo. So I wanted to maybe spend a few like maybe a minute or so talking about the type of data and what we do with the data and what's special about the way that we handle the data. And then show how that plays, when we want to use it for accurate detection investigation. So, as you can see, there are lots of different contexts for the data. There is network data, endpoint data, user data and thread data. It actually comes from a lot of different sensors. Network data comes naturally mostly from the fireworks back but actually also from the endpoints. When I talk about network data, we're actually talking about all the different, all the connections that come from the network, right? I mean each and every single connection has some meaning. Because if you want to do analytics, you want to see trends over time. We need to see everything. Endpoint data includes, the networking information but also all the processes that are spun up or the modules that are loaded and so on. User information actually has all the user context of everything. So there's really a lot of data out there. And if you look at each silo separately, there is really no connection between these different types of data. You can see data from the endpoint separately from data, from the network but actually it's really the same thing, that these are the same connections that come into play. And we actually need to stitch them together into one data set in order to make it meaningful, both for detection and also for investigation. So this is some part of the stitching that we do is really taking the different data sources. And creating one representation that is what happened in the back end, not just from a specific seidel. Then the second topic just before showing it on the demo say a few words about analytics. So how does analytics works? So that what we're trying to solve with analytics is really getting to a very small number of highly actionable alerts, that are meaningful and and relevant in your organization. And the way we do it is by learning about profiling the different users and machines in the organization. And have these different types of profiles that we create and all of that happens automatically. The system learns the normal behavior of each and every user machine and creates these different profiles. Time profile. Pierre profiles. The concept there is that once once we observe a new behavior, we have all the context about what's normal for that user, what's and what's not. And what's normal for other users in the organization, what's not. So for example, if we see somebody running remote commands or another machine, which is something that happens thousands of times in every network. We can determine if it's actually normal for that user and towards that destination or if it's abnormal. Because if it's abnormal, it could be part of an attack or an active lateral movement inside the network. But if it's normal, it's one of these thousands of cases that are normal. So we need to differentiate between those two and this is how the gist of how analytics works. So with that let's move to the demo. Demo is more visual so, hopefully it's going to be a good use of the time. So this is our incidents, screen incidents for us, the concept of incidents is really bringing together different types of alerts, that are related to the same artifacts, meaning the same processes or the same devices and so on. So this is one of these alerts has high severity, let's open that incident and see what's inside. When we opened the incident, we see that they're actually two different pieces, that are part of that incident to different users. And there are these processes that are coming to play, maybe enlarge it a little bit. So we have WinRAR, we have current and this colonel that's marked as Israel, this one is actually malicious. But it's not enough to just look at the malicious one because we want to see what happened there and if it's if it requires more attention than just looking at alert. So let's, >> check the little check by the signatures. >> Yeah. >> What was that for? >> Yeah, that says the signature is validated. So you can actually trust the signature. It doesn't mean that the file was used for good intentions, right? Because maybe somebody was using it to unpack malware or something like that. So I just opened the more detailed view and here you can see the execution chain. Maybe now did this way, so we can see that WinRAR was the what we call the group owner. This is the significant process that started all of that. He'd actually run a command line, that ran all these other processes a curl and power shell. And if you wonder why WinRAR was running. We can actually look at the parent. And see here that actually somebody was using opera to browse the web, and probably downloaded some fire, right? So this is probably the reason for WinRAR. Then specifically if you want to see the command line. We can see that somebody was using the command line because they wanted to open this particular file that was within archive. So that file was mimicking maybe an interesting file to look at but it's actually malware. But in general, what happened is that it opened all these processes that did this command control upload basically downloaded the malware and install the malware on the machine. So we actually got quite a few alerts on that. We have an alert from traps, from the endpoint protection running this through the cloud service that analyzes file samples. But we also got some other events. For example, we see that there's actually a formal event for command control. We see that the fire was detected some command control traffic. So there is a signature for that particular type of malware that was detected by the far wall. The interesting thing, is that once we stitch everything together. We see that it's all related to the same processes. Because we get the others from the flower, we get the information from the endpoint and we can stitch it together and see that it's really actually part of the same incident. So it really helps us with the investigation, also helps us with understanding the meaning of what happened. So this is one example, another example that I wanted to show, real quick is an analytics example. So when we look for an insider threat or or even an outside outside their attacker that is targeted, we typically don't see malware so often, right. I mean, it could be anybody from within the organization they don't need malware. If it's somebody from the outside, they may be using malware, but it could be a completely different malware that we don't directly find or stop. So we cannot really assume that every time there's something going on we'll see malware. But there's really a lot of hints in the actual behavior behind the scenes. So this is an example where somebody did some reconnaissance using felt connected, connection is our can be used for during reconnaissance. And in fact the relevant machines that are vulnerable to some or offer some services within the network. So this is an example how with analytics we learn which I addresses within the organization are active and which are not active. And if we see connections or connection attempts that are failed to destinations that are not active that basically don't have anything behind them. This is actually something that we want to flag. So there are a lot of failed connections in the network, tens of thousands of them in every network. And every day could be in an hour event. But really only very specific, instances of those are interesting from a security perspective. So this is one example. Another example is a brute force onto one of the services. So this is a my sequel server [COUGH] blunt force into that server means that there are a lot of legitimate connections. But when you look at the bulk of the connections you see that something is wrong. Why would anybody creates so many connections to the same service? If we look at the details we can see, again quick investigation, we can see that these connections are basically using the command line that connects to my sequel but with different passwords. So somebody is trying to guess passwords. So again this is a very quick way to to find out what was going on but the data behind it is really all the connections out there. We learned what's normal, we identify the abnormal behavior and as you can see in that case, the abnormal behavior is many connections. So taking all of that together, building the right level of incident and showing all the details for investigation is really the secret cells behind cortex six. They are decision.
