Re: [sacm] [mile] iodef:SoftwareType

[Gunnar Engelbach <[e-mail]>]

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.


On 3/26/2015 12:20 PM, Roman D. Danyliw wrote:
> (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 [[e-mail]] on behalf of Jerome Athias [[e-mail]]
> Sent: Wednesday, March 25, 2015 5:16 PM
> To: Wolfkiel, Joseph L CIV DISA ID (US)
> Cc: Gunnar Engelbach; MILE IETF; [e-mail]
> Subject: Re: [mile] [sacm] iodef:SoftwareType
>
> 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?)
>
> 2015-03-25 22:00 GMT+01:00 Wolfkiel, Joseph L CIV DISA ID (US)
> <[e-mail]>:
>> 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
>> [phone]
>> [e-mail]
>>
>>
>>
>> -----Original Message-----
>> From: Jerome Athias [mailto:[e-mail]]
>> Sent: Wednesday, March 25, 2015 4:28 PM
>> To: Wolfkiel, Joseph L CIV DISA ID (US)
>> Cc: Gunnar Engelbach; Adam W. Montville; MILE IETF; [e-mail]
>> Subject: Re: [sacm] iodef:SoftwareType
>>
>> 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.
>>
>>
>>
>>
>>
>> 2015-03-25 20:50 GMT+01:00 Wolfkiel, Joseph L CIV DISA ID (US)
>> <[e-mail]>:
>>> 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
>>> [phone]
>>> [e-mail]
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: sacm [mailto:[e-mail]] On Behalf Of Gunnar Engelbach
>>> Sent: Wednesday, March 25, 2015 3:14 PM
>>> To: Adam W. Montville; MILE IETF
>>> Cc: [e-mail]
>>> Subject: Re: [sacm] iodef:SoftwareType
>>>
>>>
>>> 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:
>>>> 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
>>>> _______________________________________________
>>>> sacm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm