Requirements: 3 Reasons Why They Make Threat Intelligence Work

Last week, I talked about what cyber threat intelligence was: an information assist to an organization’s tactical and strategic stakeholders. If you missed it, you can find the article here. I also mentioned in the take-away that you should, as a threat analyst, “strive to understand your organizational requirements. These are the questions that must be answered by the data you source, collect, parse, evaluate, and disseminate.” This week, I’m going to expand on the idea of requirements by offering just 3 reasons why they are critical to threat intelligence. Keep in mind these are not the only reasons why threat intelligence is important, but they’re important nonetheless.

The word requirements in a software sense (and very much in a any-Silicon-Valley-product sense) invokes an image of a product meeting strict stakeholder needs. In a very real way, the same goes for threat intelligence requirements.

In the case of threat intelligence, stakeholders can vary greatly. They may be the Tier 1 SOC analyst struggling to understand why an email sent from the CEO requesting her CFO release $1M in funds to an off-shore account was flagged as malicious (“Whaling”); or they may be the company’s Chief Legal Counsel, who just learned that the personal information of over 1M of their customers was leaked by hackers. It really doesn’t matter at which level of the organization stakeholders serve, because all stakeholders have one thing in common: They have information needs!

The primary job of threat intelligence is to meet those information needs in a structured, objective way; using analytical tradecraft to identify data that fills gaps in knowledge and uncovers hidden relationships that would otherwise go unnoticed. Requirements are very specific needs, expressed by stakeholders, that align with tactical and strategic goals of the organization. Here are 3 reasons why requirements are absolutely necessary.

Without Requirements, Threat Intel Wastes Time.

It’s very easy to find indicators of compromise (IOCs), information on threat actors, and malicious exploits in-the-wild. Collecting everything that can be found would be severely time-consuming to threat analysts who must find, parse, process, analyze, and report on every new indicator; to the threat defense operations team that must tune the security stack to detect the new signals; and the SOC analyst that must respond to alerts that may have little real impact on the organization. Unfocused threat intelligence doesn’t serve anyone.

Without Requirements, Decisions are Driven by Fear.

If an organization doesn’t understand what information it needs, it’s easy for external providers to grab its attention by preying on the (potentially unfounded) fear of getting infected by the latest threat-of-the-day. Watch closely next time this happens: Just a few hours after the newest ransomware or exploit kit is detected, vendors of all flavors will release statements touting how they can prevent infection. While these claims may be legitimate, it doesn’t mean you have to listen! News-driven prioritization is generally bad practice, and you should strive to be better. If an organization’s highest priority is protecting against denial-of-service for example, and the latest threat-of-the-day is POS malware exploiting a vulnerability to which the organization is protected, is it worth chasing? Hardly! Without establishing prioritized requirements, news-driven prioritization seems legitimate, even though it’s not.

Requirements Prove Value.

Good threat intelligence requirements link information collection directly with strategic organizational goals. These strategic goals, in turn, inform key business decisions. Every business decision inherently comes with risk, to which a dollar value can be and should be assigned. Key to this construct is the idea that over a specified period of time, loss WILL occur; but the benefit outweighs the loss if the time period between losses is sufficiently long. Case in point: If it costs $100K annually to deploy an endpoint monitoring system, but monthly losses amount to less than $5K a month in service support time and productivity loss due to malware detections upstream, the risk may very well be accepted, all considered. If requirements are tied directly to these accepted risks and threat intelligence can push the time period of expected loss out, this has a direct impact on projected monthly losses. In that way, threat intel proves it’s not a cost center.

Take away: Understand your organization’s critical assets, business drivers, and risk profile. These should be the foundation for requirements. If they’re not, ask your stakeholders for clarification because ultimately, threat intelligence serves stakeholders. By ensuring requirements are aligned properly, you save time, effort, and ultimately, money.