Subject: [sacm] Comments on SACM Terminology draft

From: Trevor Freeman <[email-masked]>
Date: Fri, 7 Mar 2014 16:48:43 +0000

Hi Dave,

Here are some suggestions for simplifying or clarify the SACM terminology draft. I think these definitions are a more  consistent with the other definitions.

Endpoint
This definition needs to be expanded to include virtual devices as well as physical devices.  I would also replace "IP Address" with the more general "network address".
Exposure
"An endpoint misconfiguration or software flaw that allows an attacker a means to compromise an endpoint or network"
Posture
I think overloading Posture to be both the state of the endpoint as well as the data representing the state of the endpoint will lead to misunderstandings. You have Posture Attributes so why the need to overload Posture ?
Remediation
"A set of actions that results in a change to an endpoint's Posture to address an exposure"
Software Flaw
"A   feature in software that results in an exposure"
Vulnerability
"A state of configuration or software flaw which results in an exposure"
Vulnerability Management
"The process of remediating vulnerabilities on endpoints"

Trevor

---

From: Adam Montville <[email-masked]>
Date: Sat, 8 Mar 2014 19:03:42 -0600

Trevor, many good suggestions here, thank you.  I have a couple of comments inline (as contributor).

On Mar 7, 2014, at 10:48 AM, Trevor Freeman <[email-masked]> wrote:

> This definition needs to be expanded to include virtual devices as well as physical devices.  I would also replace “IP Address” with the more general “network address”.

I like the suggestion of replacing "IP Address" with "network address."  To me, explicitly mentioning physical or virtual would be a mistake - if it's network addressable, then it can be classified as an endpoint.

> Exposure
> “An endpoint misconfiguration or software flaw that allows an attacker a means to compromise an endpoint or network”

This definition seems good.  How would "exposure" differ from "vulnerability"?  More specifically, because we're dealing with configuration assessment we're talking about configuration vulnerabilities or misconfigurations.  It seems that the presence of a misconfiguration or software vulnerability alone is not sufficient to state that the asset or software is "exposed". 

> I think overloading Posture to be both the state of the endpoint as well as the data representing the state of the endpoint will lead to misunderstandings. You have Posture Attributes so why the ne…

To me, this is more nuanced than it might seem.  Posture has a "security feel" to it.  The overall state of an endpoint (a composite of states) may be a superset of what we consider to be "posture".  It has been my experience that security-relevant configurations and attributes are considered posture.

> Remediation
> “A set of actions that results in a change to an endpoint’s Posture to address an exposure”

This is generally correct.  Would it be beneficial to include some language about correcting the misconfiguration in compliance with an expected value?  Of course, we're talking about "exposure" here, which may be mitigated without actual remediation, which is not remediation at all.

> Software Flaw
> “A   feature in software that results in an exposure”

s/exposure/vulnerability ?  This may be more nuanced as well, because a flaw in software may not be a vulnerability.

> Vulnerability
> “A state of configuration or software flaw which results in an exposure”

Hmm...  The more I'm looking at these terms the more I'm wondering how an exposure is distinguished from a vulnerability.  A software flaw may result in vulnerable software - software that, so long as the flaw exists, may be vulnerable to some threat.  Similarly, a misconfiguration may result in a vulnerable asset - an asset that, so long as the misconfiguration exists, may be vulnerable to some threat.  The software/asset is only vulnerable if it is exposed to the threat, and there may be mitigating circumstances that preclude such an exposure.

> Vulnerability Management
> “The process of remediating vulnerabilities on endpoints”

s/remediating/mitigating

I definitely like inclusion of "process" in this definition.

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

---

From: Jerome Athias <[email-masked]>
Date: Sun, 9 Mar 2014 10:34:39 +0300

Hi,

definitely something to address.
Very simple definitions (from TARA) fyi:

Vulnerability: Part of the information security infrastructure that
could represent a weakness to attack in the absence of a control.

Control: Tools, processes, and measures put in place to reduce the
risk of loss due to a vulnerability.

Exposure: Vulnerability without a control.

NB:
For me, Weakness needs to be introduced (I prefer Weakness to Flaw,
especially for CM) as different from Vulnerability (Weakness +
Exposure => Vulnerability)
i.e. I see password brute force susceptibility as a weak
configuration, not a vulnerability

For me, there is also a difference between mitigation (i.e. risk
acceptance) and remediation.
i.e. You could have a waiver for a weakness, or compensative controls
as part of the vulnerability management (so this is not just
"remediating vulnerabilities")

The primary methods of remediation are development/installation of a
software patch, adjustment of a configuration setting and removal of
affected software.

Regards

---

From: Trevor Freeman <[email-masked]>
Date: Sun, 9 Mar 2014 23:29:46 +0000

Hi Adam,

