Episode 08 of our podcast is here! Veteran security researcher Rich Barger joins hosts Will Gragido and Thomas Fischer for a conversation on the less discussed, non-shiny side of threat intelligence operations. With a long background of research and leadership positions at Splunk, ThreatConnect, the Intelligence and National Security Alliance, and more, Rich brought a wealth of knowledge on the ins and outs of threat research, analysis, and intelligence operations to our discussion. Tune in below to get tips for optimizing your own threat intelligence program and subscribe via iTunes to keep up with new episodes every month.

Highlights from this episode include:

• 1:45 - Getting started on the "unsexy side of threat intelligence": defining requirements
• 5:30 - The difference between operational threat intelligence and strategic threat intelligence
• 8:30 - Measuring the efficacy of threat intelligence programs and demonstrating value
• 12:00 - Strategies for improving the quality and usability of threat intelligence
• 19:00 - Finding the right mix of internal and external sources of threat intelligence for your organization
• 24:00 - Questions to ask when evaluating and acquiring sources of threat intelligence

Intro/outro music: "Groovy Baby" by Jason Shaw, licensed under CC BY 3.0 US

Transcript

[0:00:08.8] WG: Welcome to episode number eight of the Digital Guardian Podcast. My name is Will Gragido, I’m the director of advanced protection here at Digital Guardian. With me today are Thomas Fisher, principal threat researcher, and our very special guest from Splunk, Mr. Rich Barger, formerly of ThreatConnect. Guys, welcome to the show.

[0:00:28.2] RB: Thank you.

[0:00:29.4] TF: Thanks.

[0:00:31.7] WG: Thanks for joining us Rich, and thanks to Thomas who’s joining us from the sweltering heat of London Town, where it is 86 degrees for all of you in America, but where the rest of the world acknowledges —

[0:00:43.2] TF: 32 for those in Europe.

[0:00:44.9] WG: That’s right, 32 around the world with the exception of North America.

[0:00:49.1] RB: The pavement must be bubbling.

[0:00:51.2] WG: Right.

[0:00:51.7] TF: Yeah, the train tracks are stopping because it’s too hot. This is England. It never gets this hot.

[0:00:57.7] RB: Why is it not raining?

[0:00:58.9] TF: I wish I knew. I wish I knew.

[0:01:01.9] WG: Yeah, it’s just a global — Climate change and all that kind of good stuff. So yeah, we’re here today to talk about the unsexy side of threat intelligence and what that means for practitioners, what that means for dedicated research professionals, teams, organizations dedicated and focused on that initiative. All those thing that go unsung, all the day-to-day back office sort of aspects of threat intelligence that don’t necessarily make it to print in the form of media reports or news stories. Without which, there really would be nothing of substance.

Rich, why don’t you go ahead and give us some of your thoughts on some of the unsexy side of threat intelligence?

[0:01:59.1] RB: Yeah, that’s great to be here and talk about that. I’d always kind of kick things off to talk about requirements. A lot of folks just don’t really sit down and talk about what they care the most about. There’s been a lot of thought pieces that I’ve seen in recent years that people highlight the importance of requirements or building requirements. I wonder if there’s a lot of pragmatic content for folks to kind of really sit down and talk about what it is it that keeps the boss up at night. What are the major things that the company is doing currently is going to do in the next 12 months that people care the most about or that resources are being allocated towards?

People can start to align the technologies by which business operations are conducted, the security controls by which that traffic and content or data flows through. Then, at the end, what are we trying to protect and why? Because once we know that sort of thing, once we know what sort of questions we want to ask of our data, we can start to approach it and interrogate that data, come up with schemes by which we’ll collect it, organize it, and then start trending towards more of those sexier side of things. How it’s analyzed, the analytics that go into it. How it’s produced, the report which has the gee-whiz, flash-bang, so what story that comes out. To your point, there’s a lot of things that go into making the sausage.

[0:03:34.2] WG: That’s one of my favorite analogies for — You don’t need to know how the sausage is made, you just need to enjoy the sausage. Yeah, to your point, if we had to have a definition for the unsexy side of threat intelligence, I think it would be all those things that are truly unsung and that really most people who are consumers of threat intelligence are not likely to be interested in. To your point, the prioritization of things, in order to avoid boiling the ocean. How things apply? How threat intelligence is structured and organized by virtue of the requirements that you spoke about earlier. How those requirements reflect our — How they reflect our understanding of our critical assets, right? Whether or not those assets are mapped against our overall and overarching risk postures, whether we’re an enterprise organization or whether we’re organizations that are providing that intelligence for consumption to enterprises.

All those things are very important. Collections, for example, is a huge factor. Whether or not people truly understand that there is a very artful and scientific way to approach collection with respect to all sorts of information, and then the distillation of — The discounting, the implication, all those kind of good things with respect information as it is incorporated into our back-end ecosystems for the express purpose of assimilation. Into it, some form of tangible or intangible intelligence. Those are important things.

Thomas, would you like to add anything before we kind of go off on any tangent here, while my coffee kicks in?

[0:05:06.2] TF: What you were saying, when we’re discussing this unsexy side of threat intelligence, there’s one thing that comes up — Well, for me, comes up often, is the idea behind an operational threat intelligence aspect of what you’re dealing with, versus a strategic threat intelligence. Those are two different things. They feed each other.

Rich, I kind of like to know what you think about where that difference lies between operational versus strategic and how you would actually deal with those difference, because one is very much focused on the aspects of actually implementing that for intelligence versus the other, which is more focused on protecting those critical assets based on what you’re giving us as threat intelligence.

[0:05:49.1] RB: Yeah, great question. I think, really, at the end of the day, it comes down to what sort of decision are you trying to enable. What sort of a factor you’re trying to deliver. If it’s the SOC or the IT department, or maybe some of the GRC guys that are trying to kind of lift their heads out of checkboxes and spreadsheets and get a little bit more for leaning, there might be a little bit more — More of an operational focus where if the board is asking or other non-standard security players, like finance department or MNA, the group that does MNAs is asking, “Hey, should we enter into this agreement? What have seen over here with an open office, in this country? What sort of things should we look out for?” That might dictate the type of production produce or work product that you produce. It might require you to do more — A strategic product might require you to do more strategic or longer term retrospective analysis of various events, maybe you include other folks within your specific sector to get kind of this aggregate picture of the overall issue.

Whereas, more operationally focused product is going to be a little more concise, maybe a little more technical in flavor. It’s going to address a specific type of consumer versus a strategic decision maker.

[0:07:13.9] WG: Right. Once we achieve that prioritization right and we do have an understanding of who our consumers are, who the decision makers are who are actually going to be able to pull that proverbial tricker who onboard our technology and subsequently consume our intelligence within their various and frameworks. What do we need to do, or what do we need to stress with respect to the business value of that intelligence and the processes that go more or less unsung?

They really do claim to that idea of the unsexy side. How do we properly express the value of taking the time to go through those prioritization exercises and really understand deeply and widely the impact and the effects that adversaries have on that prioritization and political aims have on that priority and the nexus points that exist on a global basis between those things. How does that play into things in your experience, Rich? How do those things play into collections and onboarding with respect to source identification?

You and I have talked about has the value and the virtue of thinking people to live off in the land versus necessarily going out and being dependent upon third-party intelligence, whether it’s open-source or commercial exclusively, right? How do we factor all that together to make more informed decisions with regards to threat intelligence while, still, at the same time, paying close attention to those things which are more or less unsung?

[0:08:34.6] RB: Okay. You got a lot of stuff buried in there. I’ll try to pull it apart as best as I can. I hope I don’t forget anything. I really think kind of the answer your first question, is really goes back to kind of the feedback loop and really making sure that as you produce and answer those questions or against those requirements, that you’re checking in and saying, “Hey, did I do?” If this doesn’t scratch the itch, how could it scratch the itch? Then going back and evaluate, “Oh, man. Maybe if would have added proxy data to that,” or “Hey, maybe I should collect my DNS data, because I would have had much more understanding as to like maybe this command and control method or something like that.

