Hiring Your New Employee—Threat Intelligence: Detect ‘19 Series

PRESENTER: My name is Nicholas Hayden.

I'm the senior director of threat intelligence for Anomali, head of global intelligence operations for the company.

And so, this talk is a very high level strategic talk.

I take some abstract concepts and apply them to how to build a threat intelligence program.

So our of a show of hands, who here is director level or higher?

A couple people, OK.

Who here is-- I know the chief's grouped officer over here.

Who here is part of a threat intelligence team or a CISO?

OK, excellent.

All right, so a little bit about me.

I've been in this industry now for 20 plus years.

You can tell by the gray hair legitimately in cybersecurity for the last 20 plus years, head of global intelligence operations years and years ago.

I used to work in the energy sector.

And I helped develop the national standards for National Energy Regulatory Committee, which governs how we protect the critical infrastructure.

I'm also a cyber operations officer in the Air National Guard.

I am the base communications commander for the 101st Air Refueling Wing and currently on the STIX/TAXI drafting committee for interoperability sharing of threat intelligence information.

And then some bonus information about me is I was legally asked, legally asked to hack a 777 aircraft.

I can't tell you what the outcome of that was.

But so a guy by the name of Chris Roberts claimed that he had hacked a 777 aircraft.

And the flight control systems were designed by a company that I worked for, so the director of Homeland Security asked me if I would go and see, do a feasibility study, we'll put it that way.

And then I also make wine, so I own a winery called Valhalla Farms.

And I love to make wine, love to make and drink wine.

So the question is why, why this talk, why now?

Well, here we are at a threat intelligence conference, and we're all talking about how to build a threat intelligence program.

Some people are part of an actual threat intelligence team.

So why this talk, why now?

What I can say is that it's an uphill battle.

Let's see if my-- It's an uphill battle, right?

We're pushing the rock up the hill.

People are fighting with, how do we operationalize intelligence?

How do we go from all of this data?

How do we dwindle the data down?

How do we make that operational?

And how do we get ahead of the game?

The whole point of threat intelligence is to get information and put it in the defense in depth strategy prior to actually getting attacked or hit.

So how do we get from point A to point B?

And so, the problem with it is we're always competing against luck.

Do we, oh, we found this bit of information, great.

I'm going to block at my firewall.

And you hope that you get lucky that you blocked it before it actually happened.

So we're always competing against luck.

And it's always an uphill battle.

And part of that is people have struggled with trying to build a comprehensive and effective threat intelligence team.

And so, that's really primarily what this talk is about is looking at how to build a team from a different perspective.

I've spent the last 15 years building different teams, pretty successful teams.

Some of my team members are here now in the audience.

So they can heckle me and tell me how poorly I built a team and how much this talk is incorrect, but hopefully they won't do that.

So we've seen struggles.

We've seen struggles with trying to build a program, trying to implement a program, how to operationalize.

That was the first part of it.

Then we saw struggles with data overload, things like that, and then how to actually effectively implement a real threat intelligence program.

So one of the big ones is moving from a proactive to reactive.

Traditionally speaking, a lot of companies who have a threat intelligence program use threat intel data for a reactive approach.

So they found phishing email.

They found an alert on their firewall, something along those lines.

And what they do is they take that and they dump it into a tip, and they try to figure out who, what, where, when, how, and why.

But it's a reactive.

They already found something on their network or something's already happened.

So now, they're going to go start the investigation.

So the struggle is trying to move away from a reactive to a proactive.

So remember I mentioned that the key to a successful threat intelligence program is, and I want to-- I should probably preface that when I mean program, I'm talking about processes and procedures not applications.

So if you hear me say threat intel program, that's what it is referring to.

So taking that effective threat intelligence program is to get this data, collect this data, and operationalize it before an attack actually happens.

And the premise behind that, if you look back to the older days back when we had castles and we were defending castles, what was intelligence?

Intelligence was they would send somebody out beyond the enclave.

They would go out and they put their hand on the ground or they put their ear on the ground.

Or they would go up onto the highest point and look out.

And what they were doing is they were collecting data points.

If they had their hand and their ear to the ground, they would be looking to feel the rumblings of the ground and to let you know that an oncoming army or cavalry or something big was happening.

