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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Summary of the working call


Hello John-Mark,

Indeed, we found the Report to be the closest match too, however, the
description of the Report object (that it is a finalised published
report) goes against our design of "living" documents that are never
really finalised, just in a boolean state of unpublished/published with
continuous improvements form the community at any point in the
document's life-cycle.

Our original proposal
(https://www.misp.software/STIX2.1Reportproposal.pdf) that was discarded
was simply to reword the description and to include a boolean published
field, however this was rejected.

Best regards,
Andras

On 25. aug. 2017 01:04, John-Mark Gurney wrote:
> Alexandre Dulaunoy wrote this message on Wed, Aug 23, 2017 at 10:42 +0200:
>> On 22/08/17 22:12, Sarah Kelley wrote:
>>> On today’s working call, we discussed the event object. We didn’t have someone taking full notes, but I’ll try to summarize what was discussed below.
>>>
>>>
>>>   1.  The event object should be scoped down to just an IR type of event/incident. This would need to be clarified in the text, but that would then scope out some of our other use cases such as:
>>>      *   An ‘alert’ coming into your system
>>>      *   An ‘event’ such as a threat actor registering a domain
>>>      *   The MISP version of ‘event’
>>
>> As our past proposals (event and updated report) were rejected and seeing how despite expectations the new event SDO won't accommodate the requirements of many CERTs and considering that we need to
>> move on regarding this, we propose a new SDO called generic event to be able to map MISP events to STIX.
>>
>> https://www.misp-project.org/generic-event-proposal-STIX-2.1.pdf
> 
> after a quick read of this proposal, it almost seems like the Report
> SDO could be exapnded to support this use case.
> 


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