Azure Sentinel Webinar | Threat Intelligence in Action with Anomali

RIJUTA KAPOOR: Our webinar.

Just quickly, a recap on the presenters.

The first couple of minutes will be presented by me.

I'm Rijuta Kapoor, a senior VM on the Azure Sentinel Threat Intelligence Team, followed by me, there will be a couple of discussions led by Ashwin, from the Anomali Team, and a quick demo by David, from the Anomali Team, as well.

So setting the stage, right here, for anybody who is not well-versed with what cyber threat intelligence is.

So cyber threat intelligence can be categorized into a couple of buckets, or categories.

How I like to do this is I generally split them into three different categories.

Like, tactical threat intelligence, operational threat intelligence, and strategic threat intelligence.

So talking about each of them, one at a time.

Picking up tactical threat intelligence, tactical threat intelligence is anything, like, indicators or observed data.

So, for example, you have a list of IPs, or UROs, or MD5 hashes, that you are aware that they are malicious, those type of things come under tactical threat intelligence.

The second bucket is operational threat intelligence.

This one is a little more complex, and has richer contextual information.

These can vary all the way from the kind of patterns that an attack is following, the kind of tools and infrastructure it's putting into place, and utilizing to have the attack carried out.

Things like tools, techniques, and procedures, which are the TTPs, are something that fall under operational threat intelligence.

And the third bucket, which is a strategic threat intelligence, this is mostly around the kind of actors that are running the attack, the kind of campaigns they're running the attack against, the kind of verticals, whether it be financial, or health care, or IT verticals, that they are targeting.

Things like those.

And the last that comes under this, is also reports which are published about a certain threat actor, their intentions, or a certain kind of attack, pattern, or campaign that they are leading from here, that falls under strategic threat intelligence.

Talking about threat intelligence and how it's used in Azure Sentinel.

As a lot of you might have heard, Azure Sentinel is a cloud-native thing, and threat intelligence is one of those things that's sprinkled all across this institution.

And let's see how it's done.

The first area is data connectors.

These are basically rules by which you can import your data.

So in Sentinel, we have two data connectors dedicated for threat intelligence.

One is the threat intelligence TAXII connector, which is essentially used to connect to TAXII 2.0, or 2.1 endpoint.

And the second one, is the threat intelligence platforms connector.

And this one is a proprietary Microsoft solution which is used to develop integrations with most of the TIP products, like Anomali threat stream, threat connect, and so forth.

So that's about how you get the data into the product.

Once you get the data into the product you definitely want to use all your threat intelligence data to get insights into any kind of attacks that are targeted towards your organization.

And for that, you need analytic rules which basically, match your threat intelligence data with your logs, maybe it be firewall logs, or proxy logs, et cetera.

Once these analytics are enabled, they generate incidents which your SOC team members, and analysts can triage and prevent any kind of attack that's currently targeted towards your organization, and as part of that, you tend to use investigations.

You want to see how your different entities that are part of a particular incident, how are they linked to each other.

You run hunting queries, you can run Notebooks, which are Jupyter Notebooks, and are based on Mystic Fi, so you can use all of these where threat intelligence is spread, as well.

Then once you do all of this, we also offer some dashboards, which are also called workboats in Azure Sentinel, and this gives you like an overall picture of your threat intelligence.

How your TI is performing, how many indicators you're importing, maybe, things like, you are importing TI from 10 different sources, what is the kind of overlap of indicators that you see between those feeds, what is the uniqueness of a feed, et cetera.

And the last area, that I've mentioned here, is playbooks.

These are things which are generally used for enrichment kind of scenarios, et cetera, where you don't want to import your complete threat intelligence data into Sentinel, but you want to definitely enrich your instance with TI data that, maybe sitting in a third party tool, et cetera, so for that you can use playbooks, which are essentially logic app connectors.

So going forward, and talking a little deep into how do you import your intelligence data into Sentinel.

And how I like to categorize this, into two different buckets.

The first one, we talked about earlier, results of data connectors.

And the second bucket is playbooks.

And why I put them in two different buckets is, because of the kind of use case they cater to.

The first one, is data connectors.

These are platforms that you use to import TI into Azure Sentinel as a product.

So you bring in your threat intelligence from different sources into the product.

For that, we have two data connectors.

The first one, is Microsoft Threat Intelligence Platforms Connector.

This is based on a proprietary Microsoft API, which is called the Graph Security API.

And how the data flow works, here, is from your TIP products, like Anomali, Threat Stream, or Threat Connect, et cetera.

You can push your TI into the Graph API, you call the Graph API, and from the Graph API it makes into Azure Sentinel to any workspaces that have this data connector enabled.

And the second data connector that we have, is the Threat Intelligence TAXII connector.

This, you can assume this to be, essentially, a TAXII client that we have built out to connect to any TAXII server or TAXII endpoint.

Azure Sentinel supports TAXII 2.0 and 2.1 versions, so you can connect to any TAXII 2.0 or 2.1 endpoint, using this.

And through these data connectors, either of them, you basically, bring in your threat intelligence into the product, and then you can use it for analytics, investigation, and so forth.

The second bucket is called playbooks, and how is this utilized?

Most of the use cases we see for playbooks is enrichment kind of scenarios wherein, you actually don't want to import your TI, maybe, because of the size of the data-set, or you just want to, in this case, what you do is, you develop a logic app playbook that goes ahead, and queries a third party API and enriches your incidents.

So you still get a lot of value out of this, because you see enrichment if a particular incident is created.

So moving forward, and going into the major discussion for today, which is, how Anomali has built out various integrations with Azure Sentinel.

So Anomali is in a unique space and has developed multiple integrations with Azure Sentinel.

And these can be divided into two categories, again.

One, is where you can import your threat intelligence.

So talking about this one, first, there are two options by which you can get TI from Anomali.

The first one, is the Threat Stream integration.

Threat Stream, for people who are not aware of what Threat Stream is, it is the TIP product that is built out by Anomali.

It's the flagship product, so that is definitely one integration.

So it's a TIP platform.

So for this you use the Threat Intelligence Platforms data connector, which is based on the Microsoft Graph API.

We will take a deep dive into this in a couple of slides.

So going forward.

The second integration that we're going to talk about today, is the Anomali LIMO integration.

So LIMO are a free set of TAXII servers that are set-up by Anomali, which offer a great amount of TI.

So for this integration, you can leverage the threat intelligence TAXII data connector of Sentinel.

The second integration, the second bucket that I've talked about here, is Anomali Match.

So Anomali Match is a very unique one, in itself, because in this case, what you do is, you take out your raw logs from Sentinel, import it into Anomali Match, as a product, use it to match against a huge repository of TI that Anomali has within Anomali Match.

And once you do that, the third step, which is also a major one, you can bring in your alerts back into Azure Sentinel and use it for purposes of investigation and for triage, and that makes your organization SOC team, helps them, because they don't have to log-in to 10 different portals, and look at different investigations, et cetera.

They can bring back all these alerts, which are great from Anomali Match, back into Sentinel and have that same pane of glass where they look at all their incidents, so they don't have to look and learn multiple portals in this case.

So taking a deep dive into each of these three integrations, and coming to the first one, which is the Threat Stream Integration.

So talking about this one, Threat Stream is the TIP product that's built out by Anomali.

And to integrate with Anomali Threat Stream, and to bring in TI from Anomali Threat Stream into Azure Sentinel, you can use the Threat Intelligence Platforms connector.

For this, Anomali actually has built out an integrator to submit indicators to the Graph API, and from there it makes it to Azure Sentinel.

Just one thing I want to discuss about this would be, this data connector, or the graph APIs, is on a per-tenant basis.

And this works great for MMSPs, who want to push TI to multiple workspaces, actually.

So how it works is, once you push your TI indicators to Graph API, it is on a per-tenant basis, and it will make into every single workspace under that tenant that has this data connector enabled.

So maybe, you have 10 workspaces under your tenant, and if you enable four workspaces with this data connector, once you push the TI into Graph API, it will make to all the four workspaces.

So this is definitely one of those integrations by which you can bring in TI into Azure Sentinel, and put it to use in Sentinel itself.

So taking the second step of the second integration, which is the Anomali LIMO integration.

So as I had mentioned earlier, Anomali LIMO is a set of free TAXII servers that has multiple collections on it.

And I generally use this analogy about how TAXII servers and collections work.

So assume TAXII server is something like a folder by a name and inside that you have files.

Similarly, inside a TAXII server, you have collections which host IOCs, like how a file in a folder holds text data or any data that you have included.

So Anomali does offer a bunch of collections under that free TAXII 2.0 server.

I have mentioned the API route URL, right here, for the TAXII server, and a list of the collections on the right side, which is right here.

These span all the way from Phish Tank, to COVID 19 feeds to emerging threat feeds et cetera.

To connect to this, you can use the Azure Sentinel TAXII data connector, which is essentially a TAXII client that can connect to any 2.0 or 2.1 endpoint.

Very simple to configure.

You're just going to Sentinel.

You go ahead, and go to this data connector in the data connectors gallery, you will have to put in certain fields like, the API route URL, which is mentioned here.

You will have to put in the collection IDs, which are mentioned, whichever you wanted, for example, you want to look at the emerging threat feeds, in that case, my collection ID would be 68.

And you can put in the credentials, some of the other parameters like falling frequency, which is basically how often you want to connect to this TAXII server.

And that's it.

After you put in a bunch of these fields, you're good to go.

Your TI data will start importing into Azure Sentinel.

So this is the second set of integrations that Anomali offers, actually.

Now that you've built out all these integrations, your data is making into Sentinel, you want to definitely, look at your TI.

And for that, Sentinel has built a very rich UI experience where without writing any KQL queries, which is KQL to queries language queries, you can actually just look at all your TI, you can create new TI, you can tag it, search on it, start on it, and filter on it.

And how this works, is this shows up under the Threat Management Manual Sentinel, when you log-in, into Sentinel, you will see a threat, this is your view, under threat management, there is a Threat Intelligence Preview area, which you see, right here.

Here you can see all the TI that you've imported into Sentinel.

You can search for any keywords, you can apply filters, for example, you want to look at all your TI you've brought in from Anomali, emerging threats, which was one of the TAXII servers that we set up, or you want to look at only IP indicators, or maybe, you want to look at everything that's confident, things like that, is something you can do in this view.

One area, other, that I want to specifically talk about, is tagging here.

So you can tag all your TI in the search experience.

A lot of the customers I talked to often they use this feature.

They have nomenclatures set that they want to put certain information about the indicators that they found while they were investigating a certain incident, maybe, looking back at a certain incident ID, et cetera.

So, and that's a free-form text, so you can definitely leverage the tagging functionality.

So this is a great experience that you can use in order to look at your TI without even writing KQL queries.

So moving forward, where is all this threat intelligence saved into?

So as a lot of you might know, Azure Sentinel is based off of log analytics.

So as part of this, we also store all your threat intelligence data that you import from any single source, whether it be from, say, a TIP product, like Anomali, Threat Stream, or a TAXII server like Anomali, LIMO, or any of these other sources that you want to import from.

They all make into a central log analytics table, which is called the Threat Intelligence Indicators Table.

So you going into logs, under Azure Sentinel, you will see an area called Threat Intelligence Indicators.

You can write Kusto queries for this.

Basically, look at TI, this is a very rich schema, which shows you things like, what's the source of your TI, what's the confidence score, what is the threat type of the TI, what's the description, the actual indicator itself, which is in this case, you see, it's a URL, so you look at URL when it is an IP it'll go to the network IP field.

So it's a pretty rich schema that we offer.

And you can see all your logs, run queries on top of that.

Moving forward, now that you've brought in all the TI, you've looked at your TI, you've played around with it, the next step is putting your TI to use.

For which, you definitely want to power your analytics with all the threat intelligence data.

And for this, what Sentinel has done is we provide a set of 26 out-of-the-box analytic rules, that come to you as you install Sentinel, once you have Sentinel set-up, you will see these rules.

You really don't have to do anything.

And what these rules do, they basically, match your threat intelligence data with different types of log data.

So for example, they match, you want to match your domain indicators with, say, your Azure activity logs.

You can do that, or all your IP indicators with your office activity logs, or your Palo Alto logs, you can do all of this.

So all these, if you want to look up these analytic rules, they all show up in the analytics gallery, and you just need to search for a keyword TI map, because all these 26 out-of-the-box rules start from this TI map keyword.

So for example, if you take this one, these match all the domain indicators that you bring into Sentinel with your DNS logs.

So definitely encourage everybody to, who is using Sentinal, or want to use Sentinal, to take the advantage of all these analytic rules.

These are KQL based rules, so you can do any configuration yourself, you can add any types of word clauses, if you want to do certain whitelisting, you can do that, as well, et cetera.

So definitely look into all these analytic rules.

Now that you've used these analytic rules, they're generating incidents that your SOC can triage through, et cetera, one other area that I want to specifically talk about is workbooks.

And workbooks are kind of like dashboards.

They give you a higher up idea of how your TI is performing into Sentinel.

And this is basically, starting from very basic charts, like, how many URL indicators are you bringing in, how many IPs, what are the kind of sources that you're bringing TI from, to all the way to things super important charts, like, how many alerts and incidents is each of these indicators creating, how many incidents are being generated, you can create charts for that.

And the best part with these workbooks is, these are completely customizable.

They are all based off of the threat intelligence log analytics table, that I showed you a couple of slides back.

So you can create your view charts, you can add charts, delete existing charts.

So basically, it's a blank slate.

We do provide a template, but you can completely customize it as per your requirements.

So this is one other area that we talk about.

So now this was everything what happens after you bring in your TI into Azure Centinal, and you use it for analytics investigation, et cetera.

So that was all 1 bucket.

The second bucket, and the second category, is the Anomali Match Integration.

And this is a very unique one, in itself.

And how this works, is in the Anomali Match Integration it's basically, a bi-directional flow of data.

And how this works, is you export your raw logs from Sentinal into Anomali Match.

For this you have to register an application in Azure Active Directory, which is AAD, in order to have access to the Log Analytics Workspace where Sentinel is based off.

Then inside Anomali Match, you use something called a universal link, to set-up and get configured Log sources to get in data into Anomali Match.

You will see a demo that Dave, from Anomali, will give us in a couple of minutes, and learn more about this.

Once you export your logs and bring it into Anomali Match, you can use all these logs within Anomali Match to generate alerts by matching them against the massive repository of TI that Anomali has.

After you match all this TI in Anomali with the raw logs that you brought from Sentinel, you've generated alerts.

Obviously, for most of the SOC analysts, they would love to go ahead and bring this back, these alerts back into Sentinel, because they don't want to log into different portals, and do triage in 10 different UIs and 10 different products, right?

So Anomali Match Integration has definitely catered to that requirement.

And with this, you can bring in all the alerts that you've generated inside Match back into Sentinel for any investigation purposes.

And you can generate incidents that your team can go back and triage through, et cetera.

So this brings an end-to-end experience for you, because you can take data out, use all the benefits of the Anomali TI that Match has, and then bring them back into the same single pane of glass, which is Azure Sentinel to do investigation and hunting, and all of the other steps that follow.

With that, I'll pass off to Ashwin to go ahead, and talk about certain use cases that Anomali Match has seen with a Azure Sentinel.

After you, Ashwin.

ASHWIN RADHAKRISHAN: Thank you, very much.

I won't take too much time, before I kick it over to Dave to get into the fun demo here, but I did want to underscore three main capabilities, and some of the use cases that are derived from those capabilities.

Anomali Match was purpose built to give users the ability to leverage all of their relevant threat intelligence, and for Anomali, and our platform, gone are the days of just looking at individual indicators.

And we're really looking to move higher on that pyramid of pain to get into some of the more operational and strategic threat intelligence matches that we discussed, earlier.

And to that end, one of the key features of the Match Platform, is the ability to do actor-based matching, as well as campaign, or even TTP-based matching.

One of the common use cases that we see, is really, around breaking down the silos between the CTI team and the SOC team.

So rather than just kicking over specific indicators, the CTI team is able to kick over an entire profile, like, based on a specific hypothesis, for instance.

And have the SOC team match on that basis.

So that's a very powerful use case that is really empowered between Azure Sentinal and Anomoli Match.

And of course, one of the other key features, is the ability for Anomali Match to conduct retrospective matching and analysis.

So for instance, when a breach occurs, the investigation might only yield a report or indicators, 12 to 18 months in the future, and it's very hard in any type of product to go back and say, hey, was I breached 12 to 18 months ago?

Those logs might be in cold storage, but Match accomplishes this very uniquely, in the sense, that it allows folks to parse out the metadata of the log that is relevant to indicator and actor profile matching, for instance.

And then determine whether or not you were breached at that period of time after the investigation is conducted.

And want to also include that this is also empowered in real time, as well.

So it's not just query-based.

You'll have a set of alerts.

Something that, of course, Dave will go through in a moment here.

And then the third that's very important for our joint Azure Sentinal customers, is of course, the ability to funnel the alerts and matches created in Anomali Match back into Azure Sentinel.

And like was explained earlier, the reality is, folks don't want more security consoles.

They of course, want a unified way to triage and respond to their alerts.

And by leveraging the match detection engine within Azure Sentinel, users are definitely able to do that.

Next slide.

Perfect.

And we've actually gotten a lot of traction and joint customers between Anomali Match and the overall product suite, here at Anomali, and Azure Sentinal.

But one unique example, that I wanted to explain before I kick it over to Dave for the demo, is a bit of a case study.

A large telecommunications company in the UK are using it for two different use cases.

The first is, of course for their internal security operations, but again, like was explained previously, also as part of their MMSP offering to empower very highly performing and very expensive threat intelligence matching with regards to their Azure Sentinal logs that they're funneling in.

So without further ado, I'm going to go ahead and hand it off to Dave to walk through the platform.

RIJUTA KAPOOR: I'm quickly going to hand it off to Dave.

Are you able to share, Dave?

Perfect.

DAVID EMPRINGHAM: Can you see my screen?

I cannot share.

I was able to see, just for a second, a moment ago.

DAVID EMPRINGHAM: OK.

There we go.

I think we're all set, now.

Yes.

DAVID EMPRINGHAM: Thank you, Ashwin and Rijuta, for laying such a great foundational overview.

And as Ashwin said, Match is uniquely positioned to really augment, not only traditional SIMs, but other platforms, like Azure Sentinel, we all know that it is a big data game when it comes to, both tactically and strategical use, mass amounts of threat intelligence.

Well in a Anomali Match here, we can see the number of indicators and the number of environmental events that we've downloaded over the last seven days.

We have a lot of different preset time ranges, which allow us to see matches of, not just individual indicators of compromise, but also finished threat model objects Now you may ask, how do we get the Azure Sentinel data in?

It's as simple as leveraging the built in universal link at which we can open our additional log source, and see Azure Sentinel where we can add, obviously, the data source name, the tenant ID, as Rijuta mentioned earlier, application ID, and workspaces law, as well as our application secret, which is part of that configuration.

When that's happening, we then begin to evaluate and correlate against all the threat model and threat intelligence that we are bringing in.

Now the other thing I can do, is I can do the retrospective and go back a year's worth of data.

Now you can see, I've downloaded over 106 million indicators, this is exponentially more than most platforms can handle in real time, as well as 2.42 billion events.

Now this is still just a fraction of the intelligence that we have available in Threat Stream.

And you can see, that my active indicators that have a confidence level of a minimum 75, I still have almost half a billion indicators available for me to leverage.

But the real power comes in when we start to look at finished intelligence.

And as Ashwin mentioned, actor profiles.

Who have been communicating with and their infrastructure.

And you can see here, that all of these actor profiles were updated in the last, either minutes or hours ago, and automatically downloaded to Anomali Match.

I'm going to dig into one here that's called Lazarus Group.

And as this resolves, you're going to see when the threat model was first created, when it was last updated and downloaded, and the number of observables that had been associated with this actor profile.

Not just that, but in that time range we scan through and came across one particular match.

Now this really is finding the needle in the haystack.

We can drill into this, but we saw an internal IP address speaking to that external malicious indicator compromised.

It was classified as a C2IP, confidence of 87, and severity is high, but when not drill in it's not part of an asset model that I have loaded in here, but we can certainly change that.

And here's the raw logs.

So we collected it from Websense, may also have come through Azure Sentinel, we saw that the event action was dropped, but it was still an internal asset speaking outbound.

And, so at this point, we could do a number of things.

Even creating an alert automatically, which we will get to in a few minutes, or an investigation within Threat Stream.

But more so when I change the actual time range of data that I want to look at, and go back to that full year's worth of data, and I scroll down, I can start to see heat maps of where I'm matching, and what may be pervasive, and patterns.

Again it's a big data game and when you start to use Finish Threat Intelligence against all your environmental logs, you will see patterns emerge of when these attacks are happening, and when you're beginning to match up certain particular indicator types.

We have other dashboards, including Match Analysis, which allows customers to really start to see spikes and matches over time, as well as matches by feed names, maybe they're bringing in some commercial vendors, or they're generating their own intelligence.

I want to see the amount of matches and victims that that intelligence is also providing us.

You'll also see here, that we've got the top 20 impacted hosts by risk score.

Now within Anomali Match, we can actually build out asset models using vulnerability scanners, such as Qualys or Tenable, we can create them using a template.

But really, it's going to start to show us our match history and timeline with these assets.

Now, the risk score is calculated based on the criticality of the asset itself and the confidence and severity of the indicators that it's been communicating with.

Again, line of sight to what's actually happening in your environment.

And a lot of times, these indicators are also associated, or attributed to, the asset or the actor profiles, or other threat bulletins that were automatically downloaded as Threat Stream collects them.

Now let's take a look, quickly, at how we build out that asset model.

And you will see that every pane or panel within Anomali Match we can slice and dice, we can find, we can search, and we can create and save those saved searches.

But you can see here, if I wanted to create or update my asset model, I'm literally selecting my scanner, obviously my authentication profile to download that, my template, or I can enter them manually.

But once that asset model is in, again, it's giving us line of sight to those assets, and those most impacted hosts within the environment.

But what if you just want to hunt?

This is where the activity pane comes in.

You can see, I'm searching for everything.

I'm only going back seven days, but again, let's try that one year's worth of time range.

We can start to see pockets of matching, the overall accounts.

I can actually filter by severity of the indicator itself, the confidence level, I can go as far as to say I only want to see successful outbound matches, or from a feed source, or from, actually, an event log source.

So if I change this to event dot action equals allowed, this means the communication was allowed through our security controls, and we're actually seeing the matching on the malicious indicators and who the indicator was provided, to the classification confidence, and severity.

But more so, Anomali Match has, actually, got some fuzzy logic built into it.

So we're feeding it firewall data, or proxy data, or DNS data, this fuzzy logic actually looks at domain generation from malware families.

Now if those who aren't familiar with the DGA, or Domain Generated Algorithm, it's a technique that malware uses to at scale, at high volume, generate these weird looking domains, and it's a way for them to propagate their malware.

Now the time to live in these domains can be very short.

But as you have internal hosts communicating with them, Match can evaluate the domain that it's attempting to communicate with, and it does but by looking at the vowels, the constants, the numeric digits, how often that pattern happens, or replicates itself, and the length of domain.

