Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] softwareClass does not support softwareDependencies (#76)

From: Danny Haynes <[email-masked]>
Date: Wed, 05 Apr 2017 10:35:36 -0700

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 <rpm-name>" 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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-291937882

---

From: Jerome Athias <[email-masked]>
Date: Wed, 05 Apr 2017 11:59:12 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-291961883

---

From: Danny Haynes <[email-masked]>
Date: Thu, 06 Apr 2017 07:14:12 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-292187417

---

From: Jerome Athias <[email-masked]>
Date: Thu, 06 Apr 2017 23:33:24 -0700

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)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-292453474

---

From: Danny Haynes <[email-masked]>
Date: Mon, 10 Apr 2017 06:28:55 -0700

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-292949207

---

From: Jerome Athias <[email-masked]>
Date: Wed, 12 Apr 2017 22:58:52 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-293789884

---

From: Danny Haynes <[email-masked]>
Date: Wed, 26 Apr 2017 09:01:31 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-297458862

---

From: Jerome Athias <[email-masked]>
Date: Fri, 28 Apr 2017 00:29:52 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/76#issuecomment-297928614