Automating Threat Detection and Response With Security Intelligence

Automating threat detection and response has historically been a very expensive and time-consuming process. However, with the prevalence of restful Application Programming Interfaces (APIs), commercial threat intelligence, and crowd-sourced feeds, it has never been easier and more cost effective to do so. Through careful thought and a little bit of Python, organizations can begin to adopt automation into their defenses.

Whether an organization is just starting to build its security capabilities or looking to bolster existing controls, there is much that can be achieved. By combining automation with security intelligence, and applying that to existing infrastructure, an organization can greatly improve their security posture.

Start Automating Security With DNS

Domain Name System (DNS) is essential to both the internet and private networks, but it’s a common service that can be overlooked when seeking to build a threat detection and response capability. DNS is frequently deployed as a centralized service, with visibility of the clients making requests, as well as the domains and Internet Protocols (IPs) being requested and returned — an ideal candidate when seeking ways to detect and respond to potential threats. The Response Policy Zone (RPZ) is a function supported by most modern DNS servers, and provides a custom reply for any domain or IP address — aiding automated detection and response controls. If a client makes a request for something that is in the RPZ, a predetermined response can be returned. Combining security intelligence with an RPZ can supercharge what is commonly referred to as a DNS firewall by providing a broad effective coverage, which enables automated detection and response to the latest threats.

The first point of consideration when deciding to deploy an automated DNS blocking capability, is where the domains and/or IP addresses to be blocked can be sourced, and more importantly, how trustworthy those sources are. Crowd-sourced security intelligence is widely available — but might not contain the latest threats that could impact a business. In addition, poorly curated or maintained feeds such as those containing illegitimate destinations may impact an organization’s productivity.

In comparison, a curated intelligence feed — specifically, one regularly maintained in real time through automation — will more likely contain information about current infrastructure used by advanced attackers, along with additional context that can expedite the decision-making processes.

Developing an Automated Solution

Prior planning is required when handling DNS requests within the RPZ file — such as identifying what is to be detected and the appropriate response. For example, it may be desirable to present users with a helpful web page for any destinations categorized as phishing, while requests for known command-and-control (C2) servers could return an NXDOMAIN response — like a “404 Error” returned by a website that indicates the domain does not exist and allows the browser or application to decide how best to proceed.

During the requirement-gathering phase, there will be a number of additional points worth considering, such as:

• How to go about publishing the RPZ file to the DNS server(s)
• The frequency to retrieve and publish the RPZ
• Whether a whitelist should be utilized

Publishing the RPZ file for use can be as simple as transferring the RPZ to the DNS server(s) using a file share or web server. Alternatively, a more elegant and scalable solution could involve publishing the RPZ locally and conducting a DNS zone transfer.

To reduce the risk of legitimate destinations becoming blocked, whitelisting can be used for any business important destinations — removing those in advance of populating the RPZ. Sources of popular domains such as Alexa or the Majestic Million can be used as an initial base to the whitelist.

Overall, the deployment, maintenance, and operational requirements within a given organization will differ greatly from one to the next. Therefore, it is up to the design and implementation team to determine the best approach and ensure that all goals are achieved.

Finally, once each requirement has been considered, development and testing of the solution can begin. When there is a reasonable level of confidence in the solution, it can be deployed into production if it will provide an effective, automated means of detecting and responding to threats.

Maturing Beyond Initial Automation

Once an automated DNS blocking capability has been successfully deployed, further steps could include DNS request and response logging — providing visibility of historic DNS data against the intelligence that is accumulated.

Applying valuable data effectively provides greater insights into an organization’s overall security posture.This leads to further developments and greater security coverage through adoption of defense in a depth-based approach.

Download our new e-book to discover five more ways you should automate security with intelligence to supercharge your security teams, tools, and processes.