Another term I am having trouble with is the use of assessment to mean simple collection of posture attributes. The normal use of assessment involves making a value judgment not simple collection i.e.  a tax assessor is a different function  to tax collector. When reading Nancy's requirements draft I often had to re-read sentences remembering the sacm definition because I kept defaulting to the normal use meaning. 

See inline below

Trevor

-----Original Message-----
From: Adam Montville [mailto:[email-masked]] 
Sent: Saturday, March 08, 2014 5:04 PM
To: Trevor Freeman
Cc: Dave Waltermier; [email-masked]
Subject: Re: [sacm] Comments on SACM Terminology draft

I like the suggestion of replacing "IP Address" with "network address."  To me, explicitly mentioning physical or virtual would be a mistake - if it's network addressable, then it can be classified as an endpoint.
[TF] The examples all cited in the definition are all physical devices which is not what we are meaning so we do need to make it clear somehow that virtual devise are included.

This definition seems good.  How would "exposure" differ from "vulnerability"?  More specifically, because we're dealing with configuration assessment we're talking about configuration vulnerabilities or misconfigurations.  It seems that the presence of a misconfiguration or software vulnerability alone is not sufficient to state that the asset or software is "exposed". 
[TF] I agree there seems to be a lot of overlap between exposure and vulnerability. Unless there is some compelling difference we should eliminate one of the terms. 

[TF] I agree with your interpretation of posture. It does have a security feel to it as you say. I am fine with its use where we mean the posture of the endpoint itself. Where I see the confusion is when we try and make it also mean the set of attributes that describe the posture of the device. 

This is generally correct.  Would it be beneficial to include some language about correcting the misconfiguration in compliance with an expected value?  Of course, we're talking about "exposure" here, which may be mitigated without actual remediation, which is not remediation at all.
[TF] I don't think the addition helps as any change has to be to an specific value. If not you consider the changes process was unsuccessful.

s/exposure/vulnerability ?  This may be more nuanced as well, because a flaw in software may not be a vulnerability.
[TF] I agree with the nuance. Whatever adjective we pick here is trying to mean a subclass of software bugs that results in an exposure. Maybe we should stick to the term software vulnerability rather than software flaw. 

s/remediating/mitigating

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 10 Mar 2014 12:58:01 +0100

I'd second this. Maybe it would help to just differentiate between the 
terms "attribute assessment" and "attribute acquisition"?

Best,

Henk

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 10 Mar 2014 09:25:11 -0400

Hi,

I don't have time to check this right now.
Didn't we make a distinction between these in the use-cases draft?
We should make sure the three drafts are in sync on that.

David Harrington
[email-masked]
+1-603-828-1401
> From: sacm [mailto:[email-masked]] On Behalf Of Trevor Freeman
> Sent: Sunday, March 09, 2014 7:30 PM
> To: Adam Montville
> Another term I am having trouble with is the use of assessment to mean
> simple collection of posture attributes. The normal use of assessment
> involves making a value judgment not simple collection i.e.  a tax
assessor is a
> different function  to tax collector. When reading Nancy's requirements
draft
> I often had to re-read sentences remembering the sacm definition because I
> kept defaulting to the normal use meaning.
> 
> See inline below
> 
> Trevor
> 
> > Here are some suggestions for simplifying or clarify the SACM
terminology
> draft. I think these definitions are a more  consistent with the other
> definitions.
> >
> > Endpoint
> > This definition needs to be expanded to include virtual devices as well
as
> physical devices.  I would also replace "IP Address" with the more general
> "network address".
> 
> I like the suggestion of replacing "IP Address" with "network address."
To
> me, explicitly mentioning physical or virtual would be a mistake - if it's
> network addressable, then it can be classified as an endpoint.
> [TF] The examples all cited in the definition are all physical devices
which is
> not what we are meaning so we do need to make it clear somehow that
> virtual devise are included.
> 
> > Exposure
> > "An endpoint misconfiguration or software flaw that allows an attacker a
> means to compromise an endpoint or network"
> 
> This definition seems good.  How would "exposure" differ from
> "vulnerability"?  More specifically, because we're dealing with
configuration
> assessment we're talking about configuration vulnerabilities or
> misconfigurations.  It seems that the presence of a misconfiguration or
> software vulnerability alone is not sufficient to state that the asset or
> software is "exposed".
> [TF] I agree there seems to be a lot of overlap between exposure and
> vulnerability. Unless there is some compelling difference we should
> eliminate one of the terms.
> 
> > Posture
> > I think overloading Posture to be both the state of the endpoint as well
as
> the data representing the state of the endpoint will lead to
> misunderstandings. You have Posture Attributes so why the need to
> overload Posture ?
> 
> To me, this is more nuanced than it might seem.  Posture has a "security
feel"
> to it.  The overall state of an endpoint (a composite of states) may be a
> superset of what we consider to be "posture".  It has been my experience
> that security-relevant configurations and attributes are considered
posture.
> 
> [TF] I agree with your interpretation of posture. It does have a security
feel
> to it as you say. I am fine with its use where we mean the posture of the
> endpoint itself. Where I see the confusion is when we try and make it also
> mean the set of attributes that describe the posture of the device.
> 
> > Remediation
> This is generally correct.  Would it be beneficial to include some
language
> about correcting the misconfiguration in compliance with an expected
value?
> Of course, we're talking about "exposure" here, which may be mitigated
> without actual remediation, which is not remediation at all.
> [TF] I don't think the addition helps as any change has to be to an
specific
> value. If not you consider the changes process was unsuccessful.
> 
> 
> > Software Flaw
> s/exposure/vulnerability ?  This may be more nuanced as well, because a
> flaw in software may not be a vulnerability.
> [TF] I agree with the nuance. Whatever adjective we pick here is trying to
> mean a subclass of software bugs that results in an exposure. Maybe we
> should stick to the term software vulnerability rather than software flaw.
> 
> 
> > Vulnerability
> Hmm...  The more I'm looking at these terms the more I'm wondering how an
> exposure is distinguished from a vulnerability.  A software flaw may
result in
> vulnerable software - software that, so long as the flaw exists, may be
> vulnerable to some threat.  Similarly, a misconfiguration may result in a
> vulnerable asset - an asset that, so long as the misconfiguration exists,
may
> be vulnerable to some threat.  The software/asset is only vulnerable if it
is
> exposed to the threat, and there may be mitigating circumstances that
> preclude such an exposure.
> 
> > Vulnerability Management

