Hello, and welcome to our webinar today. Today, our topic is how to hunt threats effectively with network detection and response solutions. I'm John Tolbert, lead analyst here at KuppingerCole and I'm joined today by Spencer Lichtenstein from RSA. So this is one of our KC events and we have some other events coming up. Just thought I'd run through these very quickly here in the next major event we have is customer technology world, which starts on October 20th. We will have a KClive tools choice event, where we look at the leadership compass own privacy and consent management, also October 20th. And then after that, we have our cyber security leadership summit in November. So please join us for those if you can.
About the webinar: everyone's muted already, we'll control those futures. You don't need to mute or unmute yourself. We are recording the webinar and both the slides and the webcast will be available probably tomorrow or the next day.
And there will be a Q&A session at the end. And if you look in the side in the gotowebinar control panel, you'll see a blank for questions, and you can type questions in there at any time during the presentations. And we will take those questions at the end, we'll start off by giving an overview of the NDR space. I did a leadership compass on this a couple of months ago. So we'll talk about the methodology and the criteria, and then give a quick look at the top results of the leadership compass on network detection and response. Then I will turn it over to Spencer and we'll take those questions at the end.
Let's set the landscape for why we need additional security tools at the network layer. So some of the top concerns that we see in terms of network security over the last year or so are things like ransomware, it's still a big problem. It makes the news quite a bit, you know, ransomware has really evolved over the last few years. It sort of started off, well, not really innocuously, but it might lock your screen. But then we moved into encryption and, and, you know, demanding large amounts of cryptocurrency to get a decryption key. And a lot of times the bad guys wouldn't give you the decryption key. So, you know, we've, we've been recommending for years, obviously have a good endpoint protection program and then also do backups. Don't pay the ransom. You know, we've also seen some cases in the last 12 to 18 months, a ransomware being deployed as a kind of a sideshow for apt or advanced persistent threats.
So they'll load up a network, you know, different places with ransomware and then detonate it. You know, it often happens too, like on a Friday night when everybody's going home. So there's lots of, lots of cases of ransomware and that's still something, unfortunately that many organizations fall prey to password dumping, malware, you know, Verizon data breach, and many other sources will tell you how prevalent passwords are used in different data breaches. So use the dumper malware, you wind up with lots and lots of passwords. This is still a unfortunately a prime vector for attacks. What's kind of interesting though, is how misconfigurations in, in all the different complex pieces of network servers, applications and cloud are kind of leaving the front door open for a lot of attackers. And in the latest iterations with the DBIR from Verizon, they're finding about 85% of these are errors that are caught not by the companies or organizations themselves, but either exploited by attackers or maybe discovered by third party audit companies as well. So misconfiguration is definitely something that, that needs to be addressed in an even greater way. And then lastly, insider threat continues to hang around 30% of the time. And they're usually motivated by financial reasons or espionage reasons, which really still are financial reasons.
So I grabbed some graphs from the Verizon report, cause I think they've, they show things pretty well here. And the, on the left, we've got the financials very high as one of the reasons that a cyber crime happens, espionage kind of undulates there, you know, somewhere around 20 to 30% a misconfiguration, you can see that that started jumping up in 2018. It's a, you know, a little more than 40% of attacks can be precipitated or at least facilitated by misconfiguration. And then again, we see, you know, the actors and the breaches it's holding steady around 70% external and 30%, or maybe a little less from insider threat.
It's also good to take a look at specifics on what the motivations are. This comes from hag again. And I think this, this really shows 85% and that, that does hold pretty steady as motivated just by cyber crime, with espionage being, you know, month over month, about 10, maybe 12%. So these are very, very real and things that need to be mitigated against. And then it's also good to look at well, who are the victims of these attacks? And you can see from this pie chart, it's practically any industry, to some extent, whether it's, you know, healthcare related industries, as a result of the pandemic, there have been increasing numbers of attacks against healthcare providers, those doing medical research, you know, but it it's still spans. The gamut. Retail is hard hit as well. Manufacturing, you know, you can see the things like cyber espionage happen, where wherever there's information that can be gained. So whether it's the scientific technical manufacturing, all these industries are often targets of different kinds of attacks.
And then looking at the attack techniques that are used again, this is just a snapshot, but you know, it's shows kind of a representation of what the distribution is. We see malware still is often used the, the misconfigurations, the targeted attacks, you know, there's things fishing. And then some of the attacks that we've been talking about for many years, SQL injection or brute force password attempts, and then account takeovers. So again, lots of different techniques that are used to varying degrees of success by attackers. So let's talk about how network detection and response tools actually work and why we need them. So, you know, many organizations, hopefully everyone has endpoint protection and now even endpoint detection and response, which are great solutions and absolutely necessary, but they, they can't cover everything. So why do we need network detection and response? I call it the BYOB bypass for the first reason here.
And so a lot of organizations will allow their users to use some of their own devices. You know, maybe, maybe it's just a phone. Some companies allow users to use their personal equipment, but you know, if you don't own that as an organization, it can be harder to enforce machine policies or make sure that they've got for an end point protection or, or even if the iOS has patched properly. And then if you're excuse me, to have a business relationship and say, you've got business partners and contractors, again, it's a little bit more difficult to control the health of the devices that your business partners or contractors bring in. So again, network layer detection tools are useful for that. Sometimes there's just ineffective endpoint protection too. I mean, some solutions are better than others. EPP, you know, anti-malware agents have to be updated if they aren't updated.
Then, you know, in the old times it was a lot of signature base, but there are also changes to the machine learning detection models that sometimes have to happen. And, you know, some EPP clients really require full-time internet connectivity to be able to talk to the vendor cloud and send up samples for detonation. And if they're not able to talk to the cloud, then their effectiveness is diminished somewhat. Then we have IOT devices that in many cases can't run an EPB client. You know, the OSTP doesn't support it. There's no physical room on the device, whether that's memory or storage. And a lot of these devices just are user configurable. So you can't put an anti-malware client on it in the first place. Then you also have what I would call specialty devices with really limited or, you know, hard, well, not really harden, but limited OSTP builds.
And I think a common example, there are medical devices where, you know, maybe they come with a limited operating system and the hospital staff are just not allowed to tamper with that by adding an anti-malware client because of invalidate the warranty. You might also see this in industrial control systems, SCADA systems. So there's really no visibility and no way to install security software on these devices. So again, you're left with the only way to detect something bad that might be happening is at the network layer. And then lastly, advanced malware, you know, ABTS, they can actually erase your system logs, your operating log operating system logs, or, you know, in some cases we've seen them where they turn off security tools. So, you know, if you're counting on EPP to tell your SIM about what's going on there, that might not happen in the case of a very advanced attack. And again, you'd be left with no visibility except what might be happening at the network level.
So as part of a good security architecture, we think you need tools at all. The different levels that's includes endpoint protection detection and response NDR, which are kind of in some ways, an evolution from the IDs, intrusion detection and prevention systems of 15 and 20 years ago. But now they're more, I think, proactive and mostly machine learning based detection models, as opposed to the static rules of IDs. And we have soar often sitting in the middle security orchestration, automation and response, you know, gathering information from different sources and helping SOC analysts prioritize them and do investigations. You still need Sam or someplace to collect all the server logs. And then now since pretty much, everybody's got some cloud aspect to their enterprises, whether you're running infrastructure as a service, or maybe you're consuming SAS services, things like CASBY can be not only a help, you know, a gateway for that, but it can also be a source of telemetry. So CASBY or your cloud access security brokers.
And I thought it'd be useful to take a look at the MITRE attack framework. This is something I've been looking at a lot. And in all my cybersecurity related research is seeing how different vendors, vendor products align with the MITRE attack framework, you know, nine or 10 years ago, we started off with, you know, the Lockheed Martin kill chain, which I think was really good way of conceptualizing how work. Now in the last few years we've been looking at the MITRE attack framework. And I think what's most interesting here is whereas, you know, with kill chain, you might be thinking about how do you prevent and disrupt an attack. The MITRE attack framework really shows you that the prevention only works at the very beginning phases of an attack, like the initial access, or maybe preventing execution of a piece of malware. The rest of it is all about detecting and responding to it once, once an attack gets to the point of, you know, stealing credentials or are trying to move laterally around an organization, that the only thing you can prevent hopefully is exfiltration at the end. But in order to do that, you have to detect it first. So I think MITRE attack framework reflects a change in thinking in cybersecurity that we need to put more emphasis on the detection and response phases.
So let's talk a little bit about NDR products and how they work, where they get deployed, you know, in order to be most effective, you really need visibility into all the different parts of your enterprise. I won't say your network because networks themselves are pretty complicated things these days that that may involve your infrastructure, but also cloud. So, you know, it's easy to think about, you know, covering your office network, your employees, your E, and even your line of business app applications that you may have in your own data centers. So, you know, an NDR tool probably comes most of the time as either an appliance that you plug into a span or tap port on your, on your router, a switch or a packet broker to, to gather all that information. But, you know, there are also images for different cloud environments where you need to be collecting the same kind of information and passing that on to the MDR console.
So, you know, we have contractors partners VPN today, especially since, you know, as many people who can are working from home, those environments need to be covered, but then you also have other environments like shop floor laptops, you know, maybe you've designed your network to segment off the shop floor, your manufacturing systems, web services that you use. And then, and then there's the wifi IOT kind of environment where, you know, a lot of enterprises will say, yeah, we need lots of IOT devices, and we're going to try to segment that off, but you know, you need coverage in those areas as well. So, you know, it, it makes sense to try to deploy India, our appliances or virtual appliances, of course, on all the different network infrastructure. But you've got to make sure that you cover every, every logical part of the network to, so that you do get visibility, especially under those areas where you don't have fallback measures like the wifi, the IOT kinds of environments.
So, as I said, just published a leadership compass on this. So we'll take a quick look at the criteria that are used to evaluate the vendors and then the overall methodology. So here are the nine key criteria I looked at. First of all, I think it's important to understand how a product does anomaly detection in traffic patterns. And almost always, it starts with baselining. You've got to know what, you know, what a normal day looks like, and that can be difficult in itself to determine. So you, you need to know what's typical. So, you know, what's atypical, but anomalies don't necessarily translate into threats. I mean, an anomaly can just be something weird that happens. So you need to be able to apply things like metadata analysis and ML detection models to your anomalies and figure out, well, what, what are they, is it really a threat or not?
Some metadata analysis is looking at like the, the J three method looks at the TLS headers, and you can do a lot of determining whether or not something is malicious just by looking at the patterns and the traffic, rather than needing to know the actual content of the traffic. And again, I think what NDR from IDs are really one of the main things are these ML detection models. So there's so much data flying by, on, on networks and cloud networks that it's not really feasible to, to apply static rules based analysis anymore. Or you certainly can't have analysts looking at everything that goes by and trying to determine for themselves. So these machine learning algorithms need to be a good mix of unsupervised and supervised detection models to be able to properly classify anomalies into threats if they are, and then the ability to capture packets and then do analysis. That's kind of the difference in my mind between NDR and Sam or one of the differences, you know, looking at all the traffic rather than just logs of the traffic.
And then the ability to do automated responses. I put quite a bit of emphasis on this in the paper. I want to know which products can, can take actions to them. The main ones being like terminated session. If you think that you're seeing a, some nefarious traffic, you should be able to stop that as it's in process. And then also blocking by IP host name or URL integration with Semen's soar. You can't really just have NDR on its own. You probably have EPP and EDR, so that needs to be able to dump into a SIM. So these products need to support things like Swisslog or CF format, and then also integrate with sore, sore integrations typically happen as a result of connector, specific connectors being built for products. Otherwise there's customization that has to happen. And then the last two are optional there's packet decryption, you know, maybe a quarter to a third of the products that I looked at can decrypt prep packets.
And this generally requires you to kind of build a special place. So the network, maybe in front of load balancers, if the, the MDR product itself doesn't do decryption and handling of that. But again, you know, that can pose a security risk in itself. It's not always required because you can learn a lot from metadata analysis, but there are some high security environments that actually require that. And I tried to call out the products that support that same thing with sandbox detonation, if an NDR tool sees suspicious traffic, some of them have the capability of shutting that off to a sandbox, and then, you know, letting it run detonated to see what happens to determine whether or not it was a malicious.
So for our methodology, we start off by looking at a market segment in this case, NDR, define it, describe it, and define the key criteria, which I've just shown you. And then look for all the relevant vendors in the market. Then we prepare a really, really big questionnaire, technical questionnaire for them that they fill out. We'll do things like get briefings and demos from the vendors about how their products work. I like to understand what it is like in this case, an analyst or a system admin that's using, it would see. Then we do an objective rating based on the answers that are provided in the questionnaire. And then also from the demo and create the graphs. One of which we'll see here in a minute and then write the report. And before we send out the report, we always give the vendors a chance to fact check it.
And in case we get anything wrong, our main interest is putting out as accurate information as we can. When we publish, we have nine major categories that we look at a security is the first one, you know, does the product have good internal security? Doesn't require things like strong authentication for admins and analysts. Does it have, you know, role-based or delegated access control model functionality would be, you know, it doesn't do everything that we think a product should do. That's in the space. And if not, you know, you'll, you'll see that reflected in the, in the ratings integration that also covers, you know, how is it deployed? Does it deploy, you know, in every kind of environment you need, do you need lots of different products from the same vendor to be able to get that functionality? Or is it one single offering interoperability? This is, this is where standards are really important because can inter-operate with other products.
And in this case, you know, being able to pass data via SIS log to Sam or CEF, excuse me, it's probably one of the most important requirements for that usability, you know, end users for Indy. Our systems are analysts, forensic investigators, draft, honors, SOC staff. So what's it like for them to be able to use, then we look at, you know, how innovative is the product? Is, is it operating kind of above average in terms of feature set? Is it leading edge or is it, is it playing catch up and the market market position, as you know, how many customers use it, you know, which are they limited to specific industries? And then what parts of the world are actually using it? If it's limited to just say north America, it's hard to say that it's a global leader. If there are other companies that are working around the world, then ecosystem, that's kind of a measure of their partner ecosystem on any integrators can, are out there.
And in what different parts of the world are they for helping with installation and support and then financial strength? Is it profitable? Is it a public company, is a private, you know, what, what phase of funding are they in? If they're a startup, those things are often important to consider when you're buying a product for the longterm. So we take all that and come up with four types of leadership, product leadership is about the functionality and usability market leadership is the market position, financial strength and ecosystem. Innovation is just innovation, but we put all three of those together and get the overall leadership graphic, which we will show here. Here are the vendors that were in this iteration of the report. So there was a good, good crop of vendors with NDR solutions here. I won't bother to read the names, but here's the graphic. So the overall leaders here are on the right. And since I will be turning over to Spencer now, I think it's good to say that you'll see that RSA is in fact, an overall leader in the leadership compass on network detection and response. And with that, I will turn it over to Spencer.
Great. Thank you very much, John. Great to speak with everyone today on the webinar, I'm going to talk a bit about threat hunting with the network detection and response solution specifically in our case, the RSA NetWitness platform. I think a lot of these concepts should be applicable to everyone listening in today and certainly apply across different solutions. There are a lot of kind of core foundations to how we see NDR solutions working well in the ecosystem today. So just a little brief background about myself. I've been with RSA for about four years in a few different capacities first as a global solutions architect on this product. And now more focused on product strategy globally. Got my start in cybersecurity on the services side with a few different MSSP vendors in the space.
So in RSAs sort of view effective NDR really takes a platform approach. I think a lot of this is very relevant to what John was talking about earlier in respect to not only just ingesting the data from the network layer, but mashing that data up in useful ways, being able to run analytics on it and apply both sort of known detection and unknown detection to ultimately drive a better analyst and threat hunter experience. Overall, our NDR solution has been built with this sort of platform approach, particularly as top of mind, and also in a manner where that additional data outside of the network, whether it's a traditional log centric SIM or the EDR focused data is possible to, to layer in directly within the same interface in the same manner with that network focus data. And our belief here is that by mashing all of this up together in sort of a unified data model analysts and threat hunters ultimately can find and resolve, detecting, and respond to threats faster than by just having a sort of a disjointed and separate tool that they might normally operate out of.
And another key piece to this platform centered approach is ensuring that the proper context is included within the data that is ingested within your NDR solution. So whether it's the NetWitness platform or another solution, it's really critical that the threat and business contextual data is provided at the same time, that information is captured index, you know, parsed because if it's not, you run the risk of really getting data in that ha provides no real meaning to a threat hunter or an analyst who's looking at it. They don't understand what a host or what an asset might belong to within their organization. And that what we found that really causes both a high number of false positives and false responses to threats. And it also causes a lot of confusion about the amount of data that's presented to the analyst within an interface of a product.
And then that last layer, the response phase, both can be sort of orchestrated and automated and it can also be manual. And a key piece, particularly in our product set is providing a lot of flexibility for analysts and how they go about that response part of the process. So at the end of the day, the platform approach that we're kind of talking about is really about providing better results for the SOC team, for the organization and really improving the security posture. So it, frankly doesn't matter a whole lot what specific features you have in a product if you're not providing value and solving real problems for a security organization, this approach that we're taking within R and D our product is really results driven. So when it comes down to the actual sort of RSA NetWitness platform capabilities, I'm going to talk a little bit more granularly about each component, what it provides in a threat hunting context and how it goes about identification and resolution of threats.
But these sort of core tenants of the product are really the areas that you'll see emphasized in the next sort of 20 minutes or so. So the visibility component really crucial in data ingestion, pulling in the right information from anywhere within the organizations. It doesn't just mean a on on-prem infrastructure. You know, John discussed this evolution where we're seeing a lot of organizations have more cloud resources, have more shared resources operating on other infrastructure, really critical that visibility on the network layer is pulled in from all of these different pieces. Otherwise you're at risk for having a lot of off network or sort of more shadow it related resources, go unprocessed in your NDR solution. And then you're really not functioning at the scale that you're intending to with, with your, the visibility of the platform.
So getting in a little deeper to the specific components of the NetWitness platform, when it comes to an NDR use case, we're going to talk in the fall and kind of the next few slides about each of these in a little more detail, but to set the stage, the three pillars that we like to emphasize here are a visibility stage, which is about really collection of data, understanding of data before you get into analytics and action on that data. So that's kind of the far left component. The middle is the inside. What we call the insight layer. This is really focused on threat identification. It's a multifaceted approach, especially when it comes to network threats, know you have both encrypted and un-encrypted traffic. You have traffic that is coming in from devices that might be on non-specific or, or different protocols, IOT and SCADA systems that may not use the same type of transport layer that we're used to on specific on, on server or end user compute devices.
So you need to be able to provide insight and models on that type of traffic in order to really hunt for threats effectively. And then the action layer, which is all about remediation, whether it's manual or automated and resolving ultimately threat resolution, you know, how are we going to drive an analyst to make decisions quicker, escalate an incident to higher tier analysts for a threat like threat investigation and resolution, and how are we going to provide threat hunting teams who are looking more for an unknown type of threat that might not be alerted on, but they might need to bubble up the signal within the noise. How are we going to enable them to take action again, within a single platform in a manner that maximizes the value and time they're spending within the tool.
So when it comes to NDR specifically and collecting data, that's most was relevant to the network layer, we're focused primarily on raw network packet data. You know, this can come from a variety of different sources. We typically find, and that the sort of appliance or piece of hardware deployed in a network in a traditional manner off of span, or a tap is a very effective method to do this in a infrastructure that's controlled by the customer, but in a virtual infrastructure or even a SAS infrastructure when possible there are machine images that can be deployed to collect this. At the end of the day, we're looking to ingest as much raw or close to raw network data as possible, and mash that up with a NetFlow layer. You know, often we support a wide range of NetFlow protocols, but often, you know, NetFlow from traditional switches really provides a crucial piece that is not always feasible to do raw network collection on and at the time of acquisition, this visibility layer where parsing through indexing and making sense of the raw data when it's being pulled into the system and ultimately creating useful and meaningful metadata information around this raw data.
So that's Analyst readable threat hunter readable information, and mashing that up with context from the business, which is a really crucial, so piece to that threat early threat identification component. So the next phase of analytics, and we'll talk a little further about what these different analytic engines are, is both traditional sort of correlation and known signature detection of this data. That's all been ingested parse through and made sense of, it's also mashing up things like threat intelligence feeds the business to ultimately identify what is high risk, what could potentially pose the greatest risk to the business, and then filtering out the noise, right? The, the things that are interesting, but not interesting enough for an analyst to need to take action on. And this is all really driving the threat remediation component. You know, that action layer of the product, which includes things like Analyst, having a workbench and notes and processes to work from a full fledged sort of soar orchestration automation capabilities that are very applicable to an NDR world. And then also being able to work across your team, whether it's distributed remote or, or in person and share insights and notes on who is doing what and what priority things fall into.
So when it comes to the core product capabilities of the NDR solution, especially when it comes to hunting for those threats that are not as obvious in an environment, the analysis detection and sort of analytics, layers our pieces. I want to, I want to dive a little deeper into specific to the net witness solution. So that folks get an understanding of how we go about these pieces and then how that's driving a threat hunting result for the end user. So at the collection layer, what we call sort of our collection componentry of software it's decoder service can be on a physical appliance, a virtual appliance. It can be simply an AMI or virtual image file. That's, that's put it in the cloud. We're really just looking to pipe as much network data and NetFlow traffic into that decoder layer as possible. That data, when it comes through is then filtered depending on what the organization cares about, wants to take action on.
There may be certain protocols that traffic that really don't matter to them. There may also be later stage filters where they want to drop off raw payload information, whether that's like a raw packet payload that they don't want to store for storage and retention reasons, or whether there's data that's encrypted, that they just don't care to parse out. And for some compliance-based reason, but at each phase of this collection layer, there is a useful human readable analyst, interpretable metadata that is being created. And this is really the key piece at the collection layer of a threat hunting with an NDR solution. You need to generate value when you're collecting information and you need to rapidly parse and index that into some type of database so that analysts can go back search on it in those detection and analytic models can function the way they're supposed to against that data. If you're not doing this the right way, or if you're not, if you don't have sort of logic applied within your product to do this, I think all of the up and down layers are going to fall apart.
So the detection and analytics components, which are sort of the next two pieces here are both the known detections, you know, things like signature, traditional signature based detection, storage, snort signatures, things that legacy IDs products, you know, really focused on, but it's also things like behavioral complex rule patterns that weren't possible in the past that are not quite true machine learning and data science, but they're in the middle of a detection between detections and that data science layer. So these are mashed up and correlated to useful phases of an attack life cycle. You know, so these are components that can be aligned to the MITRE attack framework, that stuff that's all for example, out of the box compatible and in that witness. But it's also things like what the threat pattern means to an analyst, you know, is this indicative of lateral movement, which makes a lot of sense to a threat analyst versus a whole lot of metadata that's presented in a way that doesn't categorize to a useful indicator of compromise.
So detections and analytics for us with threat hunting are really focused on something that an analyst can take action on it's real time detection. We talked about a little bit number of different components that can be layered in here to provide that value on the data. And then really most critically the, what we call user and entity behavior analytics, but it's really machine learning and action, right? So in our case, it's unsupervised machine learning, and it's also advanced behavioral analytics on the data. And we're very focused on the network side around making sense of a lot of encrypted traffic without decrypting it, we have decryption options, but often organizations and threat hunting teams are not able to decrypt for policy based reasons for privacy based reasons. So they're looking to make sense of that traffic and anomalies around certificates around and driving alerts from that that an analyst can actually take action on. So it doesn't provide much value for a threat hunter to say, this single certificate looks anomalous because you know, it doesn't match a known certificate authority. It's much more insightful to look over time and say, you know, unsupervised machine learning algorithms believe this is anomalous because usually it behaves in this way. And today it's behaving in this way. And we'll go through a quick case study at the end of this, to show an example of how that actually works within the product and how it actually applies for a threat hunting team.
And then at the end of the day, this is all driving to that last phase, which is the response phase of the sort of threat hunting process. And so response in the net witness platform world is really two flavors. You know, one is a very robust, integrated response. You can see here just a quick screen grab of an incident related to malware callback, that's happening within a system, sort of a nodal diagram to demonstrate different hosts, different servers, different IPS, where the communication is occurring, a quick visual representation for an analyst to look at and say, all right, you know, these assets I know about, or if I hover over this asset, I can see critical information about it. I can add a journal entry. I can quickly escalate this over to my partner who is a more advanced threat hunter, and I can move on to the next piece.
Or perhaps from that action standpoint, I can click a button and kick off an automated, you know, end point process to isolate a host, or I can kick off a process to send a firewall block requests and create a new rule. These are a lot of the native features in the response pane that we've put a lot of emphasis around in the product to again, drive the threat hunter, to make a decision faster and resolve their issue faster and move on to the other pieces and drive that meantime to detection and response down. And then the other layer of response that I just want to note is sort of a full fledged orchestration automation capability that layers on top of this, it's made possible through a partnership with threat connect. And this is really layering in an another level of orchestration automation. And just back to some of John's original points around not having NDR function in a silo, this is something we feel really strongly about when it comes to NetWitness as a product and the value that NDR provides for an analyst. You need to be able to have other pieces plug in very quickly. And this is just just one area we've invested in a lot to do that.
So to wrap things up, I want to walk through a bit of a key study here and talk about what NDR inaction and threat hunting inaction within NetWitness looks like. Again, this is not something that couldn't be done in other products. This is just an example of how quick and easy it is to do within the net witness platform, particularly, and I think should show anyone who's in the threat hunting space. Why understanding the context behind the data is so important to quickly resolving a potential risk or incident that's occurred. So this case study is primarily driven from sort of a machine learning algorithm bubbling up a risky user in this case. So I'll walk through some screenshots here and, and talk through what this means, but at a high level analysts logs in, they see risky users initially, well, they see a number of risky things on their screen, but, you know, incidents and alerts and hosts that are risky.
And in this case users that are risky and they're driven based on a risk scoring from machine learning algorithms. And so they choose to pivot into one of the high risk users here. And there are a number of alerts that have driven a risks or in the machine learning engine, based on some type of abnormal changes to group policy. Now, initially it's not known exactly where these alerts are pushed from until the analyst decides to drive deeper into the user incident. So taking a user view, they see that primarily in the NDR world, these NetFlow logs in this case, and some supporting log data are showing unusual password group policy change activity that appears to be unauthorized based on when it took place and the patterns of normal and abnormal for this type of user. You know, we're choosing to show users in this case because it's a useful thing that analysts can grab onto, you know, versus just an asset that may not have a name and may not have context.
And what's interesting to see is that this, this user making changes that appear on authorized the asset that these changes are related to is enriched with information that shows it's a critical asset. And then they're able to quickly pivot in and look at reconstruction of raw network events to see that within this timeframe, there appeared to be some type of data issue or data leakage that occurred. Now, this isn't to say that this is the entire incident and there's not more follow-up, but it just shows that within a few clicks, you can kind of go from top level risk, you know, an NDR alerting scenario and drive all the way down into the raw reconstruction of network events, all within the same interface.
So it's a quick demonstration of what this looks like. So this is the springboard module on login to the RSA NetWitness platform. And you see here a nice kind of quick, quick view of different risk scores. In this case, we're focusing on the top risky users here, quick pivot in shows that in this case, mass changes to groups alerted within this user based ML system. And you can see in that, just in the graph here without even getting into a lot of detail, that there's this understanding of a, on what types of activities are related to this user profile took place. This could come from log log sources, NetFlow sources, end point sources, network sources. It could really be enriched by any data source in the system. And so the analyst, you know, Caesar's obviously a problem here, super high risk score. The next logical step is to understand like what type of action may have taken place from that user base standpoint.
So we're going to pivot in MIS next screen and take a look at events driven specifically around the user and the timeframe. If we were to dive into the query on the top of this, you'd see that these are all events that are around a specific time period driven from that machine learning sort of detection schema in the previous screen. And on the left, you've got enriched, useful metadata information about what's occurring. Then you've got an events list in the middle, and you've got your raw NetFlow information right here in this case. And you can see on the far right, this blowup that I showed, this is enriched with a high value high value asset information. In this case, the host is related as some sort of high value asset related to human resources. So one of the next logical steps I'd take as an analyst here is to, to dive deeper into the specific time period around this asset to understand if there was other alerting or concerning behavior that occurred, ultimately going back to is this suspicious activity indicative of an actual threat that occurred or data loss that occurred or some event.
So you're immediately able on this next screen to sort of right click and reconstruct network event details around the same timeframe. So we, we dove into the IP of this host and we see that just even without digging into the raw data within this, that some of these file sizes are fairly significant and that there's some zip files here that they came from the same location and they have a pretty significant payload size and they were outbound, you know, from this asset. So you might assume or draw conclusion here that there's some type of data loss that might've occurred, or some type of exfiltration of data that might've occurred possibly as a result of this change password policy or change password. There might be some additional steps to take here to fully resolve this, all that could be done within the same interface. But this is just a great case study example within the time we have of how you can drive from that quick machine learning detection at the top level, all the way down to sort of threat resolution, at least an initial response that would need to be taken, you know, in a single pane of glass, ultimately.
Perfect. So that kind of concludes a portion of my presentation and I will turn it back over and I think we're going to do some Q&A. Okay.
So yeah, let's take a look at what we've got here. We'll move on to the Q&A session. We have a question about how has the shift to work from home affected the NDR market in use cases? I, you know, I'll start off with that. I'll say, you know, I think it, you know, underscores the need for it. And especially if we think back to where these appliances virtual appliances in our tools need to be deployed, you know, there's, there's been a need to in, in some companies, cases, rearchitect access in general to allow the remote workforce to get access to what they need. But at the same time, you know, we saw at the very beginning of pandemic lockdowns, you know, kind of wide open access people coming in via VPN. So, you know, NDR tools, I think are an absolute necessity in that case where you have people who are, are, you know, masses of people coming in through VPN, whether they're employees or the business partners, it's, it's probably the only way you can detect a lot of the problems that show up there. What's your take on that?
Yeah. Yeah. I definitely definitely agree a hundred percent with that, that kind of outline. And I would probably add in that the, you know, the, the overlay of sort of EDR and NDR, especially in the remote work environment, is that much more crucial, you know, especially because of, I think that that VPN issue we're seeing very commonly are, you know, RSA happens to have a separate area of the business where we do a lot of multi-factor identity access management. And, and I saw the incredible uptick in VPN related requests, you know, for, for new and additional authentication. And it was just very apparent that there's a lot of people functioning off network doing a lot of things, and then going on network, you know, for certain assets and what, what threats and risks are being introduced. Cause you're out six hours of the day doing personal things, perhaps on the same machine. And then you connect to your VPN, you know, what have you done off network? If you even have a solution that protects you when you're off network and then what are you introducing into the corporate network when you connect back in, I think now more than ever with the lack of control of it devices, that is, that's a crucial piece of the NDR kind of battle.
Yeah. You bring up some other good points there. As far as VPN goes, MFA, multifactor authentication should be enabled. You know, that would cut down a lot of the security risk if we're just better controlling that the authentication gate who can get in and who can do what but NDR, I think provides that visibility that you probably wouldn't get anywhere else. And, you know, another point you made about people maybe using the same machines, or at least the same originating network with maybe other machines that aren't protected, you know, to connect to their enterprise. We, we do have tools available today that can help us separate these environments and bring enterprises up to the level of security that they need. It's just a matter of making sure that they're in place. And I think if things like MFA, you know, EPP, EDR and, and NDR are ways that businesses can better protect themselves from the evolving threat landscape.
Yeah. Fully agree there. One just quick story related to that and something, we, we put a bunch of investment into, cause we didn't realize how useful it would be until the last nine months is this is capability of our NDR solution to kind of talk closely with our authentication solution, you know, two separate products, but essentially like forcing step up in additional authentication as a result of risky network activity that seen in the product. You know, so if, if there are high alerts related to users from network data or even EDR data, then it forces additional authentication and step up authentication actions within an OD identity product, which, you know, we, we thought was interesting, but wouldn't be utilized as extensively as it has been. And I think the, the shifting remote workforce is a big driver of that.
Yeah. You know, that shows the, the need for not operating these tools independently or in silos, you know, I mean, EPP, EDR, NDR, you know, if any, are, can feed into risk, adaptive access control decisions, that's perfect. That's what we need. You know, we can't, you know, as an end user organization, you know, security architect, I would not want to just go out and check boxes and make sure, yeah, I've got an antivirus. You have got NDR now. I mean, the, these things have to flow together. Information has to come into a SIM and ideally, you know, be able to also flow into a soar and then have actions flow back down from that same chain so that you can have a coordinated response to threats across an enterprise.
Yeah, absolutely. Let's
See. Next question. What influence and importance do you see cloud data sources or cloud environments playing in evaluating and prioritizing NDR solutions? I guess there's a couple of ways to look at that. I'll just, I'll just say that, you know, it's, I think it's very important to make sure if you're looking for an NDR solution, that it covers all the environments you need so that you can get data about your assets in the cloud, whether it's infrastructure or SAS. And then, you know, maybe another way of looking at the cloud data sources is thinking about how that might get corroborated with threat intelligence from external providers too. What's your take on that, Spencer?
Yeah. The, and I think the data ingestion piece with cloud is, is the most challenging right now, from what I've seen on the network side, because, you know, we really want more than just sort of the typical SIS log or Jason type data that a lot of these cloud, especially SAS providers provide out of the box. It's, you know, what's a level deeper than that. And even with some of the infrastructure providers, you're getting a little bit more now from Amazon, you know, sort of closer to flow data or raw data from them, but the more we move, the more, the more that move happens, the more there's going to be a demand to pull in as much deep contextual data as possible. So I, you know, part of me thinks there'll be a bit of a demand or an expectation that there's more data opened up from cloud providers to, to gain that visibility.
And then the, the enrichment piece is really, I think to your point is really crucial. It's like we need more useful contextual data threat intelligence, and probably also some more specific cloud related algorithms and, and sort of analytics models for detecting on things that are more cloud oriented and more SAS oriented than we have now. Because I think, you know, I think the move in the infrastructure side is happening or has happened, but I'm not sure that the detection schema and the sort of the security focus on doing things uniquely cloud has quite caught up to it. And I, I would, you know, I would think that that's probably a big area. It should be a big area of focus in order to, to have that same solution provide the same level of value, especially since that the baselines and the normal and abnormal is quite a bit different, can be quite a bit different in the cloud.
Yeah, that makes perfect sense. Well, we've reached the top of the hour here and I'd like to thank everyone for attending today and thank Spencer and RSA for their participation.
Yeah. Thank you very much for the opportunity. Great.
Well, again, the slides and webcast will be available probably tomorrow. And, and thanks again for attending. Have a good rest of your day.
