Is this a good topic for the call tomorrow? Versioning leads, does that seem reasonable to you, or do you need more time to prep?
I would argue that even as the producer I don’t want to have to update every relationship every time I revision something. Let’s say I have 600 indicators linked to a TTP or a Campaign. If I update that TTP or Campaign, I do NOT want to have to update
600 corresponding relationships, even if I do have the ability to do so.
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)
www.cisecurity.org
Follow us @CISecurity
I agree with Jason.... Major things the versioning mini-group needs to know:
1) Relationships will be created by groups other than the producer of the objects.
2) The producer may NEVER have access to those relationships.
3) When the producer updates some content in their object is MUST NOT break all of the relationships in the wild.
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."
I would disagree that "explicit is infinitely preferable to implicit". It depends *a lot* on the use case of the data and how widely shared the data is.
We have to remember, *anyone* can create relationships from or to a piece of data, not just the original producer. The original producer may not even know those relationships exist or have access to that information... and even if they do, they don't have permissions
to update it. In a successful relationship model, people would be creating relationships everywhere, making a "web" of connected threat intelligence. However, If every time I publish an update to an object, all of it's relationships break (relationships which
by the way I certainly do not have permission to update as I am not the producer, and which I may not even have access to viewing), this "web" is not going to happen, instead we will just have many disconnected threads. The only reasonable solution for this
problem would be to have TAXII servers and other intel-repositories assume the job of updating all relationships transparently in the background whenever a new version comes along. But if we are assuming that - then why are we not just using implicit relationships
in the first place?
We're moving a huge burden downstream. I also see no real benefit in this - as I pointed out in slack, because everything has a timestamp, even if we have implicit relationships it is not hard for a repository to support querying the object that existed when
the relationship was first created if that is your aim (I still think this will be the far minority of actual real-world use cases)
-
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>Trey Darley ---03/21/2016 08:49:30 AM---On 18.03.2016 23:36:16,
Marlon.Taylor@us-cert.gov wrote: >
From: Trey Darley <trey@soltra.com>
To: <Marlon.Taylor@us-cert.gov>
Cc: <cti@lists.oasis-open.org>
Date: 03/21/2016 08:49 AM
Subject: Re: [cti] Question Gathering: Relationship Preservation in Versioning (Implicit vs Explicit)
Sent by: <cti@lists.oasis-open.org>
On 18.03.2016 23:36:16,
Marlon.Taylor@us-cert.gov wrote:
>
> With Implicit Relationships - as a version is updated, the
> relationships of the former as passed along to the latter.
>
> With Explicit Relationships - as a version is updated, it is new
> with no prior relationships.
>
Given a binary choice, explicit is infinitely preferable to implicit -
cf. [0].
That said, I don't believe this necessarily *is* a binary choice -
cf.[1].
[0]: https://taxiiproject.github.io/taxii2/notional-query-api/#immutability-of-objects-under-a-url-based-object-id-scheme
[1]: https://taxiiproject.github.io/taxii2/notional-query-api/#implications-for-object-versioning
--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead." --RFC 1925
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
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.
. . .
|