Hi Jerome,
Sorry if my text wasn’t clear enough. I typed it up pretty quickly! Perhaps too quickly.
I was meaning that they would each be different Identities. There would be one Identity for the Organization, and anything that the
2 analysts produced at work on behalf of the Organization would be identified as created_by_ref pointing to the Organization’s Identity object.
If the analyst liked doing threat intel so much that she was doing her own independent research at night, then if she wanted she could
create a new Identity to reflect her own Threat Intel released as her. As it has nothing to do with her work it wouldn’t be released on behalf of her work, and instead would have a created_by_ref field pointing to her own Identity – as she is releasing the
Threat Intel as herself.
Does that make it clearer?
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com From: Jerome Athias [mailto:
athiasjerome@gmail.com]
Sent: Wednesday, 17 February 2016 8:57 PM
To: Terry MacDonald <
terry@soltra.com>
Cc: Jordan, Bret <
bret.jordan@bluecoat.com>; Sarah Kelley <
Sarah.Kelley@cisecurity.org>;
cti@lists.oasis-open.org Subject: Re: [cti] versioning
Imho this highlights a design issue with Identity if one unique object could be used to describe 2 different things
(There are a lot of cases where you would like to describe relationships between Organizations and Persons or group of them, and could reuse the description of them)
On Wednesday, 17 February 2016, Terry MacDonald <
terry@soltra.com > wrote:
I think of it in that way as well. It’s the ‘Identity’ that is connected via the created_by_ref field
on the object that demonstrates who is the object creator. The Identity could be an Individual, or an Organization. This will allow individual security researchers to publish their information just as easily as large corporations.
In the scenario you describe the Identity of any objects that either analyst creates would be tied
to the ‘Center for Internet Security (CIS)’ Identity object, as they are being published by (and represent the opinions of) the Center for Internet Security (CIS) organization. In other words, even though the analysts are creating the objects, they are doing
so on behalf of the CIS, and what they produce represents the opinion of the CIS.
If one of your threat analysts wanted to do work in their spare time at home, they could quite easily
have their own Identity object that represents them, and can publish their own assertions under their own Identity (as long as your corporate policy allows they doing their own thing at home). Any objects they created for themselves published at home would
be wholly separate from the work published under the CIS identity (as they are representing themselves on their own time).
Does that make sense?
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An
FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com From:
cti@lists.oasis-open.org [mailto:
cti@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, 17 February 2016 8:35 AM
To: Sarah Kelley <
Sarah.Kelley@cisecurity.org >
Cc:
cti@lists.oasis-open.org Subject: Re: [cti] [DETECTED AS SPAM] RE: [cti] versioning
My opinion is that would be deployment specific. Meaning, an organization could choose to publish content publicly as the org vs the individual. Now with that said, your tool
may not allow that, but that is an implementation issue with the tool you are using, not a specification issue.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an
egg."
On Feb 16, 2016, at 07:18, Sarah Kelley <
Sarah.Kelley@cisecurity.org > wrote:
I would just like to clarify something.
When we say only the object’s creator can revision it, does that mean the creating organization? Or the creating user?
The reason I’ve asked is that we have two different analysts (currently) adding data to our database. For small changes (minor revisions) we can update each other’s entries. For some larger changes that require major revisions, we have been unable to do so
in the past. That creates bad situations where we’re on the same team, and yet I can'y add, change, or remove information in our collective database that needs to be altered just because my coworker entered it first.
Sarah Kelley
Senior CERT Analyst
Center for Internet Security (CIS)
Integrated Intelligence Center (IIC)
Multi-State Information Sharing and Analysis Center (MS-ISAC)
1-866-787-4722 (7×24 SOC)
Email:
cert@cisecurity.org www.cisecurity.org Follow us @CISecurity
From: <
cti@lists.oasis-open.org >
on behalf of Terry MacDonald <
terry@soltra.com >
Date: Tuesday, February 16, 2016 at 5:22 AM
To: "Jordan, Bret" <
bret.jordan@bluecoat.com >, "Wunder, John A." <
jwunder@mitre.org >
Cc: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: [DETECTED AS SPAM] RE: [cti] versioning
I would strongly recommend that we only allow object creators to administer the lifecycle of the objects
they create. The reason is this… each object published is an assertion of truth that the Organization has made. It is the creating Organization saying ‘we think this:….’. They are effectively putting their reputation on the line to describe something that
they as an Organization believes to be true.
For this reason, we need to ensure that they are the only ones able to modify, change or retract their
assertions – after all it’s their assertions. In fact, we need to eventually work out a way to cryptographically be sure that it really is their assertion and not an imposter… but that’s a problem for a different day.
We also, as Pam rightly points out, need a way for third-parties with more information to provide that
information, and we need a way for third-parties to demonstrate their disagreement with an assertion that someone else has made. Both of these are important within STIX v2.0 to allow consumers to make up their own minds about what information they choose to
trust.
For this reason, we previously proposed three mechanisms to handle these scenarios:
The relationship object:
This allows a third party to make an assertion between two objects that they haven’t created themselves.
In Pam’s scenario 2 if Org A released a relationship object of high confidence that Bigbank attack was part of the FancyPanda Campaign, yet Org B disagreed, Org B will now be able to send out own relationship object with a really low confidence that the Bigbank
attack was part of the FancyPanda Campaign. Consumers will see the two relationships, one which is high and one which is low, and should go…huh. They can then draw their own conclusions.
The opinion object:
This is another useful object. The opinion object is a way for a third party to comment on another
organizations assertion. In Scenario 2 Org B could additionally send out an Opinion object that referes to the OrgA relationship object and that flags that Org B ‘strongly disagrees’ with the relationship object that Org A sent out earlier.
The Suggested-update relationship:
If Org B is feeling extra generous, they could also sent out their own assertion of the correct details,
with a separate relationship object with a relationship type of suggested-update. The suggested-update mechanism would allow third-party organizations to create the object they believe is ‘corrected’ and push that out to the community. The original object
creator can (if they desire) take that information and check it, and if they want to, can revoke or modify the information in the originally released object.
That’s 3 different ways that third-parties can communicate their disagreement or dissatisfaction with
another Organization’s assertion. That’s a huge improvement for STIX v2 over STIX v1.x and something that I know others have been looking for a long while.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ] On
Behalf Of Jordan, Bret
Sent: Tuesday, 16 February 2016 8:46 AM
To: Wunder, John A. <
jwunder@mitre.org >
Cc:
cti@lists.oasis-open.org Subject: Re: [cti] versioning
I think this is a brilliant idea.
Bret
Sent from my Commodore 64
On Feb 15, 2016, at 1:09 PM, Wunder, John A. <
jwunder@mitre.org > wrote:
FWIW versioning would be a great scenario to try to build a reference implementation on top of. If we want to make sure it works, as with patterning and data markings, I think we
have to. Preferably we’d have two independently developed prototypes and have them exchange versioned content following the use cases that Pam outlines below.
John
From: <
cti@lists.oasis-open.org >
on behalf of "Jordan, Bret" <
bret.jordan@bluecoat.com >
Date: Monday, February 15, 2016 at 1:23 PM
To: pam smith <
Pam.Smith@jhuapl.edu >
Cc: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >, Patrick Maroney <
Pmaroney@Specere.org >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] versioning
These are great work flow examples. We need to enable valid work flows, but we need to be careful that we do not enable bad behavior that will make parsing and organizing the data
hard.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an
egg."
On Feb 15, 2016, at 06:45, Smith, Pamela A. <
Pam.Smith@jhuapl.edu >
wrote:
I agree that it would cause a lot of confusion if anyone can revision an object. Also, I think anyone should be able to provide suggested revisions to any object.
More spitballing. Scenarios
scenario 1: Originator discovery of new information that results in revision/revocation
scenario 2: Non-originator references previously shared information that
- provides additional information on that topic including identification of errors.?
- indicates they are requesting revocation (from the originator)
?Then the Originator revises or revokes previously shared information based on non-originator feedback – and includes references to
the non-originator’s input. This assumes that the originator is and remains the authoritative source. If the Originator does not maintain their own material in the face of a lot of input from others, then in some Darwinian fashion, someone else will take
over as a new Originator of a new object, I guess.
Pam Smith
JHU/APL
From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org >
on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Sent: Monday, February 15, 2016 8:29 AM
To: Patrick Maroney
Cc: Jordan, Bret;
cti@lists.oasis-open.org Subject: Re: [cti] versioning
Question - who is "allowed" to revision an object? Can only the originator revision, or can anyone?
I presume that many people assume that only the originator can revision an object - if that is so we should call this out explicitly. The current STIX versioning description (
http://stixproject.github.io/documentation/concepts/versioning/ )
implies that anyone can version an object so long as it is "sufficiently unchanged". I think that will lead to a lot of confusion if anyone can revision an object.
On the other hand, if we want to get to the world of widespread object re-use and non-duplication, then third parties have to be able to revision objects. But what if I want to be the authoritative source? Should there be an attribute like "versioning_allowed"
?
I am just spitballing.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown
<graycol.gif> Patrick Maroney ---02/11/2016 11:10:17 PM---Although I suspect I'm banned from using the term Timestamp for at least a year ;-) ...Here's an int
From: Patrick Maroney <
Pmaroney@Specere.org >
To: "Jordan, Bret" <
bret.jordan@bluecoat.com >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Date: 02/11/2016 11:10 PM
Subject: Re: [cti] versioning
Sent by: <
cti@lists.oasis-open.org >
Although I suspect I'm banned from using the term Timestamp for at least a year ;-)
...Here's an interesting concept to consider:
{from:1388534400000,to:9223372036854775807}
http://iansrobinson.com/2014/05/13/time-based-versioned-graphs/ Note: Ian Robison uses uses epoch time in this example, so that may buy me some cover ;-)
Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
<0C160672.gif>
President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053
From: "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
on behalf of Bret Jordan <
bret.jordan@bluecoat.com >
Date: Thursday, February 11, 2016 at 7:48 PM
To: "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: [cti] versioning
What would people think about a versioning concept where each TLO had a "serial_number" field that was of type integer. And every object that gets created by a producer will
start with serial_number "1". Then as they update the TLO, the producer will just incase the serial_number.
I want to get the discussion started as I know some have very strong opinions on how it should work. But I also think, that with some good back and forth dialog, and some "coming
to middle ground" we could solve this pretty quickly.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
...
This message and attachments may contain confidential information. If it appears that this message was sent to
you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . .