The Intersection of Threat Intelligence and Business Objectives: Detect ‘18 Presentation Series

I'm Justin Swisher, Security Strategy Manager at Anomali.

I started my career as a civilian intelligence analyst with the US Air Force.

So I have a good background.

All of my training and intelligence came from the government.

That's where I started.

I really enjoyed it, until the red tape and bureaucracy kind of drove me nuts, and I had to leave.

Then I spent some time at a local ISP, building up their intelligence team and their network security monitoring.

I worked for a couple of big vendors, built out one of the largest network security monitoring grids-- about 2000 sensors.

I love networks security monitoring.

I could talk packet captures all day.

I won't today, but I could.

And then obviously, threat intelligence.

So what's the problem?

Why am I here talking to you?

Threat intelligence-- it's not really understood as a business function.

Organizations, they see this buzzword.

I need threat intelligence.

I need this thing.

Give me this thing.

And what do they do?

They go out and they hire intel analysts from the government.

And the intel analysts are very good at intelligence, but they're not great at business.

Because the government does not have the same objectives that businesses do.

And so, when you look at the business organization, who are your primary users of this threat intelligence?

Well, you have your executive suite, your CISOs, and your CSO, and your security leaders.

And they have a different level of intelligence that they ingest-- strategic.

And then you've got your threat analysts who, hopefully, are creating threat intelligence, which we'll talk about, your incident responders, and your SOC analysts, who are most often consumers.

And how do these users take that intelligence, those intelligence products, and action them in a way that supports the business?

This is last year's report, but these two numbers just crack me up for some reason.

So you've got 41% of respondents saying that their organizations are highly effective with threat intelligence.

But 69% of respondents say threat intelligence is too voluminous or complex to be actionable.

So how can you be 41% being highly effective, and yet almost 70% is like, we don't know how to use it.

It's just too much.

Those numbers don't really add up to me.

So hopefully, at the end of this talk you might be able to be in the percentage that actually knows how to use it.

So I always-- and Colin Powell stole my thunder.

He got it from me.

Not really.

Actually, it sounds way more official coming from him.

But a threat coming from the government-- it is something with capability and intent.

And I won't rehash it, because hopefully you enjoyed his keynote as much as I did.

But the other piece-- intelligence.

Intelligence is a supporting function.

In the government, you support decision making.

Whether it's a war fighter, a policymaker, an operator on the ground, someone who is making an acquisition decision, you are supporting them.

They come to you because you are the expert.

You have the information, and the insight, and the knowledge to provide something to them that they can go and make a decision on.

It's an activity.

It's not a product.

There are intelligence reports.

Intelligence itself is a process.

And so, Richard Clarke, super smart guy-- actually, I got to meet him in grad school.

His quote is, "Intelligence in general can be thought of as the complex process of understanding meaning and available information.

It's about reducing uncertainty and conflict." And I love that, because it highlights that it's an ongoing process.

It's not a thing.

It's not a piece of something.

So threat feeds are not intelligence.

Bite me.

You know what I mean.

No.

But they're not.

They're feeds of data, of information.

And intelligence is the process used to create knowledge.

That data, those threat feeds, that is an input to the process.

But it itself is not the actual product.

You have to contextualize that data to turn it into information.

And you do that with a threat platform, or a tip, or something like that.

Or maybe you do it with spreadsheets.

I don't know.

But you contextualize it, turn it into information, and then you analyze that information.

And that becomes knowledge-- knowledge that people can use.

That process-- all of those pieces are key.

And that's great if you do that very well.

And many intelligence analysts do that very well, even in a business.

The problem is when you need to transfer that knowledge to another person.

How do you do that?

In what form do you transfer it so that it's understandable, and specifically to that audience?

Reporting is a big piece of that.

We write intelligence reports, you get intelligence reports from your premium-- your iSIGHTs, your CrowdStrikes, Intel 471-- they're writing for a certain audience.

And you get indicators with context and analysis.

And signatures are another form of reporting.

But the target audience for that is a different set of people.

So this brings us to the business side of things.

In grad school, I had the joy of studying some-- I didn't get an MBA, but I had to take some MBA classes for some stupid reason.

And what I actually took away from that was a business intelligence course.

And as I was working through this in my head and coming up through the slides, it clicked with me that businesses and organizations actually do understand intelligence.

But they understand it in a very different way than we do as threat analysts.

On the left side, you've got the business intelligence.

