Subject: [sacm] Feedback on vulnerability management use case

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 02 Aug 2013 20:27:49 -0400

After talking with Eliot today after the WG meeting, I think my comments
regarding vulnerability management were unclear.  I'd like to clarify
and still see if people think this is out of scope.

I am not asking to standardize vulnerability assessment per se (meaning
standardize IPS signatures).  What I am asking is whether or not SACM
needs to define a new (or standardize an existing) data model to
describe a vulnerability for purposes of efficient interchange?

My argument for "yes" is that if I am to learn about things like device
type, hardware version, software version, place in network,
configuration, etc. how can I effectively build a policy around security
posture if I do not know what vulnerabilities exist?  If we have a way
to exchange descriptions of vulnerabilities, it would enable consistent
communication to a vulnerability repository as described in the charter.
 To me, this directly goes towards posture assessment.

I don't see this as being in scope for MILE, so I wonder if this is out
of scope for SACM, would SACM disregard this type of model, point to an
existing, non-IETF model, look to tackle this in a future re-charter, or
...?

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Jerome Athias <[email-masked]>
Date: Sat, 3 Aug 2013 11:13:09 +0200

Hi,

i am interested by this and would be happy to talk about it.
So yes, we need an answer on if it is in the scope for SACM.

2013/8/3 Joe Marcus Clarke <[email-masked]>

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 4 Aug 2013 13:17:42 +0000

Hi,

The charter talks about information on vulnerabilities and vulnerability management. I agree that the system needs to be aware about existing vulnerabilities, I am not sure whether the description of vulnerabilities needs to be defined in this working group. According to the wording in the charter

Ø  content repositories are expected
to store up-to-date dictionary of specific enumerations, such as those
used for configuration element identifiers, asset classifications,
vulnerability identifiers, and so on.

so it seems to be more about defining a format for vulnerability identifiers rather than semantics for vulnerability descriptions.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Saturday, August 03, 2013 12:13 PM
To: Joe Marcus Clarke
Cc: [email-masked]
Subject: Re: [sacm] Feedback on vulnerability management use case

Hi,

2013/8/3 Joe Marcus Clarke <[email-masked]<mailto:[email-masked]>>
After talking with Eliot today after the WG meeting, I think my comments
regarding vulnerability management were unclear.  I'd like to clarify
and still see if people think this is out of scope.

Joe

--
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867<tel:%2B1%20%28919%29%20392-2867>         c i s c o  S y s t e m s
Email: [email-masked]<mailto:[email-masked]>

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

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 04 Aug 2013 13:19:54 -0400

On 8/4/13 9:17 AM, Romascanu, Dan (Dan) wrote:
> Hi,
> 
>  
> 
> The charter talks about information on vulnerabilities and vulnerability
> management. I agree that the system needs to be aware about existing
> vulnerabilities, I am not sure whether the description of
> vulnerabilities needs to be defined in this working group. According to
> the wording in the charter
> 
>  
> 
> so it seems to be more about defining a format for vulnerability
> identifiers rather than semantics for vulnerability descriptions.

Hmmm....Above what you quote (in the charter) it talks about interfacing
with these repositories to store, update, and retrieve posture
assessment content that may be used for vulnerability management (I
paraphrased).  While an identifier alone might be sufficient for
retrieval, storing new data about a vulnerability would imply (to me
anyway) a common data model for the vulnerability itself.

Joe

---

