hello and welcome to Milder, one of the advanced C T. I program
in this matter, we're going to discuss the Threat Intelligence maturity model.
It's pretty interesting. As I mentioned in the introduction, several different vendors in the cyber security
market have developed their versions of this,
away for an organization to or or the practitioners within an organization
to analyze where they are in their current timeline for the maturity of their C T. I program, starting off a level zero,
the analysts are. Even the organization as a whole doesn't really know exactly
how to get started. So some of the challenges here relate to the different threat feeds that might be available.
Anyone who has spent time searching for threat feeds has probably quickly discovered that there's
Maur Choice available than then is easily analyzed.
You might suffer from what's known as analysis paralysis.
There might be hundreds or maybe even thousands of different choices available for where you get your information.
Now we see mentioned here about the SIM device,
Sim device can sometimes be seen as sort of a all purpose tool for aggregating information and
just magically letting people know when there's a problem
and thereby making everything more efficient.
And once the SIM device is properly tuned
and has been configured in such a way that then you might get close to that ideal
But at the beginning, you're you're sending raw feeds to your SIM device.
Different vendors have different formats for the types of events that their products produced,
but usually with a sim device, your usual looking for something like a sis log format that's pretty typical. The problem again, with this kind of approach at the beginning, is that you've got
all different types of pieces of infrastructure that could be servers,
important work stations or user endpoints, firewalls, proxies, switches
and so on. There's a lot of different types of equipment that might all be sending information,
and it's difficult to understand.
Is this data that we're getting
truly useful? How do you decide where and when to filter information out of your capture so that you don't clutter up your databases and make the analysis more difficult?
In the previous course and the introduction course,
we talked about the the IOC of the Internet,
the indicator of compromise, now an indicator of compromise could be quite a wide variety of different facts or or scenarios. Some of the simpler things could be some follows. Missing or new files have been created
or a system CONFIG file has been changed. Or maybe there's a time stamp information on a file or a folder that's been modified.
Any of those things could be an indicator of compromise.
It could be that there's artifacts left over from some malware infection and someone so on. These IOC's can be
quite wide ranging, and they will obviously very on a case to case basis as far as
what is considered actionable, what's not. How do you feel for that Out and so on
a T beginning because of the use of something like a SIM. You do have some of the benefits of automation
if you can figure all your devices to send the data to the Sim than the sin can automate a reply or a alert that goes to the various people that are
that are interested in that information. But at this early stage, you really don't have your team together. Yet
the roles and responsibilities haven't been fully defined,
so because of that deficiency. There are,
uh, some definite risks and exposures, as we see here.
A lot of the work, maybe manual. You're only getting limited automation with SIM device. At the early stages,
you may not have the right
rules and responsibilities define so that
a deeper, more comprehensive analysis is not yet taking place.
anyone who's managed to sim or manage an I. D. S
knows that you end up getting overwhelmed with alerts and events,
and it's very difficult to figure out how to whittle that down on how to sort through that information to get to what's really important.
in the previous discussions where you've got this big, massive pile of hay and you're trying to find a few needles that might be hidden
in the haystack. And that's difficult challenge. At the early stages of of SETI I, maturity level one, the organization and the and the analyst and the engineers and so on are gaining some momentum.
So now the automation is becoming
a little bit more useful,
that problem of being overwhelmed still exists
because now you may be thinking, OK, we've got more and more different sources of information coming in.
But, you know, you're getting tens of thousands of events every day. How do you decide
which ones of those events are worth looking into?
The team may start taking a little bit of shape
in the previous step. Maybe your network administrator was the only person who was security administrator might be the only persons who were
looking at this information. The network admin might be involved at level one as well,
but we see that maybe, uh,
analysts or or other practitioners security practitioners might be getting involved as well. And that's important because
there needs to be some sub division of labor so that people can focus on their areas of expertise without being spread too thin.
It's always a challenge no matter what kind of environment you're in.
But as we see in the risks and exposures areas here,
this is still being reactive instead of Proactiv
because you're getting information
aggregating it and trying to automate some sort of a response.
And because the information isn't well formatted and well understood, it can be difficult to understand. Are we looking at
a campaign of coordinated events or is it just a single attack that is not connected to other events that have been recorded or discovered. That's difficult to tease that all a part and part of the reason why
the the effort on filtering and blocking must must be ramped up during this phase
in order to reduce the number of events overall
and try to find a methodology or some logical rules, or even a decision tree, if you will,
to the events on the data that are most important
while not losing any of the information which
could turn out to be critical.
There is always that that balance between filtering information out and focusing on what's left over
for the for the analyst. You know, there there's that little voice in back your head that might be saying, Well, did we filter something out that we still should be looking at?
It's a question that never really gets 100% answered. In my experience,
it's something that you just have to be aware of and
be willing to remain open minded and make adjustments as needed.
could also benefit from making some improvements in the structure of the data that's being sent to it