Network security is a hard enough task when you own and operate all the infrastructure. Moving to the cloud introduces even more complications.
Suddenly you’re securing information in someone else’s data centers, triangulating against someone else’s infrastructure, and dealing with someone else’s software running through your network. Developers are building and tearing down infrastructure, usually without telling anyone about it. With all this new complexity to deal with, it’s no wonder that cloud security can be a headache.
Then there’s that whole class of cloud-specific malware, which takes advantage of the unique architecture of the cloud to introduce new security vulnerabilities. All of the tools used for your on-prem network suddenly have to adapt to a new attack surface, or you have to find some new tool to deal with this new environment.
Finding visibility and control
The shared responsibility model used by most public cloud providers offers cold comfort for network security teams. On one hand, the sheer scale of resources cloud providers devote to physical and data security is beyond what most companies or even governments could deliver on their own. On the other hand, cloud customers are on the hook to secure everything outside of the cloud provider’s infrastructure – not an easy task by any means.
In an ideal world, you’d be able to simply extend the security architecture created for your on-prem environments into the cloud. Everything would be consistent, and the security controls you’ve developed would simply scale into a new environment. In reality, most security teams don’t even have visibility into what’s happening in the cloud – actual control over events seems like a pipe dream.
Sitting underneath (or rather, moving through) all of this complexity is the Domain Name System (DNS). Long neglected as mere network infrastructure, DNS is the common denominator which can bridge the security gaps inherent in hybrid cloud environments. That’s because every query on your network – whether on prem or in the cloud, legitimate or malicious – will have to use DNS at some point.
If you have visibility into what’s happening in DNS, you can create consistent security controls across the enterprise. More specifically, if you have visibility into internal DNS records – DNS at the level of devices, VMs, and containers – you can apply security policies regardless of where your assets sit.
Unfortunately, in most organizations cloud DNS is handled by independent cloud and DevOps teams. They are standing up BIND or Microsoft DNS servers, provisioning IP addresses, and pulling down compute on their own, without any knowledge of the security or network teams. Balkanized DNS in the cloud prevents the kind of visibility which DNS security can deliver.
Four steps to cloud security with DNS
The first step in creating a consistent security posture across the enterprise is to implement a consistent approach to DNS infrastructure. Deploying a platform which can manage DNS right at the client level will provide the baseline visibility which security and network teams need to implement needed security controls – in the cloud and on-prem. (Using a single DNS service needn’t slow down cloud and DevOps teams. In fact, automated IP address provisioning will speed up their work.)
Step two is to develop and apply security policies to DNS queries in the cloud to reduce attack surface. This can be used as a form of role-based access control (RBAC) – preventing unauthorized access and ensuring that data sets and areas of compute are only available to users with the need to know. It can also prevent lateral movement between clouds or underneath the external filters and firewalls – a key tactic of many advanced persistent threats and malicious insider activities. The policies applied to DNS can vary according to the threat – you can monitor, redirect, or block queries based on how the threat should be treated.
Third, security teams should analyze DNS data on a regular basis, looking for patterns and anomalies which could be indicators of compromise. DNS tunneling, for example, could be hiding data exfiltration which would go undetected through a standard filter or firewall.
Finally, security teams can triangulate threat data against a source IP to quickly identify the origin of cloud-based threats. It takes 100 days on average for security teams to identify and remediate cyber threats – a timeframe which is usually longer when the complexities of the cloud get in the way. If you’re watching every DNS query on your network, the process of finding and eliminating these threats is much faster, regardless of which environment you’re working in.
The BlueCat difference
BlueCat’s DNS security solutions offer the comprehensive, consistent approach which hybrid environments demand. By standardizing DNS with BlueCat across cloud and on-prem instances, network and security teams get the visibility they need and the control they want. All of that security complexity brought on by the cloud suddenly becomes manageable and decipherable.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
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.
React faster at the wire with BlueCat and ExtraHop
With the BlueCat ExtraHop Plugin, automatically create missing PTR records, and detect and react to security threats before they reach DNS servers.
Yes, IT should see what developers do in the cloud
Errors and outages occur when admins lack visibility into DNS and IP allocation in the cloud. With Bluecat, central DDI visibility is within reach.
Why McMaster University didn’t want another CIO
McMaster’s CTO, Gayleen Gray, highlights the importance of her unique role in a world where expectations of the CIO and CTO are colliding.