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

From: Adam Montville <[email-masked]>
Date: Thu, 10 Jan 2019 07:45:40 -0600

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: https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/>

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

---

From: Adam Montville <[email-masked]>
Date: Fri, 11 Jan 2019 16:16:26 -0600

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,

Adam

> On Jan 10, 2019, at 7:45 AM, Adam Montville <[email-masked]> wrote:
> 
> Hello all:
>