[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Updated report proposal
1) Separate grouping object for the reasons I have already conveyed. To Bret’s point below, I can see Report evolving and growing a bit in the future but do not see Grouping growing.
2) Strongly support using a property and not labels
3) I do not have strong feelings on the current proposed vocab. I could see it might benefit from more thought but is not unacceptable as-is. I think the key is that this vocab is applicable only to Report and not to Grouping. Maybe have an “is_automation_ready” Boolean property on the Grouping object (instead of the “status” property which would be on Report)? This sounds like it would fulfill the MIST request and while I don’t know if we would ever use it, it does not sound illogical or inappropriate.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
On 9/20/17, 8:09 AM, "Reller, Nathan S." <cti-stix@lists.oasis-open.org on behalf of Nathan.Reller@jhuapl.edu> wrote:
1) Separate grouping object. I can’t think of another library or instance where the developers decided to name a group of things a report. It confuses me.
2) Use a property
3) No comment
-Nate
On 9/20/17, 4:15 AM, "cti-stix@lists.oasis-open.org on behalf of Andras Iklody" <cti-stix@lists.oasis-open.org on behalf of andras.iklody@circl.lu> wrote:
1) Either is fine for us at MISP Project, though a separate Grouping
object would probably be somewhat preferred after a discussion with Sean
- Reports indeed have their own distinct valid use-cases and altering
them might be tricky for some.
2) We'd definitely prefer a property over a label to ensure that it's
adhered to. Labels currently seem like something rather optional and our
goal is simply to convey whether it is data that should be automated on
or not in its current form.
3) The proposed values, “initial-analysis”, “updated-analysis”, “final”,
and “finished-product”, don't help us at all sadly as they fail to
convey the main message we want to send: This grouping / report /
collection whatever is currently in a shape that the producer feels
should be used for automation or not. We internally call it the
published flag, but we're not attached to the naming at all, as long as
it gets the above message across. Having additional values on top of
that is fine by us, as long as we can map our "Do not automate / Do
automate" values to it.
Best regards,
Andras
On 20. sep. 2017 00:20, Bret Jordan wrote:
> 1) I can go either way, not sure if I have a strong opinion on this.
> What would change my opinion is knowing will either of these objects
> grow or expand in the future. Right now they seem pretty close, but
> over time will they diverge? By grouping them in to the same object do
> we prevent them from growing / expanding in the future as the growth in
> one area would negatively impact the growth in the other? If they are
> two objects then what happens when one needs to be converted in to the
> other? Is this more problematic than the risks outlined above, or would
> a new object creation just be the logical step?
>
> 2) I have argued several times for content to be in its own property
> only to have this SC and RichThe say "that is what labels are for". I
> think we need to have clear guidance on when we use labels and when we
> use a special property for things that are "labels of status".
>
> 3) The values in the list seem like they need some work, they feel a bit
> wishy-washy to me... If we do not have solid values that make a ton of
> sense, then maybe we have a field that just has 1 or 2 options. We can
> always add more later, assuming we figure out why this is not just labels.
>
> Bret
> ------------------------------------------------------------------------
> *From:* cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
> behalf of Wunder, John A. <jwunder@mitre.org>
> *Sent:* Tuesday, September 19, 2017 2:13:55 PM
> *To:* cti-stix@lists.oasis-open.org
> *Subject:* [EXT] Re: [cti-stix] Updated report proposal
>
>
> All, I wanted to re-up this since we just discussed it on the working
> call. The proposal is here:
> https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj
> <https://clicktime.symantec.com/a/1/51BWY_AGy4W7WlauinQaARx73VHj0FnxYas6Ke9M7Us=?d=2Sx8nYQF5qEDnr51qKLtPLhqjzL74XWX53CS-Diqj_FfFv3KplVJor3ejFw8z3eRMlFf4cB_VzjxLSFHRpZGKbAAxEwUgeBf12sWZaFgkKqODhPVfhAVE6wZRfDYjKwalg9JY-gkK5NdPUYnmv5ih9Jl-hGmozGLmSWYuKI8lk-30NCmKJmz5IcGDSxrzD6DD_x_eAwtrPQQAW19A__SJU7INH1JRdlVo1dD8NCzAyaJvj59tBVFp5Y96D_QmGBw-1Q4r9Gdx37_p1rrcd4aKQyY6gZ_yo7VEICHBOffjjnggFhw-DVXqNEpPkqU2X6qPQdQVbpRlbC2cke8GbsgdDlJ80chlR3rrgkJ2zYHdTSkst3M-Fj3cx6iC4PFY3gg0nQttksCtTRBCQIEq60SIz4r_XtpR2LXSXBTodFaLfue-EGeqRqU1EU8KCXF&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4%2Fedit%23heading%3Dh.y3otj21tnvuj>
>
>
>
> As a reminder, this topic is meant to address a need MISP brought up to
> share collections of threat intelligence (they call them “Events”) that
> are not at the level of a published report but need to be shared as a
> cohesive set with some shared context (title, description, labels, etc.)
>
>
>
> We still have three open questions:
>
>
>
> 1. Is doing this in the Report object the right approach, or do we need
> to add a new Grouping object? Consensus has been that we should do
> this in the Report object, though Sean in particular has pointed out
> that FireEye believes it should be separate (as he said below).
> Given previous consensus across two working calls here I think we
> can assume that we’ll do it in Report unless we get a lot of
> feedback saying otherwise.
> 2. Should we add a separate *status *property to capture the status of
> the report (as in the proposal now), or should we just use the
> *labels *property with pre-defined labels to enable automation.
> Consensus is mixed here, so please weigh in with your reasoning.
> MISP felt like to enable automation we needed a separate property,
> JMG and Bret pointed out that we’ve previously put values meant to
> enable automation in *labels*.
> 3. What values should go in that *status *vocabulary, regardless of
> which property we end up putting it in? Right now we have a proposal
> from Allan Thomson for “initial-analysis”, “updated-analysis”,
> “final”, and “finished-product”. Are these correct? What new/changed
> values should there be?
>
>
>
> I think we’re VERY close to finally figuring this one out, so please let
> us know what you think. My opinions are:
>
>
>
> 1. Do it in Report.
> 2. Honestly either way seems doable to me, but I lean towards a
> separate status field so you can easily separate out the status
> values from other stuff you might put into report labels.
> 3. I would keep “initial-analysis”, “final”, “finished-product”. I
> would remove “updated-analysis” because I think you can capture that
> semantic with the modified property and a value of
> “initial-analysis” (maybe call them “working-analysis”,
> “final-analysis”, “finished-product”).
>
>
>
> Thanks!
>
> John
>
>
>
>
> *From: *<cti-stix@lists.oasis-open.org> on behalf of John Wunder
> <jwunder@mitre.org>
> *Date: *Monday, September 18, 2017 at 4:59 PM
> *To: *Sean Barnum <sean.barnum@FireEye.com>,
> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
> *Subject: *Re: [cti-stix] Updated report proposal
>
>
>
> Sorry about that…somewhat ironically, after there were problems with
> finding all of the stuff we were working on, I moved it over to the
> Working Concepts doc later last week:
> https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj
> <https://clicktime.symantec.com/a/1/51BWY_AGy4W7WlauinQaARx73VHj0FnxYas6Ke9M7Us=?d=2Sx8nYQF5qEDnr51qKLtPLhqjzL74XWX53CS-Diqj_FfFv3KplVJor3ejFw8z3eRMlFf4cB_VzjxLSFHRpZGKbAAxEwUgeBf12sWZaFgkKqODhPVfhAVE6wZRfDYjKwalg9JY-gkK5NdPUYnmv5ih9Jl-hGmozGLmSWYuKI8lk-30NCmKJmz5IcGDSxrzD6DD_x_eAwtrPQQAW19A__SJU7INH1JRdlVo1dD8NCzAyaJvj59tBVFp5Y96D_QmGBw-1Q4r9Gdx37_p1rrcd4aKQyY6gZ_yo7VEICHBOffjjnggFhw-DVXqNEpPkqU2X6qPQdQVbpRlbC2cke8GbsgdDlJ80chlR3rrgkJ2zYHdTSkst3M-Fj3cx6iC4PFY3gg0nQttksCtTRBCQIEq60SIz4r_XtpR2LXSXBTodFaLfue-EGeqRqU1EU8KCXF&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4%2Fedit%23heading%3Dh.y3otj21tnvuj>
>
>
>
> John
>
>
>
> *From: *Sean Barnum <sean.barnum@FireEye.com>
> *Date: *Monday, September 18, 2017 at 4:56 PM
> *To: *John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org"
> <cti-stix@lists.oasis-open.org>
> *Subject: *Re: [cti-stix] Updated report proposal
>
>
>
> I don’t see any proposal in the linked doc.
>
>
>
> I would object to attempts to conflate these two objects together. I
> believe I have given clear reasoning for this position in the past.
>
>
>
> Sean Barnum
>
> Principal Architect
>
> FireEye
>
> M: 703.473.8262
>
> E: sean.barnum@fireeye.com
>
>
>
> *From: *<cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A."
> <jwunder@mitre.org>
> *Date: *Tuesday, September 12, 2017 at 8:36 AM
> *To: *"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
> *Subject: *[cti-stix] Updated report proposal
>
>
>
> All,
>
>
>
> As I mentioned in an e-mail yesterday, based on the straw poll that we
> had on the August 29 working call (notes here:
> https://www.oasis-open.org/committees/download.php/61462/OASIS-CTI-TC_WorkingSession_August29_2017.pdf)
> <https://clicktime.symantec.com/a/1/HC6joY0PeJDy6ZNZDupSHvNQ-59wZxxY7u4VfROboH0=?d=2Sx8nYQF5qEDnr51qKLtPLhqjzL74XWX53CS-Diqj_FfFv3KplVJor3ejFw8z3eRMlFf4cB_VzjxLSFHRpZGKbAAxEwUgeBf12sWZaFgkKqODhPVfhAVE6wZRfDYjKwalg9JY-gkK5NdPUYnmv5ih9Jl-hGmozGLmSWYuKI8lk-30NCmKJmz5IcGDSxrzD6DD_x_eAwtrPQQAW19A__SJU7INH1JRdlVo1dD8NCzAyaJvj59tBVFp5Y96D_QmGBw-1Q4r9Gdx37_p1rrcd4aKQyY6gZ_yo7VEICHBOffjjnggFhw-DVXqNEpPkqU2X6qPQdQVbpRlbC2cke8GbsgdDlJ80chlR3rrgkJ2zYHdTSkst3M-Fj3cx6iC4PFY3gg0nQttksCtTRBCQIEq60SIz4r_XtpR2LXSXBTodFaLfue-EGeqRqU1EU8KCXF&u=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Fdownload.php%2F61462%2FOASIS-CTI-TC_WorkingSession_August29_2017.pdf%29>
> I put together a proposal to modify the report object to cover the
> concept of an evolving collection of content (i.e., the MISP use case).
>
>
>
> Proposal is here:
> https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.n8bjzg1ysgdq
> <https://clicktime.symantec.com/a/1/8J_TVPrvYySxiNoBFKVKxMssuSku3jv90eXvX213IGM=?d=2Sx8nYQF5qEDnr51qKLtPLhqjzL74XWX53CS-Diqj_FfFv3KplVJor3ejFw8z3eRMlFf4cB_VzjxLSFHRpZGKbAAxEwUgeBf12sWZaFgkKqODhPVfhAVE6wZRfDYjKwalg9JY-gkK5NdPUYnmv5ih9Jl-hGmozGLmSWYuKI8lk-30NCmKJmz5IcGDSxrzD6DD_x_eAwtrPQQAW19A__SJU7INH1JRdlVo1dD8NCzAyaJvj59tBVFp5Y96D_QmGBw-1Q4r9Gdx37_p1rrcd4aKQyY6gZ_yo7VEICHBOffjjnggFhw-DVXqNEpPkqU2X6qPQdQVbpRlbC2cke8GbsgdDlJ80chlR3rrgkJ2zYHdTSkst3M-Fj3cx6iC4PFY3gg0nQttksCtTRBCQIEq60SIz4r_XtpR2LXSXBTodFaLfue-EGeqRqU1EU8KCXF&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14%2Fedit%23heading%3Dh.n8bjzg1ysgdq>
>
>
>
>
> The changes are:
>
> 1. The description of the Report object was modified slightly to remove
> the reference to it being “published”. There were also some
> additional examples added.
> 2. The *published* property was made optional, to allow for cases where
> the report is not yet published.
> 3. A new *status *property was added, based on a suggestion from Allan
> that what we were describing as “published” or “not published” was
> not really a binary flag. The vocabulary is still somewhat TBD,
> right now I just put “ongoing-analysis” and “final” in as placeholders.
>
>
>
> On the call most folks seemed to think that the best option was to
> modify the Report object, but we did have a couple open questions:
>
>
>
> 1. Now that you’ve seen the proposal, does this general approach seem
> acceptable?
> 2. What are the possible values in the “status” vocabulary? The thought
> on the call was that there were more than two, but I couldn’t think
> of anything and I asked on Slack and didn’t get anything either.
>
>
>
> Thanks,
>
> John
>
> This email and any attachments thereto may contain private,
> confidential, and/or privileged material for the sole use of the
> intended recipient. Any review, copying, or distribution of this email
> (or any attachments thereto) by others is strictly prohibited. If you
> are not the intended recipient, please contact the sender immediately
> and permanently delete the original and any copies of this email and any
> attachments thereto.
>
---------------------------------------------------------------------
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 email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]