Re: [cti-cybox] CybOX Object Selection

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

My point still stands however.

If there is a legitimate case for describing a threat POSED by an AS - if you want to publish a threat report saying "Data tagged with this AS number is suspicious", then that AS needs to be a top level IDable construct, that can be globally referenced - not just an attribute in Cybox.

Myself I would still like someone to provide a legitimate example of this being used in this way, in practice right now today, before it gets added to the standard as a theoretical.

-
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


Patrick Maroney ---02/04/2016 01:04:39 AM---Gentlemen, In a safe world where everyone plays by the rules, your arguments would be sound. In the

From: Patrick Maroney <Pmaroney@Specere.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Kirillov, Ivan A." <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "Paul Patrick" <ppatrick@isightpartners.com>, Trey Darley <trey@soltra.com>
Date: 02/04/2016 01:04 AM
Subject: Re: [cti-cybox] CybOX Object Selection

---

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."

On Feb 3, 2016, at 16:47, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:


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


<graycol.gif>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 ---


From:	"Kirillov, Ivan A." <ikirillov@mitre.org>
To:	"Trey Darley" <trey@soltra.com>, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
Cc:	cti-cybox@lists.oasis-open.org
Date:	Wed, Feb 3, 2016 2:54 PM
Subject:	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