Subject: [sacm] Rough work in progress for Requirements

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 14 Oct 2013 18:43:13 +0000

Folks,

As the submission deadline is today, I've posted a skeleton draft to help us drive the Requirements just now: http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt

There's plenty to discuss!

Thanks, Nancy.

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 14 Oct 2013 15:41:19 -0400

Nancy, is this just a strawman to meet the document deadline?

The role of SACM as you've outlined here has changed considerably from 
the conversations we've been having for the past 18 months (ish).

Most notably is the assumption that NEA will now be the only assessment 
methodology.  Is that the direction SACM has decided to go?

If you just need a quick ASCII architecture and text to C&P into your 
skeleton, how about Dave Waltermire's original draft:

http://tools.ietf.org/html/draft-waltermire-sacm-architecture-00

On 10/14/2013 2:43 PM, Nancy Cam-Winget (ncamwing) wrote:
> Folks,
>
> As the submission deadline is today, I've posted a skeleton draft to
> help us drive the Requirements just now:
> http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: <[email-masked]>
Date: Mon, 14 Oct 2013 19:52:23 +0000

There are other means to accomplish assessments and NEA was not going to be the only direction considered.  This would be a direction change from what has been discussed in all the side meetings and BOFs leading up to the SACM WG creation.  If this is just a document to meet the deadline, ok.

I am not aware of any consensus around NEA being the sole focus or the only assessment methodology. And if that was brought up for consideration I would vote against it.  There are many deployed products today that use other means for assessment that have proven effective.  We do need to get some of that into this working group but the focus has been on getting the architecture document nailed down…

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>
Organization: ThreatGuard, Inc.
Date: Monday, October 14, 2013 2:41 PM
To: "Nancy Cam-Winget (ncamwing)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Rough work in progress for Requirements

Thanks, Nancy.

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

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

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 14 Oct 2013 22:47:09 +0000

I agree with Kent and Gunnar that SACM needs to support assessment techniques other than the NEA protocols. However, it's not clear to me whether Nancy intended to imply that only NEA-based assessment would be supported. I guess that's why she called this a rough draft. ;-)

Two comments on earlier emails in this thread:

1)      Nancy said "the submission deadline is today". Actually, the deadline is a week from today. See http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

2)      Kent said "the focus has been on getting the architecture document nailed down". Even before that, we need to get the use cases agreed to.

I see that David has just posted a new SACM use cases draft. I'll go review that now. And write those 3 use cases that I promised...

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 14, 2013 3:52 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] Rough work in progress for Requirements

I am not aware of any consensus around NEA being the sole focus or the only assessment methodology. And if that was brought up for consideration I would vote against it.  There are many deployed products today that use other means for assessment that have proven effective.  We do need to get some of that into this working group but the focus has been on getting the architecture document nailed down...

Kent Landfield

Thanks, Nancy.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:17:27 +0000

Hi Gunnar,

Yes, it is a very rough straw man (note that there are still sections TBD)
and the ones I did fill are to help us get the conversation going.

My intent was not to state that NEA was the only assessment method, but
one ofŠbut nonetheless, my point was to state how the posture assessment
is achieved and stored from the end point was not our focusŠ.as groups
like NEA have done soŠ.I can clean up the language as such.  As for
architecture, admittedly, the one that was posted by Russ and Sean
resonated better to me draft-handt-sacm-alternate-architecture-01Š.

	Nancy.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:20:11 +0000

Hi Steve,

Please see below:

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 14, 2013 3:47 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sacm] Rough work in progress for Requirements

I agree with Kent and Gunnar that SACM needs to support assessment techniques other than the NEA protocols. However, it’s not clear to me whether Nancy intended to imply that only NEA-based assessment would be supported. I guess that’s why she called this a rough draft. ;-)
[NCW] Right, I just responded to Gunnar in kind…..

1)      Nancy said “the submission deadline is today”. Actually, the deadline is a week from today. See http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

[NCW] For some reason I had it that it was due yesterday, so my bad….in this case, better to get it done now and get the dialogue going.

2)      Kent said “the focus has been on getting the architecture document nailed down”. Even before that, we need to get the use cases agreed to.
 [NCW] Agreed!!!

I see that David has just posted a new SACM use cases draft. I’ll go review that now. And write those 3 use cases that I promised…

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, October 14, 2013 3:52 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Rough work in progress for Requirements

Kent Landfield

Thanks, Nancy.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 15 Oct 2013 11:56:03 -0400

> resonated better to me draft-handt-sacm-alternate-architecture-01Š.

With less than a week to go before the document deadline now is not a 
great time to be discussing major revisions, so I have a couple questions:

1) After this document deadline, how radically can they be changed in 
future revisions?

If large changes are not a problem and it's only important that some 
sort of document be available, it doesn't really matter what's in the 
documents right now.  If that's the case, the answer to my second 
question could wait.

2) Is it the consensus of the group that SACM is no longer concerned 
with "how the posture assessment is achieved and stored", but instead 
"...the focus of the requirements will revolve around the data models, 
protocols and transports for B, the communication of posture assessment 
from an Evaluator to an Assessment Consumer."

That strikes me as a significant and surprising change from what I 
understood as the goal of this working group, and one that I completely 
disagree with.  But I would like to know the perspective of others on 
this.  It seems counterproductive to head into IETF 88 with perspectives 
that are so dichotomous.

--gun

---

From: David Harrington <[email-masked]>
Date: Tue, 15 Oct 2013 14:31:34 -0400

Hi Nancy,

The deadline is next Monday:
2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts,
including -00) by UTC 24:00, upload using IETF ID Submission Tool
<https://datatracker.ietf.org/submit/> .

I chopped section 4 from the use-cases document, with the understanding you
would incorporate that content into the requirements doc.
-- 
David Harrington
[email-masked]
+1-603-828-1401

From:  Nancy Cam-Winger <[email-masked]>
Date:  Monday, October 14, 2013 2:43 PM
To:  "[email-masked]" <[email-masked]>
Subject:  [sacm] Rough work in progress for Requirements

Folks,

As the submission deadline is today, I've posted a skeleton draft to help us
drive the Requirements just now:
http://www.ietf.org/id/draft-camwinget-sacm-requirements-00.txt

Thanks, Nancy.
_______________________________________________ sacm mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/sacm

---

From: <[email-masked]>
Date: Tue, 15 Oct 2013 19:04:47 +0000

Oops…  Totally agree.  I must have been looking at the link in Gunnar's message when I typed that.  You are correct. ;-)

Kent Landfield

From: Stephen Hanna <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 14, 2013 5:47 PM
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, Gunnar Engelbach <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sacm] Rough work in progress for Requirements

Thanks,

Steve

Kent Landfield

Thanks, Nancy.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Oct 2013 09:23:47 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gunnar Engelbach
> 
Hi Gunnar, 

This is simple to answer. draft-camwinget-sacm-requirements-00 is a 00 draft of an individual submission. It has a long way to go, and all kind of changes including 'radical' ones can happen. I would not say either that it doesn't really matter what's in the document right now - as the goal is exactly to trigger and structure discussions around existing text, but there will be several iterations of this text until we will reach consensus and nothing is cast in stone at this point. 

Regards,

Dan

---

From: Adam Montville <[email-masked]>
Date: Wed, 16 Oct 2013 14:40:22 +0000

Just to clarify the deadline issues...  The -00 submission deadline was this past Monday (2013-10-14).  Final submission deadline is this coming Monday (2013-10-21).

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Tuesday, October 15, 2013 1:32 PM
To: Nancy Cam-Winget (ncamwing); [email-masked]
Subject: Re: [sacm] Rough work in progress for Requirements

Hi Nancy,

The deadline is next Monday:
2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool<https://datatracker.ietf.org/submit/>.

I chopped section 4 from the use-cases document, with the understanding you would incorporate that content into the requirements doc.
--
David Harrington
[email-masked]<mailto:[email-masked]>
+1-603-828-1401

From: Nancy Cam-Winger <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 14, 2013 2:43 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] Rough work in progress for Requirements

Folks,

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

. . .

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 16 Oct 2013 15:02:50 +0000

> Just to clarify the deadline issues...  The -00 submission deadline was this past Monday (2013-10-14).  Final submission deadline is this coming Monday (2013-10-21).

I don't think that's correct. Here's the info from the IETF web site:

*  2013-10-07 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00.
*  2013-10-11 (Friday): Final agenda to be published.
*  2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool<https://datatracker.ietf.org/submit/>.

Nowhere is October 14 mentioned as a deadline. October 7 is mentioned as a date by which WG chairs should provide approval for -00 WG drafts. I don't think that applies here since we won't have any -00 WG drafts coming in this time. So October 21 is the real deadline for drafts in this case. If you have some information that supports your contention that the -00 deadline was October 14, could you please point me to it? I got my info from this web page:

http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

The IETF used to have a -00 deadline one week before the non-00 deadline but that practice was discontinued for IETF 87 and IETF 88.

Thanks,

Steve

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, October 16, 2013 10:40 AM
To: David Harrington; Nancy Cam-Winget (ncamwing); [email-masked]
Subject: Re: [sacm] Rough work in progress for Requirements

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Tuesday, October 15, 2013 1:32 PM
To: Nancy Cam-Winget (ncamwing); [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Rough work in progress for Requirements

Hi Nancy,

Folks,

Thanks, Nancy.

. . .

---

From: Adam Montville <[email-masked]>
Date: Wed, 16 Oct 2013 15:07:13 +0000

Stephen just pointed this out to me as well.  I, apparently, have an out-of-date set of data in my calendar, which I probably retrieved from IETF a while back, before the change.

Apologies.

Adam

From: Stephen Hanna [mailto:[email-masked]]
Sent: Wednesday, October 16, 2013 10:04 AM
To: Adam Montville; David Harrington; Nancy Cam-Winget (ncamwing); [email-masked]
Subject: RE: [sacm] Rough work in progress for Requirements

Thanks,

Steve

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, October 16, 2013 10:40 AM
To: David Harrington; Nancy Cam-Winget (ncamwing); [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Rough work in progress for Requirements

Hi Nancy,

Folks,

Thanks, Nancy.

. . .

...

. . .

---

From: Adam Montville <[email-masked]>
Date: Wed, 16 Oct 2013 15:40:50 +0000

Nancy, thank you for working on this!  I very much like your Architectural Design Tenets section, which I believe support our Use Cases well.

I would prefer to see a Requirements document free from any architectural assumptions, such that we are able to conceive an architecture that is truly derived from requirements - in other words, let's let the requirements drive the architecture, not the other way around (I fully recognize that network architectural constraints will affect our solution in the end).

By my read, we have the following Use Cases present in the -02 Use Case draft:

2.1 - Definition and Publication of Automatable Configuration Guides
2.2 - Automated Checklist Verification
2.3 - Organizational Software Policy Compliance
2.4 - Detection of Posture Deviation
2.5 - Search for Signs of Infection
2.6 - Remediation and Mitigation
2.7 - Endpoint Information Analysis and Reporting

Endpoint Posture Assessment (Section 2) starts out with "collecting the posture of a given endpoint."  I want to limit this example to that particular statement in the -02 Use Case draft, because it applies generally to the specific Use Cases contained in that section.

>From my perspective, requirements pertaining to that statement might read something like the following:

1.       The system must be capable of expressing configuration items across technology platforms as necessary.

2.       The expression of configuration items across technology platforms must be extensible to account for changes to existing platforms as well as new platforms.

3.       The system must be capable of expressing a "platform" or "technology" instance

4.       The system must be capable of harvesting (collecting) configuration state

>From the other Use Cases, we might be able to add further requirements, such as:

1.       The system must be capable of expressing a class of platforms or technologies

2.       The system must be capable of performing assessment over a limited bandwidth network

3.       The system must be able to compare expected state against actual state for initial analysis

It seems that the question to ask about each of the Use Cases in the -02 draft is: "What needs to be true of the system we envision to realize the Use Cases we wish to meet?"  This might be an exercise for each of the bulleted items in Section 2 proper, and then further for each subsection therein.

Any thoughts or comments on taking this approach to the requirements?

Regards,

Adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, October 14, 2013 1:43 PM
To: [email-masked]
Subject: [sacm] Rough work in progress for Requirements

Folks,

Thanks, Nancy.

...

. . .

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 16 Oct 2013 12:05:54 -0400

Look out below...

On 10/16/2013 11:40 AM, Adam Montville wrote:
> Nancy, thank you for working on this!  I very much like your
> Architectural Design Tenets section, which I believe support our Use
> Cases well.
>
> I would prefer to see a Requirements document free from any
> architectural assumptions, such that we are able to conceive an
> architecture that is truly derived from requirements – in other words,
> let’s let the requirements drive the architecture, not the other way
> around (I fully recognize that network architectural constraints will
> affect our solution in the end).
>

Let's not forget that the charter also covers interaction with a content 
repository.  Here is a start on use cases covering that:

1 Retrieve materials necessary to perform standardized categorization of 
an asset (such as determine its CPE)

2 Retrieve all materials necessary to complete an automated assessment 
to determine the level of compliance of a Windows 7 x64 desktop machine 
with HIPAA regulations.

3 Retrieve materials necessary to perform evaluation of all potential 
vulnerabilities for iOS identified since the date xx/xx/xxxx that can 
yield unauthorized remote access or privilege escalation.

4 Retrieve human audience content associated with a compliance policy 
(such as the driving regulation, security training videos, etc).

5 Register with repository for immediate notification of new security 
vulnerability content that match a selection filter (Filter terms could 
include OSs, applications, severity rating, automated 
check/vulnerability announcement, original content source, content 
author rating, etc)

>
> Endpoint Posture Assessment (Section 2) starts out with “collecting the
> posture of a given endpoint.”  I want to limit this example to that
> particular statement in the -02 Use Case draft, because it applies
> generally to the specific Use Cases contained in that section.
>
> 1.The system must be capable of expressing configuration items across
> technology platforms as necessary.
>
> 2.The expression of configuration items across technology platforms must
> be extensible to account for changes to existing platforms as well as
> new platforms.
>
> 3.The system must be capable of expressing a “platform” or “technology”
> instance
>
> 4.The system must be capable of harvesting (collecting) configuration state
>
> 1.The system must be capable of expressing a class of platforms or
> technologies
>
> 2.The system must be capable of performing assessment over a limited
> bandwidth network
>
> 3.The system must be able to compare expected state against actual state
> for initial analysis
>
> It seems that the question to ask about each of the Use Cases in the -02
> draft is: “What needs to be true of the system we envision to realize
> the Use Cases we wish to meet?”  This might be an exercise for each of
> the bulleted items in Section 2 proper, and then further for each
> subsection therein.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Nancy Cam-Winget (ncamwing)
> *Sent:* Monday, October 14, 2013 1:43 PM
> *To:* [email-masked]
> *Subject:* [sacm] Rough work in progress for Requirements
>
> Folks,
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 Oct 2013 19:01:32 +0000

I am reading through all the email threads getting caught up on the discussion. A couple things jumped out at me in your email below:

1) First an observation. The term "assessment", as it is commonly used in the SACM charter, discussion, and in our drafts, encompasses both posture collection (the current RFC5209 definition) and posture evaluation. The wording of the definition in draft-ietf-sacm-terminology-00 could be improved to make this more clear. In many discussions it appears that the term "assessment" is used interchangeably with collection or evaluation. It might be best to use more specific terms like posture collection and posture evaluation to provide greater clarity in discussions. Thoughts?

2) In your email below you raise concerns about NEA being used as the sole focus for assessment. What aspect of assessment are you referring to?

