redhat-infosec/priority-intelligence-requirements-devThis guide describes a process for developing Cyber Threat Intelligence Priority Intelligence Requirements
In the rapidly evolving landscape of cyber threat intelligence (CTI), the formulation of Priority Intelligence Requirements (PIRs) stands as a crucial component of your CTI program and the planning and direction phase of the intelligence cycle. As a cyber threat intelligence analyst, you are likely familiar with the challenge of balancing limited resources within small CTI teams against the colossal task of delivering relevant, actionable information to decision-makers and stakeholders. This dilemma often leaves teams grappling with a choice: should they adopt a reactive stance, responding to emerging threats as they arise, or should they lean towards more proactive long term priorities. Integration of PIRs as a guiding principle will assist your program to pursue proactive strategic priorities more confidently without abandoning your reactive capabilities. This approach doesn't just enhance traditional functions like research, investigation, analysis, and reporting but also elevates advanced practices such as threat-informed defense, including threat hunting and detection engineering. In this blog post, we delve into this pivotal process as we unravel the significance of PIRs in shaping a more effective and strategic CTI function, thereby enabling your team to make a more substantial impact within your organization.
The original Red Hat process was structured around two distinct risk assessment exercises, one focusing on internal factors and the other on external ones. These exercises were then combined into a mapping exercise, from which we derived a cohesive set of PIRs. The goal was ambitious: to address the 'What', 'Who', and 'How' of the threat landscape. 'What' referred to the data and infrastructure of our organization; 'Who' encompassed high-level descriptions of threat actors like state actors, organized crime, or hacktivists; and 'How' partly included types of initial access vectors.
On paper, the threat actor (TA) categorization and initial access vectors (IAV) presented well, offering a seemingly comprehensive story when presenting PIRs to stakeholders. However, as we repeatedly scaled this exercise across organizations, we encountered significant challenges. The process was labor-intensive, adding weeks of work and dozens of hours for the team, yet it didn't yield the expected value in operationalization. We also found that the general categorization of threat actors and initial access vectors lacked the depth needed for operationalization. What was missing was a finer granularity, like Tactics, Techniques, and Procedures (TTPs), and associated MITRE ATT&CK categorization. Recognizing this gap, we shifted our focus to aspects that provided more substantial inputs for the operationalization of PIRs.
This is a five-step process: Step 1, identifying key organizational elements from strategic documents; Step 2, mapping these elements to supporting assets; Step 3, linking elements with types of adversarial operations using a custom classification; Step 4, assessing risks using a likelihood/impact matrix to determine the appeal of elements to attackers; and finally, Step 5 customizing PIRs into actionable intelligence requirements.
The initial step involves identifying the core elements of your organization. These elements are not directly related to information security but are crucial in defining your organization's identity. They are derived from high-level strategic documents, such as annual reports, business strategies, senior leadership communications , and even the 'About' section of your website. These documents contain keywords, topics, or short sentences that encapsulate your organization's strategy, mission, and vision.
Questions that can help you to define ELEMENTS of your organizations:
These elements should describe the essence of your organization, including both obvious and subtle aspects. They define what makes your organization unique, why customers choose your products or services, and what sets you apart from competitors. This also includes valuable data like proprietary information, R&D, partner relationships, and sensitive corporate information.
Examples of the elements for a fictitious electric vehicle producer Stellar Electric[^1]:
Sub-STEP: FUNCTION Linked to these elements is a sub-step called 'Function.' It ties the elements back to information security by clarifying what needs to be protected from an information security standpoint. For example, if an element is 'limited battery production,' its function might be ensuring continuous battery production. This context helps in understanding the element from an information security perspective and guides the subsequent risk assessment exercise.
Output: Sheet listing the ELEMENTS and FUNCTION of the ELEMENTS of your organization
Once you have defined your organizational elements, the next step is to map the supporting technology, data, or information to these elements. This step can be high-level or detailed, depending on your approach. For instance, if your element is operational technology supporting battery production, the key asset might be the Operational Technology and Industrial Control Systems that keep the production running. For proprietary technologies, the critical asset could be the documents containing proprietary information. This step is about linking the abstract elements of your organization to tangible assets. It's a crucial bridge between the theoretical understanding of your organization and the practical aspects of protecting it. When developing PIRs at Red Hat, we kept this high-level, avoiding overly specific details from Configuration Management Databases or similar documentation, which can be overwhelming and too detailed for this exercise.
These two steps form the foundation of a robust CTI process, aligning your organization's essence with its security needs, and setting the stage for mapping of adversarial threat operations and risk assessment in the next steps.
