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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

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


Subject: Re: [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April


Just to re-iterate from a previous email, here’s what having CybOX serve as a library of standard type definitions entails:

* CybOX would only define the types (i.e. Classes) around Objects and Actions, but the context and usage for these types would be defined by the languages that use CybOX
   * The implications of this are as follows:
     * CybOX would define a smaller set of entities
     * CybOX cannot be used in a standalone capacity to exchange instance data
         * CybOX does not define any TLOs
         * CybOX does not define any container entities such as the CybOX Package
* In STIX, the Observation would define the semantics around observations of CybOX Objects and potentially Actions
* In MAEC, CybOX Objects and Actions would be used to define the semantics around malware behavior
* Users of CybOX could add data markings, versioning, and any other properties to CybOX entities as they see fit, but these properties would not have to be defined natively in CybOX


Regards,
Ivan



On 4/15/16, 3:03 AM, "Trey Darley" <cti-cybox@lists.oasis-open.org on behalf of trey@soltra.com> wrote:

>Hi, all -
>
>There's been an enormous amount of discussion over the past several
>weeks regarding what CybOX should be and where the tearline is with
>other standards that leverage CybOX. It seems like that old familiar
>situation we find ourselves in so often, talking past one another in
>more-or-less violent agreement.
>
>This week Ivan and I put our heads together and came up with the
>following mission statement for CybOX:
>
><snip>
>CybOX is a library of standard type definitions for the representation
>and interchange of metadata related to artifacts of computational
>systems, used by STIX and other standards.
></snip>
>
>In general, mission statements tend to be touchy-feely BS, but in this
>case we felt like having a clear mission statement would effectively
>put a stake in the ground and end a lot of the fruitless circular
>discussions that have plagued us lately.
>
>We discussed the draft mission statement during yesterday's CybOX SC
>working call and there appeared to be complete consensus that this was
>a positive move. Our plan is to open a TC ballot measure to
>(hopefully) once and for all nail down a clear definition for what
>CybOX is.
>
>There were a few comments about the phrase "artifacts of computational
>systems". Since we already anticipate tackling a diverse set of use
>cases in future and there are surely many "unknown unknowns" lying
>ahead as well, we struggled mightily to come up with that phrasing.
>(The obvious and utterly ridiculous alternative we were trying to
>avoid was "cyber stuff".)
>
>The consensus coming out of yesterday's working call was that the
>current language is good enough and that we should put it to a TC
>vote.
>
>If you have major issues with the draft language for the CybOX mission
>statement, please speak up today. Otherwise, we'll move to open a
>ballot on Monday 18 April.
>
>-- 
>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
>--
>"No matter how hard you push and no matter what the priority, you
>can't increase the speed of light." --RFC 1925


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