Cyber Threat Intelligence Starts Here: Detect ‘19 Series

AJ NASH: Good morning, everybody.

How are we doing?

Yeah?

I know it's probably early for a lot of you.

It's sure early for me, I'll tell you that right now.

I don't normally wake up till about 9:00.

So thanks for being here.

I hope you had some breakfast.

Hope you're enjoyed the conference.

My name's AJ Nash.

I'm the director of cyber intelligence strategy for Anomali.

So I'm going to talk to you today a little bit about building intelligence programs at a pretty high level.

Two notes-- one, I apologize if I sniffle a little bit.

Apparently somebody at this conference gave me a small cold that's hitting me today.

So hopefully, that won't be an issue.

Let me give you a little bit about my background before I jump into this, though.

No, stay in the front.

Before I jump into this, I'll let you know who I am and where I came from and why I'm up here today.

So as I said, I'm the director of strategy for Anomali now.

My background, though, is mostly government.

So about 18 years or so in the government space, I suppose.

A little over nine years-- US Air Force.

I don't know, nine or so as a defense contractor-- all traditional intelligence.

So I did counterterrorism, counterinsurgency, countering trafficking in persons, chased war criminals for a couple of years.

I spent all five years countering threats in cyberspace.

Most of my work was at the executive level.

So, writing papers for secretary of state, secretary of defense, White House, that kind of stuff-- Congress.

I was originally traditionally an intelligence linguist.

I was a pretty lousy linguist, but I was a decent analyst, apparently.

So I got out of the Intelligence community about 4 and 1/2 years ago, now-- somewhere in that area.

Went to a large US bank.

I don't drop names a lot about where I worked, but they're very interested in what's in your wallet.

It's kind of creepy.

So I was there for about a year.

I helped them build their intelligence program, essentially, from scratch.

So I understand the financial industry a bit.

Definitely regulated industries.

We talked about how to build intelligence products, how to build a team, collections, how to communicate with leadership, et cetera.

I did that for, like I said, about a year.

Then I went to a large tech company.

Then spent about three years there.

The first two, I spent on the commercial side.

So I helped dozens of customers either build programs or mature their programs.

Talked about how to consume intelligence, how to make sense of it, how to communicate to leadership.

And then in the last year, that company actually went inside.

And I built the program again from scratch.

Turns out everything I was telling the world to do, we weren't actually doing particularly well.

So I went in and built that program.

Went from ideation to IOC-- initial operating capacity--in about nine months.

So built the whole timeline for that, and all the collections and procurements and everything goes with that-- hiring people, et cetera.

And then I was recruited to come over to Anomali.

We're going to help a lot of people do stuff.

So essentially, what it comes down to is I either build programs or I help people build programs based on my experience.

So I'm really excited to be here to talk to you guys.

This presentation, I'll tell you a couple of things.

I talk pretty quickly, normally.

So feel free to slow me down at any time and interrupt me with questions.

If you don't, we'll get to the end.

And nobody will have spoken.

And I'll just have to ask you about so much stuff done now-- no, I'm just kidding.

Yeah.

AUDIENCE: What language did you speak?

A.J.

NASH: Oh, I very poorly spoke Serbian and Croatian.

That's remarkably useful.

Comes in handy all the time, as you can imagine.

Constantly asked things in Serbian.

I would have preferred Spanish.

It would've come in a lot more handy.

But yeah, so I served the Balkan war.

It was kind of a big deal at the time.

So Serbian and Croatian, which means I understand a little bit of Russian just enough to get in trouble, and apparently communicate in Moscow when I was there.

Otherwise, pretty useless.

So let's jump into the slides and see where this takes us.

First point, anybody who works in intelligence right now, the private sector, has probably seen some of this.

This is what Jim asks us all the time.

Who's after us?

What are they trying to accomplish?

How are we going to get ready for it?

Have we been compromised?

If so, how bad is it and what are we going to do about it?

So these are the constant questions you get from your CSO or your CIO or whoever is responsible for these kinds of problems.

And if we're going to be honest, this is pretty much the typical answer, which is, I don't know.

Most people aren't honest.

They kind hem and haw, and they say, we'll look into it.

But the honest truth is most of us don't know the answers to this, and this is where intelligence comes in.

You're not going to get those answers from just looking through Splunk or from some of our other tools that are designed to keep us safe.

But to understand some of these things, you've got to go down the intelligence path.

So that sort of sets the stage on where we're trying to go, speaking of setting this stage.

Here's what we're trying to solve for.

Now, I could've listed but the three primary ones that I thought were important were fear-- this is a huge problem in industry.

Our leadership [INAUDIBLE],, and they should be.

So fear is a big problem.

Nobody wants to be on the news.

Nobody wants to be Anthem, nobody wants to be Target, Capital One recently-- I was long gone, thankfully-- in those situations.

So our leadership's very afraid.

That's unfortunate.

Fear is a good motivator.

That's nice for budget, but fear also makes people panic about a lot of things.

So we have to help control that.

We're solving for data overload I think anybody who works in a SOC probably understands how that works.

So we've passed the point where we don't have things to work with.

We have plenty of data to work with.

All of our tools are filling us with data.

We've got plenty of intelligence sources we can go to.

We've got open source, we got news, we've got fake news, we've got social media.

We're flooded.

That's not our problem.

It's about making sense of all of that right.

So data overload is something we have to deal with on a regular basis.

And then proactivity-- so reactive state is where most organizations still live, and that's where a lot of tools are going to take you.

Well, something happened.

Now we've got to go back, figure out what it was and how to fix it.

That's not that's not really where we want to be, though.

From an intelligence standpoint, the goal is to try to become proactive.

So think of it this way.

On a timeline-- in the kinetic world, we used to talked about staying left of the boom.

So [INAUDIBLE] being left to right, or in your case, left to right.

The boom was a bomb or a terrorist attack.

So you want to be left of the boom.

If you're right of the boom on that timeline, it's battle damage assessment.

It's blood, it's guts, it's picking up bodies.

It's a really bad time.

So you want to left of the boom.

The only way to do that is proactively using intelligence.

In the cyber world, it's not too different.

There's a little less gore on the right side of the boom, but it is 24-hour operations.

It's the CSO chewing on your neck.

It's hourly bridge calls.

It's a bad way to live your life.

It's really unpleasant.

So the goal is to stay left of the boom, and that's where intelligence comes in, where we can be proactive.

So we need to be in a position where we can understand our adversaries, we understand things before they hit the wire, and we can be prepared.

That's what we're trying to solve for.

And then who are we serving?

Essentially, there's three basic audience.

You've got your tactical, technical audience.

That's your hands on keyboard.

That's your network defenders.

That's your SOC analyst.

You've got your operational audience.

Generally, that's the management level, folks have to decide who do we hire, where do we put them, how are we going to set up our resources going forward, and how we're going to set up organizations.

And then you've got your strategic audience.

So that's your executives, your leadership, your five-year plans for the corporation as a whole.

So these all are different levels that require different inputs.

Your CSO generally-- not always, but your CSO doesn't often [INAUDIBLE] the IOCs.

They don't care about hashes and indicators.

Conversely, your hands on keyboard, your folks in the SOC try to get work [INAUDIBLE],, they're not really concerned about the five-year plan of China, necessarily.

Maybe they should be, but they're probably too busy in their actual work.

So let's make sure our outputs match what our customers are looking for.

So who's familiar with this slide or some version of it?

Generally speaking-- well, you don't count because you're familiar because of me.

So generally speaking, if you're familiar with a slide, it's because you probably have an intel background.

So this is from Joint Pub 2-0.

Most things I talk about come out of US or Western intelligence or US doctrine.

I'm not here to invent intelligence.

I'm not here to sell you a new thing.

The goal here is to bring the best of breed from the government space to the private sector and just educate folks on what that is.

So Joint Pub 2-0 talks about [INAUDIBLE] data, information, intelligence, among other things.

It's a large board.

But the point here is we have too many organizations that are living in data, and we have too many vendors happy to sell you data and call it intelligence.

So a good way of understanding this slide from a data standpoint-- if I have a large feed of IOCs, a large feed of IPs, URLs, for instance, that's data.

Now, there's companies selling that is intelligence right now.

It's not.

It's data.

It's [INAUDIBLE].

It's incredibly important.

I'm not saying anything on here doesn't matter.

Data is the blocks of everything we're going to do here.

But if I sell that to you as intelligence, that's the equivalent of selling you a bunch of bricks and telling you I sold you a house.

You can make one of those bricks, but you certainly have no place to live when I sell them to you.

Information-- that's that same list of IPs and URLs with some sort of context, a threat score of some kind.

Really important, gets you further down the track so you understand what's going on.

That's still not intelligence yet.

And that's where the bulk of the industry is right now, in my opinion.

Now, intelligence is those IPs and URLs.

We've got some sort of threat score, some sort of context.

But we also understand what adversaries have been associated, when they were associated.

When was this infrastructure safe, when was it dangerous, when was it safe again?

What are the tactics, techniques, and procedures we should be looking for?

What are the behaviors related?

That's intelligence.

That's that complete holistic picture that we're trying to get to.

Now, when you talk about executive-level intelligence, you go a step further.

You try to put a little more context on it.

You try to explain to leadership where we think it's going to go.

That's finished intelligence production.

That's a little bit different discussion here.

But this is just talk about the difference between data, information, and intelligence.

If you guys want to sit down, we've got seats.

I don't mind.

You can walk through.

It's cool.

So how do we define intelligence?

Well, this is always a challenge as well.

There isn't one, the intelligence community has five or six different definitions based on what agency you're in.

Everybody likes their own brand.

They're all remarkably similar.

And the private sector doesn't have a definition of intelligence.

So I cobbled together something here.

This is really just based off of the intelligence community definitions.

Took out some government-only type verbiage that just isn't very useful.

I don't recommend trying to memorize it.

What it really comes down to is intelligence is the product of a process, and the purpose of intelligence is to give leadership what they need to make informed decisions.

Now, one caveat that goes with that, for any of you who work on the intelligence teams-- sometimes you're going to give them good information.

You're going to give them good intelligence, and they're not going to make the decision you think they should make.

You get used to that.

So our job is to give them what they need to make informed decisions.

Leadership has other inputs.

They've got risk to consider, they've got budget to consider, they've got politics to consider.

Whether it's in the government space with the generals or the politicians downtown or whether it's in the private sector, as an Intel analyst or as an Intel producer, you sort of have to pull yourself back from that and just accept that that's not my role.

I simply provide them what they need to make the best possible decision, and then they own that decision from there.

Otherwise, you'll be very frustrate when you're working intelligence, which have been several times, and anybody I know who's worked in intelligence has been.

So let's talk about categories of intelligence.

Now, before anyway snipes at me, you probably could throw a couple more up here.

I've pretty much got it down to three categories that I live with.

I think most I work with feel the same way.

If you have a fourth, feel free to tell me.

I'm always happy to learn something new.

But to me, there's basically three categories.

There's cybercrime, there's espionage, and there's hacktivism.

So when we talk about these, cybercrime to me is money for money's sake.

It's motivated by money.

I want to do business email compromise.

I want to trick you into sending me money to pay a bill that doesn't exist, for instance.

I want to do ATM jackpotting.

My goal is to get cash and get out.

As yesterday one of the keynotes somebody mentioned-- I believe was Admiral Rogers-- criminals, they're in a hurry.

They want to get in, they want to get out, they don't want to get caught.

That's their top motive.

That's their biggest concern.

I think he's exactly right.

Who's going to argue with a four-star, right?

So when you talk about espionage, generally it's data.

So this gets a little challenging.

I'm going to fill out some of the examples here, because I'm thinking about IP and PII, for instance.

Now, you can make an argument that that's crime, and you're right a lot of times.

People do steal IP and sell it.

People do steal personal identified information and sell it.

So I'm not suggesting that can't cross over into crime.

Here's the way I look at it, though.

The minute there is a data breach, I start with the assumption it's nation state until proven otherwise.

And here's why.

If I'm a nation state and I want to compromise-- let's see.

Let's say I want to compromise the organization that handles all the security clearances for a government.

And I'm also going to compromise a giant health care organization that happens to have really strong connections with the military of that government.

Then I also want to compromise a giant credit reporting agency that holds all the credit reports for all the people in that country, which includes everybody that works for that government.

I can take those three pieces of data, those three giant datasets, put them together, take some time and effort.

They use people or a lot of machines, and I can get a pretty good list of people I want to target from a human collection standpoint.

I know people who have top secrets security clearances, who have credit issues or family with credit issues, or they have health issues or family with health issues.

Those are three massive breaches that most would assume are crime, but very may very well be nation state.

Now, as it turns out in this case, none of this is hypothetical.

All three of those happened.

They all happened in the US, and none of that data ever made it to the deeper dark [?

web ?] where it was sold to anybody.

So that's my point.

When something is breached, until I see it sold, I can assume it's a nation state.

If it makes it to the deep and dark web, it's more likely to be criminal activity.

Now, again, as Admiral Rogers said, one of the challenges we have is North Korea, who's become the only state that we've been able to see that actually use nation state purposes to sell things and make money.

They're doing it more in the cyber crime side in terms of trying to-- SWIFT and things of that nature or political stuff like Sony.

But we can't rule out the possibility that some of the poorer nations are going to use these tactics for criminal benefit but still be nation state actors.

So attribution is always challenging.

I think most people in the room know that, and this is just one of those challenges.

Then the last piece is hacktivism.

Anonymous is probably the most common, well-known.

New World hackers, there's a few others.

Five years ago, I would have said this was going to be the scourge of the universe for us.

We were all worried about DDoS attacks.

We were all worried about website defacement, anonymous-- you had operation xyz, whatever it was going to be.

This has become more of a nuisance than anything.

Anonymous has become somewhat predictable.

They've actually sort of developed an ethos within their group.

You have a fair understanding what's coming, and they give you a good heads up now.

So this is annoying.

It's difficult, it's a pain, but it isn't a serious concern compared to the other two right now.

We have counter DDoS capabilities with just a little bit of intelligence.

And frankly, even without great intelligence, just monitoring their Twitter accounts, in this case, can be really, really useful and help you see what's coming.

Operationalizing intelligence, big slide, lot of words.

I've actually spent a whole hour on the slide before.

I won't today, I promise.

So there's a big snapshot of all the thought process I had when I was time building programs.

Even though it's built left to right, I actually recommend we start on the right-hand side.

You want to focus on your consumers first.

Who are we serving?

I talked about this earlier, right?

So if you're building a program, it's important to do stakeholder assessments.

We've got to figure out who we're serving and meet with them and have discussions with them and figure out what their needs are, how they like to consume things.

I like to interview folks.

How your CSO wants to consume is going to be very different from how your SOC manager wants to consume things.

And you are in a service business when you're building an Intel program, so you have to understand what they need and how you can best deliver it to them.

So you do your stakeholder assessment.

You figure out who your customers are and how we're going to deliver to them.

Then we go back and start doing our intelligence requirements.

So this is the biggest challenge I've seen globally.

Pick an industry, with the exception of the government, this is the biggest challenge we see is organizations deciding to build an intel program, and then they don't develop any requirements and they start throwing things at people.

Well, the problem you're going to have there is you don't [INAUDIBLE] given them.

You're not consistent about what you're giving them, you have no idea if meets the mark.

You don't know what they were looking for.

I've seen a lot of organizations put a lot of time and effort into building intel, and their customer that comes back and says, I don't know why you're giving this to me.

And it could be because have no idea what they're looking for.

It could you haven't educated them on what intelligence is and what to do with it.

There's several problems, but it normally starts with intelligence requirements.

So again, as you do your stakeholder assessment, you have your meetings, you've got to develop requirements.

If you don't know how to develop requirements, there's folks like myself, there's others in the company, there's other companies, for that matter.

We're happy to help.

There's a lot of folks willing to work with you on intelligence requirements that are going to be effective.

I recommend working with somebody if you don't know how to do it yourself.

If you don't have documented intelligence requirements that have been worked with your stakeholders and accepted on both sides, you will probably fail as an intelligence program.

You're going to have a very hard time developing a successful program and delivering results that your customers care about and need.

And you're going to spend a lot of money, too, so you better get it right.

So when we talk about intelligence requirements, we also have to understand what our assets are, who has access to them, what are the technology dependencies.