Being able to dissect where you’re producing really well and where it could be better, versus just producing for the sake of production. Back in the day, in the ICU, it’s like product or perish, but then you had these shops that would just kick out all sorts of reporting. That was really not much value, it’s just getting points on the board, but none of those were really effective.

That feedback loop, in my transition over to Splunk and building a product that is delivering content to help folks make decisions, interrogate their data and ask questions, we’re really adopting a lot of engineering principles into the agile method and being able to incrementally produce. Through that incremental approach, we’re always getting feedback and we’re synthesizing that feedback on including or making the product better.

I was really thinking, it’s like, “Man, what would happen if the intelligence community of the threat intelligence community really adopted similar principles that come out of the software development practice and adopt some of those to synthesize some of the feedback,” because it’s very quick. It’s very tight. What was the kind of the second halfway of your question?

[0:10:28.8] WG: Yeah, the second half was really more aligned to the lines of once we’ve kind of go through those exercises and really kind of clearly articulate the value proposition that’s demonstrated by all those back-end, diverse back-end exercises that are more or less unsung and unseen that have a very non-intersection between threat and adversarial activity on a global scale with political influxes. All source versus exclusive machine-oriented sources are things of that nature, right?

How do we best communicate that and how do we continue to stress the value? This is an important question for threat intelligence producers. I’m hesitant to say manufactures, but for those organization that produce threat intelligence as a primary consumable product or service. At the same time, it’s also important for consumers downstream to understand, because, again, the valuation of intelligence is there’s a lot that goes into that work if it’s done properly. To your point, thoroughly. It’s much more than just assembling a CSV list of IPs and domains and kind of kicking it off and sending it downstream if you’re conducting true intelligence work, the analysis work.

I’ll let you go ahead and finish your thought.

[0:11:36.8] TF: Can I just add to that, Rich? There’s also what I’ve seen — Will is talking about all these providers. From my book, there’s almost a lack of taxonomy as well. A universal kind of discussion on universal categorization and universal way of presenting that data. For me, that’s part of this discussion as well of how can we consume the information properly.

[0:11:59.7] RB: Just so I understand, Thomas, was that a follow up question to Will’s — Sorry---

[0:12:04.7] TF: Yeah, it’s a part of Will’s question. Can we actually — The feeds that we’re consuming, all the intelligence that we’re consuming, can we actually — Is there a way that we can make it better so that it’s actually usable in a more coherent way, because there’s a lot of — Will mentioned CSVs, or I guess IP addresses and just some of the information that we get, we might get from three different providers. It’s the same information, but it’s categorized or it’s presented in a different way so it just adds more work to what we’re doing.

[0:12:38.7] RB: With that, that kind of goes back to a talk I gave at Sans last year under the threat connect banner in terms of where we place the most value. In the process or the product? Is it the methodology? The analytic methodology and the tradecraft by which I produced the indicators, or the indicators themselves that provide the most value.

I argue as to like where we are, kind of this intersection on our industry. It’s like, “I’m going to get more value and knowing kind of the tradecraft or the analytic that you’re using consistently, especially if it’s a very ubiquitous and I can apply it across — If it can help me catch an APT actor as well as a criminal actor or other sorts of things.” Really focusing on that technique versus this perishable indicator that has more value to me, that has more shelf life in terms of being able to target and detect and investigate something, because it’s a learnt behavior. I can roll and new hash. I can dispose of a new IP and set up a new hop very, very quickly and be on my way.

To go back to kind of what Will was talking about in terms of being able to prioritize and kind of know the value of what is being produced, I think maybe even modeling in a micro instance of what the intelligence community and how they leverage the national intelligence party framework, which is basically is communications between the President and The National Security Council basically say, “These are the things that keep me awake at night.” We’re going to allocate budget and we’re going to allocate time and we’re going to allocate people into answering into all these questions in these various buckets.

