softwareClass does not support softwareDependencies

[athiasjerome]

As per current softwareClass, and as indicated in CIM_SoftwareIdentity Version 2.28.0 "Note that ConcreteIdentity can also be used to describe the relationship of the software to any LogicalFiles that result from installing it. As above, there may not be sufficient detail or instrumentation to instantiate this association.":
I suggest also adding CIM_SoftwareElement

[athiasjerome]

somehow close to applicationComponent

[djhaynes]

Hi Jerome,

It sounds like you would like to add an IE to the softwareInstance IE that allows for the specification of files associated with a piece of installed software. For example, if you run "rpm -ql " on a Linux system, it will display the files that were installed on the system as part of the specified rpm. Is that correct?

Also, can you be more specific about "adding the CIM_SoftwareElement"?

Thanks,

Danny

[athiasjerome]

That is correct.
Files (and their versions (or hashes)) that compose a software/package/application would be needed to be known/identified in some cases for automation.
e.g. https://github.com/CISecurity/OVALRepo/pull/775/files

I am not aware (after years of researches) of any proper model in any reviewed standards/interchange format for softwares' IEs that is complete enough/well designed for covering the automation use cases. (i.e. missing in CVRF)
While the recently introduced softwareClass IE is derived from the CIM model, I suggested to reuse the CIM_SoftwareElement part of this model to extend the softwareClass while I identified it as being the closest element in the CIM model to what i would like to be modeled.

Kindly don't hesitate to let me know if that is unclear

[djhaynes]

Would it be enough to include an absolute file path and the versions/hashes could be looked up at a later point in time? Or, does that information need to be embedded in the SoftwareInstance IE?

So, I think it is okay that the softwareInstance IE doesn't support everything in CIM_SoftwareIdentity (or any other DM for that matter) because DMs may support IEs beyond those specified by the IM. We also want to be careful not to make IM IEs so specific that they preclude the use of DMs because they can't implement the IE. For example, we wouldn't want to use the CIM_SoftwareIdentity version property because it is fairly restrictive and would not accommodate version strings used to describe RPM and DPKG software on Linux among others. With all that said, if there are certain properties that seem generally applicable that should be included, I would like to hear your's and others' thoughts on them.

[athiasjerome]

I understand and agree with the keep it simple here.
It is important to have a relationship with a SoftwareInstance and Files.
(could it be libraries files (e.g. OpenSSL), and the version of these files (could it be binaries/so other softwareInstances) will be important to be known during the automation process)

This does not need a complex DM (CIM_SoftwareIdentity was just suggested for interoperability)

[djhaynes]

Thanks for the clarification Jerome. Do you think adding a filepath attribute would be sufficient to address this gap? Also, do others have thoughts on this?

[athiasjerome]

filepath could be obtained from SWID, but unknown for custom softwares/applications

So I would recommend filename+version couples to cover libraries (binaries/components that are not really SoftwareInstance)
NB: this will be easily highlighted when validating using CVEs

Example of illustration: Figure 2, Page 4 (Bins/Libs) of NIST SP 800-190 (DRAFT)
http://csrc.nist.gov/publications/drafts/800-190/sp800-190-draft.pdf
See also 4.2.1 (and 4.3.1) Page 21

[djhaynes]

Hi Jerome,

Should we just add a "library" value to the softwareClass enumeration and add the filepath IE to the softwareClass IE? If not, could you please propose a new IE using the format described in the IM?

Thanks,

Danny

[athiasjerome]

Your "library" approach is an option yes, and this will allow covering more use cases than currently, so yes.

Reminder however of the importance of the attributes version/epoch/hash
e.g. http://lists.cisecurity.org/pipermail/oval_developer_lists.cisecurity.org/Week-of-Mon-20170417/000222.html

In the future we would have to cover another one which is for software of type website (e.g. web admin interface of a device (so not really a firmware), and web applications (not really server/desktop softwares) where the -software's components/dependencies- (quite equivalent to "libraries" from a model point of view) are: software artifacts (understand source code/files like web pages (e.g. .php, .aspx pages, JavaScript, or .py, .rb, etc.)

To cover all of this, a softwareComponent class would be more generic (from a model and semantic point of view), where a softwareComponent/Dependency could be a library or an artifact (so basically a file), which validates basically your filepath IE approach

[athiasjerome]

Oracle Critical Patch Updates Advisories illustrate the point about "Component" and "Sub-component"