From Packets to Intel: Building your own Network Threat Feed

[Music] Good afternoon everyone. I'm Jared Nordier. I'm going to talk about uh how you can build your own network thread feed and how you can use that for proactive defense. But first, a quick introduction. Um I head up security at synthesis. We're AWS uh premier partner where I help organizations adopt cloud securely. In my free time, uh, I do research on cyber security topics that intersect with national security and foreign policy, things like disinformation surveillance uh nation state activity, etc. I also help, uh, run community events like this one and a few others. And, uh, yeah, it's always great to give back to the community. So if you're a network defender um and you know on the blue team perspect you know

on the on the blue team uh operating in a cloud environment you know that securing the cloud environment can be you know quite challenging and securing just a single cloud environment can be quite challenging but as many organizations move to a multi cloud world um this be is becoming significantly more challenging and then when you start adding in all of these third party SAS services uh that a lot of us are using um this becomes quite a major headache and when you start looking at securing these vendors uh many of them will have uh secure defaults or managed rule sets and policies that you can uh enable which is a good starting point. However, in a

mature security environment this is often not enough uh and often these services lack the granularity that you need in order to protect them uh properly. So um and a lot of these services will often push the burden of security onto the various um security teams uh through monitoring. So instead of having granular control, there's kind of this focus on do doing monitoring instead of trying to prevent like bad things uh from happening. And often what you'll notice is that often the self-hosted version of some of these platforms actually have more granularity than some of the cloud and SAS uh versions of these uh platforms. So for example, Bitbucket is a really good example where the onremise version uh

has a lot more granularity from a control perspective, but then you kind of trade off the all of the zero days uh and CVEes that are present in in those stacks. So um a lot of these vendors will have uh out of the box rules and policies that you can use uh to enable the securing of your environment. And uh these uh rule sets are often tied into third party uh threat feeds. Um a lot of parameter vendors also allow you to import external threat feed into uh these devices. However, when you start looking at the big picture, uh the challenge that you have is that you land up with a lack of consistency and

visibility um across your environment. So for example, you might have a secure default or a managed rule set that protects you against a certain emerging threat, but another vendor platform doesn't have that. So you kind of have a bit of a a hole in that. And this is particularly problematic in uh the cloud space um uh in particular. And a potential way to fix this is to actually use a threat feed um to actually build some actionable controls um to kind of gain a bit more consistency. And that's what I'm going to be talking about in a moment. So when we start looking at building your own threat feed, um the first step is really to look at your own

internal data to understand what's going on in your environment and then how we'll talk about how you can then use external data to kind of complement that. So the first good thing to look at is network data. So in order to observe what's happening on a network uh we can collect net flow which shows uh network events that are that are occurring on a specific network. There are specific vendor formats but most of them can be uh converted uh to a generic and airflow version and this includes um source and destination IP addresses, ports uh etc. And from that data we can then import this into a seam or a log analytics uh tool where we can visualize the data and

investigate it or interrogate it further as we need to. Uh this data will also show you what devices are connecting to other devices in the network um both from an internal and external uh perspective and this is very helpful to uh visualize network traffic flows but it can also be used for performance monitoring and capacity planning as well. And from there you can also get a sense of the geography that you are seeing traffic from. Um from a hyperscaler perspective a lot of them have a version of net flow called flow logs uh which is similar to net flow but uh it has some different uh information and sometimes operates in a different way. Um and this

data is very helpful if you have an incident. So you'll know exactly what devices have communicated to other devices uh by looking at this uh data. And if you use security groups properly, this is a great way to detect a compromised machine. So for example, if a machine is compromised, one of the first things an attack is going to try and do is to try to recon. And that's a really high quality signal that that machine needs uh further investigation. So when you combine net flow with uh application and authentication logs, you can now start building your internal threat feed data to understand the real world attacks that are actually happening in your environment. And then

next we want to see how we can combine that data with open-source data. So there is a lot of publicly available open-source and community feeds and um this includes SANS, abuse.ch Netwatch and others. There's also several companies um that provide this data free of charge um on an open- source kind of basis and um a lot of this data is gathered through honeypot and other mechanisms of malicious behavior. This includes credential stuffing, brute forcing, uh vulnerability scanning, uh spamming and a bunch of other malicious uh activities. And uh the SANS uh provides probably the most uh or the highest collection of threat feeds for this information or for this malicious activity. This includes scanners, emerging threats, tour notes, and more.

And this data is particularly helpful um if you want to correlate what you're seeing in your internal data versus what's actually happening on the internet. So for example, if you see a certain port is now getting scanned, uh you can go look at the threat fish to see is it specific to you or is it happening across the internet. Then there are sites like malware URL that list IP addresses and domains associated with malware. Uh there are also several uh GitHub repositories that track open proxies, reverse proxies and tour nodes and other potential malicious infrastructure. uh one of the uh git repositories is this project called netwatch which is a community project. So they run a whole

bunch of sensors around the world that look at attacks uh that are happening and they publish uh this data on a daily basis and uh you then get an understanding of uh various IP addresses that are performing uh this traffic or the these attacks. And then there are several commercial companies like Proof Point that provide some threat feeds and rule sets uh that you can download and implement on your firewall. Um in a lot of cases the companies only provide the rule sets but then you can create processing to actually pull the data out of those um rule sets. So there is a little bit of work involved in that. So once we have a list of of threat feeds

