Zero Trust DNS Security Webinar: DNS as Border Control

Standing by

00:05 – 01:29

Hello everybody. Welcome to the webinar.

We will wait a few more minutes for people to join.

We will wait one more minute to let everybody join, and then we will start.

Introduction

01:29 – 03:05

Okay. Hi everybody.

Thank you for joining us for today’s webinar on Zero Trust Security and the critical role of DNS in it.

The session will be recorded today, and we will send you the recording after the webinar, so please take that into account.

I will now get started.

I am Yaelle Harel. I lead Product Marketing for Security Solutions at EfficientIP. I have over 15 years of experience in cybersecurity protection, and I focus on helping organizations strengthen their security strategies with DNS-based defenses.

Today, I am honored to co-host this webinar with Peter Goodwin, one of the leading experts in DNS security. Peter, I will let you introduce yourself.

Hi, thank you Yaelle. My name is Peter Goodwin. I am the Customer Solutions Director for EMEA at EfficientIP, and I have been working for EfficientIP for the last four years.

Thank you, Peter.

Today, we will start by understanding the Zero Trust model and what it is about. Then, we will talk about the role of DNS in Zero Trust Security.

After that, we will review how enhancing access control with DNS-based micro-segmentation can help with Zero Trust implementation.

Then, we will look at how proactive DNS threat detection and adaptive response can help. We will also see how simplifying Zero Trust with observability and automation can be achieved.

Finally, of course, we will leave some time for questions and key takeaways.

Understanding Zero Trust Through a Real-World Example

03:05 – 05:43

Let’s start by understanding the Zero Trust concept through a non-technical example from the real world.

A few years ago, there was a major issue in Poland where visas were being sold for money. People were given visas without background checks, security checks, or proper regulatory processes.

As a result, many people who received a visa from Poland traveled around Europe and outside Europe thanks to the visa they had obtained, and thanks to the Schengen Agreement.

Let’s see how this could theoretically impact Europe. This is not an exact real case study, but rather a theoretical story.

Let’s meet Selina Kyle. She is a thief who wants to enter Europe. More specifically, she wants to enter France and cause damage in one of the famous museums. She wants to damage the Mona Lisa painting because this would help her build her reputation.

She wants to get to France, but she knows she cannot obtain a French visa because she is already a well-known thief with a criminal record.

Then, she sees on TikTok an ad saying that she can get a visa for Poland for about $5,000, without any background check. This is something that really happened at the time.

She applies for this visa and receives a legitimate visa through an illegal process.

Then, she travels to Poland using the Polish visa she purchased. She manages to enter Poland.

From that point, it is very easy to get to France. She rents a car, goes to France, and her mission is accomplished.

Of course, this is a theoretical story. It did not happen exactly like this and may not be realistic in all details. But it helps emphasize the meaning of Zero Trust.

Once you trust someone who is inside the organization, they can move around and do whatever they want inside the organization.

Now, let’s take that idea into a real cyberattack example.

Real Cyberattack Example: Verkada Breach

05:43 – 09:41

Let’s start with a short video.

Hackers infiltrated thousands of internet-connected security cameras used inside schools, hospitals, and several major companies.

CBS News reported that the hackers claimed to have breached the feeds of 150,000 internet-connected security cameras.

Some cameras showed hospital staff and security personnel dealing with a patient appearing to have a medical episode. Other cameras showed what appeared to be a hospital intensive care unit, police interrogation rooms, prison cells, community centers for children, as well as factory and showroom floors of automakers such as Tesla and Nissan.

As you saw in the short video, this was a major data breach involving a company called Verkada in March 2021.

Attackers managed to exploit their system. They exploited a support Jenkins server vulnerability and entered the organization.

Let’s look step by step at what happened.

First, the attacker managed to gain admin credentials that were simply exposed on the internet.

They then accessed the Jenkins server thanks to a misconfiguration of this server.

Once they had the admin password, they managed to access the support web interface. This was a support system used to help customers who had security cameras, for example to solve issues or improve camera resolution.

So it was a support system with some access to customers’ remote cameras.

The next step was access to the command platform, which allowed control over customer cameras. This was already the system with direct access to customers. In this case, it had access to all customers.

We will talk later about how Zero Trust could have helped in this situation.

After that, the attacker executed commands on the cameras. Not on all cameras, but on many cameras involved in the incident.

For example, they ran commands to identify information by IP address. They managed to obtain Wi-Fi names and passwords, as well as other interesting information.

The important point here is that commands were running on the cameras, and some traffic went externally from the cameras. This could theoretically have been detected if the relevant measures had been in place.

The next step was downloading footage from around 150,000 cameras.

The download was not done directly from the cameras, but from databases storing the camera footage. The attackers also managed to access some live footage, as shown in the video.

Finally, as if all this were not enough, they managed to obtain badge credentials. This means they could potentially have printed actual badges, accessed customer buildings, entered them, and caused additional damage.

They did not do that in this case. The attackers claimed they only wanted to show the vulnerability of security cameras.

Still, they reached a lot of information and accessed very sensitive data.

How Zero Trust Could Have Helped

09:41 – 15:30

Now we will demonstrate how Zero Trust could have helped in this attack, if it had been part of the company’s architecture or strategy.

The first step would have been to protect the password. This was the entry point of the attack.

A simple procedure such as multi-factor authentication could have blocked this attack in this case.

Of course, the principle of least privilege would also have helped. It would have ensured that, even if the passwords were stolen, the attacker would not have been able to do everything we just described.

The second point is not directly confirmed in this story because we do not have evidence that phishing was used to retrieve the password. However, phishing is one of the most common methods used to steal passwords and data.

Having anti-phishing protection and advanced engines to detect phishing is also important to protect such information.

At the second step, it is very important to prevent the use of those credentials.

In the Zero Trust principle, which we will see in the next slides, we never assume trust.

Even if someone has admin credentials, and in this case super admin credentials, it does not mean they should be able to access everything in the organization.

This is a good example of why.

The organization could have implemented measures that would have blocked the attack one step after it started.

Network segmentation is also important. There was no reason to give the admin access to all footage from all cameras. Yet the attackers managed to access almost everything without segmentation or business-need definition.

At the next step, when the attackers accessed the command platform, micro-segmentation could again have blocked lateral movement.

Another important aspect is continuous authentication, which ensures ongoing trust verification.

The idea is that when someone moves inside the organization, we never assume that it is still a verified person. In this case, it was not a legitimate person moving around, but an attacker.

If the network had been monitored and if access to each element had been continuously verified, the damage could have been mitigated.

The next point concerns the commands that were run on the cameras.

Some traffic left the cameras and went to domains that were not needed for camera management.

Granular access control using DNS, which operates at a very early point in the network, could have detected or blocked such access. For example, cameras could have been allowed to access only their management systems and no other domains.

We will see later in the demo how this can be achieved with DNS.

DNS monitoring and user behavioral analysis could also have detected anomalies in the traffic and helped block the attack.

When the footage was downloaded, behavioral analysis could again have helped. Of course, no technology can promise to detect everything, which is why a comprehensive approach is needed.

But anomaly detection of DNS traffic going from the organization to the internet could detect data exfiltration. It could have detected footage going to a place where it should not go, such as an external cloud source rather than an internal organizational server.

Additionally, automated response to that detection could have blocked the attack before the footage reached the attacker.

The video footage and images from the different cameras could potentially have been stopped automatically.

Encryption of the data would also have helped.

Regarding the last step, where the attackers gained access to badge credentials, user-based access control would also have helped.

They managed to obtain information that they should not have accessed. An admin did not need access to user badge credentials.

Automated response could also have helped by quickly blocking the users whose badge data was stolen from accessing the organization.

If everything had been deployed as expected in a Zero Trust model, maybe, just maybe, the cybercriminals would have dropped the attempt to attack this organization and moved to the next victim.

