The Cyber5 Podcast

EP70: Holistic Uses of PDNS and BGP Data to Address Intelligence Needs in the Private Sector

Episode 70 | April 6, 2022

In episode 70 of The Cyber5, we are joined by Open Source Context Director of Operations, Donald McCarthy.

Episode 70 | April 6, 2022

In episode 70 of The Cyber5, we are joined by Open Source Context Director of Operations, Donald McCarthy.

In this episode we discuss external telemetry available to the private sector, focusing on passive domain name systems or passive DNS, and Border Gateway Protocol or BGP. These data sets are critical for threat intelligence teams, as they often provide crucial information on attacker infrastructure for the SOC. Still, they also help solve problems and provide context on a much broader scale.

Here are the 5 Topics We Cover in This Episode:

1) What is Passive DNS and how is it collected?

To simplify, passive DNS is a way of storing DNS resolution data so that security teams can reference past DNS record values to uncover potential security incidents or discover malicious infrastructures. Passive DNS is the historical phone book of the internet. Practitioners can collect it by:

  1. Collecting on the resolver: Have access and enable logging on the resolver, often termed “T-ing the Resolver.” The client-side of the DNS is called a DNS resolver. A resolver is responsible for initiating and sequencing the queries that ultimately leads to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address. DNS resolvers classify data using various query methods, such as recursive, non-recursive, and iterative.
  2. Listening on the wire: DNS is port 53 UDP unencrypted, and many security teams put a sensor like Bro, Onion, Snort, or Suricata that can collect and then parse the data.


2) What is Border Gateway Protocol (BGP)?

  1. BGP is designed to exchange routing and reachability information between autonomous systems on the Internet and is often complementary to passive DNS.
  2. If PDNS is the historical phone book of the internet, Border Gateway Protocol (BGP) is the postal service of the Internet. BGP is the protocol that makes the Internet work by enabling data routing. For example, when a user in Thailand loads a website with origin servers in Brazil, BGP is the protocol that allows that communication to happen quickly and efficiently, usually through autonomous systems (ASes). ASes typically belong to Internet service providers (ISPs) or other large organizations, such as tech companies, universities, government agencies, and scientific institutions. Much of this information can be commercially collected and available.


3) Use Cases for PDNS and BGP in the SOC:

  1. Identifying attacker or botnet infrastructure.
  2. Identifying all internet-facing infrastructure in business use.
  3. Identifying tactics, techniques, and procedures of attackers.


4) Use Cases for PDNS and BGP outside of the SOC:

  1. Verify internet-facing applications and infrastructure for merger, acquisition, and compromise items for M&A.
  2. Verify internet-facing applications, infrastructure, and compromise for suppliers. 
  3. Review staging infrastructure of competitors to scan product launches. 
  4. Investigate threatening emails to executives.
  5. Investigate disinformation websites and infrastructure.


5) Enrichment is King and Does Not Need to Be Resource Intensive:

If security teams are not engaging with the business to solve problems that risk revenue generation, data sets like PDNS or BGP do not matter.  For example, if an organization does not control DNS at their borders, they will lose a lot of visibility to reduce risk and potentially give away proprietary information.


Listen to other podcast episodes

Read Transcript

LANDON: Welcome to the Cyber 5, where security experts and leaders answer five burning questions on one hot topic on actionable intelligence enterprise. Topics include adversary research and attribution, digital executive protection, supply chain risk, brand reputation and protection, disinformation, and cyber threat intelligence. I’m your host Landon Winkelvoss, Co-Founder of Nisos, Managed Intelligence Company. In this episode, I talk with Open Source Context’s Donald McCarthy. We discuss external telemetry available to the private sector, with a focus on passive Domain Name System, or passive DNS, and Border Gateway Protocol or BGP. To simplify, passive DNS is a way of storing DNS resolution data so that you can reference past DNS record values to uncover potential security incidents, or discover malicious infrastructures. BGP is designed to exchange routing and reachability information between autonomous systems on the internet, and are often complimentary to passive DNS. Both of these data sets are critical for threat teams as they often provide critical information on attacker infrastructure for the SOC, but they also help solve problems and provide context on a much broader scale. We’ll discuss those problems on the scale next on the “Cyber 5.” Mac, welcome to the show, sir, would you mind sharing a little about your background with our listeners please?