There's a lot that goes into this.

We can talk offline, if you want, more discussions about intelligence requirements.

Then we've got to talk about our goals-- detect, defend, attribute, prosecute.

So question for the audience-- attribution.

We hear attribution all the time.

Every leader I've ever worked with wants to know, who did this?

What are the only-- if you come up with a different answer, I'm happy to hear it.

But so far, I've only come up with two answers as to why we care about attribution.

Can anybody tell me why we care about attribution?

Don't say we don't.

AUDIENCE: [INAUDIBLE] companies [INAUDIBLE] care about attributions [INAUDIBLE] predictive models and long-term studies of particular [INAUDIBLE] gets involved there, we can go back [INAUDIBLE]..

A.J.

NASH: Absolutely.

that's one of the two is you want to have attribution so you can understand what might be coming next.

Once we understand who we think this is, if we have a good understanding of the adversary, we can develop that understanding, we can see what we think is coming next.

If you want to use kill chain, for instance, how we discovered this, we've attributed to so and so.

Well, this is only a step 2 of the kill chain.

Let's look further down and see if they've gone further down, and try to catch where they're going.

I think that's a perfect answer.

So the only other answer that I've seen so far if you you have the ability to do something about it, if you have the ability to prosecute or strike back.

As Admiral Rogers said yesterday, that's essentially the government.

I happen to agree with him.

Not that my opinion's remarkably important, but hack back's a really bad idea.

It should be limited to government only.

The repercussions of hack back are incredibly powerful.

The politics go with it as well.

You're never going get a lawyer who's going to agree to it.

So if you're not able to hack back and you're not able to prosecute somebody, then attribution isn't remarkably important, except for what you said, which is looking ahead.

You want to see where they've gone, and you want to be able to predict the next thing.

So unfortunately, leadership a lot of times wants to know just because they want to know.

It's a gee whiz thing for them.

And that's a hard discussion to have, to explain just how much time and effort you're going to spend on that if you're not doing one of these two things.

So I recommend framing it in exactly the way you did.

This is why we do it and how we do it, and also letting them know upfront how much effort it takes to go down that path.

And you have to talk about caveat language and confidence language because you're unlikely to get You can never really rule out the possibility somebody is mimicking somebody else's behavior.

So capabilities, limitations, personnel, tools, access, budget.

So we have to be honest with ourselves when we're building programs.

I've worked with some organizations that have said, my goal, we're going to build a world-class intelligence program.

And then the very next sentence they say, we have $250,000.

And that should've got more laughs.

This is a quiet room.

So those two don't go together at all.

If you have $250,000, you're not building a world-class program.

It's important to be honest about what we have and what we're trying to accomplish.

Now, if you have $250,000 this quarter, and we're going to continue to build from there, that's great.

You can build a roadmap.

But if leadership says that's what we're going to spend, period, then we really have to build a plan that says, this is what you'll get for that.

You can get better with $250,000 than with zero, but you're not going anywhere near world-class.

So we have to be honest about that.

And then the other one I talk about here is the access and authorities.

I'll talk about personnel a little bit later.

Access and authorities-- ideally, your intel team will have as much access as anybody in the company.

That's a really tough thing to do, especially if you're working in, say, a financial organization, and the fraud team likes to hold on to their data.

SOCs don't like letting Intel teams have access to their Splunk instance because they don't want us to break them.

Insider threat is enough another tough area because that's segmented off.

But ideally, your intel team has as much access as possible.

You can connect the most dots.

If you can't get access to organizations, then you have to build relationships with them.

You might not get direct access to fraud data, but you can build a relationship with whoever owns that data and at least be in a position where they can double check things for you.

They'll [?

lead ?] the access.

You may not get access to the insider threat program.

You probably won't, frankly.

They make for a good customer, normally.

But you can use them again as a resource, and most them come with really good backgrounds in law enforcement or intel.

So make relationships where you can't get access.

And then prioritizing your sources is the big one.

Some organizations have a hard time understanding this.

I-- absolute true story.

When I worked in a previous position, we had a customer who said-- or it was a potential customer-- who said, we don't need intelligence program.

We don't need to build this.

We monitor Twitter.

We're fine.

True story.

And I heard it secondhand.

I never met that individual, probably because they were wise to keep me away from them.

So I just didn't know what to do with that.

If that's your answer as an organization, you don't have an intel program-- and you can accept your don't have an intel program, but that's not going to work.

So it's important to understand open source and media have a place.

They're really good, I think, as early warning and indicators and a place to start.

That's not intelligence, though.

You can't validate any of the sources, essentially.

So you really have to start there is just a place to get going.

It's a pointer, perhaps.

To me, that's sort of a prioritized list here.

You've got ISACs They're really not intelligence organizations.

They're information sharing organizations.

That's even how they're named, so it's important to understand what they can and can't do.

Couple of them are getting better on producing intelligence, but they're really a great place for early warning, again.

If you're a financial, the first place you should learn about a breach is from a fellow financial through the ISAC.

The challenge with the ISACs is that the ISACs remind me a bit of a junior high school prom in that everybody shows up, and they all stand around on the sideline and nobody talks to anybody else.

And that's not really useful, either.

So if you're going to be a part of an ISAC, engage.

Work with your partners and actually get involved, and put information in there.

Work with your lawyers to get permission to do it.

I know legal's difficult for this.

But otherwise, the ISACs don't work as designed.

And then you go to things like IOC feeds, something it's got a little more vetting to it, and then finished intelligence.

So if you're going to build out an intel program, when you talk about your sources, you should really build out a source matrix and do a scoring system with that so you can weight your sources appropriately.

So it's the best slide in the whole deck, as far as I'm concerned.

Simple math of intelligence.

You might have noticed in my resume I didn't talk about math at all.

So you're not going to see any numbers.

To me, intelligence is talent times access times time.

I'm more than happy to change this variable has a better idea.

This originally did say talent plus access plus time, but a mathematician pointed out to me that a zero in any one makes a zero at the end, and they were right.

So I will change.

But what comes down to, like I said, talent, access, and time.

You have to have the right people, you have to have the right access to data and information to get things accomplished, and then you always have to have some level of time to get things done.

And that's always the hard one because everybody wants it really, really fast.

So I'm going to talk about the rest of the presentation based on these three concepts.

So talent-- I'm running a little ahead of schedule, I think, too.

So I think there's a few different ways you can build a program.

The way we've got set up here, you've got your internal only.

So gives you increased control and visibility.

You're going to be able to own all your people and direct them as you see fit.

They can work directly on your needs and your requirements.

It's really expensive, and it's really hard to find the right people.

So we hear a lot about the gap in talent in cybersecurity.

Statistically, it's millions of jobs, I believe, now.

The gap in talent for intelligence, from a percentage standpoint, is probably higher.

One of the things we see happen is people try to fill that gap by putting perhaps the wrong people in those positions.

So we have a real challenge when it comes to filling these teams up properly.

So you can try to do it internal, but it's going to cost you a fortune.

You can outsource everything.

It's going to decrease your costs.

There's plenty of vendors out there that are happy to take your work and happy to work for you, and they do some really good work.

The challenge you'll have is they're not going be focused on alone.

No vendor, unless you spend just as much money as hiring your own people, no vendor is going to have dedicated assets entirely for you.

They may have an asset or a couple, but generally, they're split.

That's how it works.

And if I'm a vendor and you're a financial, I'm going to put a couple analysts that work towards you but also work towards a bunch of other financials.

So I get the most value out of my analysts who get the most value out of my business.

That's still good for you, but it is going to reduce their focus on your specific needs.

So you have to be realistic about that.

So you lose that control and visibility, as it says, and the intelligence may not be where you want it to be.

So it requires more management of your vendors.

There's a challenge that goes with it.

So with every cost benefit, there's a challenge.

Then the hybrid approach, which is the one I happen to believe in, and I think is probably the most common at this point, which is organizations that choose to build an internal cadre, a handful of people that are highly talented and focused only on your needs.

By doing so, you're getting all the benefits of having an organization where you can build your intelligence requirements and connect your internal customer base, an organization where you can really focus on your needs and you can drive them and manage them, but then outsource the other things.

Couple things I highly recommend outsourcing-- deep and dark web.

Unless you plan on building an entire network separate from your own network to work on deep and dark web and you want to hire people that are heavily trained in that field, I don't recommend going into it.

There are vendors who do a really good job of this.

They're insulated from you, keep you safe and secure.

They'll get you what you need, and they'll do it faster and better, frankly.

And keep in mind, my company doesn't do that.

So that's not self-serving.

I just happen to believe in it.

It's just safer to farm that work out.

So there's a few other aspects coming to mind, but deep and dark web's always first to me.

So you reduce your challenges.

You reduce your cost at the same time.

You will get the best mix, I think, with a hybrid approach.

And you can still make sure your needs are met.

The only real challenge I see in this one-- there's obviously some cost issues, and procurement becomes a bit of a hassle-- but you do have to manage vendors.

So make sure somebody on your team has that as part of their requirement.

It can be the person who manages your intel team.

[INAUDIBLE] believer in probably delegating that down one level.

Generally, when I've built teams, I've tried to split it up between sort of a collection aspect and a reporting aspect.

So when we do the collection piece, I have that person who runs a collections handle the vendor, since it ties into collections.

That's just one example, one recommendation.

Yeah.

AUDIENCE: So if you're doing any form of fusion intelligence, so risk-based intel, business intel, [INAUDIBLE] intel, when you need to get talent for those pools, are you looking for [INAUDIBLE] from the field you're trying to fuse with?

Or are you trying to take someone who understands intelligence [INAUDIBLE]?

Which way do you want them to have [INAUDIBLE]??

A.J.

NASH: That's a good question.

First of all, I'll say, if you're doing fuse, you're one of the few.

So you're already ahead of the market in a lot of ways.

There aren't a lot of people doing that.

So it's good on you.

That's a good question.

So I tend to want to look for people that have intel background, but you may have found the one exception.

So if you're dealing with fraud or business risk-- I think those were the two ones you mentioned-- I might be more inclined to get something from that side because the foundational pieces of intel I can teach them.

The dirty secret of intel-- there are some things that are very hard and take years and years to learn, and that's why people and Intel are well-paid and hard to find.

But the real basics you can learn very quickly.

I mean, you can take GCTI, you can read ICD 203, 206, 208.

You can read JP 2-0.

In a matter of a couple of months, I can get you spun up on really the foundational things you need to survive in the intel world and how to build products.

And I probably wouldn't go that route, me personally, because I can teach that stuff, whereas I can't get them spun up on fraud or risk, for instance.

That takes a little bit longer, and that's not my expertise.

So were it me, I'd probably go that direction.

Were I somebody with a deep fraud background who didn't have an intel background, then I go the other direction.

That makes sense?

What are you guys doing?

AUDIENCE: So [INAUDIBLE] thing is fraud intelligence, so attacks on fintech [INAUDIBLE] engineer and create [INAUDIBLE] how they're perpetrating the difference in the [INAUDIBLE] technology [INAUDIBLE],, but we're also doing [INAUDIBLE]..