3) You mentioned that "there are many deployed products today that use other means for assessment".

Are you suggesting that there are other transports and data models for posture collection? Or for posture evaluation?

What are they? Are these methods proprietary or standardized?

Do they support use cases that are not addressed in the use case draft? If so, what are they?

Are there important requirements that need to be captured relating to these methods? If so, what requirements?

Thanks,
Dave

Kent Landfield

Thanks, Nancy.

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 17 Oct 2013 16:40:13 -0400

Hey Dave, welcome back to the world of the working!

On 10/17/2013 3:01 PM, Waltermire, David A. wrote:
> I am reading through all the email threads getting caught up on the
> discussion. A couple things jumped out at me in your email below:
>
> 1) First an observation. The term “assessment”, as it is commonly used
> in the SACM charter, discussion, and in our drafts, encompasses both
> posture collection (the current RFC5209 definition) and posture
> evaluation. The wording of the definition in
> draft-ietf-sacm-terminology-00 could be improved to make this more
> clear. In many discussions it appears that the term “assessment” is used
> interchangeably with collection or evaluation. It might be best to use
> more specific terms like posture collection and posture evaluation to
> provide greater clarity in discussions. Thoughts?

To me, "assessment" implies that some sort of collection must have 
occurred.  If it helps, I'm all for being more explicit in terminology 
-- although I'm sure I'll get tired of typing "posture collection and 
evaluation".

"Assessment" and "scanning" are the terms that seem to get used most 
frequently and might have different meanings to different people.  Maybe 
we should use less common terms that we define for ourselves so that 
people who don't read the terminology document are less likely to make a 
faulty interpretation.

"Collection" and "evaluation" are good.  I don't have any suggestions 
for the combined action.

>
> 2) In your email below you raise concerns about NEA being used as the
> sole focus for assessment. What aspect of assessment are you referring to?

NEA would be doing both collection and evaluation.  From the reading 
I've done on NEA it would make available evaluation results for an 
endpoint, but could not be used for generic evaluations or arbitrary 
collection.

But I'm hoping we can not worry about what NEA (or SNMP, or WBEM, or 
whatever) can and can't do.  NEA is an existing standard that is being 
built into existing products -- I'd like to see if what we define can 
take advantage of what it does provide in the places where it is available.

>
> 3) You mentioned that “there are many deployed products today that use
> other means for assessment”.
>
> Are you suggesting that there are other transports and data models for
> posture collection? Or for posture evaluation?

Certainly.  Just do a search for security and compliance evaluation 
tools and most of them are using proprietary means for this.  ISS, 
NetRanger, Nessus, ...  Yeah, I'm deliberately picking older ones, but 
you get the point.

> What are they? Are these methods proprietary or standardized?

Most are proprietary, but there are some existing standards for 
collection (and management) such as SNMP, WBEM, OVAL, (arguably: Puppet) 
and some standards that add evaluation -- NEA, OVAL, XCCDF.

Certainly not an exhaustive list, but the thing is, none of these 
provide coverage as complete as what I think this working group is 
looking for.  Or maybe I'm just being aspirational.

I also think it's very important that the collection and evaluation 
content -- the automated part of the Content Repository -- should be in 
a standardized format, but I don't see that as excluding the use of a 
variety of possible collection techniques.

> Do they support use cases that are not addressed in the use case draft?

And that also fall within the scope of the SACM charter?  Nothing that 
pops into my head right now but it's a good point -- I'll keep thinking 
about that.

> these methods? If so, what requirements?

You mean to enable the use of them?  Such as "TCP simple services must 
be installed and the firewall rules modified appropriately..." in order 
to use SNMP?

> Of [email-masked]
> *Sent:* Monday, October 14, 2013 3:52 PM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [sacm] Rough work in progress for Requirements
>
> There are other means to accomplish assessments and NEA was not going to
> be the only direction considered.  This would be a direction change from
> what has been discussed in all the side meetings and BOFs leading up to
> the SACM WG creation.  If this is just a document to meet the deadline, ok.
>
> I am not aware of any consensus around NEA being the sole focus or the
> only assessment methodology. And if that was brought up for
> consideration I would vote against it.  There are many deployed products
> today that use other means for assessment that have proven effective.
>   We do need to get some of that into this working group but the focus
> has been on getting the architecture document nailed down…
>
> *Kent Landfield*
>
> *McAfee | An Intel Company*
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> *From: *Gunnar Engelbach <[email-masked]
> <mailto:[email-masked]>>
> *Organization: *ThreatGuard, Inc.
> *Date: *Monday, October 14, 2013 2:41 PM
> *To: *"Nancy Cam-Winget (ncamwing)" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [sacm] Rough work in progress for Requirements
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 17 Oct 2013 21:22:48 +0000

> Sent: Thursday, October 17, 2013 3:40 PM
> To: Waltermire, David A.; [email-masked];
> [email-masked]; [email-masked]
> > 1) First an observation. The term "assessment", as it is commonly used
> > clear. In many discussions it appears that the term "assessment" is
> > used interchangeably with collection or evaluation. It might be best
> > to use more specific terms like posture collection and posture
> > evaluation to provide greater clarity in discussions. Thoughts?
> 
> -- although I'm sure I'll get tired of typing "posture collection and evaluation".
> 

To assess is to evaluate, so it seems that comparison of actual to expected values is the "assessment" portion of what we're doing.

Before you can assess, you need to have an actual value (or lack thereof), and that might be termed harvesting, collecting, gathering.

> "Collection" and "evaluation" are good.  I don't have any suggestions for the
> combined action.

There probably isn't a good term that explicitly encompasses both, but I do believe that an assessment implies that some sort of harvesting has occurred.

Perhaps we let "assessment" mean exactly that and when we mean "compare actual vs. expected" we use "evaluate"?

> take advantage of what it does provide in the places where it is available.

I tend to agree with your perspective here, Dave.  It seems to me that we should remain as open as possible when it comes to data conveyance and harvesting mechanisms.

> > has been on getting the architecture document nailed down...
> >
> > *Kent Landfield*
> >

. . .

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 20 Oct 2013 03:35:20 +0000

Hi Adam,

Please see further comments below:

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 16, 2013 8:40 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Rough work in progress for Requirements

