CybOX 3.0: Address Object Refactoring

Issue Description

The existing Address Object in CybOX is very abstract, and supports the capture of a wide variety of network addresses (IPv4, IPv6, MAC, ATM, Email, etc.). This can cause ambiguity in address expression, such as an email address with an "address_type" value of "ipv4". Likewise, it means that fields in other CybOX Objects that make use of this Object are not constrained to a particular type of address, leading to issues of semantic accuracy (see below).

Existing Address Object Usage

The existing Address Object is currently used in the following places, thus notionally allowing any type of address supported by the Object to be used. Ideally, these fields should be restricted to a specific type or types of address in order to be semantically accurate, as noted below.

Object	Field	Necessary Restriction
ARP Cache	IP_Address	Should be restricted to an IPv4/IPv6 address.
DNS Record	IP_Address	Should be restricted to an IPv4/IPv6 address.
Email Message	From	Should be restricted to an email address.
Email Message	Sender	Should be restricted to an email address.
Email Message	Reply_To	Should be restricted to an email address.
Email Message	X_Originating_IP	Should be restricted to an IPv4/IPv6 address.
Email Message	Recipient	Should be restricted to an email address.
HTTP Session	From	Should be restricted to an IPv4/IPv6 address.
Network Flow	Nexthop_IPv4_Addr	Should be restricted to an IPv4 address.
Network Flow	Router_Next_Hop_IP	Should be restricted to an IPv4/IPv6 address.
Network Flow	Vlan_ID_MAC_Addr	Should be restricted to a MAC address.
Network Flow	Reverse_Vlan_ID_MAC_Addr	Should be restricted to a MAC address.
Network Packet	Destination_MAC_Addr	Should be restricted to a MAC address.
Network Packet	Source_MAC_Addr	Should be restricted to a MAC address.
Network Packet	Sender_Hardware_Addr	Should be restricted to a MAC address.
Network Packet	Sender_Protocol_Addr	Should be restricted to an IPv4/IPv6 address.
Network Packet	Recip_Hardware_Addr	Should be restricted to a MAC address.
Network Packet	Recip_Protocol_Addr	Should be restricted to an IPv4/IPv6 address.
Network Packet	Target_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	Target_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	Target_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	Dest_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	Link_Layer_MAC_Addr	Should be restricted to a MAC address.
Network Packet	Src_IPv4_Addr	Should be restricted to an IPv4 address.
Network Packet	Dest_IPv4_Addr	Should be restricted to an IPv4 address.
Network Packet	Src_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	Dest_IPv6_Addr	Should be restricted to an IPv6 address.
Network Packet	IP_Address	Should be restricted to an IPv4 address.
Network Packet	Address_Mask	Should be restricted to an IPv4 address.
Network Packet	Address_Mask	Should be restricted to an IPv4 address.
Network Packet	IPv6_Addr	Should be restricted to an IPv6 address.
Network Route Entry	Destination_Address	Should be restricted to an IPv4/IPv6 address.
Network Route Entry	Origin	Should be restricted to an IPv4/IPv6 address.
Network Route Entry	Netmask	Should be restricted to an IPv4/IPv6 address.
Network Route Entry	Gateway_Address	Should be restricted to an IPv4/IPv6 address.
Socket Address	IP_Address	Should be restricted to an IPv4/IPv6 address.
System	IP_Gateway_Address	Should be restricted to an IPv4/IPv6 address.
System	IP_Address	Should be restricted to an IPv4/IPv6 address.
System	Subnet_Mask	Should be restricted to an IPv4/IPv6 address.
System	DHCP_Server_Address	Should be restricted to an IPv4/IPv6 address.
WHOIS	IP_Address	Should be restricted to an IPv4/IPv6 address.
WHOIS	Email_Address	Should be restricted to an email address.
WHOIS	Email_Address	Should be restricted to an email address.

Refactoring - New Objects

Based on the requirements for characterizing network addresses derived from the existing CybOX Objects (as described above), it's clear that we require Objects that can characterize the following:

• IPv4 Addresses
• IPv6 Addresses
• MAC Addresses
• Email Addresses

There is also a need in certain Objects to capture either IPv4 or IPv6 addresses. However, given the refactoring of relationships between Objects to be represented via separate entities versus embedded Objects, there is no longer a need for a separate Object to capture this.

IPv4 Address Object

Supports capturing ONLY IPv4 addresses and netmasks.

Notional Implementation

IPv4AddressObject

Field Name	Type	Description	Accepted Syntax
type	string	The mandatory type of the object; fixed to "ipv4address-object".	n/a
ip_address	string	A single IPv4 address value.	CIDR OR IP address (implicit /32 CIDR block)

Examples

{
    "type": "ipv4address-object",
    "ip_address" : "192.168.1.1/32"
}

IPv6 Address Object

Supports capturing ONLY IPv6 addresses and netmasks.

Notional Implementation

IPv6AddressObject

Field Name	Type	Description	Accepted Syntax
type	string	The mandatory type of the object; fixed to "ipv6address-object".	n/a
ip_address	string	A single IPv6 address value.	CIDR OR IP Address (implicit /128 CIDR block)

Examples

{
    "type": "ipv6address-object",
    "ip_address" : "FE80:0000:0000:0000:0202:B3FF:FE1E:8329/128"
}

MAC Address Object

Supports capturing ONLY MAC addresses.

Notional Implementation

MACAddressObject

Field Name	Type	Description	Accepted Syntax
mac_address	string	A single MAC address value.	EUI-48 (hyphen delimited)

Examples

{
    "mac_address" : "01-23-45-67-89-ab-cd-ef"
}

Email Address Object

Supports capturing ONLY email addresses.

Notional Implementation

EmailAddressObject

Field Name	Type	Description	Accepted Syntax
email_address	string	A single email address value.	Full (local + domain)

Examples

{
    "email_address" : "[email protected]"
}

Other Address Objects

Besides those mentioned above, the existing Address Object supports characterizing the following types of addresses:

• ASN
• ATM
• IPv4 Netmask
• IPv6 Netmask

Accordingly, the question stands as to whether we should create new Objects for these address types. This revolves primarily around netmasks; the AS Object already captures AS numbers, and the likelihood of ATM addresses being exchanged using CybOX seems very low (though let us know if we're wrong!).

Given that a netmask is implicit in CIDR notation, this may not be necessary; it's also worth considering if netmasks are ever characterized and exchanged in a standalone capacity, or only as part of another Object (which is already the case in several CybOX Objects).

Impact

The direct impact of implementing this proposal is that the Address Object would be deprecated, several new Objects would be created, and accordingly each Object that currently uses the Address Object would need to updated to use the newly created Objects. Also, any existing use of the Address Object in Indicator sharing implementations (i.e. using STIX) would have to be updated to use one or more of the new address-related Objects.