They do market analysis.

Who is in my space?

What are the consumers?

What are the competitors?

What is the environment like?

What is the attitude like for this specific space I want to enter?

We, as threat intel analysts, we talk about the threat landscape.

Who are the actors?

What are they doing?

What are they targeting?

How are they operating?

Business intelligence looks at their competitors specifically.

Who am I going up against?

Are they entrenched?

Do they have a solid market that I'm entering?

Are they new like me?

We have our adversaries.

Are they APT?

Are they advanced and persistent?

Are they script kiddies?

We have to understand that.

The business looks at its competitive advantages.

What do I do that sets me apart from my competitors?

Do I do things better?

Do I do it fast, or do I do it cheaper?

Am I beating a need of my consumer in a way that my competitors don't?

As security folks and threat intel folks, we have our defense and detection systems.

Those are our competitive advantages against the adversary.

What visibility do I have?

What defenses do I have in place to counter them?

Am I countering the right things?

And then lastly, from a business intelligence side, you have to look at yourself and be critical.

What are my disadvantages?

Am I new to this space?

Are they entrenched?

Am my fighting for a market that is well-known?

If I'm going up against Kleenex facial tissue-- everyone calls it "Kleenex", but it's a facial tissue-- how do I go up against a business that is so entrenched that their product is known as the product itself.

And then as threat intelligence, we have to look at our vulnerabilities.

Obviously, vulnerability management, patching systems, but where my visibility gaps?

What are the things that I can't see, or I can't protect?

Or, for business purposes, I cannot patch because it would break the longstanding system or a longstanding process that would cost us money?

So I pulled this from the Joint Pub 2-0-- "Joint Doctrine for Intelligence Support to Operations." Because I think it's really relevant.

"Dissemination of intelligence reporting must be direct and concise with the command mission and the intelligence purpose in mind.

The commander should be able to quickly identify and apply relevant intelligence." What if we remove those two words, and changed them?

"Dissemination must be direct and concise with the business mission and the intelligence purpose in mind." The executive should be able to quickly identify and apply relevant intelligence.

It works just as well.

So you've got to think about the mission and the audience.

And we can do so.

But how do we do that?

So we've got to look at the business objectives.

We have to understand, what is the objective of the organization I work for?

What are they striving towards?

Well, these are six macro level business objectives.

And it's from a book, "How to Define and Build an Effective Cyber Threat Intel Capability." It's a pretty good book.

But I like this because it helps us identify those things that the business is striving towards, that we as threat intel analysts don't always think about.

So the first is to grow revenue.

A business wants to grow revenue, whether it's by increasing margin, increasing market share, whatever they can do to grow their revenue.

Also, lowering expenses.

That kind of goes towards the increasing margin.

But what costs can I cut?

What things can I trim to decrease my expenses and make sure I have a larger earnings-- was it earnings before income tax?

Whatever EBIT is.

Business stuff I don't understand.

And then also, reducing and mitigating risk.

The business really cares about that.

Customer satisfaction and retention.

Are my customers happy?

Am I losing my customers?

What's my renewal rate?

What's my retention rate?

How do I make sure that I stay high?

How do I keep them there and keep them involved?

Also, employee satisfaction.

This is important.

Your employees have a business.

They have your intellectual property in their head.

Oftentimes, they're the ones that really make that product great.

So you want to keep them around, because it's cost intensive.

If you lose them, you have to train up new people.

And lastly, compliance regulation-- the thing every business has to do.

So what can we do as threat intelligence analysts to think about these business objectives and align ourselves with them?

Well, we don't make money.

We cost money.

So right there, we're not going to really be able to help grow revenue.

We may not be to help with employee satisfaction, because security oftentimes makes them unhappy.

What do you mean I have to have an app on my phone with two-factor?

What you mean I have to do this wonderful computer-based training on phishing links?

They don't enjoy that.

And lastly, we don't interact with customers.

Especially-- as a threat intel analyst at a vendor, yes you do-- but as a threat intel analyst at your organization, you're not going to interact with the customers.

And do the customers really-- are they concerned about a threat intel team at Kleenex, at PMG?

The average customer is not.

So what can we do?

Well, we can provide input into risk calculations.

So we can help with the risk reduction and mitigation.

We can identify and contribute to purchasing decisions.

So help lower expenses, buy the right things, and buy the right things the first time.

Don't go out and buy all the things and hope that maybe one of them will work, and spend a lot of money.

