CybOX 3.0: Network Connection Object Refactoring
Note: this proposal was submitted by a community member. Many thanks for their submission!
Currently, CybOX does not have a coherent model for representing network traffic, and has multiple objects to represent different aspects of network traffic, including Network_Connection, HTTP_Session, DNS_Query, Network_Flow, and Network_Packet.
Even with these various objects, CybOX currently cannot represent common network connection use cases. For example, the Network_Connection object does not include UDP (stateless network connections), and is not designed to represent tunneling (one network connection contained within another). Furthermore, elements in the Socket_Address and Network_Flow objects are could be represented more effectively as properties of the Network_Connection object.
Define a high-level Network Connection object with a set of shared properties for traits common to most network connections, and additional property packages for specific protocols and log types. In addition, elements currently in the Socket_Address, Network_Flow, HTTP_Session, and possibly DNS_Query objects could instead be represented as extensions of the Network_Connection object.
Basic, common characteristics of network connections that should be part of the Network_Connection Object are defined in the table below.
| Field | Datatype | Multiplicity | Comments/Examples |
|---|---|---|---|
Start_Time |
string | 0..1 | Replaces Creation_Time |
End_Time |
string | 0..1 | n/a |
Service |
string | 0..1 | TCP4, TCP6, UDP4, Teredo |
Connection_State |
string | 0..1 | SF, etc. |
Source_ASN |
number | 0..1 | n/a |
Destination_ASN |
number | 0..1 | n/a |
Overall_State |
string | 0..1 | ESTABLISHED, LISTENING, CLOSED, UNKNOWN, etc. |
Initiator_Bytes |
number | 0..1 | n/a |
Responder_Bytes |
number | 0..1 | n/a |
Tx_Packets |
number | 0..1 | n/a |
Rx_Packets |
number | 0..1 | n/a |
History |
string | 0..1 | Dd |
As with the File Object refactoring, the high-level model for the updated Network Connection is based on having a base set of properties with extension points for additional classes of properties.
The ports of a network connection could be represented as an extension of the Network_Connection object.
| Field | Datatype | Multiplicity | Comments/Examples |
|---|---|---|---|
src |
number | 0..1 | The source port for the network connection. |
dst |
number | 0..1 | The destination port for the network connection. |
Statistics about transmitted/received packets could be represented as an extension of the Network_Connection object.
| Field | Datatype | Multiplicity | Comments/Examples |
|---|---|---|---|
tx_packets |
number | 0..1 | The number of transmitted packets. |
rx_packets |
number | 0..1 | The number of received packets. |
Information about connection state could be represented as an extension of the Network_Connection object.
| Field | Datatype | Multiplicity | Comments/Examples |
|---|---|---|---|
connection_state |
string | 0..1 | The connection state with regards to the service/protocol specified in the service field. |
overall_state |
string | 0..1 | The overall state of the connection. |
Depending on the protocol used, properties could be included for both source and destination of the network connection. Future expansion of CybOX could use extensions to represent Virtual Private Network protocols that use layer 2 (data link), layer 3 (network), and/or layer 4 (transport).
Instead of the existing “Layer7_Connections” field within the Network Connection object, extensions could be used to represent specific application protocols such as HTTP. Such extensions could replace the separate existing layer 7 objects, such as HTTP Session. Additional extensions could include logging formats such as Netflow, Silk, and IPFIX to incorporate those currently covered in the Network_Flow object.
Employing the proposed extension model, any network protocol can be added to CybOX without having to update the Network Connection object to specifically represent additional protocols. Rather than specifying Layer7 Connections within the Network Connection object, CybOX can define encapsulated objects independently and then connect them to a Network Connection via a relationship. Furthermore, it would be possible to represent SSL/TLS independently, without being concerned with the duality of its operation at both layer 5 (session) and layer 6 (presentation). An added advantage of this approach is that application protocols defined in CybOX such as DNS Query can inherit general characteristics from the base Network Connection object such as Start_Time (instead of Date_Ran) and Service (instead of Service_Used).
To enable the Network Connection object to fulfill all current and future use cases, it is necessary to eliminate the Socket Address object. Instead, the elements currently represented in the Socket Address object would be extensions of or related to the Network Connection object. Specifically, the source and destination ports would be extended properties, and the source and destination IP addresses would be related objects. Examples of this in JSON are provided later in this document. Currently in CybOX, only the Network Connection and Netflow objects make use of the Socket Address object.
Given the above proposal, the Network Connection could subsume some of the fields that currently exist on the Network Flow object, as outlined in the below table.
| Network Flow Field | Comments/Changes |
|---|---|
Start_Time |
Deprecated; replaced with Start_Time from Network Connection |
End_Time |
Deprecated; replaced with End_Time from Network Connection |
Flow_Start_Milliseconds |
Deprecated; replaced with Start_Time from Network Connection |
Flow_End_Milliseconds |
Deprecated; replaced with End_Time from Network Connection |
Octet_Total_Count |
Deprecated; replaced with Tx_Bytes + Rx_Bytes from Network Connection |
Packet_Total_Count |
Deprecated; replaced with Tx_Packets + Rx_Packets from Network Connection |
Reverse_Octet_Total_Count |
Deprecated; replaced with Rx_Bytes from Network Connection |
Reverse_Packet_Total_Count |
Deprecated; replaced with Rx_Packets from Network Connection |
Src_Country_Code |
Deprecated; replaced with Source_Country_Code from Network Connection |
Dest_Country_Code |
Deprecated; replaced with Destination_Country_Code from Network Connection |
Byte_Count |
Deprecated; replaced with Tx_Bytes + Rx_Bytes from Network Connection |
Packet_Count |
Deprecated; replaced with Tx_Packets + Rx_Packets from Network Connection |
Src_Autonomous_System |
Deprecated; replaced with Source_ASN from Network Connection |
Dest_Autonomous_System |
Deprecated; replaced with Destination_ASN from Network Connection |
Accordingly:
- The Network Flow object will be used to represent elements that relate to specific network logging tools such as SiLK and IPFIX.
- To avoid inconsistency and confusion, the application layer information should be represented in one location, preferably as part of the Network Connection object, not in the Network Flow object. This includes fields such as
SiLKRecordType:Flow_Application.
A simple use case is representing the output of the netstat command.
{
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "tcp",
"extended-properties": {
"port": {"src": "5354",
"dst": "80"},
"state": {"overall_state": "established"}
}
},
{
"id": "object--2",
"type": "IPAddress",
"IPv4": "127.0.0.1"
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "192.168.1.34"
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "destination"
}
]
}Another common use case is representing a TCP/IP connection.
{
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "tcp",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"initiator_bytes": 35779,
"responder_bytes": 935750,
"extended-properties": {
"state": {
"connection_state": "sf",
"overall_state": "established"
},
"port": {
"src": "24678",
"dst": "80"
},
"packet": {
"tx_packets": 14356,
"rx_packets": 14326
}
}
},
{
"id": "object--2",
"type": "IPAddress",
"IPv4": "172.16.12.34"
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "192.168.1.34"
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "destination"
}
]
}Another common use case is representing a UDP connection.
{
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "udp",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"initiator_bytes": 357,
"responder_bytes": 9357,
"extended-properties": {
"port": {
"src": "24678",
"dst": "53"
},
"packet": {
"tx_packets": 3,
"rx_packets": 52
}
}
},
{
"id": "object--2",
"type": "IPAddress",
"IPv4": "172.16.12.34"
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "192.168.1.34"
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "destination"
}
]
}Another common use case is representing an ICMP (ping) connection.
{
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "icmp",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"initiator_bytes": 57,
"responder_bytes": 567,
"extended-properties": {
"packet": {
"tx_packets": 1,
"rx_packets": 1
}
}
},
{
"id": "object--2",
"type": "IPAddress",
"IPv4": "172.16.12.34"
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "192.168.1.34"
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "destination"
}
]
}The Network Connection object could contain an SSL object, which could in turn contain any application protocol, e.g., HTTP, FTP, etc.
{
"objects": [
{
"id": "object-1",
"type": "NetworkConnection",
"service": "tcp",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"initiator_bytes": 45779,
"responder_bytes": 1035750,
"extended-properties": {
"port": {
"src": "24678",
"dst": "8080"
},
"state": {
"connection_state": "sf",
"overall_state": "established"
},
"packet": {
"tx_packets": 24356,
"rx_packets": 6243
},
"HTTPSession": {
"version": "HTTP/1.1",
"domain_name": "www.mitre.org",
"http_client_request": "index.html",
"http_method": "GET",
"status_code": 200,
"reason_phrase": "OK"
}
}
},
{
"id": "object--2",
"type": "IPAddress",
"IPv4": "172.16.12.34"
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "192.168.1.34"
},
{
"id": "object--4",
"type": "x509Certificate",
"version": 3,
"serial_number": 1
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "destination"
},
{
"id": "relationship--3",
"type": "relationship",
"from": "object--1",
"to": "object--4",
"relationship_value": "uses"
}
]
}In order to represent tunneling such as PPTP or Teredo network activities in CybOX, there are several encapsulated objects.
Each network connection can be represented as an individual object, and any encapsulation can be represented using a “contains” relationship.
{
"objects": [
{
"id": "object--1",
"type": "NetworkConnection",
"service": "PPTP",
"start_time": "Jan 4, 2015 10:00",
"end_time": "Jan 4, 2015 10:15",
"initiator_bytes": 35779,
"responder_bytes": 935750,
"extended-properties": {
"port": {
"src": "2487",
"dst": "1723"
},
"state": {
"connection_state": "sf",
"overall_state": "established"
}
}
},
{
"id": "object--2",
"type": "NetworkConnection",
"service": "tcp",
"start_time": "Jan 4, 2015 10:01",
"end_time": "Jan 4, 2015 10:14",
"extended-properties": {
"port": {
"src": "24678",
"dst": "80"
},
"state": {
"connection_state": "sf",
"overall_state": "established"
},
"packet": {
"tx_packets": 14356,
"rx_packets": 14356
}
}
},
{
"id": "object--3",
"type": "IPAddress",
"IPv4": "172.16.12.34"
},
{
"id": "object--4",
"type": "IPAddress",
"IPv4": "192.168.1.34"
},
{
"id": "object--5",
"type": "IPAddress",
"IPv4": "192.168.1.54"
}
],
"relationships": [
{
"id": "relationship--1",
"type": "relationship",
"from": "object--1",
"to": "object--3",
"relationship_value": "source"
},
{
"id": "relationship--2",
"type": "relationship",
"from": "object--1",
"to": "object--4",
"relationship_value": "destination"
},
{
"id": "relationship--3",
"type": "relationship",
"from": "object--2",
"to": "object--3",
"relationship_value": "source"
},
{
"id": "relationship--4",
"type": "relationship",
"from": "object--2",
"to": "object--5",
"relationship_value": "destination"
},
{
"id": "relationship--5",
"type": "relationship",
"from": "object--1",
"to": "object--2",
"relationship_value": "contains"
}
]
}