Subject: [sacm] iodef:SoftwareType

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 25 Mar 2015 13:42:31 -0500

I’m cross-posting to SACM because this is a relevant discussion to that WG also.

During today’s MILE session we discussed some options with respect to iodef:SoftwareType.  The room seemed to favor looking for a way to allow referencing software using more than one software identification mechanism.  It was also acknowledged that SACM might find use in being able to use different mechanisms of software identification.

It could be easy enough to submit a given specification/data feed for expert review to the ENUM registry.  But, is this sufficient for our software identification needs?

The potential issue is how the software identification will be relied upon downstream. If we want to take the software identification component at face value, then using the ENUM registry would likely be sufficient.  If, however, we need to specifically interpret or specifically apply portions of the software identification component, we need more information about (or a priori knowledge of) how to handle that type of software identification component.

Perhaps it’s sufficient to rely on encapsulating the software identification element in another construct, which could potentially make this a non-issue.  For example, if we needed installation information for applicability, we could bundle the SoftwareType within a larger class which would have any corresponding information (e.g. exact location of the software on an endpoint) required for the particular case.  

Still, for cases (if they exist) where a fully specified software identification component is intended to be used to identify a broader software class, we may run into underspecification issues.  The same is true where a software identification component intended to classify software is needed for instance-level identification.

It seems that some cases of software identification would require specification over and above that which would be obtained by simply using the ENUM registry.

Thoughts?

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 25 Mar 2015 15:13:33 -0400

As you say, it depends on the usage for the software identifier.

For SACM that usage isn't likely to go beyond determining applicability 
because when it comes time to do the security checks then the policy 
implementation is likely to specify the particular endpoint attributes 
to be collected and not rely on any data associated with the software 
identification.

It seems obvious to me that, with the goal of being able to support 
multiple software identification systems, that SACM would embed the raw 
identifier information below a tag that indicates which identifier type 
it is.

As far as applicability checking goes, I can see two primary principles:

1) Avoiding false negatives
2) Efficiency

Presumably a check system that has the ability to collect endpoint 
attributes and calculate security results from that also has the ability 
to self-determine its own applicability.  With that as a fallback, then 
the worst case is that every policy is attempted to be applied to every 
endpoint and execution halted for each found to self-determine 
non-applicability.

Following from all that, if the decision point where policy assessment 
assignment is occurring is capable of parsing a particular software 
identifier well enough to positively remove a particular policy from the 
list of potentials, that should suffice.

At first glance, this is not a very interoperable approach.  But from a 
practical usage standpoint the goal isn't to be perfect, it's to reduce 
resource utilization for security assessments below the threshold where 
it affects business operations.  I think it likely that the number of 
formats necessary to achieve that will be fairly small.  And adding 
support for new ones relatively simple.

--gun

On 3/25/2015 2:42 PM, Adam W. Montville wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 25 Mar 2015 19:50:55 +0000

We write most of our policies to the individual application level, but generally don't go to version.  If the MILE requirement includes the ability to specify to a given software instance on a particular device and you think the softwareType element needs to be able to deal with both constructs, then you'll definitely need the ability to handle different levels of granularity and be able to specify which type of identification you're making.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Wednesday, March 25, 2015 3:14 PM
To: Adam W. Montville; MILE IETF
Cc: [email-masked]
Subject: Re: [sacm] iodef:SoftwareType

--gun

---

From: Jerome Athias <[email-masked]>
Date: Wed, 25 Mar 2015 21:28:17 +0100

Hi,