From: Adam Montville <[email-masked]>
Date: Sun, 4 Aug 2013 18:05:57 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joe Marcus Clarke
> Sent: Sunday, August 04, 2013 10:20 AM
> To: Romascanu, Dan (Dan)
> Cc: Jerome Athias; [email-masked]
> > The charter talks about information on vulnerabilities and
> > vulnerability management. I agree that the system needs to be aware
> > about existing vulnerabilities, I am not sure whether the description
> > of vulnerabilities needs to be defined in this working group.
> > According to the wording in the charter
> >
> >
> >
> with these repositories to store, update, and retrieve posture assessment
> content that may be used for vulnerability management (I paraphrased).
> While an identifier alone might be sufficient for retrieval, storing new data
> about a vulnerability would imply (to me

I think you both have valid points the working group may eventually need to consider.  At this point, we need to get the use cases figured out, consider which use cases we need to entertain, and then move forward from there.  

I'm sure the WG would consider a use case for updating/augmenting vulnerability context for inclusion in this chartered work or to, at least, consider for later phases.

Additionally, I'd like to call attention to the terminology of "vulnerability" and that we, typically, mean software vulnerability by it.  It might be more precise to call say so explicitly.  There are many categories of vulnerabilities: Software, configuration, policy, process, etc.  From my perspective, it makes complete sense to be pedantic and state explicitly the type of vulnerabilities we are interested in rather than assuming one type over another.

> ...

. . .

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 04 Aug 2013 14:12:07 -0400

> I think you both have valid points the working group may eventually need to consider.  At this point, we need to get the use cases figured out, consider which use cases we need to entertain, and th…

The reason I brought this up is that one use case for me in
vulnerability management, as a vendor, is to be able to publish my
vulnerabilities in a way that can be consumed by customers and
potentially other vendors (I'm thinking of OEMs) and vice versa.

> Additionally, I'd like to call attention to the terminology of "vulnerability" and that we, typically, mean software vulnerability by it.  It might be more precise to call say so explicitly.  There…

I think that's fair.  I was operating under a similar understanding of
vulnerability.

Joe

---

From: Gunnar Engelbach <[email-masked]>
Date: Sun, 04 Aug 2013 15:57:16 -0400

As Adam says, we'll want to go through the use case/requirements process 
and determine exactly what this working group is going to focus on, but 
I'll mention for now that the initial focus is security automation, 
which is deliberately non-specific.  It's hard to imagine we won't, at a 
bare minimum, allow for automated assessment of software vulnerabilities 
and configuration compliance, but I think the goal is more to create 
tools sets that have the possibility of being used for other purposes as 
well.

--gun

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 6 Aug 2013 07:43:19 -0400

For vulnerability information, there have been 2 efforts discussed previously to bring to the IETF.  NIST submitted the following draft, that I am sure if it is of interest could be updated (no longer expired):
http://tools.ietf.org/html/draft-booth-sacm-vuln-model-01

There was also talk of CVRF coming into the IETF, possible in MILE since it is related to that work.  This has not happened yet and I don't have a current plan for them.

Best regards,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gunnar Engelbach [[email-masked]]
Sent: Sunday, August 04, 2013 3:57 PM
To: Joe Marcus Clarke
Cc: Romascanu, Dan (Dan); Jerome Athias; Adam Montville; [email-masked]
Subject: Re: [sacm] Feedback on vulnerability management use case

--gun

---

From: Jerome Athias <[email-masked]>
Date: Tue, 6 Aug 2013 14:50:13 +0200

Hi,

A Vulnerability Model is included in the XORCISM model
http://www.frhack.org/research/xorcism.php
As it is implemented, and used, it stores for example all CVEs, and other
software vulnerabilities repositories
It could be easily used also for other forms of vulnerabilities

I would be happy to extract it to share and discuss it

Best regards

2013/8/6 Moriarty, Kathleen <[email-masked]>

> For vulnerability information, there have been 2 efforts discussed
> previously to bring to the IETF.  NIST submitted the following draft, that
> I am sure if it is of interest could be updated (no longer expired):
> There was also talk of CVRF coming into the IETF, possible in MILE since
> it is related to that work.  This has not happened yet and I don't have a
> current plan for them.
>
> Best regards,
> Kathleen
> From: [email-masked] [[email-masked]] On Behalf Of Gunnar
> Engelbach [[email-masked]]
> assessment
> >> I think you both have valid points the working group may eventually
> need to consider.  At this point, we need to get the use cases figured out,
> consider which use cases we need to entertain, and then move forward from
> there.
> >> I'm sure the WG would consider a use case for updating/augmenting
> vulnerability context for inclusion in this chartered work or to, at least,
> consider for later phases.
> >>
> >> Additionally, I'd like to call attention to the terminology of
> "vulnerability" and that we, typically, mean software vulnerability by it.
>  It might be more precise to call say so explicitly.  There are many
> categories of vulnerabilities: Software, configuration, policy, process,
> etc.  From my perspective, it makes complete sense to be pedantic and state
> explicitly the type of vulnerabilities we are interested in rather than
> assuming one type over another.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 06 Aug 2013 11:34:54 -0400

> There was also talk of CVRF coming into the IETF, possible in MILE since it is related to that work.  This has not happened yet and I don't have a current plan for them.

I would support CVRF coming into the IETF, but I think it fits more with
SACM, honestly, given how I've read the charter and a need for this
vulnerability management concept.

Joe

---

From: Chris Inacio <[email-masked]>
Date: Tue, 13 Aug 2013 16:03:10 +0000

> existing, non-IETF model, look to tackle this in a future re-charter, or

Joe,

Let me attempt to inject a little more context, and you can tell me if I'm off track, because I'm trying to understand your original comments.

Is what you are looking to accomplish is a little more complex than just saying "X has vulnerability Y"  such that you can understand that "Windows Server 2008 R2 has a *remotely exploitable* software vulnerability on port 12345" such that you can include within the framework a mitigation that might include say putting a Cisco :) firewall in front of said Windows Server in the network to remediate the said vulnerability?  So that SACM supports not just saying "patch X with software level N+1", but that "Vuln Y on X is mitigated by device P"?

Is that the intent?

I like the idea of the generic IDS/IPS language though…  :) 

--
Chris Inacio
[email-masked]

---

From: Eric Walker <[email-masked]>
Date: Tue, 13 Aug 2013 10:42:00 -0600

Hi,

It is easy to split hairs on the distinction between a "vulnerability," a "misconfiguration," a patch check, and other, similar concepts.  There are good reasons for distinguishing these things -- a vulnerability can be addressed in any number of ways, e.g., by removing the host from the network, by blocking a port in the firewall, etc., so detecting or addressing a vulnerability is not always a simple matter of applying a patch, updating software or toggling a security-related setting.

But we know from experience that many vulnerabilities that go back to the state of an endpoint can be detected using the same means that are used to detect deviations from security policy or missing OS patches or out-of-date software.  I'm concerned that if we make too fine a distinction between these different use cases, we'll set ourselves up for parallel standards that overlap in important ways.  This is something to be avoided.

Eric

>On Aug 2, 2013, at 8:27 PM, Joe Marcus Clarke <[email-masked]>

[...]

---

From: David Harrington <[email-masked]>
Date: Wed, 14 Aug 2013 17:09:52 -0400

Can you provide proposed text for the document?
--
David Harrington
[email-masked]
+1-603-828-1401

On 8/13/13 12:42 PM, "Eric Walker" <[email-masked]> wrote:

>Hi,
>
>It is easy to split hairs on the distinction between a "vulnerability," a
>"misconfiguration," a patch check, and other, similar concepts.  There
>are good reasons for distinguishing these things -- a vulnerability can
>be addressed in any number of ways, e.g., by removing the host from the
>network, by blocking a port in the firewall, etc., so detecting or
>addressing a vulnerability is not always a simple matter of applying a
>patch, updating software or toggling a security-related setting.
>
>But we know from experience that many vulnerabilities that go back to the
>state of an endpoint can be detected using the same means that are used
>to detect deviations from security policy or missing OS patches or
>out-of-date software.  I'm concerned that if we make too fine a
>distinction between these different use cases, we'll set ourselves up for
>parallel standards that overlap in important ways.  This is something to
>be avoided.
>
>Eric
>
>
>

---

From: Eric Walker <[email-masked]>
Date: Thu, 15 Aug 2013 10:21:27 -0600

My comments were of a general nature and were addressing points raised by Joe Marcus Clark, below, and others.  I assume this thread is commenting on the use cases, but I'm not sure.

There is this paragraph in version 5 of the use cases:

Vulnerability management involves identifying the patch level of software installed on the device and the identification of insecure custom code (e.g. web vulnerabilities).  All vulnerabilities need to be addressed as part of a comprehensive risk management program, which is a superset of software vulnerabilities.  Thus, the capability of assessing non-software vulnerabilities applicable to the system is required.  Additionally, it may be necessary to support non-technical assessment of data relating to assets such as aspects related to operational and management controls.

The first sentence seems fine to me if we understand SACM's scope to be restricted to vulnerabilities that go back to the state of an endpoint.  To capture the recent thread, perhaps we would want something like this:

A vulnerability is generally understood to refer to a situation that will facilitate the compromise of a network or an endpoint.  Some vulnerabilities relate to processes and network topologies, while others go back to the state of individual endpoints and can be inferred from their patch level, whether they have up-to-date software, and so on.  A comprehensive risk management program may try to take into account all of these kinds of vulnerabilities, and effort should be made to anticipate how such a program might work in the real world so that the SACM work will integrate well with such efforts.  In the context of software running on an endpoint, a "vulnerability" is often closely related to the operating system patch level, the versions of programs installed and the configuration of settings.  While it would be difficult to define the term precisely, an important area of security automation involves identifying and addressing vulnerabilities on endpoints.  [etc.]

This is more food for thought than a suggestion for the actual wording.

There is one other issue with the above paragraph, however (I have not had a chance to review the full document).  I notice that we're trying to pick up both software vulnerabilities and vulnerabilities that require a questionnaire or other human workflow of some kind to identify.  This is analogous to the division of labor between OVAL and OCIL, to give two examples.  I am sure that there is a need for a way to systematically identify and address vulnerabilities that require some kind of human-driven workflow, and that this is a pressing one.  But the two sets of processes work on very different timescales and have somewhat different needs.  It was an architectural mistake, in my opinion, for XCCDF to attempt to include reference to both OVAL and OCIL in the same benchmark and for the SCAP program to hang the possibility at one point that vendors would need to provide support for both sets of processes in their tools.  I would urge this group to consider pushing the human-driven identification and remediation workflows out of the scope of SACM, at least initially, while trying to provide suitable hooks for interoperability.

Eric

-----David Harrington <[email-masked]> wrote: -----

To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio <[email-masked]>, Joe Marcus Clarke <[email-masked]>, "<[email-masked]>" <[email-masked]>
From: David Harrington <[email-masked]>
Date: 08/14/2013 02:11PM
Subject: Re: [sacm] Feedback on vulnerability management use case

---

From: Chris Inacio <[email-masked]>
Date: Thu, 15 Aug 2013 18:42:44 +0000

Can't we get a definition of vulnerability that is more basic, and then expand from there on what it means to manage and remediate?

A vulnerability is a state of configuration or defect in a system which allows an unintended and unauthorized party to violate the security or policies of the system.

Therefore, vulnerability management is the process of mitigating the ability to exploit a vulnerability, via defect removal or protective measures such that exploitation becomes impossible or highly unlikely.

So then, the job in SACM is to cover the use cases of doing vulnerability management:  software patching, configuration modification, or various protective measures.  Obviously, this is the *really* hard part.  :)

--
Chris Inacio
[email-masked]

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 15 Aug 2013 15:22:44 -0400

+1

Good definition.

On 8/15/2013 2:42 PM, Chris Inacio wrote:
>> There is one other issue with the above paragraph, however (I have not had a chance to review the full document).  I notice that we're trying to pick up both software vulnerabilities and vulnerabilities that require a questionnaire or other human workflow of some kind to identify.  This is analogous to the division of labor between OVAL and OCIL, to give two examples.  I am sure that there is a need for a way to systematically identify and address vulnerabilities that require some kind of human-driven workflow, and that this is a pressing one.  But the two sets of processes work on very different timescales and have somewhat different needs.  It was an architectural mistake, in my opinion, for XCCDF to attempt to include reference to both OVAL and OCIL in the same benchmark and for the SCAP program to hang the possibility at one point that vendors would need to provide support for both sets of processes in their tools.  I would urge this group to consider pushing the human
 -
>   driven identification and remediation workflows out of the scope of SACM, at least initially, while trying to provide suitable hooks for interoperability.
>>
>> Eric
>>
>>

---

From: "Baker, Jon" <[email-masked]>
Date: Thu, 15 Aug 2013 19:46:49 +0000

CVE has some pretty widely accepted definitions for vulnerability and exposure: http://cve.mitre.org/about/terminology.html Of course, these are based upon the software vulnerability analysis domain that CVE supports. 

The definition below that includes configuration aligns fairly well with the NIST definition: http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]

