other things to think about is the analysts themselves.
I mentioned this ideal of earlier from a financial point of view,
but if your organization is large enough and you've got enough maturity in the cyber security program,
then you probably will have a tactical threat. Analyst and operational threat analysts. In a strategic for an analyst,
these functions could be performed by
the same team. For instance, if your organization's little bit smaller.
relationships larger, larger, it might make more sense to break these into separate little functions.
Or at least you got a
CT I theme. I'm sorry, c t. I team with different analysts rules within it.
And these are great things to focus on as faras
for that particular function
because a tactical threat analyst is going to have slightly different priorities and methods and tools than someone who's working at the strategic level. That makes sense.
So the idea would be that these these different types of ales would work together
sharing information where it's appropriate
look at the bigger picture and the smaller picture, and maybe the medium sized picture
detecting and responding a P T S.
Sometimes the AP ti is not discovered for years at a time.
And that's where the tactical and operational Strategic
Threat identification could play a big part
because there may be some near term indicators
that seemed to point to a threat that's in the environment.
And then when it studied at over ah, larger timescale and using different types of information, it might be determined, Hey, we've got a bigger problem than we thought and it's more pervasive than we thought.
And therefore, that's the benefit of these different levels of focus as it relates to time frames.
We're the biggest tricks of of any threat intelligence program would be to identify false positives.
It's very easy to get excited and think that you found something that's actionable,
but really there needs to be some sort of verification or validation steps
so that the organization doesn't waste time
The idea that you should
be able to verify the information from maybe two or maybe three different sources is a pretty good rule of thumb to follow.
This way you could do some correlation and some verification from
different places, different sources differing threat feeds, for instance.
And this provides more assurance or confidence to your management when they decide to
pull the trigger and say, Okay, we've got a big problem. Let's get the incident response team going on this.
So talking again about into indicators of compromise.
I've got several of them listed here, and these are all
things that might be
suspicious. They might be malicious,
for instance, any kind of large amounts of traffic
compared to a baseline,
the baseline concept is pretty important. It applies to a lot of different things. But
in the cyber security sense,
performance considerations and so on is very important, because what this means is
that you've got some point of reference to say that we've measured
a typical worked it. For instance,
we know that there's a certain amount of
streaming video traffic. There's a certain amount of
encrypted communications coming in and out of the environment.
It might be a certain expected about an email, traffic and so on.
There's a really great tools for measuring these kind of things, things like a net flows,
which basically will let you look at
the metadata of all the package your network
which is basically the headers, right.
this will let you categorize the traffic to say that we've got this percent of
streaming video. This percent of
regular http traffic, some other percentage of FTP traffic or whatever is appropriate.
And if you look at that information over longer time frames, it becomes easier to spot anomalies.
So So the longer timeframe becomes sort of a baseline. And then you look for
unusual spikes in that traffic, too,
to say Okay, well, looks like maybe there is a denial of service attack happening.
Or maybe there's a worm outbreak, and this explains the spikes in outbound traffic
I. P. Address the public I p address. That's got a poor reputation score.
You could go on and on for quite a while, thinking of all the different types of indicators of compromise.
This is just a small
lives to get you started
and to to think about, how would you measure this?
How would you measure, for instance, up something like patching anomalies
if you've got a well defined program for patching
and systems are getting past outside of the normal maintenance where? No. Then that's a potential IOC.
what about data in suspicious locations?
I mentioned this an earlier conversation.
Intruders typically will bundle up information that they're intending to exfiltrate.
In the meantime, they've got to find a place to keep it
hopefully so that it doesn't get discovered until the time is right for them to pull the data back out
so you could use things. Tools like file integrity, verifiers,
trip wires. A good example of this
looking for, ah, an alternate data streams
or just doing searches for zip archives or any other archive type file.
indicators that something strange is going on, especially if those files are password protected or encrypted,
and nobody knows anything about it. And that's not a normal way of doing business that looks suspicious just on its own
strange ports and addresses on the network
again. Something like that flows is useful for this kind of thing.
These are great ways, Thio correlate as well you might.
Okay, we're on it flows showing a strange amounts of traffic going to I P addresses that are unfamiliar, and we're also seeing some indicators on our I. D d a p s.
Maybe you correlate that with some firewall logs or even longs from your proxy.
Then you can start to paint a more complete picture to show where the connections are coming from, where they're going to
and if the traffic appears to be something other than than what it's headers imply.
A simple example of this might be something where you discover
a large amount of data that appears to be http
That's what the header of the package says. But inside the payload,
there's encrypted data
that shouldn't be the case. If it's Http,
the entire payload should be in the clear should be readable
by using a simple packet sniffer
or a particle analyzer.
So if I discover http packets with an encrypted payload,
there's an excellent chance that someone's
using a tunneling mechanism through http because that port is open
and you can get through the firewall with it
that by definition, should be treated as suspicious traffic.
You get the idea here on what
which have things to look for,
and as the analysts become more accustomed to their jobs and the tools are more refined and tuned to eliminate false positives.
Then your your list of potential IOC's
might expand quite a bit.
And then, hopefully you've got the right criteria and the right thresholds to understand
if a particular I'll see is appears to be happening,
you should build a drill down a little bit deeper and find out if it's really all right. So that's the end of the box. Will see you in the next one. Thank you.