Playback speed
×
Share post
Share post at current time
0:00
/
0:00
Transcript

Log4j Continues to act as Organizational Vulnerability

Season 3, Episode 13: Cato Network’s Etay Maor provides fresh research on the abuse of unpatched log4j libraries.

Catch this episode on YouTubeAppleSpotify, or AmazonYou can read the show notes here.


This week on Adopting Zero Trust (AZT), we highlight a significant cybersecurity risk focused on the notorious Log4j vulnerability and the growing concern around shadow IT. Featuring expert insights from Etay Maor, the Chief Security Strategist at Cato Networks, the conversation initially looks into the persistent exploitation methods, the importance of knowing one’s cybersecurity environment, and strategic approaches to mitigating risks.

Key Takeaways

  1. Persistent Threats: Log4j and other older vulnerabilities remain a significant threat due to their widespread use and the challenges in patching them.

  2. Importance of Network Awareness: Understanding your network environment is crucial in identifying vulnerabilities and mitigating security risks.

  3. Virtual Patching as a Strategy: Virtual patching offers an effective interim solution to protect against exploitations while permanent fixes are being implemented.

  4. Challenges of Shadow IT: The rise of unsanctioned applications and devices in corporate networks necessitates robust security measures and open dialogue within organizations.

  5. Layered Security Measures: Implementing multiple security layers helps manage the influx of personal devices and applications, reducing potential security gaps.

Editor’s Note

We are about to kick off a mini-series with the folks over at ThreatLocker that walks through how an organization needs to operationalize in preparation for and during the adoption of a Zero Trust strategy. This will differ slightly from past episodes in that we are knocking down the walls of cybersecurity and looking at how other parts of the business will be impacted. If you have specific questions, let us know and we’ll build them into this three-part series.

Log4j: The Persistent Threat

Despite being identified nearly three years ago, the Log4j vulnerability remains a formidable threat to organizations worldwide. As Etay explains, this particular library is deeply integrated into various software solutions, often unknown to the organizations using them. This makes identifying and patching the vulnerability particularly challenging.

"One of the main reasons that it is such a big issue is because this is a lot of software library that is integrated into many different solutions," says Etay. "In many cases, organizations don't even know that they're vulnerable."

Log4j, along with other older vulnerabilities, continues to be a top target for threat actors, primarily due to its widespread use and the difficulty in effectively patching it.

From Q1 2024 to Q2 2024, Cato CTRL observed a 61% increase in the attempted use of Log4j in inbound traffic and a 79% increase in the attempted use of Log4j in WANbound traffic. You can read more about Log4j and other common vulnerabilities from the report.

Know Thy Network: A Key Defensive Strategy

A recurring theme in this episode is the critical importance of understanding your network environment. Both Etay and Neal stress that many organizations fail to have a comprehensive awareness of their systems, leading to prolonged vulnerabilities and gaps in security.

Etay emphasizes, "Do you really know your environment? This is a tough question, and it's getting tougher with the expansion of remote users, cloud applications, and third-party integrations."

To mitigate these risks, Etay advocates for virtual patching—a method that protects against exploitations without necessarily patching the actual vulnerability. This approach allows organizations to safeguard their systems while they work on identifying and applying the necessary patches, ensuring operations remain uninterrupted.

The Shadow IT Phenomenon

Beyond traditional vulnerabilities, the rise of shadow IT presents a new layer of complexity. Shadow IT refers to using information technology systems, devices, software, applications, and services without explicit IT department approval.

Etay brings attention to the unchecked proliferation of AI-based applications and other unsanctioned software within corporate networks. He shares an eye-opening example from Cato Networks’ research, where TikTok ranked high in network traffic for corporate environments, raising serious privacy and security concerns.

"Without even going to the discussion on whether TikTok is malware or a legitimate app, are you happy that this is on your network?" questions Etay.

Neil concurs, highlighting the necessity of layered security measures to manage the influx of personal devices and applications in corporate networks effectively.

Practical Tips for Mitigating Risks

Throughout the episode, practical advice is shared on how organizations can better manage these persistent threats. Here are some key takeaways:

  1. Perform Regular Network Audits: Continuous monitoring and auditing of your network are essential. Knowing what devices and software are part of your network enables quicker identification of potential vulnerabilities.

  2. Implement Virtual Patching: Use virtual patching as a stopgap measure while working on permanent fixes. This helps mitigate the risk of exploitation in the short term.

  3. Encourage Open Dialogue on Shadow IT: Foster a culture where employees feel comfortable discussing the tools and applications they need. This transparency helps the IT department provide secure alternatives and mitigates the risks associated with unsanctioned software.

  4. Leverage Strategic Threat Intelligence: Utilize insights from industry reports, like the one provided by Cato Networks, to stay informed about the most exploited vulnerabilities and emerging threats.

By focusing on persistent vulnerabilities such as Log4j and the emerging challenges posed by shadow IT, organizations can adopt more robust strategies to protect their environments. The key lies in maintaining thorough knowledge of your network, embracing innovative patching methods, and fostering transparent communications within the corporate culture. Stay vigilant, informed, and proactive to safeguard against these ever-present threats.

Thank you for joining AZT, an independent series. For more detailed insights from our episodes, visit adoptingzerotrust.com and subscribe to our newsletter.

Show Transcript

This transcript was automatically created and is undoubtedly filled with typos. As usual, we blame the machines for any errors.

Elliot: Hello, and welcome back to Adopting Zero Trust or AZT. I'm Elliot Volkman, your producer alongside Mr. Neal Dennis, your host, the guy who actually knows what most of this is actually about. And today we're going to be revisiting something that even though it's not necessarily in the largest of headlines, still in some headlines is still an issue.

It's a pretty common thing that we see for most vulnerabilities and issues. And it's a pretty common thing that we see for most vulnerabilities and issues. But fortunately, we have an expert who recently released a report on that situation who's going to be able to walk us through that. And of course, what I'm alluding to is the lovely log4j situation which has never really gone away.

fortunately, we have a time mayor from kiddo networks, who I believe is the chief cyber security strategist now. And you are part of the recently released report that reevaluates and get the pulse check on the current state of long for J and how it's impacting organizations. Before we get necessarily to the report itself, and some of the findings that you have.

Okay. Hopefully most of our listeners are very intimately familiar with that situation and the patching and the vulnerabilities associated with it, but maybe you can give us a little bit of a history lesson and a reboot of why it was an issue, you know, several years back and then we can kind of pick it up to current day.

Etay: Sure. So first of all, thank you for having me on. So the log for J vulnerability was identified in December, I believe, three years ago, roughly December 11th, if I remember correctly. And one of the main reasons that it is such a big issue is because this is a lot of software library that is integrated into many different solutions.

And so we So in many cases, organizations don't even know that they're vulnerable to this specific export because it may be nested within a software that they purchased or is used by you know, a third party that is in their systems. So it's hard, very hard to identify all the vulnerable systems.

And the number two is, you know, number one, it's, it's, there's a vulnerability. Number two, it's super popular. It's everywhere. So the combination is kind of a lethal mix in terms of vulnerabilities and exploits.

Elliot: So I'm curious from your perspective, since this is a nested issue and it requires a certain level of maturity and, you know, knowledge from the organization who owns the library itself. From your perspective, typically, where is that vulnerability or issue flag? Does it come, is it like a two way street?

So the owner of the library will hopefully be the one to identify it, patch it, and update it to the current version? Or is it like a third party, and we have like supply issues, supply chain issues involved? Where, where does that usually originate?

Etay: So if we're talking broadly about vulnerable software, you know, first of all, I wish there were no issues, but if there are that the person who created that, that software would actually alert and patch it. You know, when you think about it, though, a lot of times these things tend to come up in the context of a breach.

And when you talk about a breach, there's usually only three ways that a breach gets detected. It's either you detected. Either somebody told you about it, mostly like law enforcement, probably. And number three is the criminal or the attack group tell you that, Hey you've just been ransomed give us the money.

So those are the three, and unfortunately, we see it in the other way around, right? Mostly it's the third option, and then the second option, and then the first option, in terms of how likely are they to happen.

Elliot: that in mind, and that lens, it sounds like it's a pretty reactive function, which brings us to the current state and the report that this is still impacting organizations. If there's not really a whole lot of attention being raised, this report obviously helps bring that back into the limelight.

You know, how are you seeing organizations trying to deal with it today? Or is it just kind of, you know, neglected. What, what is essentially containing the report that's identifying? Is there an increase in exploitation of it? Yeah, maybe give us a little bit of a rundown of what the current state is.

Etay: Sure. So a little bit of background. So the report we're referencing is the Cato 2024 Q2 threats report which we released. And we look into a lot of different topics in these in the report, the quarterly report. One of the topics is indeed the most vulnerable, the most exploited vulnerabilities that we see out there.

We Cato. For those who don't know a sassy provider the leader according to the magic quadrant we have over 2, 500 customers So we look into the networks and see what is really happening on these networks. What a threat actors really trying to do The reason I'm emphasizing this is there's a lot of discussions about zero days and the number of vulnerabilities that you can protect from.

And don't get me wrong. I mean, you say zero day, I won't shut up for about two hours. I love talking about these things, but I'm trying to look the truth in the eye and see what is actually being done. And I was shocked to see that the top 10 and actually even more, we only talk about the top 10 in the report.

Vulnerabilities being exploded are not very new. They're pretty old ones. I mean, log4j is three years old, but I mean, I've seen vulnerabilities there that are seven years old, ten years old, that threat actors still try to exploit. Why? Because it works, apparently, for them, for some, you know, and then we have to ask ourselves, why does it still work?

And what should we, what should we focus on? And unfortunately, again, log4j is one of those vulnerabilities, along with several others. That are harder to find and harder to patch because you know, I don't want it to come off, you know, Hey, tie the security guy says secure everything and you'll be fine.

Yeah, it's really easy to say that, but the reality is it's not easy to identify. Some systems are even hard to patch, even if you know that they're vulnerable. If you're thinking about critical systems, right? And if you patch them and something breaks along the way and you know, systems go down. So that's, that's another kind of like risk.

So there's, there's a lot of issues around the identification, but then also what do you do about it?

Neal: the fun part about this is, you know, you're spot on, right? On the respect to the, the efficacy of old things related to threat actors and what they're wanting to do. I always find these reports fascinating for that fact alone. They obviously would not put them in there.

If they're not still getting some kind of success, right? Because some of those things could potentially kick off alerts in certain security stacks that would keep them from being able to go further with other stuff. So for them, the wins are still there relative to that exploitation path, so they're obviously still using it.

And the other fun part of this with Logforge that you're talking about, the whole SBOM piece. I'm hoping we can kind of go down that rabbit hole a little bit as we get through this but On that note, you know, is this, I, I'm just for clarity up here for everybody listening, are you seeing log four, just like the number one, even though it's still in the top 10, but is it up there in the top five kind of exploitation attempt paths?

Is it down at number 10? Have we seen it go up and down a little bit or, you know, what, what's the historical path that you've seen? Is it's like top of the tier or is it starting to kind of wane a little bit?

Etay: I mean, it's still top of the tier. You will get get occasional spikes if there's a new vulnerability that, you know, a lot of threat actors will want to use. They'll just put it into their scanners. They'll put it into their systems and try to find the vulnerable systems to exploit them. But this is like the, you know, those that are said, but true from italica, like it's been in the charts for forever.

It's not going anywhere. Same here. It's in here. It's still top, top of the chart. It is still up there again going back to that kind of lethal combination of super popular. Hard to patch, hard, hard to catch in some, in some instances. And yeah, the threat actors are relentless. I mean, we still read about different, unfortunately, a lot of them are, are ransomware attacks that are using this specific vulnerability in order to, you know, do, do their thing, so to speak.

And I think it also speaks to when we talk about these, these breaches, about the fact that We need to pay attention to the entire security stack. And one of my kind of like pet peeves when we talk about security is you read these articles and they say, you know, company X was breached because of vulnerability.

Company Y was breached because of password. Pro company Z was breached because of I don't know, misconfigured firewall. But it's, it's never just one thing. It's never just, oh, we were vulnerable for a log for J and that's it. Because. Okay, that's how they got in. But what happened after that? How come they weren't detected on the network?

How come when they downloaded the payload that wasn't identified when it was exposed on the network? Why was that not identified? You know, one of the things I really don't like is the saying that the attacker needs to be right just once the defender needs to be right all the time. The attacker needs to write a lot of times and we should pay attention to the initial access, but also all There's a lot of other opportunities in there to also identify the breach that started with this vulnerability.

Neal: Yeah, I think. I'm going to go back on a few other things here in a moment, but I think the exploitation path is a very fair call out. You're right. There are plenty of steps beyond initial exploitation where you could have mitigated the larger threat and a lot of people tend to forget about that. Now, hence this podcast.

This is part of the discussions we've had and like to have is why Zero Trust as a construct is so important. You know, potentially important for implementation because just because I get one server doesn't mean I should be able to get everything, right? And unfortunately, log4j, Apache Server Base, once you get through that, most people still have that backdoor wide open with no other gateways in play, right?

And just to iterate on this, I think that's part of why log4 is such an issue. Aside from its persistence, it's obviously because of where it's stationed and what makes it so popular and what you're taking advantage of. You know, this is a server side exploit that, that, that toolkit is, like you mentioned, exceedingly persistent in almost every version of Apache that you could ever hope for.

And then other things, so that's the other part. People look at it from the Apache server space, but there's other ways to get through. When you think about This exploitation path, when you think about log forage and other stuff like this, these long term persistent exploits, what are, what are some of the things that people need to really maybe put resources towards other than, than blatant mitigation of log forage, but what are some ideas on how to find this or what should they be considering from a resource perspective to actually take care of this and maybe some of those other persistent things?

Etay: So one of the methodologies that I personally am a huge advocate of is virtual patching. And for those who are not familiar with virtual patching, there's some really good articles that define it and explain how it's being done. But virtual patching is the action of protecting against the exploitation without necessarily patching the actual vulnerability.

So what you're actually doing is you're identifying the attack that the attackers are taking or the exploitation that the attackers are trying to perform. And you're stopping that essentially printing like this, you know, Detective shield around your your network. So while you are still vulnerable, and it's very important for me to, to emphasize this, you may still be unpatched.

You're not letting the attack in. And that is something that I think is a great approach because, again, it allows the the The target of the, of the attack in this case. To take their time, identify the vulnerabilities, identify how to patch them, not break stuff, test it, and so on, knowing that they're protected from the actual vulnerability from the actual exploitation.

Just for the sake of the example, that's exactly, you know, that's, that's what we did with this within 17 hours and 40 minutes, if I remember correctly, from the point that it was released, our customer, it was an on issue for our customers. And and it really hurts me because you know, we were talking about this before.

I mean, you see literally on a daily basis. You see exploitation of this was something that could have been avoided. So that's that's an area of that. That's one area that I think is very important. Virtual patching. The other area is really something that I mentioned before, and that is focus on the exploits that matter and not the latest and great, not just the numbers or or even the most recent.

Look at the end of the day, there's only so many organizations with limitless resources. It's like the top five banks, right? Everyone else has some limitations and they need to focus. And as much as I like working and talking with the large organizations, you also have to keep in mind the very small ones, the ones where the I.

T. Guy is the guy who does the the the firewalls and the tickets. And, you know, it's all on that one person that runs a small shop. And so While I would like you to have be able to do everything, it's it's not practically possible. So focus on the ones that really matter and don't just go with solutions or approaches that say, hey, we have 10 million vulnerabilities that we are, you know, whatever ludicrous numbers.

Yeah. But the ones that are important to me, the ones that I have, the ones that the attackers are using, show me those.

Neal: Yeah, I think prioritization is a big thing for a lot of companies, like you mentioned. You're right. Having worked on that side more often than not, the latest and greatest flavor of the day comes out, and leadership is oh my God, have we patched this? It's not even in our environment. Why are you calling me at 7 a.

m. on a Saturday morning? Oh, I'm sorry. No, you're not. You just read a news article, and you bought into the doom and gloom speech by some vendor who said they could fix it. Thanks. With that in mind, knowing your environment, right, is critical. And the smaller companies like you're referencing, you know, I, I would say personally that if you're in the fortune 2, 500, give or take a little bit, you should be able to afford some modicum of S bomb approach and, and resource management and control on that.

