Abstract "Victim" to top-level construct rather than only embedded within Incident and TTP

[johnwunder]

Victim information is represented in two places:

• In an incident, you can describe the actual victims that were impacted by the incident.
• In a TTP, you can describe abstract victim targeting information, such as across several incidents or within a campaign or threat actor.

These are very similar constructs, does it make sense to create a top-level "Victim" construct and use references from Incident and TTP?

[johnwunder]

This might also be related to #235

[athiasjerome]

I would suggest to have this abstracted as Asset (Ref. https://github.com/STIXProject/schemas/issues/234 )

In short, Asset could be: Organisation, Person (Ref CIQ), or IT-Asset Ref. http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf

A Threat Actor or Victim are basically Assets

(Note that for going behind Asset Identification NISTIR-7693, could be considered inclusion of Physical Assets. e.g. https://nccoe.nist.gov/publication/draft/1800-5b/#t=ITAMvB%2F5Architecture%2F5Architecture.htm ) ((Note also that another abstraction layer, would lead to a decomposition of Components))

[packet-rat]

[Attacker]<==>[Victim] relationships: Aren't these First Order Relationships?

We can tie some dimensions of Victims/Targets/Assets in via Incidents, but these seem to narrow definitions and Stove Pipe the relations into "a series of Incidents" vs. a holistic view of the entire Red Team <==> Blue Team Cyber-Battlespace dynamics and relationships.

There are of course many scenarios where organizations will never share any Victim/Target specifics. However, there are also valid CTI Inter-Exchange Use Cases where it not clear how to map these relationships effectively today.

Would appreciate any thoughts/insights on how to effectively model/manage these (4) Use Cases (including victim notification and coordination in (4) using the existing CTI Model

Use Case Examples

1. One needs to model supply chain compromise TTPs where Intermediaries exist as both Victim and Target : [Attacker] ==> [Intermediary Target One | Attacker] ==> [Intermediary Target Two | Attacker] ==> [Actual End Target].

2. Sharing Tokenized Victim Targeting Intelligence (for those Communities of Trust with Capability Maturity Models to perform Sector Wide Targeting Analysis for attack detection/mitigation and attribution).

   (Jim Smith, Senior VP, Naval Systems Business Development , Big Corporation, Jim.Smith@bigcorp.com) ==> [Tokenization] ==> (Employee138, Executive, Business Development, DIBCORP-44, Employee138@DIBCORP-44)

3. Detailed attributional specifics on Assets of Victims, Intermediaries, and Attackers need to be reported (for example DIB DFARS Mandatory Incident Reporting to DoD via DC3/DCISE, DIB CDC Incident Reporting to DSS, etc.).

4. There are real-world Cyber Battle-Space use cases that require substantive tracking of details on public facing assets across many dozens of organizations. For example, there is a specific APT Group that successfully compromises a common set of NGO, Media, Content Delivery Web Sites in recurring Fall and Spring Campaigns. They prepare the Battle-space by establishing admin control of these public facing websites, testing Exploiting/Delivery Methods (i.e., iFrame Insertion), removing same, and verifying they still control the assets ~ every 30 Days. When they prepare to launch their actual semi-annual campaigns, they pre-position new Zero Days, Exploit delivery mechanisms, and then in a coordinated process simultaneously change 100's of NGO, Media Web Site Home pages to deliver the 0-Day exploit).

   4.1 In all cases the primary assets used in delivering initial/secondary attack phases are legitimate public facing assets. The real world CTI requirement is to track details on all of these public assets, their compromises, their organizations (Actual Content Owners, Web Services providers, ISPs), and their victims (through often complicated engagement with Content Owners, Web Services providers, ISPs, Agencies, and Law Enforcement). Since these attack patterns have continued since 2009, there is a much broader life-cycle management to Public Asset Monitoring, victim notification, and repeated remediation of root causes for what have historically been repeated web site compromises.