Subject: [sacm] SACM Requirement Simple Architecture

From: Trevor Freeman <[email-masked]>
Date: Fri, 14 Mar 2014 05:29:17 +0000

Hi Nancy,

We need an endpoint posture attribute collection service whose job is to collect the posture data from end points for SACM. That is a separate function from the evaluation of the posture data to interpret the state of the endpoint. There would most defiantly be a repository associated with the collection service where that captured data is stored. The interpretation of the data to deduce the endpoint state could be done real time as the data is acquired, or post acquisition as far as the architecture is concerned. You will need policy to determine what data to collect, and how often to collect it. If you were collecting event logs for example, you would likely be collecting them on a regular basis. How to interpret the posture attributes will also need policy from multiple sources. For example, the endpoint will likely have an update service so its software can be patched, there may also be an AV service which will be publishing regular updates. To evaluate therefore if a device is both patched and its av is current would need to know the current policy from the update and AV services. There may well be other services to collect policy data.

A posture attribute consumer can query the evaluation serve to find out its view of the endpoint state, or it may prefer to query the repository directly because it wants to make its own evaluation. The posture consumer may also query the repository for historical data about the endpoint. There is no reason to think the posture repository would only have the latest collection data. The collection process would be additive i.e. the new data would be appended to the existing data.   Conceivably a posture consumer may also set policy on what data to collect, e.g. if the collector was investigation a new incident indicator.

There is definite value in standardizing how the collection process is performed on the endpoint, and how the repository is queried by the consumer. I don't see much up side to trying to standardize how the collector stores the data in the repository, nor how the evaluator interacts with the collector or repository. We can, for the purpose of the architecture, consider them a box. Implementations are free to build them however they want.

Given the above I would draft the SACM simple architecture diagram slightly differently.

Trevor

.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 14 Mar 2014 09:17:41 +0300

+1

NB: that remembers me the CAESARS (Continuous Asset Evaluation, Situational
Awareness, and Risk Scoring) architecture

2014-03-14 8:29 GMT+03:00 Trevor Freeman <[email-masked]>:
> Hi Nancy,
>
>
>
> We need an endpoint posture attribute collection service whose job is to
> collect the posture data from end points for SACM. That is a separate
> function from the evaluation of the posture data to interpret the state of
> the endpoint. There would most defiantly be a repository associated with the
> collection service where that captured data is stored. The interpretation of
> the data to deduce the endpoint state could be done real time as the data is
> acquired, or post acquisition as far as the architecture is concerned. You
> will need policy to determine what data to collect, and how often to collect
> it. If you were collecting event logs for example, you would likely be
> collecting them on a regular basis. How to interpret the posture attributes
> will also need policy from multiple sources. For example, the endpoint will
> likely have an update service so its software can be patched, there may also
> be an AV service which will be publishing regular updates. To evaluate
> therefore if a device is both patched and its av is current would need to
> know the current policy from the update and AV services. There may well be
> other services to collect policy data.
>
>
>
> A posture attribute consumer can query the evaluation serve to find out its
> view of the endpoint state, or it may prefer to query the repository
> directly because it wants to make its own evaluation. The posture consumer
> may also query the repository for historical data about the endpoint. There
> is no reason to think the posture repository would only have the latest
> collection data. The collection process would be additive i.e. the new data
> would be appended to the existing data.   Conceivably a posture consumer may
> also set policy on what data to collect, e.g. if the collector was
> investigation a new incident indicator.
>
>
>
> There is definite value in standardizing how the collection process is
> performed on the endpoint, and how the repository is queried by the
> consumer. I don't see much up side to trying to standardize how the
> collector stores the data in the repository, nor how the evaluator interacts
> with the collector or repository. We can, for the purpose of the
> architecture, consider them a box. Implementations are free to build them
> however they want.
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 17 Mar 2014 17:49:41 +0000

Hi Trevor,

Thanks for providing this perspective!  Please see further questions comments below:

From: Trevor Freeman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 13, 2014 10:29 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: SACM Requirement Simple Architecture

Hi Nancy,

