Proposal: Add Location structure for Observables

Status: Open
Comment Period Closes: TBD
Affects Backwards Compatibility: No
Relevant Issue: https://github.com/CybOXProject/schemas/issues/16

Background Information

This proposal concerns the ability to associate a geolocation with a given CybOX Observable. Numerous use cases for CybOX require the ability to associate a location with a given Observable and CybOX currently lacks the capability to do so. Given the diversity of relevant use cases, adding a location capability will need to support a diversity of types of location information and will need to be asserted in association with a range of constructs (Events, Actions and Objects) within CybOX. In addition, CybOX should avoid reinventing the wheel and attempt to identify and leverage existing approaches for specifying location information that have established community (including beyond the cyber security community) acceptance. Finally, recognizing that no single approach will always work for all use cases, CybOX should leverage the same abstract extension approach leveraged elsewhere in CybOX to enable the flexibility of using alternate location encodings.

Identified needs for geolocation expressivity include:

• Address ** Number ** Street ** Post Code
• Geographic region
• Country (name and/or code)
• State
• City
• Locality (e.g. Pudong)
• General location descriptor (e.g. Laguardia Airport or Central Park)
• Freeform descriptor
• Lat-Long
• Alternate coordinate systems
• URL reference to map

Proposal

Add a LocationAbstractType to cybox_common to serve as a basis for specifying particular geolocation data structures. LocationAbstractType will include @id and @idref attributes and a Name element for asserting a very simplistic location name without additional structure.

Add a new location folder under extensions containing a new ciq_address_3.0.xsd file. Add a CIQAddress3.0InstanceType (within ciq_address_3.0.xsd file) which extends LocationAbstractType with a Specification element of AddressType from the OASIS CIQ v3.0 standard. OASIS CIQ was selected because it offers expressivity for the range of identified required location constructs, significant extensibility for future growth, is already used within the STIX language and has a broad basis of community acceptance.

Add a Location element to EventType, ActionType and ObjectType of LocationAbstractType to enable asserting location information with a given Event, Action or Object. In addition, also add a Location element to MeasureSourceType. This, in combination with the proposed solution to issue #79 (Change multiplicity on Observable_Source to capture multiple observations/sightings of a given Observable) would enable the assertion of location information in association with multiple sighting reports of the same Observable. This should be accompanied by suggested practice documentation stating that when multiple Observable_Source entries with different Location elements exist for a given Observable that the location information should only exist within the Observable_Source constructs and not within the underlying Events, Actions or Objects constructs of the Observable to avoid confusion or conflict.

An example of a simple location assertion for an IP address could look like the following:

<cybox:Observable>
        <cybox:Object>
            <cybox:Properties xsi:type="AddressObj:AddressObjectType" category="ipv4-addr">
                <AddressObj:Address_Value>192.168.0.5</AddressObj:Address_Value>
            </cybox:Properties>
            <cybox:Location xsi:type="cybox-ciq:CIQAddress3.0InstanceType">
		<cybox-ciq-:Specification>
			<xal:Country><xal:NameElement @NameCode="US" @NameCodeType="iso-3166-2"/></xal:Country>
			<xal:Locality><xal:NameElement>New York City</xal:NameElement></xal:Locality>
			<xal:Premises><xalNameElement>Empire State Building</xalNameElement></xal:Premises>
		</cybox-ciq-:Specification>
            </cybox:Location>
        </cybox:Object>
    </cybox:Observable> >

Impact

There is no expected compatibility impact. These changes record additional information beyond what was possible to represent in previous versions of CybOX. Because the fields are optional, both producers and consumers who are not interested in the information contained in this field may ignore it.

Requested Feedback

1. Is there value in adding Location information for Observables?
2. Is the list of identified needs for geolocation expressivity adequate or are there other expressivity needs?
3. Is the flexible abstract extension approach (where CIQ Address is a default but not the only possible implementation) useful?
4. Is adding Location to EventType, ActionType, ObjectType and MeasureSourceType adequate?
5. Are there any issues with leveraging CIQ AddressType as a default Location implementation?