SIEM vs Threat Intel

Security Information and event management and the crossroads with threat intelligence program.

Threat Intel vs . Threat Data

When I meet with a client that wants to build a threat intelligence program we sometimes you have to backward architect. Threat intelligence has been in the news a lot. It’s a big information security topic right now and there’s a lot of companies out there that add a lot of value and very quickly as a cybersecurity analyst you can go out to the web or go out to a vendor and start digesting a lot of cyber threat intelligence. In one of the articles that I did a while back, I attempted to differentiate between a cyber threat intelligence and cyber threat information. And here’s the article here. I’ll try to put the information down in the description below, but it really defines what is cyber threat intelligence.

What is Cyber Threat Intelligence: https://www.maturesecurity.com/what-is-cyber-threat-intelligence/

I wrote this article after meeting with the couple, of very well informed and talented cybersecurity professionals that were specializing in the cyber threat intelligence pillar. One of them works for a big vendor that helps decrease ATO attacks. Another one came up through the military and actually, the third one I talked to came up through the military in threat intelligence. I got to learn that there are different channels of threat intelligence, whether they’re social or technology and there is geographic scope. Just a huge topic. But it’s very tempting for us as cybersecurity analysts to help improve and mature the program that we’re working on by just going out to the web and starting to look through cyber threat intelligence or accepting vendors, subscribe and download all their data.

Levels

And one of the ways that we can kind of put a pause on it and work our way backward to say, where are we at and what do we want to develop with this program, is I break it down into three different levels. Kind of think of it as your level 100 level, 200 level 300. 

100

At level 100 we start with just very basic questions.

• Do we understand the unique risk that this business faces from a cyber threat profile or what’s their cyber risk?
  
• What kind of data is at risk?
  
• What kind of secret sauce, crown jewels, patent information, maybe it’s, you know, healthcare information, whatever it may be to that unique business? 
  
• Do we know what the risk is? 
  

It sounds like a silly question and I feel very elementary asking it. But I would say probably less than half the clients that I meet with have actually taken time to define what that is.

They want to go through steps and they have an interest in reducing their risk and improving their cybersecurity program. But it’s a little premature and you’re not going to get the return on it if you don’t actually know what that risk is. That level 100 is actually asking basic questions about what is the unique business risk that cyber threats could impact.

• Maybe that’s your healthcare information.
  
• Maybe that’s your manufacturing detail plans. 
  
  

200

Whatever may be unique to you or your client. That’s what you want to focus on. And that’s what you want to document. And then once you have that, then you can start working your way up to that 200 program, which is defining within an asset management system where all those risks lie. Like within the data that you defined, whether it be the crown jewels or the healthcare information, ask the questions,

• where does that data originate within the system then the digital systems? 
  
• Where does it traverse?
  
• What does it touch it?
  
• Who uses it?
  
• And then where is it destroyed?
  
• Where does it live to the end of its life?
  
• What is the end of its life?
  
• Do you have seven-year retention on it?
  
• Do you have a secure deletion process?
  
• Does it leave your company on hardware when endpoints are recycled and they’re refreshed?
  

Those are good questions to ask and I don’t mean any judgment, but it’s really good to see where the data goes through the whole life cycle. And when we try to map that data life cycle, you start to bring to the surface all the different assets that it touches, whether they be endpoints or servers, cloud applications, network segments databases.

Where is it stored? Once you start pulling those assets, then we can start taking a look at the risk profile of each of those digital assets that the data touches during the data lifecycle.

Focus on Top Risks

What I recommend doing is just picking the top three. You’re going to have to decide how you want to inventory those systems. You can either inventory them based on their data, so you could say, healthcare data and follow that. What I like to do is actually document the applicant at an application level usually a CMDB or a common management database.  So just pick those top two or three systems that are touching the type of data or crown jewels that you’re unique businesses concerned.

Start at where the data originates and follow it all the way through until the data is destroyed. Following each of those systems, you map it out on a whiteboard or napkins, whatever you want to do, and then go through a process of validating that.

Origination of Data

Go in and find out where it’s originating. 

Do you think that it came in the https maybe from a Dropbox? Then look at your firewall logs or your proxy logs and validate that you know exactly where it’s coming from. Pull logs up from 30 days and see the scope of IP addresses that it’s originating from.

• Ask is that a cloud service provider?
  
• Would you expect those IP addresses to be dynamic and change in nature over the next 90 days?
  
• Or is it from a static source that you could actually add to a white list?
  
• Where does that data go?
  
• Does it go to a transmission system, maybe in an MQ? 
  
• Or does it land, does it get ingested in an application or a database?
  
• Who has access to that database and the tables that are stored?
  
• What other applications are on that database?
  
• Could something escalate privileges or get cross-contamination with another system?
  
• What application is the front end and how is that digested?
  
• Is it digested to other applications or is it direct to the user?
  
• Has that application been assessed?
  
• Do we know what language it was written in?
  
• How old it is and whether it had gone through any kind of manual or dynamic penetration testing? 
  
• Is this important?
  
• Is it externally or internally available?
  

So those are questions that you walk through as threat analysis. And this is all at that 200 layer because you can spend a lot of time.

My point is, you can do a really great job of spending time on the fundamentals of the data security before ingesting threat intelligence.