I would prefer to see a Requirements document free from any architectural assumptions, such that we are able to conceive an architecture that is truly derived from requirements – in other words, let’s let the requirements drive the architecture, not the other way around (I fully recognize that network architectural constraints will affect our solution in the end).
[NCW] That is a fair comment, albeit I tend to think of them as being interdependent as you also note in the parenthetical note :-)

Endpoint Posture Assessment (Section 2) starts out with “collecting the posture of a given endpoint.”  I want to limit this example to that particular statement in the -02 Use Case draft, because it applies generally to the specific Use Cases contained in that section.

3.       The system must be capable of expressing a “platform” or “technology” instance

[NCW] Given our charter, I am concerned that "configuration items" may be too broad?  I like the notions enumerated in #3 and 4…albeit by expression, I think you mean a common attribute/schema that allows systems to interpret what a "platform" is? (though, I think that is more to "endpoint" definition?)  as we'll also have to include characteristics like virtual, hw vs. sw and the like…

[NCW] Yes, I think some of the use cases highlight the means (both in timing and filtering) by which the information is to be extracted.

It seems that the question to ask about each of the Use Cases in the -02 draft is: “What needs to be true of the system we envision to realize the Use Cases we wish to meet?”  This might be an exercise for each of the bulleted items in Section 2 proper, and then further for each subsection therein.

Any thoughts or comments on taking this approach to the requirements?
[NCW] I'm not sure I'm quite ready to call it a system :-)  but I'll try to see how I can update the draft to include some of the points above

Regards,

Adam

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, October 14, 2013 1:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sacm] Rough work in progress for Requirements

Folks,

Thanks, Nancy.

...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . .

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 20 Oct 2013 03:36:43 +0000

Hi Gunnar,

I think what you are calling out is that information could (and should?)
be requested to/from not just what I was calling the Evaluators but also
from modules that provide interfaces to the posture repositoriesŠ.so I can
try to update to that affect as well.

	Nancy

On 10/16/13 9:05 AM, "Gunnar Engelbach" <[email-masked]>
wrote:

>> architecture that is truly derived from requirements  in other words,
>> let¹s let the requirements drive the architecture, not the other way
>> Endpoint Posture Assessment (Section 2) starts out with ³collecting the
>> posture of a given endpoint.²  I want to limit this example to that
>> 3.The system must be capable of expressing a ³platform² or ³technology²
>> instance
>>
>> draft is: ³What needs to be true of the system we envision to realize
>> the Use Cases we wish to meet?²  This might be an exercise for each of

---

From: Adam Montville <[email-masked]>
Date: Mon, 21 Oct 2013 13:43:38 +0000

From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]]
Sent: Saturday, October 19, 2013 10:35 PM
To: Adam Montville; [email-masked]
Subject: Re: Rough work in progress for Requirements

Hi Adam,

I would prefer to see a Requirements document free from any architectural assumptions, such that we are able to conceive an architecture that is truly derived from requirements - in other words, let's let the requirements drive the architecture, not the other way around (I fully recognize that network architectural constraints will affect our solution in the end).
[NCW] That is a fair comment, albeit I tend to think of them as being interdependent as you also note in the parenthetical note :-)
[AWM] Agreed.  Iteration will typically have additional constraints being discovered as architectures meeting initial requirements are contemplated.  My goal is to be as clean as possible in this first pass - may or may not be a reasonable goal from the sacm-community-perspective.

4.       The system must be capable of harvesting (collecting) configuration state
[NCW] Given our charter, I am concerned that "configuration items" may be too broad?  I like the notions enumerated in #3 and 4...albeit by expression, I think you mean a common attribute/schema that allows systems to interpret what a "platform" is? (though, I think that is more to "endpoint" definition?)  as we'll also have to include characteristics like virtual, hw vs. sw and the like...
[AWM] Scoping will be an ongoing issue.  The reality is, I believe, that configuration items are important as they relate to the security of a given endpoint, and this changes with time.  It might well be that a particular configuration item is not deemed a "security-relevant-configuration-item" until tomorrow when it is leveraged in some way by an adversary.  So, "configuration item" is broad, but necessarily so.  We need not encompass the whole set of "configuration items" at the outset, however - the basics should suffice.  Extension and modification are going to be the important pieces of this, I think.

Any thoughts or comments on taking this approach to the requirements?
[NCW] I'm not sure I'm quite ready to call it a system :-)  but I'll try to see how I can update the draft to include some of the points above
[AWM] Ha!  Yes, I agree, but I really didn't know what other term to use in reference to the whole. :)

Regards,

Adam

Folks,

Thanks, Nancy.

...

...

. . .