It's a kind of multifaceted [INAUDIBLE],, and it's hard to figure out which direction [INAUDIBLE]..

A.J.

NASH: Yeah.

Yeah.

Another issue that may come up just becomes availability.

Because that is such a coin toss, you may just end up going with availability.

If you can find more fraud people quicker, which generally you can, I think.

It's still hard to find intel folks.

You may just go that route because you can train them up.

Like I said, GCTI really helps out, something of that nature.

I know took it.

So [INAUDIBLE] that definitely helps.

By the way, if you haven't met, he's with Worldpay.

Really smart guy, recommend you chat with Matthew.

They've got a pretty good program going on over there.

So the last piece on this slide-- and this is controversial.

Some people don't like it, but I'll say it anyway.

My personal opinion is you're going to build an intel program, you better put somebody who knows something about intel in front of that program, generally an intel pro.

Now, there are exceptions to this rule.

I've seen really good teams that didn't have an intel professional running the team.

So I'm not trying to offend anybody.

Generally, that's somebody who is very self-aware, knows how to hire good intel people and then allow them to help direct to the team's functions, and then that person handles the business aspects and the managerial aspects.

But the challenge I've seen-- the most common problem I've seen in the industry, and I've seen it repeatedly, is organizations who-- the board says we need an intel program.

Regulators tell us we have to have one.

We got an intel program.

The board tells the CSO, and the CSO tells somebody, SOC director, whoever it is.

And the end result is we're going to build an intel team.

All right.

Well, Steve over here is really, really good at IR.

He's our best IR guy.

He's been a manager a long time.

Steve's ready for a promotion.

Steve, you're the new director of intelligence.

Steve doesn't know anything about intelligence, though.

Steve's an IR guy.

That's his background.

He might've been a great manager.

He might be a great worker, he might be a great leader, but he doesn't know anything about intel.

And Steve is probably going to hire three more Steves because that's what Steve will do.

And you'll end up with an intelligence team that's actually just another IR program.

I've seen it happen repeatedly.

And after a year, maybe six months if you're fast, more like the organization's going to figure out we don't have any intelligence.

We have another team that's just living in the atomic world.

It's all atomic indicators.

It's all that data I showed you before, maybe the information.

They're not producing finished intelligence.

They're not built for that.

And poor Steve, who was great and having a fine career, is now going to be fired along with all the rest of his team.

Steve was set up to fail.

I see it happen all the time.

And full transparency, that's how I ended up with my last gig building an intel program because somebody hired the wrong person and they built the wrong team.

It wasn't their fault.

They're all good guys.

They're all hard workers, but they were the wrong people.

So it's important to put somebody in front that's an intel person.

They will help you with the recruiting aspect.

Intel people know intel people.

I could pull three or four people out of the intelligence community right now, probably.

Somebody who isn't in the community isn't going to know those people.

They can also vet resumes.

Another big challenge you'll have if you start trying to hire intel people, everybody looks like a superstar in a resume.

The intelligence community's great at building amazing resumes and amazing people.

Some of them aren't 100% honest.

It's easy to have a resume that says the great things you did.

But if you dig in, it's, well, you were part of a team that did great things.

But which part did you actually do?

And a lot of times, it's not as much as they say.

So having somebody who knows people.

The intelligence community is pretty small.

A few phone calls, and you can find out this person's legitimate and what they actually did, and that's hard to do without intel, without somebody that's actually from the community.

So that person will help you build the team.

They'll bring in the right talent.

So it's important get that key hire right.

So another piece with talent, it's the intelligence cycle.

If you haven't seen this, there's a million different copies of this, different graphics.

It's all the same.

But it starts with planning direction.

I talked about intelligence requirements.

If you don't have intelligence questions, again, you will fail as an intel program.

You will never be able to get full success and full value of your program.

Requirements drive collection.

Once you understand what you need, you've done your stakeholder assessment, you've gotten your requirements vetted and approved by your stakeholders-- get documentation, agreement between you and your stakeholders on what your requirements are, because later on, if they say you're not meeting their needs, you're able to go back and look at requirements and say, we either need to change the requirements or we have another issue here because we had an agreement on what you need, and we're trying to fill those needs, and here's our documentation.

But once you have your requirements, [INAUDIBLE] your collection.

It's important to do that before you pick vendors, in my opinion, because you'll have a better chance of getting the right vendors for your needs, get the most value out of them if you know what you're trying to do.

If you're a company that's really, really interested in fraud, well, there are vendors that do that stuff really well we can help you.

But if you start buying all your vendors and then figure out, well, we didn't get a vendor who's really good at fraud.

Now we really need fraud data, and we're all out of money, but we bought this other vendor that does stuff we don't really need very much of, that's a problem.

You need to understand, do I care more about nation states?

Do I care more about cyber criminals?

Different vendors focus in different areas are better at some than others.

So do your stakeholder analysis.

Do your PIRs before you start talking my collection, before you start building out your collection program, ideally.

Collection drives into processing, analysis, production, I'll talk about that in a minute, how the sausage is made, then dissemination.

You have to have a way to get intelligence back to people, and that arrow represents a feedback loop, another really important piece.

So dissemination-- at some point, you have to report things to people.

You have to have a mechanism for doing that.

You have to have processes.

One of the things that's not covered here is almost all these have to have pretty well documented processes.

Your collection process has to be documented.

All of your processing and your analysis processes and your reporting processes have to be documented.

Regulators are going to need that.

