Re: [sacm] Review Request: Endpoint Posture Collection Profile

Adam Montville <> Fri, 11 January 2019 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 968721200D7 for <>; Fri, 11 Jan 2019 14:16:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7GJslQYY8WK for <>; Fri, 11 Jan 2019 14:16:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4BAB1200B3 for <>; Fri, 11 Jan 2019 14:16:29 -0800 (PST)
Received: by with SMTP id v23so14491963otk.9 for <>; Fri, 11 Jan 2019 14:16:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=0FaAVsFWsskS5AgmXJcTUai57ZYKypAVsKkx13uKUKE=; b=kC+uGEhp9yhvxlamC3dYI/9Ra+iSWWOrdXTLPf+ncjHVSptA+UIyOmhQXV6eq1BOtM OJSZkw+yds9ZvZu/yooKo5fSunvbdA+mqaToeL22J4lQ7xv/1f59Xfp803KoHAtkGgqh YMh0VrmapmlnnGKYHc54WRAf7V8zNBzgIxhy+mnUqT5rNHNfC0R9o1GsaYrRLvk8iqfP jcoYXoYZ/UOz+8I7Ns7CpvfkciTuHqhbWsCscM4X+c7k1fWoJq9r2iVnKymETSM/3F/2 xBMxXQ0kUFO3Q6Tp1mUlfe0Jnj2cD6QSrlQ2KiJD5w0jRM7GfpV+LFvLOYp/2HjiJHrm isNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=0FaAVsFWsskS5AgmXJcTUai57ZYKypAVsKkx13uKUKE=; b=ocPlBt6mHZrmrRsVF9imkH2baPjp+qayr8pSvnuJ9kWUo7ZFsMZz2MCLKeXbQKYH7v QQOzygTpsSgT7iTrTnvHTNyZ7LzJQIawa1CpKgsUrDQmbNsW6gDv0PTVuBZYk24Wexh4 e40ljn2pe/SfSMQAPGrZHmYJ8ibc/T6AQIbmcCukZhR31Y2mRYFavU2/FXx+WNwg11NC wxfZ4rqJp0WJJd7Cea2Wx47oQEbw9gIV72iW/Ax8hBzxJOLh9jhjsyvXIJFnm0f4xevg 6K84/j3JLekEaDoJUiwVS4k1GFjuWxdzZiltCRDwTfsi04Kc3Y4tAF59jgyLTyAWjFYp IOLg==
X-Gm-Message-State: AJcUukfCk2iQKBLBHYX2/KFQA+lNWapsnJd3S8z5SPfK0QsbAXcOaOAH +2UFOdByUb7RzdC/1qvBhReYQOwu
X-Google-Smtp-Source: ALg8bN4XUhmgTlDAp+K2FYCDo2UHu+1HIXCvn5JDwFGWp6SaVyyAzoTjKxfeyQD9z34lbO727/Iw6w==
X-Received: by 2002:a9d:3d0:: with SMTP id f74mr10451222otf.52.1547244988353; Fri, 11 Jan 2019 14:16:28 -0800 (PST)
Received: from afv.lan ( []) by with ESMTPSA id l9sm34685249otj.9.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jan 2019 14:16:27 -0800 (PST)
From: Adam Montville <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FA35F61-4725-40C2-BADA-0BB1019E6797"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 11 Jan 2019 16:16:26 -0600
References: <>
To: "<>" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [sacm] Review Request: Endpoint Posture Collection Profile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Jan 2019 22:16:32 -0000

Hello (again) all:

The following is a list of comments regarding this draft - thanks to Bill Munyan for his many contributions to all this (items are numbered for identification, not for order of importance):

1. The draft may benefit from additional content, perhaps in the Introduction, that describes the increasing granularity of the sections in the draft. What has always seemed to be difficult is grasping how the abstract turns into the specific in this draft (part of this may be the nature of "wordy people" (Jess' words, not mine!)). The reality of this draft is that it addresses an abstract architecture consisting of a posture manager and an endpoint-resident posture collection engine connected by a protocol. The draft seems to dance around making a statement about the paradigm it embraces: Limit collection access to a specific set of systems, so that all the downstream components need not "hit" each endpoint (something that can be catastrophic in large enterprises).

The draft then goes on to talk about what implementations ought to do in Section 5; the draft then goes into actual implementations in Section 6. For first-time readers of this draft, concisely stating the abstract and pointing to Sections 5 and 6 respectively could go a long way toward decreasing the learning curve. Further, the NEA EPCP implementation requires further specification of particular poster collectors and validators, for example, Section 6.1.5, which describes the SACM SWAM extension. It would be easy to fit YANG push into the abstract notion presented in EPCP as well.

What the previous paragraph intends to convey is that the Endpoint Posture Collection Profile could, in theory, be applied in a variety of different ways. For example, we could create an OVAL extension to NEA EPCP. In theory, given some assumptions regarding the second item below, we could create a new implementation for remote command output collection (i.e. via SSH). While it is true that this last potential implementation doesn't support event-driven collection - it does, however, recognize that there are many remote collection solutions available today and it would be helpful to bring them along on this SACM ride.

Thought for consideration: Should these different levels of abstraction be split out into separate drafts?

2. In Section 5, it seems that there ought to be normative language, and the working group ought to figure out what that normative language ought to be. For example, implementations MUST, SHOULD, or MAY provide for which of each of the transactions set forth in this section? (Provisioning, discovery and validation, event-driven collection, querying, data storage, data sharing). Given the number of tools presently available in the marketplace operating on a remote (i.e. non-endpoint-resident) basis, it seems reasonable that the event-driven collection ought to be a MAY or a SHOULD.

3. In each of the EPCP descriptions - from abstract to implementation - the Posture Manager is expected to store collected information in a repository and provide unspecified interfaces to that repository. Further, an unspecified interface is expected to exist for unspecified administrative actions. It still feels that these interfaces need to be more descriptive. 

4. Section 1.7 states that posture information belongs to the enterprise. From time to time it may be the case that some personally identifying information is itself or is part of or is metadata to the collected information. While there may be no reasonable expectation to privacy on enterprise-owned systems, it seems that indicating such information belongs to the enterprise is somehow a bolder claim.

Up next (sometime soon-ish), how this all might fit in the SACM Architecture.

Kind regards,


> On Jan 10, 2019, at 7:45 AM, Adam Montville <>; wrote:
> Hello all:
> Given the holidays and USG shutdown, I thought I'd try to take care of some of the actions that came out of our virtual interim. From the notes that Bill Munyan took, there were several actions that needed to be taken. One of which is a call for additional review on this draft: <>
> I am submitting comments by the end of this week, and encourage others to do the same.
> Bill and I will also be submitting our thoughts as to how this draft jives with the present architecture draft.
> Kind regards,
> Adam