MAC: Thanks Landon, I appreciate it. My name is Donald McCarthy, I go by Mac. I am a former infantryman through the United States Army Noncommissioned Officer. And after I left the army, I got into computer science and ultimately cybersecurity stuff through the Linux High Performance Computing project at Middle Tennessee State University. Been doing information security stuff for 15 ish years, almost 15 years now. Currently I serve as the Director of Field Operations for Open Source Context. Open Source Context is a startup that focuses on passive DNS and historical BGP data, and it’s collection indexing and searching. And our primary focus is really to help break down data silos inside of an organization, automate the SOC for resiliency and workload reduction, and enrich external data sets so that when the SOC is making a decision, they’re not making blind decisions. Fortunately, with DNS being one of those interesting data sets that touches every single workflow that everybody does. We’re a digital workflow society at this point, and because DNS is an integral part to the way the network functions, it also has a really cool, interesting side effect of being able to bridge a lot of gaps inside the organization to make other teams besides just information security, more effective and help information security be more than just the guys who say no.

LANDON: First of all, thank you for your service. And certainly second of all, explain passive DNS and BGP data and how that’s generally collected.

MAC: BGP and PDNS are similar data sets and in some ways they’re collected exactly the same. And then there’s a slightly different method for each of them. So, if we look at PDNS first, passive DNS is quite simply, and for those who don’t know what it is, it is a data set that is somewhat like a historical phone book, if you will. So, DNS is the phone book or the yellow pages of the internet. Is a way that I’ve frequently described it and heard it described. And passive DNS would simply be having the yellow pages going back many years, and seeing how things changed over time, both for the organization and the network. So you can collect passive DNS one of two ways. The first method is you can collect on the resolver. And doing this means that you have to have access to the resolver, and being able to enable logging on the resolver itself. We generally refer to that as teeing the resolver. The second way you can do this is to just listen on the wire. Typically, DNS is port 53 UDP unencrypted. That’s how it works best, that’s how it was intended to work. There are other implementations that are beyond the scope of podcast that I’m not gonna say that they don’t work, but they definitely don’t perform the same way that port 53 UDP is.

So that’s the way that most people choose to run DNS. And for doing so, you can put a sensor like bro, or onion, or snort, or suricata out, and you can collect those as well and then parse them from that. So both of these methods have a little bit of their pros and cons. If you actually log on the resolver itself, you can get really interesting data in the fact that you’re gonna know who the stub resolver or the asker of that question is. And in an enterprise environment, that can be really helpful if you’re doing breach or post-incident investigation to know which stub resolvers, which clients on the network asked that. However, on busy resolvers, you’re gonna need to have a disk I/O for every query, and this really could lead to a huge performance bottleneck. The other way that we would do it is obviously via teeing it. And there are really two ways to tee the resolver. The first way is to tee say downstream of the resolver or between the stub resolver and the recursive resolver, what most people think of as the DNS server. And if you do that, you get all the benefits again, in an enterprise environment of knowing which client actually asked that question. However, you have to be really careful and make sure that you’re not violating ULA’s or local jurisdictions.

Because some jurisdictions consider that DNS ask PII. So the second way you can do it is to just jump upstream of the resolver. So, once you do that, you know what question is asked, you know what the answer is given, you just don’t know exactly who asked the question. And in general, that’s fine. Even for people who collect behind on the stub, when they allow query access to it, they generally actually do some kind of thing to mask and anonymize the data, and only want that stub access or to know which stub resolver asked the question, in the case of a necessary investigation. So they have some kind of a break glass policy that has controls around it.

LANDON: When you say resolver, to the layman that’s listening, talk about that.

MAC: When you make a request for any network resource that’s using a domain name or a host name on the internet or on the network, you say, “Hey, I want to go to” And your browser, your computer turns into what’s called the stub resolver, or the client. And it asks a preconfigured address that could be issued via a DHP, or can be manually programmed. One of the most famous sets of resolvers are the quad4s, the quad8s, the quad9s, the quad1s resolvers like that, and those are recursive resolvers. And the recursive resolver is the next step in that chain where there’s a recursion process for those who are familiar with computer science, that works from that root down through the TLDs into the domain, and asks a series of questions to different places and servers to get the answer of is hosted at, or whatever answer you get. Generally you go either through that recursive resolver process, or if you’ve asked the question very recently, that recursive resolver will cash the answer for some period of time. And if it’s within that cashed period of time, instead of actually going all the way out to the internet and asking these questions down the recursive stack, it will just answer the question the way it knows it inside the time to live.

LANDON: You made a comment that’s interesting that, depending where their collection point is that some ULAs see this as PII, what about passive DNS? ‘Cause if we’re talking about the phone book, the way most people understand the phone book is name and phone number. We’re talking about IP addresses here, so a lot of people know generally how you can have static IPS, you can have dynamic IPS. So depending on who it is, a few people would agree that an IP address is dedicated to PII. So, how are some ULAs classifying passive DNS to PII?

MAC: It depends on how the agreement is made with the employees. Some employers absolutely say, “Hey, we’re gonna monitor everything you do on your workstation.” In some jurisdictions that’s not legal. And some countries, they believe that the right to privacy is that if you ever asked a question on the internet, you have the right to be forgotten, and that’s fine. Because in the general case of passive DNS, you actually really don’t need that. In the initial investigation phase unless you’re doing a very specific corporate investigation that’s not beneficial. It also leads to a lot of duplication of data and it can slow down. So if I’m storing the address for Google in my database, and I only store the changes to that address, I may have maybe 100 entries as Google changes through IPs and load balancers over time. But if I’m storing every single person that asks for that address, then I’m storing those same 100 answers potentially a million times each.

So searching and storing it becomes a bigger problem and, that’s generally why, especially at O/S context, we steer away from it because we don’t believe that it provides our clients that extra value, and it would just be a huge cost. But the other part to that is if you think of DNS as the phone book, and you said, “Hey people think of it that way.” That’s right. But passive DNS would be more akin to something like a pen register. So it’s not just knowing that a particular entity is located at a particular address, it’s that metadata of knowing that a particular entity is located at a particular address, and a other entity had a conversation with that person at an address at a particular time. And that’s where people start to see the privacy issues and we understand that and respect that and have made choices to make sure that as we get our data and we work with our partners, that that privacy is protected, and we’re just really not interested in who asked the question.

LANDON: Did you discuss BGP data and how that works as well?

MAC: Sure, so BGP is how we say, I love it when we draw it on a whiteboard, we put a Cloud up and we say big eye. This is how big eye internet works versus little eye internet as people think about it. ASNs, the Autonomous System Numbers are kind of how we route things between bigger networks. So, the routing tables on these routers especially historically needed to be considerably smaller than knowing exactly where every address on the internet was and individually was located. So we broke them into networks and autonomous systems. So one of the things that BGP can do, you can dump the outta routers that is less interesting but effective. And you can get that data for free at places like the Route Views Project from the University of Oregon. Or you can simply listen on the wire for these announcements that are made. Because these are also clear text made announcements.

And one of the things that you get if you’re listening on the wire is, technically nobody should be announcing anything smaller than 255 IP addresses or a /24 network. But sometimes people do try and make /29 announcements or something smaller than a /24. If you have a properly configured router that’s reporting to these free projects, you probably won’t see that come across. But if you’re listening to that announcement on the wire, you could. And one of the interesting pieces especially for an intelligence piece, is when somebody either announces a more specific prefix, because we network engineers understand for sure that the most specific route generally wins. So if they are going to announce a smaller prefix or a more specific route, and they’re targeting either a particular part of your client base, or they’re trying to reroute a particular part of your network traffic, ISPs that put less controls around their router and are less willing to configure things properly may actually accept that announcement and could lead to your customers having a bad experience on your behalf.

