cyboxproject / schemas Goto Github PK

We should update the annotation for the File_Path element in the File Object to state that it can contain the name of the file along with the path to it. I would change it to

The File_Path field specifies the path to the file, including the file name but not 
including the device. Whether the path is relative or fully-qualified can be specified 
via the 'fully_qualified' attribute of this property.

Break out Domain from the URI object and create its own object to allow better specificity and flexibility.

The element has an attribute named @type. It also has child elements of <Defined_Object>, <Domain-specific_Object_Attributes>, and <Custom_Attributes>. All four of these fields relate to the expression of detailed information about a particular Object instance. Currently, however, there is some confusion relative to the intent of these structures:

• There is an intent that ad-hoc attributes (<Custom_Attributes>) not be intermingled with schema-defined attributes (<Defined_Object, and <Domain-specific_Object_Attributes>). The schema, however, does not prevent this.
• The type attribute is intended to characterize ad-hoc attributes and is not intended to be used with schema-defined attributes. The type attribute name does not clearly indicate this purpose, and the fact that it is restricted to a list of enumerated values is actually somewhat antithetical to this use.

It has been requested that ObjectType be revised to more clearly indicate and follow the language intent.

We should add support for the abstract capture of file fingerprints, such as those derived from function signatures or other means.

The RelationshipsType in CybOX Core is rather ambiguously named; it actually only deals with Action-Action relationships, so it should be renamed to ActionRelationshipsType for clarity.

We need to add object schemas for characterizing some of the document object formats. Current proposed formats include:

-PDF
-DOC
-PPT
-XLS
-SWF (FLA, F4V)
-SCR
-CHM
-Generic/flexible XML construct for Office 2007+, openDoc, etc. formats

Create a TPM Object that can indicate PCR state, enabled flags, and changes thereto. This would be a new ObjectPropertiesType implementation that would go under the objects directory.

This began with this STIX 1.0 issue: STIXProject/schemas#11

The Layer4ProtocolType and Layer4ProtocolEnum in Port_Object.xsd and Network_Connection_Object.xsd could possibly be combined and moved to a common reference schema.

It is proposed that the <Stateful_Measure> element be eliminated from the CybOX language and instead would be promoted to be a direct child of . The @has_changed attribute would be moved to be an attribute of the element.

This reduces the number of XML levels necessary to describe Objects using CybOX. As such, it represents a simplification of the CybOX language.

Create an ObjectPropertiesType implementation for the representation of Directory information. It is possible that this has integration with the File Object. This would be a new schema under the objects directory.

Depends on #315

Add ability to express ordered and unordered sets of observables with or without
temporal windows/relationships.

For example, it would be helpful to express the temporal relationships between observed events and the creation/modification/removal/etc. of other observables.

CybOX currently uses xs:dateTime and cyboxComon:DateTimeObjectPropertyType to store datetime information. DateTimeObjectPropertyType does not constrain values to xs:dateTime formats or enforce the use of timezone information, which is often essential when communicating cyber observable information.

Community members have identified the need to store more granular datetime information such as timezones information, which is not currently enforced by schema.

Pattern restricting the fields in schema may not be possible due to the CybOX patterning capability requirements (a regex does not conform to the xs:dateTime format), so we may just need to provide guidance on how best to store datetime information in both schema annotations and the specifications.

URL_Label of the version 1.0 Link_Object should be of type cyboxCommon:StringObjectPropertyType. Currently the field is defined as an xs:string which leaves out the ability to represent standard cybox conditions on the field.

We should think about adding support for characterizing files that may masquerade as other files. E.g. a PE file masquerading as a JPG.

We currently can't capture useful email attachment characteristics like the MIME Type, so we should consider restructuring the Email Message Object to support these entities. Another possibility would be to create a separate Email Attachment Object (based upon the File Object) to capture this data.

Linux_Package_Object has a fairly limited ArchitectureTypeEnum, distinct from CodeObj:ProcessorTypeEnum. System_Object has its own ProcessorArchEnum, distinct from (though identical to) CodeObj:ProcessorTypeEnum. Again, a centralized enum would be easier to maintain.

Currently these are all required which prevents you from utilizing @Trend as intended (without specific rate, unit and scale values).

Currently they explicitly call out "this cyber observation source instance" when in reality the type is used throughout CybOX and STIX to represent time for many things.

Consider adding file hash information to ImageInfoType under ProcessObjectType to supplement path and file system information. This would allow to be able to convey hash information in single observable rather than having to associate a related file element and hash.

The Socket Address Object is currently at version 1.0, yet it sits in the "2.0" folder on the CybOX website:

http://cybox.mitre.org/XMLSchema/objects/Socket_Address/2.0/Socket_Address_Object.xsd

We should it move it to "1.0" to accurately correspond with its version.

On many constructs in cybox there is both an id and an idref. When using an idref an id MUST not be specified, and the element's value should be empty. This needs to be documented in the cybox schema

It would be useful to keep track of the name of the parent process as part of the Process Object, so we should add it to the next version of the Process Object.

It would be useful to keep track of the name of the children spawned by the process as part of the Process Object, so we should add it to the next version of the Process Object.

The Link Object is missing XSD annotations; we should add them.

The EffectTypeEnum enumeration, found in cybox_core.xsd can potentially be converted into a controlled vocabulary, and moved into cybox_default_vocabularies.xsd.

This change would require the creation of a EffectTypeVocab implementation of the ControlledVocabularyStringType within cybox_default_vocabularies.xsd.

