[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Non-DoD Source] Re: [cti] How to model the object in this situation
I'm personally partial to using Infrastructure in a more general sense for incident reporting, but that's typically because the reports we see don't describe specific systems by name and instead by general function. In these cases Infrastructure works well since it seems like the fields will be largely identical and it could also function in a similar manner akin to a nested container.
If you do want to get down to an abstraction of the more base level I agree that something like asset would be needed that could be part of the composition of an Infrastructure object. I imagine for example it might be pretty useful if an org could end
up creating a STIX map for their own internal assets identified by CPEs and then tied to Vulnerabilities. If an Incident does occur you could then link it all together, or just use it to match against potential adversary actions from reporting feeds.
I attached a rough stab at how this might integrate with an Incident proposal I shared a while back, and which we have been having a bit of back and forth internally at DC3 on to make sure I'm understanding it correctly. I left the asset itself very bare
bones for this, since I was mostly focused on the links, and don't want to step on the work that's being done now for the property mappings.
Jeff Matesâ
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Paul Patrick <ppatrick@darklight.ai>
Sent: Friday, March 26, 2021 2:22 PM To: Jason Keirstead; bj@ctin.us Cc: cti@lists.oasis-open.org; jessie@nccst.nat.gov.tw; jg@ctin.us; Kelly.Cullinane@newcontext.com Subject: [Non-DoD Source] Re: [cti] How to model the object in this situation All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
Jason,
We, at DarkLight, have also been working on the definition of a custom object to represent an âassetâ, so weâd definitely be interested in collaborating. The use case/scenario you described is very common to the one which weâre addressing, so we should find lots of common ground. Weâve looked at the definition of IT Asset as defined inNIST IR 7693 < Caution-https://doi.org/10.6028/NIST.IR.7693 > for inspiration as well.
Paul Patrick EVP Engineering/interim Chief Product Officer DarkLight
Mobile: (408) 465-6635 Email: Paul.Patrick@darklight.ai
Caution-www.darklight.ai < Caution-http://www.darklight.ai/ >
This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received this e-mail in error, please delete it from your system without copying it and notify sender by reply e-mail so our records can be corrected.
From:<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Just want to chime in here;
There is currently no object in STIX to model "the asset", as in, the host/container/VM with the vulnerability. Its a use case that has been brought up a few times over the years, but never tackled.
You can shoe-horn it in with an Indicator, but honestly IMO it is improper and weird to do this.
"Infrastructure" SDO could maybe be embraced-and-extended, but it is very much designed for threat actor infrastructure, and has a very different set
of information than what you would use to describe an asset.
We would love anyone who is interested in this use case to come over and collaborate with us on it. Currently what is there is basically a minimal stub used for a specific use case, and needs a lot more thought and fleshing out. Caution-https://github.com/opencybersecurityalliance/stix-shifter < Caution-https://github.com/opencybersecurityalliance/stix-shifter > if you're interested.
- Caution-www.opencybersecurityalliance.org
|
Attachment:
incident.json
Description: incident.json
Attachment:
incident_asset_context.json
Description: incident_asset_context.json
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]