We need an endpoint posture attribute collection service whose job is to collect the posture data from end points for SACM. That is a separate function from the evaluation of the posture data to interpret the state of the endpoint. There would most defiantly be a repository associated with the collection service where that captured data is stored. The
interpretation of the data to deduce the endpoint state could be done real time as the data is acquired, or post acquisition as far as the architecture is concerned. You will need policy to determine what data to collect, and how often to collect it. If you were collecting event logs for example, you would likely be collecting them on a regular basis. How to interpret the posture attributes will also need policy from multiple sources. For example, the endpoint will likely have an update service so its software can be patched, there may also be an AV service which will be publishing regular updates. To evaluate therefore if a device is both patched and its av is current would need to know the current policy from the update and AV services. There may well be other services to collect policy data.
 [NCW]  I believe you are detailing a specific implementation of the Endpoint Assessment Use Case (e.g. Section 2.1 of draft-ietf-sacm-use-cases-06)…..agreed that these are things that need to be addressed by the things we standardize but what you describe is only one potential instantiation for the need to describe the set of posture attributes and "profile" that drives what posture attributes to collect (I am trying to distinguish this from "policy" as imho "policy" may be too vague for our purposes, as we have used terms like "configuration checklist", "endpoint characterization" and "checklist verification" in the use cases that would help drive 'what' attributes would need to be collected).

A posture attribute consumer can query the evaluation serve to find out its view of the endpoint state, or it may prefer to query the repository directly because it wants to make its own evaluation. The posture consumer may also query the repository for historical data about the endpoint. There is no reason to think the posture repository would only have the latest collection data. The collection process would be additive i.e. the new data would be appended to the existing data.   Conceivably a posture consumer may also set policy on what data to collect, e.g. if the collector was investigation a new incident indicator.
[NCW]  From a SACM perspective, the query requirement needs to be addressed whether the "provider" is an evaluator or a repository (or a system that couples both, or a system as you describe in your diagram that does collection, evaluation and storage).

There is definite value in standardizing how the collection process is performed on the endpoint, and how the repository is queried by the consumer. I don’t see much up side to trying to standardize how the collector stores the data in the repository, nor how the evaluator interacts with the collector or repository. We can, for the purpose of the architecture, consider them a box. Implementations are free to build them however they want.
[NCW] Not disagreeing that we need to address the collection progress, am just not sure we need to constrain it to "endpoint" only….agree that implementation (e.g. How the data is stored or how evaluator interacts with the collector or repository is in our scope).  Which is why, from SACMs scope, I distilled it to a simple interaction of a Provider who could provide:
 - a list of endpoint and their identifiers
 - provide "profiles" (e.g. The grouping list) of posture attributes that either need to be collected or evaluated
 - posture attribute values (marked by some filtering to address the use cases; e.g. Either by endpoint, list of endpoints or a combination of the endpoints and the "profiles")

To do the collection and facilitate the orchestration, we need to start with the information model, but we'll also need the data models, protocols and transports to instantiate the standards and ensure interoperability.  The charter states that we need to identify how what we standardize is distinct from other standards (like NEA and MILE and others outside the IETF)…..the simple architecture I drew was to first call out distinguishers from NEA….but obviously, we need to clarify this further.

Given the above I would draft the SACM simple architecture diagram slightly differently.
[NCW]  Can you help clarify from the provided architecture diagram what would be in scope for SACM?

Trevor

.

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 17 Mar 2014 14:30:01 -0400

Referring to this and other discussions we've had in the past, it seems 
that SCAM, at its lowest level, devolves into a set of discrete logical 
components.  These components are defined by what type of action 
requests they can handle and respond to.

A "collector", for example, accepts a request for system artifact(s) and 
responds with those data items (or accepts a request for change 
notification).  The collector might be an agent on an endpoint, a 
front-end for a CMDB, a proxy for an SNMP/NEA/etc link to endpoints, and 
so on.

Within this model there is a very wide diversity of how these components 
can be combined.

So my question is, at this point in the process, is there a consensus on 
whether there should be any restrictions on how these can be combined?

In any case, it seems that it help communicate the functionality of SACM 
if multiple architecture examples were available, but none of the 
existing documents seem like a good place for that.  Possibly in an 
architecture document, or somewhere else?

Also, while this might seem a bit soon in the process to be drawing such 
examples, I think in fact being able to visualize more examples would 
assist the rest of the process.

--gun