Maybe not. Full efficacy because I also saw a stat a while back that the average Enterprise agency has somewhere north of around 1, 200 Various vendor type solutions within their larger corporate environment whether that's a simple software suite on a laptop Whether that's an actual log forge enabled Apache server things like that But some 1, 200 plus vendor related products minimum within their stack of IT so Understanding the entire S bomb of all of those is probably never going to happen even for the fortune, you know, 50.

But I say all that because back on S bomb I, I think having the right relationships as a small company with the companies that you're attached to that are way larger than you. And Letting them know that you're part of their exploitation path, especially if you're providing a service might help you get some more credit and clout downrange for them to help you maybe even a little bit.

So from an SBOM perspective do you think that there's ways to, to drive that home? Do you think that would be an effective approach specific for these types of exploitations? And do you think it's worth the energy to create an SBOM if you're a smaller company or request SBOM from those vendors at large and spend all that resource?

Around all of this. Yeah.

Etay: do that with us. It's such a it's such a deliberate and such a heavy process to do. If I'm honest, the large organizations are having some issues with with doing as bomb as you know, as you'd want them. There's a lot of discussions around what is the proper way to do it and how do you handle this this process?

Actually, one of the things that I do is I'm also part of the RSA conference committee and I can tell you we. We talk about that a lot when we receive presentations, and that's one of the topics we want to discuss, but it's, it's not an easy discussion. And just to make things even more difficult, you touched upon a topic that I, I really think is important.

And that is, you said, know your network. Do you know your network? Do you even know your environment? And, you know, I come from the world of, of doing adversary simulation, attack simulation, and breach preparedness, and. I used to tell CISOs and this, this happened a lot, you know, if I asked a CISO or an IT manager, what does your network look like?

I know what I'm going to get. I'm going to get this, this visual file and I'll see all the routers and everything would have nice lines and everything would be organized and really nice. But then if you ask a red teamer, what does that environment look like? Hopefully a red teamer, not the threat actor.

And they say, Oh, well, there's this you know, unmanaged router that I saw that somebody installed in the office. Or I saw this user that somebody didn't close when the person left the organization. Those are my way in and you'll never see them. So do you really know your environment? And one of the topics that I touch upon in the, in the report that I mentioned before is also, which applications are running in your own environment?

And I want to give two examples, if that's okay. Last year, I was actually shocked when I did the, the review of the whole of, of last year I was looking at about 1500 different applications that we were monitoring on customer networks and the top five would be the ones you'd expect, you know, Microsoft, Google stuff.

But then number 23 on the list in terms of amount of network traffic was tick tock, I was like, On corporate networks. What is that doing there? Now, without even going to the discussion, whether it's tick tock, a malware by some government or is it a legitimate, you know, are you happy that this is on your network?

Are you aware of the of the problems this might cause privacy security issues? And I'm seeing the same thing now again, because I specifically looked in this report into and I don't mean to derail this. Conversation. But I will mention this. I looked into what is now referred to as shadow AI, right?

AI applications, hundreds of AI based applications. And again, are you familiar with these things that are running on your corporate network? A lot of them are like health trackers and kids, stuff that kids use. And now you're talking about all kinds of issues. So do you and going back to your Going back now to what we started talking is, do you really know your network?

Do you understand what is going on there? And that's, that's a tough, that's, that's a tough question that I feel is getting even tougher because, I mean, you know, this 15, 20 years ago it was, oh, I have my perimeter, you come into my office, I can control everything. I have everything inside my perimeter.

Everything is, is, I can see it. Now you have remote users and cloud applications and, and third parties and, and you are. inheriting their, their security posture and you're responsible without being able to fully control it.

Neal: Yeah. I will say that this is a very relevant part of this topic in my opinion. Why Logforge is still there is because people don't know what the hell is going on in their, in their networks the right way. And I also want to put a line in the road. SBOM versus Network Awareness and Resource Awareness, two different things.

And at the end of the day, you need one to get to the other, technically. And the other one gets you a lot more. But SBOM, massive workload. And this is why I was asking about it, because I think, I think it's important for critical resources. At your, at your company to understand what the SBOM is for very critical things to use.

So whatever your risk profile is, if, if an Apache server is what's keeping your website live, and keeping the dollars rolling in for your PayPal payments or whatever it is you're using, you should probably know everything you can about that entire solution SBOM wise. If it's a, a website that people use to come and look at your latest and greatest news, but it's.

It's only getting hits once a week, probably doesn't matter as long as it's not connected. As long as you know that it's Apache, and when someone mentions Apache, you know to go look, but you don't need to know the full suite until it becomes problematic. So awareness of what's there versus SBOM, for those listening, big differences.

Knowing your environment versus knowing the SBOM. Know your environment at the very least. Know what's actually hanging out out there. And then back to your point about network awareness and the infrastructure. I'm going to go down that one because I love this stuff. The tools, the AI, all the fun things we're bringing from home with us.

And you're right, it used to be as simple as put up some kind of DNS resolution and people who were smart enough to practice a loud list versus, you know, a blacklist, denied list, things like that. I think that's where people need to get going too again. And once again, back on Zero Trust. I, I should not be allowing people to connect to my network and have every single one of their apps also be able to connect through that network.

If I've got the right DNS resolvers and some other things in play, that phone should only be talking to my Outlook server at that point and whatever else is required for work if you're doing your job right. So I just want to iterate your points on that because I, I do think it's critical and difficult.

So know thyself, right?

Etay: Yeah. And, and, and when we have these discussions with organizations you know, I'll give an example that I, I, I used, I used to show all kinds of you know, gadgets, you know, the rubber duckies of the world and how to use them, one thing that I didn't like when I used to do these demonstrations is you'd show like a rubber ducky to an organization, say a midsize organization.