using CPEs, for example, in this case would be ok since using the
first part of it (application 'name', before the version - or with
'*') could cover the use case. (for SWID, I don't know)
Then, that's right that if we want, for MILE,  to cover use cases like
Policy P1 (e.g. CIS X Level 1) for Application A1 on Asset A1, and
Policy P2 (e.g. CIS X Level 2) for Application A1 (the same) on Asset
A2, etc.
it's a different story (ID, UID, GUID, context...)
Same for use cases where Software S1 + Software S2 is an issue, but
not when S1 used without S2, etc.
(context/groups)

A model for Software/Application/Components (e.g. libraries) and
combinations of/relationships between them would have to provide the
granularity wanted/needed.
But this could be covered step by step.

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Wed, 25 Mar 2015 21:00:53 +0000

I expect the MILE use case would also need to be able to deal with software for which the only available data is the name of a file and an execution path (e.g. "c:/program files/baddexec.jar").  This is out of the CPE case altogether, but would be critical to assist in either forensic analysis or malware detection.  

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
(301) 225-8820

-----Original Message-----
From: Jerome Athias [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2015 4:28 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Gunnar Engelbach; Adam W. Montville; MILE IETF; [email-masked]
Subject: Re: [sacm] iodef:SoftwareType

Hi,

---

From: Jerome Athias <[email-masked]>
Date: Wed, 25 Mar 2015 22:16:25 +0100

so that would be better covered by OVAL (with CPE embedded), and/or
some kind of MITRE MAEC (YARA included)/CybOX capabilities (mutex and
in memory opcodes needed?)

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 26 Mar 2015 16:20:37 +0000

(Reposting to SACM already on MILE)
Hello!

The original thread on the MILE list [1] about iodef:SoftwareType, this thread, and an illuminating offline explanation by Adam Montville and Dave Waltermire, highlighted an important distinction as we consider how to reuse the existing information models.  There is a difference between (a) an identifier into an enumeration; and (b) a blob which is the entirety of the information.  In both (a) and (b), a reference to the underlying specification is necessary.

The ENUM [2] draft provides support for (a).  The current iodef:SoftwareType of RFC5070bis [3] supports neither.  Section 4.4 of IODEF-SCI [4] supports both (a) and (b).  The caveats for using IODEF-SCI for (b) is that the blob has to be XML.  Likewise, the approach for (a) uses the @ContentID attribute and/or the now replaced iodefv1:Reference class (It was replaced by ENUM and Takeshi Takahashi, the editor, has noted this needs to be updated after 5070bis is complete in an earlier posting to this thread).

Support for multiple approaches to identifying software was voiced several times.  The two most actively discussed options were CPE and swid.  CPE is an instance of (a) and swid is an instance for (b).  

Thinking through the needs, the representation for software should:
(1) support (a) and (b)
(2) support public extensions (with an IANA registry) and private approaches
(3) blobs in formats other than XML?
(4) support the ability to convey the configuration of the software? 
(5) ability to reason about software at different levels of versioning (x.x.x vs. x.x.* vs. x.*.*)?
others?

To the notion of public extensions in (2), which IANA registry should be used?  IODEF-SCI uses a single registry for a collection of classes that are semantically different.  Should a dedicated registry(ies) be used to track standards/formats that describe software?  If a dedicated registry is not used, how should implementers know which of the entries in the registry are valid software description standards/formats?

Roman

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01660.html
[2] draft-ietf-mile-enum-reference-format-14
[3] draft-ietf-mile-rfc5070-bis-11
[4] RFC 7203

________________________________________
From: mile [[email-masked]] on behalf of Jerome Athias [[email-masked]]
Sent: Wednesday, March 25, 2015 5:16 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Gunnar Engelbach; MILE IETF; [email-masked]
Subject: Re: [mile] [sacm] iodef:SoftwareType

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 Mar 2015 15:37:56 -0400

There's a third type of software identifier, suitable for applicability 
testing in SACM:  self-determining.

In this type of identifier, a small set of attributes are collected from 
the endpoint and the value of these attributes are used to determine if 
a particular policy applies to that endpoint or not. This, in fact, 
represents the majority usage of CPE.  In this usage, the CPE identifier 
just refers to an executable function, the results of which determine 
applicability of the benchmark that references it.

For applicability testing, the needs are quite different than your list 
below, and I haven't yet seen anything related to SACM creating a 
requirement beyond applicability testing.  Except for your need number 
five:  that is valid for applicability testing.

A couple other notes, for what it's worth:

A CPE isn't just an identifier into an enumeration, the various parts 
have meanings.  The type of component it refers to, vendor, product, 
language, product version.  A bare CPE string still has utility, even 
without reference to an enumeration or a self-determination function.  
It's biggest drawback is that the content of any component in the string 
is largely non-deterministic.

Usage of a SWID, on the other hand, doesn't have to be as an XML blob.  
It has an identifier which can be used as a lookup for that XML blob.  
The SWID identifier, however, is an arbitrary string that can't be 
relied on to provide any other information, so it's only useful if a 
lookup is performed.

That is, CPE is both (a) and (b), as are SWIDs.