And lastly, we can help ensure compliance.

It's not fun, it's not sexy, but it's definitely something that we should be involved in.

So we can directly support three of those business objectives-- lowering expenses, reducing and mitigating risk, and compliance regulation.

And this quote I like as well.

It says, "Good intelligence is a combination of information and insight.

The key to producing good intelligence is getting this combination right." So if we think about the business objectives we can support, then we can think about the type of intelligence we need to create to make sure that the executives and the leaders can make the decisions to exceed and move towards those goals.

And aligning ourselves is critical.

It provides a scope for collection.

And this, I think, is the first step.

It's the first real impact you can make.

Because, if you know the business objectives you're supporting, you can define the type of information you need to go get.

What threat feeds do I need?

Am I creating strategic intelligence?

And I creating operational or tactical?

It will define the types of data you need to go and get-- and not just get, but purchase.

Do I need to make a purchase decision on this threat feed?

Or do I need to go get all the threat feeds?

Chances are you don't.

So that definitely makes a big impact in purchasing for collection and getting the right data to start.

And then, it outlines the type of intelligence you're going to create.

Am I writing strategic reports to executives?

Am I supporting incident responders?

Am I supporting SOC?

Everyone's going to take a different type of intelligence.

And lastly, make sure you answer the right questions.

When the executive comes to you and asks a question, you're prepared.

You have the right data.

You have the right information and insight.

And you've combined it and prepared it in a way that you can give him that answer or give her that answer without hesitation.

And you have to tailor it.

So different objectives are going to require different products.

And matching your language to the intended audience.

And the executive may be a technical person, but they may not need that technical information.

And while a SOC analyst probably doesn't need strategic level information, but needs specific indicators with context to make good decisions.

So I thought I'd go through and give just a short example of each one to kind of give you, hopefully, an idea of what it might look like.

Obviously, every organization is different, and may look different to you.

But when we talk about the objective of lowering expenses-- so you have to come up with your intel requirement first.

So how would we do that for lowering expenses?

Well, we can identify threat actors most likely to target the organization.

Research their tactics, techniques, and procedures, or TTPs.

And align this information, this external intelligence with the defensive systems to identify our gaps and provide coverage.

So taking external intelligence, knowing what to research, who to research, and how they operate-- aligning it with what we know about our systems inside, and saying, all right, where are they going to hit us?

And do we have visibility?

Do we have coverage?

Do we have defense?

If we don't, why not?

And then, if we can do that, then we can say, how do we detect them with current tools?

And if we don't detect them with current tools, we're going to have to go purchase something.

What tools will be most effective in helping us meet this threat head-on, and give the executives an answer to say, here's what we need to purchase?

Based upon TTPs, based upon how they operate, based upon the vulnerabilities, our competitive disadvantages, if you will-- this is what we need to get.

This is going to cost x dollars, but this is the reason why.

So if you write that level of reporting to management, that's going to give them the ability to say, OK, I know why you want this system.

You've outlined it clearly.

Yes, it's expensive, but you've kind of given me a reason to go and purchase it.

And you've shown me that I don't need to go buy x, y, and z.

Or maybe we have those things.

We just need to redirect efforts so we can save some money and shift costs that way.

And at the operational level, you're going to kick out TTPs and behavioral patterns.

Incident responders, as you go into your forensics, look for these types of activities.

Maybe you inform a threat hunting team.

If you're at that maturity level, here are our TTPs, and behaviors, and patterns of activity you can go and hunt for.

And then at the tactical level, you've got IOCs and purchasing the right threat feeds.

If I know my internal systems, and the types of logs that I have from those systems, and the fields that exist within those logs, I can know what threat feeds to purchase to make sure that there's as close of a possible overlap, and then I don't have feeds of information I can't match against.

Or I don't have logs with no intelligence to match against.

The second objective is reducing and mitigating risk.

So again, let's walk through our intelligence requirements.

We have to research and identify the risk to primary sources of revenue.

What systems contain our highly sensitive intellectual property?

That information which if stolen, if lost, if, God forbid, ransomware encrypted it, would cost the business a lot of money.

What systems, if they went down for a certain amount of time, would cost large amounts of money?

Many SAS businesses and other businesses with operation cycles, they don't have the luxury of losing a system for maybe even an hour.

Or maybe you lose a system for an hour and it doesn't cost you too much money, but it cost brand recognition.

You have to help ask these questions and identify the answers.

