Intelligent CIO Middle East Issue 04 | Page 25

COMMENT to crash by sending malformed packets and queries Reconnaissance – Attempts by hackers to get information on the network before launching attacks DNS tunnelling – Tunnelling of another protocol through DNS for data exfiltration Protection from these attacks should be done at the DNS level. The DNS appliance should have: Intelligent detection and mitigation – It should detect and drop the attack queries before they reach the core DNS server. The DNS server should not spend valuable CPU and memory resources to process these requests. This can be achieved by offloading the threat protection to built-in dedicated compute Automatic threat updates – It should stay up-to-date with new and evolving threats automatically. There should be no need for writing scripts or manually applying new protection rules to the DNS server every time a new threat is detected Fine-tuning of protection – DNS traffic patterns and attacks might not be the same for each organisation and customisation of protection is necessary to minimise false positives. It should allow for adjusting of parameters for each rule and customise them for the environment Centralised visibility of attacks – Centralised reporting capability is important to provide visibility into the load on the system, diagnose problems, and identify attacks that are happening across the network Secure Authoritative Name Servers – External authoritative name servers should have recursion disabled. Inbound/outbound zone transfers should be disabled or secured with TSIG to prevent resource exhaustion attacks Preventing malware and APTs from using DNS Data breaches are growing at a staggering pace. Investing in next-generation firewalls www.intelligentcio.com or Intrusion Prevention Systems (IPSs) can stop some Malware from entering the network, but not all. Trends like Bring Your Own Device (BYOD) complicate the situation further and provide new avenues for Malware to enter and go undetected for longer periods of time. Malware and APTs evade traditional defences by using DNS to find and communicate with botnets and command-and-control servers. Botnets and command-and-control servers hide behind constantly changing combinations of domains and IP addresses. Once internal machines connect to these devices, additional malicious software is downloaded or sensitive company data is infiltrated. Sometimes Malware and APT attacks are hidden or disguised by external attacks on networks. During an external attack, IT staff are distracted in protecting the network and might miss alerts or warning logs about Malware and APT activity within the network. In order for DNS to detect and block queries for malicious domains and networks, a Response Policy Zone (RPZ) must be configured and implemented. At a very minimum the RPZ must have the following capabilities: Configurable RPZ policy – RPZ should be configured to apply, either Passthrough, Block, NXDOMAIN or Substitute policies to malicious traffic Up-to-date threat data – The threat data should come either from Generic malware or targeted APT (though ideally, it would come from both) Timely visibility on malicious DNS queries and infected devices – data should include the number of attempts to reach malicious domains, the names of the malicious domains and the date/time. Many IT organisations today are using load-balancers, IPS and firewall devices, generic DDoS protection solutions and cloud-based solutions to try and counter DNSbased attacks. All of these solutions are limited in what they can and cannot protect. Most of them are external solutions that are “bolted on” rather than built from the ground up to secure enterprises’ DNS against attacks. None of them can compare to the effectiveness of a purpose-built, DNSspecific defence solution. INTELLIGENTCIO 25