Section 3.1.1 Posture Assesment Information Provider

[jimsch]

version -03

In paragraph 3 - The sharing of things spontaneously seems to be problematic from an authorization point of view. It is one thing to provide data asynchronously from a previous request, where the authorization can have already been checked and another to just start arbitrarily sending data to somebody. I realize that the latter matches, to a large degree, the case of a Posture Collector sending data to an initial Posture Consumer, but it might be well to separate these two cases deal with them separately. Are there other cases for the second case that I have missed?

In paragraph 3 - I think you mean based on the former rather than the latter. Authorization restrictions would be based on the consumer not the provider.

In paragraph 5 - A Provider which is not authorized to provide information does not seem to be a very useful concept. I suggest deleting "and further, be authorized to do so" you might add to the end "and for specific consumers"

[llorenzin]

Spontaneous / unsolicited publication is required to enable loose coupling of consumers and providers (i.e., so that consumers and providers don't require a priori knowledge of each other). Providers must be able to publish spontaneously to support use cases where endpoint posture changes. This could apply to a policy server publishing user authentication information (logon / logoff), endpoint security software reporting changes in endpoint compliance state (real-time AV protection disabled), network sensors observing traffic indicating endpoint compromise (IPS or behavior monitor seeing unauthorized traffic), etc. Controllers can still apply authorization policies to unsolicited publications.

-----Original Message-----
From: Jim Schaad [mailto:notifications@github.com]
Sent: Tuesday, July 07, 2015 9:34 PM
To: sacmwg/draft-ietf-sacm-architecture
Subject: [draft-ietf-sacm-architecture] Section 3.1.1 Posture Assesment Information Provider (#19)

version -03

In paragraph 3 - The sharing of things spontaneously seems to be problematic from an authorization point of view. It is one thing to provide data asynchronously from a previous request, where the authorization can have already been checked and another to just start arbitrarily sending data to somebody. I realize that the latter matches, to a large degree, the case of a Posture Collector sending data to an initial Posture Consumer, but it might be well to separate these two cases deal with them separately. Are there other cases for the second case that I have missed?

In paragraph 3 - I think you mean based on the former rather than the latter. Authorization restrictions would be based on the consumer not the provider.

In paragraph 5 - A Provider which is not authorized to provide information does not seem to be a very useful concept. I suggest deleting "and further, be authorized to do so" you might add to the end "and for specific consumers"

—
Reply to this email directly or view it on GitHub #19 . https://github.com/notifications/beacon/AKcH1cIpdIpLIr8QSmDD_T3ztg9Xz-8yks5obJ-3gaJpZM4FUH0n.gif

[llorenzin]

Resolution - expand third paragraph to two paragraphs - one addressing unsolicited / spontaneous publication, the second dealing with requested publication.
A consumer may ask any request; a provider may choose not to respond, or to respond with a subset of information.
P5 comment - no change

[llorenzin]

Henk - unsolicited could be an ongoing event stream in SIEM domain, would like to include this kind of processing of information
notifying about changes of attributes, crossing thresholds
LL - add as an example

[ncamwing]

I've reworked the 3rd paragraph and taken Jim's suggestion to clean up the 5th paragraph as well....updated in v05 draft.