And then, what actors target these types of systems?

There may be actors with an intent to target you, but if they don't have the capability against those systems, are they a threat?

If they do, what tools, specifically, are they using so that we can start to identify and report to management, these are the systems that, if they are hit, will cost us the most money.

Here's how we're protecting them currently.

Here's how we can do it better.

We'll need to purchase this.

Or we'll need to shift some resources this way.

Maybe we want human capital threat-- maybe we need threat hunting because we don't have live detection systems, but we can actually automate scripts and go out and search for activity.

And then at the operational level, you can help with patch management, prioritization specifically.

These systems need to be patched immediately.

Because if they're hit, we have huge problems.

Or we recognize that this system needs to be patched.

It can't for operational purposes.

So we need rapid detection and response on that system.

We need constant visibility and an understanding that if that system has an alert, that becomes P1 or P0.

And then lastly, the fun one-- compliance regulation.

Nobody likes this.

But it must be done.

So let's look at our requirement.

What do I need to do with my SEM to stay compliant?

What log sources are in my SEM?

Am I gathering the right ones for compliance purposes?

Do I have sources missing?

Maybe I have enough for compliance, but it won't cost us too much more to add this other log source that increases our visibility.

And identifying the relevant threat feeds that map IOCs to those event logs.

Again, if you've got the logs in the SEM for compliance purposes, you might as well make sure you're purchasing the right threat feeds, correlating them, and bringing them in.

And then at the tactical level, our product is probably going to look very targeted, very concise, and hopefully, contextualize threat feeds.

So when those alerts come into your SOC, they can make a decision quickly.

We support them in quick triage.

We'll talk a minute about intelligence collection.

So all those requirements drive that collection.

You have to define the questions you're going to answer.

If you don't do that, what happens?

If you just go out and get data without a relevant question, you're going to buy lots and lots of stuff.

Because you don't know what's within scope.

And we've seen this before at Anomali and working with customers.

We see-- and even before this, at other jobs-- you see, I want to do threat intelligence, so I'm going to go buy all the threat feeds.

Or I'm going to go just try them all.

Do you need to do that?

If you're asking the questions about the requirements and defining that specifically, you don't.

Because if you don't have a question, you're going to buy it all, and then go, all right, how is this useful?

I don't know.

I've got some logs.

I got some feeds.

We'll see what happens.

Maybe I get no hits.

Well, that feed's not useful.

Or maybe you get too many hits.

Well, that feed's kind of useful, but not really.

So you get rid of some.

And you say, this one had some hits, so I'm going to keep it.

And this one didn't have any, I'm going to get rid of it.

But I got to find more to replace that.

And you repeat that cycle.

So start with a question that you have to answer.

And hopefully, that question supports the business objectives.

And then you can find and get the relevant information.

And you make one purchase up front.

Or maybe you make a couple, and the business executives say, let's buy a little more.

Because maybe they don't understand.

But you can help them define, these are the ones we really need based upon intelligence requirements.

So a quick note on metrics-- I actually stole this from Travis's presentation.

Because he's my boss, so I'm allowed to do that.

Because at the end of the day, all of this work, all of this reporting has to have some value to the business.

I mean, that's what I'm hopefully trying to drive at.

And so you've got to ask the question-- and again, requirements, questions, they drive this-- how valuable is the intelligence we produce?

If you're asking yourself that question-- and then as an intel analyst for the government, there were times where I would get just some really dumb questions.

What are all the threats?

Where are all the cyber threats to the F-35 platform?

I can't answer that.

I mean, what I give you is going to have no value because it's going to be so broad that you're not going to learn anything.

So ask yourself that question.

And for me, when I wrote a report and nobody read it, that was like the worst thing.

So I had to ask myself, why was this not useful?

We need to ask ourselves that question.

How valuable is it?

How was it used?

Was it used?

Was it used correctly?

Did I use the right verbiage and the right language for the target audience?

Maybe the report would have been really valuable if I had changed the way I presented it.

What resources were used to produce it?

Did it take 15 analysts?

Did it take one analyst?

Did it take 100 threat feeds and one analyst?

What actually-- look at everything you used to produce a report and determine its cost versus its value.

And then, were there any measurable impacts?

Did you actually impact a purchase decision?

Did the executive say, yes, based upon this reporting, we're going to invest in this, or we're going to defend this.

Or did the hunt team come back and say, hey, that operational reporting on behaviors, we found a compromised system that we hadn't seen-- we didn't know was compromised.

That kind of leads to that last point.

At each level-- strategic, operational, and tactical-- understand the audience, how it should be used.

Is it being used the right way?

Is it supporting decision making?

Is it helping respond to impacts from threats from behaviors and patterns of activity?

And is it preventing it?

At the tactical level, I'm a big believer in rapid detection and response versus blocking.

But I know that blocking is often easier.

And organizations may not have the cycles to do rapid detection and response.

So are we preventing the right threats?

Are we preventing the impacts from those threats based upon intelligence reporting?

I'm probably done a little early.

We have to remember-- and this is something I've learned, and it's been difficult.

Because as a security guy, I just care about security.

I just want to do defense.

Like I said, give me a packet capture.

Let me figure out how they're communicating, and write signatures, and I'd be happy.

But we have to understand and be sure that we know that businesses are interested in reducing risk and growing profits.

At the end of the day, that's what a business must do.

They have shareholders.

They have a board of directors.

They have people they are responsible to, to make sure that they're growing their business in the right way.

We as threat intel analysts, hopefully, what we're interested in is protecting that business.

Defeating the attackers, keeping them out, that's the fun stuff.

Those don't always line up perfectly.

And so, the business is not going to change.

As much as we want the executives to change, and shift, and have our mindset of security, that's not going to happen.

So our goal should be to align with those business objectives as best we can.

Tailor it to support specific objectives.

Speak their language so that what you produce is relevant and actionable.

And start with requirements before collections.

Ask the questions to scope out what you need to get.

And lastly, is what I am creating intelligence?

This was something we asked ourselves and the government all the time.

Am I creating intelligence?

Or am I just regurgitating something I've read?

Am I taking that information and adding insight, adding my expertise and my experience, so that someone can read it and make a decision, versus reading it and go, I saw this before.

Or I could get this on the news.

You know how many times I heard that?

And make sure it's valuable to the business.

I'm done a little early, but maybe guys have a couple of questions.

Maybe not.

I'm open to questions if you have any.

I love when no one has questions.

Because I'm just going to presume that you all just knew exactly what I was trying to say.

And it just was in your brain, and you don't have to worry about questions.

Don't ask me a question, you.

[LAUGHTER] It's a good question.

So what was your question-- so what was your answer for the F-35?

[INAUDIBLE] Part of that answer is obviously classified.

The other part of that answer was, this question is too broad.

We need you to scope it.

What do you mean specifically when you say the F-35 platform?

Do you mean the aircraft itself?

Do you mean the ground support system?

Do you mean specific pieces of that platform?

So we would go back.

And we had collection requirements managers who would say, hey, scope it for us.

What do you really want to know?

You don't actually want to know all the threats.

You might think you do, but you don't.

There's something you actually need to know.

And so, by asking them those questions, they could then scope out what they really needed.

And sometimes you may have to do that with your executives.

Do threat intelligence.

Well, what do you really want me to do?

Do you want me to defend the organization?

Do you want me to help you make purchasing decisions when it comes to security tools?

What do you really need from me?

Because threat intelligence is broad.

And I could just end up sitting there, reading news, typing it back up, and sending it to you.

And then, who's providing value?

Thank you, Nicholas.

Yes?

[INAUDIBLE] Yes.

Usually.

So the thing is the-- the expectation from the [INAUDIBLE].

But one of the requirements [INAUDIBLE]..

Yeah.

You're the expert, you should be able to tell me, right?

So, if you want to prioritize these things on a scale of 1 to asked for intelligence on teams.

So what's your take on it?

On taking that F-35 kind of a question.

So you answered in a different way.

The business needs to know what they want.

But often, businesses will ask the question, hey, you are the threat intelligence expert.

Can you give some kind of a risk ranking for all the threats?

Yeah.

No, that's a very good point.

So what I have seen-- and again, this is my personal two cents, not supported by anybody but myself.

So blame me if it doesn't work-- is, that's where you have to understand the internal environment very well, and understand those business objectives to marry up, well, if I'm worried about risk and I know the organization has these systems that are critical-- IP, whatever-- I can align that with the external intelligence and the threats that I know about.

Maybe they have capability but no intent.

Maybe they have intent but no capability.

So I want to find those threats with both, and marry that up with what I know about the internal, and then prioritize it that way.

And to do so not just in a way that says, oh, APT-29 is our top risk.

What does that mean?

What does that mean to the business?

That's an acronym to them that maybe they know a little bit about.

But what systems do you need to purchase to mitigate that risk, or to reduce that risk?

Or maybe we accept that risk.

Is not always a great answer.

But maybe we that's a risk we have to accept and just prepare for in another way.

Does that help?

I'm a big fan of the Socratic method.

So asking questions to draw out the information they really want-- that's where your expertise of the threats and the internal environment-- and you sit down with them and ask those questions about, OK, what do you care about?

Internally, as a business leader, what things keep you up at night?

What things do you worry about?

Let me worry about the external threats.

But if I can understand what you're worried about, I can marry that up with the external and give you something that hopefully is a little bit more relevant.

So along those same lines, based on your lessons learned, do you have one or two practical recommendations for trying to create that synergy between the BI teams and the CTE teams?

Travis, do you want to answer this as you sneak out?

I actually do.

Oh, I thought you were going to sneak out.

I was like, he's leaving.

He's leaving.

Catch him.

Catch him.

So Travis is my boss and has much more experience than I do in the business sector.

So he will have a good answer for this.

A good answer.

A great answer even.

You're setting the bar pretty high.

I am.

So I ran into these kind of problems that you were alluding to and that your follow up question kind of goes to.

And what we had to do-- because I think we all struggle with this.

I worked at Exxon Mobil.

Management did not know anything about intelligence at all, as you'd expect.

I think that's the case at most businesses.

And so, they were really, to your point in the first question, they were expecting us to be able to provide requirements to them on what we were going to produce.

And we eventually, after struggling with them and trying to explain intelligence to them and stuff a bunch of times, we finally just took ownership of that.

And we were like, OK, here's what we're going to do.

We understand, on some level, what Exxon Mobil does.

And we understand, probably, some threats to that environment in various contexts.

And so we're going to just come up with our own stab at what these requirements probably look like.

And we're going to go through the process of spelling those out, developing collections, going through the threat intel lifecycle, basically.

And we're going to produce something.

But we're going to hammer them on feedback.

They're not going to volunteer the feedback.

Maybe they are.

Maybe you have the type of management that's going to come back and go, well, I don't know how this is useful.

I mean, thank you for doing this, but-- well, then you start asking questions, to Justin's point, like, well, what would you like in there?

What would make this better?

You know you mentioned x.

We have y here that sort of has some overlap with that.

But what is it that you really want?

And I think if you iterate through that process a few times of trying again and being like, OK, how about this?

You asked the question about the thing you saw on 20/20 last night.

We came back with an answer that's contextualized to this environment.

What do you think of this?

Does this meet your expectation?

And if so, the follow up question is, what action or decisions are you able to now make as a result of this intelligence we've been able to provide you?

So you can try to gauge the value of what you've been able to provide for them.

And I think, as you iterate through that, and you just continue to build that rapport with the business-- whoever the consumers are that you're going to be talking about-- I think over time, you get to a place where they're like, this is there's actually pretty awesome.

This is what we're looking for.

We're able to immediately do this, this, and this, and make these decisions as a result of this.

Keep up the good work.

Thanks a bunch.

Or hey, we liked all this, but we would really like to see a little bit more in this area.

OK, great.

We can tune what we're doing to address that.

Hopefully that-- it's not a great answer.

But there's not a great answer to that question, unfortunately.

But that's a really good point.

It's going to be a little trial and error, hit and miss.

Based upon what you said, here's something.

Is this valuable feedback?

Soliciting that feedback is going to be really critical to tone the process and hone the information down to something where they do say, yeah, this is great.

Thank you.

More of this.

Or maybe they might say thank you, they may not.

It's the executive.

But I was blessed in the ISP when I came out of government.

My executive there came to me.

We were building a third intel team, a few of us.

And he said, your job is to keep me safe.

That's what he said.

It was broad, but he understood what intelligence was there for.

Fill the detection systems with signatures.

Make sure that we had the right IOCs, that we had the right context that the SOC analysts could come to us with an alert, ask a question, get an answer, and take action on it.

So I was blessed to have that right out of the gate.

Was former GE.

So they, as I'm sure you're aware, have had a long history of fun with APT actors.

But that really helped me out.

And so it made the transition from government intelligence to threat intelligence in the private sector much more smooth.

And I know some people may not have that easy path.

And hopefully, you take something away from this today.

Anything else?

Going once?

Twice?

Sold.

Thank you, guys.