[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] CybOX Object Selection
A few more updates:
Also, we’ve updated the CybOX 3.0 visualization to take into account the current list of Objects that will not be included for the 3.0 release (in purple): http://cyboxproject.github.io/cybox3.0/viz/
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Friday, February 5, 2016 at 1:52 PM To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org> Subject: Re: [cti-cybox] CybOX Object Selection Small update: after a discussion with some other users, we’re also considering inclusion of the SMS Message Object for CybOX 3.0. Accordingly, as part of this, it has been suggested that we consider refactoring this object and likely Email Message into
a base “Message” Object with corresponding extensions.
Regards,
Ivan
From: Ivan Kirillov <ikirillov@mitre.org>
Date: Thursday, February 4, 2016 at 8:20 AM To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Patrick Maroney <Pmaroney@Specere.org> Cc: Bret Jordan <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Paul Patrick <ppatrick@isightpartners.com>, Trey Darley <trey@soltra.com> Subject: Re: [cti-cybox] CybOX Object Selection I don’t have any examples of it being used today, but I would imagine that reporting on an AS that is used for malicious hosting (e.g., for malware) would be a viable use case. ZeusTracker [1] and others provide this information today, just not in STIX/CybOX.
Based on the twigs model, this could notionally be represented as:
Malicious_Infrastructure (AS) -> (Hosts) -> Asset (URI)
Regards,
Ivan
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, February 4, 2016 at 6:46 AM To: Patrick Maroney <Pmaroney@Specere.org> Cc: Bret Jordan <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>, Paul Patrick <ppatrick@isightpartners.com>, Trey Darley <trey@soltra.com> Subject: Re: [cti-cybox] CybOX Object Selection My point still stands however. Gentlemen, In a safe world where everyone plays by the rules, your arguments would be sound. In the real world where malicious actors do not play by the rules (and in fact aggressively exploit the fact that we lack imagination about such things), we (the people defending our networks and interests) have to capture, retain, and potentially share all of the details of the "truth on the ground" at the time of exploitation. Issues around exploitation of Internet protocols like BGP, IS <> IS route aggregation, etc. are well understood by those who deal with Nation State Adversaries and other sophisticated malicious actors. Google the term "bgp routing exploit" if you require publicly available evidence to accept this assertion. There is much that is not in the public domain. The same assertions can be made for things like DNS, Whois registration, etc. It's fine if you want to make the provision of such details optional. However, please do not remove our ability to fully describe these objects in a shared standardized construct. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Wed, Feb 3, 2016 at 4:32 PM -0800, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote: I would agree.. I do not see the need for duplication of data. If an analyst wants to look it up, the UI tool they are using should provide that functionality. But there is no reason to encode that and send that in STIX. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Sorry it seems like I am harping on such a minor point - I just really don't get the use case for the object... 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 ---
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
[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]