On 3/17/2014 1:49 PM, Nancy Cam-Winget (ncamwing) wrote:
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> function from the evaluation of the posture data to interpret the state
> of the endpoint. There would most defiantly be a repository associated
> with the collection service where that captured data is stored. The
>
> interpretation of the data to deduce the endpoint state could be done
> real time as the data is acquired, or post acquisition as far as the
> architecture is concerned. You will need policy to determine what data
> to collect, and how often to collect it. If you were collecting event
> logs for example, you would likely be collecting them on a regular
> basis. How to interpret the posture attributes will also need policy
> from multiple sources. For example, the endpoint will likely have an
> update service so its software can be patched, there may also be an AV
> service which will be publishing regular updates. To evaluate therefore
> if a device is both patched and its av is current would need to know the
> current policy from the update and AV services. There may well be other
> services to collect policy data.
>
>   [NCW]  I believe you are detailing a specific implementation of the
> Endpoint Assessment Use Case (e.g. Section 2.1 of
> draft-ietf-sacm-use-cases-06)…..agreed that these are things that need
> to be addressed by the things we standardize but what you describe is
> only one potential instantiation for the need to describe the set of
> posture attributes and "profile" that drives what posture attributes to
> collect (I am trying to distinguish this from "policy" as imho "policy"
> may be too vague for our purposes, as we have used terms like
> "configuration checklist", "endpoint characterization" and "checklist
> verification" in the use cases that would help drive 'what' attributes
> would need to be collected).
>
>
> A posture attribute consumer can query the evaluation serve to find out
> its view of the endpoint state, or it may prefer to query the repository
> directly because it wants to make its own evaluation. The posture
> consumer may also query the repository for historical data about the
> endpoint. There is no reason to think the posture repository would only
> have the latest collection data. The collection process would be
> additive i.e. the new data would be appended to the existing data.
>    Conceivably a posture consumer may also set policy on what data to
> collect, e.g. if the collector was investigation a new incident indicator.
>
> [NCW]  From a SACM perspective, the query requirement needs to be
> addressed whether the "provider" is an evaluator or a repository (or a
> system that couples both, or a system as you describe in your diagram
> that does collection, evaluation and storage).
>
> consumer. I don’t see much up side to trying to standardize how the
> collector stores the data in the repository, nor how the evaluator
> interacts with the collector or repository. We can, for the purpose of
> the architecture, consider them a box. Implementations are free to build
> them however they want.
>
> [NCW] Not disagreeing that we need to address the collection progress,
> am just not sure we need to constrain it to "endpoint" only….agree that
> implementation (e.g. How the data is stored or how evaluator interacts
> with the collector or repository is in our scope).  Which is why, from
> SACMs scope, I distilled it to a simple interaction of a Provider who
> could provide:
>   - provide "profiles" (e.g. The grouping list) of posture attributes
> that either need to be collected or evaluated
>   - posture attribute values (marked by some filtering to address the
> use cases; e.g. Either by endpoint, list of endpoints or a combination
> of the endpoints and the "profiles")
>
> To do the collection and facilitate the orchestration, we need to start
> with the information model, but we'll also need the data models,
> protocols and transports to instantiate the standards and ensure
> interoperability.  The charter states that we need to identify how what
> we standardize is distinct from other standards (like NEA and MILE and
> others outside the IETF)…..the simple architecture I drew was to first
> call out distinguishers from NEA….but obviously, we need to clarify this
> further.
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 17 Mar 2014 20:41:05 +0000

Hi Gunnar,

You raise an excellent question:
  So my question is, at this point in the process, is there a consensus on
  whether there should be any restrictions on how these can be combined?

[NCW] I had presumed that to be the case given the use case discussionsŠ.

Your suggestion to visualize especially the use cases would be
goodŠ.anybody
want to help with that?   I can try to start on this but may take me a
week or two
as my work schedule's full at the momentŠ.

	Nancy.

On 3/17/14 11:30 AM, "Gunnar Engelbach" <[email-masked]>
wrote:

>> draft-ietf-sacm-use-cases-06)Š..agreed that these are things that need
>> consumer. I don¹t see much up side to trying to standardize how the
>> am just not sure we need to constrain it to "endpoint" onlyŠ.agree that
>> others outside the IETF)Š..the simple architecture I drew was to first
>> call out distinguishers from NEAŠ.but obviously, we need to clarify this
>> further.
>>

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 19 Mar 2014 16:53:29 +0000

Hi Nancy,

No problem.

Hope this reply makes sense. I have been grabbing time between meeting to compose this.

Don't want you to feel that you are alone in this endeavor and that the dialog will help us all:)

From: sacm [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, March 17, 2014 10:50 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: [sacm] SACM Requirement Simple Architecture

Hi Trevor,

Hi Nancy,

We need an endpoint posture attribute collection service whose job is to collect the posture data from end points for SACM. That is a separate function from the evaluation of the posture data to interpret the state of the endpoint. There would most defiantly be a repository associated with the collection service where that captured data is stored. The
interpretation of the data to deduce the endpoint state could be done real time as the data is acquired, or post acquisition as far as the architecture is concerned. You will need policy to determine what data to collect, and how often to collect it. If you were collecting event logs for example, you would likely be collecting them on a regular basis. How to interpret the posture attributes will also need policy from multiple sources. For example, the endpoint will likely have an update service so its software can be patched, there may also be an AV service which will be publishing regular updates. To evaluate therefore if a device is both patched and its av is current would need to know the current policy from the update and AV services. There may well be other services to collect policy data.
 [NCW]  I believe you are detailing a specific implementation of the Endpoint Assessment Use Case (e.g. Section 2.1 of draft-ietf-sacm-use-cases-06).....agreed that these are things that need to be addressed by the things we standardize but what you describe is only one potential instantiation for the need to describe the set of posture attributes and "profile" that drives what posture attributes to collect (I am trying to distinguish this from "policy" as imho "policy" may be too vague for our purposes, as we have used terms like "configuration checklist", "endpoint characterization" and "checklist verification" in the use cases that would help drive 'what' attributes would need to be collected).
[TF] I am not wedded to the term policy as it often comes with the kind of baggage you describe, but the collection process does need input from a variety of sources on what posture attributes to collect. I also don't think configuration by itself cuts it. I think of configuration as a set of parameters necessary for the functioning of the service itself and therefore a matter for the local admin. This data set would be more dynamic.

A posture attribute consumer can query the evaluation serve to find out its view of the endpoint state, or it may prefer to query the repository directly because it wants to make its own evaluation. The posture consumer may also query the repository for historical data about the endpoint. There is no reason to think the posture repository would only have the latest collection data. The collection process would be additive i.e. the new data would be appended to the existing data.   Conceivably a posture consumer may also set policy on what data to collect, e.g. if the collector was investigation a new incident indicator.
[NCW]  From a SACM perspective, the query requirement needs to be addressed whether the "provider" is an evaluator or a repository (or a system that couples both, or a system as you describe in your diagram that does collection, evaluation and storage).
[TF] In your diagram, every evaluator has a repository so I am not sure of your distinction between evaluator and repository. The collected data will need to be stored so it can be proceed so every SACM posture attribute collection will have a repository of some form. I don't think that impacts the architecture.  Different instances of a SACM service may have a repositories of varying capacities. From an architecture perspective, this is all irrelevant.  Conceptually, the consumer can issue a query to the SACM service for either its evaluated option, or raw collection data. The SACM service may be unable to comply with the request for a variety of reasons. Maybe the repository is of limited capacity, maybe it has a large capacity but the service is new so has no data. Maybe because of policy (that word again I know).  The consumer will have to handle those cases. It cannot expect to have all its requests met.

There is definite value in standardizing how the collection process is performed on the endpoint, and how the repository is queried by the consumer. I don't see much up side to trying to standardize how the collector stores the data in the repository, nor how the evaluator interacts with the collector or repository. We can, for the purpose of the architecture, consider them a box. Implementations are free to build them however they want.
[NCW] Not disagreeing that we need to address the collection progress, am just not sure we need to constrain it to "endpoint" only....agree that implementation (e.g. How the data is stored or how evaluator interacts with the collector or repository is in our scope).  Which is why, from SACMs scope, I distilled it to a simple interaction of a Provider who could provide:
 - a list of endpoint and their identifiers
 - provide "profiles" (e.g. The grouping list) of posture attributes that either need to be collected or evaluated
 - posture attribute values (marked by some filtering to address the use cases; e.g. Either by endpoint, list of endpoints or a combination of the endpoints and the "profiles")
[TF] I agree we should have a short description for the typical cases. We also need to respond to new developments i.e. specify arbitrary attributes that need to be collected. Something the attribute by be explicitly defined, i.e. file in in this path, other times it would be more descriptive, i.e. all executables in this location. Sometimes the collector may be harvesting event and log data i.e. upload the file or files from this location or export the event log. These are all potential attributes of the posture.

To do the collection and facilitate the orchestration, we need to start with the information model, but we'll also need the data models, protocols and transports to instantiate the standards and ensure interoperability.  The charter states that we need to identify how what we standardize is distinct from other standards (like NEA and MILE and others outside the IETF).....the simple architecture I drew was to first call out distinguishers from NEA....but obviously, we need to clarify this further.

Given the above I would draft the SACM simple architecture diagram slightly differently.
[NCW]  Can you help clarify from the provided architecture diagram what would be in scope for SACM?
[TF] The SACM box in the diagram is meant to represent the logical set of services that SACM is defining based on the use cases.  The diagram is intended to show how those serves interact with external parties via standardized interfaces based on the use cases. For example,  interaction between the collector and the endpoint would be standardized via a protocol. The components within the box are free to interact with each other by whatever means the vendor wants.  It shows the posture consumer interacting with SACM repository, the repository could be a single or multiple physical services. It could be a file system or RDBS. I don't think SACM should care.  The same is true for the collection services.  While we know the services inside the box have to interact with each other, it's not clear we need to standardize those aspects based on the use cases. We assume implementers do whatever is appropriate and are free to offer a range of implementations to meet different markets.   This is a similar model LDAP for example where we have standardized the protocol for interaction with the service but it is an implementation detail on how the LDAP service stores it is data.

Trevor

.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 19 Mar 2014 13:19:11 -0400

Hi Nancy and Trevor,

This is a fascinating thread...

It seems that the word "policy" may be overloaded in this architecture
discussion.  So a suggestion:

"configuration" - scope is admin configuration of the SACM service itself
(as Trevor suggested and commonly used in IT)

"preferences" - scope is consumer choice of defaults and protocols for
interacting with the SACM service
(as commonly used in browsers and applications)

"policy" - scope is decision-making rules for the evaluation of collected
posture attributes
(as commonly used in AAA and other security topics)

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Mar 19, 2014 at 12:53 PM, Trevor Freeman <
[email-masked]> wrote:

> Don't want you to feel that you are alone in this endeavor and that the
> dialog will help us allJ
>
>
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Nancy
> Cam-Winget (ncamwing)
> *Sent:* Monday, March 17, 2014 10:50 AM
> *To:* Trevor Freeman
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] SACM Requirement Simple Architecture
>
>
>
> Hi Trevor,
>
>
>
> *From: *Trevor Freeman <[email-masked]>
> *Date: *Thursday, March 13, 2014 10:29 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *SACM Requirement Simple Architecture
>
>
>
> Hi Nancy,
>
>
>
> the endpoint. There would most defiantly be a repository associated with
> the collection service where that captured data is stored. The
>
> interpretation of the data to deduce the endpoint state could be done real
> time as the data is acquired, or post acquisition as far as the
> architecture is concerned. You will need policy to determine what data to
> collect, and how often to collect it. If you were collecting event logs for
> example, you would likely be collecting them on a regular basis. How to
> interpret the posture attributes will also need policy from multiple
> sources. For example, the endpoint will likely have an update service so
> its software can be patched, there may also be an AV service which will be
> publishing regular updates. To evaluate therefore if a device is both
> patched and its av is current would need to know the current policy from
> the update and AV services. There may well be other services to collect
> policy data.
>
> draft-ietf-sacm-use-cases-06).....agreed that these are things that need to
> be addressed by the things we standardize but what you describe is only one
> potential instantiation for the need to describe the set of posture
> attributes and "profile" that drives what posture attributes to collect (I
> am trying to distinguish this from "policy" as imho "policy" may be too
> vague for our purposes, as we have used terms like "configuration
> checklist", "endpoint characterization" and "checklist verification" in the
> use cases that would help drive 'what' attributes would need to be
> collected).
>
> *[TF] I am not wedded to the term policy as it often comes with the kind
> of baggage you describe, but the collection process does need input from a
> variety of sources on what posture attributes to collect. I also don't
> think configuration by itself cuts it. I think of configuration as a set of
> parameters necessary for the functioning of the service itself and
> therefore a matter for the local admin. This data set would be more
> dynamic. *
>
>
>
> would be appended to the existing data.   Conceivably a posture consumer
> may also set policy on what data to collect, e.g. if the collector was
> system that couples both, or a system as you describe in your diagram that
> does collection, evaluation and storage).
>
> *[TF] In your diagram, every evaluator has a repository so I am not sure
> of your distinction between evaluator and repository. The collected data
> will need to be stored so it can be proceed so every SACM posture attribute
> collection will have a repository of some form. I don't think that impacts
> the architecture.  Different instances of a SACM service may have a
> repositories of varying capacities. From an architecture perspective, this
> is all irrelevant.  Conceptually, the consumer can issue a query to the
> SACM service for either its evaluated option, or raw collection data. The
> SACM service may be unable to comply with the request for a variety of
> reasons. Maybe the repository is of limited capacity, maybe it has a large
> capacity but the service is new so has no data. Maybe because of policy
> (that word again I know).  The consumer will have to handle those cases. It
> cannot expect to have all its requests met.  *
>
>
>
> interacts with the collector or repository. We can, for the purpose of the
> [NCW] Not disagreeing that we need to address the collection progress, am
> just not sure we need to constrain it to "endpoint" only....agree that
> implementation (e.g. How the data is stored or how evaluator interacts with
> the collector or repository is in our scope).  Which is why, from SACMs
> scope, I distilled it to a simple interaction of a Provider who could
> provide:
>
>  - posture attribute values (marked by some filtering to address the use
> cases; e.g. Either by endpoint, list of endpoints or a combination of the
> endpoints and the "profiles")
>
> *[TF] I agree we should have a short description for the typical cases. We
> also need to respond to new developments i.e. specify arbitrary attributes
> that need to be collected. Something the attribute by be explicitly
> defined, i.e. file in in this path, other times it would be more
> descriptive, i.e. all executables in this location. Sometimes the collector
> may be harvesting event and log data i.e. upload the file or files from
> this location or export the event log. These are all potential attributes
> of the posture. *
>
>
>
> with the information model, but we'll also need the data models, protocols
> and transports to instantiate the standards and ensure interoperability.
>  The charter states that we need to identify how what we standardize is
> distinct from other standards (like NEA and MILE and others outside the
> IETF).....the simple architecture I drew was to first call out distinguishers
> from NEA....but obviously, we need to clarify this further.
>
>
>
> *[TF] The SACM box in the diagram is meant to represent the logical set of
> services that SACM is defining based on the use cases.  The diagram is
> intended to show how those serves interact with external parties via
> standardized interfaces based on the use cases. For example,  interaction
> between the collector and the endpoint would be standardized via a
> protocol. The components within the box are free to interact with each
> other by whatever means the vendor wants.  It shows the posture consumer
> interacting with SACM repository, the repository could be a single or
> multiple physical services. It could be a file system or RDBS. I don't
> think SACM should care.  The same is true for the collection services.
> While we know the services inside the box have to interact with each other,
> it's not clear we need to standardize those aspects based on the use cases.
> We assume implementers do whatever is appropriate and are free to offer a
> range of implementations to meet different markets.   This is a similar
> model LDAP for example where we have standardized the protocol for
> interaction with the service but it is an implementation detail on how the
> LDAP service stores it is data. *
>
>
>
> Trevor
>
>
>
>
>
> .
>
>
>
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Mar 2014 13:03:34 +0000

... a proposal for draft-ietf-sacm-terminology?

Dan

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Wednesday, March 19, 2014 7:19 PM
To: Trevor Freeman; Ira McDonald
Cc: Nancy Cam-Winget (ncamwing); [email-masked]; Atul Shah
Subject: Re: [sacm] SACM Requirement Simple Architecture

Hi Nancy and Trevor,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Wed, Mar 19, 2014 at 12:53 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nancy,

No problem.

From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, March 17, 2014 10:50 AM
To: Trevor Freeman
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM Requirement Simple Architecture

Hi Trevor,

Hi Nancy,

Trevor

.

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm