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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: RE: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable


Couldn’t that lead to a big database explosion?  If someone puts in an object, and then modifies something trivial such as the description 10 times, they will have 19 full objects created in their system (1 for each version, 1 for each relationship.  That could get heavy, no?

 

In the past, I’ve seen this issue solved using effective and expiration dates (both) on each object.  This leads to some pretty complicated application logic, but would keep databases fairly clean.

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Wednesday, November 11, 2015 2:49 PM
To: Cory Casanave; Jerome Athias; Sarah Kelley
Cc: Jordan, Bret; Ivan Kirillov; Ali Khan; cti-stix@lists.oasis-open.org; cti-cybox@lists.oasis-open.org
Subject: RE: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable

 

I personally think we should only do Major Updates, and drop support for Incremental Updates (http://stixproject.github.io/documentation/concepts/versioning/).

 

Major Updates would mean that any update to a STIX Object would actually be an issue of the updated Object under a new Object ID, with an explicit relationship (using the new top-level relationship object) of ‘supersedes’ with the Object ID of the ‘replaced’ Object.

 

This has numerous benefits:

·         The relationship is explicit. Rather than an implicit relationship where you as a consumer need to be able to detect the similarities between old and new, with an explicit relationship you are absolutely aware of the fact the new object is a replacement.

·         The original Object still exists, allowing analysis of the timeline in changes. This will help inform consumers of how ‘accurate’ a producer is.

·         De-duplication is then able to be performed solely on the Object ID as timestamp is no longer involved as a composite key in identifying the specific object revision. This makes processing updates easier.

·         It allows us to do tricks such as generating the Object ID from a hash (prepended by a namespace). This in turn gives us benefits in that deduplication is now easier as we just need to compare the end of the Object IDs to match the same STIX Objects, even if they are sent from within different producer namespaces.

o   Note: This still doesn’t help if we allow lists of things, such as lists of IPv4 Addresses as each implementation would need to pull out the individual Objects and de-duplicate using those.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Cory Casanave
Sent: Thursday, 12 November 2015 12:45 AM
To: Jerome Athias <athiasjerome@gmail.com>; Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; Ivan Kirillov <ikirillov@mitre.org>; Ali Khan <akhan@soltra.com>; cti-stix@lists.oasis-open.org; cti-cybox@lists.oasis-open.org
Subject: RE: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable

 

I would like to strongly “+1” the idea of using the relationships as a basis for versioning. Deleting data is so 20th century!

 

If you consider each instance of these relationships a “statement” (or fact) stated by some party at some time, it will always be true that this  party said what they said when they said it. In this area of threats, such “historical” statements can be very important even if they are no longer considered “true” by some party (i.e. some statements that made the U.S. go to war in Iraq ). As these statements (relationship instances) are already first-class things they can have a timeframe and confidence. We can say “that statement is invalid” or “That set of statements is not longer true”. If some implementation wants to interpret that as a “delete”, that would be fine but others may want a record of such statements (U.S. national archives likes to do such things).

 

Most of the infrastructure is already in place to do this, relationships have identity. Adding “second order” statements about them such as “superseded by” or “end date” provides for a very robust distributed knowledge base, which is what we are fundamentally trying to support.

 

-Cory

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jerome Athias
Sent: Tuesday, November 10, 2015 9:08 PM
To: Sarah Kelley
Cc: Jordan, Bret; Ivan Kirillov; Ali Khan; cti-stix@lists.oasis-open.org; cti-cybox@lists.oasis-open.org
Subject: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable

 

While implementation dependent, imho, the top construct Relationship (remember top of our todo list) will help.

Would be 'easy' to implement a purge procedure of all observables that don't have a Relationship created more than x month/week ago

(Similar to logs or backups/archives management/roll process)

 

Should we finalize the Relationship?

On Tuesday, 10 November 2015, Sarah Kelley <Sarah.Kelley@cisecurity.org> wrote:

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)

Follow us @CISecurity

 

 

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, November 10, 2015 at 1:16 PM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: Sarah Kelley <sarah.kelley@cisecurity.org>, Unknown Unknown <athiasjerome@gmail.com>, Ali Khan <akhan@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
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. <ikirillov@mitre.org> 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, "cti-cybox@lists.oasis-open.org on behalf of Sarah Kelley" <cti-cybox@lists.oasis-open.org on behalf of Sarah.Kelley@cisecurity.org> 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: cert@cisecurity.org
www.cisecurity.org
Follow us @CISecurity






On 11/10/15, 11:06 AM, "cti-stix@lists.oasis-open.org on behalf of
Kirillov, Ivan A." <cti-stix@lists.oasis-open.org on behalf of
ikirillov@mitre.org> 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, "cti-cybox@lists.oasis-open.org on behalf of
Jerome Athias" <cti-cybox@lists.oasis-open.org on behalf of
athiasjerome@gmail.com> 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 <akhan@soltra.com>:

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 | akhan@soltra.com


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


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.


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