cti-cybox message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-cybox] CybOX Object Selection
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- Date: Wed, 3 Feb 2016 19:47:24 -0400
Sorry it seems like I am harping on such a minor point - I just really don't get the use case for the object...
The last thing I want to be responsible for when I publish a network flow object, is to do a bunch of APNIC lookups to fill in fields like "Name" and "RIR" in an AS object, when all of this can be looked up at receipt time by anyone who wants to know it.... this is a similar conversation as what we had with the "vulnerability" object, where I think we got consensus to drop all the superfluous fields that can be looked up like "name" etc.
Are people planning on supplying actual intel *about* an AS? Is there a concrete use of this in the field today...
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
Jason Keirstead---02/03/2016 06:57:09 PM---I don't really get the use case still. Why would you need to make a relationship to an integer?
From: Jason Keirstead/CanEast/IBM@IBMCA
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Cc: "Paul Patrick" <ppatrick@isightpartners.com>, "Trey Darley" <trey@soltra.com>, cti-cybox@lists.oasis-open.org
Date: 02/03/2016 06:57 PM
Subject: Re: [cti-cybox] CybOX Object Selection
Sent by: <cti-cybox@lists.oasis-open.org>
I don't really get the use case still.
Why would you need to make a relationship to an integer?
It would always be more efficient to just store the duplicate integer everywhere.
Sent from IBM Verse
Kirillov, Ivan A. --- Re: [cti-cybox] CybOX Object Selection ---
From: | "Kirillov, Ivan A." <ikirillov@mitre.org> |
To: | "Paul Patrick" <ppatrick@isightpartners.com>, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> |
Cc: | "Trey Darley" <trey@soltra.com>, cti-cybox@lists.oasis-open.org |
Date: | Wed, Feb 3, 2016 3:33 PM |
Subject: | Re: [cti-cybox] CybOX Object Selection |
Ah, yup – that’s another valid use case. Thanks for the input Paul.
Regards,
Ivan
From: Paul Patrick <ppatrick@isightpartners.com>
Date: Wednesday, February 3, 2016 at 12:28 PM
To: Ivan Kirillov <ikirillov@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@soltra.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Object Selection
Ivan,
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)
Paul
From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Wednesday, February 3, 2016 at 1:21 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Trey Darley <trey@soltra.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Object Selection
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.
[1] http://stixproject.github.io/data-model/1.2/ASObj/ASObjectType/
Regards,
Ivan
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, February 3, 2016 at 12:14 PM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: Trey Darley <trey@soltra.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Object Selection
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]