Consuming Threat Intelligence: Feeds or APIs

The right intelligence, at the right time, enables rapid, preventative action to be taken to protect customers. Cyber threat intelligence feeds provide a simple way to keep existing threat intelligence databases up to date with actionable, relevant and valuable information. In the previous blog in this series we outlined what threat intelligence is and briefly introduced how to assess the relevance of a threat feed to an application. In future blogs, we will look in detail at the analytical techniques that turn data into intelligence, and how intelligence needs to be relevant and refined in order to be of value. Here we look at where threat intelligence feeds fit within a malware detection system. We will compare their application with alternative technologies: API access to cloud security services and the use of local scanning engines.

Threat intelligence feeds

The main benefit of a threat feed is that it delivers required intelligence – knowledge  that wasn’t previously held – regularly, into an existing threat intelligence database. And it does this privately, without having to share any information. Carefully selected, the right feed can provide zero-day visibility into unknown threats. It can also fill gaps in knowledge about existing malware. This enables more effective analysis. Gaps in knowledge may exist because of a lack of geographic coverage, data missing from other feeds, or because existing analytical techniques fail to extract the specific intelligence required. But improving the efficacy of existing systems or developing new services is often the goal.

Whatever drives the need for threat intelligence, the use of a feed does require an existing threat intelligence database. It also requires an understanding of how to integrate threat intelligence into existing malware detection systems.

Anti-malware scan engines

A threat feed’s primary function is therefore to share threat intelligence between threat intelligence databases. This is in contrast to anti-malware scan engines that deliver the capability to scan files locally and assess them for malware, in real time.

Scan engines can be built in-house or leverage Software Development Kits (SDKs) such as Avira’s Anti-malware SDK. This latter approach enables proven, existing engine designs to be used, and allows a scan engine to be implemented quickly, without the costs and time taken with in-house development: It avoids reinventing the wheel.

In practice, threat feeds and scan engines often derive their threat information from the same database. However the intelligence is presented very differently. Threat feeds deliver their information in an easy-to-access file every minute, while scan engines receive their intelligence as a regular database update consisting of powerful generic rules and engine based detections.

Application Programming Interfaces

Application Programming Interfaces (APIs) to a cloud security service sit somewhere between the two approaches described above. They assume that there is some existing malware detection technology, but not necessarily a threat intelligence database. An API leverages the threat intelligence hosted within a cloud security service by making an enquiry. This may take the form of a simple request to check the hash of a file. It may allow a file to be uploaded for analysis. Or it may query whether a URL is currently considered clean or likely to be hosting malware or PUA (potentially unwanted applications). The benefit of an API approach, similar to a local scan engine, is that it allows files to be uploaded to a cloud security service for malware analysis.

The Avira Protection Cloud delivers an API query service. It allows you to query if a website hosts malicious content in the moments between clicking a link and arrival on that site. Within the service, hundreds of millions of URLs are already classified as containing malware, phishing, malicious search engines, or Potentially Unwanted Applications (PUAs). In contrast, a URL reputation threat intelligence feed will provide the same threat data on domains and URLs, but not on an on-demand basis. It will provide the most recent changes to the database on a regular, defined basis.

The choice of whether to use an API or a threat feed may turn on a number of factors. Volume of data consumed and privacy may be among these. The cost of an API service is typically variable and based on the number of enquiries made, while the threat feed has a fixed, defined, monthly cost. The right to upload data to a cloud service may be another factor. If data cannot be uploaded for analysis, a threat feed in which data is simply consumed, may be a better choice.

How analytical techniques turn data into information and, ultimately, into valuable intelligence is something we will explore in our next blog in this series. In the meantime, take a look at our threat intelligence for insight into Avira’s threat intelligence feeds.