Subject: Re: [sacm] Regarding SACM Terminology (was: sacm Digest, Vol 25, Issue 17)

From: "Brian Ford (brford)" <[email-masked]>
Date: Tue, 1 Apr 2014 12:42:27 +0000

Adam,

Thanks for your feedback.  It was very helpful.

Regarding 'Posture'; if posture is the state that we found on a subject device is that based on 1) we ran a test against the device and these conditions failed, or 2) a program analyzed the configuration files of the subject device and determined that the configuration was not as it should be.  

If 1) then in order to assess posture I don't have to know how to configure the device.
If 2) in order to asses posture I have to have some expertise at configuring the device.

There is a big difference here.  I'm leaning towards wanting a solution that runs the test rather than having to interpret configurations.  Is this two separate use cases?

I think we agree that a posture attribute should capture an observable or raw output that has not been interpreted or processed.  Registry variables, Syslog output, the contents of a system file are all observables.  If my solution reads a number of registry variables and produces 'Yes" when the values found add up to a number greater than 3 -> that's not a posture attribute of the target system but of my solution.

I'd like to see the definition of posture attribute tightened up to reflect this and acknowledge that the 'posture attribute' is considered synonymous with 'observable'.

I took away the same interpretation for misconfiguration that you stated here - "Generally, the endpoint attributes we look at are posture attributes and these are "configuration items" (to load another term on the pile).  A misconfiguration is simply an attribute set to an organizationally-impermissible value".  But in this case I can have an endpoint that operates just fine and without error but has a 'misconfiguration'.  I associate 'misconfiguration' with trying to enter value that should not work - or cause the endpoint to not work.  Setting the configuration of a network adapter on an endpoint so that it can't communicate with a switch (and participate in a network) is a misconfiguration.  I think what you are trying to capture here goes back to policy violation or an exception.

I think misconfiguration should be out and policy exception should be used instead.

I think we agree that a remediation is either something was broken (did not work) and this is how you fix it OR it has to reference a specific policy; a policy remediation.

Liberty,

Brian

-----Original Message-----
From: Adam Montville [mailto:[email-masked]] 
Sent: Monday, March 31, 2014 3:37 PM
To: Brian Ford (brford)
Cc: [email-masked]
Subject: Re: [sacm] Regarding SACM Terminology (was: sacm Digest, Vol 25, Issue 17)

Hi Brian, thanks for your questions.  I'll provide some responses inline.  Others may also provide their perspectives, but hopefully I do well enough.

On Mar 31, 2014, at 12:56 PM, Brian Ford (brford) <[email-masked]> wrote:

> SACM Team;
> 
> I have observations and questions regarding the definitions used to describe posture or posture attributes in Terminology for Security Assessment  (draft-ietf-sacm-terminology-03) and whether these definitions fit well into the security automation and continuous monitoring operations.  This message is regarding some of the 'Pre-defined Terms'.
> 
> Regarding 'Posture':
> 
> "Posture - Defined in [RFC5209] as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's  security policy." This term is used within the scope of this document to represent the state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings)."
> 
> Is posture the configuration of a device or what the security policy of an organization that use the device suggests that the device configuration should be ("as it pertains to the organization's security policy")?  Reading RFC 5209 one could come to the conclusion that an endpoint's posture is either right or wrong, or acceptable or unacceptable given an organizational security policy at the time of assessment.

Posture is being used as a noun and can reference the actual state of the subject - in this case the endpoint.  Posture should not be construed as the configuration state of an endpoint as it should be, but rather as it is.  

Policy is a tricky term that has many meanings and, most important, very specific meanings in other areas of the IETF.  If you dig back into SACM's BoF history you'll find a presentation that shows a four-layered model with a vertical column adjacent to and straddling each layer.  The four layers are, from top to bottom: Operational Risk Management, IT Risk Management, Control Frameworks, and Controls.  The vertical column is labeled "Policy, Process, and Procedure" (or something similar).  This depiction can be viewed as a contextual guideline for SACM.  Then, when we use the term "policy" we are often using it to refer to that set of organizational mandates that are derived from the four risk management layers.  This distinction is important in the SACM context.