And they were like, okay, no more USBs in our company. That thing is scary, no more USBs. I'm like, that's not what I really meant. Because you have to be very careful when you block, completely block stuff. All of a sudden, everybody becomes a hacker. And what you'll see next is, you'll probably see presentations and corporate stuff on Gmail going to drives that you're not familiar with.

And I see you're laughing, you're like, You know where, where, where this is going. And And so the approach to it can be kind of a multi tiered approach of Okay, what do we do with all these different applications? And I look at it and say, Okay, you could go with a complete blacklist. And right, let's take the example of an I don't know, whatever, an AI tool.

And you can say, okay, yes or no, I want it or don't want it on my network on my you know, allow it on my network and then you can go a level down. You can say, you know what? I'm not going to block, let's say Chad GPT, right? I'm going to allow you, but I'm only going to allow you using you know, an corporate user, not your private user, because that one I can monitor and I can control a little bit better.

So that might be a choice. And then you can go down another level and you can say, you know what? I allow you to use this application. I allow you to use your own user. But there are certain actions that I'm not gonna allow you. For example uploading files. That's, that's too risky from our network.

And then you can go another level down, you know. I'll allow you to use that, that application. I'll allow you to use your own user. I'll allow you to upload files. But you can't upload files that contain, you know, HIPAA information or PCI DSS information. So you're going into kind of like the DLP space.

But organizations, they can, they can, they have, there's controls that you can use to kind of decide where, where is. Either your depends how you look at it, your level of comfort or what is your risk appetite, you know, with these different applications. But it goes back to the same point that you mentioned before.

You have to know that these things are there to even start that discussion.

Neal: I think this day and age with the BYOB and BYOD piece especially as corporate life gets back into the office space post, you know, all this other fun stuff. The, the individuals, myself included, if you put me back in an actual office space, I'm just gonna be just as bad when I'm sitting at home looking at my damn phone when I don't have a meeting.

But, understanding that current user base needs that type of access, right? Or to your point, they'll find ways to do it that aren't going to be gated the right way. And I am just as guilty as the next one for all this stuff. If you can't give me some kind of public drive in whatever service we're using, I'm gonna go start up my own Gmail account and do that if that's what I need to get my stuff to my client base, right?

The one thing I like, and we did this in the military even back in the early 2000s, when internet cafes were still kind of a thing. And you would have all of your normal network space. We didn't have to worry about cell phones. They weren't allowed where I worked working in skiffs and stuff. But they knew that people still needed to connect to the dot com world, and so they started standing at these little small internet cafe type things on, in our facilities.

And so you'd go out of your secure space into another space, and that network that you were logging into wasn't the actual unclassed network. It was a segregated, just go do internet things network, holistic gateway, holistic security policy and protocol. Now I do see this at some enterprises today, where they purposely do that, right?

So they gatekeep what they need to gatekeep. They put in these different echelons, like you're talking about, to give people some flavors. And then they say, you know what, at the end of the day, Here's, here's this unrestricted or somewhat less restricted public Wi Fi space for you to log in through and go do your TikToks to your heart content with your own private stuff.

And then they block access through corporate layer on that. So I think that's the thing people need to remember. If you're having your employees come back, especially post COVID stuff, that phone is not going anywhere. And their desire to do their TikToks and their other fun stuff at work is not going to go anywhere.

And then that brings you back to the exploit path. How do you control it without them becoming little hallway hackers?

Etay: You brought back some memories. I think we might have some similar background in terms of military. We would secure these facilities and then you'd have an officer come in with like a Like a Fitbit or something on their chest and they're like running around the base or doing whatever and like Dude, this is supposed to be you know

Neal: Oh my God. I remember those. That was a fun one to read about with the overseas places where they were doing the Strava.

Etay: Yeah Strava heat maps and stuff like that. And by the way, see this is another another thing So it's it was in the news about Eight years ago, and then I read about it again Three or two or years ago. I'm like didn't didn't that happen like almost a decade ago. How didn't you read the article?

Neal: Yeah. Well, so let's get talking about your exploitation footprint and I'm going to wrap myself out here. I bought a watch that at the time was probably the Had the highest battery life and performance ratio for, for those, those fitness things called a KOROS brand. This is not me saying go buy KOROS.

This is me saying don't. Even though I still have mine. The watch performs beautifully for those looking. And my advert link will be down here in a little bit. No but I didn't realize, I didn't do a whole lot of research into the company. A lot of athletes that I was looking at, and this goes back to why people are doing TikToks and exploitation paths.

It's the weird things you don't think about until you have your guardrails up. I have guardrails here at my house. I have DNS resolution. I have a bunch of other things. I have my own snort box. I have all these things. Paying attention to some of the lowbrow things because that's what you do when you have guests, kids, and other weird people using your internet.

And I didn't realize that Khoros itself is a Chinese company. I go in to look at my, my logs. And I see all these, these resolution requests from my phone, for the app, out to China. Alright, out to Alibaba website, or space, server space. So I got worried for a few minutes. I went through and ripped apart everything on my phone, cause I didn't realize it was that damn app.

Because the referral link did not show that it was coming from the Khoros app, and I couldn't figure out what app was doing it. And then once I figured it out, I ended up finding some good resolution on the websites, or the URLs that it was trying to reference back to, but it was like eight layers deep.

All that's there. People download weird things like that. People do stuff like that. And the only reason why I caught it is because I had the right guardrails. So that app doesn't exist on my phone. It exists solely as an actual watch. I don't use any of the apps that go with it. I don't touch it anymore.

We can discuss why I don't like that, other than China. But, point is, I didn't know. And I wouldn't know unless I had the right guardrails, right? People bring stuff into your workspace like that all the time. I don't know. And that footprint is massive, way more larger than people anticipate. And we are always playing catch up.

And Log Forge, back on that, is a great example. We don't know what's there because we don't have the resources or the time to go find it.

Etay: Yeah. And I think you did something very similar to what I did. I ran a practice at home of I wanted to see how many Bluetooth devices I have at home and I counted them and I think I counted like 13 or 14 and I opened a hacker one RF. You know, one of those devices. I was so off. I didn't realize that my dishwasher had bluetooth capabilities.

I'm like, why does it? Why does it even have that? By the way, a reverse of what we're talking about, not a reverse, but like consequences of different devices and vulnerabilities. A couple of years ago, I remember I don't know if you remember this. They had a problem with, I think it was an update to the Garmin.

We're talking about smart watches to the Garmin watches and the implications of that turns out that Garmin also provides maps to, to pilots. It's also the Air Force pilots have Garmin watches when they jacked and it's okay, so we can't use that. So Like the consequences of, of these things that we need, you know, about asthma before, how do you factor in so many different elements into your operational, you know, operational situation.

Neal: Yeah. Now, I think back on the asset awareness and resource awareness, and for those who are listening that are fretting over SBOM and the fact that we keep mentioning you might be having a heart attack, I don't think either of us are saying that you need to go out and do SBOM. I think we're saying At the very least, though, you do need to expend resources knowing your base environment.

So when something does happen, then you can go worry about the SBOM for that tool if you really, really have to. And this comes back to relationships and criticality, like I mentioned earlier. If your risk profile says server A is more important than server B, you've probably mitigation strategy and some monitoring strategy, hopefully around server A to help with whatever that risk is.

And like Etai mentioned earlier, virtual patching, I love that. I think people don't realize how often that actually happens across all sorts of products. If you get behind all those and you, you start really hitting them directly, you'll find out most of your software providers have done exactly that for a large swath of things.

Mitigations are there, the awareness is there, but the patches, the actual features, Fixes to those vulnerabilities are not there because if they apply them, they break your entire tool stack, but it doesn't mean you're not protected. It just means that, that they've done a good job at monitoring for that, that issue and are stopping it before it gets there.

And I think that's the key thing. S bombs are important for very specific things, but as best as possible, awareness about your environment is very, very critical when things like a log forge kick off and back to your report, people don't know they have Apache still. People. Still don't even realize that that's even a resource in their environment.

And that's, to me, is the real issue. It's just that awareness factor. Yeah.

Etay: further, one of the things that kind of I don't want to say, I fear it, but it's something that I think is really worth looking into. A different vulnerability that was discussed actually this year, because a lot of times I'm being asked and talk about open source, you know, the X, X, Z, where you had a thread actor that was willing to, to be there for two, three years in the system and wait until you know, exploiting something like that.

And I think we got really lucky with that. I think it was a Microsoft employee from Italy, if I remember correctly, like smart guy that actually identified. I was like, wow, we're so lucky. But now you have threat actors who are willing to say really, this is the very, you know, slow and, but, but consistent, consistent threat that's out there.

Neal: No, that's a very fair call. And thinking about your personal risk profile versus the risk profile of upstream and downstream products that you're attached to or enterprises you're attached to providing resources back. And this is something I try to drive home with everybody. If you are tied to someone else who is considered a possible target of any, pick a flavor of APT in particular, congratulations, chances are you're also being looked at from an exploit perspective, and people will do that.

Threat actors, you know, the, the tier one ish APTs mean time to dwell is years in most cases. Well over a year, at least, in many cases. And when you're looking at what's going on in your environment, if you're tied to, let's say, a Fortune 100 company as a primary resource, I guarantee you, you're being targeted.

Especially if you're a critical asset for them, or, at the very least, a direct vendor provider of some sort. And you've probably been pwned for years, and they're just waiting to find that one critical exploit that gets them through your stuff into their, like SolarWinds, You know, SolarWinds is a prime example of that.

Etay: You just touched upon something that is very important for me because I think you know, I look at these graphs and the dwell time and I think those numbers are a little bit skewed. We talked about it at the beginning, right, that there are three ways to be, to identify you've been attacked. Either you identify it, somebody tells you, or the threat actor tells you.

And you look at the mean time, like people will say six months, eight months, I see the number going a little bit down and people will say, oh, we're doing a better job. I don't think so, actually. I think a lot of the cases. The ransomware group will tell you, Hey, you've been ransomed. And then it's Oh, they've been six months.

Yeah, but they could have stayed, like you said, two more years if they didn't let you know, because they needed the money. They wanted to get the money. And so the number is a little bit skewed because the threat actors are actually exposing themselves. It's not like we're exposing them. They're exposing themselves.

That's why the mean time is going down. And yeah, And another topic that you mentioned that I think is very important is that now the discussions with, you know, we're talking, we're talking to something super tactical log4j and how to identify the vulnerability. But CISOs today don't have, so to speak, the luxury of just doing tactical stuff.

They have to be very strategic. And now you have the CISO who need to understand also, Geopolitical conflicts. Hey, there's a war between this country and that country. The other country sees you as part of of that stack. And now you're gonna be a target because guess what? In war, it's tanks against tanks and fighters against fighters.

In cyber security, it will be a government versus, you know, that water facility or that bank or that private business. And now you have to have that kind of view. You have to have a strategic and operational and a tactical view. You can't just do one.

Neal: Oh, I'm gonna toot my own horn for about a half a sec. I don't do this very often. Usually Elliot's trying to do that for me, because I self deprecate too much. Many, many moons ago, about, seven, eight years ago I wrote a couple of different articles on geopolitical situations and, and cyber exploitations.

