+1
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org]
On Behalf Of Paul Patrick
Sent: Thursday, 4 February 2016 6:28 AM
To: Kirillov, Ivan A. <ikirillov@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@soltra.com>; cti-cybox@lists.oasis-open.org
Subject: Re: [cti-cybox] CybOX Object Selection
In addition, having it as a separate object helps in the ability to relate it to other things (at least that is how we use it)
Yup, it’s just the number, along with some data that you can glean from the RIR [1]. The primary impetus for having it as a separate Object was for cases where
you may want to share information about malicious AS’s without additional context. If we feel that this isn’t a likelihood (or useful), I’m fine with excluding it and implementing it as a number in the Network Connection.
What would be in the AS object?
AS is a number with a defined enum, why do we need an object to communicate a number? Should STIX copy data from APNIC and RIPE...., why would we...
Sent from IBM Verse
Kirillov, Ivan A. --- Re: [cti-cybox] CybOX Object Selection ---
Going through the “green-field” list again (BTW Rich Piazza added a column highlighting the relative complexity of each Object via its number of UML classes/enums), I think it might be reasonable to also include the following objects:
* AS - well understood and likely to be used in the updated Network Connection Object (source/destination ASN).
* x509 Certificate - well understood and supported via the x509 to CybOX utility [1]
[1] https://github.com/CybOXProject/x509-to-cybox
Regards,
Ivan
On 2/3/16, 8:19 AM, "Kirillov, Ivan A." <ikirillov@mitre.org> wrote:
>I think that makes great sense, Trey.
>
>On the point release front, we’d love any input to help us plan out this roadmap - which objects/object classes would you like to see us address first? I know that Terry is keen on the web forum post object/credential dump object, as an example.
>
>Oh, and if we do envision using these Object subsets/classes as a means for producers/consumers to declare their particular facet of CybOX support, it seems like this is a topic for the interoperability SC.
>
>Regards,
>Ivan
>
>
>
>
>On 2/3/16, 4:31 AM, "Trey Darley" <cti-cybox@lists.oasis-open.org on behalf of trey@soltra.com> wrote:
>
>>On 02.02.2016 13:44:00, Jason Keirstead wrote:
>>> ". Maybe what we really need is a “malware analysis” subset, a “digital
>>> forensics” subset, etc."
>>>
>>> Yep that is what I am saying I suppose.
>>>
>>> Cybox Base
>>> Cybox Network
>>> Cybox Digital Forensics
>>> Cybox Malware
>>>
>>> That way a product can more easily specify what they support. And,
>>> people looking for products can more easily align expectations.
>>>
>>
>>Hey, Jason -
>>
>>This is precisely the approach Ivan and I intend to pursue in point
>>releases to 3.0. The idea for 3.0 is, let's get the core CybOX
>>abstract type definitions right and refactor the set of core MVP
>>Observable types selected. Then, say, for 3.1, we as a community
>>decide to prioritize the digital forensics domain. So we'll pull
>>together a constituency of subject matter experts to guide the
>>creation / refactoring of additional Observable types focused on
>>digital forensics use cases.
>>
>>In parallel to the ongoing 3.0 effort, I'd like to see us:
>>
>>0) Assemble a list of use case categories a la:
>>
>> * network
>> * digital forensics
>> * malware analysis
>> * mobile
>> * virtualization
>> * ...
>>
>>1) Prioritize that list to produce a point release roadmap.
>>
>>2) Work to identify subject matter experts to guide those discussions,
>> reach out, get them on board, and execute the timeline.
>>
>>Thoughts?
>>
>>--
>>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
>>--
>>"For all resources, whatever it is, you need more." --RFC 1925
|