Accelerating Your Threat Intelligence Integrations: Detect ‘18 Presentation Series
After you have watched this Webinar, please feel free to contact us with any questions you may have at firstname.lastname@example.org.
So, a little bit about me.
Why am I up here, talking to you guys?
So I am a senior manager of Customer Operations for Eastern Federal, with Anomali.
Basically, I handle post-sales.
I was actually a former customer.
I used to work in [INAUDIBLE] for two years, and I went through the whole process of looking at all the tips, picking one out, having to deploy it, build your processes.
So I've been on the customer side, too, which makes my job a lot easier because I can usually relate to the problems.
As I mentioned, I've been with Anomali for two years, now.
It'll be two years, November 7.
I'm very excited.
And I'm a Splunk-certified architect, Level II.
Although apparently I have to be retested now-- thanks, Splunk.
[LAUGHTER] And, yeah, so, a little bit about what I've done since I've worked here.
So I've built filters for, conservatively, over 60 customers, at least.
It's a lot of fun.
Every customer has different use cases and different needs.
So I've built a wide variety of filters, to try and meet their needs case best.
And so what I found, while doing all these filters, was that a lot of customers understand the basics of filtering.
You know, because we talk about the same three fields all the time during the presales process.
Confidence, iType, severity.
And so that's what most customers build filters on, because that's your first introduction, but there are so many more fields and so many more ways that you can control how your data flows.
And we'll get into that a little later.
I'm also a Georgia Tech alum-- if there's any Yellow Jackets in the room.
Oh! Yay! A little fun fact.
So my sister Trish Cagliostro also works for Anomali.
And we live together and play softball.
We like to keep it in the family.
So a quick overview of our agenda for today.
So we're going to start with a quick introduction, talk a little bit about the business problem-- like, what's the issue we're trying to solve?
And then we'll go into some of the things that you should consider when defining your priorities because, if you don't know what your priorities are, it's pretty hard to accomplish them.
And then we'll talk about how Integrator can help pull this all together and make your lives a little easier.
And then we'll talk about all the tools in your tool bag.
There's a lot of things that you can do with Integrator and that you can do with your filters, to help get more out of the product.
And a lot of these tools are a little bit underutilized in our customer base.
And then, lastly, we'll do a filtering deep dive.
So we'll go through three common product lines-- a SIEM, a firewall, and an endpoint solution-- and how you would approach filtering for all three of those.
And there will be a sample filter on the screen.
It won't be very pretty, because it's complicated, but we'll walk through what it all means.
So, as Hugh mentioned in our keynote, for those of you that did make that, indicator counts are on the rise.
When Anomali first started, there was on the order of maybe 1 million active indicators.
And this was about four years ago.
Now, in 2018, we have close to 1 billion indicators historically.
Any given time, there can be hundreds of thousands, or hundreds of millions, active in your environment, depending on what feeds that you have enabled.
And so this creates a big data problem.
And so you have to look at indicators a little bit more analytically, because not all indicators are created equal.
Every indicator is going to serve a different purpose.
Depending on where it comes from, it's going to carry different weight with you.
Depending on how sure the source was that it's bad, you're going to care less or more about it.
And then also, there's different types of indicators.
So you have the operational indicators-- your IPs, domains, URLs, things you can shove into your tools and do automatic searches for.
And there's also, you know, the indicator types that don't fit that standard model, like things like HTTP referrers, user agents, things that you wouldn't necessarily always think to put into your SIEM to search for.
But those are things to take into consideration when filtering.
And so, when you have billions of indicators, it's impossible to manually review every single one-- unless you have a really big staff, in which case I'm sure everyone in the room is jealous of you.
And so, you have to find ways to look at the-- take a step back from the data, and be able to create these rules and priorities, and build from there.
So you can take a more automated approach to how you view your indicators.
And then the other business problem that we run into, with such a large data set, is that all of your integrations are going to have different thresholds for what they can handle.
A SIEM is going to be able to ingest more indicators and search against larger log sets.
By your firewall is probably going to take a lot less indicators and not be able to scale as well.
And so it's important to keep in mind what kind of integration you're pulling into, what the limitations are of the integration, but also what you're trying to accomplish.
So what does that tool do?
What indicators make sense to send to it?
You're probably not going to want to send a file hash over to a firewall-- not very useful-- but an IP list, very helpful.
But there are things that are going to be, your firewall's already doing, and there's no reason to push the IP.
So, like, scanning IPs, for example.
Everyone knows they're being scanned.
Everyone knows you're knocking on the door, nonstop.
If you've got a pretty good firewall, most of those connections are probably dropped.
There's not really anything you need to do with that.
So why send a scan IP to your firewall for automated blocking, when it's already being dropped?
So I want to make sure that we're not double-dipping and creating more work on our tools than we need to.
And so one of the things that I think a lot of customers struggle with is that, when threat intelligence isn't filtered well, you can end up creating a false positive machine for yourself.
And you get analyst overload.
You've got 1,000 alerts a day.
And there's no way that somebody can reasonably look at all those alerts.
And honestly they probably don't need to be looking at them.
It's a lot of noise.
And so what we want to do in this talk is talk about how you can help cut down on the noise, to make sure you're getting what you need, you're not missing anything, but you're not wasting time spinning cycles on things that require no action.
Right, There's a button.
So, before you can do any of that, you have to know what matters to your organization, first.
Every customer is going to have different priorities.
And if you don't have your priorities defined, there's no way to know if you're meeting your goals or achieving what you need to achieve.
And so I've listed out just a couple of things to think about when you're defining your priorities.
One of the things I think a lot of customers overlook is the size of their team.
You're not going to be able-- you know, if you have a smaller staff, you maybe want to tailor back to your expectations a little.
One person can only do so much.
And so it's important to keep that in mind, when you're setting your goals and setting your expectations early on.
Another thing-- I'm going to skip that "Identify"-- go right to Roles and Responsibilities.
So it's also important to know, what is your team supposed to do?
As a user of Treat Intel platform, you could be on a variety of teams.
When we first started, our primary use case was a SOCs analyst who was using our product.
Threat Intel teams weren't as common as their own entity.
But now, in certain organizations, we're starting to see that threat intelligence has its own team and its own functionalities and defined responsibilities.
And there may be overlap with the SOC.
And so it's important, from an early-on phase, to talk about what your team is supposed to be doing, what you're trying to accomplish, and what other teams may have a stake in this, and how can you work with them.
So if you are a pure play Threat Intel team, and you have a SOC, before you even deploy anything you should probably talk to them and say, hey, we've got this thing.
How can we use this together?
And that can help facilitate more advanced use cases, as well.
And the last point I want to make, here, is, identify your integration points early.
Figure out what tools you want to plug into, and prioritize them.
Most customers choose to go SIEM first, because it's got the highest visibility.
But it's important to always keep in mind, hey, what else can I be integrating with?
What kind of approach does my team want to take?
Are we going to be more proactive and do automated blocking, or do we want to be more reactive.
Are we more risk-adverse, where we're too worried about blocking things?
Then you'll want to more heavily leverage your SIEM.
Or maybe you want to do a firewall integration but put it in Alert mode instead of Block.
But the earlier you identify your integration points, the more effectively you can define your filters to make sure you're not double-dipping.
Moving on-- right place, right time.
So most customers now are choosing to integrate with more and more tools.
When we first started, typically customers would have one integration for their threat intel, and that was it.
You'd send everything to your SIEM, get all your alerts in one place, and then you'd react-- and hope for the best.
But customers are getting more and more advanced, and we're starting to see more integration points within a single customer.
So now it's pretty common to see not only a SIEM integration but a firewall integration and a next-gen endpoint integration and a proxy integration.
So, that way, you can get more coverage, to reduce the amount of incident response you have to do.
And the benefit to Integrator is that this makes it scalable and easy to manage.
For those of you in the room who don't know what Integrator is, Integrator is what we internal-- or, I guess, externally, too-- call our man-in-the-middle software.
And so Integrator sits in your environment, and what it does is, based on the filters that we're going to talk more about, will pull the indicators down from the cloud and then, depending on the integration you define, will format them correctly for that destination.
And it will either be a push or a pull to that integration.
So it helps you automate the movement of your indicators to your security solutions.
And so, within Integrator, you can have up to five different types of integrations off of one box.
So it makes it easier to manage.
It's one place to log in.
We put a nice GUI on it, about a year ago, so no more command-line configurations.
And it's a lot more intuitive and easier to use.
And so with Integrator you can use Integrator to push the indicators to places in your security environment where you can get actionable alerts-- have your automated blocking.
The whole point of threat intelligence is that it should make your job easier.
It should not make it harder.
It should not create hours and hours of more work and more alerts for you to dig through and mark as false positive.
It should help enhance your experience, to make it a little easier to identify, is this a real threat?
Do I need to care about this?
The idea is to make that a little easier.
CSO filtering is what ensures that the data is in the right place at the right time.
Now I don't have to look at this.
So the tools in your tool bag.
So, as I mentioned earlier, a lot of customers start off with filtering purely on confidence severity in iType.
And that is a great way to get started.
But it's-- you know, it's, when you first start riding the bike, it's like having the training wheels on.
Those are your three core ones that you'll start with.
And a sample filter that you'll typically see early on is something as simple as confidence greater than or equal to 70.
And a lot of times that is a great starting point.
Sometimes you don't know in your environment how much noise you're going to create.
For a smaller shop, confidence greater than or equal to 70 may only create one or two alerts a day.
But, for someone larger, like Citibank, that would be very noisy and not a lot of fun for their SOC team, I can tell you that, for sure.
These filters are not intended to be "set it and forget it." That's something I haven't mentioned yet.
They are intended to be like a living thing that, as you respond to alerts, and you see what makes noise in your environment or what you think you're missing, you tune the filter to meet your use case.
Every customer is going to be different.
So that's why some choose to start-- Customers have one or two approaches, when they first start out with threat intelligence.
They either go, send me everything and we'll tune it down-- so, confidence greater than 70.
Or sometimes they do the opposite.
Only give me 100% confidence, high severity, and we'll add more from there.
Both approaches are good, but both require you to constantly be rereviewing the alerts you're getting, what your filter is doing for you, and how do you get more out of it-- how do you get better are ROI?
So what customers mature into, a lot of the times-- the first step seems to be tags.
And tags are a great way to control how data moves in your environment.
In my next slide, I'll go into that a little bit more in depth.
One of the fields I really like is Last Modified.
There are some indicators that, when they come in, they live forever, or they live for a very long time, or they get reactivated all the time.
And so it's hard to easily identify stale intelligence.
Using the Last Modified timestamp as opposed to when it was created enables you to keep the indicators that are being updated and people are still looking into and still seeing in the wild and researching.
Where Created isn't always as telling-- it can tell you how new it is.
So it's great if you're looking for, just give me the brand-new indicators.
But Last Modified gives you a little bit different view.
Feed ID is something a lot of our customers choose to filter on.
So, basically saying, like, oh, CrowdStrike.
I love CrowdStrike.
I want all of their intelligence in my SIEM, no matter what.
And then you could use the feed ID to help ensure that that happens.
And one of the fields that I really like that I don't think very many customers, if any, are really using is the Country and certain indicators.
So everyone knows that, for their organization, there are going to be countries that are going to be targeting them, right, or certain countries they identify as higher risk.
And so, by using the Country field within filtering, you know, you can say, like, OK, for IPs I want to be very restrictive-- unless the IP comes from this country, because I know they're bad guys and they don't like us.
And you can use that to make sure that indicators for-- Russia, for example, is one that comes up with a lot of US customers-- all the indicators from Russia make it into your integration points.
And so there's a variety of ways that you can use these different fields, in order to get what fits your organization's needs best.
Tag and bag.
So tagging is a great way to control how your data moves through your environment.
And I think it's very important, because, most of the time, your filter is going to cover most of what you want there.
But, every now and then, you'll be doing a review.
Maybe you read a threat bulletin.
You see associated intelligence, and you're like, oh, I don't care that we're only 10% sure it's bad.
I know that, if this is in there, it's going to be a big problem for me.
I want it in Splunk.
And so, in order to manually do that, you would have to clone the indicator, make sure you set it to meet your filter requirements, and then hope you don't change your filter requirements or [LAUGHS] forget about it.
So that's not exactly ideal-- too many steps, too many clicks.
If it takes me more than three clicks to do something, I'm over it.
And so we can use filtering, though, to control how the data-- or, sorry, tagging-- to control how the data moves.
And so, for every Add, I always recommend adding a Remove tag.
So for Splunk, for example, we typically recommend going with Company Name, Product, Action.
So Anomali, Splunk, remove.
Anomali, Splunk, Add.
For a firewall, you might want to do Anomali, Palo Alto, blacklist-- whitelist.
You don't have to stick with Add/Remove.
You can use whatever verbiage you think is the most clear for you for the integration point.
And the cool thing that we released about four months ago is preferred tags.
So, prior to preferred tags, you would have to remember exactly how you spelled everything and, oh, did I use dashes or underscores?
I don't know.
But we released this great feature called "preferred tags" that allows an org admin to define the tags that they want their team to use.
Now, they are not restricted to using that only, but when they start typing a tag and it starts matching on the right letters it will recommend the preferred tag first.
So that's a good way to also make sure that your data stays consistent across your organization.
Company, products, Splunk-- sorry-- lost my place.
Yeah! So, yeah.
So your filter is going to cover most of what you want, but there's always going to be one-offs and things you want to add and remove, and tags are a great way to accomplish that.
And so I know this naming convention seems pretty rigid, and there's a reason why I recommend this naming convention.
More and more customers are using tags to control their data, and a lot of teams are named similar things.
So, if you were to go by your team name-- right?
Like, CTI, Cyber Threat Intel-- dash, product, dash, action, then you run the risk of having a collision with another team in another organization doing the same thing.
And you get data in there that you don't necessarily want.
Another thing to note is that your company name, if it's only three letters-- you know, try and expand it.
Because three letters can sometimes match things that you don't necessarily want-- three random letters in, like, a URL, for example, in a tag.
That was a big problem.
I used to work at a company called ICE, the parent company of NICE.
And so we would have to spell out Intercontinental Exchange, even though it was annoying and I always typed it wrong, because otherwise we would have collisions with I-C-E being in all sorts of things.
So, Filtering on Integrator.
So, before we go into the deep dive, there's some things I wanted to mention.
There's a couple of not necessarily gotchas but things to be aware of.
So on Integrator there is some implied logic.
So you never need to say "status equals active" or "type doesn't equal string." Integrator already knows that.
And the reason why I call this out is because, when you put these types of filter logic into Integrator, it can cause unexpected behavior.
For example, putting "status equals active" overrides the built-in logic that removes indicators as they go false positive or inactive.
So you end up with indicators that live forever-- which-- not ideal.
The other thing is, you cannot-- so we have a concept of source versus destination filters.
And so any Integrator box will only have one source filter, but it can have many destination filters.
The source filter controls what comes down to the Integrator box.
The destination filter controls, from there, what goes to your integrations.
So if it's not going to be included by your source filter, it's never going to make it to your integrations.
And so there's one little gotcha with source filters.
You cannot use time fields-- so, no Last Created, no Modified Date-- because it messes with the database where all the indicators are stored.
So if you want to use those two fields, you do have to put them in your destination filters-- just as a heads-up.
Now, I've listed out our four primary security categories of tools that we support.
And that would be SIEM, Proxy, Firewall, and Next Gen Endpoint.
With the release of SDK, this is with our integration SDK being released, this is obviously going to expand rather rapidly.
But this is the four primary types of tools we integrate with today.
I was going to save this question, but you could just [?
?] So, the SDK, is it going to be mainly on the Integrator, itself?
Or are you going to be able to apply it separately?
You know, when you're integrating [INAUDIBLE] confined with some of the same limitations on Integrator, like you were saying, like [?
five-- ?] That's a good question.
I am not sure yet.
I haven't seen the official documentation on it.
My understanding is that the idea is for the SDK-- to allow you to use the SDK on Integrator, so you won't have to set up up a separate box for it.
But I think they might be separate things.
I'll let you know, Dwayne.
And so I like questions.
How we doing, so far?
Is anyone very-- any questions?
I noticed that one context [INAUDIBLE] we usually use.
So I tested both, and the same result.
So I don't know if that's intended.
The greater than and equal and the greater than minus is the same thing.
I didn't know that! Very cool.
I didn't know that, either, but-- Yeah?
A little fun fact for you guys.
[INAUDIBLE] when you mentioned the modified time greater or equal to 30 days, but the official documentation says greater [?
and ?] minus 30 days.
Huh! Fun-- But "minus" makes more sense to me-- It does, logically.
Because, like, greater than or equal to 365 days, you wouldn't think, would be the last year.
You would think would be-- yeah.
So that's good to know.
[INAUDIBLE] just wanted to ask if it's intended, but I guess it's new to you-- Yeah, it's new to me, too.
So I have to say that.
So our documentation, I have to say, is kept very well up to date.
And it's important to note that, when you're trying a filter on a field, you always want to check the Integrator documentation to make sure that it's a supported filtering field.
There are some fields that we can filter on in the cloud that we can't use on Integrator.
So that's a good point to keep in mind.
So now we're going to get into the fun stuff.
So SIEM filters are my-- I'm going to be honest-- my favorite.
I'm a Splunk-certified architect.
It's, like, my bread and butter.
So this just makes me really excited.
But typically-- so, like, when you're integrating with your SIEM, you're going for automated alerting.
And the next two we'll talk about will be automated blocking and automated detection.
So, with automated alerting-- and the SIEMs are the ones that can handle the most number of indicators, out of our current existing integrations.
And, depending on how beefy your deployment is, and which type of SIEM we're integrating with, you can typically pull in somewhere between 500,000 indicators and 2 million.
like, the iffy point.
And so, with SIEMs, it also takes the widest number of types of indicators.
You've got all of your five observable types-- IPs, domains, URLs, email, and MD5.
But just because they can bring it in doesn't always mean you should.
So a lot of customers send file hashes.
But if the only log source you have with file hashes is from your antivirus, your antivirus is already going to-- when it sends a file hash, typically, it already knows that it's suspicious or bad.
So it's already creating alert for your team to investigate.
And so, while having threat intelligence could help validate that this alert is, like, a real thing, it can sometimes create extra noise and extra workload on Splunk, for minimal value, if any.
Now, if you guys are sending a ton of endpoint logs that have, like, all file hashes identified, absolutely very useful.
But if it's only coming from your antivirus solution, it may not make sense for you.
And emails are the same way.
Not all customers store their email logs in their SIEM.
In fact, many don't at all.
And so there is no point in sending email indicators if you don't have any logs to match on.
And so I've put a sample filter in the bottom of this, just to make it a little easier to explain what I'm talking about when I say "advanced filtering." So here is a perfect example of how we would format our filter to use the tags to move the data.
And so the way this works is you're saying, at first, like, OK, the tag says remove from Splunk?
Don't go any further.
And then we go into our next line of logic, which is talking about our filter that's going to apply to the broad indicators, the ones that we're not manually reviewing.
this ?] [?
is, ?] you know, pretty good start.
In our example, we're saying, there's no email, no file hash logs, we're looking at confidence greater than or equal to 70-- which is a pretty standard place to start.
We're removing low-severity indicators, because most of the time there's not anything you can do even when you do get a match on those.
We're removing scan IPs, because you probably already know you're getting scanned a million times a day.
You don't need another flashing light telling you, hey, look at me.
And then we're looking only at indicators that have been updated in the last year.
And so that's our base filter of what's going to go to Splunk.
And that's a pretty good base filter, for many customers.
And then, at the end, we have-- or, if I say send it to Splunk, I don't care about any of this-- send it anyways.
Oh-- a little too fast.
Questions, on this?
Or ideas, of what else would you add for your environment?
Trusted circles-- great point.
We will be able to filter on trusted circles with Integrator 6.5.2, which I think was released yesterday officially.
And so that's a new feature for us.
We're very excited about that.
Previously, you could only filter on feed ID or source.
You couldn't filter on trusted circle ID.
And the big benefit to that is, with trusted circles, like, NH-ISAC-- now rebranded to just H-ISAC-- they share all their indicators in our platform through their trusted circle.
So filtering for it before was a little tricky, because we'd have to try and match on a tag or something like that.
But now we'll be able to do things like explicitly list the trusted-circle ID.
So that's a great way to additionally filter.
I personally filter on things like, is it coming from AIS [INAUDIBLE]??
Is it coming from FS-ISAC?
Because we put [?
in ?] FS-ISAC into our stuff, because going through those emails, forget it.
And, besides that, it's so chatty.
[LAUGH] Anybody who has FS-ISAC, you know they're chatty.
So another thing-- [INTERPOSING VOICES] I used to have the same thing, when I was on the customer side, the [INAUDIBLE] got you going to a small inbox.
But another thing you could filter on, too, would be if there's a particular actor that you know is targeting your company.
Most of the time, indicators associated with that actor are going to be tagged in a similar way.
So maybe you would want to add in here, maybe, [?
n ?] tags contains APT28 or Fancy Bear, if you know that you are a target for them.
Is there any limits to the depth of our performance [INAUDIBLE]??
Like, we started filtering a-- like, each one of these were a different source or stream?
So there is a character limit, on filters.
So you can be as crazy as you want until you hit the character limit.
And I think it's something like 400 characters?
So you can get, I think-- what was mine?
Basically an entire slide of text [?
for ?] filtering would fit in Integrator.
But there are some reasonable limitations around that.
I was playing with a filter, and I wondered if it's possible that I stitched two [INAUDIBLE] together [INAUDIBLE].
It works in the advanced search.
But when it comes to the Integrator, when I refresh I don't see the number increasing.
[INAUDIBLE] So it could have to do with your source filter.
So, if you have in your source filter, for example, confidence greater than or equal to 70, but then in your destination filter you put confidence greater than or equal to 60-- Oh, I do, like, 80 and 90.
Well, we'll have to take a look at it.
[INAUDIBLE] But, yeah, so that brings me to another good point.
So I mentioned, earlier, source filters versus destination filters.
Another reason why, when you're setting up your tags, you want to use a naming convention of company first is so, in your source filter, you can say "or tag starts with," "or tag contains company name." And so, that way, when you go and build your destination filters for each of your integration points, you will there specify product action.
And so it just makes it a little bit easier to manage.
You don't have to explicitly list out all of your preferred tags.
The SIEM is where you're going to see the most noise, [?
probably ?] your highest false-positive rate.
And that's just the nature of what SIEMs do.
They're a huge aggregation point for your logs, so they're going to have the most status.
They're probably going to have the most false positives.
So, moving on to firewalls.
So firewalls [LAUGHS] have a significantly smaller amount of indicators they can take.
One of our firewall integrations, the limit is 600.
Palo Alto can go all the way up to 10,000.
What we focus on with firewall filters is automated blocking, most commonly.
And so, with automated blocking, you probably want to be a little bit more restrictive on your filtering, a little bit more conservative, because you don't want to accidentally take down, you know, network access for your employees-- probably wouldn't be too happy about that.
So, yeah, so you want to be a little bit more restrictive in the way that you filter.
Additionally, you have to get that indicator count down a lot further.
We were talking, earlier, we said you could have hundreds of millions of active indicators.
If you have hundreds of millions, how do you pick-- even if you just have millions-- how do you pick the 10,000 that you care the most about?
And how do you build your filter in such a way that you can still get value out of this?
Well, the good thing about firewalls is they're probably already doing some of the work for you.
So maybe you guys have it configured where you do geo blocking.
So you automatically drop traffic to Russia-- sorry, Russia's just going to be the go-to for this talk.
Maybe you automatically drop traffic to Russia because you don't do business there at all.
And so, as a security precaution, you agreed that you were going to do that.
So maybe you want to remove all indicators from your blocklist from your tip that are identified as being associated with Russia.
You already have a security measure in place to block that traffic.
Why take away from the other indicators you can be getting value out of instead?
So that's one thing to consider, right, geo blocking.
A lot of the integrations can also take not just IPs but domains and URLs.
And some companies, on their firewall, choose to do top-level domain blocking.
And so, if you're already blocking certain top-level domains, again, don't send indicators with those domains.
Try and make sure that you tailor your data set to enhance your controls, not to double-dip.
And so, underneath, we've got a little sample filter.
Again, we have the same logic of, if it has this contains, we want the allow one.
Just drop it, and you're good.
Keep going on.
Next we have higher confidence, confidence greater than or equal to 80.
And now, this time, we're not just removing low-severity indicators but we're also removing medium-severity indicators.
And also, if you notice, our TS modified date is significantly lower.
Last time we were with the SIEM we were looking at indicators modified in the last year.
Now we've dropped it down to last month, because we want to be more restrictive.
Questions, so far?
Is anyone in the room doing automated blocking on their firewall now?
One, two, three-- OK.
[INAUDIBLE] Good! OK.
So, moving on to endpoint filters.
So endpoint filters allow you to do automated detection-- so, the third option in our automation queue.
And so endpoint integrations can typically handle a similar load to firewalls, around on what endpoint solution you have.
Generally speaking, your traditional antivirus doesn't-- most don't have the capabilities to ingest indicators.
Although I think we'll see that change in the short term.
But your next-gen endpoint solutions, such as Tanium, CrowdStrike, Carbon Black, all of those types of tools are already built to handle things like indicators of compromise.
And so these can handle-- very similar, but slightly different to, the firewall-- IP and domain, but they don't do URLs.
But they do do MD5s.
And so, while most of the endpoint integrations can do IPs and domains, I find that you're going to get the most value out of your MD5.
Odds are, if it's going to an IP or domain, it's going to go through your firewall, which will create an alert in your SIEM.
Where the next-gen endpoint is really the place where you have the most visibility into your file hashes.
And you don't have that kind of visibility in most of your other tools, so I find it's what I like to focus on.
And so here we have a sample filter.
And this one's the messiest one yet.
But there's a reason.
So file hashes are one of the noisiest indicator sources that we have.
There's just so many of them.
And the thing with file hashes is, one, if malware is halfway decent it's going to be polymorphic.
You're not going to see the same file hash twice.
So that's one problem that we have.
The other problem, too, is that these file hashes turn over so quickly.
The third problem is that, if it's a real commodity malware, then within 7 to 14 days your antivirus is going to be picking it up anyways.
Why put the extra pressure on your endpoints?
So that logic is reflected in our filter.
So we're going for the higher confidence, confidence greater than or equal to 90.
Again, no low-severity or medium-severity indicator.
We want high and very high only, basically saying, give me the worst of the worst.
And then we have our first filter-- I should back this up a bit.
So here we have it broken up into two mines.
The first filter is applying to the IPs and domains indicators.
The second filter is applying to the file hashes.
And I broke it up in this way so, that way, you can be more granular with the value for the file hashes.
I probably could've been a little more efficient, grouped the confidence and severities together, because they're both the same, but if you wanted to change them it'd be easy to do here.
And so, if you notice, we've also got a regex in here for our value.
So, even though type says "md5," it really means hash.
Any type of file hash can be stored in what we call "MD5 type," which is very misleading.
I can see the bug eyes, over there.
I'm like, yeah, that's how it works-- fun fact.
And so, by adding this value regex, we are then enforcing that we only want MD5 values.
Good thing about file hash is they all have standard formats.
And so you can build regexes to identify what you want most typically.
Yeah! So you're saying, if you have [INAUDIBLE],, you would have to [?
add ?] the regex value for that-- Yep.
--and call it "md5"?
Yeah, so the type would-- your filter would still say type=md5-- by the way, one of my biggest pet peeves.
But [LAUGHS] it would still say type=md5, and then you can build the regex using value, tilde, and then regex, to filter it to [INAUDIBLE] 256.
And that's something that's really important.
Because your endpoint, your next-gen endpoint, may only be able to search for MD5s.
And you only get to send 500.
Do you really want to be accidentally sending half indicators that you can't use?
No, because that's not useful.
So it's important to note.
Any other questions on this?
Can I use a regular expression to match against any field or any tag or anything, in there?
or is it just strictly for the hash type?
So it's-- you would have to look at the documentation, to confirm this.
I know, at a minimum, it's supported for the value field.
And value is basically where the indicator is stored.
So, if you said value, tilde, and then put an IP CIDR [?
block ?] in there, then it would try and search all value types, but it would only match on IP types-- unless you told it to only look at type IP, I guess.
What type of regex does it support?
Oh, it's in our documentation.
It's a really standard one that regex.com helps me test.
I know that.
[LAUGHS] I don't remember exactly the versioning, though.
I think it's the one that-- yeah, no, I don't remember.
I'm going to be honest.
OK, moving on.
So we're up to my wrap-up slide.
I wanted to leave a lot of time for questions, because I find that it's a little bit more helpful for the technical talks to not just listen to me talk about you for forever but be able to ask questions that you're interested in.
Before we do that, I'm just going to do a quick wrap-up on what we've talked about today.
So your first step-- define your priorities.
You can't know what you need to do if you haven't defined it.
So you want to make sure you know, what's your team's job, what are you trying to accomplish, and how are you going to measure your success?
And so how you measure your success is something we haven't really talked about, I guess.
So that's something I'd like to touch on briefly.
For your organization, you may have to report metrics up to your management.
And so it's important, when you're first building the product and deploying everything, that you understand what the expectation is from you from your management and that you let your customer-success person know so we can help build the defined processes and make sure your integrations are going to meet that-- and not only meet it but show that you meet it.
So, if you need to show that, you know, you're having a lot of blocks in your environment, maybe you do want to send scan IPs to your SIEM.
Maybe you want to build some advanced logic into your SIEM, so you ignore it but so the metrics are there.
And so those are things to also keep in mind when defining your priorities.
The other thing is, just be reasonable.
If you're a team of two people, don't compare yourself to the Citis and the Morgan Stanleys.
Citi has a 40-person intel analyst team.
That doesn't include their SOC, their engineering team.
And there's also a separate team that manages all the relationships with the feeds for them.
They have 40 pure play analysts.
So, if you're a shop of two people, of course you're not going to have the same capabilities as someone who has all of those resources.
And so just keep in mind that you've got to do the best with what you've got.
You're already here, so you're doing better than most companies.
You acknowledge that threat intelligence is something that you should be paying attention to.
And so, at a minimum, give yourselves a pat on the back for that.
You guys are going the right way.
And the next point I want to drive home is, use all the tools in your tool bag.
Really take a look at what you're trying to accomplish with your integrations and what they're already doing for you.
Get the most out of your threat intelligence with the minimal amount of work.
Next, I want tag and bag indicators.
It's a great way to track the flow of indicators through your environment-- just makes it a little easier on everyone.
And then, yeah, consider the capabilities of the integration when filtering, and then let Integrator do the work.
Integrator is there to make your life easier-- give you a single pane of glass to run all your integrations from.
It's pretty useful, very intuitive.
The help docs are great.
And so, yeah, let Integrator do the work for you.
And so, with that, I'm to open up the floor to questions.
[INTERPOSING VOICES] [INAUDIBLE] What advice, what suggestions, might you have, to make sure that-- especially as I'm rewriting everything next week, for the new SDK-- would make it as useful as possible when it gets to the other end?
Be accurate with how you bring the data in.
So, a lot of times, indicators just get thrown into the malware iType or, I guess, threat category because they don't know where else to put them.
And that's fine.
But if you know that something's associated with bot-IP activity or scanning, or it's just a spam IP that you don't want to see anymore, put that into the iType.
That really helps customers be able to trust the data more, too.
Because when a customer gets an alert on an indicator, and it says it's malware but it's very obviously just advertising, then the customers start to lose faith in the providers.
I would also recommend using tags, as much as you can, to try and describe what the data is.
It's a great way to give a glimpse into what the indicator is used for.
So, if you know who the actor is, not only associating it with the actor profile but apply the actor name that you guys standardize as a tag.
And I feel like Nicole might have some feedback for you, too.
Just be careful with tagging when you're doing actors, because if you tag it to your specific actor and it turns out not to be that actor, you can actually make your customers very angry.
Particularly for people who have been in the threat-intel space for quite a while, and let's say that you think that it's Fancy Bear, and it's not actually Fancy Bear, they're going to come back to you and be like, why did you-- Why.
[INTERPOSING VOICES] I think another thing, too, with the [?
new ?] [?
feed's ?] SDK, I think this will probably be a lot easier.
But, as you find out that indicators are not relevant, whether they need to be flipped to inactive because they're not being used or because it's a true false positive, going back and changing the status of the indicator as you learn about that kind of information, customers really do appreciate.
And that, as a feed provider, by doing that you're cutting down the false-positive rate in your customers' integrations, which gives them higher confidence when they see a match to your data.
Customers in the room-- anything else to add?
Now's your time.
What about other questions?
There's no way I explained everything that well.
We'll talk to you on Monday.
[LAUGHTER] [LAUGHS] I get that.
In case you guys haven't noticed, I have a couple customers in the room, so I could call them out by name.
Is there any [?
feature ?] to match the file hashes [INAUDIBLE] CVEs?
Or is that something that [INAUDIBLE] providers have to do?
Tag file hashes with CVEs?
This file hash is known to exploit this vulnerability.
So some of the vendors are already doing that.
And what Anomali has done, to help improve our threat model associations, is that, when feed providers or open-source intel tags an indicator with a particular CVE, we not only have the tag in the UI but we also have the autoassociation to the CVE under the threat models.
And so, when you scroll to the bottom and you look at the Associations tab, you then have that single pane of glass that I've been trying to find.
I hate having to open up seven different portals to do my research.
But what associations allows you to do is, along the bottom, you can see, OK, what write-ups are there about this indicator?
What vulnerabilities does it typically use to exploit?
Are there any TTPs that are typically used with this indicator?
So all that information is in the portal in a single pane of glass, so you don't have to click to seven different things.
But I would say, like, for that kind of stuff, too, push on your feed vendors.
And push on us, right?
We have our own feed.
We have our open-source intel that we curate.
When you guys find things that you don't like or that you find frustrating or difficult to use, or, oh, it would be so much cooler if you took this one more step, tell us! We may not have thought of it.
Or we may not have realized that it was important to our customers and might have overlooked it.
Customer feedback is really important to us, and it's something we take very seriously at Anomali.
And if you ever don't know who to give your feedback to, you can always email email@example.com.
Our support team is phenomenal and very responsive.
That's our manager of support, back there.
[LAUGHTER] Any other questions?
So, when you implement filters, based on [INAUDIBLE],, so let's say [INAUDIBLE] Yeah, so you can filter by feed ID.
And each feed in our app store has a feed ID.
And some of them-- well, some of them may have trusted-circle IDs, but we can now filter on those, too.
So you can filter based on where the intelligence is coming from.
My other question is that, when it comes to the rating, you have x amount that is open-source [?
feed ?] [INAUDIBLE].
So the [?
rating ?] [INAUDIBLE] Confidence score.
Is it [INAUDIBLE] all these three?
That is a great question.
And the simple answer is no, it's not normalized across all three.
And that's because it depends on where the intelligence comes from.
And that's how it's going to be scored.
So, for example, with a lot of our premium vendors they have their own score that they create themselves, and so we'll use that score in the portal.
Some of our premium vendors choose to have a static score.
They ask us, on ingestion we want all of our indicators at 85 confidence.
Open source tends to go through our internal scoring algorithm, called Macula-- Machine Learning Algorithm-- great password.
But what it does is it takes into account 20 to 30 different factors, depending on what kind of indicator it is.
And it'll take into account certain things like, has this been reported by other sources?
Is it a newly registered domain?
Where is it geographically located?
Is it from a high-risk ISN, for example?
And it will take this logic and then generate a score, from that.
And that's-- fun fact-- anything scored confidence 15 and below is automatically marked as a false positive.
And our logic behind that is, if you're not even 15% sure that this is a real thing, how bad could it possibly be?
So, if you're ever inputting your own intelligence, make sure you go over 15.
Otherwise, it automatically goes to false positive.
Does that answer the question?
If you're looking for specifics on a particular feed, how the confidence is generated, we can always give you that, too.
[INAUDIBLE] are you guys generating that confidence level, or are they?
Because that's one of the ones I have the the most problems with-- Yeah.
[INTERPOSING VOICES] No, no, it's OK.
FS-ISAC-- [INAUDIBLE] It does [INAUDIBLE].
[INAUDIBLE] Are they bringing in the confidence level, or are you calculating it?
I think we calculate it but give it a minimum floor.
So, like, every [?
indicator ?] [INAUDIBLE] ISAC, I think, has at least a minimum confidence of 40, so it doesn't automatically flip to false positive-- or something like that.
But it varies from customer to customer.
Because FS-ISAC is set up as a private feed for each individual customer.
So, if you're not happy with the scores you're getting now, we can take a look at it, Dwayne, and maybe make some changes to the configuration.
Same question, [INAUDIBLE].
[LAUGHS] NCFTA, I think we-- I think we use their scoring?
NCFTA is a little different than FS-ISAC, in terms of the scoring, because FS-ISAC is set up per customer basis.
So the configuration can vary amongst customers, where NCFTA is coming in the same way for everyone.
I don't know, offhand-- I'll shoot you an email, Brent.
Oh, I don't have to do I when I get out of here?
Great! Get a nice little weekend break Kidding.
[LAUGHTER] [LAUGHS] Other questions?
Is this helpful?
Now, it's Friday, on day two of the conference, so I think I'm going to let you guys go a little early, unless we have more questions.
If you want to talk one-on-one, I'll be around and we can do that.
Thanks, everyone, for coming!