| If there is enough interest in doing some of these things, then the TC should do them. That is the correct place for the work to be done. Then they can be released as standalone specs for that one object.
I know I have brought this up in the past, but post 2.1 I see the TC working on a series of objects that get released as standalone specs. Some objects may just be extensions. Some may be really informally published via Github or a website. Some may be released as a Committee Note.
Then over time (several years), once there is a bunch of these defined objects, the TC can then fold them all back into the main spec and release a version 2.2 or if there is enough changes, a 3.0.
But the work on STIX and TAXII should be done in this TC. So if you have ideas for things or you are working on some objects, please start discussing them on the list and start fleshing them out. Then when you are ready I can help show you how to start an official document and submit it to the TC for a CSD ballot.
Bret
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â
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 <image001.png> 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. 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.
IBM and some others are working on this problem area via a custom object in STIX Shifter in the OCA because its a very important object & use case for us in a bunch of scenarios around posture management, as well as reporting back of findings using STIX. Once its more settled we would publish an extension with the proposal. -
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
Caution-www.ibm.com/security
Co-Chair - Open Cybersecurity Alliance, Project Governing Board With STIX 2.1 SCO objects are now treated as top-level objects. So yes, you would use the SCO Software object to describe the version of Chrome and the SDO Vulnerability to describe the CVE. Then you would use a relationship to tie them together. We did not call out this relationship type specifically in the specification. However, if you look at Infrastructure you can see that there is one called âhasâ vulnerability. So I would do the same here. SCO Software âhasâ SDO Vulnerability.
Bret
> On Mar 26, 2021, at 4:07 AM, èåæ <jessie@nccst.nat.gov.tw> wrote:
>
> Hi TC members,
>
> We are confused about how to describe "affected releases" in STIX 2.1.
>
> There are two use cases:
> 1. CVE-2020-16013 exists in Google Chrome affected chrome versions prior to 86.0.4240.197.
> âAre affected releases modeled using STIX Software SCO? ( chrome versions prior to 86.0.4240.197 here)
>
> 2. Microsoft Exchange Server Vulnerabilities(CVE-2021-26855ãCVE-2021-26857ãCVE-2021-26858åCVE-2021-27065) affected Microsoft Exchange Server 2013ã2016ã2019.
> âAre affected releases modeled using STIX Identity SDO? ( Microsoft Exchange Server 2013ã2016ã2019 here)
>
> We are wondering if there exists "an Object" (without building our own SDO/SCO) that could describe the affected object (no matter it is system or software)?
>
> Regards,
> Jessie Chuang
>
> Taiwan National Computer Emergency Response Team
> No.116, Fuyang St., Daâan Dist., Taipei City 106, Taiwan (R.O.C.)
> Tel: 886-2-6631-6483
>
> This email may contain confidential information. Please disregard and delete this email if you are not the intended recipient.
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
Caution-https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php < Caution-https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
|