Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
johnwunder opened this issue Apr 2, 2014 · 3 comments

Comments

@johnwunder
Copy link
Member

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?

@sbarnum sbarnum added this to the Version 2.0 milestone Apr 22, 2014
@jonathanbaker jonathanbaker modified the milestone: Version 2.0 Nov 3, 2014
@gtback gtback changed the title Investigate adding a top-level "Victim" construct Add top-level "Victim" construct Nov 3, 2014
@johnwunder
Copy link
Member Author

This might also be related to #235

@sbarnum sbarnum changed the title Add top-level "Victim" construct Abstract "Victim" to top-level construct rather than only embedded within Incident and TTP Oct 26, 2015
@athiasjerome
Copy link

I would suggest to have this abstracted as Asset (Ref. #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
Copy link

[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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants