Proposal: Add Location structure for Observables

Status: Closed
Comment Period Closes: 12/19/2013
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:

Needed Expressivity
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 an additional 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.

The table below identifies mapping of fields provided within CIQ Address3.0 to the identified expressivity needs:

Needed Expressivity	CIQ Address Representation
Address
* Number	PostalDeliveryPoint
* Street	Thoroughfare
* Post Code	PostCode
Geographic region	FreeTextAddress/AddressLine (Type)
Country (name and/or code)	Country/NameElement ; Country/NameElement[@NameCode]
State	AdministrativeArea[@Type]/NameElement
City	AdministrativeArea[@Type]/NameElement
Locality (e.g. Pudong)	Locality
General location descriptor (e.g. Laguardia Airport or Central Park)	Premises
Freeform descriptor	FreeTextAddress/AddressLine (Type)
Lat-Long	LocationByCoordinates
Alternate coordinate systems	GeoRSS
URL reference to map	GEORSS/link

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 Observable_Location (to specify a location for the Observable) and Observation_Location (to specify the location of the observation measurement) elements 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><xal:NameElement>Empire State Building</xal:NameElement></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?