That is how — As you go about that and you invest towards answering that question, you can say, “Hey, I just bought this sort of technology and it’s supposed to be answering this thing. Oh, by the way, I bought this feed, and it’s not answering this question which I thought I would. You know what? I’m not going to pay for this next quarter. Maybe I’m going to hire a person to do that for me.”

You could really start to kind of make the business decisions in around the production and or the consumption of the intelligence depending on where you sit in that ecosystem.

[0:14:46.3] WG: Yeah, I think those are important considerations. That brings us to another point which I think is important to kind of introduce and broaden here, is like how much of the tradecraft from the traditional world of intelligence analysis is actually understood and beyond being understood and applied in the “backend”, in these providers for the expressed purposes of the collection, or the aggregation, the normalization, the duplication, and the multi-dimensional analysis that leads to confidence and veracity in that intelligence.

How much of that is occurring in your opinion? You think that people are actually putting forth that type of effort or do you think that we’re somewhat weak in our game when it comes to —

[0:15:35.3] RB: I think it’s like a philosophical discussion. It goes deep, man, because if you got to think about, there’s these competing equities, especially within public and private sector. Public sector isn’t going to share sources and methods, because that usually is within the classified channels and they’re going to — From a national security perspective, you don’t want to give up your goodies there. From a commercial perspective, sources and methods, there’s a thing that makes me unique and keeps me in business.

Again, I’m not in an advantage to give that away because my competitors can do it. Although, my consumers might gain a greater confidence in my work product if they know the real deal behind how I got it or where I’m getting it or the decisions I made around it.

You have those respective equities completely aligned against what are we trying to do at the end of the day and to better serve and protect our networks. It’s how do we deliver against that purpose knowing that we have these challenges both on the public and private sector. At the end of the day, if I can share these awesome detection signatures and I can share and the method by which I investigate it and I can share the recommended mitigation actins all in an encapsulated product that just says, “Here, depending on where you sit, from tier one to tier three, and maybe even at the C-level or director level in between, these are all the things you need to make your respective decisions. Now, go.”

How much quicker would we be? How much more agile would we be? How much more could we reduce the surface area of the problem if we didn’t have to kind of worry about those equities that I talked about a little earlier.

[0:17:28.1] WG: Yeah. Thomas, what do you think? What are your thoughts on those things?

[0:17:31.8] TF: I’m trying weigh the idea. My fundamental issue is a lot of times we just don’t have teams or the people to do that as a full-time job or to actually invest the time into learning and better understanding what intelligence is coming in. A lot of times it’s firefighting right? You’re tending to the latest attack or you’re tending to the latest attempt to bridge your data or to steal your data. It becomes complicated because you are technically gathering all that intelligence, your own intelligence, plus you’ve got all the external intelligence that’s coming in, but when do you actually have time to be able to process it properly? Unless you’re a dedicated team to it. That’s not necessarily feasible for most organizations.

That’s where I’m kind of little bit stuck on how we actually can get this done properly and where that tradecraft can fit in and how we can get people up into the trade and into understanding what needs to be done. It’s a lot more complicated with just saying, “Yeah, we can do this.” That’s where I fall through. I’ve been in operational roles where I was doing incident response and you wish you could get to that phase where you do the review of the incident and you can actually pullout the proper indicators — A few times out of 10, you’re not going to be able to do it because you’re just fighting the next fire.

[0:18:59.6] RB: Yeah, I think what you’re highlighting is kind of the trough between the consumers and the producers. The producer’s problems are not the same problems as the consumer. I think that’s a good break down.

[0:19:17.4] TF: Then it raises, are we dependent too much on producers, external producers, and we’re not just — We’re just gathering all that data and feeding all that data that they’re producing into our systems or into our process and then we’re just overloaded with too much noise. Is it just also drowning that attempt to actually get something done properly in your organization?

[0:19:36.7] RB: I think you’re right. It’s kind of an unintended consequence, because in the consumer’s quest to find the easy button, they almost make the problem worse because it’s additional signal that seemingly produces more noise for them to go through.

[0:19:56.8] WG: Yeah, it’s a valid point. Again, I would argue that — Like Rich having worked for multiple organizations whose hearts of whose missions were absolutely dependent on being an upstream provider, a creator, origin source of intelligence. That the burden is on the provider to provide that quality. Consumers have to ask themselves, to Rich’s point earlier, about living off the land. How much information they’re actually harvesting from their own ecosystem, from their varied and sundry endpoints, from their network devices, their servers, etc., etc. You need to be able to take advantage of all those things that are either traditionally acknowledged as being sources of intelligence or untraditionally look that as being sources.

At the same time, they also have to be informed about where they understand their gaps are and then what sources they’re looking to from a third-party, whether they’re open sources. We all know some of those are going to be far better curated and managed more time than others, or commercial sources. Wherein the tradecraft, I think, comes really much more important and it plays a much greater role in producing high-fidelity actionable intelligence that is meaningful.

I think that that’s something as an industry — And I’ve watched, I’m sure you guys have too, watched this thing become its own industry, threat intelligence, and kind of really been curious because you know from experience that there simply aren’t that many actual intelligence analysts who have kind of matriculated between the traditional intelligence community space and the digital, the data front and security front, and then gone off into the private sector to kind of produce these organizations.

That is where the tradecraft I think becomes really important to me is that when we talk about fidelity on all that back-end work, all that research work that may or may not be dependent upon automation or collection vehicles of various types and processes dedicated to normalization and aggregation and duplication.

When we talk about tradecraft, is that the missing link when we’re actually talking about threat intelligence. In a lot of ways, I think it is. I’m curious about what your opinions.

[0:22:11.6] RB: I think the tradecraft, it speaks to the management of collection assets. What’s the business automation that I have to run in my network anyway? This kind of goes back to your notion of living off the land. I got to have a web. I have to have email. I have to have DNS. That is just a basic kick. To have a company nowadays, I probably have to have those sorts of services and protocols to be effective.

Because I’m doing it anyway as a security practitioner, now this gives me surface areas and/or control points to look for things and/or stop the bad man if I know what I’m looking for. Really being able to understand what those are, think creatively as to what surface I have, be at my endpoint, be at proxy infrastructure, whatever it might be. Thinking creatively about what sort of questions do I want to ask. Where I can ask that question? How complete is my picture? If it is incomplete and I can’t answer some of these specific questions, what do I need to do in terms of process? What sort of people do I need to hire or train up in terms of being able to add some analytic horsepower behind something?

Again, since you’re down there anywhere, since you’re already leveraging this business automation, how can we just turn it on its head and also use it for various security use cases as well?

[0:23:37.9] WG: Yeah, those are really good points. I think those are very good points. I think we don’t often times trust enough, to your point, Thomas, and to your point also, Rich, about the value and living off the land, and really looking into those data sources. DNS is a great one. Taking advantage of those things and really tapping into things that are already at our disposal.

What sort of questions should organizations be asking themselves when they start looking at product platforms, when they start looking at third-party providers or threat intelligence so they can make the most informed decision with respect to selection and acquisition of a source or a platform predicated on threat intelligence. What do you think are the most important questions that perhaps the uninformed buyer or, at best case, the informed buyer needs to be asking?

[0:24:30.3] RB: Yeah, I’m trying to get this back to the unsexy side of it. Maybe it’s controversial, but I’d say can I do that too? Based on whatever vendor; X, Y, Z is presented to me, do I have the manning, do I have the technology? Do I have the time and resources really to do this? If the intent is there, in some degree, the capabilities there, then really looking to — Again, try to look at those specific technologies or specific types of problems.

Being able to queue and leverage multiple sources of data, so my web and DNS data might be in great place to look for command and control. My email and web traffic might be a good way to look for inbound attacks. If something evil is going to come in, likely going to be there. Sure, there’s other ways, but maybe this is a starting point. My end point, what sort of coverage do I have there. Are there some users I want to watch closer than others? Just really being able to think about how can I do this, how can I do this smartly? What can I leverage on my own? If I am resource constraint, then maybe it makes sense — Either way, if I’m resource constraint, I got to do it on my own or I got to pay someone to do it for me. Those are sort of the decisions that folks have to do it. I don’t know if that’s a good answer or not. I’m trying to fit it in to the unsexy side.

