Re: [cti-cybox] CybOX Object Selection

["Kirillov, Ivan A." <ikirillov@mitre.org>]

After discussion on this topic during today’s working meeting, I think we came to agreement on the following:

1) To move forward on the CybOX 3.0 development and Object refactoring, we’re going to use the current set of agreed to Objects as the “baseline” for those that will be included in 3.0. Accordingly, we’ve updated the CybOX 3.0 draft spec [1] with this list, and have also tried to make explicit those Objects which won’t be making the cut.

2) Any Objects suggested for inclusion in the future will only be considered if the requesting party agrees to do the necessary work with regards to their refactoring, JSON schema generation, etc

.

3) We need to develop/formulate the process for users who wish to use other, non-standard Objects, such as those that won’t be included as part of the official 3.0 release. This is important so that we do not hinder the communities who have a need for the use of such Objects.

Also, we need to make a final determination on the Objects currently marked as “maybe” as to whether they’ll make the cut. My thoughts are as follows:

• AS
  • Comments: this one is pretty basic, and there are some relevant use cases around associating IP addresses with ASN’s, so I would err on including it.
• Code:
  • Comments: this one is mostly used to describe malicious code snippets in MAEC. Since these are really just strings, the Code Object adds some metadata about programming language, etc. I could go either way on this one.
• Custom
  • Comments: this is a very basic object (just key/value pairs) and we’ll likely still need the ability to define custom Objects in this fashion, so I would err on including it.
• Device
  • Comments: if we’re going to be refactoring the System Objects, Device is likely going to a part of this effort, so I would err on including it.
• Disk Partition:
  • Comments: this one falls into the disk forensics bucket, along with things like Volume which are not slated for inclusion, so I think it would make sense to refactor them all at the same time. Therefore, I would err on the side of not including it in the 3.0 release.
• Product:
  • Comments: if we’re going to be refactoring the System Objects, Product is likely going to a part of this effort, so I would err on including it.
• Semaphore/Win Semaphore
  • Comments: these are very basic Objects, but relevant primarily for some rather esoteric malware analysis use cases. I would err on the side of not including them for the 3.0 release, and instead include them in a malware-analysis centered minor release.
• SMS Message:
  • Comments: if we’re going to be refactoring the Email Message Object as part of a new “base” Message Object, it would make sense to include SMS Message as part of this effort, so I would err on including it.
• User Account:
  • Comments: we’d likely have to refactor the other Account Objects in conjunction, which are not slated for inclusion in 3.0, so I would err on the side of not including it.
• User Session:
  • Comments: this Object is rather ambiguous (what kind of session does it it refer to? a browser session, etc.?) so unless we figure out exactly what it is intended to represent, I would err on not including it.
• X509 Certificate:
  • Comments: this Object is used only in a CybOX utility, though its structure is well understood and there are some relevant use cases around it such as digital binary signing. Therefore, I would err on the side of including it.

[1] https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.wvnupljz2z6u

Regards,

Ivan

From: 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)

[1] https://zeustracker.abuse.ch/monitor.php?as=1101

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.

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