There are a lot of questions that can be asked. I mean maybe you get through your top three, your top 10, your top 20 applications and you really feel good about each digital asset, the vulnerability scope, the exploit scope, you know, the way that you’re managing it, the way you’re looking for other rogue assets on there, that your encryption protocols, your ACL, your identity and access management around all those systems. Once you feel really secure about that, then you graduate from that 200 to that 300 level.

Risk Gaps

Let’s use this image as kind of a whiteboard. Let’s look at a common threat Intel program. What we like to think of is that you have this measurement of risk within your company and that’s what this orange column represents.

Our best goal or our best attempt is to build preventative security controls that are equal to the amount of risk that basically negates all risks. But in actuality, what we find is that our preventative controls only reduce our risks so much. So we’re left with this remaining risk and we have to decide what we do with that.

Risk Treatment

And if you’ve read my other blog or articles or listen to my other youtube videos, you’ll know that risk can be dealt with. You can either;

• Remediate – which means fix it and remove the risk.
  
• Mitigate -put in other preventative controls so the risk can’t be actually assessed.
  
• Transfer the risk – often done with insurance.
  
• Accept – this risk is going to cost so much to address that it actually doesn’t justify our efforts. We’re just going to accept that risk. And even then it should have some kind of risk acceptance documentation system so you can monitor that.

But anyway, my point here earlier is that preventative controls only make up for so much of the risk. The other things that we can do are have detective controls and response controls.

So when we couple preventative, detective, and response, we’ve got this full scope and that’s what this blue column represents. The security capabilities that come pretty close to our full risk exposure and through there we’re going to want to determine of those gaps. We have a gap between our risk and our controls. Whatever that gap is, that’s really what we’re looking to assess with some type of SIEM program. Security Information and event management or compliment that with a threat Intel program depending on what kind of risks that is.

Asher Security Services

We can come in and sit down at the table with you, look at these threats and determine whether they’re internal or external and whether it’s going to benefit you and speed up your ability to detect and respond if you have a threat intelligence program.

When I say threat intelligence, I’m going back to that article that we talked about before is saying, can we digest a threat intelligence feed and make it actionable? Can we detect something that we were worried about happening and get alerted about it? That’s threat intelligence. If you’re just digesting threat intel, just being downloaded, you’re reading a blog or a portal that’s just threat data until it’s automated or built into a security process is not threat intelligence. So that’s why I want to bring up, and sometimes threat intelligence can complement this gap between risk and controls and sometimes it can’t.

SIEM

The other thing you could do is look at your SIEM rules, (security information and event management). You start to build correlation rules to detect,

• What would an event or an attack, a malicious activity against this risk look like?
  
• Can we capture logs from systems that would help detect a, an incident like this and bring it to the surface and notify us?
  

And that’s what the SIEM is for. So with SIEM and threat Intel, they can partner really well, but the ultimate goal is for them to be a complement of security systems to address the outstanding gap between preventative controls and the amount of risk that you have. So once we get to the 300 layer, if you did all that stuff and you were like, we’re ready. We’ve taken a look at our top 10 systems applications. We feel like we’ve addressed the secret sauce. We know exactly what our risk is. We’ve got some good security correlation rules built into our systems to help us detect whether some of these things that we’ve read about in the news or people have told us about or whether we’ve been able to sit down and do a tabletop exercise. We’ve got pretty good controls and feeling pretty confident we still want to mature our security program. Well then you’ve graduated to that level. 300.

300

Congratulations. there are a few organizations that I’ve worked with and you get into specialized threat intelligence, and red team, blue team. Maybe you’ve heard that terminology before. It’s being done by big enterprise companies. They have a very talented staff. At that 300 level program, you want to start implementing what they call playbooks. So these are playbooks that maybe you anticipated would happen to your company or maybe you didn’t anticipate and you want someone else to come in from the outside and basically put together a situation and see how your security program would have prevented detected or responded to that.

A really great playbook system that’s available is unit 42 from Palo Alto. They’re one of the leaders in security. They start off with firewalls a large spectrum of security capabilities. One of the leaders in the market and they’ve been so kind to actually publish this and make it available. You don’t even need to register, you don’t need to buy anything. Very generous of them and they have all these different playbooks here and some of these are based on real-world situations that they were able to observe and document. They go through the whole campaign. And what happens during this campaign. This is something that we would use as a tool. These playbooks or other playbooks that are available. We sit down at the table with you and we walk through the situation and we say, would we be able to prevent, detect, or respond to this event?

And if not, what can we do moving forward? What kind of either process improvements, knowledge improvements, correlation improvements, or technology improvements can we help you make?

We’re on ‘rancor’ here in this example. The weaponization is to acquire and or use third party infrastructure services. They have some indicator patterns that can be used. Obviously, some of this came from, it looks like Facebook.

There is ‘patchwork’ playbook. Also known as ‘monsoon’, dropping elephant.

Look at all of these, IOCs (indicators of compromise), that they have here. DLL sideloading what DLLs they actually list the indicators here that you could watch for. It’s amazing. So these are really great playbooks. If you make it to level 300, it’s great to bring in an external playbook and review that as a team.

Conclusion

I hope you found that helpful of where SIEM and threat intelligence can help you mature your program. Break it down into that 100, 200, 300 level program. And before you start looking to increase your capabilities around threat intelligence, just ask the fundamental questions. Do you understand exactly what your unique business risk is and where are you at as far as maturity?  We can mature at that level.

I hope you found this helpful. And if you want help with this, reach out to us. And this is what we partner with our customers for. Take care.