[0:26:12.9] WG: It is unsexy. Because, again — You did well actually Most of the things that I think I’m more overtly and probably you are as well, and I think Thomas is as well, our concern about is really your earlier analogy, which was an apt one, is what’s going on upstream at the sausage? What are your ingredients look like? Where are you sourcing those ingredients from? Sure, I want to understand and enjoy the product, but if I’m an informed buyer who’s got limited time, resources, or energy, or who just simply want to make sure that they’re actually playing their bets on the best available provider as possible, right? I want to understand those things. To the best of my ability to understand those things. I would argue that, typically, those are things are not sexy.

[0:26:54.6] RB: I think when we talked about kind of the upstream, what about — Does the quality of the upstream affect the quality of the downstream? Again, if you’re not putting all the pieces together, if you’re not even looking on the right places, what can you expect? I always riff on people about just how important — Again, the collection management, signature management. How often are we revisiting this signature? Where are we placing the sensor? What are seeking to collect? That is super unsexy. Nobody likes managing that and revisiting and refreshing signatures and testing them and making sure they’re accurate. That is like the dirty work.

Again, if I’m putting all these sensors out and they’re just alerting on all sorts of crap, what do you think my SIEM experience is going to be like? That’s my point, is just like to really focus on sharpening the axe on the frontend, because as that stream flows down, that poor soul sitting in front of the SIEM who has to make real-time decisions as to how I dole this out and how I triage. That’s his or her decision making cycle. It’s going to be impacted.

[0:28:10.1] TF: I think that’s one of the things that we didn’t really talk about is, up till now, is aging. Intelligence has its own lifecycle. It’s not valid all the time. There’s going to be fluxes around when it’s useful and when it’s not useful and how often it repeats or it doesn’t repeat and you want to actually fine tune your process so you can actually age all that information up, because something that you thought was potentially bad at one point in time after reviewing how the business operates or some of the business workflows, you might actually find it’s normal operating environments and it’s something that you should normally see in your senses. That’s a good point.

[0:28:50.6] RB: It also kind of speaks back to the tradecraft. Again, if I give you a really tight signature or I can give you a really good Splunk search, how long is that going to last you versus if I give you a spreadsheet of random indicators? Is that something that you create a dashboard around? Is that something you can deploy and/or share with others and have them look for other things and give you feedback on and tighten it up overtime, or fork it for secondary or tertiary sort of lookups. That’s why I just feel, at this stage, in terms of threat intel, it’s not like one over the other. You just use — I’m not like bashing indicators, because there is some utility —

[0:29:31.5] WG: You can go ahead and bash indicators. I bash them all the time. I’ll be honest, I hate indicators, because indicators are good at one point in time, right? Those indicators change, and they change quite rapidly in this environment.

[0:29:45.8] RB: But that’s all you do, is you tuck that in the back of your head and really — It’s all in the context of what are you looking at. Because if you say, “Hey, I’m looking at this saying, but it’s within the window of ‘You know what? I don’t think they would have changed that fast,’ or ‘Hey, this lines up exactly with what we saw over here.’” The indicator proved its value.

However, if it’s — Again, I guess it’s the name talking point of bashing indicators is age. I might be able to leverage a lookup table with a technique — A lookup table with indicators with a specific technique. If I happen to see that, I have so much more confidence in whatever that alert is, because I have the best of both worlds. I have a PowerShell Splunk search with a handful of indicators that I know is tied to a specific group. I can say, “Damn, I got a technique, and I got an indicator. I got the best of both worlds confirming and denying that that thing happened, or confirming that that thing happened.

[0:30:43.3] TF: You’re raising the — I’m missing the word. The confidence of that alert. You’ve just upped your game because you actually say, “I’ve seen both these things, so I know that this is more likely to be real than something that’s only got one of them or something that just happens to trigger on an indicator.”

[0:31:01.2] RB: Absolutely, and you’re further down in your investigation chain because you have context in that scenario because you say, “Oh, okay. It’s this specific group.” I can say, “What is that group tend to do, or what do they tend to go after?” Now, I know kind of what my next step or my next place to go to look for something could be, because I’ve got a starting point to that alert versus power shell. Okay, power shell what? Power shell APT? Power shell criminal? Where do I go with this?

[0:31:28.5] TF: Yeah, fully agree.

[0:31:29.9] WG: Yeah, those are all valid points. Yeah, I think too just to kind of — Not to beat it into the ground, but I do think that there is a time to life in many instance with indicators. Some people obviously — Some organizations, some threat actors and adversaries leverage them more regularly and for longer periods of time, share them. Then again, in general, those are the minority. I think you’re absolutely right.

Guys, for getting up on the 30-minute mark, why don’t we go ahead and consider pointing out some final thoughts and closing thoughts on the topic today, which is the unsexy — Those unsexy aspects of threat intelligence, and why we need to be caught in some of those things when we’re making our decisions for incorporation, selection, and adoption.

[0:32:13.7] TF: One of the things that we didn’t really talk about on the unsexy side, especially for the more technical people, is the business process. I think it could be the whole subject of a separate podcast essentially, but business process needs to fit into this somehow because understanding how the business works and what the threats and the risks that the business takes can substantially help you build that threat intelligence and improve that intelligence which how you’re placing your senses. That would be my final thought, really.

[0:32:47.0] RB: I concur with that completely. I think that that actually could be something that could be used to empower and make the case for intelligence in terms of an investment area, because that allows you to speak to decision makers and into the board. If an analyst is able to frame context, the intent of the attacker and the context is to whatever technical capabilities they were leveraging does not matter to an executive. He or she does not care. All they want to know is what are they after? What are they trying to do? Why and how are we going to stop them?

All that geeky stuff can be for us to ooh and ahh over, but at the end of the day, if a technical analyst is able to immerse themselves into the business to understand what the product lines are, to understand what the company is trying to do, what are some of the objectives for the company in terms of what they’re doing in the market and that sort of things. All of that can be used to produce a better work product and to frame whatever that thing that they’re working on to better articulate the need for what they’re doing and justify their efforts and really sell internally the value that is threat intelligence and/or security.

I think the answer is out there somewhere, but where is it that we can flip and turn the assumption that security is just a cost of operations? It’s just a sub-cost. Now, how can we turn this into some sort of business value where the company is making decisions based on that information, or is able to do something with that derivative data where they can actually make the company money versus just be a call center.

[0:34:37.4] WG: Excellent. Guys, thanks very much, Rich, to you and your team at Splunk for taking time to be a part of this podcast. We hope to have you on again soon. Thomas, thank you as always for participating. Your insights are very very valuable.

For myself, Will Gradgido, I want to say thank you to our corporate sponsors. Also, for everyone who’s out there listening. Please let us know what you think of the podcast. We’re open to your feedback and we hope to hear from you soon.

On our next podcast, episode 9, we will be hosting Mr. Nick Selby of Street Cred Fame, and we’ll be talking about a variety of things that are related to law enforcements, the intersection of data protection, threat intelligence, adversarial cognizance and a whole list of other things. Thank you very much for your time. Stick with us, and we’ll see you soon.

[0:35:23.1] TF: Thanks, everyone.

[0:35:25.0] RB: Thank you.

Previously on the Digital Guardian Podcast

• Episode 07: The Future of Authentication with Wendy Nather
• Episode 06: WannaCry, Patch Management, and Third Party Risk with Dave Lewis
• Episode 05: Lessons Learned From CISOs - Security Priorities in 2017 with Rafal Los
• Episode 04: The Current Cybercrime Landscape with Dan Cohen
• Episode 03: Privacy in 2017 with Adrian Mahieu
• Episode 02: The Yahoo! Hack Indictment, Vault 7 Leaks, and Emerging Threats featuring John Pirc
• Episode 01: RSA Recap and the Google/Uber IP Theft Case