Ask any CISO what a perfect world looks like and you’ll no doubt hear, “Full network visibility to secure the enterprise with no possibility of breach.” But we don’t live in a perfect world.
What security professionals really want is real-time data on all network activity: every client, every query, every device, every app and service, every pattern – to prevent breaches from known and unknown threats.
Staggering stats expose the difficult truth about IT security threats in a recent IBM report which pegs the numbers at 206 days to detect a breach and another 50 to contain it. It’s no wonder security professionals seek the promise of ultimate control.
One of the many tools in the arsenal security engineers use to defend the network is a traditional DNS firewall. This approach needs to evolve to thwart the efforts of increasingly sophisticated hackers who know that every successful breach begins with a DNS internet query.
This 5-minute whiteboard session by BlueCat Networks CTO, Andrew Wertkin, on DNS firewalls and innovation in client-facing DNS firewalls, may be the most valuable five minutes you spend to protect your network.
Traditional DNS Firewalls
Traditional DNS firewalls can only do so much to protect the enterprise. Here’s why:
They are only capable of capturing DNS queries that actually recurse out to the internet.
The DNS firewall only sees a query and response from the DNS server, normally in the DMZ, that either forwards to DNS services (google, ISP), or queries public DNS directly. It then compares that query/response against a blacklist of known entities harmful to the organization. Policies that may be in place only block queries already identified as unacceptable.
IT security professionals readily admit the shortfalls of traditional internet-facing firewalls as:
- Not client-specific – cannot identify who made the initial query (person or device) without some arduous work-around or data correlation
- Check only one query at a time, without context to the queries that became before or after
- Not particularly useful for forensics, with limited knowledge of lateral movement, especially when severs before the last hop cache the results from the first client that queried the domain
- Respond to public, internet-bound traffic only
- Do not see every query – including those cached and queries to internal servers
Very importantly, internet facing DNS firewalls do not have all of the necessary context to drive real policy. Policy is mostly focused on the destination domain of the query or the response. It lacks any information on the specific client, the network or location of that client, or the device type of that client.
Consider the security exposure to network infrastructure when a firewall can’t detect where the original query is coming from, who that individual is, or what device or app is being used to make the request.
DNS grapples with another major security hurdle. Over 80 percent of DNS queries are cached – so if any caching occurs before the DNS firewall, it is immediately blind to 80 percent of the queries. If caching is delayed, network performance can suffer.
There is a better way.
Client-Facing DNS Firewalls
What if there was a DNS firewall on the CLIENT side of the DMZ?
What if all queries went to the client-facing DNS firewall first?
What if all queries were logged, regardless of caching, and regardless if queries are for private or public namespaces?
What if you could create rich contextual policies that allow you to apply least privilege access models to DNS?
Client-facing DNS firewalls can apply proactive security policy with full knowledge of the query.
These are just a few of the security data deficiencies resolved with a client-facing DNS firewall:
- Know the source of every IP address of every query
- Know each client-specific query
- Create policies around query patterns – only achievable with visibility into client-specific queries
- Track lateral movement – seeing every client’s query in historical context
- Address both public and private queries – not limited to internet-facing queries
Client-facing DNS firewalling is smart.
It enables full visibility into network queries, leverages cached records and logs activity data. Client-facing DNS data empowers enterprise security with intelligence to preemptively bar unwarranted activity by setting specific policies for least-privileged access by user, device, app or service – flagging any query or use pattern that falls outside pre-set security parameters.
To be useful, the DNS data must be comprehensive and formatted – without compromising network performance. Innovations in DNS data capture allow a client-facing query to be sent while simultaneously evaluating its security profile, without onerous overhead to the network.
The time is now to get proactive about network security. DNS data, readily available, can provide insight and intel to set essential activity boundaries for network protection and peace of mind.
SUNBURST/Solorigate Situation Briefing
BlueCat leaders discuss how the malware attack via SolarWind’s Orion platform exploited DNS and how BlueCat Edge could have helped to detect it.
January 21, 2021: Learn more about how the SUNBURST/Solorigate malware exploited DNS to execute its attack.
Customer situation brief on SUNBURST/Solorigate
Learn more about the attack via the SolarWinds Orion platform and how BlueCat products use DNS to help protect customers against compromises like it.
On the road to platform hardening, consider a STIG
Security Technical Implementation Guides standardize security configuration on networks, servers, and devices. BlueCat uses them and you can, too.