Leadership's going to need that to know that you have a repeatable process that works so they understand why you're doing.

And if things break down, you're going to know where the problems are and how to fix them.

And then dissemination.

Now, that can be as simple as email or text message, whatever works for your organization.

But you have to have something that's a repeatable process for dissemination.

But the feedback loop, this is a huge gap, even in the intelligence community.

I've written hundreds of intelligence reports in my career, I'm sure.

I can probably count the number of times I got actual feedback on one hand.

It just doesn't happen much.

The only feedback I ever got was when I did in individual briefings.

And that's the challenge we have here.

But feedback is incredibly important, and it's on you as an intelligence team to make this happen.

It's not on the customers.

If you think they're just going to give you feedback, you're mistaken.

They're going to read it, and they're going to like it or not like it, and they're going to move on with their day.

You have to build a process for feedback, for regular engagement with your customers, so you can ask them, have you read these reports, how did they meet your needs, and get that feedback so you can drive the rest of your program.

Otherwise, you'll be in a steady state, and you'll find out six or eight months later that this customer you thought you were serving, you've got all these requirements, then you've met them in your mind, and they're not happy with anything you've been producing.

So make sure you having a regular cadence with your customers.

That's why you have that stakeholder analysis.

You can pick out a stakeholder from each organization that can be your cadence call.

Also with the talent, analytics, standards, and tradecraft.

So I mentioned I use government documents a lot.

I'm a big believer in the intelligence community directives.

By the way, these are unclassified.

You can Google the term ICD, or Intelligence Community Directives, and you can read them if you feel like it.

There's, like, 800.

I don't recommend it.

But ICD 203, 206, 208, those are worth reading.

I can't imagine they're more than 10 or 15 pages combined.

They'll give you a lot of basics, a lot of the foundations of intelligence.

One of the most important pieces is the caveat language, which is mentioned up here.

In intelligence, words matter.

Words matter to all of us, but in intelligence, words are incredibly powerful.

And we need to understand them, and we need we need to help educate our customers on how to read intelligence.

So a perfect example-- If I write an intelligence report that says, we have a low-confidence assessment based on limited intelligence that China is going to attack us, and I also read an intelligence report that says, we have a high confidence based on a large body of reporting that China is going to attack us.

If you haven't educated your readership first, all they read is China's going to attack us.

These are equal reports to them.

And they require very different responses.

So one of the things I recommend when you're building a program, which is what I've done in the past, is you build sort of a user guide, how to read intelligence, I would say.

So whatever format you end up with, walk your customer through what this section means, what this section means, how to perceive this, how to understand that.

And be willing, again, as you're doing your stakeholder assessments, as you're doing your PIRs, as you're starting to develop your program, as you're building these relationships, to meet with them and have a briefing.

Maybe it's a one-on-one, maybe it's a team.

And sit down and walk through them, and say, I want to explain to you what this means because this document's really powerful, and we want to help you get the most out of it and make the most of your time because you can read certain sections and decide if you care about this product.

But you also want to make sure you explain caveat language to them so they know what they're seeing.

Otherwise, you're going to have a very hard time when people overreact to things, which is what exactly you're trying to avoid.

Part of our job in intelligence isn't just to inform for purposes of action, but sometimes to inform in order to calm the stress.

I talked about that earlier, about the fear.

I can write a product that alleviates some of that fear, theoretically.

The news is all about fear.

The news is all about noise and ratings, in a lot of cases.

So they're going to make a lot of noise and scare a lot of people.

If you can be in a position where that noisy story comes out, and your CSO is all upset, and you can come back and put it in context and say, hey, this actually isn't new, boss.

I get why you're upset.

This is a scary story.

But this is a rehash.

This happened eight months ago.

This is a slight variant to it.

We're already covered.

This is everything we know about it.

This actor doesn't even care about our industry or our geography.

You can solve a lot of their problems in a hurry.

So a big chunk of our job is also just to give peace of mind to our leadership.

So make sure you're educating them.

So what does a program look like?

So this is a snapshot of what a built program can look like.

Obviously, I've got some of our particular products on here.

But you've got all these things coming in.

You've got your open source, you've got your premium vendors.

I've got a handful of them listed on here, whether it's the CrowdStrikes or the FireEyes or the Flashpoints, the Intel or the Recorded Futures or the Silobreakers or any of the 42 premium apps that we have in our app store or anything else you want to use, you've got all those things coming in that you're paying for.

You've got, in our case, Anomali Labs.

That's our individual research team I've listed up here.

It could be others.

You've got the ISACs, you've got government sharing.

So there's a ton coming in.

This is the argument in favor of a threat intel platform.

So full disclosure-- before I at Anomali, I was a customer.

It's part of the reason I joined the company.

I believe in threat intelligence platforms because I've lived in a world where you don't have one, and you have to work through all of that.

It's just too damn hard.

You don't have enough bodies.

You're not can get through things.

You're going to waste a lot of money on a lot of things you're not going to use, and you're not going to get the most value.

A platform changes all of that.

So I'm a big believer in the concept of a threat intelligence platform.

I happen to believe in Anomali's, obviously.

So you have all that coming in your platform.

You can tie that back to-- I've got Anomali Enterprise listed here.

I apologize.

It's now Match, as of yesterday.

I'll change that.

But you've got it tied to Match and, of course, Splunk in the background of that.

Or you've got to tie to a source solution.

I had to put Cybersponse up here.

It could be Phantom, it could be any other source solution.

But be in a position where, from a machine standpoint, ideally, the world.