>Gunnar Engelbach
>Sent: Thursday, August 15, 2013 3:23 PM
>To: Chris Inacio
>Cc: Eric Walker; Joe Marcus Clarke; David Harrington; <[email-masked]>
>> Can't we get a definition of vulnerability that is more basic, and then expand
>from there on what it means to manage and remediate?
>>
>> A vulnerability is a state of configuration or defect in a system which allows
>an unintended and unauthorized party to violate the security or policies of the
>system.
>>
>>
>> Therefore, vulnerability management is the process of mitigating the ability
>to exploit a vulnerability, via defect removal or protective measures such that
>exploitation becomes impossible or highly unlikely.
>>
>> So then, the job in SACM is to cover the use cases of doing vulnerability
>management:  software patching, configuration modification, or various
>protective measures.  Obviously, this is the *really* hard part.  :)
>>
>> --
>> Chris Inacio
>> [email-masked]
>>
>>
>>
>>> My comments were of a general nature and were addressing points raised
>by Joe Marcus Clark, below, and others.  I assume this thread is commenting
>on the use cases, but I'm not sure.
>>>
>>> Vulnerability management involves identifying the patch level of software
>installed on the device and the identification of insecure custom code (e.g.
>web vulnerabilities).  All vulnerabilities need to be addressed as part of a
>comprehensive risk management program, which is a superset of software
>vulnerabilities.  Thus, the capability of assessing non-software vulnerabilities
>applicable to the system is required.  Additionally, it may be necessary to
>support non-technical assessment of data relating to assets such as aspects
>related to operational and management controls.
>>>
>>> The first sentence seems fine to me if we understand SACM's scope to be
>restricted to vulnerabilities that go back to the state of an endpoint.  To
>capture the recent thread, perhaps we would want something like this:
>>>
>>> A vulnerability is generally understood to refer to a situation that will
>facilitate the compromise of a network or an endpoint.  Some vulnerabilities
>relate to processes and network topologies, while others go back to the state
>of individual endpoints and can be inferred from their patch level, whether
>they have up-to-date software, and so on.  A comprehensive risk management
>program may try to take into account all of these kinds of vulnerabilities, and
>effort should be made to anticipate how such a program might work in the
>real world so that the SACM work will integrate well with such efforts.  In the
>context of software running on an endpoint, a "vulnerability" is often closely
>related to the operating system patch level, the versions of programs installed
>and the configuration of settings.  While it would be difficult to define the
>term precisely, an important area of security automation involves identifying
>and addressing vulnerabilities on endpoints.  [etc.]
>>>
>>> There is one other issue with the above paragraph, however (I have not had
>a chance to review the full document).  I notice that we're trying to pick up
>both software vulnerabilities and vulnerabilities that require a questionnaire
>or other human workflow of some kind to identify.  This is analogous to the
>division of labor between OVAL and OCIL, to give two examples.  I am sure
>that there is a need for a way to systematically identify and address
>vulnerabilities that require some kind of human-driven workflow, and that this
>is a pressing one.  But the two sets of processes work on very different
>timescales and have somewhat different needs.  It was an architectural
>mistake, in my opinion, for XCCDF to attempt to include reference to both
>OVAL and OCIL in the same benchmark and for the SCAP program to hang the
>possibility at one point that vendors would need to provide support for both
>sets of processes in their tools.  I would urge this group to consider pushing
>the human
> -
>>   driven identification and remediation workflows out of the scope of SACM,
>at least initially, while trying to provide suitable hooks for interoperability.
>>>
>>> Eric
>>>
>>>
>>> To: Eric Walker/San Francisco/IBM@IBMUS, Chris Inacio
><[email-masked]>, Joe Marcus Clarke <[email-masked]>,
>"<[email-masked]>" <[email-masked]>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 15 Aug 2013 17:02:10 -0400

> Is what you are looking to accomplish is a little more complex than just saying "X has vulnerability Y"  such that you can understand that "Windows Server 2008 R2 has a *remotely exploitable* softw…

Yes, that is my intent.  If a vulnerability, mitigation, remediation is
properly described then SACM can take the asset and config data together
with the vulnerability data and provide a posture assessment.

Joe