Threat Intelligence: The Essential Ingredient In Your XDR Strategy

THOMAS GRAVES: Good day, everyone.

My name is Thomas Graves.

And over the last year or two, I've noticed during many of our customer engagements that customers feel overwhelmed with the lack of visibility they have over their environment and overwhelmed by the number of security technologies they have deployed to monitor, detect, prevent, and respond to threats against their organization.

As a vendor, I'm seeing a lot of consolidation where companies are integrating numerous technologies together, such as SIEM and SOAR or SIEM and EDR, to further enable their security teams to protect their environment.

By combining as many security technologies as possible, we can start to offer customers, what I like to call, a single pane of glass, almost like a security cockpit where the pilot has all of the toggles and controls at their disposal to operate the plane.

So, how do we successfully operate the plane?

We do that by characterizing the threat landscape.

To be able to fly that plane safely, a pilot needs as much intelligence on the operating conditions as possible, such as the weather, obstacles, like other planes, threats to the flight path, and so on.

And that's where threat intelligence comes in.

Security teams today are stretched thin trying to protect their organizations from both broad-based and sophisticated threats.

What can we do to stop those threats?

Understand the threat landscape, prioritize those threats, and identify which incidents need immediate action while also preparing for future possible attacks.

So, first and foremost, organizations have to be able to define the operating environment.

Organizations today are made up of assets that communicate both internally and externally.

Capturing logs from those assets generally tends to be a good starting point.

And the volume of log data we've seen grow exponentially year after year, almost to the point that some companies specialize in technology that is specifically focused on collecting and aggregating all logged data so that analysts can make good sense of it.

Once the operating environment logs are collected and aggregated, we can successfully start to characterize the threat landscape.

And how can we do this?

We do this by understanding how threats operate and trying to keep a pulse on emerging threats.

Now, many vendors sell this type of threat intelligence data in some form or another.

Some vendors specialize in deep and dark web collection.

Others specialize in ransomware intelligence, and many organizations today, especially, they have a public brand on social media that they use to interact with their customers on sites like Facebook or Twitter, or LinkedIn.

And some vendors specialize in, what I call, social media monitoring and collection.

And then lastly, a lot of times, the best place for gathering intelligence is from your own network or from the network of your peers.

And so, a decade ago, we saw the forming of, what we call, ISACs, I-S-A-Cs.

An ISAC is an Information Sharing and Analysis Center.

And so, an ISAC generally contains a collection of organizations that are grouped based on industry.

So when one organization in the ISAC is breached, they can share detection logic to all other members so that the entire community benefits from herd immunity.

Same concept that we see in healthcare, where one person gets sick, you use the antibodies that they've generated to distribute to all the other people, and now they're protected from that same virus or bacteria.

And the last piece I'll touch on is government.

So many government entities today, such as Department of Homeland Security, DHS, or the Cybersecurity and Infrastructure Security Agency, CISA.

They publish things like threat research or adversary tactics, notifications to the community to aid in awareness and promote secure practices.

All of this data combined together is what makes up threat intelligence.

So we've seen year over year the volume of threat intelligence that's available to companies has grown exponentially.

And so, I remember, I was an analyst years ago, and I remember the day where we had one million indicators of compromise exactly in our threat intelligence platform, and we threw a big party.

We thought of this glorious achievement.

But today, you fast forward a couple of years, I've worked with some organizations that have a half a billion indicators of compromise up to a billion indicators of compromise that they're leveraging day in and day out.

So, we've seen that as organization's network endpoint and cloud data set to grow, so does the available intelligence about the potential threats that reside in those data sets as well.

And so, this is where we see the intersection between threat intelligence and XDR.

XDR stands for extended detection and response.

And it's a strategy that integrates security products in a manner that fully unlocks threat detection and incident response.

I'm here today to help illustrate why threat intelligence is so important to any organization considering a shift to XDR.

And also today to talk about some of the benefits that organizations will realize by implementing an XDR-based strategy.

As a byproduct of integrating threat intelligence with XDR, there are a lot of other benefits that organizations will realize, from strategic levels of reporting to understanding external cyber threats in that threat landscape, even physical security threats and internal insider threats.

Really we're not only focused on stopping the bad guys that live outside of our organization but also ensuring that the trusted entities or the good guys that have access to our network aren't abusing or taking advantage of the trust that we placed on them to operate on our network.

As organizations start to implement XDR and achieve maturity in threat intelligence, they're going to have a solid understanding of the threat landscape.

They'll be able to prioritize the threats to their organization and prepare for future attacks, enabling them to fully unlock the power of an XDR platform.

So let's peel back the layers of the onion here and take a closer look at some of the features of XDR that require threat intelligence as an input.

So first, we're going to talk a little bit about visibility.

This goes back to that challenge that I outlined earlier.

Organization tend to struggle a lot with visibility.

They struggle with understanding what's happening on their networks, what assets reside on the network, what the defensive posture or compliance state of those assets are in.

And to solve this visibility challenge, they go out, and they buy a lot of products, a lot of tools that will collect different types of logs and store those logs in a central place so that their analysts have the ability to review alerts in a single pane of glass.

Now, with XDR, organizations are striving to consolidate this function into that single pane of glass so that their analysts have all the access they need to protect the organization and understand what's happening across the environment.

This is where threat intelligence comes in because as we're feeding rich intelligence to the systems that organizations have already invested in, we're bubbling alerts to the top that the analysts are going to want to focus on.

So we're sending high fidelity, high priority intelligence into these various tools that are collecting logs in an attempt for these tools to generate alerts that are high fidelity and high priority so that the analysts can really focus on what they've been trained to do, what they specialize in, which is conducting analysis.

The second pillar we're going to talk about is detection.

When something anomalous is occurring, we need the ability to detect it.

It's basic.

No matter what the scenario is, we want to detect it.

An XDR strategy relies on different analytics to detect abnormal behavior.

So let's talk about some of the things we might want to detect.

Let's start with the outside of our network boundary looking in.

So if an adversary was footprinting or scanning your organization's network perimeter to look for a way in, you'd want your detection capabilities to notify the right stakeholders, right?

Of course.

From the inside, looking out if your security tool successfully blocked an outbound connection to a known adversary malware server, that's great.

But that also means that an adversary is still potentially in your environment operating below the covers.

We want to know what malware the adversary likes to leverage.

We want to know what other malware servers a specific adversary group might be operating at the same time.

We want to know how they could have potentially gotten into our environment in the first place.

Threat intelligence has all the critical elements of information to help answer these questions.

What about internal to internal traffic?

Maybe we have an asset on our network that's trying to authenticate to a file share over and over, and it's unsuccessful, or we have an asset that's sending large print jobs to a printer during abnormal hours of the day.

XDR isn't only concerned with cyber threats but also insider threats.

So oftentimes, insider threat activity, it can't be detected based on indicators of compromise, but it is detected based on behaviors.

So really, what it comes down to is there's a valuable lesson to be learned here from a detection perspective, and it's that we not only need signatures and indicators of compromise to detect known bad things.

But we need the ability to detect unknown things, things that are only going to be detected based on behaviors.

Behavior-based detection, while it's effective at detecting insider threat activity, it's also effective at detecting zero-day malware or detecting advanced persistent threats who are operating with malware that does not have a known signature today.

So we need a blended approach to provide full coverage for all the different types of threats that we could potentially face.

And this segues us nicely into our third pillar, which is incident response.

Once something is detected, what do we do about it?

Do we just drop everything and deal with it?

Not always.

The alerts that in XDR strategy will generate for the security team can naturally be grouped into different categories of priorities.

We all adversaries operate in different phases of the kill chain.

An alert aligned with the first phase of the kill chain, which is reconnaissance, should be treated drastically different from an alert that's allied to one of the later phases, one of the more dangerous phases, like installation or command and control.

And there are times when malware might be successfully delivered via spear-phishing email or some other means, but its installation is blocked on the endpoint.

So if we don't have all of the logs at our disposal to see all aspects of the kill chain, we can't properly respond to anything.

Historically, security analysts would spend a lot of time in different security tools trying to figure out if the email was opened or if the attachment was successfully blocked from performing any actions.

Did the machine start behaving abnormally after an email was opened if we didn't say we blocked it?

There are a lot of questions we're trying to answer, and we need different log data sets to be able to answer those questions.

With XDR, an analysts is going to have access to all the data sets required to answer these questions from a single pane of glass directly inside of their security cockpit.

They'll have access to network logs, endpoint logs.

They'll have visibility into what's happening at all the layers of the organization.

And so, at the end of the day, XDR is going to categorize alerts such that security teams can prioritize them appropriately, respond accordingly, and have all of the necessary details to feed back into the threat intelligence loop to protect from future attacks.

And the very last piece I'm going to underline here is related to SOAR, or security orchestration, automation, and response.

A fully unlocked XDR strategy will enable analysts to initiate response actions inside of their single pane of glass.

So, for example, if a malicious file was found on an endpoint that was downloaded from an email, an analysts would be able to trigger an action to quarantine that file inside of all email inboxes across the organization.

So we're automating response actions that analysts would historically do manually that were very time-intensive.

Another example might be if a compromised credential was seen in the wild in a data dump or a data breach.

We could have a security playbook that could automatically initiate a password reset for all of the accounts that were tied to my organization right inside of Active Directory.

And so, the real goal here is that we automate as much as we can so that the analyst doesn't have to manually spend time doing these actions so that we can free up their time to do more proactive actions to protect the organization.

So now that we've explored the pillars of XDR let's summarize these into consolidated use cases that threat intelligence enables.

First, an XDR strategy includes consolidation of solutions that act as the primary mechanism for collecting data, aggregating data, monitoring for threats within those data set, detecting anomalous activity, and informing the incident response process.

Threat intelligence includes much of the detection logic that the systems that you've already invested in need to be effective.

And oftentimes, as part of the incident response process, an investigation has to naturally occur.

So we want to prioritize the analyst's efforts and prioritize the incident response process so that the analyst is addressing the highest priority alert first.

During an investigation, an analyst might use threat intelligence and really any threat intelligence that's available to them to aid in decision-making around how to best resolve the incident.

Ideally, these analysts would invest equal efforts using the available threat intelligence they have to prepositioned defenses and also be proactive at combating threat.

But we know that that's a high maturity play.

That's not always the case.

A lot of times, analysts are performing more reactive functions.

So threat intelligence can be used from both a research and proactive perspective, but also from an investigation and reactive perspective.

Lastly, there's hunting for threats.

I've recently read an article from a threat hunting company that's local to me.

And this company, they get called in a lot from their customers who are on retainer to assist those customers that suspect that they've been breached by an adversary or an adversary is already inside of their environment.

And this company published a finding stating that the average dwell time for adversaries in their customer's environment was 200 days.

So 200 days as average dwell time seems like a long time for an adversary to go undetected.

But there are two primary ways that XDR would aid in threat hunting efforts.

And so these include.

We'll take a look at the first way now.

The first would be looking for historic evidence of threat by performing retrospective analysis of log data.

So that would be taking intelligence that we're learning about now and looking inside of our logs six months ago or a year ago or two years ago to see if we could detect reconnaissance or initial intrusion, those early phases in the kill chain.

So if we do detect that activity, it means an adversary could be dwelling in our environment undetected.

That's the first use case.

The second would be using behavioral analysis to try to detect threat for which a signature or detection logic is not available.

So the threat is already in your environment.

They're not making a lot of noise.

Advanced persistent threats and nation-state threat actors are really good at not making a lot of noise once they're already in the environment, but they do need to perform actions from time to time to move laterally so that they maintain their persistence or even they might need to install or provide updates to some of the software that they've installed in your environment so that they maintain the access they require.

And when they do this, the assets that they're touching might start performing actions that are not consistent with their baseline.

That's how we can potentially detect them.

And so as a bonus, in addition to that retrospective hunting or behavioral analysis to detect those threats, we're getting a lot of other benefit from threat hunting in that we can feed a lot of the outputs of a threat hunt back into the threat intelligence loop and update our security tools so that we're protected from future adversaries and kind of raising the bar so that they have a more difficult time getting past the defenses we have in place.

We briefly discussed some of the benefits of threat intelligence and how it intersects with XDR.

For organizations considering going down this route, I have three general considerations to take into account.

First consideration going to be architecture scalability.

There are two key components we talked about during this presentation related to scalability.

One is going to be the volume of threat intelligence that is increasing exponentially year over year.

Organizations had one million indicators of compromise Today, they have half a billion indicators of compromise, and they have hundreds of thousands of research reports and malware reports, and adversary report.

So that volume of threat intelligence is going to require the right kind of technology to be able to interact with it successfully and slice and dice it and use it for different purposes.

The second is going to be the volume of network post or endpoint, and cloud data organizations are generating.

To be successful, we have to ensure that our XDR back in and the tools that we're using to store these logs can support not only today's data but tomorrow's data.

We know that data is increasing exponentially year over year.

Our log sources are getting bigger.

And as we think about that dwell time scenario, I've worked with some customers that have seen dwell times up to two years.

And so, to be able to detect that activity, we need logs that go back to the five years.

We need technology that can store 2 to five years of historic logs.

So we need to be able to scale to store tomorrow's exponentially larger data, but also store today's data and store the data of the previous years.

That's a big concern that organizations should consider when choosing the right technology components to plug into their XDR strategy.

Additionally, we've talked a little bit about behavior-based detection.

Behavior-based detection is enabled from artificial intelligence and machine learning.

And as these AI and machine learning models get stronger and more powerful, they're going to need more performance power.

We're going to need an architecture that can support these types of models.

So these are really some of the things that my customers are thinking about and that I'm thinking about as I consult with various organizations to help them determine what the proper products are to deploy within XDR strategy.

Next, we're going to talk about technology compatibility.

XDR components need to integrate smoothly, or in some cases, they need to integrate smoothly.

We gained so many efficiencies by leveraging XDR that it would be counterproductive to plug in components that don't play nicely together.

It's OK to sacrifice some features in exchange for compatibility.

And when thinking about these trade-offs, it really honestly just underlines the old argument for best of breed versus best of suite.