Think of that as a fingerprint.

And it will score the probability that this domain actually being malicious on a 0 to 1.

And it will categorize, based on that fingerprint, here's the malware families that this is most indicative of being a part of.

If you don't agree with that, you can at any given time mark this is a false positive.

So it will never be presented to you in any of the dashboards again.

So that's activity.

Again, it's a matter of finding your data and matches at any given point, but what if you don't have time for eyes on glass?

Let's get into the configuration of alerts.

And this is where we can do a lot of things to let a Anomoli Match do the heavy lifting for us.

Here's an example.

Let's walk through this alert that I preconfigured.

I want to see all of my internal assets who are communicating with indicators that may have a vulnerability associated with them.

So obviously, going to give it a name.

Here's my source, is it just threat indicator matches, or do I want to match against finished threat intelligence objects such as campaigns, or TTPs, or vulnerabilities.

For me, it's typically just a threat indicator match, and I'll explain why in a second.

We can do a simple match.

We can do frequency detection, spike detection, or I can build out a look up list that either include or exclude, so consider that black or whitelist evaluation, and then tags.

Now indicators are not always associated with the CVEs that were downloading automatically from Mitre into Threat Stream, but I can, actually, look for a particular tag.

I want to make sure that I can evaluate every indicator that has been tagged with this particular CVE as part of its behavior that has been seen by others.

Now I can also choose a time range.

This is continuous, meaning it's going to evaluate from here, moving forward, based on all the environmental logs that we collect from Azure Sentinel, or I can choose a custom time range, and this is a combination of presets, just like all the other dashboards, or I can do a relative, or I can do a date range.

Which means, if I have a specific window of time, let's say, back 240 days ago, for three weeks, I can put those presets in, and I can set Anomali Match to go out, and hunt, and find any communication with the criteria that I've specified.

Now I had mentioned before, about searches, like, what we were doing in the activity pane.

I can save any of those searches in a criteria and just use them here.

So they are a building block, think of LEGO, throughout Anomali Match, that I can reuse.

It's going to save me a lot of time to set these up.

I can build out an expansive alert list again, to let Anomali Match to do the heavy lifting.

But it's at that point, what do I want to do when the criteria is matched?

And you can see here, that obviously, I'm going to send an email, I can do a lot of variable substitution with that email.

I'm going to send it to myself, I may send it to the SOC team.

I can also list out these events within our incidents or alerts dashboards.

But here's what I can do, as far as involving Azure Sentinel.

I can add it to an investigation, I can execute a script, but I can also forward a syslog in the format that Rijuta mentioned in her presentation to where I'm going to send it over to Azure Sentinel, over address, and port that data connector, which is going to collect it, for additional log analytics, part of that investigation , make it part of the referential data set for Fusion, whatever the case may be it could be even workflows or playbooks.

But it's that bi-directional activity, both from Azure Sentinel into Anomali Match, that allows you to use an incredible amount of threat intelligence, as well as environmental log data.

I want to be respectful of everyone's time, and give us a little bit of time for Q&A.

So with that, I think I'll turn it back over to Rijuta and Ashwin.

RIJUTA KAPOOR: Great.

So I'm, quickly, going to share my screen just for the last slide.

Can you folks see my slide, by any chance?

Yes I see the demo slide, yep.

RIJUTA KAPOOR: OK, great.

So with that, we come to the end of the presentations and the demo.

There are some of the very great, very important links that you can use to understand more, both about Sentinel and Anomali Match, and Threat Stream integrations.

You can look at the tech community blog, there's a blog that I had authored about the Anomali Match integration with Azure Sentinel.

It gives you a step-by-step process of how to set up this integration, et cetera.

There are a couple of videos that are published by Anomali about how Match is to be used, what are the kind of use cases.

You can look up Anomali Match on the Azure Marketplace listing, as well.

And then there's a data sheet that Anomali has published about Match, as well, that you can read about on the Anomali website.

There are links to each of these in the presentation.

So please feel free to check these out.