welcome to Lesson two module to within the Attack based stock assessments training course.
In this lesson, we're going to talk about how you can understand data sources in the context of attack based stock assessments.
This lesson fits into the third phase of our generic attack assessment methodology analyzing components and in particular, represents kind of the first sub phase of this
larger phase. Here. Within the analyzed components stage, we really consider three primary things. We look at
data sources, analytics in tools and in this list, we want to focus primarily on how you can analyze data sources as they relate to attack based stock assessments.
This lesson has three primary learning objectives.
First, after this lesson, you should understand what attacked data sources are
second after the lesson. You should know how to quickly identify relevant data sources given informal description of them and, of course, lastly tied into the second point, you should be able to map informal logging strategies back to the attack data sources that those strategies might be keying off of.
So looking at the attack framework here we have a screen shot of the O s credential dumping act technique. One of the interesting things we can see here is in the lower right hand side, the data sources. This is effectively a list of different things that defenders can monitor to potentially identify this adversarial behaviour,
breaking it down even further attack features 58 unique,
not standardized but
unique defined data sources. And on average, each data source maps to about 26 techniques.
Of course, this is skewed very heavily, and you can look at the chart on the right to see that really the most useful or rather, the techniques that can potentially help detect the most techniques.
Our process. Monitoring, which clocks in a 286 potential techniques process command line parameters at 182 and then file monitoring at 162. Of course,
there's a lot of nuance and and differences here, but you can see that there is a nice spread of different data sources that we can consider in running an attack based stock assessment.
So from an assessment perspective, you know, data sources sound great. This is good to have, but but why do we really care, right? What is what is the key thing for assessments and data sources.
And ultimately, the point is, most socks tap into data sources in some way, be directly logging them using detection tools, a key off of them or building custom signatures and analytics leveraging attack data sources.
And the idea is that ultimately, if we can map what the sock does, right, what the technologies are doing
with the data sources they're using back to the attack framework, Then we can infer some kind of coverage.
And for this lesson, when we talk about this this methodology we're gonna we're gonna go through
coverage here. It's really just whether or not the data source can potentially detect the technique,
we'll get into a little bit why we use this very simple definition later in the lesson.
So here's an example of how we can analyze a specific data source or data source strategy.
Were given a description of a sock here. Um, it's relatively contrived, but here we're gonna say, Oh, my sock has amazing detection. We are running antivirus and all of our endpoints leveraging quantum supremacy for predictive Blockchain analytics capturing packets to and from all of our endpoints
forwarding all application logs into a SIM platform
and proactively patching all zero days with next Gen Artificial intelligence.
Given this as my strategy for what I'm doing with my socks,
what techniques might I be able to detect?
Well, the way you can you can figure that out, is to break down this informal strategy into each of these kind of bullet points and analyze the bullet points individually
walking through what that looks like. We're going to look at the first bullet point running antivirus and all endpoints
right away. We can see that phrase antivirus
and realize Oh, hey, this maps back to the attack Data source Antivirus. So right there, we have a data source that this is going off of.
And the second bullet point we're leveraging quantum supremacy and predictive Blockchain analytics.
Those sound cool, particularly when used together, but they don't really map back to the attack framework.
The third bullet point capturing packets to and from all endpoints is pretty solid. We can immediately see Oh, capturing packets that represents packet capture within the attack Data source Corpus.
The next bullet point is forwarding all application logs into a SIM platform. The same platform is great. But here the key thing we care about is the application logs
that right there is an attack data source.
Then the last bullet point. We're proactively patching all zero days with next Gen Artificial Intelligence.
This is another fun one. But like the second bullet point, these are cool things to do but not necessarily relevant for attack data source.
after running through this analysis, the cool thing that we have is that we have these three data sources that we know that this sock is going to be using and we can look at each of them to understand what coverage looks like here. We've created little heat maps showing what each of these data sources might be able to detect. And what's cool is you can aggregate all of them together
to paint this kind of, you know, general coverage scheme that says, Hey,
if that's your data or a strategy, here is where you might be good. Here's what you might not be so good.
So a couple of gotchas and tips for working with data sources.
Number one always pay attention to deploying versus collecting versus using a data source. There's a ton of nuance here and give them an example. I I'd go to antivirus from From From the last slide
here, this is something that is both something that is deployed. You deploy an antivirus software suite to your end point, but you can also use it as a data source. There's nuance there, and you almost always have to make a judgment call based on the context.
And then the second key thing is that even if you're collecting something, you're not always using it. We can forward all the process monitoring logs into a SIM platform. But if we're not building good analytics with those logs, there's gonna be a lot more noise to signal.
The second tip is to be as specific with data sources as possible whenever possible.
Always try to log specific sources as opposed to broad categories. An example here is, you know, suppose you have a network appliance,
you know, say from vendor A. It's best to note that you have A S logs as opposed to just generically application logs always try to be specific when you can.
It's also not just the type of data, but where it's collected.
If I tell you. I'm I'm collecting processed logs, Process monitoring logs.
That's a good thing for me to do. But if I'm only doing that on, say, 5% of the endpoints of my network, well, maybe it's not as
that fantastic of a thing. Of course, it is a good thing to do, but
it's not going to provide you a ton of coverage because I'm only doing it on a very small portion of my net.
And then looking at a data source doesn't mean you'll detect the technique
often just with data sources. We like to say, Can you see the data source or not? But coverage itself when you're when you're performing the full attack by stock assessment that ultimately depends on how you're using the data source. This goes back to process. Monitoring is a great example of something that you can ingest a ton of. But if you're not building good analytics with that data,
you're really not gonna be detecting anything.
And then, lastly, a little bit of nuanced sub techniques and techniques they don't always have the same data sources. Sometimes sub techniques have data sources that don't apply to the primary technique,
Of course, attack data sources are great, but the community has done a great job of building more resources to use to come up with different attack assessment methodologies with regards to data sources as well as other resources. That same map, actual logs to the attack data source that they applied to
one that's always stuck out to me is the first one all of heartsongs Attack Data map project.
And here is just a very simple screenshot from that project taken from an excel sheet that Olaf published.
And the cool thing is that on the left we map these different attack data sources to the actual events that we might see at the technical level
and just give you an example highlighted. We have an event code Windows 46 56 which is a very specific Windows event log, and we can see all this maps to Windows Registry.
I like this sheet a lot because oftentimes when you're doing an attack based stock assessment, you'll be getting this stuff on the right. Those very detailed descriptions of what logs are being collected and then using a chart like this, we can easily map them back to the attack data source that those logs represent
so a few summaries and take away points from this lesson.
Number one data sources provide the cornerstone of many sock activities. Almost any attack based stock assessment should have some sort of analysis of data sources within it.
Number two, mapping sock things. The data sources can let us infer attack coverage.
This is a very quick and easy way for us to understand more.
We have not abstract, but but
not well defined in an attack perspective, things that the soccer is doing.
You can let us take those things and push them back to the attack framework.
And of course, there's tons of nuance. Not all data sources are created equal.
Just because you're collecting a data source doesn't mean you're using it. And be careful with data sources and sub techniques.
Lastly, to close out this lesson,
we encourage you to look at the next lesson. Where will walk through a few examples that you can use to really use these and put into practice
the points from this lesson itself.