So do we select components that will meet our needs understanding that some integration is necessary, selecting the best of breed from every disparate category and investing some of our own initial Dev resources to integrate these products, or do we select components all from the same vendor knowing that there's a pros and cons trade-off?

So when considering the best of breed versus best of suite argument, there are a couple of things we can take into consideration.

I'll give some examples.

Best of breed might require a strong procurement and legal team.

There's potential to be negotiating with five to 10 different vendors and having them manage different contracts with different renewal cycles, different teams.

And that's a lot for some smaller organizations to manage.

With best of suite, we may only have to deal with one vendor, but maybe we need a stronger and more creative analyst and engineering team because that vendor isn't always going to be quick at prioritizing the features that my organization is asking for.

They're likely going to prioritize features that give them the most coverage across their customer base.

So if you're asking for a feature that no one else is asking for, good luck.

You may not see it for a while.

And so, these are some of the trade-offs we have to consider.

There isn't one right approach.

It's really going to come down to the size of your organization, the majority, and your organization's goals.

So really, the bottom line is that the path chosen it's really up to you.

It's just about making informed decisions.

And it's not always best to follow what your peers are doing.

So it's my pleasure to be able to speak to you today about threat intelligence and XDR strategy.

I'd be happy to take any questions now or discuss the topic further over email or on LinkedIn.

INTERVIEWER: All right.

Great.

Thank you for that informative presentation, Thomas.

As a reminder to our viewers, if you have a question for Thomas, just select the Q&A button at the bottom of the console.

If we're not able to answer your question during the show, you'll receive response to it within a few days.

It looks like we have some questions from the audience.

Let's begin our Q&A session.

Our first question is, what are the first steps my organization can take to determine the appropriate threat intelligence sources I should be collecting from?

THOMAS GRAVES: Great question.

This question comes up a lot during our threat intelligence engagements.

And oftentimes, the best way to determine which sources are most appropriate to collect from will be-- that's going to be driven by your internal policy.

A lot of mature organizations they have these things called priority intelligence requirements or PIRs.

So priority intelligence requirements are almost like a way to inform the threat intelligence team on what things they should be collecting against.

So, for example, you want to collect intelligence based on what assets you're trying to protect.

You're going to collect intelligence based on what your organization's most likely threats are.

Maybe you collect intelligence based on the log sources that you have available for detection.

So if you don't have endpoint logs available for detection, it wouldn't make sense to collect intelligence that was file hash related, for example.

And so, these are a lot of things that we assist our customers with early on during threat intelligence engagements to help them determine what their priorities should be, and we built the entire program around those priority intelligence requirements.

INTERVIEWER: All right.

Thank you for that.

The next question is, is there an XDR Gartner Magic Quadrant?

THOMAS GRAVES: Yeah.

So that question actually comes up a lot as well.

The short answer is no.

There's no an XDR Gartner Magic Quadrant yet.

I will say, though, a lot of the components of XDR like I mentioned earlier.

So a lot of vendors are starting to combine SIEM and ETR, or SIEM and SOAR, and they're starting to combine elements that already have a Magic Quadrant.

And so, when it comes to XDR, there doesn't exist a Magic Quadrant, but there is a Magic Quadrant for the individual components that make it up.

For threat intelligence platforms, there's no Gartner Magic Quadrant, but there's a company named Frost Radar that did release sort of a Magic Quadrant last year for threat intelligence platforms.

And so, I'd encourage you to go check out all of that material.

INTERVIEWER: All right.

Thank you for that.

Looks like we have time for one more question.

My organization doesn't prioritize alerts that are associated with the reconnaissance of the kill chain.

We ignore all the alerts associated with scanning and probing.

Any ideas for how we can start leveraging these lower priority alerts?

THOMAS GRAVES: Really good question.

This is actually a challenge that a lot of organizations face because there are competing requirements.

There's resource requirements.

There headcount requirements.

There's cost requirements.

There are a lot of challenges to triaging all of the alerts generated within the security operations center, and so I've seen some customers take the approach where they try to add more analysts to the team to be able to triage more alerts.

But I find that's not a cost-effective approach.

One of the approaches I've seen work very well is leveraging technology to automate as much as possible so that you can free up more of your analyst time to let the analysts do what they're being paid to do.

At a lot of organizations, analysts spend a lot of time writing automation logic and collecting data, things that technology can be purchased to do.

And so, if we can gain efficiencies, and I challenge you to look internally at ways you can gain efficiencies by leveraging technology to free up your analysts to triage more.

And so, I think that's probably something that you might consider to be able to inspect more alerts and tackle some of those lower priority alerts that are still valuable when trying to be proactive and defending your environment.

INTERVIEWER: All right.

Thank you for that.

Unfortunately, that's all the time we have for questions.

Thank you again to Thomas and Anomali for being with us today and sharing all that great information.

And, of course, thank you for tuning in.

We hope you enjoyed the presentation.