I like to see us get to, and we're not there yet is you have all this coming in, and you've got it going into a threat stream.

You've done all your tuning and you understand what your run books are going to be.

And if we have a threat that's validated as an 80% or greater-- let's say that's where we put our threshold-- we've done the matching.

We've run it through SOAR, and we've opened a ticket through, say, ServiceNow.

SOAR does that automated, remediates, closes the ticket, notifies you.

You can get a lot of your tier 1 done, intelligence-driven security without personnel being involved.

But besides that, from an intel standpoint, we've got all this running and, you got the intelligence team and what your outputs are going to be.

So I already talked about the tactical technical, the operational strategic.

There's another piece listed on here, which is physical security.

They kind of fall between the tactical and the operational, which is why I listed them separately, but more because I wanted to call out something a lot of people don't take a look at.

Your customer base, more than likely, will not be just your SOC.

A lot of people build an Intel team that supports the red team and their blue team, sometimes just their blue team.

That shouldn't be your entire customer base.

Obviously, you've got your executive-level manager.

I mentioned that.

But we should talk about a larger scope, things like physical security, like fraud, like risk, like insider threat, procurement.

A lot of people don't think about procurement from an intel standpoint, but it be great if we worked with procurement so when you're bringing things in, you can understand the risks of bringing those things in your networks before you do.

A lot of organizations acquire technologies and put them into the network and infect themselves because they haven't taken the time to figure out the procurement process, and perhaps this organization we shouldn't be buying equipment from or software from.

M&A is another one.

You're going to buy a company.

A lot of organizations do their due diligence, and really it all comes down to, well, are they profitable?

And are they under investigation for anything?

And that's where due diligence ends.

And there's a little bit more to it.

I don't mean to denigrate the business side of things.

But we don't take a look at the intelligence side to find out, does this organization have second- or third-level connections that we shouldn't be associated with, that are bad for our business or dangerous?

I'll give you one quick example.

Had a customer a few years back.

They came panicked to us, as an intel team, and said, hey, we've got a problem.

We need your help.

Our CEO has just announced that we are going into a partnership with a Chinese non-government organization.

Again, not enough chuckles in the room.

I've got to work on this.

If you don't know anything about China, there's no such thing as a Chinese non-government organization.

Ultimately, everything runs back to the government at some point.

So large pharmaceutical company, they've gone into business with a Chinese non-government organization.

They don't know the risks.

So they tasked us with it.

We put a Chinese expert on it.

She did an amazing job on research, and she came back with a large paper, but more importantly this big org chart that showed basically everybody who is in leadership for this NGO, they were also in the Chinese government.

In fact, their offices were co-located with a branch of the Chinese military.

Everything was very coincidental.

So we were able to come back and explain-- we had a-- I don't remember if it was a moderate or high.

That was a high confidence assessment that if they went into business with this organization, all of their data was probably going-- all their IP was probably going to go to Beijing.

That's a real problem for them because they now explain that to their CEO, who's already made a public announcement.

That's a political nightmare.

Unfortunately, the second piece of that, for those who don't know China, is once they've targeted you for a partnership, there's a pretty good chance, even if you say no, they're just going to attack you.

So that was the second piece we were able to explain to them is if you choose to say no, you really should harden all of your systems against these problems.

If they haven't already gotten in, they're probably on the way.

But that's an area where had they had a more mature understanding of intelligence-- and they were relatively new at it-- before that CEO got out there and made that decision, he could have worked with his intel team, asked them the risks, run through the same process we did, and probably would've come back with a different answer on whether they want to go into business with China.

I don't know how it ended with them, to be honest.

So time's the last piece.

Talent, access, time, right?

We don't control time.

I think everybody knows that, and time's a big challenge for us.

Average time to detect on a breach right now, I've got 197 days, give or take.

It takes another 70 or so for us to actually mitigate that.

Unfortunately, actors are working really fast.

The time to go from development to market and to actual being able to use new tactics, techniques, new tools, it's down to days.

So we're fighting a losing battle on time.

There's no real argument on that.

Unfortunately, the result is a lot of folks think we just need to move fast.

Fast, fast, fast.

And that cannot be your only metric.

It can't be your only metric internally for leadership to judge you, and it can't be your only metric for judging your vendors.

It's a real challenge we have.

Generally speaking, if somebody is always first, I would actually be pretty skeptical.

I'd really want to look into what their processes are and how they're getting to their conclusions, and if they're applying proper tradecraft and standards.

There are a lot of small vendors who know that first is the metric people care about.

They'll be first and worry about whether they're right later, and that's really dangerous.

You need to be timely and accurate when it comes to intelligence.

It's all about credibility.

If you're first and you're wrong repeatedly, you'll end up losing business if you're a vendor.

But for you guys, you'll end up losing credibility in your organization, and essentially, you'll lose your job, eventually.

So the best way I look at this one you talk about fast.

I used [INAUDIBLE] school football for several years.

I loved fast players.

You can't make people faster.

You can do a little bit of coaching, but really speed kills.

So you want fast guys.

But I never really liked fast guys who were stupid because that fast guy who's dumb just gets on a position a whole lot quicker, and I can't do anything with him.

I'll take the slow guy who knows where he's going every time.

So this is a big communication point with our leadership, is to explain to them how we're going to get where we're going and why you know some of our timelines need to adjust.

Now, one of the ways to mitigate this when you work with leadership is when you build a product line, which I didn't talk much about here, is you build a staged product line.

You may have something called a flash.

And I recommend building a matrix for this that you can explain to leadership.

Say, I've got a flash, and I can deliver that and up t