ThreatTank – Episode 2 – Quarterly Attack Trends

An Introduction to ThreatTank – Episode 2: Quarterly Attack Trends

Tom Gorup: Welcome to ThreatTank, a podcast covering the latest threat intelligence. Threat response and insights about the security landscape around the globe. I’m your host, Tom Gorup, Vice President of Security Services at Edgio, and joining me today are Richard Yew, Senior Director of Product Management for Edgio Security Solutions, and Michael Grimshaw, Director of Platform Engineering at Edgio.

Tom Gorup: Welcome, Richard, Michael.

Richard Yew: Thanks for having me here again.

Tom Gorup: This might become a recurring theme, Richard. So, last time I opened up with an icebreaker question and I felt like we had to keep that going, but finding one is not easy, right?

Because I think we set a solid bar last time. So, here’s my icebreaker. And for what it’s worth, I’ve not given time to think about it either. So, I’ll join in on this one. But here’s a question. I’m going to ask you first, Michael. I’m going to put you on the spot. If you had to be trapped in a TV show for one month, a full month, what show would you choose and why?

Michael Grimshaw: I got to admit the first thing that comes to my mind and I wasn’t even alive in the first run of this would probably be Gilligan’s Island because the idea of spending an entire month on a tropical island, even if you’ve got to use the professor to figure out how to get running water or anything else like that. A nice tropical island for a month doesn’t sound too bad.

Tom Gorup: What an answer. I love it. No, I haven’t seen Gilligan’s Island in a long time, and I’m not even going to say it out loud it’s been a long time since I’ve watched. That’s a good answer. How about you?

Richard Yew: Oh, wow, that’s a tough one. You know, I’ve been thinking about well, I mean I said a Peppa Pig like is there any other TV show that has pigs, you know I’m going to keep the same pig theme going but I guess I’m going to stop with that.

I guess for me, like hands down Game of Thrones, like, I mean, I would be trapped inside Game of Thrones, but maybe I’ll get the first day or the last day, who knows? But, yeah I mean, let’s go with that.

Tom Gorup: That that’s that. Yeah. That’s brave.

Richard Yew: Yeah. That’s very brave. Yeah. I’m pretty bold, man.

Richard Yew: I’ll probably just put on my black cloak and just stand on a wall and see what happens.

Michael Grimshaw: Well, Tom, let me also give you the inverse. Any Game of Thrones and any zombie-themed movie shows would be on my not to be a part of a list.

Tom Gorup: That’s a good answer. You want to survive, right? That’s fair.

Richard, man, bold. Game of Thrones. So, I was sick last week, unfortunately. I had COVID, which was miserable. But I did catch up on some old House reruns. So I think I would, I would choose House. I definitely want to sit in on some diagnosis and probably say it’s not lupus. I just need to say it at least one time.

It’s not lupus. It’s never lupus. That would be my show for a month. I think it would be a good time, at least I know my survival rate would be pretty high by comparison to Richard’s choice there.

Tom Gorup: All right. So we’re not here to talk about TV shows.

We’re here to talk about actually a new trend report that Edgio is coming out with, which I’m super excited about. I’m taking a snapshot of Q4 and looking at all sorts of trends. This is the first time in a very long time, in years, I’d say it’s a kind of a revival of this report.

And we’re covering all sorts of data points from request methods, trends over time, uh, MIME types, all sorts of geolocation, uh, and that’s Well, I kind of brought you both here today to talk about because I think there’s a lot of interesting insights out of looking at data this way, I think sometimes you can look at data sets.

You’re like, well, so what? What does it matter? Why? Why am I even looking at this? How can we look at this information and extrapolate some value out of it? And then I’m so pretty excited to get both of your work. Insights. So to kind of high-level categories of topics that kind of came to mind that’d be again interested in your perspectives on one was application architecture, right?

Application Architecture – What You Observe Matters

Tom Gorup: If we’re looking at these, this report, thinking about our, our architecture, our applications, how we’re leveraging our tools to be properly configured based on the architecture of our app and also maybe some compliance. Aspects of, uh, how can we use this information to start thinking about again, our apps in a different way.

So to start off, I think application architecture. So kind of getting a frame of reference here. There’s two data points in this report. Look at request methods in mind types, and there’s more. We can definitely feel free to, you know, you guys have seen reports have access. You can pull whatever you have in there.

But first, what? Why is it important to look at? These sorts of things like request methods in mind types. I mean, when I first look at the report, it was like nine over 98 percent of requests for getting posts. What? Welcome to the Internet, right? Like, why is it important to look at that data this way? What do you guys think?

Michael Grimshaw: No, I would call out the, you know, the some of the big things that comes to my mind is what you observe matters, what you’re looking at matters. So there, we can talk architecture and building like new greenfield apps and all the architecture about that on one side.

But the first thing I would get, and it’s the power of reports like this and data and information like this, obviously threat intelligence. I’m a big believer in doing your architecture around your compliance, your security needs, and really the non-functional requirements is, you know, the business logic of your application is not a small pool, but gone are the days where you can just focus on just business logic and one thing, you have to be looking at multiple dimensions, like how you can adjust your observability, how you can take more advanced infrastructure and platform approaches like repaving and rotation of credentials.

I can talk, we can talk for days about that, but the big thing it comes down to is having actionable intelligence to know what you’re looking for. So from an app, from you mentioned tools, that’s one of the first things I would call out, understanding where you were, you know, what the vectors are. What state actors are leveraging what script kiddies and everyone in between is leveraging That needs to inform you of what you’re looking at what you know, whether you’re doing, quarterly, you know scans, hopefully you’re doing scans more than just quarterly obviously. Depending on your compliance profile, you need to do them in a minimum quarterly, but hopefully you’re moving to more of a DevSecOps shift right model where you’re continuously scanning or where you’re continuously monitoring for security of build and mobility.

So the first thing I would call out is this data. This information is important to know. What you need to be taking a closer eye on, what you need to be tweaking your observability stack to look for your security observability stack, and then inversely on shift, right? It’s paying attention to more things and more potential vulnerabilities that you could introduce in your code to make sure you don’t do that.

You’ve got to have an eye on your horizon. Anytime we have one of these conversations, you’re going to hear a lot of analogies, but it is kind of like if you’re running if you’re in a marathon or you’re doing cross country running or something like that you keep your eyes on the horizon so that after you have to tactically shift. One way or another because of a pothole, you know a river or something like that. You’re not losing sight of the horizons you’re running towards.

Richard Yew: I mean, the other way, like you look at this, right?

It’s also when it comes to application architectures, you know, when I look at the data, like Tom said, most of the requests can be get imposed, but you know, it’s internet, right? But I think one of the things that you break down, it’s also when you look at data, like how many requests, because it tells you the stories of like, what is the conversations of the content that we’re getting, right?

Obviously. If you are running a lot of application space, you know, especially like, let’s say you have a spa, right? As your primary architectures, right? You’re going to see a lot of posts. You’re going to see a lot of different methods, right? If you take a lot of user-generated content, you might see a lot of posts and put, right? So, it’s a really good breakdown to see. And also, given that this is security data, it means that this data comes from a web application firewall, right? It really sees how much of the payloads that we inspect that actually trips a lot.

So in this case, a lot of times I get right. But you also see a quite significant amount of those things coming from the post because that’s where the payloads, so it’s very, and it really tells a story about the surface. The surface areas of your attack, and it tells you that if you just look at your request method distributions, right, anything that receives any endpoint as opposed, right, you’re going to have a much larger surface area because, you know, post is like, I use an analogy and the people tell me it’s dumb, it’s in the house, like the post request, it’s like your garbage and your toilets and, you know, your, your public, uh, anybody, like just send you a payloads, you know what I’m saying?

MIME Types

Tom Gorup: I love what you’re saying, though, is that things like just request method start to paint a picture. Tell a story about your application, how it’s being used, how it’s being attacked, where it might be vulnerable. It gives you a good perspective. And it leads right into the kind of MIME type as well.

One thing I thought was interesting, I’d love to get your guys’ thoughts on this, is what we saw this go around is a, it’s a large amount, 76 percent of those blocks. Again, this WAF activity is, was application JSON MIME type. So a lot of prevention around. Json request type, and what does that tell us about the Internet as a whole, how applications are being developed and architected?