uh what we want to do is we really want to build a combined list where we use the internal data along with uh the open source data uh and then uh we can then process that and what we want to do is we want to have this data in a unified format so that we can use it. Uh some of the challenges is that a lot of these feeds are in or not in a common format. So you actually have to do quite a bit of processing uh to extract information out of it. there's a lot of false positives. It's difficult to correlate between different threat feeds. Some of the threat feeds don't have context. So,

for example, if you see a spike of certain behavior, you might not know why that's the case. You might need to investigate further, but sometimes you might not know why certain things are actually happening. And then another problem which is very kind of specific to South Africa is that a lot of these feeds are very US and EU centric. So we don't have a lot of good data around emerging threats happening in Africa, the Middle East and South America. So inside of these threat lists, uh there's normally a bunch of IP addresses. Uh that IP address will normally belong to a net block which is normally larger than a SL24 and that net block will be owned by an autonomous

system number or ASN. Uh companies can have uh multiple ASN. So for example, Facebook will have four voter phones for MTNS2 and China Net has multiple. And what we want to do is we want to add this ASN information onto the IP addresses. Now some threat feeds will automatically include the ASN data um but some of them don't. And the ones that you don't you need to look that up uh that information up. And what we want to do when we look this up is we want to get the other net blocks affiliated tele uh telecom domains the country and the ASN uh that's affiliated uh with that specific IP address and these lookups can be achieved through uh various

open-source uh data sets um but you can also use an IP uh lookup uh service as well. So once we have processed the data we now have this in a unified format um and then we can start analyzing uh that uh data. So um we can look at uh how many uh threat feeds are reporting on a single uh IP address and maybe add some kind of scoring um along with that. And then we can also look at it from an ASM perspective to see which ASN actually has the the most or the highest number of uh IP addresses that are performing malicious activity. And when you look at the data, you'll often see a lot of

bulletproof hosting providers uh in uh uh these uh feeds. Um so if we look at analyzing kind of the data further, when you start plotting the locations of these attacks, I think to nobody's surprise in this room, you generally see the Asia-Pacific uh uh region. Um and it's not just Russia and China, right? It's also um attacks coming out of cloud providers in Singapore and Japan as well. Um, Singapore for some reason uh is a a favorite uh location that's used to attack cloud infrastructure in Ireland and in other uh regions as well. And what you'll also notice when you start doing this an analysis is that uh a lot of the threat feeds actually don't

overlap. So for example, you might have uh malicious infrastructure trying to brute force something um but you might not actually see that infrastructure in some of the other threat feeds. And this is one of the benefits of having a combined uh threat list. So let's look about how we can actually use this for proactive uh defense. So from a defensive or blue team perspective, we can use this data to enrich seam data. We can correlate internal threat data with what's happening on the internet and then we can use it as a high quality input into actionable controls to reduce uh our attack surface. So, as one example of how you can use this, um, scans for

vulnerable infrastructure often come from a bulletproof hosting providers. So, one of the things that you can do is actually consider blocking these ASNs, uh, on on your uh, network perimeter and if you run your own ASN, you can actually go to your upstream providers and maybe ask them to actually filter some of these uh, malicious providers out. This is actually the official recommendation both from Rob and Ayana. um that you should uh look at ASN filtering as well. Obviously, you do need to be careful that you don't accidentally block residential um networks in the process. Um now, you might say this is actually, you know, a bad idea. Maybe we we can't block um ASN's, but what you could potentially do

is use it in a kind of a layered uh approach. So um from a public perspective you might want to do like a challenge uh on a website or something and then on a third party system if you see a login from one of these ASNs you can then generate an alert and then maybe on your internal systems uh you could completely block it outright. This obviously depends on your uh risk uh tolerance as an organization. And one thing to also look at when you are doing filtering, don't just look at the ASN itself, but look at the both upstream and downstream providers um of that ASN. Often a lot of these malicious ASN's uh typically reside with each

other um because they use the same uh telco uh infrastructure. So when we look at it uh blocking this from a zero day perspective um you can actually reduce your attack surface quite significantly. So if you do have a zero day in one of your network appliances um it gives you that little bit of extra time to do to actually patch it and does actually reduce the chances that you might get compromised. One thing to keep in mind is that the prevalence of pre-orthes is becoming a lot more common. Um and by blocking these ASNs you do get that a little bit of additional time and it is an additional layer of uh protection that you can have on your

network. Um when we look at it from a nation state perspective like the overwhelming majority of companies are not going to be the target of a deliberate AP uh uh attack. However, if you are familiar with China cyber operations, you know that they have a desire to build out operational relay boxes or orbs uh through vulnerable perimeter devices. So, they might not be interested in your network, but they might be interested in where your network can get them. And by adding this control, it is a small but meaningful control to potentially prevent uh this activity. Then lastly, looking at how we can actually uh deploy this. So we can actually build a deployment process where we take this data combine it into

a thread feed. We can then use infrastructure as codes to actually implement these controls. So Terraform is quite uh common in a lot of companies especially in South Africa. And this can be done through either a manual process. You can create some kind of thing to actually script out the Terraform. Or if you're feeling fancy maybe you can use a LLM with some rag uh so that it can generate the Terraform for you. And uh once that's done then you can deploy uh high high quality controls uh using this data across uh your environment. So while not all of the services have the ability to you know support these kind of controls where this data would

be useful um it does allow you to use threat data in kind of a meaningful way to ensure that you have a bit of consistency across uh your environment and across your platforms. Thank you very much. [Applause]