OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] [Non-DoD Source] [cti] How to model the object in this situation


All:

Earlier on this thread Jeffrey mentioned that he had a stub for an Asset object. I wonder if we should schedule a working session to flush this out a little bit? It seems like there is a fair amount of interest in pushing this forward. If there is a demand for this within the community, I think we should follow Bret's roadmap for releases of object-specific documents until we are at a stage for a minor release.Â

The most important thing, however, is that we don't cause any delay to the work on the Interop Committee Notes and the STIXPreferred website update. As a TC, that is a high priority for us. So, we need to weigh resource availability to work on an Asset object, relative to the work that Marlon and Rajesh are moving forward on Interop.

Thanks Jessie for getting this dialogue started.

Jane


On 3/31/2021 8:47 AM, Bret Jordan wrote:
That sounds great. Yes, the current view of infrastructure is attacker infrastructure because that is was the model designs that people were bringing to the table. Often it is hard to get a large group like this to move forward on something without a solid initial proposal and commitment from people to drive the work forward. If you have that now, that would be great.Â

Bret

On Mar 31, 2021, at 7:55 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

Â
Back in 2017 when Infrastructure was created, non-attacker-infrastructure was a non-goal of the object
Â
    "1) The primary goal is to document attacker infrastructure. Specifically where malware was delivered from and where it is beaconing to.
    Â2) If other types of architecture can be documented, okay, but that is not our focus right now."

We thus went in the direction of a custom object because Infrastructure does not have any of the data we are actually trying to model when one thinks of an asset, and is currentlyÂvery attacker-focused (see infrastructure-type-ov vocabulary for example). As opposed to trying to get people to re-think what Infrastructure means, it seems cleaner to make a seperate object for this very different use case.Â
Â
I am open to maybe extending infrastructure (I am open to anything at this point....) but we would have to consider the impact of that to users of it.
Â
Our goal is to have proven working open source code and implementations. Once any issues are shakenÂout with those the extension could certainly be taken up by the TC if it wanted to do that.
Â
-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board
Â
Â
----- Original message -----
From: Bret Jordan <bj@ctin.us>
Sent by: <cti@lists.oasis-open.org>
To: "Mates, Jeffrey CIV DC3/ Tsd" <Jeffrey.Mates@dc3.mil>
Cc: Paul Patrick <ppatrick@darklight.ai>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "jessie@nccst.nat.gov.tw" <jessie@nccst.nat.gov.tw>, "jg@ctin.us" <jg@ctin.us>, "Kelly.Cullinane@newcontext.com" <Kelly.Cullinane@newcontext.com>
Subject: [EXTERNAL] [cti] Re: [Non-DoD Source] [cti] How to model the object in this situation
Date: Sun, Mar 28, 2021 12:30 AM
Â
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 ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
Â
Â
On Mar 26, 2021, at 7:01 PM, Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil> wrote:
Â
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

Â

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

Â

Â

Â

From:<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:ÂFriday, March 26, 2021 at 1:29 PM
To:Â"bj@ctin.us" <bj@ctin.us>
Cc:Â"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "jessie@nccst.nat.gov.tw" <jessie@nccst.nat.gov.tw>, "jg@ctin.us" <jg@ctin.us>, "Kelly.Cullinane@newcontext.com" <Kelly.Cullinane@newcontext.com>
Subject:ÂRE: [cti] How to model the object in this situation

Â

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.

Â

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.

Â

-
Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management
Caution-www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

Â

Â

----- Original message -----
From: Bret Jordan <bj@ctin.us>
Sent by: <cti@lists.oasis-open.org>
To: "
èåæ" <jessie@nccst.nat.gov.tw>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "JG @ OASIS" <jg@ctin.us>, Kelly Cullinane <Kelly.Cullinane@newcontext.com>
Subject: [EXTERNAL] Re: [cti] How to model the object in this situation
Date: Fri, Mar 26, 2021 12:50 PM
ÂÂ
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Â>ÂÂ

Â

Â


--------------------------------------------------------------------- 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
<incident.json><incident_asset_context.json>
Â


-- 
**********************************
R. Jane Ginn, MSIA, MRP
OASIS, CTI TC Secretary
OASIS, TAC TC Secretary
jg@ctin.us
**********************************


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]