The Death of Private Sector PIRs
Priority intelligence requirements (PIRs) are an intelligence industry sacred cow. It’s time to kill them in their current form, so we can focus on connecting intelligence to risk and business value.
Before building an intelligence capability, as conventional wisdom goes, an organization must first understand its own intelligence requirements. In an enterprise, this often leads to a project initiation in which someone is tasked with gathering requirements from each line of business — a project that may consume resources for years.
Additional issues that impact PIR generation:
Leaders don’t know how to “ask the right questions,” which should be formulated based on acceptable risk impacts.
PIRs developed in a vacuum, without holistically normalizing risks across the business, create a negative effect.
Incorporating intelligence’s inherent time value.
Data collection priorities are only relevant with a well-thought-out intelligence consumption plan.
Naturally, business owners generally have no clue about PIRs, which leads to confused conversations in which business intelligence is conflated with threat intelligence. In the public sector (military, intelligence, law enforcement), intelligence requirements are better understood because these agencies’ respective missions are straightforward. As an industry, we need to invest in helping leaders consume intelligence toward improved questions and better results.
Business leaders are not intelligence experts, yet both business leaders and security teams need intelligence — particularly the convergence of cyber and geopolitical intelligence — to strategically manage risk and identify the security controls that will best produce desired business outcomes.
What to do? Instead of wasting resources gathering and collecting requirements from bewildered executives, there is a better way. As previously shared, there are five risk category impacts that every private sector organization, regardless of industry, would like to minimize:
Brand impairment (reputational risk)
Legal or compliance failure
Financial fraud
Operational disruption
Competitive disadvantage
Every company can identify with one or more of these risks. Working backward, security professionals can map network systems, applications, and data “threat effects” — deny, degrade, disrupt, deceive, destroy — that create “risk impacts.” Working backward from effects leads to technical and human vulnerabilities, exploited by actor tools, tactics, and procedures (TTPs), and sometimes the actors that wield those TTPs (actor attribution is difficult to accomplish with confidence and less useful in the private sector).
Organizations rarely have the resources to prioritize intelligence for every TTP and associated adversary. Assessing threat proximity (easier to communicate than “likelihood of occurrence”) and impact severity against existing security controls will also assist prioritization.
Voila. PIRs accomplished in a day (or a couple of days) and tailored to a specific organization. It may feel too simple, but because we know that the PIR trail will always end in one of these five risk impacts, we don’t need to waste time pursuing and educating colleagues trying to master a PIR list.
The “P” in PIRs is always accomplished by illuminating the adversary TTPs that achieve effects which lead to one or more risk impacts. PIRs are helpful in the public sector, but it may be time to remove this vestige of an acronym from private sector security lexicon. Proactively mapping intelligence to risk (I2R) saves time for higher-order work and productivity.
Let’s work with a simple example: Acme Financial Services. Acme has $50B under management and provides retail services, investment management, and wholesale services. Acme’s leadership realizes the time has come to build an intelligence capability to improve security and inform risk. Where does the company start? With requirements, of course.
To continue international operations and avoid fines with additional oversight, Acme spends significant resources on governance and compliance. Second, Acme’s reputation is a priority in an industry with plenty of competition. Third, Acme needs the ability to trade and service its clients.
Thus, while Acme may be concerned with financial fraud and competitive disadvantage, those are a distant fourth and fifth in the risk impact prioritization because Acme has spent significant resources building controls to prevent or minimize financial fraud. It isn’t concerned about competing in markets where government-sponsored adversaries can steal intellectual property and trade secrets.
This risk identification is remarkable because the ACME CISO (her name is Nina) performed it with background knowledge of Acme’s business without additional meetings with each line of business head. Note that Nina’s background knowledge of the business is crucial to her ability to efficiently identify what risks matter.
Nina is focused on mitigating risk impacts from legal or compliance failure, brand impairment, and operational disruption (in that order). Nina now moves to network threat effects and identifies attack types with high impact or proximity in financial services. As fortune would have it, Recorded Future’s intelligence cloud is available to help Acme identify the adversaries and associated TTPs most likely to create those network “5 Ds” adverse effects.
The following are simple examples of prioritized TTPs and associated actor categories for Acme that either create high impact, have shown industry historical high proximity, or both. The TTP linkages include examples of actors employing these TTPs and related sourcing examples.
The above is a small sample. The graphic could be extended to the right with more granularity and structure (most intelligence professionals work in spreadsheets or similar) for sharing. Even further to the right is where sourcing requirements live to ensure maximum TTP coverage.
In the above exercise, private sector PIRs enumerate organizational context and applicable risk impacts; no interviews required.
Where you can elicit feedback is great, but don’t let an absence of it slow you down.
This is an interesting idea, but I'm wondering what your thoughts are on the feedback part of the intel cycle? Does this imply that we just leave our stakeholders without their input even without PIRs?