Then you take that data and you run back to the castle, and you present that information to somebody to start building a defense strategy.

You know?

So that's really no different than what we're doing now.

So a lot of people, we mentioned a reactive, which is we find something and then we go get the intelligence.

But the point of intelligence is to put your hand outside the wire of your enclave, grab those bits and pieces, take that information back, build your defense, so that you don't get compromised.

So again, operationalizing data, how do we get all these data points?

And how do we turn it into something that we can actually use to get ahead of the curve?

What is operationalizing threat data mean?

So these are all constant struggles that many, many teams have.

How do you know if your threat intelligence program is successful?

What is your measure of success?

And how do we hire the appropriate people?

So there was a few hands here.

Some people are director.

Some people are part of a team.

Who here feels that their team is fully staffed?

Not a single person raised their hand.

Exactly.

And part of that is that threat intel people are very difficult to find, especially good threat intel people because there is a shortage of cybersecurity professionals.

Right?

So here we talk about, so there is a shortage of cybersecurity professionals.

We know that across the board.

The scary part is that there is even a greater shortage of analysts.

There was a recent security study that was done with here's my little mouse here-- that said basically lack the necessary skills to combat the threats against the organization.

And 37% report that their teams just can't handle the sheer workload.

So again, this goes back to the struggles that a threat intelligence team has.

So how do we build a proper threat intelligence team?

The other thing about cybersecurity and threat intel is that you have a layer of cybersecurity professionals who are very technical.

They're great with firewalls.

They're great at reversing malware.

They're great at programming.

They're great at understanding how data crosses a network.

But majority of them are introverts.

And the thing about threat intelligence is you have to know the people aspect of it as well.

You have to understand why people are doing what they're doing.

You have to understand what their motivations are and what their thought process is.

And once you acquire that skill set, that's when you can really be considered an actual threat analyst.

And so, we have a shortage down here of security professionals.

But now you're taking people who are traditionally introverts and, hey, we want you to know about people too.

So it's difficult.

It's difficult to make that transition.

So for a while, we'll always have a struggle.

So I looked at this.

And having been in this industry a while and I wanted to say, let's stop competing against luck.

So the basis of this talk is actually, again, an abstract concept where Competing Against Luck is a book written by Clayton Christensen.

And the main point of it is called jobs theory.

So is anyone here familiar with jobs theory?

Couple of people, OK.

So jobs theory is that you're hiring something, someone.

You hire a product.

It's really more around products.

But you're hiring something to do a certain job for you.

And so, it works, usually, most of us have hired people.

Especially if you're a director level, you've hired somebody.

So you've written a job description for somebody because you're trying to fill a need.

That same concept can be applied to programs and applications.

So you're going to write a job description to fill your needs.

So we're going to take that abstract concept and apply it to building a threat intelligence team.

So remember that I mentioned that the whole point of jobs theory is you're writing a job description.

You're going through a hiring process of a product or program that will satisfy your need.

So what we're going to do is we're going to take a look at a standard recruitment process.

First thing you need to do is you need to understand what the company's needs are.

So why do you need a threat intelligence program?

Do you need a threat intelligence program just because someone told you that you need a threat intelligence program?

Do you need a threat intelligence program because someone said, hey, threat intelligence is pretty cool.

So you got to understand what the company needs are.

Then you'd go to writing an actual job description.

And we'll go through this whole process as we go through this talk.

Short listing candidates, interviewing candidates, hiring candidate, and then doing performance reviews.

Everyone here has gotten hired at some point in time, and you've gone through this process.

There's a few over here that I saw raise your hands, you've actually hired somebody.

So you've gone through this process.

So what I'm trying to teach you is to use a process that you know and you're probably comfortable with in order to build an effective threat intelligence program.

So understanding company needs, questions to ask, and apparently these slides just automatically come up.

So why are you hiring an employee?

What are you expecting them to do?

What's your expected outcome of that employee?

And what job are you hoping that employee is going to accomplish for you?

So why are you hiring an employee?

I'm going to reach out to the audience.

Why are you hiring an employee?

To do a job, right.

So the next piece is, what is your expected outcome?

Are you expected that person to come in and reverse malware?

But what is your expected outcome?

So is it to take that malware and grab IOCs and then dump that into something to block?

So you got to really understand, what is your expected outcome of that individual?

Because, one, if you don't know what your expected outcome is, you're going to set that person up to fail.

But a bigger picture is you got to understand what you're hoping that that person or that program, because remember we're talking about threat intel program, is going to do.

So what is your expected outcome of a threat intel program?

Is it to reduce the time of detection from the time of infection?

Or is it to get information quicker to your security operations team?

Is it to build a-- to get the information to the IT department to build a defense strategy quicker?

You have to take a step back and understand what it is you want to accomplish with your program.

It's not just to run out and hire a bunch of really smart people and say, OK, I'm not really sure why we want to do this.

But we need to do this.

So I'm going to let you guys figure it out.

You've got to take a step back and understand why you're hiring in the program.

And then what job are you trying to accomplish?

So once you identify what job it is, as was mentioned here just a second ago, what are you trying to accomplish?

What do you want this program to accomplish?

So you know what your expected outcome is.

How are you going to get there?

What are you expecting that job to actually do for you?

So let's talk about writing a job description.

Here's a job description for a server.

So in your opinion, does this define what you want it to do, what the expected outcome is?

We're going to make this a little more interactive.

OK?

By a show of hands, is this a good job description?

Show of hands.

Yes.

Show of hands if you think it is.

Show hands.

No one's raising their hand.

All right.

Why?

Anyone?

Pardon me?

AUDIENCE: Not enough specifics.

PRESENTER: Not have specifics, right.

So you got to be careful about when you're developing a threat intelligence program is it can't be too vague.

Because if you're going to be too vague, your expected outcome or the measurables that you're going to put in place will never happen because you're not necessarily going to have the right people.

So here's another job description.

This is an electrical engineer.

I had to do this because I used to be an electrical engineer at one point in time.

Is this a good job description?

Better?

OK.

By a show of hands, who thinks this is a good job description?

OK.

We got a couple people.

Why?

Details, OK.

Could there be anything wrong with this job description?

Too much, OK.

So yes, you're right.

It's too much.

Because if you try to define something so much that your requirements are so heavy, you will never ever find the talent to accomplish what you're trying to do.

Your program will never be successful because you're too specific on what you wanted to do.

So what do I mean by that?

Let's say you want to minimize your time of infection to time detection to 24 days or less.

Is that even going to be feasible if you don't have any monitoring tools in place, if you don't have any program in place?

So you're getting too specific.

You want a person who can reverse malware as part of your program in less than 24 hours?

What if they're handed Stuxnet?

So you can write your requirements that are too specific that you will never, ever be able to hire an effective program to accomplish what it is you're trying to do.

So the key is to have a happy median as to make sure that it's clear, concise.

There's enough leeway that you can be flexible.

But you're also going to accomplish the task.

So like I said, maybe a first task is to say that you want an effective program to just to reduce the meantime of detection to infection.

Maybe that's your goal.

Because it's a measurable goal, right?

Soon as you have your sensors in place, you find a detection from infection.

You track that.

Maybe it's 265 days.

Who knows?

Maybe it's 180 days.

Industry standard seems to bounce all around the place, depending on who you talk to.

But maybe you have that.

And maybe your goal is to get somewhere around the industry standard.

And then maybe as you progress, as you do a performance review, you take a look at where you stand.

And maybe you want to reduce that a little bit more.

But the key is not to limit yourself so tight on your requirements that your goals are unattainable.

So let's take a look at drafting a job description.

So I apologize.

Because normally, this slide should have this stuff come up one by one.

But this apparently doesn't.

So I took the liberty of drafting a short job description of what a threat intelligence program should accomplish.

So deliver sufficient threat and risk information to executives to make informed decisions.

Is that too strict?

No, it's pretty generic.

But it's specific enough that you need to take information and you need to up channel that information to the executives, so that they have at least enough information to start to come up with a decision on their own.

The other thing is qualifications, strong analytical skills and experience turning data into actionable intelligence.

Again, is that too specific?

No.

So it's written in a way that it's specific enough but not too specific.

So if you think about the whole jobs theory, what we're talking about, right?

We're talking about trying to develop a effective threat intelligence program by using a strategy that we already know.

So taking a step back, sitting down with your key people, and just deriving what you want the program to accomplish and how you want it to accomplish it.

So from there, we want to short list the candidates, right?

We're still going through the same process of hiring a threat intelligence program.

So the key there is there is no one size fits all program.

So at this point, what you do is you start grabbing POCs.

You start grabbing different pieces together.

You see how it'll work.

But you have to have more than one candidate.

So you have to take those position descriptions that you wrote, and you have to take multiple pieces together and apply them together.

It's not going out and buying the newest shiny just because it's shiny and then trying to figure out how that fits into your program because that never actually works.

It is going out gathering multiple candidates, sitting down.

Don't settle for different features and functionalities.

If there's something that really works for you and that fits your need, go with that.

Adjust, adjust workflows, processes, programs, things like that, vice versa, so that it fits the program, fits your position description.

Do a parallel comparison of the different setups that you come up with.

And then eventually, you would take that information and you would pass it up to an executive to help make that decision.

So again, I mentioned that I have a vineyard, so I had to add my grapes in there.

So how do you accept or reject candidates?

So you've taken the time.

Your executive team, maybe you're the one that's building this program.

You've taken the time.

You've developed different COAs, as we would call them in the military.

You would developed different concept of operation.

So what's the next step?

How do you get-- how do you accept or reject a candidate?

So we go through a very simple process, one that we already know.

Are you meeting the qualifications?

So you wrote a position description.

Same thing if you're hiring a person, do they meet the qualifications?

They may meet all of them.

Maybe they don't meet all of them, but they meet majority of them.

So then you go through a screening process.

You got your POCs.

You got the time where you're trying to see if this program is actually going to work.

Then you go into the exception, rejection.

So typically, in the exception and rejection, you're going to have the team members here that raised their hand and said that they're part of a threat intel team already, those are the people who are going to be helping to accept and reject the program because they're the people that are going to know whether or not it's going to be effective.

And then they send that information up to the executives for buy-in.

So again, it's a process that we've all done.

It's just looking at it from a different perspective on how to implement a threat intelligence program.

Onboarding, make sure you have the tools to validate what it is you're trying to accomplish.

So I mentioned, a lot of the time during this presentation, the time from detection to the time of infection.

You have to make sure you have the tool in place to be able to measure that.

If you don't, then how are you going to be able to validate what it is you're doing?

So training, making sure that's in there.

Structure.

Make sure that there's training for the processes and programs.

Make sure the threat intel people that are part of this program have the training of the tools and that you're not just dropping a tool in place and hoping that they'll figure out how to use it.

But the key to success really is making sure you have the metrics to support your decision.

If a program does not have measurable, anything that's measurable, so no metrics, no information that you can show that the team is doing what it is supposed to accomplish based on your position description that you wrote, it will not be successful.

You won't be able to go to the executive team to say, this is the success that this team has.

This is what we've accomplished.

Then as you do your annual review, you take a look at it and say, OK, now that we've been this good, we want to be even better.

But in order to accomplish that, you have to have metrics.

You have to.

So now that you have the team implemented, it's in place, it's rolling, the key to success is you have to have reviews.

You have to review what program you have.

It is not a ronco style.

It's not set it and forget it.

You don't just put the turkey in, you push a button, and you come back two hours later and everything works.

It's got to be performance reviews.

The first thing you need to do is have a performance review at the very least 45 days.

Give it a score.

Give it a score.

Are you meeting your expectations?

Are you meeting your position description?

So this is no different.

We use 15, five at Anomali as part of our performance reviews.

We do weekly performance reviews.

Now in this type of situation, you wouldn't necessarily want to do a weekly performance review.

But it wouldn't be unheard of to do a monthly or quarterly thing like that, things like that, performance reviews to make sure that what you put in place is meeting the standards that you established.

So make sure that the program or, in this case, I wrote employee here, but making sure that the threat intel program can complete its tasks.

If it's not meeting the tasks and it's not able to complete those tasks, then you need to go look at what's going on with your process and procedures and do a reiterative process.

Provide direction from the manager.

So the worst thing you can ever have is a new employee and not give them any direction or guidance, right?

So why are we not doing the same thing for a threat intelligence program?

