Re: [sacm] [mile] iodef:SoftwareType

"Roman D. Danyliw" <rdd@cert.org> Thu, 26 March 2015 16:20 UTC

Return-Path: <rdd@cert.org>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E521A8799 for <sacm@ietfa.amsl.com>; Thu, 26 Mar 2015 09:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqV6gMOGgy5E for <sacm@ietfa.amsl.com>; Thu, 26 Mar 2015 09:20:49 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7190A1A7D82 for <sacm@ietf.org>; Thu, 26 Mar 2015 09:20:42 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t2QGKfRU012790 for <sacm@ietf.org>; Thu, 26 Mar 2015 12:20:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1427386841; bh=LrgGuNzRgs/4guyRcQDZx7ryzqgUVoKSu6nStRl6sAg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=did4T1qNkaiTvJR5cUUx6MSIWQ5YsOAQAPS4OSbvzuqSQtzvG41q1leXKt1uqsXAJ g3eNfs3mnLDChl/XjoSP5lFedDgiP4G5VtrQ5yGqkswSGAG3312p/A9VX62nxr6EfZ loekrkkFBaqLBJZNhfTdwab+lHEsEBBJqSjr5e90=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t2QGKdIq016695 for <sacm@ietf.org>; Thu, 26 Mar 2015 12:20:39 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Thu, 26 Mar 2015 12:20:38 -0400
From: "Roman D. Danyliw" <rdd@cert.org>
To: "sacm@ietf.org" <sacm@ietf.org>
Thread-Topic: [mile] [sacm] iodef:SoftwareType
Thread-Index: AQHQZzM6OYsvKLLE3Uu52UVsls50KZ0tphjigAANgVSAAT879Q==
Date: Thu, 26 Mar 2015 16:20:37 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD93D88B0@marathon>
References: <B551AB38-A9E5-48C0-8049-F44122AF24AE@gmail.com> <551308DD.4040908@ThreatGuard.com> <9F61CC8E6ED7BC4DBA90C13F25D29C002DA5752B@umechpanz.easf.csd.disa.mil> <CAA=AuEdcmXdCe+iUfgLN3wnp98MZnNw5ULMmKnk+5wdrOA=Zmg@mail.gmail.com> <9F61CC8E6ED7BC4DBA90C13F25D29C002DA57678@umechpanz.easf.csd.disa.mil>, <CAA=AuEcBh3s6Hbkj_4G-OQCyGHHF0QkbusRXGbSWoatwgCtt=Q@mail.gmail.com>
In-Reply-To: <CAA=AuEcBh3s6Hbkj_4G-OQCyGHHF0QkbusRXGbSWoatwgCtt=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sacm/NxVU2BL_gPPdC8qx6Jaa78n6gr0>
Subject: Re: [sacm] [mile] iodef:SoftwareType
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 16:20:52 -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 [mile-bounces@ietf.org] on behalf of Jerome Athias [athiasjerome@gmail.com]
Sent: Wednesday, March 25, 2015 5:16 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Gunnar Engelbach; MILE IETF; sacm@ietf.org
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)
<joseph.l.wolfkiel.civ@mail.mil>:
> 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
> Joseph.L.Wolfkiel.civ@mail.mil
>
>
>
> -----Original Message-----
> From: Jerome Athias [mailto:athiasjerome@gmail.com]
> Sent: Wednesday, March 25, 2015 4:28 PM
> To: Wolfkiel, Joseph L CIV DISA ID (US)
> Cc: Gunnar Engelbach; Adam W. Montville; MILE IETF; sacm@ietf.org
> 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)
> <joseph.l.wolfkiel.civ@mail.mil>:
>> 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
>> Joseph.L.Wolfkiel.civ@mail.mil
>>
>>
>>
>> -----Original Message-----
>> From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Gunnar Engelbach
>> Sent: Wednesday, March 25, 2015 3:14 PM
>> To: Adam W. Montville; MILE IETF
>> Cc: sacm@ietf.org
>> 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
>>> sacm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sacm
>>
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile