-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
This might also be related to #235 |
I would suggest to have this abstracted as Asset (Ref. #234 ) In short, Asset could be: Organisation, Person (Ref CIQ), or IT-Asset 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 ) |
[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
|
Victim information is represented in two places:
These are very similar constructs, does it make sense to create a top-level "Victim" construct and use references from Incident and TTP?
The text was updated successfully, but these errors were encountered: