Orienting Intelligence Requirements to the Small Business Space

The discipline of intelligence, particularly in the context of cyber operations, features a number of formal concepts and processes that may appear distracting or irrelevant to the practical needs of small to medium-sized businesses (SMBs). While intelligence requirements, including priority intelligence requirements (PIRs) and similar concepts, play a crucial role in national security, the conventional methods of developing, refining, and documenting these requirements may seem burdensome for the SMB level.

However, a balanced approach is essential and can be achieved by focusing on the organizational benefits of intelligence requirements without getting bogged down in excessive processes.

Intelligence & Decision Making

Intelligence as a concept is primarily concerned with decision making, but not for its own sake. Stakeholders within the organization, whether a gigantic military power or even a small printing shop, must make decisions in the face of uncertainty. Intelligence works to reduce—but not eliminate—this uncertainty to enable better, more relevant actions within the scope of the organization’s goals. As seen in the following chart, we can view intelligence as a practice where the universe of all possible observations is whittled down through collection to relevant data points, which in turn are refined into information and finally completed intelligence through processes of analysis and production.

The end result of this refinement should be relevant guidance and similar assistance to drive organizational decision making. In the broadest sense, this can range from business intelligence items such as pricing and investment strategies to competitive intelligence on what organizational rivals seek to achieve. For our purposes, we are focusing on cyber threat intelligence (CTI).

CTI is typically viewed as a stream of indicators or other technical observables for populating firewall block lists or similar. Yet this ignores the huge array of potential decisions around information technology, the use of such technology, and the policies governing it that intelligence can meaningfully inform and improve. For example, intelligence can help guide investment in products (beyond security-specific items) based on observations of the threat landscape, determine policies such as migration to cloud services, or even inform the type and nature of security awareness training offered by the organization. Both practitioners and consumers of CTI must break free of an overly specific view of this discipline and embrace a wider perspective, understanding the variety of decisions that are supported and improved through its application.

However, the expansive view of CTI poses a problem. Within this much wider field of responsibility, where does CTI focus its efforts, and what priorities exist for its exercise? With unlimited time, resources, and personnel, this may be irrelevant as all possible avenues of interest can be investigated simultaneously—but no organization exists with this mixture of unlimited capacity. Instead, limited resources in terms of personnel, time, and technical sources of information need to be prioritized to align with the organization’s goals, and the decisions most important and relevant to its success.

The Need For Requirements

At this moment, the necessity of intelligence requirements becomes obvious. In a resource-constrained environment, a thorough review and analysis of requirements becomes an invaluable mechanism to guide intelligence analysis and production toward the areas most relevant and beneficial to the supported organization. Intelligence requirements are thus not about intelligence itself, but rather focused on how intelligence and its outputs relate to the supported organization.

Within the scope of large organizations, developing accurate, meaningful requirements can be a long, complex process. Done properly, requirements would investigate the organization’s purpose and objectives, the processes through which those objectives are achieved, and then identify the key decision makers behind these specific processes. These stakeholders can then be interviewed to determine needs, identify knowledge gaps, and focus intelligence efforts throughout the intelligence cycle.

Within CTI specifically, stakeholders emerge from the Chief Information Security Officer (CISO) or equivalent down to the Security Operations Center (SOC) lead, with multiple potential intermediate entities in between. Collection efforts will be driven by the problems and concerns facing these audiences, with follow-on refinement, analysis, and production looking to address the decisions these stakeholders must make. Finally, feedback enters into the equation to determine how appropriate the resulting intelligence products are, from indicator feeds for the SOC to informed policy guidance for the CISO, for the desired outcomes and necessary decisions facing these audiences.

While we can admire the thoroughness of this approach and note its benefits in driving an accurate, evidence-driven methodology to build and guide an intelligence program, we also must admit a critical shortfall. The described methodology of intelligence requirement building is costly. These costs extend from the personnel to perform such in-depth analysis to the time required to do such analysis well. Such costs may be difficult to justify or, for smaller organizations lacking a significant or independent CTI function, impossible to bear. Thus, there is a temptation to forgo the requirements process and allow whatever CTI resources are available to do what they think is “best” based on CTI’s own perception of needs and values.

This independent action may end up producing good results, but if so, such outcomes are almost more due to luck than skill. Particularly within the context of complex organizations, understanding complete organizational functionality and dependencies is a lot to ask of any individual, let alone prioritizing how these functions relate and which require the most support. Within strictly defined information security functions, we may assume CTI can likely scope this narrower field adequately, but even here risks remain.

For example, cursory reviewing of most major media reporting—such as what would land on the desktops of key organization decision makers—would stress state-sponsored disruption and similar items as appearing most relevant and severe for an entity, while a more hard-nosed review of data and impact scenarios might identify ransomware and business email compromise (BEC) as most critical to the organization itself. Bridging this gap, getting buy-in for the analysis produced, and understanding how and why these analytical approaches are relevant or reflected in organizational decision making are vital tasks to ensure the relevance and eventual application of CTI.

Simply, CTI left to its own devices remains aloof. CTI can still function, produce outputs, and maybe even justify its existence in some cases, but it will be unmoored from the primary purposes and goals of the organization itself. CTI thus becomes so much “frictionless spinning in a void” rather than a critical support mechanism for security decision-making.

Translating Requirements Beyond Enterprise Needs

The case for large, well-resourced organizations seems clear. But what about smaller entities who face similar decisions and security risks, but have nowhere near the resources to engage in such a process?

In these circumstances, we—as either CTI practitioners or consumers—benefit from looking at the requirements process as a continuum of possible outcomes, rather than a binary decision. Namely, there is a range of potential requirements available to us, extending from ignoring the requirements process entirely to the thorough interview and integration actions described previously. For the SMB (or hospital, school district,  or local government), a CTI requirements process lies somewhere between these extremes, driven by a combination of that entity’s capacity to drive the process and the risk faced in failing to adequately do so.

SMBs must balance the benefits of requirements development with the costs of doing so to arrive at some satisfactory compromise. One key mechanism driving this point is understanding what the organization (or its service providers) cannot do organically, and seeking external support when necessary.

In the case of business intelligence, core SMB decision makers do not have an analytical department producing in-house market analysis—but key decision makers will leverage trade publications and similar media to remain informed of the environment to ensure some understanding beyond the organic capacity of the organization. Similar solutions should, therefore, be sought after in other fields, including the realm of CTI, given the importance of information systems to the health and continued operation of nearly all organizations in the modern economy.

We thus arrive at outsourcing the CTI process, and even many of the requirements development items, to third parties that can aggregate efforts across multiple organizations to scale vision and effort adequately and effectively. This sounds deceptively simple, but for smaller decision makers (or the service providers acting on their behalf within the IT realm), it is critical to identify those providers that are specifically attuned to the needs of and threats to these organizations. Thus, some critical assessment and filtering is necessary, as intelligence outputs that are perfectly relevant and satisfactory for a government security service or large commercial enterprise will often be nearly useless for the SMB or service provider focused on such entities.

For the SMB recognizing the need to drive IT investment and decision making through an intelligence-informed process, or the service providers that do so on behalf of multiple such entities, critical questions emerge:

• Does a provider understand and acknowledge the risk profile of my organization, or the organizations I support?
• Does a provider engage with entities such as myself to continuously learn about the concerns facing such organizations, and refine that understanding over time?
• Does that provider deliver outputs that are relevant to and actionable for my security decision making?
• Are the costs associated with this provider justifiable and reasonable for the value added or created through a possible partnership or vendor relationship?

Nearly all of these questions have equivalents within an internal requirements generation process, but here, they are simplified into procurement-type language to drive the outsourcing of CTI functions for organizations that simply cannot build such capacity organically. In this manner, the organization (or service provider acting on the organization’s behalf) arrives at a place in the middle of our earlier requirements continuum, gathering some of the benefits of a requirements generation process while avoiding the steep costs of a full CTI requirements endeavor. The result should be incorporating an external resource for CTI and similar intelligence that can benefit decision making for the SMB or service provider, and therefore drive better value creation and more efficient resource allocation.

Conclusion

Intelligence without requirements can exist, but will often find itself lost or irrelevant. However, developing and refining requirements is a time-consuming, expensive process itself.

For resource-limited organizations like SMBs, finding a balance between simply forgoing intelligence support and unachievable intelligence outcomes is necessary. Identifying those parties that align best with the needs of the organization and understand the type of decisions facing such an organization are also critical to ensure success. Ignoring or overlooking the relevance of a potential CTI source to the defended organization or partner entities risks wasting resources, while omitting such support entirely means critical decision makers will remain in the dark concerning items vital to the entity's survival and growth.