Jason, check out the sectioning on STIX versioning: http://stixproject.github.io/documentation/suggested-practices/
Cybox, or Observables, did not make the STIX versioning cut. If we cannot edit an observable, then we have to replace the reference to that observable in it’s parent object.
I am not saying I agree or disagree with this versioning approach in STIX, I am just saying we are working with the cards we have been dealt.
Aharon
--
Aharon Chernin
CTO
SOLTRA |
An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 |
www.soltra.com
From: <> on behalf of Jason Keirstead <>
Date: Wednesday, November 11, 2015 at 2:34 AM
To: Aharon <>
Cc: Sarah Kelley <>, "Jordan, Bret" <>, Ivan Kirillov <>,
Unknown Unknown <>, Ali Khan <>, "" <>,
"" <>
Subject: Re: [cti-stix] Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
Something I am not understanding from this trail. This problem all originates from this process:
"In our instance of Soltra Edge, we have (on many occasions) had to ‘edit’ an observable. Currently this involves editing the indicator, deleting the
link to the current Cybox observable, and creating a new observable. This leaves lots of orphaned observables in our database that we really need to
have the ability to purge."
Why can one not simply edit the original observable, preserving links, and not orphaning anything?
If we can't update/edit/append/delete an observable and have that cascade to all linked indicators ... then there is little point to having this linkage vs simply embedding signatures directly in the indicator.
Is the reason you can't do this a problem in STIX/Cybox? Or is this a tool issue (does Edge not let you edit an observable? I am not sure, have never tried)
-
Jason Keirstead
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
Aharon
Chernin ---11/10/2015 07:35:51 PM---Sarah, We are throwing around a number of ideas of regarding cleaning up orphaned observables. Our n
From: Aharon Chernin <>
To: Sarah Kelley <>, "Jordan, Bret" <>, Ivan Kirillov <>
Cc: Unknown Unknown <>, Ali Khan <>, ""
<>, "" <>
Date: 11/10/2015 07:35 PM
Subject: Re: [cti-stix] Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
Sent by: <>
Sarah,
We are throwing around a number of ideas of regarding cleaning up orphaned observables. Our next major release should include a STIX compliant solution.
Aharon
--
Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 |
www.soltra.com
From: <>
on behalf of Sarah Kelley <>
Date: Tuesday, November 10, 2015 at 1:21 PM
To: "Jordan, Bret" <>, Ivan Kirillov <>
Cc: Unknown Unknown <>, Ali Khan <>,
"" <>,
"" <>
Subject: [cti-stix] Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
At this point, we’re currently just trying to clean up our own database. I’m sure there is a much wider issue involved, but our current context is that we have the same observable in our system five different times (which is obviously unnecessary).
The only things that changed were things like TLP, or “Hey, I fat-fingered something!” I understand the concern about "what does it mean to revoke a fact", but what if it’s just wrong? You type 1.1.1.1, and you really meant 2.2.2.2? The first is not correct,
but currently is lingering in the system, even after unlinking it from the indicator.
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:
www.cisecurity.org
Follow us @CISecurity
From: "Jordan, Bret" <>
Date: Tuesday, November 10, 2015 at 1:16 PM
To: Ivan Kirillov <>
Cc: Sarah Kelley <>, Unknown Unknown <>,
Ali Khan <>, ""
<>, ""
<>
Subject: Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
We have talked about this a lot in the past, in regards to STIX, and I now view this as an implementation or process related issue. The reason for that is you can not guarantee that the other end of the link will honor your request. Maybe
in "like" systems, meaning all systems built by EclecticIQ or Soltra, you would have some level of success.
But when you span across products there is no guarantee that they have implemented it in their code, nor that the administrator will allow it. Requests like that may go in to a bucket for human review.
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 Nov 10, 2015, at 11:09, Kirillov, Ivan A. <> wrote:
Thanks for the context, Sarah - very helpful.
To me, this comes down to being a language versus process question - that is, is Observable revocation something that should be addressed as part of the CybOX language, or should it be considered more as part of the processes in which CybOX is used? I’m leaning
towards the latter, for the reason that the notion of revocation around Observables is something that doesn’t seem to fit as part of the data model around them. This is because, at their core, Observables represent some cyber “fact”, and what it does it mean
to revoke a “fact”? At least with Indicators, you can argue that the Indicator may no longer be valid, or that its pattern is incorrect. With Observables, I think the semantics of revocation are not as clear and may not really make sense.
At least in your case, it seems like we may need to consider defining some sort of garbage collection process, where Observables (and any other id-able CybOX/STIX entities) that were referenced and/or embedded in another entity and then no longer referenced
be pruned from the datastore.
Regards,
Ivan
On 11/10/15, 12:31 PM, " on behalf of Sarah Kelley" <
on behalf of > wrote:
Just to give a little context around this question, this came up in a
conversation between Ali (well, several Soltra people) and myself today.
In our instance of Soltra Edge, we have (on many occasions) had to ‘edit’
an observable. Currently this involves editing the indicator, deleting the
link to the current Cybox observable, and creating a new observable. This
leaves lots of orphaned observables in our database that we really need to
have the ability to purge. The understanding we have is that currently
Cybox doesn’t support any sort of revoke/purge like Stix does.
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:
www.cisecurity.org
Follow us @CISecurity
On 11/10/15, 11:06 AM, " on behalf of
Kirillov, Ivan A." < on behalf of
> wrote:
Great question Ali; unfortunately I don’t have much insight into this
topic. Moving this to the STIX list - I think revocation is more specific
to STIX (though it clearly touches upon CybOX as well).
Regards,
Ivan
On 11/10/15, 11:00 AM, " on behalf of
Jerome Athias" < on behalf of
> wrote:
Potential review of this
https://stixproject.github.io/data-model/1.2/indicator/ValidTimeType/
Suggestions welcome
2015-11-10 18:48 GMT+03:00 Ali Khan <>:
What is the cybox committees discussion so far for future versions to
support ability to revoke and remove completely a cybox observable
that was
created and then shared but now there is a need to remove it.
Thank You
Ali Khan
Lead Analyst
SOLTRA | An FS-ISAC & DTCC Company
Tampa, fl 33647
813.470.2197 |
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
...
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.
. . .
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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.
. . .