Richard Yew: I mean, I’ll start with that. Like it basically tells you where your junks come from, right? In a sense, JSON makes sense because, like, most of the API endpoint, uh. Uh, like restful, even not even restful, like GraphQL, you name it, right? Contains like JSON payloads. Um, right. So this is par for the course, in my opinion, it shouldn’t be anything that’s surprising for a lot of organizations, right?

Obviously you also see like payloads coming from like HTML content type, uh, you see a bunch like from XML, right? So, you definitely want one thing when it comes to like designing and security mechanisms, right? You don’t want to just look at JSON, but you just want to, because I’ve seen certain security products, they can only parse say XML.

That they have no ability to parse JSON. It’s like, if you can’t parse JSON, you can’t look at the payloads. So you want to make sure you have the ability to JSON. You got to make sure your parser is up to speed. I mean, guess what? Because most of it bypassed to, to a WAV is to like exploiting the parser.

So they’re sending out payloads either through a special encoding format or like they, they would send it in a format like. Even just sometimes just change. This is a JSON, but it changed the format into multi-part, whatever. And the web stopped parsing it because it just looked at headers. Oh, this is not JSON. So I’m not parsing it.

So then this is how you get the payload to slide through. So it’s definitely something that you want to be able to, make notes of like, wow, JSON, it’s the most popular. You also want to look at what are some of the more obscure ones. Those and items on there that I want to point out, but I’ll save it for later.

Michael Grimshaw: I think Richard made a great point is it just an X and no parser doesn’t cover it in the modern age of web development. I don’t find it surprising that the application JSON and JSON payloads represent such a large percentage because in modern web development, JSON is in the world, you know, and it’s not even just web development.

You look at, for example, someone should cloud. Uh, whether you’re talking, about CloudFormation and AWS and others, you know, let me use because AWS is big one out there. It wasn’t that long ago, four or five, maybe a little bit more years ago. I don’t remember the exact date, but CloudFormation was entirely XML and then moved to JSON-based and that totally took over.

So it’s web development infrastructure, JSON. Yeah, you’ve got to be able to parse in JSON as well as XML, but Richard’s point as well is even the more esoteric and the outlier is you’ve got to be able to parse all the data.

Richard Yew: Yeah. Speaking of outliers when I look at the data, right, I always look at the smaller data points, like the 1 percent or the 0.5 percent or something that stood out right from the report is that we have 0.14. So 0.14 percent of like trace amount of data. Other non-uncharacterized information, right? But it might sound strange, but when you’re talking about billions of billions of data points a month, I mean, 0.14 percent of the billion, it’s quite a lot. And some of those content type turns out to be like images. Javascript and others, like you would historically think that, oh, those are static content, you know, like those are highly cacheable. Why would you, put WAV in front of your JPEGs?

You know, like why you have a lot of images, right? What do you do that? Well, let me tell you that, right? There’s this thing called lateral movement in security, right? It’s like if those JPEGs. Like, unless you’re putting them in the storage, like on the edge, right, net storage, and where it’s just 100 percent serve, any of those requests goes back to your web tiers, you know, like in your environments, if even just 0.1 percent of those requests goes back to your origins, it means that the attacker can actually ship payloads, either in the form of headers, cookie, cookies, query strings, arguments, et cetera, from the request to a JPEG file and send those things to your backend. So if you’re using the same backend for your, say, your, you know, your HTML and your JPEG, like JPEG, right?

You might be susceptible to lateral movements because they’re saying, Hey, you know, like, this is just image domain. Like, maybe you don’t need to protect that. A lot of people are like, why would I put a WAF? Waste my money, you know, like to put the protections on a mostly static thing. And again, this is something to notice.

You always want to find flaws because as a defender, as somebody who is blue team, right, you have to be right all the time. The attacker just needs to be right one time, right? You know, who knows, like the very first payloads in the very first JSON request that happens to get forwarded to the origins created the backdoor. It could happen.

Tom Gorup: Yeah. 100 percent and what I love kind of where you’re going with this, too, is, it spoke first about painting a picture or telling a story about your application. So getting a good understanding of the architecture of your app. And then where are you applying your controls?

Because to your point where you think is maybe the least vulnerable might be that that avenue of approach when we’re looking at, um, And again, this is inside the report as well. But when we’re looking at the categories of attacks mitigated, 45 percent were actually access control rules, meaning prevention of maybe post requests.