LANDON: That’s certainly helpful. And it frames the context of a lot of different, security teams can use this type of data. What are the common use cases that you’ve seen applied from the private sector? Just for context, you have an enterprise that has routers and packets that are designed within its internal perimeter. I mean, that’s obviously being overhauled with a lot, and a lot of people moving to the Cloud. But between Cloud infrastructure and on an on-prem infrastructure, you have your perimeter and everything that we’re talking about is outside of that perimeter, which is the heart of what threat intelligence really is. So I guess, what are the common use cases that you see applied? How do you apply this?

MAC: They’re pretty wide. I love the fact that you mentioned the Cloud and we used to play the drinking game, right? Anytime somebody says the word cloud, you gotta take a drink, but the reality is that the Cloud is here and it’s here to stay. One thing that I know some of my clients use this for is quite simply, they spin up a Cloud service, and it’s located at a particular IP address, or they have to use a CNAME over to a record. And one of the things that they do is monitor who else is using that IP address, or who else is pointing back to a similar CNAME record, simply because they want to monitor the reputation of things in their neighborhood. So it used to be that if you had all of your on-prem infrastructure and you were in your own /24, that you leased from one of the IP leasing agencies, you had your own ASN or however that worked, you were connected to the internet with IPS that belong to you. So you could control what was using them in a sense, or at least you had responsibility to control who was using them with you. Sometimes they got breached and you didn’t.

But if you were doing something reputationally poor on the internet, you would potentially, or should be able to see that, and your own IP space would suffer the consequences of potentially having a poor reputation on the internet. However, as we move to the Cloud, I can be doing completely good well-intentioned actions on a specific set of infrastructure or IPs that may be shared with 100s or 1000s of other people, and their actions actually have some potential consequence on my brand reputation. So, if brand reputation teams who are typically not super technical teams, and that’s fine, but work with the security team or others that have access to the passive DNS data, they can actually monitor over time potential impact that lesser respected brands that may be sitting on the same infrastructure have for them. But then we can take it back to the traditional SOC. One of the things that you can look at is domain name comes across, was it ever parked in an RFC 1918 Space? That’s an indicator of potential botnet activity and how botnet operators oftentimes park their bots. Or is it known to be a sinkhole address? There are well known sinkhole on the internet. So did somebody try and sinkhole that domain and respond back?

And these are things that you can do automatically as alerts come into your SIEM or your SOAR, or whatever platforms you’re using there. And as you enrich that data, as you get more context around that data, especially when you do it in an automated way, your SOC analysts get more time to respond to either more events, or they get more time to go grab a cup of coffee, because the time to response to a traditional event goes down. We’ve seen merger and acquisition teams use this. One of the best stories that I ever had, is, I walked into a company to do a demo, and they asked the same question that you did Landon, “Well, how do you use this aside from these four use cases here?” And I said if you find me somebody in the enterprise that’s involved in internet technology, I can probably find some way to use this data for them. And on a friendly bed of a beer, they walked me over to the merger and acquisition team that just so happened that the guy was sitting at the desk and looking over a declaration form of what IT assets that a company that they were potentially gonna buy was declaring. And one of the things that they did was declare no Cloud services. And going back to that Cloud thing again, that’s strange in today’s IT environment.

So we just started taking a look at the domains and some of the IPs that that company used, and low and behold, they were really being incredibly truthful. There were not traditional Cloud infrastructures. They didn’t seem to have slack pointing back to them. They didn’t have email service providers that were delivering mail on their behalf. Their SPF records were their own internal hosted stuff, which was interesting except for the one thing that they forgot was their DNS was actually hosted at Google. And we may or may not think of that as a Cloud service, but the reality is if you purchase that company and you don’t know that ahead of time, and you can’t get control of the DNS once you take possession because you didn’t get the Google account, that matters.

So, you can use it really in a broad places. Another use is third party risk and compliance teams using the BGP data. We were pitching another company that ultimately became our client, and we were looking at the provider that managed their 401k. And it just so happened that they were announcing their routes on a much bigger block than I would typically think that I want to announce the routes. And from a number of places, there were routes that got announced that said, “Hey, this particular /24 needs to go through Brazil, and then to Romania, and then back into the United States.” And it was really interesting for them to be able to call their vendor and say, “Okay, did you know about this? Is this proper?” That may have been completely proper, may have been in a man in the middle attack, who knows?

LANDON: On that note there, what we’re talking about here is risk, right? What is the business risk that you are just talking about that example around the 401k provider?

MAC: You gotta pay your employees. And they wanna know that the things that they’re doing are safe and secure. So if you are providing your employees service through a retirement plan like 401k, or a 43B, or whatever it is that your company has decided and elected to do, and you’ve outsourced the management to that, you wanna know that when a customer logs in to that space, he has the shortest path possible. And along the route, the only people that can see into that traffic ideally are the customer, and your 401k service provider. But if you’ve got a foreign entity, whether it’s a state sponsored entity or a less state sponsored entity, something like Evil Corp or something like that that’s doing targeting and reconnaissance on your employees, or trying to get man in the middle on your employee’s money, whatever it is that they do, if they reroute that traffic. So it’s not going straight to the data center where it’s supposed to, and then it runs back out through Brazil and then through Romania, where they have infrastructure to run an SSL downgrade attack or something like that. And then back through, and they just proxy it along the route, your employees may be giving a criminal organization complete access to their retirement account. And they’re not gonna be real happy with you and your selection of a retirement provider if their 401k savings all of a sudden gets transferred out beyond their control.

LANDON: So everything you’re describing here, it has a risk and compliance type of feel for it. So how do you use this as well? What’s a use case for an investigation? Walk us through that as well.

MAC: One other investigation that we helped out with was simply we were working with a company and looking at their email servers, and they had gotten a series of phishing attacks into their email server. And one of the things that we noticed when we started looking at that and the company noticed as well was quite simply that they had a complete offsite disaster recovery set up for their mail. It was well synced, but it was very low in the mail priority records. And in doing that, this organization was targeted through their fourth priority mail server. That’s not typical. It’s not coincidental. Maybe it’s coincidental if one piece of mail arrives to your fourth priority mail server for some reason, but for hundreds of pieces of mail to arrive to your fourth priority mail server is definitely atypical. And this company engaged back with the attackers and they were a very skilled ransomware group that was trying to ransom this company, but knowing your actors’ TTPs, knowing the skill level of your adversary is incredibly important. And a less skilled adversary would’ve just let the MX records of DNS, do the routing the way that the MX records did.

A more skilled adversary, made a bet that they weren’t running the same male policy settings or male prevention settings. They weren’t paying licenses for something like a proofpoint or other mail security product on their backup servers. And they made that bet and they went after it, their bet was wrong, they failed. But in many organizations, I could say that I was probably gonna be a pretty good bet. So that’s an intelligence use case on it. So another place that companies use this oftentimes is a corporate counterintelligence mechanism. So there was another customer that I had that they brought their brand reputation team in, and a marketing team and showed them some certain things. And somebody else had an idea and, “Hey, we have this team that’s dedicated to researching our competition so that we can stay even with them. And it was very interesting. They brought that team in and said, “Well, what can you do for me?” And I wasn’t even involved in this, I got into it after the fact because it was just one of the coolest stories I’d heard. And they just started doing, show me all the host names in my competitor’s domain name space. And ultimately, several weeks, at least I believe it was closer to two months prior to this company launching an updated, revised, overhauled version of a product. It was considered a new product launch, I don’t know that it was truly a new product launch, but they were really gonna reposition how it was in the marketplace and what it was doing.

And they stood up the staging infrastructure for this. And it got picked up by the automated process that the security team had helped this team set up. It’s counterintelligence, right? I don’t know what we would really call it in the corporate space. The corporate competitiveness division, whatever it is, these guys went and pulled down the pages. They weren’t hidden, they weren’t blocked. They could go and see, and they had weeks and weeks notice of how this company planned to basically roll out this product and rebrand it, remarket it, update capabilities, reposition it against them. And they developed a whole counter strategy to that that was ready to go, and as this company was doing this big webinar or launch event, if you will, to push the product into the marketplace, the other company had their entire response to it. Let press releases go and how they were perfectly positioned to compete with it, had all their websites ready to go before their competition completed their launch event. And it really took a lot of win outta the sales of the competition, according to their competitive intelligence folks.

LANDON: If you’re a chief security officer and you have to protect the executive team. Let’s say, executives get no shortage of threatening emails for example, how can passive DNS and BGP be used in that regards as well?

MAC: I’m not gonna claim to know the answer on the BGP side, I haven’t really thought about that one. However, I think from a passive DNS standpoint, you can do a number of things. First of all, knowing where the emails are actually coming from. If they’re not being sent from Gmail, are they being sent from spambots, are being sent from a static IP at a data center that you can then tie back to somebody. So, being able to reverse in on those email headers is incredibly important. The other interesting thing you can do is, I mean, if you remember, there was a famous InfoSec reporter that had a social security number published in DNS along with some other records.

So being able to do things like search for text records or other records that may contain information about your executives that get put into DNS as signaling mechanisms is another example on that. And then the other piece that you can do is quite simply, if you think about DNS and your attackers, you can model TTPs out of DNS. You can see that they may have a particular way or place that they start to set things up and then move it to a live infrastructure. They may have a particular naming convention, something else like that that you can look in on that. And because of that, you can micro target risk and premine DNS, or passive DNS for information that could potentially expose your executives and you can actually give them a higher layer of protection and micro target their risk.

LANDON: So I mean, what you’re saying, and we deal with this quite a bit with Nisos as well. And if you truly want to determine quickly that if your executives are being a target of opportunity or target of attack, passive DNS is a pretty critical data set to be able to access and ascertain, would you agree?

MAC: I would agree. And more I would agree that it’s not necessarily gonna tell you that your executives are under attack. You’re gonna have a lot of other signaling mechanisms about that. I think passive DNS is gonna give you a lot more information about potentially who is attacking them, as well as the skill level of who is attacking them.

LANDON: That’s helpful. You’re talking about a lot of websites. You’re talking about collecting them, that’s essentially what passive DNS really is, is collection of a phone book on the internet. My mind immediately gravitates toward disinformation. Disinformation actors routinely set up webpages to propagate their narratives. And of course use social media as the outlet, walk through how passive DNS and BGP are and pull in those aspects as well.

MAC: I’ve spent a little bit of time working with the intelligence community both when I was in the military and having left the military. And one of the things that these folks consistently talk about is getting left of boom. That’s the ideal location to be in intelligence is before that event happens. So one of the things that you can do, especially when it comes to different information campaigns and other things, and I wrote a blog post about this actually on our site that goes back to the whole ivermectin piece. We could see a significant rise prior to the pushing of the ivermectin, and we could see people actually standing up these sites and we were looking for things like vermectin, right? whether they were spelling it with an evermectin or an I as an ivermectin, there were a number of different spellings. So one of the things that we were able to do is actually look for those terms and newly resolving domains over time, as we saw it.

And we really, through the summer where ivermectin became popular, we really watched the number of domains that talked about ivermectin grow significantly. So if you’re looking at disinformation campaigns, both from an intelligence standpoint or even a social network defensive standpoint, being able to constantly look back into this DNS data set and see the things that are new and see the things that are new that meet interesting terms. Terms that organizations maybe like QAN on or others post out, and those things turn into domain names. You can monitor that. And then the other part of it is things like bulletproof hosters or other particular signatures, if there’s a particular neighborhood that these folks like to, disinformation campaigns get hosted in, one of the things you can do is say, “Okay, fine. I know that this range of IP addresses is regularly out for disinformation or host disinformation campaigns.

Tell me anything new that shows up in those IP addresses.” And you may not be completely left of boom, You may be just right of boom, but ideally, you’re becoming more proactive. And it removes a bit of the assymetry of just one person versus the whole world. And you’re automating that, and then at that point, you can write scripts to do things like, “Oh, we found a new domain name. Let’s go pull the main page on that domain name using a script that’ll take an image or a screenshot of that. And we can present that to relatively low technically skilled analysts. People who are more traditionally intel analysts, not IT analysts, and we can make that an automated process where they’re flipping through screenshots and they can make a reasonably quick decision as to whether that really looks like a disinformation campaign or whether that happens to be somebody who chose the wrong place to host their platform.

LANDON: Is data alone enough or does this need to be enriched with other open source data sets? And if so, what are the most common data sets? How do you aggregate a lot of this to actually solve the problem at hand?

MAC: The short answer is no. This data by itself is never enough. I don’t think any data set by self is ever enough. Part of it is because data is just data. It’s not until you run it through some analytical processes, some of them may be automated and machine based, but others are gonna be human based, that we really transition that data into information. And then again, it’s another reanalysis of that if you will that matters into inferences and conclusions. And that’s what we generally think of as intelligence. So, in order to get intelligence, this data is not enough, there’s process that you have to structure around that. As far as other data sets to make PDNS more useful, well, that’s the opposite way that I generally think of it. Generally what we’re going to do is use PDNS to enrich other data sets. Especially network-based data sets. So, no, the data isn’t necessarily enough. And I’ll also go back to a thing that I talk about with CISOs and others again, which is, it doesn’t matter how good your PDNS data. It doesn’t matter how good your SIEM and SOAR are, if you are not really engaging with your business, if your security team is thought of as the jerks, you just say no.

If you aren’t getting security embedded as part of the culture of the business, or as part of the main business processes of the business, you’re not gonna be successful. It doesn’t matter how good your data is or not. People are gonna still click on links they shouldn’t click on, people are still going to be an insider threat, whatever it is, if you aren’t really getting into the root of enabling business with your security team, you’re just not gonna be success. And that’s part of why I really love PDNS and BGP because whether people realize it or not, again, it touches all the things that they do. So it allows a CISO to give a security team a charge to go empower business units, to go assist business units, and not be that team that says no. So when the team does have to come in and say no, when the team does have to come in and make a hard decision based on data that they have, then they are more likely to get cooperation. And the business unit itself is more likely to say, “Wow, this is gonna be a little painful in my business process, but that team supports me, we can support them.”

LANDON: You’ve mentioned the security team and the CISO team that really needs to ingest this. There’s a lot of people that are big believers in threat intelligence, big believers in intelligence to begin with, to prioritize a unique risk based approach for what the business needs. Do you really need to advance security team to work with this kind of data? And if not, what blocking and tackling needs to be in place before they can really start leveraging these types of data sets?

MAC: The point that I can’t drive home the most is quite simply, if you don’t control DNS at your border, if you are not forcing the business to use your resolvers, you’re gonna lose a lot of visibility. So one of the first pieces of blocking and tackling should be, I shouldn’t, as a general case, have a stub resolver in my network that is able to directly reach out to somebody else’s DNS server. It should be a DNS server that we’ve chosen that we control. Now, you could have it reach out to somebody else’s DNS server because you’re paying for DNS as a service or something like that. But again, that was your choice of who they contacted not their choice. So that’s the first thing you should do. You should always control it at the border. And that doesn’t take a super highly technical skilled security team to do that. That’s a firewall wall policy that even junior security engineers have no problem writing that policy. The second part to that is, PDNS can be a huge part of your basic blocking and tackling. So just because you don’t have a super advanced team also doesn’t mean that you can’t take advantage of using PDNS to actually reinforce some of basic blocking and tackling pieces.

So you’ve gotten DNS controlled at your border. You’ve taken that step one. So, one of the things that you should probably ask yourself is, what does my attack surface look like from the external world? And passive DNS is a tool that can actually do that. So I can use vulnerability scanners and other things to scan my IP address range, but not necessarily if, will I get all the host names that are assigned to a particular IP address especially things like load balancers, unless I have our DNS, reverse DNS, properly configured. And that’s not the general case. I can find potential attack surface or inventory of things that are on my network that I didn’t know about before. And that’s huge, right? When you look at critical controls, knowing what’s on your network is a critical control. Being able to have an inventory is a critical control. One of your next steps of critical controls as your organization matures is things like security architecture reviews, and change control process.

So, if I see a new server pop up in the staging area, or a new server pop up in our production environment, that I have no clue about me being the SOC or the security team, or the responsible party for change management, and I’ve never seen whether that’s in inventory, whether that’s in the patch management, whether a security architecture review was done on that, whether it was proved for the rollout, I know too big things about my organization right there. If I did have a change management process in place, and it included whoever managed DNS, there’s a breakdown in how they’re responding to that process. But then the second part of that is, I know that there is something out there that I need to quickly be able to get my hands around. And if somebody deployed an old version of Log4j, the last thing that we wanna do, is provide a nice, neat ownership with an old phone or something like that out. So, that’s probably the easiest thing that you can do. It’s a basic search, we can script it in five minutes, I can help somebody who has no technical knowledge set that up as something that runs multiple times a day and delivers the results of that to email for something like their managed security provider to deal with. Or their managed intelligence provider. So, if you wanna get the absolute most outta passive DNS, and you really wanna press it out to the edge, yeah, you need some security team, you need some security team with experience, or you go out and you find yourself an MSSP or a managed intelligence provider like Nisos.

LANDON: We’ve talked a lot about the use cases. We’ve talked a lot about the teams that need to ingest. We’ve talked a lot about analysis. At the end of the day, we’re intelligent providers, it’s all about outcomes. What are some outcome that you’ve seen derive from those types of problems?

MAC: So, we’ve seen a number of outcomes come from that. We’ve seen business email compromise attacks stopped. We’ve seen phishing attempts to try and get ransomware installed through backup mail servers stopped. We’ve seen competitive intelligence gains. We’ve seen mergers and acquisitions be more successful and faster at being able to vet the IT infrastructure of people that they’re doing their due diligence on. But the biggest thing at the end of the day, and the biggest thing that I want to, again, drive home and Landon I know that you hate buzzwords, but I’m gonna do it anyway, which is business enablement. Enabling the business. Being a business partner as opposed to a business stopper. And what I mean by that, again, is going back to that CISO. If the CISO can use the security team to support business process, to help people that are not necessarily security focused do their job better, do their job more complete, or do their job faster, and have other time to do other things, that really is a business in enabler. And it transitions security into the mindset and the culture of the business and away from just this thing that we have to do as a training once a year. And when it comes to the SOC, if we can reduce that time, one of the biggest things that you can hopefully do as a CISO, is not do seven interviews for SOC analysts every week because you’ve got a constant churn.

LANDON: Love what you guys are doing at Open Source Context. We come from the same community so certainly that mission to drive and find bad guys and really help enterprise and reduce loss is certainly impactful and goes to our core, I appreciate you joining us here today. For the latest subject matter expertise around managed intelligence, please visit us at There we feature all the latest content from Nisos experts on solutions ranging from supply chain risk, adversary research and attribution, digital executive protection, merger and acquisition diligence, brand protection and disinformation, as well as cyber threat intelligence. A special thank you to all Nisos teammates who engage with our clients to conduct some of the world’s most challenging security problems on the digital plane, and conduct high state security investigations. Without the value the team provides day in, day out, this podcast would not be possible. Thank you for listening.