Subject: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 17 May 2016 18:42:17 +0000

During today's virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3].  The slide's from today's meeting can be found here [4].

The second issue was around clarifying the definition of "vulnerability detection data".  Specifically, whether or not "vulnerability detection data" was the representation of the "vulnerability description information" that is used by security tools to drive the vulnerability assessment process and, if so, is "vulnerability detection data" considered guidance.

During the meeting, after discussion, the general consensus was that "vulnerability detection data" represents the instructions that would be used by a SACM Component to assess an endpoint for vulnerabilities.  Furthermore, there was consensus that "vulnerability detection data" was considered guidance.  As a result, we would like to propose that the definition of "vulnerability detection data" be clarified to note that it is a type of guidance.

If you have any thoughts on this issue, please provide feedback by May 31st.  We are planning to have an updated version of the scenario for June 8th.

Thanks,

Danny

[1] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/
[2] https://github.com/sacmwg/vulnerability-scenario/pull/3
[3] https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html
[4] https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ (looks like the slides are not available just yet, but, I suspect they should be soon)

---

From: Adam Montville <[email-masked]>
Date: Thu, 19 May 2016 19:05:22 -0500

No objection here.

> On May 17, 2016, at 1:42 PM, Haynes, Dan <[email-masked]> wrote:
> 
> During today’s virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3].  The slide’s from today’s meeting can be found here [4].
> 
> The second issue was around clarifying the definition of “vulnerability detection data”.  Specifically, whether or not “vulnerability detection data” was the representation of the “vulnerability description information” that is used by security tools to drive the vulnerability assessment process and, if so, is “vulnerability detection data” considered guidance.
> 
> During the meeting, after discussion, the general consensus was that “vulnerability detection data” represents the instructions that would be used by a SACM Component to assess an endpoint for vulnerabilities.  Furthermore, there was consensus that “vulnerability detection data” was considered guidance.  As a result, we would like to propose that the definition of “vulnerability detection data” be clarified to note that it is a type of guidance.
> 
> [1] https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ <https://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/>
> [2] https://github.com/sacmwg/vulnerability-scenario/pull/3 <https://github.com/sacmwg/vulnerability-scenario/pull/3>
> [3] https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html <https://www.ietf.org/mail-archive/web/sacm/current/msg03958.html>
> [4] https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/ <https://datatracker.ietf.org/doc/slides-interim-2016-sacm-3-1/> (looks like the slides are not available just yet, but, I suspect they should be soon)
> 
> _______________________________________________
> sacm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 24 May 2016 11:43:07 +0000

Thanks Adam.  What do others think regarding the clarification to the definition of “vulnerability detection data”?

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, May 19, 2016 8:05 PM
To: Haynes, Dan <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

No objection here.

On May 17, 2016, at 1:42 PM, Haynes, Dan <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Danny

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

---

From: Michael Godsey <[email-masked]>
Date: Tue, 24 May 2016 14:26:15 +0000

We are having similar discussion in the ISO SC7/WG21 working group, regarding data/information definitions (specifically in 19770-1 WG).   Regarding definition of data vs. information, I’m a bit concerned with a definition of vulnerability data including guidance.   If the data represents some raw, collected thing which itself is used to do analysis and assessment, I can see that data can contain any number of things from raw measures of metric or attribute, to text regarding vulnerability impact, to a tag showing what version of a component is present, to instructions for an analysis tool do drive its process vulnerability assessment process.    However turning that data into information is the process of analysis.  Resulting information can be considered guidance, but I have a hard time thinking of the “data” itself as more than that which is used to drive analysis and resulting recommendation (information).

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Tuesday, May 24, 2016 4:43 AM
To: Adam Montville <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Thanks,

Danny

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, May 19, 2016 8:05 PM
To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

No objection here.

Thanks,

Danny

---

From: Adam Montville <[email-masked]>
Date: Tue, 24 May 2016 20:20:49 -0400

That’s an interesting perspective.  I’ve never been a fan of the term “guidance”, but it seems to be what has stuck so far in this group, and it also seems to apply.

The data, in this case vulnerability detection data, is providing instruction to a tool interpreting that data.  The instruction provided can be considered guidance - the data is telling the tool what to look for to detect the presence of a vulnerability and/or to detect its absence.

Is there something we’re missing?

> On May 24, 2016, at 10:26 AM, Michael Godsey <[email-masked]> wrote:
> 
>   <>
> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Adam Montville
> To: Haynes, Dan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On May 17, 2016, at 1:42 PM, Haynes, Dan <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Michael Godsey <[email-masked]>
Date: Wed, 25 May 2016 01:38:59 +0000

Possibly just the term “guidance” which for me is not quite the same as “instructions”, which sounds more like what is meant in this context.   Not a fan of the term either, I guess J  Guidance is something that helps make an informed decision, but which is analyze or reason through something,  and isn’t really 100% prescriptive.  However from what you just said, guidance is used more as detailed processing steps, or instructions.  If that is the understood meaning then I guess data can contain guidance, sure.

From: Adam Montville [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 5:21 PM
To: Michael Godsey <[email-masked]>
Cc: Haynes, Dan <[email-masked]>; [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

On May 24, 2016, at 10:26 AM, Michael Godsey <[email-masked]<mailto:[email-masked]>> wrote:

To: Adam Montville <[email-masked]<mailto:[email-masked]>>

Thanks,

Danny

No objection here.

Thanks,

Danny

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 24 May 2016 22:12:01 -0400

Hi Michael,

What might be more relevant (than what an obscure
ISO group is considering) is perhaps citation to the
suite of related specifications and definitions adopted
in ITU-T related to this subject - that are translated into
five other languages and freely available with
persistent URIs.

Additionally, OVAL, CVE and an array of mature vulnerability
assessment related specifications were brought into the ITU-T
over several years through the assistance of MITRE and multiple
U.S. government agencies for adoption globally and translation
into five other languages.  See
_X.1500_: /Overview of cybersecurity information exchange/ 
<rec.aspx?rec=11060>
*X.1520-X.1539*: Vulnerability/state exchange 
<javascript:__doPostBack('ctl00$content_result$tv_content','s388\\810\\812')>

		_X.1520_: /Common vulnerabilities and exposures/ <rec.aspx?rec=12040>

	
		_X.1521_: /Common vulnerability scoring system/ <rec.aspx?rec=12614>

	
		_X.1524_: /Common weakness enumeration/ <rec.aspx?rec=11374>

	
		_X.1525_: /Common weakness scoring system/ <rec.aspx?rec=12357>

	
		_X.1526_: /Language for the open definition of vulnerabilities and for 
the assessment of a system state/ <rec.aspx?rec=12039>

	
		_X.1528_: /Common platform enumeration/ <rec.aspx?rec=11610>

	
		_X.1528.1_: /Common platform enumeration naming/ <rec.aspx?rec=11611>

	
		_X.1528.2_: /Common platform enumeration name matching/ 
<rec.aspx?rec=11612>

	
		_X.1528.3_: /Common platform enumeration dictionary/ <rec.aspx?rec=11613>

	
		_X.1528.4_: /Common platform enumeration applicability language/ 
<rec.aspx?rec=11614>

Inquiring minds might also ask:
1) why the already existing use case work on this subject
isn't being used.  See
https://oval.mitre.org/adoption/usecasesguide.html#vulnerability
2) why considering that OVAL is central to this draft, the citations
don't reflect the transition of OVAL responsibility to CIS.  See
http://oval.mitre.org/

Yet there are all these new OVAL related IDs that are
floating through SACM.

Just trying to understand what is happening here.

cheers,
tony

On 2016-05-24 10:26 AM, Michael Godsey wrote:
>
> We are having similar discussion in the ISO SC7/WG21 working group, 
> regarding data/information definitions (specifically in 19770-1 
> WG).Regarding definition of data vs. information, I’m a bit concerned 
> with a definition of vulnerability data including guidance.If the data 
> represents some raw, collected thing which itself is used to do 
> analysis and assessment, I can see that data can contain any number of 
> things from raw measures of metric or attribute, to text regarding 
> vulnerability impact, to a tag showing what version of a component is 
> present, to instructions for an analysis tool do drive its process 
> vulnerability assessment process.However turning that data into 
> information is the process of analysis.Resulting information can be 
> considered guidance, but I have a hard time thinking of the “data” 
> itself as more than that which is used to drive analysis and resulting 
> recommendation (information).
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 25 May 2016 06:17:36 -0400

Fair enough.  At the same time, the beauty of the English language has “guidance” and “instruction” as being synonyms (by at least a couple of thesauri).

If we can agree that, in this case, guidance means instruction, we can probably keep moving.

