The Cyber5 Podcast

EP77: Moving a Security Team Beyond IOCs and Positioning for Stronger Outcomes

Episode 77 | July 6, 2022

In episode 77 of The Cyber5, we are joined by our guest, Eric Lekus, Senior Manager for Threat Intelligence at Deloitte. Eric delivers for Deloitte’s internal security team and is not a client-facing consultant.

Episode 77 | July 6, 2022

In episode 77 of The Cyber5, we are joined by our guest, Eric Lekus, Senior Manager for Threat Intelligence at Deloitte. Eric delivers for Deloitte’s internal security team and is not a client-facing consultant.

We talk about how to evolve cyber threat intelligence in a SOC environment, beyond basic indicators of compromise (IOC) integration. We discuss the different stakeholders a CTI team has beyond a SOC, but also focus on what a CTI team needs to push and pull from a SOC to be relevant for a broader audience. We also outline success metrics for a CTI team.


Here are the 4 Topics We Cover in This Episode:


1) Indicators of Compromise are a Baseline Activity, Not Holistic Threat Intelligence:

Indicators of compromise consist of known malicious IPs and domains. Stakeholders expect security teams to be doing this as a baseline. However, IPs and domains can change in the matter of seconds so it’s not fruitful to only rely on IOCs to be integrated into a SIEM that alerts with other network traffic and logging.


2) A Security Operations Team Already Has A Rich Source of Baseline Activity; Enrich with Threat Intelligence:

Security teams should be integrating many sources of logging, such as IPs from emails, using threat intelligence to alert on malicious activity. This should then establish two-way communication where a threat intelligence team is pulling information from the SOC to enrich and provide feedback. A SOC team is generally writing tickets for alerts and a threat intelligence team can’t just ask for bulk data; therefore automation to integrate into threat intelligence platforms is critical. A SOC analyst will ask, “what’s in it for me” and a threat intelligence professional should address this.


3) Threat Intelligence Should be a Separate Entity from the SOC; They Have Numerous Customers:

The following services are generally associated with cyber threat intelligence teams. Since the SOC is a major stakeholder, the CTI usually has the following functions:

  • Adversary infrastructure analysis
  • Attribution analysis
  • Dark Web tracking
  • Internal threat hunting
  • Threat research for identification and correlation of malicious actors and external datasets
  • Intelligence report production
  • Intelligence sharing (external to the organization)
  • Tracking threat actors’ intentions and capabilities
  • Malware analysis and reverse engineering
  • Vulnerability Research and indicator of compromise analysis (enrichment, pivoting, and correlating to historical reporting)


4) Success for Security Teams Means Reducing Risk Through Outcomes:

Regardless of who the stakeholders are in an organization, improving security should be focused around reducing risk and influencing outcomes for disrupting actors. This should be accomplished in alignment with the executive team and the culture of the organization. Showing how you are reducing risk over time is what makes threat intelligence teams successful in the eyes of business executives.

Listen to other podcast episodes

Read Transcript

LANDON: Welcome to the Cyber5, where security experts and leaders answer five burning questions on one hot topic in actionable intelligence enterprise. Topics include adversary research and attribution, digital executive protection, supply chain risk, brand reputation and protection, disinformation, and cyber threat intelligence. I’m your host, Landon Winkelvoss, Co-Founder of NISOS, a managed intelligence company.

In this episode, I talk with Senior Manager of Cyber Threat Intelligence at Deloitte, Eric Lekus. We talk about how to evolve a cyber threat intelligence in a security operations center environment, beyond basic indicators of compromised integration. We talk about the different stakeholders of CTI team has beyond the SOC, but also focus on what a CTI team needs to push and pull from a SOC to be relevant for a broader audience. Finally, we discuss success metrics for a CTI team. Stay with us.

Eric, welcome to the show, sir would you mind sharing a little bit about your background for our listeners, please?