What Is Zero Trust?

15:30 – 17:16

What is Zero Trust?

I have talked a lot about Zero Trust and said I was introducing it, but I have not yet explained what it is.

First, Zero Trust is a philosophy and a security model, not a tool or a product.

It was introduced by Forrester as an alternative to the perimeter security model.

Why was it proposed?

Because in the perimeter security model, once someone is inside the perimeter, they are trusted by default.

But perimeter security is no longer enough. Environments have become more diverse and hybrid.

Organizations now have environments combining cloud and on-premises infrastructure. They have remote workers. They have IoT devices.

So we can no longer use past security assumptions.

With a Zero Trust security model, everyone is untrusted by default, even if they are already inside the network.

All access requests must be verified, and users are only allowed to proceed if they are explicitly permitted.

This case is a good example.

It is not necessarily that the admin did something intentionally wrong, besides maybe using a weak password or exposing the password.

The issue is that someone took control of the admin’s credentials and used them to move inside the organization.

A Zero Trust approach can help reduce such incidents.

The Role of DNS in Zero Trust Security

17:16 – 19:27

What about DNS and its role in Zero Trust Security?

Let’s start with a few reminders about DNS.

DNS is a critical point for every organization. It is positioned as an early checkpoint that can be leveraged to perform checks at a very early stage of an attack.

DNS routes internal and external traffic between users and applications.

This means that a lot of traffic passes through DNS, and DNS offers visibility into network traffic at the user level.

We will see examples of how this information can be leveraged for detection, visibility, and automation.

This is possible because DNS is located in a very critical place in the organization.

DNS also holds data about the behavior and intent of users in the network.

By using DNS data, organizations can understand what is happening in the network and detect anomalies that may indicate attacks.

With that in mind, let’s look at what network and security teams say about the use of DNS in Zero Trust.

This comes from a 2024 EMA survey on Zero Trust, which surveyed 270 companies in the US, Canada, and Europe.

All respondents mentioned that DNS has an important role in Zero Trust implementation.

DNS can help with policy enforcement. It can help reduce the attack surface through security solutions, and more.

Now, we will talk about the four main use cases where DNS can help with a Zero Trust networking strategy.

Peter, I will hand over the microphone to you.

Four Zero Trust Principles Where DNS Helps

19:27 – 23:14

Thank you, Yaelle.

These are four key principles of Zero Trust, and DNS fits into all four of them to some extent.

First, never trust, always verify.

As mentioned earlier, DNS is typically the first part of any network transaction. Over 90% of transactions start with a DNS request because people generally remember names, not IP addresses.

Having the DNS request at the beginning gives organizations a perfect opportunity to apply security profiles at the start of the transaction, rather than waiting for something to happen later.

By default, organizations could deny all DNS requests so nobody could do anything. But if a request is validated, the user can be authorized to proceed.

The second principle is least privilege and default deny.

Typically, when someone is inside a network and makes a DNS request, they receive an answer.

It is almost like using an old phone book: you look up the information you want, and it is freely accessible.

If organizations want to control what people access, they can start by saying that users only get access to what they need to do their job.

Users start with no privileges, and permissions are increased only as needed.

The third principle is full visibility and inspection.

You cannot secure what you cannot see or do not know about.

Being able to look at what people do with DNS on a daily basis, and to look at individual behavior, gives organizations more ability to control what is happening.

Most organizations ignore DNS day to day.

There is so much data generated by DNS queries across a network that analyzing it in near real time, or even after the event, is difficult.

Unless there is an issue, nobody really looks at DNS. Forensically, teams may go back and look at what happened after an event. But if DNS is working, people usually leave it alone.

The fourth principle is centralized management.

Most organizations have more than one DNS server running in their network.

If they want fine-grained policies to be pushed to the edge, where DNS servers are located, so that only authorized users and devices can access certain resources and applications, centralized management is critical.

If DNS management is distributed, dispersed, and there is no common view, it becomes very difficult to coordinate security.

Centralized management is therefore a key element.

Enhancing Access Control With Micro-Segmentation

23:14 – 25:55

Let’s now look at enhancing access control with micro-segmentation.

What do we mean by that?

As mentioned earlier, if someone is on a network and makes a query from a machine for a valid DNS name in a valid DNS zone, they will typically get a valid response.

If they ask for the IP address of a name, they will get the IP address.

The question we ask customers is: should someone be able to access any name in any valid zone?

They may not have the right to access a particular system, but by making a DNS query, they may get both the name and the IP address. That is already two pieces of information they did not have before.

Organizations can start controlling access by filtering based on allow lists (whitelists)  and deny lists (blacklists).

This is not only about looking at the destination name that the client is querying, whether internal or external.

Of course, organizations can check DNS queries against known threat actors by consuming threat intelligence on a DNS server.

Every query can be checked against those entries. If a query triggers a rule, organizations can rewrite it, block it, or apply another action.

But when it is a valid name, it does not usually trigger security rules.

If organizations want to control access, they need to identify the user making the query and consider the destination.

By combining allow and deny logic, organizations can apply very granular security controls at the DNS level.

They can stop users from accessing certain names, or restrict them to only one or two names.

There are several use cases for this.

Use Case: IoT Devices and Client Query Filtering

25:55 – 31:58

Thank you, Peter.

I will now show an example of what Peter just explained, using the case of IoT devices and how we can manage access for those devices.

At the center, you see our Client Query Filtering feature, which is the implementation of the technology Peter just described.

The first step is to have multiple lists: client lists and domain lists. These lists define which clients are allowed to access which domains.

Let’s use a simple laptop example first.

In this example, the laptop is authorized to access all allowed applications. This is just for the sake of explaining what happens with an IoT device.

Once an IoT device is connected to the network, it is identified automatically.

Once identified, the client list is updated with an entry indicating that this client is an IoT device.

An IoT device is only allowed to access specific IoT management applications, which are listed in the domain list.

When the IoT device tries to access a domain or application defined as an IoT application, it succeeds and is authorized.

But when it tries to access anything else, for example a search engine that the device does not need, access is denied.

We will now see exactly this in a product demo.

On the screen, you see the DNS Guardian dashboard.

The first thing we see is the list of domains and the list of clients.

For the sake of the demo, we have only two lists: one domain list and one client list.

To show how a domain list works, let’s look at list one. It has the domain URL and relevant tags.

Each domain can have different tags. These tags can be added automatically based on a feed or manually, depending on preference. The two approaches can also be combined.

The client list has, for each client, the tag of the client, the zone, and other criteria that can be defined.

Now let’s take a quick look at the tags.

In this example, we have attack-type tags such as DGA, malicious, and malware.

We also have tags that categorize by type of device or type of domain, such as IoT.

This can be very granular. Organizations can tag automatically using a feed, such as EfficientIP DNS Threat Pulse, or their own feed. They can also define their own tagging policy.

Now let’s look at the rule set.

In this example, we will look at a rule set that contains two rules to simplify the demo.

As per the Zero Trust principle, the first rule is always block all. By default, nobody should access anything unless access is specifically allowed.

We then activate this rule.

The screen shows a script created to illustrate real traffic.

Once the block-all rule is activated, all different queries are blocked, as expected.

The next step is to activate the rule that allows IoT devices to access IoT domains.

This rule combines two definitions.

The first definition is the IoT tag. Clients that are tagged in the client list as IoT can access domains tagged in the domain list as IoT.

This is a simplified demo, but very granular rules can be defined per unit.

The second match in the same rule is that every client in the organization can access search engines as a baseline.

This is where we move from blocking everything to defining what each client, based on its type, is allowed to do.

After activating this rule and running the traffic again, we see that the IoT devices are accessing domains tagged as IoT domains, and their traffic is allowed.

The same applies to search engines. In this case, Google is allowed, so all clients, including IoT devices, can access those domains because that is what was defined in the rule base.

Proactive DNS Threat Detection and Adaptive Response

31:58 – 37:43

The second area where DNS can help with Zero Trust Security is proactive DNS threat detection and adaptive response.

This is an important combination because it enables organizations to detect threats and react very quickly and very early.

The foundation for detection is DNS Transaction Inspection, also called DTI.

DTI provides granular visibility and analysis of internal enterprise DNS traffic.

As mentioned earlier, DNS contains very important traffic. Part of that traffic is internal traffic.

Inspecting DNS transactions gives many insights into what is normal and what may be anomalous or suspicious.

On top of DNS Transaction Inspection, we have User Behavior Analysis.

This analyzes client behavior and detects threats based on that behavior.

It can look at one client or a combination of several clients and analyze how they communicate through the DNS protocol.

If something is abnormal, the system can detect it as a potential attack.

This is a very good place to detect attacks because it is located at an early point in the network.

On top of that, there are advanced detection technologies.

Cyber threats are evolving. They are becoming more sophisticated. Attackers have many different ways to execute attacks, including using AI to develop attacks.

It is therefore important to stay ahead of attackers and develop advanced detection technologies.

To complement what exists on the DNS Guardian side, EfficientIP’s Threat Cloud platform provides detection of advanced threats.

There are three examples.

The first is phishing detection, where NLP, or natural language processing, and image recognition are used to detect phishing attempts and block them early.

The second is domain behavioral analysis, which is very important for Zero Trust because it can detect data exfiltration.

The system looks at traffic going from the organization to the internet and identifies unusual patterns in domains.

For example, if a domain suddenly creates many subdomains and many clients communicate with that domain, this may indicate suspicious activity. It may be used to steal data.

The third example is DGA detection.

DGAs, or Domain Generation Algorithms, are often used by attackers for command-and-control communication and data exfiltration.

Detecting DGAs is therefore another important aspect of detecting data breaches.

EfficientIP has developed an innovative tuple clustering model, which detects advanced DGAs, sometimes months before they become active.

This allows the organization to block them at a very early stage.

Detection is important, but organizations also need to react once they detect a threat.

For that, EfficientIP provides adaptive countermeasures, which are essentially automation for incident response.

Organizations can define their own actions based on what is happening and based on their internal policies.

They can block traffic, redirect traffic, or quarantine a client.

Quarantine is a patented technology that allows organizations to automatically quarantine a client once it is identified as probably infected based on behavior. The client can then be checked later to decide what to do.

Another important aspect of incident response is DNS intelligence and analytics.

This is extremely important during an incident like the one we saw at the beginning of the webinar.

One positive point about the Verkada incident is that the company responded very quickly to the leaked footage. They notified their clients immediately and managed to contain the incident.

Having DNS data, intelligence, and analytics can help organizations do that when an incident occurs.

Simplifying Zero Trust With Observability and Automation

37:43 – 44:18

The last aspect that can help simplify Zero Trust in DNS is observability and automation.

Peter, I will hand the microphone back to you.

Thank you, Yaelle.

If we look at Zero Trust and where organizations are trying to implement it, visibility is necessary.

Organizations need visibility into what is happening across the network, especially with DNS, so they can detect where threats are occurring, enforce policies, and make sure people are continuously verified in the network.

There are several key ways DDI can help with this.

The first is baselining normal behavior.

Again, most organizations do not really look at what is happening in DNS day by day.

Having a method to see what is happening in DNS and to react to anything abnormal helps with observability.

We talked about restricting or monitoring users and devices querying names that they probably should not query.

This helps identify possible lateral movement, data exfiltration, and other suspicious activity.

It also helps organizations see what is happening with DNS servers themselves.

By monitoring DNS and network metrics, teams can detect indicators that they may be under attack.

Some attacks specifically target DNS servers to starve them of resources.

One example is SlowDrip attacks, which are particularly insidious.

Attackers send a series of queries designed to take a very long time to get an answer from the internet.

These queries do not produce errors. They are valid requests, and they result in valid answers.

But they consume resources while waiting.

If enough of these queries are sent, the DNS server may stop accepting other queries.

This does not necessarily look like an error. Recursivity goes up and various other indicators appear, but it can be difficult to see that it is an attack. It may simply look like the DNS server is struggling for CPU.

If someone is performing lateral movement, they will make reconnaissance queries.

Organizations need to understand when this is happening.

They need visibility across the whole environment to detect issues in any particular network or site.

Having end-to-end visibility across all DDI infrastructure, then correlating all these metrics in one place, allows teams to react.

This is what EfficientIP does with DDI Observability.

From there, organizations can move toward automation.

Typically, automation provides building blocks that allow multiple systems to interoperate.

For example, if a threat occurs and the organization knows the IP address it is targeting, it would be useful to tell a firewall to block traffic to that IP address.

To do this, organizations need a good discovery tool to build a network source of truth.

If you automate actions, you need to automate based on good data.

It is not useful to pull an IP address from an Excel spreadsheet if you are not sure that it is really in the network.

Having a network source of truth enables automation.

Open APIs and plugins also allow communication with third-party applications and platforms.

For example, if an organization uses ServiceNow and wants to automate the creation or registration of IP addresses, and then automatically create a DNS name for the service associated with that IP, this can be done automatically.

When the service is removed, the information can also be cleaned up automatically.

If DHCP pools or fixed addresses are needed, these can be created as part of the service lifecycle.

Specifically around Zero Trust, integrating with a NAC service means that a particular user or IP address can be blocked.

Integrating with SIEM and SOAR tools means that when a security event is triggered within the DDI infrastructure, relevant information can be sent to the SIEM or SOAR.

Security teams can then act on it.

In many cases, customers may not block or rewrite DNS requests that triggered a DNS security event.

But even sending the security teams a notification through the SIEM or SOAR that something anomalous occurred can be enough to make them aware.

Again, they cannot secure what they cannot see. If they do not know about something, they cannot act on it.

The Network Automation Hub enables IT teams to see what is happening, connect systems together, get better value from the infrastructure they already have, and automate many security profiles so that they are enforced everywhere and at all times.

Key Takeaways

44:18 – 45:52

Thank you, Peter.

We are getting close to the end of the session.

Today, we covered how Zero Trust Security can be strengthened through AI-based threat detection, adaptive countermeasures, DDI observability, and network automation.

Let’s go over the key takeaways.

DNS helps across the three steps of an attack.

First, DNS helps organizations proactively protect before they are attacked, which is very important for Zero Trust Security.

Second, DNS helps detect attacks early once they enter the organization and block them at the earliest possible stage.

Third, DNS helps organizations respond effectively, as we saw in the previous sections.

The key takeaways can be tied to the four use cases in which DNS security can help with a Zero Trust strategy.

The main idea is that DNS helps maintain the security level required for Zero Trust across different aspects of the network.

About EfficientIP

45:52 – 47:02

Before we finish, we want to briefly remind you who EfficientIP is, in case you do not know us.

Peter, I will hand it back to you.

Thanks, Yaelle.

We have been talking about Zero Trust and DDI, so it is fairly self-explanatory that we are a DDI company.

EfficientIP acts as a global leader in this field.

We operate around the world in over 100 countries. Our North American headquarters is in Philadelphia, our EMEA headquarters is in Paris, and our APAC headquarters is in Singapore.

We have over 1,000 customers worldwide, and analysts recognize us as one of the leaders in the field.

The purpose of EfficientIP is to make networking simple and secure everywhere, and to deliver the best user experience at all times.

That is why the company was created, and that is what we do every day.

Q&A

47:02 – 55:31

Question 1: How well does this technology interoperate with Active Directory, which is deeply integrated with DNS?

A lot of what we have talked about today is not something that Active Directory DNS really does.

Active Directory DNS comes with Active Directory and is essentially free from Microsoft, but organizations still have to pay to maintain and run it.

What we often see with customers is migration away from Active Directory DNS toward EfficientIP DNS servers.

For the Zero Trust part discussed today, we are mainly talking about the recursive function: caching, forwarding, and recursion.

Authoritative data can still be left on Active Directory.

From EfficientIP’s perspective, that authoritative data can be managed either in read-only mode or as a control point if needed.

Organizations can also move the authoritative data to EfficientIP, and EfficientIP supports what is needed for Active Directory.

But typically, if an organization wants to implement Zero Trust and micro-segmentation, the recursive function needs to run on EfficientIP.

Question 2: How often are these lists updated, and who checks them?

There are two types of lists.

For micro-segmentation, allow lists and deny lists are very specific to each customer environment.

Typically, the people managing DNS day to day — whether NetOps, NetSecOps, or another operations team — manage these allow and deny lists because they know the names and users that need to be controlled.

When consuming threat data, organizations can consume third-party threat data on the EfficientIP platform.

In that case, the third party maintains the feed.

For the feeds produced by EfficientIP, there is a team in Paris that curates them.

They are constantly curated to make sure there are low false positives.

They can be updated minute by minute, depending on the level of support and how often the customer wants them updated.

Question 3: What about BYOD environments and users not using corporate DNS servers?

The largest issue in BYOD environments is users not using corporate DNS servers.

Some organizations are moving toward a more managed device environment for employees, but still run into DNS over HTTPS or DNS over TLS challenges.

When deploying into a customer network, EfficientIP Professional Services typically handles most of the migration and the build-out of the solution.

If the question is specifically about configuring users to use DNS over HTTPS or DNS over TLS to access DNS servers all the time, there are several possibilities.

EfficientIP DNS servers can natively handle DoH, or DNS over HTTPS.

In some cases, organizations may prefer to put a proxy in front of the DNS server to handle encryption and decryption, and offload that work from the DNS server.

That is also possible.

EfficientIP has guidelines on how to do this, but the implementation is generally specific to each customer and how they want to organize it.

If the organization manages the devices, it can enforce which DNS servers those devices use.

So it is possible, but it is generally a customer-specific implementation.

Question 4: Can DNS blacklists be added?

Yes.

Most implementations using threat data or micro-segmentation include both a whitelist and a blacklist.

Usually, the whitelist is ordered first. If something is on the whitelist, it always gets answered.

Then, organizations can have their own private blacklist.

After that, they can apply any threat data or segmentation rules they want.

The feeds and lists can be reordered in the way the organization prefers.

Question 5: How does this interact with DNSSEC?

From a recursive viewpoint, organizations can use DNSSEC validation on the recursive side.

For any external name, EfficientIP can validate that the response received is valid using DNSSEC.

For authoritative DNS, DNSSEC is not really affected by the filtering described here.

That is because segmentation and blocking happen before the recursive query goes to the authoritative server.

The authoritative server is the one that answers with DNSSEC records.

From a recursive perspective, if the organization wants to validate any recursive query against DNSSEC, that happens after the name has already been evaluated to decide whether the system should recurse it or not.

Question 6: Are blacklists included, or do they need to be licensed separately?

The DNS firewall functionality in EfficientIP is built into the product.

The blacklist and whitelist functionality is included in the base product.

So no, they do not need to be licensed separately.

Question 7: Would this solution help triangulate the source IP address and user during an incident or breach investigation?

To do that, organizations typically need to log every single query, and this can become problematic because of the large volume of DNS traffic.

What EfficientIP tends to do is log where the threat is triggered.

For example, if the event is triggered against a particular threat feed, or by an allow or deny list, or by micro-segmentation, then EfficientIP logs the source IP address and the name.

That information is sent to the SIEM, so teams can see who had that IP address at that time.

Closing

54:51 – 55:31

I hope that answers all the questions.

If there are any more questions, you can send them to us and we will answer offline.

Thank you very much.

We can now close the session and stop the recording.

Everyone will get the ability to download the deck and view the recording if they want to.

Thank you for your time.