Akamai Diversity

The Akamai Blog

What makes a good "DNS Blacklist"? - Part 2

In "What makes a good 'DNS Blacklist'? - Part 1", we explored the background and factors that have gone into Akamai's thinking behind New security products like Enterprise Threat Protect (ETP). This article continues with a list of factors and questions to ask any DNS Threat Feed providers, including Akamai.

What should enterprises look for in the DNS Threat Policies?

DNS Threat Policies are more than a DNS Blacklist.  The term "DNS threat policy" refers to a combination of three factors: the reputation of the FQDNs or IP, the reference to the threat vector (C&C, downloader, etc),  and the action (NXDOMAIN, Null Response, Redirect to Remediation Page, Redirect to Tracker, etc). A DNS Threat Policy is more than a "threat feed." It is more than a "DNS blacklist.".

What would an Enterprise look for in the "DNS Threat Feed," "Blacklist," and DNS Threat Policy market? What would an Enterprise expect from a DNS based service that uses these DNS Threat Policies for their services? The following is a list of critical factors that all enterprises should look for in their DNS threat policies. This list  can be a checklist for any enterprise as they evaluate their options. Be mindful to explore options - there is no "one" DNS Resolver based Threat system that is perfect for everyone. Each solution has its own strengths. Sometime you need a combination. This is why the AnswerX architecture is built to either merge DNS Threat Feeds or to create a workflow of feed 1 to feed 2 to feed X.

Note: Akamai views all the organizations who supply feeds as our "security" peers and allies. The best security defense is collaboration.

  • What would happen to your business if all the malware and BOTNETs infections did not increase? In other words, what would happen to your business if security tools were effective? The most critical element of a successful DNS Threat Policy Feed is the decoupling from criminal success. Imagine a company who only succeed when there is a crime wave. When the crime wave goes away through community action, the company's revenue drops. Business success linked to the criminal's success means the company is conflicted. Solving the security problem puts their business in jeopardy. Is this really in your best interested? One of the first things to check is if the company/organization success dependant on the criminal's success. If it is, then it would be one of the factors to weigh in your evaluation.

    Akamai is an interesting counter to this trend. Akamai has security solutions which mitigate the attack, and we have products which remediate tools used to launch the attack. In other words, Akamai actively removes the tools the bad guys used to initiate an attack. For example, ETP customers are encouraged to remediate all devices on their network infected with malware. Some of that malware application used by Threat Actors to attack our customers using the Kona Cloud Security solution. Akamai's bases its security strategy on synergy loops which lessen the security risk to all our customers. Akamai uses the data from our 'security mitigation' solutions to identify the tools/devices used to launch the attack and then use other services (like ETP) for 'security remediation'  to remove the threat actor's toolkit. 

  • What is your Threat Feed's "surface area of detection?" There are rich sources of data on the Internet which can be turned into threat intelligence. But, that one rich source of data is not the entire Internet. Ask the Threat Feed operator who many sources of data, in which locations, and which environments they pull that data. That would give you an indication of the surface area of detection. A small surface is of detection does not mean the data sources is security intelligence abundant. The are many "single source" data sources with a small surface area but containing a gold mine. For example,  a DNS Tap on a Top Level Domain (TLD) operator whose TLDs are used by Threat Actions would have a small surface area, but be a rich source of security data. The key principle is to understand the Threat Feed's surface area, value, and context.  

  • Do you leverage the Internet DNS Threat Feeds Ecosystem from multiple DNS feed partners? If yes, how do you use these outside feeds to enhance your Threat Feed? There are some DNS Threat Feeds which are unique from a particular data source. There are others sources collect data from a specific geography. What we know is that no one Threat Feed can cover everything type of threat. Ask the Threat Feed provider where they collect their threat intelligence sources. Do they pull in open source DNS Threat Feeds (see Open Source and Other Threat Intelligence Feeds)? Are the feeds timely? How often are they updated?

    Akamai approach to our ETP/CSI DNS Threat Policy combines Akamai's rich source of data with a range of Threat Intelligence feeds from across the industry. Some of these are open source threat intelligence feeds. Some of them are part of our partnerships. Akamai also buys some security DNS Threat Feeds. Akamai uses these feeds to provide a rich security data source that minimizes work from false positives. The combined intelligence is used to sanity check everything, to be able to provide Akamai's ETP customers with impactful DNS Threat Policies that mitigate the security risk.

  • Which White Hat and Security Trust Groups do you participate and how does that work enhance your DNS Threat Feeds? Finding out is the Threat Feed Providers are active White Hat participants and the extent of their involvement is a valuable discussion.  Malware, ransomware, phishing, spam, botnets, stressors, and other Threat Actor infrastructure does not just "appear" or disappear. The industry has a multi-layered community of white hat peers who work with each other on common security goals. The range of these communities is diverse, complex, and non-public. Participation is an essential element to the Threat Feed provided to organizations. Ask the Threat Feed provider about these groups? How do they participate in these groups to enrich the DNS Threat Feeds provided? Do they provide threat data into these groups to enhance the community's response? A Threat Feed Provider who responds with "sorry that is TLP:RED information and we cannot share the details" is OK. It indicates that they are OPSEC mindful. They do not want or jeopardize methods or practices of the white hat "trust groups." A Threat Feed Provider who responds with "we are plugged into to everyone and everything" may require some digging. Most organizations who are active participants do not boast nor do they take a risk with details of the communities.  Understanding the Threat Feed Provider's maturity working with their peers is the core objective with these questions.

  • Do you share your security experience, new best practices, and other security lessons learned from your Threat Feed practice? The providers of DNS Threat Feeds and the services they support produces a wealth of information on the real impact they have on the Threat Actors. This insight also uncovers new threats as anomalies are tracked down and investigated. Asking if the Threat Feed provider shares their insight, how they share that insight, and what they hope to achieve by sharing. Yes, the security industry is known for a "battle of the security blogs." But, many of the security organizations don't think of it as a "rush to blog." They view the security blog as a useful tool to communicate to their constituents. Others will wait for the security conferences and present their insights at those forums. Still, others will have periodic security reports. Akamai's State of the Internet / Security Report is one example. The core is to have the conversation, explore the response, and review examples of how the Threat Feed provider offers their insight.

  • Do you use the data from our Threat Feed "Hits" to Improve Your Intelligence? An organization which pulls down a DNS Threat Feed is using that data to protect their organization. They are also building information. Every hit and policy match is a valuable data point. For example, if there is a DNS Policy that redirects all DNS queries that matched a BOTNET Command and Control (C&C), that 'match' is an indication that the Enterprise/Operator has malware that is part of the BOTNET. That BOTNET data point is valuable to tracking the BOTNET. "Policy Hits is data the Enterprise/Operator wants the Threat Feed Provider to use to improve their data. If all their customers contribute back, it results in a more efficient Threat Feed. Asking if they collect this "feedback" and how it improves their feed is a tool to evaluate the Threat Feed Provider.

  • Does your Threat Feed have modernized algorithms to look for "organizational unique" threats vs. threats that are common among all customers?  There are some threats which are common to all customers. For example, a BOTNET's Command and Control (C&C) that is used for IoT DOS attacks would be seen in a broad range of networks. In contrast, there are attacks vectors which are regional (part of the world), local (a specific country), industry oriented (power generation), or unique to a particular organization. These focused attack vectors require algorithms designed to dig out the focused attack intelligence and turn it into action.  The fundamental question, "will your DNS Based Security Service block threats which are uniquely targeted to my industry vertical or specifically to my organization." The conversation around this question will be informative.

  • Is your Threat Feed a closed list? Can someone add to the list? What would happen when we add our white list or enterprise incident blacklist to our DNS Firewall? DNS Threat Feeds which are "closed" limit the Enterprise/Operator's ability to respond to specific security issues. The Threat Feed provider should be open to interacting with their customers. The services using the DNS Threat Feeds should have capabilities that allow incident feeds from the Enterprise and white list of services that should not be blacklisted are both abilities that add security agility.

  • What are your "Secret Sauce" innovations which keep the bad guys guessing? How do you know your Threat Feed will stay several steps ahead of the Threat Actors? We cannot fight the battles of the past to learn about the battles of the future. Threat Actors are constantly learning. Having a Non-Disclosure based conversation about the Threat Feed's secret sauce and other tools that will keep the feed up today to the latest threats is critical to any evaluation process. The objective is confidence in the future of the Threat Feed and assuredness that the services the Threat Feed supports will stay ahead of the Threat Actors. While you might not get details of the "secret sauce," you should walk away with confidence that this service is the right one for your organization.

  • My investigative workload from false positives in my existing Threat Feeds is consuming scarce resources. What does your Threat Feed do to minimize false positive? How do you define a false positive? There is no perfect DNS Threat Feed. There will be times where there is a false alarm. There will be times when there are indicators that infected devices in your network need investigation, but end up perfectly OK.  These false positives are normal. The question to ask is how the DNS Threat Feed works to minimize these false positives. Also, the service the DNS Threat Feeds support should be set up in a way to reduce the false positive workload.

  • How do you search for the unknown DNS exploit vectors? Threat Actors are always working around your DNS Threat Feed's effectiveness. How will I have the confidence that you can keep up? Threat Actors are motivated. They will constantly look for new techniques to achieve their goal. We know that exploiting unique characteristics of the Domain Name System (DNS) is core to their exploit research. Given this, the DNS Threat Feed provider and the services which use DNS Threat Feeds should have some focused research to track the activities of the Threat Actors. In addition, the DNS Threat Feed provider should be plugged into their white hat peers, the DNS researchers, and the DNS standards community to look for unforeseen DNS threats along with technology to mitigate these DNS threats.  

    This "DNS Threat Activity Search" should not be limited to the Internet-wide DNS threats. Advanced Persistent Threat (APT) attacks are often go unnoticed until DNS logs feed into a DNS Threat analysis engine finds strange DNS anomalies. Today's DNS Threat Feeds need to have the culture of constantly looking for the unexpected and quickly respond to protect customers and collaborate with their industry partners to mitigate the threats large and APT specific.

Akamai's ETP and AnswerX Difference

Akamai looks forward to conversations around all of these questions. We recommend all organizations start with DNS Resolver Protection for their staff via the Enterprise Threat Protection (ETP) service. The service is setup to work with most existing DNS deployment. It will provide an introduction as to what can happen with a tool focused on secure DNS resolution path and removing that "entry vector" as a Threat Actor tool.

Carriers, Operators, Cloud Providers, and other organizations who like ETP, but want to build their own DNS platform for their own customers and own market are encouraged to partner with Akamai. AnswerX is the foundation behind ETP. Akamai has and will continue to work with partners to facilitate their success. Locking down the DNS resolution vector so that Threat Actors cannot use it to push malware, phishing, DNS exfiltration, SPAM, BOTNETs, and other services is in everyone's best interest. Akamai strongly encourages others to use our platform's strength and security insight to build DNS based security tools which protect their customers.

What makes a good blacklist Img3.png

Special Thanks to my colleagues Matthew Lebourgeois and Gordon Marx for suggestions, questions, and interaction to craft a better blog.

Leave a comment