ERIC: Sure, Thanks for having me. So I work at Deloitte Global where I’m on the internal cyber threat intelligence team and I’m the operations manager, meaning I focus on things like bringing intelligence into our systems and automated indicator dissemination to our security appliances. I will be speaking for myself. These are my own opinions and not officially representative of any organizations with which I’ve been associated. And also wanna point out that I am not a consultant. This is not an offering of any professional advice or anything like that.

LANDON: Today we’re gonna be talking about moving the security team beyond IOCs and positioning for stronger outcome. I think that, you know, we’ve talked a lot in the past and prior to the show, you indicated that, you know, certainly, that IOCs, a lot of people think of threat intelligence as just indicators of compromise, which of course are you know, forensic artifacts that are found within an environment that of course would indicate a possible compromise or breach.

And we’ve both agreed that certainly that, that is just that at certainly an aspect, but it’s certainly just really the beginnings and a lot of people saying like you heard a lot of thought leadership that, you know IOCs are not intelligence. And so it’ll be kind of great to explore that today. So provide a baseline kind of starting out, like how are IOCs used in general and should this be a basic building block for threat intelligence to an organization or should it really be a lot broader?

ERIC: So absolutely. You know, as you mentioned, indicators of compromise that is sort of a key baseline activity and we’re talking about, you know, getting IP addresses or hashes or whatever it is that has been seen with, associated with malicious activity, blocking those in our environment where we can, making them available. And for example, a security event monitoring system. So, that if there are, you know, connections, you have appropriate warnings in your system but they’re only a baseline.

I think they’re an important baseline. I sometimes, you know, to what you said, Landon some people not only, you know, discuss that well, are they truly intelligence, but question the value just because they’re so easy to change. My argument would be that they’re a great starting place, if you’re not blocking them and something’s in your environment, you’re gonna have a hard time explaining why there’s For example, you allowed a connection to a known malicious IP, so you should be doing this. However, I think that the important lesson here is you shouldn’t just stop there.

And, you know, in my view, we should be thinking about IOCs not as the intelligence output, if you will but actually a key input. And what I mean by that is you have a rich source of IOCs in any organization, which is your your own activity. With your security operations center, whatever activity you are seeing, for example, phishing you know that this is malicious because you’re seeing it in your own records, right? This is a good place to be starting. So, what if you were to take that information and then automatically extract it and run it through other databases.

So, you know, whether if any of those have already been observed whether they’re known to be malicious. So just to make up an example, you have IP, and that’s the sender IP for a phishing email campaign. And you take that and you have that automatically ingested in say, a threat intelligence platform. And then your threat intelligence platform is receiving intelligence from other sources and lo and behold, you have a hit that says that that particular IP address is associated with with a known threat actor. You know, pick your APT you know, advanced the persistent threat of interest.

By doing that, you’re setting the stage for a two way communication between your defenders and the threat intelligence team. Because now you have that possible link. You can be telling your defenders, Hey, not only are we experiencing this phishing campaign but a possible sender is, you know they’re known to use certain, you know, tactics, techniques, and procedures perhaps there are other IOCs that they’re known to use. So you can proactively search for those in your environment.

Maybe there are yard rules, or are there signatures that you can use for hunting? And the line goes on. So again, rather than saying, okay, our job is to say here are IOCs. We’re just gonna block them. It’s really using IOCs and particularly your own IOCs as the starting point for your defensive activity.

LANDON: Let’s unpack that a little bit. Let’s start with IOCs in general, just for listeners that aren’t familiar with the lingo or the terminology or the technical details, an indicator compromise is a forensic artifact that could be malicious in your environment. You made a key question that they changed so quickly and that they’re irrelevant very quickly. What does that mean?

ERIC: I think those of us who work with them every day tend to use some of the lingo interchangeably. So I use the example, just as an IP address. That’s all it is. It’s not an indicator of compromise. It only really becomes an indicator of compromise when there’s context about it. When you said, for example this was the center IP of a phishing message.

The reason that they’re so easily changed is that many cases actors will use an IP address and then they’ll burn it, you know, that quickly switch to other providers. And so, the source IP today, may not be the source IP tomorrow. And you wanna be careful, because if that’s the case, you know, let’s let’s say I block the IP range well tomorrow that may be associated with perfectly legitimate activity. And so there definitely is danger in trying to chase some of these IPS. And I think that is why there’s a lot of reluctance in the threat intelligence community to put all of your eggs into this basket.

LANDON: That’s certainly helpful. And I guess which leads to kind of the next question is really as a security team matures, you have the security operations center. Which are usually level one to level four analysts that are looking and, you know, doing the blocking and tackling really around the endpoints in the servers of an environment of all the infrastructure in the environment. And they’re detecting and alerting and remediating on a day to day basis.

So of course, when a threat intelligence team comes or is formed, they’re certainly one of their primary customers is the security operations team. How does that threat intelligence team pull information from the SOC to enrich their findings. Kind of walk through some nuances there, and then we’ll get into, you know, how you guys push information to the SOC. Let’s start with a poll first. How do you think about that?

ERIC: I think this is really key in terms of building the relationship, getting the buy in from your security operations center, and ultimately making this a mutually beneficial relationship. Because as you said, you are gonna rely very heavily as as the threat intelligence team. If you’re gonna follow this model, you’re gonna rely very heavily on on the security operations center. The reason for that is I can’t simply go to a SOC, in any organization and say, give me all your IOCs.

Yes, the IOCs are probably residing in some sort of ticketing system or however the organization holds its information. But for this type of arrangement, you’re really gonna need to automate the process. And so not only do the systems have to in theory, talk to one another and, have that some sort of integration, but the data really needs to be clean on the front end. So what do I mean by that? Let’s say people are, are writing.

You mentioned the SOC analysts. So yes, they’re gonna be writing out tickets, but in order for that to be sent in an automated fashion you’re gonna need to grab those from some sort of metadata field. they’re gonna need to be entered consistently. And so, for example, if you think about you know,, that’s gonna be a domain, right. Versus, you know, you add the HTTP at the front of it and you know, something at the back end. And, and now we’re talking about it, a URL.

Well, oftentimes if the person who who writes that gets that mixed up, the information may not transfer correctly. So really being consistent in how you’re entering the information and also being very careful that the SOC analyst is putting the information in the right field. because what you don’t want, you know, I’m only talking here about the malicious actor side of things. You don’t want them to accidentally put your own organization, the recipients, you know, your internal IP addresses or anything like that.

You don’t want that mixed up with the external malicious things cause that that’s how you’re gonna get false positives. You could even have privacy issues where now you’ve put personal information about people in your organization in a database that’s not accredited to hold it. So these are not only the kinds of things that you have to think about, but you’re asking a lot as a threat intelligence professional, of your SOC colleagues. This is just one more thing that the SOC analyst is gonna have to do. And so, they’re gonna have to see that what what’s in it for them. And I think that’s gonna be, you know, the the other half of your question.

LANDON: Yeah. So go dive into what is in it for them? Right. So now you’re getting information certainly from them in terms of a ticketing system. And I have to assume that logs and everything else has to you know, come to your fingertips to enrich that. So I guess it’s, I’m just curious, two part question, is the threat intelligence team really an augmentation of the SOC or is it really an enhancement? And then the second part of that question should be then like, how do you on the other side, push information to the SOC to enrich their findings, you know, so you make everything work and you’re giving that what’s in it for them?

ERIC: So the first part of your question, I do think that threat intelligence team is ideally a separate entity and that you really are enriching what the SOC does, but perhaps out of the scope of this conversation, but there are so many different customers for the threat intelligence team within the organization that you don’t want this to become the only customer that you have. That being said, it’s an incredibly important customer for the threat intelligence team. In terms of what you can be doing. So, first of all, there’s the possibility of sending information back on an automated basis.

So I’ve extracted the IOCs, Now wouldn’t be great if there was some sort of maybe a lookup table or some other way where you’re like, Hey, I sent you this list of a thousand IPs that sent malicious traffic to our environment. We have independent intelligence on 87 of them. And here’s the threat actor. So, you know, it’s right there at the SOC analyst’s fingertips. Perhaps not in an automated fashion, but still important, is for the threat intelligence team to be able to communicate, okay, here are some of the trends that you’re seeing.

So for example, are there sustained campaigns against your organization that, you know, the the SOC analysts might not see when they’re really down you know, in the weeds going ticket to ticket, but you’re able to pick out, you know a ticket from Monday and a ticket from Thursday and in the following Tuesday and be like, Hey, these three are related. And maybe give that kind of context that, you know, this is pick your threat actor with your favorite funny name and say, okay we are seeing this activity in our network.

And let’s say you use, you know, the MITRE framework, the MITRE attack framework, You know, here are some of the top tactics that were being seen used against us. Again, you know, here are some rules that you can use for searching in our environment. I think that’s where the value added comes from threat intelligence back to the SOC, is helping them know what to look for. And so you’ve almost created this loop of information where things come into the organization, they go from the SOC, they get enriched, they come back to the SOC, and the SOC then has a better sense of what to look for.

LANDON: And then I guess, like, go another step further there. And again, this feeds in kind of the next question, I guess kind of provide a little day in the life in terms of how you’re interacting with the security operations team. So after you make that enrichment as an example, that’s helping them do their job better. Are alerts getting then escalated to the security engineering team? Are they getting escalated to other business stakeholders? So I’m kind of curious what happens after you make that enrichment.

ERIC: I think this is gonna be organization dependent, or depend on the size of your organization, your particular setup, and so forth. But I think that gets to some of that feedback from threat intelligence to the SOC needs to be automated. So, for those analysts who are head down in in the data, you have that they don’t have to go and pull it, it’s right there in their system.

But whether it’s through written products, whether it’s through some sort of regular meeting cadence, particularly with some of the leaders of the SOCs, some of those other security teams, I think threat intelligence needs to have a way of of saying, here is the big picture. I definitely think both the written, you know, communication via reports and, and more of the verbal briefing, those are gonna be necessary in order to communicate those trends that you’re seeing.

LANDON: Which is a great lead in to kind of the different stakeholders that you kind of align to. At the end of the day, we talk about this all the time with NISOS, is intelligence, you’re selling outcomes, right? And whether you’re on customer side security or you’re solution side security, you’re ultimately selling outcomes, where security teams can generally align across an organization. So, what outcomes can security teams generally align and what are the important procedural elements across different stakeholder communities that, you know you can see, or you can see those outcomes?

ERIC: To me, it all comes back to improving your security and lowering your risk. And I know they’re closely related but they’re not synonymous. And just to give an example of that, let’s say that you’re operating in a certain country, and because you operate in that country, maybe you have contacts with the local government, you know threat actors in other countries may target you. And so, simply by not operating in that country, you remove that risk.

Now I’m not advocating that, to illustrate that you’ve made no security changes but you still changed your risk. So, they kind of go hand in hand. But ultimately I think it’s about, we need to bring out all of our communications back to these concepts of how are we improving our security and how are we lowering risk? And I mean, you know, one of the things we said a minute ago was talking about how the threat intelligence team is communicating its findings. This is really why, you know, no one can do this alone.

Threat intelligence is certainly not in position to ultimately be able to answer the question how are we reducing our risk? How have we improved our security? You have to have all of the key players at the table, you know, your security and architecture folks, The SOC incident response, we can kind of go down on the line here, but the really important part is that they’re all together.

And with threat intelligence saying, Hey, here’s what we are seeing. And then the other stakeholders saying, okay, here’s what we are then doing to defend the organization. And collectively, that should be able to particularly when it comes to the risk, you’re gonna be be able to give a better answer to your senior executives.

LANDON: This is the fascinating part that even we as on the solution side, often get to deal with. And often we don’t get to see all the times, what our customers do in terms of the disruptive aspects to reducing risk. If we’re in the game of reducing risk, right? And if we’re talking about cyber attacks, we want them to stop. How do you get them to stop? Obviously the clear answer is, of course, you tweak your security controls. That’s kind of like what we’ve been talking about with the SOC.

You have other aspects, and I’ll just speak just on what we’ve seen with our other customers, You see disruptive actions through cease and desist, through administrative actions, through sometimes publicly outing the attackers, you know, sharing with law enforcement, sharing with security researchers. It’s fascinating, just the different types of outcomes that you can use to generate that reduce risk. Right. And I think that’s the exciting part. And I still think we’re still early days. I’ll just, you know, speak on behalf of my opinions on that. I think we’re still early days in terms of influencing those outcomes, you know beyond just controls. So I guess like the question really becomes, what does success look like overall in this field?

ERIC: I’d like to look at this both from a more tactical perspective, you know, those of us who are doing it day to day, all day long, versus the senior executive more strategic view. At that more tactical level, I think success is going to look like, do you feel that you have a way to explain what are the threats that your organization is facing? And it’s based on actual experience that you can say we think that this is the top issue for our organization. And it’s based on our own observation of X, Y and Z, that yes, you can supplement that with information from vendors, and open sources, and your information sharing partners.

But your answers are gonna be much more reliable if you can say, well this is our own experience, and not, well we heard this from a similarly situated organization or this is what’s going on in our sector and so forth. Again, use that to supplement what your own information is telling you. At the more strategic level, I would say again, you’re taking that information about what you’re actually experiencing, but have you translated into overall risk for the organization? And do you have some way of measuring that? So, you know, maybe they’re qualitative metrics, maybe they’re quantitative.

But what risk are you facing today? But then when you are asked that question in 90 days, you know, how has our risk changed at the next senior stakeholders meeting? How are you going to explain whether it’s gone up or down? So having those metrics for what does risk constitute for our organization? I think that’s really gonna be the sign of success. Not just for threat intelligence, but for your, you know, cybersecurity organization at large, because you’re all gonna have to be working together to answer those questions, to have good metrics for how you’re doing.

LANDON: I love the metrics question because I think it’s a nuance that is still early days in that, a lot of teams are still trying to wrap their heads around. What metrics have you seen be successful?

ERIC: I think we’re all very early in this. Things that I might look for, So obviously, you know, ransomware is a huge issue for organizations. So let’s take ransomware as an example. How often are you detecting it in your environment, but then maybe track where in this process, from delivery to execution, did you detect it? You know, did you stop it at your outer perimeter? Did an attempt come that external intelligence said, Hey, that this might have been associated with a group that tries to deliver ransomware.

Did you block those phishing emails, let’s say, at the outer perimeter? Were they delivered to the user quick, but you had other controls in your environment that stopped the execution? And you can kind of go down the line and start to have that, okay, how good are we at stopping threats before, you know they even reach the user? How many are reaching the user? How many frankly, was it user education where simply the user recognized that this was a little weird and they either stopped doing what they were doing or reported it, getting both the human element and and the technical security element into the conversation. Combining that with, okay. What are trends in your sector? You know, bringing in that external perspective. I think together that could give you some good metrics to start tracking.

LANDON: Eric. You’re certainly a master of your craft. I really appreciate you coming on the show today, and congratulations on all the success.

For the latest subject matter expertise around managed intelligence. Please visit us at There, we feature all the latest content from NISOS experts on solutions ranging from supply chain risk, adversary research and attribution, digital executive protection, merger and acquisition diligence, brand protection and disinformation, as well as cyber threat intelligence. A special thank you to all NISOS teammates who engage with our clients to conduct some of the world’s most challenging security problems on the digital plane, and conduct high state security investigations. Without the value the team provides day in, day out, This podcast would not be possible. Thank you for listening.