Product Object Refactoring

[ikiril01]

Although the existing Product Object is intended to characterize software or hardware products, it has a few semantic inconsistencies in this regard:

• Several fields, such as Edition and Language, are largely specific to software.
• The Device_Details field is intended to capture device-specific details of the product through the use of the Device Object. However, the Device Object contains several fields that may have semantic overlaps with those in the Product Object. For instance, the Vendor field in the Product and Manufacturer field in the Device could both be used to capture the name of the company that produced the Product/Device.

Accordingly, it may make sense to relegate the Product Object to just characterizing software and the Device Object to just hardware. This would entail deprecating the Device_Details field and otherwise leaving the object the same.

[athiasjerome]

I concur with the observations.
I am ok for Product-Software and Device-Hardware.
Note that a Device is a Product (so could the Device Class/Object could inherit from Product)

To go further: Vendor and Manufacturer could (MUST imho) be "Asset" Objects. By that, I mean that Vendor and Manufacturer are Organization or Person (or group of). Use of something like NISTIR 7693 would be of great benefit... (e.g. A Product's Vendor could be a STIX Information_Source, or an OVAL Definition Producer, etc.)

Note for later: a Component Object will help to define relationships for both Products' Components (e.g.: files, libraries, DLLs, etc.) and Devices' Components (e.g.: motherboard, processor, chip, SIM card, etc.)

[ikiril01]

@athiasjerome thanks for the feedback! I think Assets are something that is being covered by STIX, though there's obviously overlap here.

[ikiril01]

Also, one suggested possibility for the refactoring of the Product Object into the new "Software Product" Object would be to use the SWID schema as a basis: http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd

If we do take this approach, we'd have to determine which fields from SWID make sense in CybOX, and which do not.

Update: Some suggested fields from SWID

• SoftwareIdentity.name – string product name
• SoftwareIdentity.tagID – guid for the tag, useful as proxy ID for the product
• SoftwareIdentity.version – product version
• Entity.name, Entity.regid, Entity.role
• If we want to capture digital signature info, perhaps Entity.thumbprint
• Meta.colloquialVersion, Meta.edition, Meta.product, Meta.revision