---

From: Adam Montville <[email-masked]>
Date: Mon, 10 Mar 2014 09:07:38 -0500

> We should make sure the three drafts are in sync on that.

+1 - term definitions and use must be synchronized across our documents.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:29:54 +0000

Hi,

Please see my comments below:

On 3/8/14 5:03 PM, "Adam Montville" <[email-masked]> wrote:

>>terminology draft. I think these definitions are a more  consistent with
>>the other definitions.
>>  
>> Endpoint
>>as physical devices.  I would also replace ³IP Address² with the more
>>general ³network address².
>
>To me, explicitly mentioning physical or virtual would be a mistake - if
>it's network addressable, then it can be classified as an endpoint.
[NCW] I'm OK with making these adjustments as extensions.  I'll add a new
sentence to also include "To further clarify the [RFC5209] definition, it
is any physical or virtual device that may have a network address."

>
>> Exposure
>> ³An endpoint misconfiguration or software flaw that allows an attacker
>>a means to compromise an endpoint or network²
>
>configuration assessment we're talking about configuration
>vulnerabilities or misconfigurations.  It seems that the presence of a
>misconfiguration or software vulnerability alone is not sufficient to
>state that the asset or software is "exposed".
[NCW] Both Exposure and Vulnerability are defined in RFC 4949.  Exposure
is defined as "A type of threat action whereby sensitive data is directly
released to an unauthorized entity." and some examples are enumerated.
Vulnerability is more a design, implementation or operation flaw that can
be exploitedŠ  I think referencing these definitions help make that
distinction.

> 
>
>> Posture
>> I think overloading Posture to be both the state of the endpoint as
>>well as the data representing the state of the endpoint will lead to
>feel" to it.  The overall state of an endpoint (a composite of states)
>may be a superset of what we consider to be "posture".  It has been my
>experience that security-relevant configurations and attributes are
>considered posture.
[NCW] I tend to agree with Adam's view of thisŠ..

>
>> Remediation
>> ³A set of actions that results in a change to an endpoint¹s Posture to
>>address an exposure²
>
>language about correcting the misconfiguration in compliance with an
>expected value?  Of course, we're talking about "exposure" here, which
>may be mitigated without actual remediation, which is not remediation at
>all.
[NCW] I would prefer that we continue to reference accepted definitions.
I think the definition provided was taken from a NIST documentŠ.but I will
leave it to group consensus as I like simple definitions as well (as
suggested by Trevor).

>
>> Software Flaw
>> ³A   feature in software that results in an exposure²
>
>> ³A state of configuration or software flaw which results in an exposure²
>
>result in vulnerable software - software that, so long as the flaw
>exists, may be vulnerable to some threat.  Similarly, a misconfiguration
>may result in a vulnerable asset - an asset that, so long as the
>misconfiguration exists, may be vulnerable to some threat.  The
>software/asset is only vulnerable if it is exposed to the threat, and
>there may be mitigating circumstances that preclude such an exposure.
>
>> Vulnerability Management
>> ³The process of remediating vulnerabilities on endpoints²
>
>s/remediating/mitigating
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:29:59 +0000

We are trying to synchronize them :-)

Section 2 of the Use Cases (v6) describes the intent behind Posture
Assessment which admitted includes the collection of posture attributes.
Perhaps the fuzziness comes from the RFC 5209 definition of a posture
attribute being both the "raw data" as well as the "evaluated data" (e.g.
The configuration or status of an endpoint feature)?

	Nancy.