Why are we not giving that program direction and guidance on how it's supposed to operate, what it's supposed to do?

Are you meeting your goals?

Are you not meeting your goals?

Things like that.

And then we also do like high fives with the 15, five.

And that's important too, making sure that the program itself.

Because all the people that are part of that program, it's important that they know that what they're doing is successful.

That is a key to not losing people as part of the program because you just established the entire program.

You hired very intelligent, very short amount of people or not short amount of people.

There's a shortage of people, and you happened to find a couple that fit in.

Maybe you're growing them on your own.

You don't want to lose them.

So as part of that program as a whole, you have to give the positive feedback as well as the constructive.

And that's all done with your performance reviews.

So establish a performance review whether it be 45 days.

At the very minimum, you have to have at least an annual review of your program.

So we kind of talked about this whole process, right, understanding the company needs.

We talked about first why do you even want to have a threat intelligence program?

What's the point of it?

I'm talking too fast.

So what's the point of the threat intelligence program?

What do you want to do?

And then once you figure out and establish what you want the program to actually accomplish for you, and the next step is to write the job description.

Again, don't write the job description so vague that you can't meet your requirements.

And also, don't write it so detailed that you can never find anything that will fit the position or the job description that you wrote.

So once you do that, once you start establishing what that program is, derive a list of candidates.

Look at different threat intel tips or look at different firewalls.

Look at different host-based detection.

How do those fit in?

Can you get any intelligence data out of those?

Do they even help you?

Do they help you maybe with the monitoring side or the detection side of things?

So understand how all the pieces are going to fit together before you actually put them in place.

And then go through and interview the candidate.

So have a committee of at least one executive person.

Have a bunch of people.

Don't have it just be the threat intel people because there are inputs and outputs to this program.

Again, going back to the position description, have other people, have people that you wouldn't even think should be part of the planning process of the team, have someone from HR come through and review it as if you were reviewing an actual candidate itself.

Because you're going to get someone looking at it through a different lens, which is key, another key to a successful threat intelligence program.

And then once you get there, hire it, implement it, get it going.

Have a standard as to how long it's going to take for you to get this program up and running.

What's the implementation strategy?

And as part of that hiring the candidate, you have to establish those performance reviews.

You have to establish what metrics you want.

Because remember, in the position description, we didn't establish criteria that was very strict, right?

We just said we wanted to reduce the amount of time from detection to the time of infection.

But now when you're starting your performance review and as part of the hiring candidate, remember you have to have something that can measure the statistics.

So therefore, you should be able to establish a baseline of the metrics that you're acquiring.

And then as part of our performance review, so in this phase between these two, they need to start to establish the metrics and start to establish your goals as part of your performance reviews.

So it's not without its challenges though.

And I know there's a few members of my team that are in here.

I like this Tuckman stages of group formation.

With any type of program that you have, you're going to have forming, which is discovering what CTI actually is.

You're going to have the storming.

We know we need it.

But how do we use it?

Then you're going to have the normalization, which is implementing the CTI for detection.

And eventually, you will get to the performance phase.

So keep that in mind that you may have some hiccups along the road.

You may get some personality conflicts both with people and programs or applications.

So maybe one person really likes one application.

Maybe one person doesn't really like the other application.

But eventually, as you start to progress, people get accustomed to workflows.

Maybe you're starting to establish those workflows.

And you'll get to the normalization phase and then eventually the performance phase.

So through these first three phases here, the teams are going to be reactive.

We mentioned that from the previous slide or one of the very first slides.

Your team will be reactive.

You'll find something.

You're going to go do an investigation.

Hopefully, you're doing some indicator expansion to find other pieces of the puzzle and then going back to see if that infection had spread or that compromise had spread in order to get ahead of the game.

Eventually, you will get to the point where you're starting to collect all this data and information.

Maybe it's through information sharing like, ISACs.

Maybe it's through just an organizational group that you've established.

But you'll start to say, hey, I saw this.

Did someone else see this?

Or you're subscribing to someone like Intel 471, something like that that's going to give you your tipping and cueing based on your intelligence collection requirements.

So you'll start to get that.

And hopefully, you'll get to the point where you're actually performing and you're driving actions before they actually happen.

I appreciate all your time.

Thank you.