At layer 1:
Wifi 802.11 protocols?
At Layer 2 I’d add:
ARP
DHCP
At Layer 3 I’d also add:
IPv6 (if its not already in there under IP)
ICMPv4
ICMPv6 (which is quite different so potentially needs its own extra attributes)
At Layer 7 it would be an option to add:
SSH (but I’m not sure how useful it will be)
There are also some other tunnelling protocols like GRE that could be useful, but we should probably just worry about them if people
ask for them. The stuff above is part of the common network technologies.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: Kirillov, Ivan A. [mailto:ikirillov@mitre.org]
Sent: Wednesday, 17 February 2016 4:56 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Casey, Eoghan CIV DC3/DCCI <Eoghan.Casey@dc3.mil>
Cc: cti-cybox@lists.oasis-open.org; Terry MacDonald <terry@soltra.com>
Subject: Re: [Non-DoD Source] RE: [cti-cybox] Network Connection Object Refactoring
Given today’s call, it sounds like we’ll be focusing on having a Network Connection Object that is more closely oriented towards the OSI model. Accordingly, does
anyone have thoughts on the minimum set of protocols/extensions that we MUST support for a CybOX 3.0 MVP? What would it take to characterize something like Zigbee in the future?
I’ll use my previous list as a strawman/starting point:
* Layer 1 extensions
* Ethernet physical
* Bluetooth
* Layer 2 extensions
* Ethernet
* Layer 3 extensions
* IP (partially represented in proposal)
* Layer 4 extensions
* TCP (partially represented in proposal)
* UDP
* Layer 7 extensions
* HTTP (based on existing HTTP Session Object)
* DNS (based on existing DNS Query Object)
Regards,
Ivan
From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, February 16, 2016 at 8:29 AM
To: "Casey, Eoghan CIV DC3/DCCI" <Eoghan.Casey@dc3.mil>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>,
Terry MacDonald <terry@soltra.com>
Subject: RE: [Non-DoD Source] RE: [cti-cybox] Network Connection Object Refactoring
Originally there ware attributes in the base object that assume IP and even TCP.. things like "Connection State" which is referring to TCP with values like ESTABLISHED, etc. It seems
those have been removed today, so that is good. However, the ASN fields are still present in the root object, which presume an IP protocol.
-
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
"Casey,
Eoghan CIV DC3---02/16/2016 10:40:15 AM---Jason, We are proposing a refactoring of the Network_Connection object for exactly the reasons you s
From:
"Casey, Eoghan CIV DC3/DCCI" <Eoghan.Casey@dc3.mil>
To:
Jason Keirstead/CanEast/IBM@IBMCA, Terry MacDonald <terry@soltra.com>
Cc:
"Kirillov, Ivan A." <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date:
02/16/2016 10:40 AM
Subject:
RE: [Non-DoD Source] RE: [cti-cybox] Network Connection Object Refactoring
Jason,
We are proposing a refactoring of the Network_Connection object for exactly the reasons you state. The proposed refactoring does not assume IP-based networking, but must fully support this common protocol. You will observe that the proposed refactoring
is designed with encapsulation in mind, and can represent Layer 1.
I encourage you to contribute an example along the lines you describe to see if you find any gaps/weaknesses in the proposed refactoring that require filling/strengthening.
Eoghan Casey
Chief Scientist
Defense Cyber Crime Center (DC3)
410-694-4329
Eoghan.Casey@dc3.mil
-----Original Message-----
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Tuesday, February 16, 2016 7:42 AM
To: Terry MacDonald
Cc: Kirillov, Ivan A.; cti-cybox@lists.oasis-open.org
Subject: [Non-DoD Source] RE: [cti-cybox] Network Connection Object Refactoring
You are making a big assumption there that the network connection is point-to-point and is using the IP protocol. Not all network protocols are point-to-point, many are broadcast or mesh.
I made some related comments on the doc - but my exec summary of this is, we need to stop thinking only about IP based networking. We have to be able to model CTI that happens over any protocol, For example what about an emerging threat that uses Zigbee,
how would I model that using this proposal? It would not align at all.
I believe the network object should start at Layer 1 and each protocol layer be extensions on top of that. Having assumptions that you are starting at Layer 3 (IP) is not a good starting place, it is way too limiting, and will result in us later on having
to craft things like "ZigbeeConnection" objects because we can't use the existing network connection.
-
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
Inactive hide details for Terry MacDonald ---02/16/2016 05:59:35 AM---A question.... a network connection is a communication reTerry MacDonald ---02/16/2016 05:59:35 AM---A question.... a network connection is a communication relationship between an initiator
and a recip
From: Terry MacDonald <terry@soltra.com>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 02/16/2016 05:59 AM
Subject: RE: [cti-cybox] Network Connection Object Refactoring Sent by: <cti-cybox@lists.oasis-open.org>
________________________________
A question.... a network connection is a communication relationship between an initiator and a recipient. The initiator service opens a network connection and is given a source port sends traffic from an IP address to the recipient. The recipient service
has separately created a listening port bound to one or more IP addresses on the listening device. The network connection is a connection between those two items at a particular time.
My question is… shouldn’t we represent a network connection as an initiator endpoint object and a recipient endpoint object and a connection object showing the communication between them as a connection between the IP/port combinations at either end?
In other words:
Initiating Service resides at 172.16.12.34 on TCP Port 24356, Recipient Service resides at 10.16.1.44 on TCP Port 80, Network connection is communication at a particular time between these two services.
This is slightly different to the proposal
https://docs.google.com/document/d/1k5cZiiOgo4WjXN2GLRZ0-1vO8wstKnPZLbjwlb23Hkg/edit# <https://docs.google.com/document/d/1k5cZiiOgo4WjXN2GLRZ0-1vO8wstKnPZLbjwlb23Hkg/edit#>
, as it would treat the endpoints as separate things, and would relate the two entities together independently
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "tcp",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"extended-properties": {
"state": {
"connection_state": "sf",
"overall_state": "established"
},
"packet": {
"initiator_packets": 14356,
"recipient_packets": 14326
"initiator_bytes": 35779,
"recipient_bytes": 935750,
}
}
},
{
"id": "object--2",
"type": "NetworkedService",
"extended-properties": {
"ipv4": {
"address": "172.16.12.34"
}
"tcp": {
"port": "24356"
}
},
{
"id": "object--3",
"type": " NetworkedService",
"extended-properties": {
"ipv4": {
"address": "10.16.1.44"
},
"tcp": {
"port": "80"
}
}
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "initiated_connection_from"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "received_connection_on"
}
]
}
Comments?
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com <mailto:terry@soltra.com>
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.
Sent: Tuesday, 16 February 2016 11:09 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: cti-cybox@lists.oasis-open.org
Subject: Re: [cti-cybox] Network Connection Object Refactoring
Sure, here it is:
https://docs.google.com/document/d/1k5cZiiOgo4WjXN2GLRZ0-1vO8wstKnPZLbjwlb23Hkg/edit?usp=sharing <https://docs.google.com/document/d/1k5cZiiOgo4WjXN2GLRZ0-1vO8wstKnPZLbjwlb23Hkg/edit?usp=sharing>
Please add any comments there; I know I definitely missed some as you had mentioned. Oh, and pardon any formatting issues - this was a direct copy of the rendered markdown.
Regards,
Ivan
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com <mailto:Jason.Keirstead@ca.ibm.com> >
Date: Monday, February 15, 2016 at 4:55 PM
To: Ivan Kirillov <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >
Cc: "cti-cybox@lists.oasis-open.org <mailto:cti-cybox@lists.oasis-open.org> " <cti-cybox@lists.oasis-open.org
<mailto:cti-cybox@lists.oasis-open.org> >
Subject: Re: [cti-cybox] Network Connection Object Refactoring
There was a substantial amount of feedback on this proposal on Slack a few weeks ago... many of which aren't captured.
Can this be re-posted somewhere we can comment directly on it, such as Google Docs? It would greatly help the discussion.
I don't really want to re-hash all of my slack chat comments over email (or on the phone)... but I can do that if needed...
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security <http://www.ibm.com/security> |
www.securityintelligence.com <http://www.securityintelligence.com/>
Without data, all you are is just another person with an opinion - Unknown
Inactive hide details for "Kirillov, Ivan A." ---02/15/2016 05:35:27 PM---All, Here is a community contributed proposal around "Kirillov, Ivan A." ---02/15/2016 05:35:27 PM---All, Here is a community contributed proposal around refactoring the Network Connection
Object and r
From: "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >
To: "cti-cybox@lists.oasis-open.org <mailto:cti-cybox@lists.oasis-open.org> " <cti-cybox@lists.oasis-open.org
<mailto:cti-cybox@lists.oasis-open.org> >
Date: 02/15/2016 05:35 PM
Subject: [cti-cybox] Network Connection Object Refactoring Sent by: <cti-cybox@lists.oasis-open.org <mailto:cti-cybox@lists.oasis-open.org> >
________________________________
All,
Here is a community contributed proposal around refactoring the Network Connection Object and related Objects:
https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Network-Connection-Object-Refactoring <https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Network-Connection-Object-Refactoring>
The main points around this refactoring are:
1. The hierarchy around Network Objects would be replaced with an extension-based approach (as with the File Object) that revolves around the “base” Network Connection Object
1. A base set of properties common to all network connections would be defined
2. Existing layer 7 Objects (HTTP Session and DNS Query) would be become extensions
3. The Network Flow Object would likely be split up into its components (e.g, YAF log, Netflow log, etc.), each of which would be an extension
4. New extensions for common Network Connection properties, e.g., port, state and packet statistics, would be added
2. Connections to destination/source IP addresses would be defined via relationships
3. The existing Socket Address Object would be deprecated, as given the specification of IP addresses via relationships and the new port Network Connection Object extension it will no longer be necessary
We plan on discussing this (at least these high-level points) during tomorrow’s working session.
Regards,
Ivan