If your app doesn’t accept posts, like limit your threat landscape, limit where attackers can poke and prod at your application by applying access control rules. If you don’t accept application, Jason, block it. Right. Prevent it. There’s no reason to allow that to happen in the 1st place.

And then you bring a good point of like, looking at the kind of the outliers, the smaller portions of the app. I love that thought process there. So along those lines, let’s continue to pull on that thread a little bit. So 45 percent are access control rules where we blocked 37%. Uh, we’re managed rule sets.

So that’s all of your threat intelligence and your cross-site scripting those sorts of tax. And then 19 percent were custom rules seeing this and thinking about like layer defense. That’s kind of what I thought here was that as requests come in, they’re going through these filters that you need to be contemplating, right?

A Layered Defense Approach

Tom Gorup: When you deploy WAF or security controls within your application, you need to understand its architecture and adjust your security tools to match that. To, again, limit your threat landscape, but then you also need layers, right?

Michael Grimshaw: You need layers. And one of the things I do want to, and let’s, and I want to talk to layers, but I think this is what we’re talking about here is just really shines a light on the importance of the feedback loop between your development, your feature developers, your SDLC, your architects, and your security team, because if your security team or your WAF or your SOC or whatever is flying blind, you know, they don’t know, okay, should we accept JSON payloads here?

Do we not post? What, what do we do? Is that, that communication, that feedback loop? You can save money as far as FTE wasted time, save money on tooling, just a tight feedback loop between your developers, your architects and your, and your security team makes all the difference in the world.

Richard Yew: When it comes to the layers, I always say, no, I’m going to bring up meta buzzword, you know, like defense in depth. You know, like, I really think that we need, we got to have a mentality that, it really has order for your terms. But maybe I’m wrong.

Maybe there is a single-layer water filter, you know, they’re using fancy like coconut carbons, whatever, like, you name it. Right. But usually in general, when we look at securities, right? No single layer can be assumed to be a magic bullet. Like, for example, just because you have bot management doesn’t mean that you want to expect bot management to catch everything from application, you know, like DDoS to account takeovers.

Every mechanism works together. And the way you’re trying to put it, like, as you know, like. Okay. Efficient as possible. Like, so we’re taking like 45% excess rules. I like to call it ACL. I mean, this is just, it’s ACL, right? It’s that ACL usually runs on our first layer. And there’s a reason behind that because it’s cheap to run.

It’s just a bunch of like IPs, country, whatever. Uh, ASN, JA3 signatures, right? You run them behind because it’s a static signature that anything that violates those. Immediately gets future away in like we’re second sub milliseconds, you know, right? It’s our whole layers, plural runs in sub-milliseconds.

But you know, like you want to be able to get rid of as much of its junk, right? And I used to have a buddy working in the industry is like he would tell me, right, this is this is kind of what we call a shrinking the haystack. You want you want to take a whole bunch of like requests coming in, right? And you try to find the attack.

It’s kind of like, well, you’re trying to find that single HTTP request that’s carrying that bad payload and that results in a breach. So you’re looking for a need of a haystack. So be able to quickly string the haystack, remove as much of those junk as possible from front layers so that the most sophisticated layers can process.

By additional data what would be very helpful again, it goes back to the fact that we’re not just running perimeter defense, right? It’s just because you cross, you breach the wall. It doesn’t mean there’s, you should have watchtowers, right? In fact, the whole concept of defense in depth is a military strategy that came from the Romans as they expanded their territories to the point it became an empire.

It’s not feasible to just be walls around and make sure that you only rely on the other perimeters to defeat the attack. This is why. We have layered defense.

Michael Grimshaw: Absolutely. And I think we might have mentioned this, we covered this in a previous discussion, Richard. I like the immunology example here is if your health is dependent on a sterile environment, you’re a dead man.

You know, it’s not about avoiding, it’s not about having a lockdown walled up environment and everything within its sterile. It’s about building immunity. And the only way you get that that’s how you are free from pathogens is you develop immunity to them and a layered defensive layered approach is required for that.

It’s like you. Yes, you need the best network firewalls. You know, you do need a strong perimeter. But guess what? That’s going to be breached. I mean, in the world of state actors and where the whole world is, is potentially a threat. Effectively, you need to just plan that your perimeter is going to be breached.

So once they do that, then what is the next layer? And the next layer after that, and the next layer after that. And then how are you monitoring that and fingerprinting those types of breaches so that you know what they’re going after. Yeah, it is imperative

Distributed Architecture

Tom Gorup: That’s interesting, and for some reason, there’s thinking about how does a distributed architecture play into that? Because I can see kind of two ends of the spectrum here. You might look at it and look at risk, you’re adding sprawl, but then you also might. Uh, look at it and, uh, bringing more value. Distributing the workloads across, uh, various regions or locations, allowing for more availability.

So where do you guys see that playing?

Michael Grimshaw: Absolutely. We live in the world of distributed architecture. When you have a global footprint, well. You know, 300 plus pops points of presence around the world. We are in a massively distributed parallel compute age, and it is not just us. I mean, um, this goes back well over 20 years, but this is the essence of web development. Web infrastructure. You have to assume you are distributed. that you’re running massively in parallel and where, the thing that moves the needle here from a security, from a support, and from a cost stand is the first thing I would call out is avoiding avoidance of snowflakes is, and this also relates to compliance, which we’ll get to here in a bit is that if you are running massively parallel, massively distributed, you need your infrastructure to be as similar as possible with as many variances in that distributed, distributed architecture. Um, um, one, because when you’re talking to your auditors, you can assert, you can attest.

Michael Grimshaw: Yeah, we just have to really look into one of those because this is a cookie cutter in every, you know, we have to look at, you know, and your auditors will sample it. They’re not just going to take one example and run with that. You can take a look at any of our global points of presence and they are basically exactly the same cookie cutter one after another that helps for security.

So you have basically the same model that you’re going at as you’re, as you’re working on your layers and rolling out your layers one, but also as you’re tracking, scanning, and observing. That would be one of the big things I would talk about as far as distributed architecture and the reason I was mentioning that with compliance is because if you’re in a massively distributed system, your auditors are not going to want to pen test and audit every single one if they can validate and verify and you can assert that they are correct. The exact same architecture, they are competitors of each other.

Tom Gorup: That’s got to be easier said than done, right? Especially in talking about a distributed architecture in our scenario, right? We’re not talking about deploying a whole bunch of EC2 instances that are coming from a, you know, gold image sitting someplace.

We’re talking about like hardware. Right. In a sense. And how do you operationalize something like that?

Michael Grimshaw: That is an excellent, excellent point. And where that comes to one there, it’s multi-layered approach to that as well. Not just security in that on that comes from you, your procurement and your lifecycle management team, you need to be aligned on that because a good example, the reason let me get Kubernetes is a great example.

It’s parallel distributed, not globally distributed, but you’re not going to be running a Kubernetes cluster all around the globe. But Kubernetes gets a great example of this is that you run into problems in Kubernetes. If you have a whole bunch of servers that have different drivers or different, you know, different nick cards or different hardware, you basically can’t run Kubernetes.

This is why, like I said, working with your life cycle management and your procurement team to commoditize your infrastructure. That is the tip of the spear on the tip of the spear on that. You want to get your hardware as similar as possible to each other. Now, let me call out a great risk that we’ve recently experienced during COVID is the issue we found with logistics and the massive shock to the global distribution space has made it to where you, even if you were running commoditized cookie-cutter hardware prior to COVID with the delays in shipping with the shocks to the shipping and transportation and logistics.

Michael Grimshaw: Of getting being even able to get the same type of chipsets or anything else like that And it’s not just you it’s the people that you buy hardware from their suppliers, etc. It’s sort of a big curveball in that so that brings up the second layer where you have to adapt and that is on when you get to imaging and the actual software you’re running on it, first of all, like Your hypervisor or your operating system or your hypervisor?

That is the next layer to where, even if it is not completely uniform underneath, though, you want to get there as close as possible. Next layer is to make it as much cookie cutter and uniform in your imaging and in your OS hypervisor layer. And then from there, a similar approach with applications.

You want to get this as standardized as possible security for costs for a whole bunch of reasons.

Richard Yew: You know, I’ll tell you like when it comes to applications. Right, you know, disputed, I know it’s probably contrary to popular belief, and this might be a bit counterintuitive because we’re thinking about well-distributed architecture.

So we’re taking from centralized soft servers, cloud environments, and we’re distributed all over the world. What if I tell you that having a distributed architecture actually makes your attack surface smaller? Sounds kind of weird. It sounds kind of, but, but think of it this way, right?

By having distributed, and this is why I think it’s very important when you’re designing applications, especially we’re talking about website, right? You don’t, design and what I find a common mistake, and this is borderline security. So if I veer off topic a little bit is that I find there’s a mistake where I’ve seen people, customers, organizations, they will design the applications based on a centralized architecture and then try to run it in the distributed platform like a, CDN, then you have to create a lot of optimization yet like, Oh, what needs to be shipped, you know, after the fact to the logics, but you know, the modern, it’s called a modern design, right?

It is to actually design applications with distributed architectures in mind. It’d be like, so for example, you’re used to processing a lot of logics in a centralized location. You just use CDN to cache your JPEG and your static files, etc. But how about you ship some of the logics?

Like, let’s say you just take a really simple example, like your redirections, right? You just like your original centralized infrastructure is going to do redirections for a customer. What if you have tens of thousands of redirections linked? Right. Um, how about you shift those logics to the edge?

How about you shift those things? And by doing that, right, when I say attack surface, right, you are, by shifting those logic to the edge, right, you’re reducing the loads, you’re reducing the probability of failure in a centralized, like, like architectures by, by having offload some of that, you know, outdoor security is what CIA, right?

Richard Yew: We’re talking about the availability part of that. It’s very important. So I would say by moving a lot of those, including security mechanisms. So if you are able to filter again, shrink the haystack of the attack at the outer edge of perimeters, right, you are susceptible, less vulnerability in your centralized, you know, a cloud or like hardware, hopefully not anymore.

Richard Yew: You guys 2024, you know, but hardware, but basically we call the origins infrastructure and that’s very important. I can just tell it like there’s so many more things you can do because we are obviously at the edge of what we’re implementing a lot of technologies and I’ll tell you, man, like just doing distributed counting.

In like 1 millisecond and having all of the servers, like, like things across, right, that the data, it’s a pain, you know, when you’re trying to sync the number of requests count per seconds across all of your infrastructures, uh, within a pop, right? Um, but I, I think it’s something that you want to make use of.

Richard Yew: So, so, so instead of having just a central brain, like, uh, logics in your, in your centralized architecture. Started maybe split it up just like humans, you know, humans brains are technically distributed architectures. You have your cerebrum and you have your lizard brain. And guess what? Because, because when you touch something hot, you’re not going to have time to react.

Richard Yew: If those things have to go through a central brain. You got to burn yourself before you pull back, right? That’s why so like, start thinking about what is a new architecture design. Maybe instead of doing machine learning and training and everything in the centralized, you do inferencing on the edge and then you do a training in centralized locations.

Again, it goes back to like. In a sense, you’re actually reducing the vulnerability a little bit and make your entire system more robust from a security perspective.

Michael Grimshaw: Yeah. Yeah, and this stuff tells perfectly what we were just talking about layering is because in moving away from a centralized, um, um, or what we were talking about with immunology as well, moving away from a centralized, um, um, approach.

You, if, when you do get attacked and you do get pawned, um, the, the amount of data or, or, or the exposure that you have is tremendously limited, so it’s not a full, full Boolean, um, am I protected or am I not? When everything is centralized. All right. If they’re in and they have access to the data, they’re going to have access to the data, make it distributed.

Okay. Maybe, maybe one region or one subset or one subsystem. Um, um, an attacker can leverage a zero day or whatever it is and get in, but they don’t have your whole system. And it’s also a resiliency thing because you are not losing your whole cerebral cortex all in one fell swoop.

Richard Yew: By the way, like, Lindsay bot just fact-checked me and, uh, I guess I used a bad analogy. Uh, human is, I guess, I guess we, we don’t have brains and elsewhere, but I should have, I should have said is an octopus. An octopus has like brains and all of the arms. Yeah. That’s, that is a true distributed architecture.

Geolocation – Where are we blocking the most attacks?

Tom Gorup: Yeah, that’s fair. That’s good. So, staying along the lines of distributed architecture, maybe pulling in compliance a little bit here. One of the stats that I thought was. This was pretty interesting to me, at least to see on paper, I was looking at geolocation. So where are we blocking attacks from the top five countries?

All right. I get this top five countries were us, France, Germany, Russia, and Chechnya. What I thought was super interesting here is for what it’s worth knowing that there’s a lot of APTs that run out of China. They’re not on the list. Not on the list, which I thought was kind of interesting when we think about geolocation.

I think a lot of people turn to geofencing. Hey, let me lock down in countries that I know are likely to be attacked from, but 26%. The number one hater there was from the US. Like, what does that tell you guys? I also think I’m thinking about this from a compliance standpoint as well. How does What is geofencing like in, you know, 2023, 2024, that’s where we’re at now.

Richard Yew: I mean, my opinion, right, I know we have, like, every customer, you know, when we get on board, we talk about export control, and we have to, like, do, like, those control with, like, geofencing, I feel like some of those things, some of those requirements to get revisited since I know it might be not something that everybody wants to hear, especially if you run GRC, I apologize in advance if I’m giving you a headache, but I think we’re in a day and age where it’s like everybody gets their hands on VPN and everything, right? And so easy to just spin up VM everywhere. Like, I remember when we were looking at Black Hat last year, we were looking at distributions of like the ISP for anonymous Sudan DDoS attack, right?

Richard Yew: There’s like, they’re using a hosting provider. Everywhere. We know where they come from, like they come from this specific country, Eastern Europe, you know, like that’s where the organization is, right? But, then the attack comes from anywhere, like nowadays. So it’s like, does it, you then block a Chinese hacker by Joe fencing China? Does that even work nowadays? Right?

Michael Grimshaw: No, but you’re absolutely right. And, China is well known historically for using that very, very approach VPNs and, and really obfuscating the origin of where the attack is, um, obviously with Russia, they use there is so much of a homegrown, you know, almost the state, almost encouraging individual actors in Russia to take part of it.

China’s command and control structure is quite a bit less of Shall we say mob or, or, um, um, oriented that you see in like Russia or, or, or Cheshire and things like that were decentralized. Exactly. Um, good call. Um, but yeah, and, and Richard, I absolutely think you’re right. We do need to revisit this, but there are going to be customers and there are going to be market segments.

And verticals that do have regulatory requirements. So, and one of the big ones you don’t mess with is Office of Foreign Asset Control, OFAT. And that’s where geofencing and with, with like especially any one of the financial services, banking industry, um, making sure that, you know, making sure your banking or your financial services aren’t available to North Korea, for example, or Iran and other places on the lists on the list.

The geofencing still matters, especially towards regulatory requirements. We need to revisit those. And, and we need, um, in fact, this, this just recently came up with in Ukraine where, um, um, uh, it was called out that, that the Russian Fort, while, while [00:39:00] Starlink uses geolocation. To keep it from being used in Russia, Russia operates Russian soldiers and operators are, are utilizing it, uh, sourced from other countries in, in, uh, occupied Ukrainian territory.

The list is long about dual use. Dual-use materials, things like that that could be used for both civilian and military purposes and how that is oftentimes sourced from third party countries and this is the same thing is true here, but there are still absolutely hard regulatory lines. Some customers have to deal with or geofencing very much.

Richard Yew: You’re right. It’s, it’s just an arms race. I think the point is, while we’re talking about distributed architecture, we talked about how it’s important for our customers to use that to protect us. But like Mike and I said, both the attackers are using distributed architectures.

Richard Yew: I mean, they are, well, I mean, it’s kind of funny, that was the whole point of DDoS. Right? I mean, that’s where the D comes from.

Tom Gorup: Yeah, this is good. You know, I’m disappointed that we’re running out of time because I think we can spend probably at least another 20 minutes on this topic alone.

Final Thoughts & Recommendations

Tom Gorup: But since we are running a time, I’m, I would love to hear just kind of, you know, thinking about this report, thinking about some of the data points that we that we talked about here. From application architecture to, you know, compliance, geofencing, the whole the whole gambit. I love to hear your thoughts, and recommendations to the audience.

Like, what should we be looking at? How can they better protect themselves?

Michael Grimshaw: Yeah, I love this report. You know, I want to bring it back and talk about the report. We’ve talked about a lot of things, but one of the things that, and maybe this is because I’m going through. What a PCI audit right now is one of the things I love about this report is in two things that just come to mind, um, around where this report and these approaches help with your security and especially really your compliance stature is in PCI. It’s one of the requirements in PCI is to establish a process to identify secure vulnerability security vulnerabilities using reputable outside sources for information and assign a risk ranking. Now, this, this report doesn’t give exactly a CVEs, but this is part again to layering your auditing approach is I would, you know, I love taking a report like this with specifics from maybe operating system vulnerabilities or shift left like vulnerability database in that background.

Michael Grimshaw: And being able to put together a whole picture for our auditors on the one hand, and then another requirement PCI is making sure that you’re and I’m just focused on PCI. ISO sock to a whole bunch of other regimes. But the other thing is, it’s important to have your employees trained and up to date on the security landscape and how to prevent that.

And yes, you do training on an annual basis. You know, you need to do training when someone’s hired. Okay. Every year after that, but reports like this, this is absolutely something I would get through every one of my employees and across the whole company just to increase security awareness, helps with their compliance, helps with your security. I’m a big fan.

Tom Gorup: That’s great advice. I love that. How about you, Richard?

Richard Yew: I’ll say definitely like, you know, sometimes having the visibility is very important. And I would say to make things easier, right? It’d be nice to have this kind of visibility across all of the applications, at least what we’re talking about public facing applications, because we’re not going to look at all of your endpoints on the management, like your laptops and Macs, but at least we can see like what’s going out in and out because I’m a firm believer that you need to have one single pane of view for basically everything like internet facing that’s coming in and out of here.

Like we’re talking about every HTTP requests, every external request, in and out of network needs to be cataloged and be great. Like, if they are all collected and be able to reported under a consolidated view like what we talked about here, I think it’s going to also help facilitate your compliance, especially when it comes to providing evidence, et cetera.

So. Okay. Again, visibility is important, right? You know, if you look at the three, well, actually five phases of like a NIST security framework, right? I mean, that there is that on the far left side, there’s just a text like preventions and then you have to response, right? But, you know, having the ability to have visibility, the detection is very important.

You can’t mitigate what you can see.

Tom Gorup: Yeah, yeah. I always equate security posture, visibility, exposures, and threats. I can’t protect what I can’t see. I need to understand where my weaknesses are, and I need to understand how I’m being attacked. It’s the three of those that really come together to define your security posture.

And it got a little interesting too about like sharing this with other people in the business. One of the deep dives that we do in the report as well as digging into directory traversal, that was actually pretty much the number one type of attack that we see still very prominent on the Internet today.

Now we’re protecting against it, but it doesn’t mean that applications aren’t vulnerable to it. And ensuring that your engineers or developers understand how this attack can be used against you is a great way to make sure that you’re building secure code from the ground up. And what I love what we talked about today is thinking about the application architecture, not just your application architecture, but also your business and how it operates.

So in using that to inform your security tools, right? So you have your application architecture of what types of requests do I expect to see? What types of MIME types, but also where is my business able to operate and applying those and putting those all as part of controls into your security tooling?

So I think that’s what excites me about the report is not just looking at the data, but also taking the time to think about, like, how can I use this information to think about the world just a little bit differently and maybe use that to inform my security tools to put more controls, constraints, prevent my business from being popped. You know, at the end of the day, that’s what we’re here to do is to protect the business, allow it to give it the freedom of maneuver to make money for f constituents and bring value to our customers. So good stuff. So that’s all we have for today. Thank you everyone for joining in on ThreatTank.

If you want to stay up to date with the latest threat intelligence from Edgio, jump over to edg.io. That’s edg dot io and subscribe, you know, you’ll get more Intel as it comes out. Michael, Richard loved the conversation. I feel like again, we could have gone at least another 45 minutes. This was great.

Tom Gorup: I really appreciate both of your time.

Richard Yew: Yeah. Yeah. Thanks for having us here. Thanks for the great engagement and discussions.

Michael Grimshaw: Thanks for the great information, Tom. Yeah. Appreciate it. And always fun chatting with you, Richard. Outstanding.

Richard Yew: Likewise, man. See you guys.

Tom Gorup: Till next time.