Re: [sacm] [mile] iodef:SoftwareType

["Adam W. Montville" <[e-mail]>]

All:

It’s come to my attention that there is such a thing as the “ENUM Registry” (I honestly didn’t know it existed), which has caused some confusion outside of our working groups [1].  

Because we now have a named registry, it may be better to call it by that name or some variant thereof (Security External Enumeration Registry - SEER).  

Regards,

Adam


[1] https://en.wikipedia.org/wiki/Telephone_number_mapping <https://en.wikipedia.org/wiki/Telephone_number_mapping>


> On Mar 26, 2015, at 11:20 AM, Roman D. Danyliw <[e-mail]> 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