Changing EffectTypeEnum to a controlled vocabulary would require changes to DefinedEffectType in cybox_core.xsd. Currently, DefinedEffectType leverages the EffectTypeEnum for its effect_type attribute. This attribute would be converted to an element of type cyboxCommon:ControlledVocabularyStringType. The annotations should make mention of the newly created EffectTypeVocab, ControlledVocabularyStringType implementation.

We need to add the ability to capture character encodings for strings and other relevant element datatypes, as well as any custom encodings that may be used. This would likely be accomplished by adding several corresponding attributes to the *ObjectAttributeTypes, e.g.,

FileObj:File_Name encoding="custom" custom_encoding="wideutf16"

In Windows Registry keys, the hive is the very first portion of the key. Thus, for consistency, we should move the Hive element in the Windows Registry Key Object to come before the Key element.

We should investigate the addition of an object for characterizing Address Resolution Protocol (ARP) cache entries.

Browser/URL history can be useful for serving as an indicator of malware presence, among other things. We should investigate adding such an object, preferably one that can be applied across many different browsers.

Modify the Network_Connection object such that where it currently offers a single option of Destination_Socket_Address, it would offer a choice of three destination types (Socket_Address, Domain and URL).

This would enable more flexible specification of instance and patterns where the connection is primarily to a Domain or URL and not to a known IP/Port pairing.

The need for this has come out of mapping exercises of real-world content from various community stakeholders.

We should add Android-based objects, such as an Android APK object. There are likely new action names that need to be added as well, such as 'Start Broadcast Receiver.'

Linux_Package_Object has a fairly limited ArchitectureTypeEnum, distinct from CodeObj:ProcessorTypeEnum. While these clearly serve separate purposes, having them in different XSD files will make it harder to ensure that they are up-to-date. Speaking of which, ArchitectureTypeEnum could do with i586, i686, x64_64, and armel - all architectures used in Linux packages. There may even be alpha and m68k boxes still out there.

STIX defines an EncodedCDATAType for all fields that are intended to store CDATA blocks. It could be beneficial to have a analogous data type defined in CybOX, as it could be easier to identify fields (in code) that require the application and/or removal of CDATA wrappers.

It currently is required (exactly one), should be 0..1.

Currently, the CybOX platform structure is explicitly bound to the use of CPE through a set of custom elements largely mimicking the NIST CPE dictionary from the National Vulnerability Database. This is not adaptable to the use of other platform naming schemes and structures and ends up being fairly heavyweight for CPE support. Adoption of a more flexible and simpler scheme for identifying platforms has been recommended.

The cybox schema does not currently require ids to be unique and they are intended to be unique within a given xml instance. When making this change, schema documentation also needs to be updated to state that ids MUST be unique.

The 'type' attribute of URIObjectType is fixed to "URL". The 'fixed' constraint should be removed.

HTTP_Request_Response/HTTP_Client_Request/HTTP_Request_Line/HTTP_Method/@datatype should be optional, currently it is required.

CybOX uses the xs:dateTime datatype to represent time information, which has an optional offset to indicate the timezone. Currently, behavior is not deterministic when the timezone offset is not present: is the time a local time, UTC time, or something else?

CybOX needs to either require the presence of an explicit timezone specification on all timestamps or to specify the expectation for what the timezone is when it isn't specified on the timestamp.

We currently have characterizations of HTTP and DNS network objects, but there are other Layer 7 objects that we should add support for, including:

*IRC
*SMTP
*FTP
*NetBIOS
*POP3
*IMAP

The StructuredTextType type, used primarily in elements, is a highly structured object, including sub-elements for titles, code, comments, images, and basic text, as well as the ability to group such structures into "blocks".

While this structure is useful for some cases, it has been observed to be overly cumbersome for many other uses. Moreover, the structures are not widely used in the general community, and thus do not represent standardized practices.

It has been proposed that this structure be simplified and brought more in line with community practice.

Create a new ObjectPropertiesType implementation for the representation of a Zip file. This would be a new schema under the 'objects' directory.

It says you should use the URIObjectType when the LinkObjectType would be a better fit.

Right now the Process Object has its own method for defining the characteristics of the file associated with the process memory image; we should consider using the File Object for this, both for consistency and expressivity since at the moment we can't capture basic properties like hashes in the image info.

There is use in storing physical, geolocation information about assets/observables. We need to investigate where this information would be best stored, and how best to use this information.

In many cases, length fields are specified as PositiveInteger or UnsignedLong types, but in other cases they are specified as mere Integer types. Presumably the Integer ones are there because a malicious data source could put a negative number in there with the intent of inducing an overflow.

The <Observable_Composition> element is used to define logical combinations of elements. Currently, the permissible operations, defined by the OperatorTypeEnum are AND, OR, and NOT.

It has been observed that the meaning of the NOT operation is currently ambiguous when there is more than one operand (i.e., child element): is the intended meaning NAND or NOR?

The annotations in all Object elements/attributes should be looked over and updated for consistency; it looks like there are places where we refer to 'properties' instead of 'fields' (e.g., in the PEHeadersType in the Win Executable File Object) etc.

Currently CybOX uses the xs:dateTime datatype to represent timestamps, which requires precision down to the second.

In many cases, however, precision for a time is only available to the minute, day, or even month. In these cases, it would be desirable to have a way to express that precision to avoid implying that a timestamp is more precise than it actually is.