> 
> Regarding 'Posture Attribute':
> 
> Posture Attributes -"Defined in [RFC5209] as "attributes describing the configuration or status (posture) of a feature of the endpoint.  For example, a Posture Attribute might describe the version of the operating system installed on the system."  Within this document this term represents a specific assertion about endpoint state (e.g. configuration setting, installed software, hardware).  The phrase "features of the endpoint" refers to installed software or software components."
> 
> Using the word 'attribute' I think that posture attributes should be variables that were derived by examining an endpoint.  In the STIX language I think of 'observables'.  On a computer running the Windows operating system an observable might be a specific registry variable setting or the physical address of the Ethernet adapter connected to Network 3.  I would suggest that posture attribute capture a variable setting without interpretation.
> 
> RFC 5209 defines 5 different types of attributes (assertion, posture, request, result, and remediation) based on different usage scenarios.
> 

Generically, an attribute is simply a characteristic - it's some thing that is regarded as a quality or feature of another thing.  In the STIX language, an observable can be considered an attribute of the thing on which the observable was observed.  To me, these terms (observable and attribute) can be considered synonymous.  

> Regarding 'Misconfiguration':
> 
> misconfiguration -" A misconfiguration is a configuration setting that violates organizational security policies, introduces a possible security weakness in a system, or permits or causes unintended behavior that may impact the security posture of a system. (from NIST IR       7670) The misalignment of a unit of endpoint configuration posture relative to organizational expectations that is subject to exploitation or misuse."
> 
> I don't see how this 'misconfiguration' can be part of 'posture', or an attribute or an observable of a system.  A misconfiguration is something that is the result of some analysis performed by a program or an analyst and has to reference a specific policy that the configuration violates.  Is a misconfiguration a diff between what the policy should be and what it was discovered to be?
> 

Generally, the endpoint attributes we look at are posture attributes and these are "configuration items" (to load another term on the pile).  A misconfiguration is simply an attribute set to an organizationally-impermissible value (i.e. set against policy - see comment above regarding policy in the SACM context).  

> Regarding 'remediation':
> 
> "A remediation is defined as a security-related set of actions that results in a change to a computer's state and may consist of changes motivated by the need to enforce organizational security policies, address discovered vulnerabilities, or correct misconfigurations. (from NIST IR 7670)."
> 
> I'm concerned that this definition of remediation is too broad.  From what is written it would seem that remediation spans 'actions' that could include adding or removing hardware or software to or changing the configuration of a 'computer'.  I associate remediation with addressing vulnerabilities and correcting misconfigurations.  I don't view a remediation as being the word I'd use to describe changes made to enforce organizational policies.  Do you have to remediate all the computers that are your network if a decision is made to change software providers?  Clearly that could be an automation issue but is it a security automation issue?
> 
> I'd suggest that a remediation should be a specific action or set of actions that changes configuration to acceptable within organization' policy.

This might be a good suggestion.  We could get into a semantic discussion about whether a mitigation is a form of remediation, but for SACM's immediate purposes remediation is out of scope.  This will be important later in life.  For what it's worth, I think the term "remediation" probably has origins in the IT audit domain where we talk about "findings" and such.  An auditor would probably provide a list of findings and each finding would need to be "remediated" in a general sense, which is just another way of saying that the finding needs to be addressed in some way.  But, as I said before, remediation is out of scope for our present charter.

> 
> In general I think we all see the linkage between SACM and NEA.  I think there needs to be more review and discussion about the linkage between SACM and MILE and other security operations and incident response initiatives such as STIX and OpenIOC.

The links between SACM and MILE and STIX and OpenIOC and NEA and others are very important.  Each provides at least one part of a "whole" set of automated information security tools.  Ideally, each should inform the others - you raise a great point.  In an ideal world, we'd all have a common vocabulary from which we operate, but that's not the case.  

What sort of review/discussion would you envision taking place and to what end?

> 
> Liberty,
> 
> Brian
> 
> 
> 
> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, March 23, 2014 3:01 PM
> To: [email-masked]
> Subject: sacm Digest, Vol 25, Issue 17
> 
> Send sacm mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/sacm
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific than "Re: Contents of sacm digest..."
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Tue, 1 Apr 2014 08:33:59 -0500

> There is a big difference here.  I'm leaning towards wanting a solution that runs the test rather than having to interpret configurations.  Is this two separate use cases?

These don't feel like two use cases, but one.  This situation seems to map well to the design of many network devices that have two sets of states, one running and one configured.  

I'm not sure I'm tracking how "you" (an operator, auditor, administrator?) would need to have some expertise at configuring the device.  If you're the "content producer" then I agree.  At some point, someone has to have a fair degree of expertise to create assessment-driving content, but that exists for both of the cases you've mentioned above.  Maybe I'm missing something?

> I think we agree that a posture attribute should capture an observable or raw output that has not been interpreted or processed.  Registry variables, Syslog output, the contents of a system file ar…

The question is whether compositions of "primitive" or "root" attributes are themselves attributes.  If an endpoint has attributes A, B, and C, then should the sum of these also be an attribute?   

I would say that the sum is not an attribute of the solution, but I am not quite ready to say that the sum is not an attribute of the endpoint.  It may not be explicitly named, but does it need to be?  The sum of A, B, and C describes a characteristic of the target in a way that A, B, or C taken separately cannot, and the sum is inherent to the posture of the target.

> I think misconfiguration should be out and policy exception should be used instead.

What do others think of this?  Loosely, these may end up meaning the same thing.  I like the notion of including "policy" in the term as an explicit tie to the fact that we're assessing a target in support of some enterprise policy.  But, use of the term "exception" may be problematic, as it can easily be read as "waiver," which has very specific meaning in the SACM context.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 1 Apr 2014 14:04:53 +0000

Adam,

What I understood from Brian:

Posture:  it is what it is

Policy Assessment:  what it is, may or may not be what it should be.

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, April 01, 2014 9:34 AM
To: Brian Ford (brford)
Cc: [email-masked]
Subject: Re: [sacm] Regarding SACM Terminology (was: sacm Digest, Vol 25,
Issue 17)

On Apr 1, 2014, at 7:42 AM, Brian Ford (brford) <[email-masked]> wrote:

> Regarding 'Posture'; if posture is the state that we found on a subject
device is that based on 1) we ran a test against the device and these
conditions failed, or 2) a program analyzed the configuration files of the
subject device and determined that the configuration was not as it should
be.  
> There is a big difference here.  I'm leaning towards wanting a solution
that runs the test rather than having to interpret configurations.  Is this
two separate use cases?

These don't feel like two use cases, but one.  This situation seems to map
well to the design of many network devices that have two sets of states, one
running and one configured.  

I'm not sure I'm tracking how "you" (an operator, auditor, administrator?)
would need to have some expertise at configuring the device.  If you're the
"content producer" then I agree.  At some point, someone has to have a fair
degree of expertise to create assessment-driving content, but that exists
for both of the cases you've mentioned above.  Maybe I'm missing something?

> 
> I think we agree that a posture attribute should capture an observable or
raw output that has not been interpreted or processed.  Registry variables,
Syslog output, the contents of a system file are all observables.  If my
solution reads a number of registry variables and produces 'Yes" when the
values found add up to a number greater than 3 -> that's not a posture
attribute of the target system but of my solution.

The question is whether compositions of "primitive" or "root" attributes are
themselves attributes.  If an endpoint has attributes A, B, and C, then
should the sum of these also be an attribute?   

I would say that the sum is not an attribute of the solution, but I am not
quite ready to say that the sum is not an attribute of the endpoint.  It may
not be explicitly named, but does it need to be?  The sum of A, B, and C
describes a characteristic of the target in a way that A, B, or C taken
separately cannot, and the sum is inherent to the posture of the target.

> 
> I'd like to see the definition of posture attribute tightened up to
reflect this and acknowledge that the 'posture attribute' is considered
synonymous with 'observable'.
> 
> I took away the same interpretation for misconfiguration that you stated
here - "Generally, the endpoint attributes we look at are posture attributes
and these are "configuration items" (to load another term on the pile).  A
misconfiguration is simply an attribute set to an
organizationally-impermissible value".  But in this case I can have an
endpoint that operates just fine and without error but has a
'misconfiguration'.  I associate 'misconfiguration' with trying to enter
value that should not work - or cause the endpoint to not work.  Setting the
configuration of a network adapter on an endpoint so that it can't
communicate with a switch (and participate in a network) is a
misconfiguration.  I think what you are trying to capture here goes back to
policy violation or an exception.
> I think misconfiguration should be out and policy exception should be used
instead.

What do others think of this?  Loosely, these may end up meaning the same
thing.  I like the notion of including "policy" in the term as an explicit
tie to the fact that we're assessing a target in support of some enterprise
policy.  But, use of the term "exception" may be problematic, as it can
easily be read as "waiver," which has very specific meaning in the SACM
context.  

> 
> I think we agree that a remediation is either something was broken (did
not work) and this is how you fix it OR it has to reference a specific
policy; a policy remediation.
> Hi Brian, thanks for your questions.  I'll provide some responses inline.
Others may also provide their perspectives, but hopefully I do well enough.
>> I have observations and questions regarding the definitions used to
describe posture or posture attributes in Terminology for Security
Assessment  (draft-ietf-sacm-terminology-03) and whether these definitions
fit well into the security automation and continuous monitoring operations.
This message is regarding some of the 'Pre-defined Terms'.
>> 
>> Regarding 'Posture':
>> 
>> "Posture - Defined in [RFC5209] as "configuration and/or status of
hardware or software on an endpoint as it pertains to an organization's
security policy." This term is used within the scope of this document to
represent the state information that is collected from an endpoint (e.g.
software/hardware inventory, configuration settings)."
>> 
>> Is posture the configuration of a device or what the security policy of
an organization that use the device suggests that the device configuration
should be ("as it pertains to the organization's security policy")?  Reading
RFC 5209 one could come to the conclusion that an endpoint's posture is
either right or wrong, or acceptable or unacceptable given an organizational
security policy at the time of assessment.
> 
> Posture is being used as a noun and can reference the actual state of the
subject - in this case the endpoint.  Posture should not be construed as the
configuration state of an endpoint as it should be, but rather as it is.  
> 
> Policy is a tricky term that has many meanings and, most important, very
specific meanings in other areas of the IETF.  If you dig back into SACM's
BoF history you'll find a presentation that shows a four-layered model with
a vertical column adjacent to and straddling each layer.  The four layers
are, from top to bottom: Operational Risk Management, IT Risk Management,
Control Frameworks, and Controls.  The vertical column is labeled "Policy,
Process, and Procedure" (or something similar).  This depiction can be
viewed as a contextual guideline for SACM.  Then, when we use the term
"policy" we are often using it to refer to that set of organizational
mandates that are derived from the four risk management layers.  This
distinction is important in the SACM context.
>> Posture Attributes -"Defined in [RFC5209] as "attributes describing the
configuration or status (posture) of a feature of the endpoint.  For
example, a Posture Attribute might describe the version of the operating
system installed on the system."  Within this document this term represents
a specific assertion about endpoint state (e.g. configuration setting,
installed software, hardware).  The phrase "features of the endpoint" refers
to installed software or software components."
>> 
>> Using the word 'attribute' I think that posture attributes should be
variables that were derived by examining an endpoint.  In the STIX language
I think of 'observables'.  On a computer running the Windows operating
system an observable might be a specific registry variable setting or the
physical address of the Ethernet adapter connected to Network 3.  I would
suggest that posture attribute capture a variable setting without
interpretation.
>> 
>> RFC 5209 defines 5 different types of attributes (assertion, posture,
request, result, and remediation) based on different usage scenarios.
>> 
> 
> Generically, an attribute is simply a characteristic - it's some thing
that is regarded as a quality or feature of another thing.  In the STIX
language, an observable can be considered an attribute of the thing on which
the observable was observed.  To me, these terms (observable and attribute)
can be considered synonymous.  
>> misconfiguration -" A misconfiguration is a configuration setting that
violates organizational security policies, introduces a possible security
weakness in a system, or permits or causes unintended behavior that may
impact the security posture of a system. (from NIST IR       7670) The
misalignment of a unit of endpoint configuration posture relative to
organizational expectations that is subject to exploitation or misuse."
>> 
>> I don't see how this 'misconfiguration' can be part of 'posture', or an
attribute or an observable of a system.  A misconfiguration is something
that is the result of some analysis performed by a program or an analyst and
has to reference a specific policy that the configuration violates.  Is a
misconfiguration a diff between what the policy should be and what it was
discovered to be?
>> 
> 
> Generally, the endpoint attributes we look at are posture attributes and
these are "configuration items" (to load another term on the pile).  A
misconfiguration is simply an attribute set to an
organizationally-impermissible value (i.e. set against policy - see comment
above regarding policy in the SACM context).  
> 
> 
>> Regarding 'remediation':
>> 
>> "A remediation is defined as a security-related set of actions that
results in a change to a computer's state and may consist of changes
motivated by the need to enforce organizational security policies, address
discovered vulnerabilities, or correct misconfigurations. (from NIST IR
7670)."
>> 
>> I'm concerned that this definition of remediation is too broad.  From
what is written it would seem that remediation spans 'actions' that could
include adding or removing hardware or software to or changing the
configuration of a 'computer'.  I associate remediation with addressing
vulnerabilities and correcting misconfigurations.  I don't view a
remediation as being the word I'd use to describe changes made to enforce
organizational policies.  Do you have to remediate all the computers that
are your network if a decision is made to change software providers?
Clearly that could be an automation issue but is it a security automation
issue?
>> 
>> I'd suggest that a remediation should be a specific action or set of
actions that changes configuration to acceptable within organization'
policy.
> 
> This might be a good suggestion.  We could get into a semantic discussion
about whether a mitigation is a form of remediation, but for SACM's
immediate purposes remediation is out of scope.  This will be important
later in life.  For what it's worth, I think the term "remediation" probably
has origins in the IT audit domain where we talk about "findings" and such.
An auditor would probably provide a list of findings and each finding would
need to be "remediated" in a general sense, which is just another way of
saying that the finding needs to be addressed in some way.  But, as I said
before, remediation is out of scope for our present charter.
> 
>> 
>> In general I think we all see the linkage between SACM and NEA.  I think
there needs to be more review and discussion about the linkage between SACM
and MILE and other security operations and incident response initiatives
such as STIX and OpenIOC.
> 
> The links between SACM and MILE and STIX and OpenIOC and NEA and others
are very important.  Each provides at least one part of a "whole" set of
automated information security tools.  Ideally, each should inform the
others - you raise a great point.  In an ideal world, we'd all have a common
vocabulary from which we operate, but that's not the case.

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 01 Apr 2014 11:43:30 -0400