Some of them were, one of them was focused on Iranian exploitation with Shimon 2 and then eventually Shimon 3. And when that first kicked off, why it was very obvious that it was them before we knew it was them geopolitical situation said so very, very quickly and history said so, but more aptly, everybody got up in arms.

About, it was about seven, eight years ago, and we had the what was it? The OPA breach, the government healthcare and, and records piece. And then following that we had I forget which airlines, United and maybe I think it was United and someone else had a massive breach perpetrated by Chinese APT as well.

All within a couple of months, right? And everybody came out and was saying, oh, they're doing that so they can track CIA and blah, blah, blah, blah, blah. And the funny part about this was, if you actually looked at the larger geopolitical situation, you would realize that this isn't trying to focus on government accesses and trying to track someone with a clearance.

It was focused on enterprise, business, commercial, private stuff that they were doing there because in their five year plan, they stipulated that airlines and healthcare growth and a capability internal to them to match U. S. and Europe for that scalability and scalability. Was one of their primary goals for that current five year plan.

They had crappy airlines, they had crappy global healthcare systems. So what do they need to do? They need to learn how to set all that up. They go and exploit systems that show them how to set those databases up. And boom, they rinse, lather, repeat and do what they do best, which is copy IP and do it for themselves.

But everybody was so up in arms that, No, they're doing this to go out and make money and track everybody or whatever else. In reality, they're just doing it to support their own private business. So that, that awareness factor and that geopolitical situation, if people pay attention to the larger story, once again, helps you figure out if you are going to be a target.

It helps you figure out if your tie ins left, right, vertical, what you're doing mean you're part of the exploitation path or part of the war path piece being exploited simply for data or to get somewhere else, or if someone's blatantly going to come to you because you are a critical asset, like a solar winds or a log forge and use you to cause global catastrophe.

Etay: Yeah, I mean, I had a little bit of goosebumps because I was at, I worked at RSA when the RSA breached for those who remember happened a while back. At the time, I think it's now, I think it's public knowledge now that the, what was attacked was the secure ID number

Neal: Oh yeah.

Etay: And that ended up with we weren't, we were, we were just part of the attack that actually was later used against Lockheed Martin to, you know, boycott.

The result of what happened to me 14 years ago is probably the J 20 that we see today. Erica. And yeah, and now you are part of something that's even even bigger, even bigger than that. And by the way, this also reminded me of another kind of defining moment in my career that was definitely defining one for me in cyber security.

Another area was the understanding of what are your crown jewels? Because you mentioned Neal before, you know, Hey, identify that server that is important. I remember one of the things that kind of got me thinking about how to even identify the crown jewels was the Sony breach where the most damage wasn't through like movies that were stolen or anything like that.

It was the emails between the executives talking about the actors and how much they make. And I'm like, I don't think in any simulation, breach simulation, that would be identified as, Hey, that's going to give us the most issues later. So it's, it's, it's definitely a tricky situation.

Neal: Yeah. I mean, yeah, I love this. The, as an Intel analyst, one of my biggest goals in an enterprise layer is to find out what the C suite thinks is their risk profile. And each person at C suite should have something slightly different to say. It all ties back to money, right? But it's from their perspective of what they think impacts the bottom dollar.

And, you know, you go ask a, a CFO. You know, what they think is the big thing, and depending on how your CFO is aligned, or if you have a CRO versus a, you know, depends on your financing setup, that CFO might be more fixated on just uptime and availability of whatever they're providing, if it's an IT company versus a physical product, but a resource officer might be more focused on actual Like the Sony breach might be more focused on how they're managing money with their third party accesses and things like that.

Maybe it doesn't matter, but they're all going to have a little variation on what they say. And then as an Intel analyst, my job is to take those, those, that risk profile that's defined by the board and senior leadership and figure out a way to turn that into requirements for my technical. downrange. So whether it's physical or digital related security issues that would get me as a threat actor to impact those risks that were discussed, I could turn those into a potential dollar value to go get resources from my security team.

But to your point, you're never going to find it all. That's where things like for at least cyber, where things like MITRE ATT& CK Framework come in hand where you can say you told me this was a risk but I have absolutely no coverage for this column whatsoever. Don't. This is a soapbox moment. Miner's great at fingerprinting threat actors, but that's not why it was created.

Use it to identify what you're missing in your security procedures and policies and resources to help drive the rest of the requirements. So that, that is my Intel Analyst 101 speech for the day. Get requirements from your board of directors. They're never going to be right about everything, but at least you've got your ass covered for when they're wrong.

Etay: It's funny you mentioned this because I teach a course here in Boston at Boston College on cyber security and I teach the MITRE framework and the case study that I use for MITRE framework is actually gap analysis. I ask the students to take this, show me where your defenses and then layer over the attacks and then start looking at the gaps.

That's what you really want to pay attention to. You know, take. You think you're gonna and here we're going back to that question. Oh, I might be targeted by an Iranian threat actor. Okay, so take oil rig and APT 34 or 36. I can't remember. Put them together. See what are the common fingerprints, but then layer over that the solutions that you have to understand where are the gaps that you need to, you know, look into before they look into it.

Neal: yeah, I mean, spot on. That's exactly why that framework was created. It's coincidental and, and nice that you can use it to fingerprint a threat, but the idea is to fingerprint what you've done wrong.

Etay: Yeah.

Neal: What you haven't done yet. Yeah, that's a whole other fun topic about procedures and stuff like that, right?

But.

Etay: complete. Sorry for stopping. That's why I think it's never completed. One thing that I like is doing the You know, you can use Caldera, Atomic Red Team, you know, start punching the holes into where you're not sure, you know, where you stand and take those micro procedures and, oh, you think you're protected from WMI based you know, okay, let's, let's run a test.

Let's see. You know.

Neal: Well, that gets us right back to know thyself, right? Like you mentioned, this is whether you're trying to map out risk and, and risk mitigation profiles and strategies for the things that you need to cover down on that you don't have resources through MITRE, or whether you're just trying to figure out what the heck's on your environment, because part of that gets you to both sides of the coin. It comes back once again, the reason why log forge is so popular still, because people haven't had the chance or the resources to do exactly this. And next thing you know, someone gets in and ransomware, since that is still the massive flavor of the day for what most people are taking advantage of. And in my opinion, you're lucky if it's ransomware nowadays and just ransomware, whatever they're doing from both you know, legit ransom versus blackmail versus the rest of it.

I think if, if a couple million dollars worth of ransom is the least of your problems during an exploitation path nowadays, you're lucky because an APT legit state sponsored threat could have taken advantage of the same thing. And back to meantime to dwell and respond to all this other fun stuff. Been there for two, three years, sucking down IP and building the next J20, right?

And you not even know. And so I think. Double edged sword, but we're fortunate that monetization of these exploits is so popular in the cybercrime world versus monetization at the moment through APT as a primary, because one, in my opinion, you lose a lot more money long term than just getting ransomed.

Yeah, there's brand wariness and all this other crap that happens when you get popped, but I would much rather say I had to pay a million dollar ransom than three years later say China's been sitting on my network for three years and lose all of my contracts and every work that I've been doing with anybody else up downstream.

Etay: Yep. Kind of sounded better. Yep. Yep.

Neal: so coming back around final loop, the, the Logforge SBOM versus just know thy self awareness stuff. Critical assets and features, all these things playing a part of at least trying to keep yourself from being the next ransomware victim, the next APT target, but more aptly, I think paying attention to the list like y'all are providing specifically.

I love seeing these lists. I love seeing the research that goes behind these when, when vendors and researchers provide this type of insight, because if it's in that top 10 health, it's in the top 100 with people put out a more exhaustive list. Every single thing on that list should be something I'm scanning for in my environment the moment that list hits.

And if you're not, congratulations, it's probably there. Especially these popular ones. And unless you know for a fact that you've already done a mitigation strategy against it, you should probably go look. It's kind of my leftover two bits for that piece.

Etay: Awesome. And yeah, I think you know, what we try to cover in the report is, is, is the vulnerabilities. It's the applications. It's, it's, it's the know yourself. It's looking into the, the different protocols that, that you're using, or, you know, another interesting thing that we saw there, for example, is inbound and outbound communication is most, in most cases by most organizations is being encrypted.

One bound communication is not as Okay, you might feel comfortable with your one bond, but so will the threat actor that will be in there if they get there. So that's an area to look into. So just a lot of different elements to look into that I think are interesting for organizations where you don't really realize, you know what is really happening on your network.

And we do this comparison, by the way, in the large numbers. I mean, we analyze 1. 38 trillion network flows for this quarter, but we also do it for different industries. So you can see trends over time for different industries and what, you know, what happens on their artwork. So just a lot of interesting points to look into there for those who are interested.

Elliot: All right, so that takes us to the end of our episode, the end of this conversation. But I have to say, and I'm going to toot Neal's horn as he likes to call it out for me, is that I think You know, we started on the topic of Log4J, but you all carried us down a few different strains that, frankly, we need to have more conversations about.

First, I want to revisit the importance of organizations like yours who are able to identify issues that are still longstanding, still impactful. Yeah, we'll see some coverage in the trade magazines. But the only reason I'm seeing any coverage in the trade magazines are because folks like you are, of course, putting information out to the world to ensure that we have that.

Thank you all, you all, to continue on that research and flagging and making it very clear that these are other issues. But some of these other things Neal and I just haven't really dug into are things like The shadow AI, frankly, not even shadow it part. Those are important pieces of the conversation.

So I appreciate that you're able to elevate that too, and knowing yourself and all that. But that said, I really appreciate you coming on, sharing a bit of your journey and your research and your information. I think that's super important for our listeners to be able to, again, revisit things that may have fallen off the radar.

And at least, you know, revisit some issues like log 4j. I think it was 2, 3 episodes ago. We had similar issues that were just targeting small businesses. I think log 4j was on that list among others. But again, thank you so much for your advocacy and being part of this, this system and community to, you know, help keep us all on our toes.

Etay: Thank you very much for having me. You'll keep seeing more reports coming out both strategic ones as well as tactical ones on threat actors and the different exploitations that they utilize. We'll keep seeing more information, but thank you for having me on.

Elliot: Excellent. All right. Thank you so much.

Announcer: Thank you for joining a Z T an independent series. Your hosts have been Elliot Volkman and Neal Dennis to learn more about zero. Go to adopting zero trust.com. Subscribe to our newsletter or join our slack community viewpoint express during the show did not reflect the brands, employers, or companies of our hosts, guests or potential sponsors.

Discussion about this podcast

Adopting Zero Trust
Adopting Zero Trust
Today, Zero Trust is a fuzzy term with more than a dozen different definitions. Any initial search for Zero Trust leads people to stumble upon technology associated with the concept, but this gives people the wrong impression and sets them off on the wrong foot in their adoption journey. Zero Trust is a concept and framework, not technology.
We are on a mission to give a stronger voice to practitioners and others who have been in these shoes, have begun adopting or implementing a Zero Trust strategy, and to share their experience and insight with peers while not influenced by vendor hype.