> On May 24, 2016, at 9:38 PM, Michael Godsey <[email-masked]> wrote:
> 
> On May 24, 2016, at 10:26 AM, Michael Godsey <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: sacm [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Haynes, Dan
> To: Adam Montville <[email-masked] <mailto:[email-masked]>>

---

From: Adam Montville <[email-masked]>
Date: Wed, 25 May 2016 06:38:07 -0400

Hi Tony,

I’m not sure how your persistence here is more relevant than a working group participant trying to understand our approach to date.

In fact, I am trying to understand the perspective you seem to be taking by suggesting that participants in this working group are somehow unaware of the specifications and use cases that have been around in this problem domain for years (especially when many of our primary contributors may well have been authors or of or contributors to the original work).

If you would like to understand more about how CIS’ operation of the OVAL Repository and conservatorship of the OVAL Language can co-exist with OVAL-related I-Ds having been submitted to this working group, simply consider the existing deployment of OVAL-interpreting tools.  They need continued support while we do work to improve the state of the art in this working group.  If you would like to discuss this further, I’m happy to do so offline.

Kind regards,

Adam

> On May 24, 2016, at 10:12 PM, Tony Rutkowski <[email-masked]> wrote:
> 
> Hi Michael,
> 
> X.1500: Overview of cybersecurity information exchange <x-msg://10/rec.aspx?rec=11060>
> X.1520-X.1539: Vulnerability/state exchange <javascript:__doPostBack('ctl00$content_result$tv_content','s388\\810\\812')>
> 
> 	X.1520: Common vulnerabilities and exposures <x-msg://10/rec.aspx?rec=12040>
> 
> 
> 
> 	X.1521: Common vulnerability scoring system <x-msg://10/rec.aspx?rec=12614>
> 
> 
> 
> 	X.1524: Common weakness enumeration <x-msg://10/rec.aspx?rec=11374>
> 
> 
> 
> 	X.1525: Common weakness scoring system <x-msg://10/rec.aspx?rec=12357>
> 
> 
> 
> 	X.1526: Language for the open definition of vulnerabilities and for the assessment of a system state <x-msg://10/rec.aspx?rec=12039>
> 
> 
> 
> 	X.1528: Common platform enumeration <x-msg://10/rec.aspx?rec=11610>
> 
> 
> 
> 	X.1528.1: Common platform enumeration naming <x-msg://10/rec.aspx?rec=11611>
> 
> 
> 
> 	X.1528.2: Common platform enumeration name matching <x-msg://10/rec.aspx?rec=11612>
> 
> 
> 
> 	X.1528.3: Common platform enumeration dictionary <x-msg://10/rec.aspx?rec=11613>
> 
> 
> 
> 	X.1528.4: Common platform enumeration applicability language <x-msg://10/rec.aspx?rec=11614>
> https://oval.mitre.org/adoption/usecasesguide.html#vulnerability <https://oval.mitre.org/adoption/usecasesguide.html#vulnerability>
> http://oval.mitre.org/ <http://oval.mitre.org/>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 25 May 2016 08:04:49 -0400

Hi Adam,

FYI, I spent four years as Q4/17 rapporteur working with
the core developers of OVAL, helping turn it and related
specifications into a structured set of international
standard equivalents.  It is not altogether unfamiliar
territory.

What I'm pointing out is you have a confusing set of
inconsistent references (and in some cases, lack of
references) with essentially no explanation of what
is occurring.  That seems like a fair observation.

CIS' new role here is applauded.  Among other things,
tighter integration with the Critical Security Controls
can be effected.

--tony

ps. Transfer of SACM work to OASIS as a companion
to CTI also seems a good course of action.

On 2016-05-25 6:38 AM, Adam Montville wrote:
> In fact, I am trying to understand the perspective you seem to be 
> taking by suggesting that participants in this working group are 
> somehow unaware of the specifications and use cases that have been 
> around in this problem domain for years (especially when many of our 
> primary contributors may well have been authors or of or contributors 
> to the original work).
>
> If you would like to understand more about how CIS’ operation of the 
> OVAL Repository and conservatorship of the OVAL Language can co-exist 
> with OVAL-related I-Ds having been submitted to this working group, 
> simply consider the existing deployment of OVAL-interpreting tools. 
>  They need continued support while we do work to improve the state of 
> the art in this working group.  If you would like to discuss this 
> further, I’m happy to do so offline.
>

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 26 May 2016 13:43:45 +0000

The current definition of “guidance” [1] is:

 Input to processes and tasks, such as collecting, assessing or reporting. Guidance influences the behavior of a SACM component and is considered content of the management plane. Guidance can be manually or automatically generated or provided. Typically, the tasks that provide guidance to SACM components have a low-frequency and tend to be be sporadic. A prominent example of guidance are target endpoint profiles, but guidance can have many forms, including:

: Configuration, e.g. a SACM component's name, or a CMDB's IPv6 address.

: Profiles, e.g. a set of expected states for network behavior associated with target endpoints employed by specific users.

: Policies, e.g. an interval to refresh the registration of a SACM component, or a list of required capabilities for SACM components in a specific location.

Maybe we should make a minor revision to the definition to make it more clear.  Maybe something as simple as the following?

“Input instructions to processes and tasks, such as collecting, assessing, or reporting…“
Thoughts?

Thanks,

Danny

[1] https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md

Sent: Wednesday, May 25, 2016 6:18 AM

On May 24, 2016, at 9:38 PM, Michael Godsey <[email-masked]<mailto:[email-masked]>> wrote:

Possibly just the term “guidance” which for me is not quite the same as “instructions”, which sounds more like what is meant in this context.   Not a fan of the term either, I guess ☺  Guidance is something that helps make an informed decision, but which is analyze or reason through something,  and isn’t really 100% prescriptive. However from what you just said, guidance is used more as detailed processing steps, or instructions.  If that is the understood meaning then I guess data can contain guidance, sure.

From: Adam Montville [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 5:21 PM
To: Michael Godsey <[email-masked]<mailto:[email-masked]>>
Cc: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Thanks,

Danny

No objection here.

Thanks,

Danny

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 26 May 2016 13:49:36 +0000

+1. This sounds reasonable to me.

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Thursday, May 26, 2016 9:44 AM
To: Adam Montville <[email-masked]>; Michael Godsey <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Thanks,

Danny

Thanks,

Danny

No objection here.

Thanks,

Danny

---

From: Michael Godsey <[email-masked]>
Date: Thu, 26 May 2016 14:25:02 +0000

Agreed.

From: Waltermire, David A. (Fed) [mailto:[email-masked]]
Sent: Thursday, May 26, 2016 6:50 AM
To: Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; Michael Godsey <[email-masked]>
Cc: [email-masked]
Subject: RE: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Thanks,
Dave

To: Adam Montville <[email-masked]<mailto:[email-masked]>>; Michael Godsey <[email-masked]<mailto:[email-masked]>>

Thanks,

Danny

Thanks,

Danny

No objection here.

Thanks,

Danny

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 26 May 2016 11:24:07 -0400

Hi Dan,

Out of curiosity, any inclusion of LISP
addresses and bindings?  They are likely
to be far more pervasive than IPv6 -
especially in NFV environments.

--tony

---

From: "Haynes, Dan" <[email-masked]>
Date: Thu, 26 May 2016 15:29:59 +0000

Not that I know of at this point.  However, this sounds like a request for a new information element in the IM :).

Thanks,

Danny

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Thursday, May 26, 2016 11:24 AM
To: Haynes, Dan <[email-masked]>; Adam Montville <[email-masked]>; Michael Godsey <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Hi Dan,

--tony

---

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 27 May 2016 10:23:51 +0000

Hi Tony,

Just as a heads up, I added a tracker item to create an IE for LISP addresses and bindings [1].

If you have any information (references, etc.) that would be helpful in creating the IE or thoughts on how you might want it to be represented, please include them in the tracker.

Thanks,

Danny

[1] https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/42

From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
Sent: Thursday, May 26, 2016 11:30 AM
To: [email-masked]; Adam Montville <[email-masked]>; Michael Godsey <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] FOR REVIEW: Vulnerability Assessment Scenario Issue #2 - Clarifying Vulnerability Detection Data

Thanks,

Danny

To: Haynes, Dan <[email-masked]<mailto:[email-masked]>>; Adam Montville <[email-masked]<mailto:[email-masked]>>; Michael Godsey <[email-masked]<mailto:[email-masked]>>

Hi Dan,

--tony

---

From: Adam Montville <[email-masked]>
Date: Fri, 27 May 2016 06:45:25 -0400

+1

> On May 26, 2016, at 10:25 AM, Michael Godsey <[email-masked]> wrote:
> 
> Agreed.
>   <>
> To: Adam Montville <[email-masked] <mailto:[email-masked]>>; Michael Godsey <[email-masked] <mailto:[email-masked]>>
> [1] https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md <https://github.com/sacmwg/draft-ietf-sacm-terminology/blob/master/draft-ietf-sacm-terminology.md>
> 
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>]
> To: Michael Godsey <[email-masked] <mailto:[email-masked]>>
> Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On May 24, 2016, at 9:38 PM, Michael Godsey <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Adam Montville [mailto:[email-masked] <mailto:[email-masked]>]
> To: Michael Godsey <[email-masked] <mailto:[email-masked]>>
> Cc: Haynes, Dan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 27 May 2016 12:02:53 -0400

With charity beginning at home so to speak,
you certainly want to cite the copious materials
in the lisp working group of IETF.
https://datatracker.ietf.org/wg/lisp/charter/
There are some great current presentations
from the most recent lisp WG meeting.

There is rather considerable material
available with a simple search on LISP
use in virtualized networks.  See, e.g.,
https://www.ietf.org/proceedings/88/slides/slides-88-lisp-7.pdf
Cisco folk have some great tutorials.  It's
already been embedded in two NFV specs
out of EVE and SWA:
GS NFV-EVE 005 V1.1.1 (2015-12)
GS NFV-SWA 001 V1.1.1 (2014-12).

My LISP friends say that LISP traffic exceeds
IPv6, but that not verifiable.

--tony

On 2016-05-27 6:23 AM, Haynes, Dan wrote:
> If you have any information (references, etc.) that would be helpful 
> in creating the IE or thoughts on how you might want it to be 
> represented, please include them in the tracker.
>