> What do others think of this?  Loosely, these may end up meaning the same thing.  I like the notion of including "policy" in the term as an explicit tie to the fact that we're assessing a target in…

How about compliant/non-compliant?

It's also necessary to differentiate between policy compliance and 
policy item compliance.

---

From: Adam Montville <[email-masked]>
Date: Tue, 1 Apr 2014 13:58:31 -0500

On Apr 1, 2014, at 10:43 AM, Gunnar Engelbach <[email-masked]> wrote:
> It's also necessary to differentiate between policy compliance and policy item compliance.
> 

I like compliant/non-compliant.  Not sure how others feel.

I’m not sure that we need to explicitly differentiate between policy compliance and policy item compliance, though.  I also don’t want to assume I understand what you mean…  Policy compliance = overall compliance in the context of all assessed items; policy item compliance = compliance to a specific assessed item.  Is that right?

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 16 Apr 2014 15:31:00 +0000

We have had previous discussions in this working group about compliant, misconfigured, vulnerable, and many other inferred conditions for an endpoint (or the related hw/sw) based on its posture. The past consensus was that we are not trying to make any qualitative judgment about the meaning of the comparison of actual (collected) state vs a definition of expected state. The use cases (use cases -06 section 2.1.4) that we have been developing address the mechanisms needed to determine this delta (actual vs expected), but do not go beyond this to characterize what a specific delta means.

Reading through this discussion thread, it appears as if we are driving terminology in a direction that goes beyond the consensus scope previously discussed in the working group. We may want to consider removing terms like: exposure, remediation, vulnerability, software flaw, vulnerability management to focus more broadly on the collection and evaluation of endpoint attributes for any purpose. This will make the work more relevant to all the possible uses and interpretations for an assessment delta.

What this would leave us with is: posture matching or not matching an expectation. This can be interpreted to mean any number of things depending on the intent of the guidance data driving the assessment process.

Thoughts?

Dave

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, April 01, 2014 2:59 PM
To: Gunnar Engelbach
Cc: [email-masked]; Brian Ford (brford)
Subject: Re: [sacm] Regarding SACM Terminology

On Apr 1, 2014, at 10:43 AM, Gunnar Engelbach <[email-masked]<mailto:[email-masked]>> wrote:

I'm not sure that we need to explicitly differentiate between policy compliance and policy item compliance, though.  I also don't want to assume I understand what you mean...  Policy compliance = overall compliance in the context of all assessed items; policy item compliance = compliance to a specific assessed item.  Is that right?

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 16 Apr 2014 12:03:31 -0400

+1.

I think it is important to keep the technology needed for collection and
comparison of attribute value sets  separate from the application-specific
interpretation of the results.

David Harrington

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

+1-603-828-1401

From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Wednesday, April 16, 2014 11:31 AM
To: Adam Montville; Gunnar Engelbach
Cc: [email-masked]; Brian Ford (brford)
Subject: Re: [sacm] Regarding SACM Terminology

We have had previous discussions in this working group about compliant,
misconfigured, vulnerable, and many other inferred conditions for an
endpoint (or the related hw/sw) based on its posture. The past consensus was
that we are not trying to make any qualitative judgment about the meaning of
the comparison of actual (collected) state vs a definition of expected
state. The use cases (use cases -06 section 2.1.4) that we have been
developing address the mechanisms needed to determine this delta (actual vs
expected), but do not go beyond this to characterize what a specific delta
means.

Reading through this discussion thread, it appears as if we are driving
terminology in a direction that goes beyond the consensus scope previously
discussed in the working group. We may want to consider removing terms like:
exposure, remediation, vulnerability, software flaw, vulnerability
management to focus more broadly on the collection and evaluation of
endpoint attributes for any purpose. This will make the work more relevant
to all the possible uses and interpretations for an assessment delta.

What this would leave us with is: posture matching or not matching an
expectation. This can be interpreted to mean any number of things depending
on the intent of the guidance data driving the assessment process.

Thoughts?

Dave

 

On Apr 1, 2014, at 10:43 AM, Gunnar Engelbach
<[email-masked]> wrote:

I'd like to see the definition of posture attribute tightened up to reflect
this and acknowledge that the 'posture attribute' is considered synonymous
with 'observable'.

I think misconfiguration should be out and policy exception should be used
instead.

It's also necessary to differentiate between policy compliance and policy
item compliance.

I'm not sure that we need to explicitly differentiate between policy
compliance and policy item compliance, though.  I also don't want to assume
I understand what you mean.  Policy compliance = overall compliance in the
context of all assessed items; policy item compliance = compliance to a
specific assessed item.  Is that right?

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 16 Apr 2014 17:58:28 +0000

Hi Dave,

In a perfect world, of course we would have all read and memorized the terminology draft:)

In that process we can define any word to me anything.

The challenge is where we are using word in the terminology has a preexisting definition, which we amending or extending that definition. This forces the reader (and author) to substitute the new meaning to correctly interpret the work.

The test for the terminology is not what we have agreed, but does the resultant terminology allow a reader to easily understand what we mean.

For example, we use assessment to mean the act of collection of posture data. Assessments base definition is however is to evaluate a value, to pass a judgment on what a value should be.

If there is an alternative description which means we do not need to have to redefine a word, we should use that . Posture Attribute Collection vs. Posture Assessment for example is   more verbose but it is a more natural usage.

Trevor

Sent: Wednesday, April 16, 2014 8:31 AM

Thoughts?

Dave

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, April 01, 2014 2:59 PM
To: Gunnar Engelbach
Cc: [email-masked]<mailto:[email-masked]>; Brian Ford (brford)
Subject: Re: [sacm] Regarding SACM Terminology

---

From: Adam Montville <[email-masked]>
Date: Wed, 16 Apr 2014 13:00:10 -0500

I generally agree.

We must provide some meaning behind what we are doing, and specifically in the context of security configuration assessment (this is, after all, the exact context of our charter).  Whether we seek to use terms like “vulnerability” or “exposure” seems of little import unless we seek to eventually describe a vulnerability in some way.  At the core of the problem we are still looking at some *thing* and determining whether the state of that thing is as we expect it to be.  

Because our work is in the context of security configuration assessment, however, it may be reasonable to entertain the possibility of adding a layer of context to results.  We have said that we will report results, but we have never determined *how* we would describe such a report.  

Please note that I am not suggesting that we go and create contextual specifications for every type of endpoint element assessment there is.  I am simply pointing out that doing so may arguably be within the scope of our charter, should the working group desire to include that type of information in results.

Adam

On Apr 16, 2014, at 11:03 AM, ietfdbh <[email-masked]> wrote:

> +1.
>  
> I think it is important to keep the technology needed for collection and comparison of attribute value sets  separate from the application-specific interpretation of the results.
>  
> David Harrington
> [email-masked]
> +1-603-828-1401