How to Define and Build an Effective Cyber Threat Intelligence Capability (2015)

Chapter 2. A Problem Well-Defined is Half-Solved

Abstracts

This chapter covers the importance of molding a threat-intelligence program around (company-specific) business objectives, that is, it must pursue a well-defined mission that is bounded, scoped, and relatively rigid; work within a set of clear expectations in a portfolio of responsibilities that everyone agrees to; and meaningfully report metrics that matter to management and budget holders.

Keywords

application vulnerabilities

malware signatures

URL blacklists

botted nodes

vulnerability threat intelligence

security posture

risk assessment

spear phishing

Threat intelligence is absolutely the buzzword “du jour.” It is being used to seek venture capital and fund start-ups. It is being aggressively pitched to the enterprise market by the provider industry as the solution to all their woes. Well, to put a fairly aggressive stake in the ground, we would argue that the majority of what is being sold and billed as “threat intelligence” is not. It is data. From lists of bad IPs, or application vulnerabilities, or malware signatures, or URL blacklists, to botted nodes, or botnet C2 servers, or social media data; from open source or web-based content to RSS feeds and IRC channels, in their initial form, none of these things is “intelligence,” they are data.

2.1. Data feeds vs. intelligence

Our contributing editor, Cyveillance, will tell you they love data. Data is great! They produce data, buy data, sell data, and there is no question data plays a pivotal role here. However, we are going to cover the subject of data as it relates specifically to building a threat intelligence capability, and there is an absolute distinction between data and intelligence. So, in the spirit of “a problem well-defined is half-solved,” we can save a lot of confusion if we start by explicitly defining the differences between data and intelligence to truly understand the issue.

Data, (the stuff so often marketed as “intelligence”) is typically some form of machine-readable feed, file, or service in a format like XML, JSON, or CSV, or an API, web service, or some other access point for information that go from one machine to another machine to be read by a machine. There are lots of feeds and services like this out there, and many of them are actually extremely useful, but to be explicit, anyone selling you a feed of this would be selling you a data feed, not an intelligence feed. Well, if we have now said what intelligence is not, let us explicitly state what we believe it is.

2.2. Defining threat intelligence

From a professional’s perspective, intelligence is data that has been put through a logical and analytical process, most often a human-based process that evaluates the data in context and produces a usable output. In rare cases, there are options for that process to be entirely machine driven if the outcome allows an action, change in security or defensive posture, or decision that was not possible before the process. In any event, whether the data is transformed or distilled or otherwise turned into usable intelligence by software or neurons, the output must meet at least the following three requirements to meet the definition of intelligence. The information must be:

1. Relevant: It must be relevant to your enterprise/ industry/ business objectives, or some other aspect of organizational life. Take for instance a company that runs Linux for all its servers, and all its desktop are Apple Macs. Now a vendor comes to them saying, “Hi, I am a sales person for XYZ Co. I have vulnerability threat intelligence.” About 98% of the data this vendor may be delivering focuses on vulnerabilities in Microsoft Windows or Windows applications. It may actually be great data, but it is in no way relevant to an enterprise that does not run a single Windows machine.

Although this example seems quite simplistic, it is just a way to illustrate the following point: data must be relevant to the organization or it can be the world’s greatest and/or most interesting data for the sake of intellectual exercise. However, if it does not impact the organization and is not relevant to it, it cannot be threat intelligence applied to that organization.

2. Actionable: The data must be actionable, a term you are probably familiar with since everyone, including vendors, likes to use it. It is in fact a little bit of a misnomer; but the misnomer takes too long to fit on a marketing slick. To ensure full clarity, the concept of actionable means that it must be specific enough to do one of two things:

• It must either prompt, enable, or inform some response, action, decision, or change in security posture, configuration, level of sensitivity or other organizational network or human change to the environment; OR

• It must provide sufficient information to support making an informed decision not to act. That is, not acting is in fact an action, so long as it is an informed choice not to act that is made out of considered evaluation, rather than just inaction out of ignorance.

To illustrate this point, here is an example. Imagine establishing context, specifics, and a risk assessment around an event. For example, suppose an attempted penetration of a network or attempted spear phishing of an employee occurs. Now you may discern on the basis of your investigation or review that the hacker is unsophisticated, that the attack does not actually pose a threat or reflect any kind of serious activity targeting the organization, and the attempt was crude and easily neutralized. Although a more sophisticated attempt might prompt increased authentication requirements, data egress rule changes, employee training or some other response, in this case your evaluation might support an informed decision to take none of those steps due to the low level of risk posed by the unsophisticated attack. In this case, no action still falls under the definition of actionable intelligence because the “not taking action” was an informed decision.

3. Valuable: The information must be valuable, and at the organization (not department) level, value must translate to the business. Security professionals, although often experts in their fields, often lack the vocabulary, business background, or skills to understand and make this argument. Even if the data or information is relevant, actionable, and capable of allowing the security team to do something that they believe is in the organization’s interest from a security perspective, the organization will be robbed of value if its security experts cannot translate or align their operational activities of a threat center, a threat intelligence function or similar team with the business objectives of the company. Regardless of whatever your cyber center, fusion center, and so forth may be called within your company, the threat intelligence function may not get off the ground or may be short lived if the experts cannot align and report their activities with the aim to achieve some useful business outcome that ensures both start-up and on-going funding and support. Therefore, it is vital that you know how to translate the value back to the business.