Subject: [sacm] Relation/relevance of CVRF to/for SACM?

From: "Jan-Oliver Wagner" <[email-masked]>
Date: Wed, 19 Nov 2014 10:27:43 +0100

Are there any opinions or plans about CVRF in relation to SACM?

  http://www.icasi.org/cvrf

-- 
Dr. Jan-Oliver Wagner |  +49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner

---

From: Jerome Athias <[email-masked]>
Date: Wed, 19 Nov 2014 10:46:14 +0100

Hi,

good point
meantime this is now closely linked with CVE
https://cve.mitre.org/cve/cvrf.html

Best regards

2014-11-19 10:27 GMT+01:00 Jan-Oliver Wagner <[email-masked]>:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 19 Nov 2014 16:54:54 -0500

An opinion:  possibly.  But I don't see it as being necessary for the 
first iteration of SACM.

But let me address that in more detail and see if it makes sense.

Starting with a simple process stack, using my own terminology:

--- Section One:  Prose ---
  Guidance
--------------
  Policy
--------------

-- Section Two:  Automation ---

    Evaluation
--------------
    Collection
--------------
    Endpoint Attributes
--------------

This is divided into two sections where the topmost is in a prose format 
and the bottom is in a format that is machine-executable.

Guidance:  The high-level security goals, such as "password settings are 
sufficient."  HIPAA, SOX, 800-53 and PCI would be examples at this level.

Policy:  The detailed items for each platform needed to fulfill that 
guidance item, such as password length, complexity, aging, etc.  The 
DISA prose STIGs or other hardening guides are examples at this level.

Evaluation:  The logic rules that, when applied to the endpoint 
attributes, are able to make a valuation for each policy item, such as 
pass or fail.  XCCDF and OVAL work at this level.

The thing is, all of these are interdependent, especially in the 
automation section.  The ability to automate the evaluation means that 
the endpoint attributes must be in a format that can be used within an 
evaluation expression.

The format used for evaluation also needs to be able to drive collection 
so that the complete set of attributes needed for evaluation are collected.

XCCDF and OVAL comprise an ecosystem that already does all of this, 
hence my response to Chris Inacio's question.  They also are their own 
results formats, so CVRF would be mostly* redundant.

So, with all that in mind, here's the argument:

The majority of SACM's charter can be achieved using XCCDF and OVAL, 
standards that are publicly available and have already been implemented. 
  And while I would term them non-ideal, using CVRF would mean a change 
or addition to those standards.

We could, of course, choose to use something other than XCCDF/OVAL and 
CVRF could be part of that.  But keep in mind that whatever does the 
evaluation would then need to have the information necessary to produce 
results as CVRF.  And the format that is used to express the evaluation 
logic would also need to be able to communicate the complete and 
unambiguous set of items to collect to whatever mechanism is doing 
collection, which then needs to do that collection and return the 
attribute set in such a manner that the evaluation can deterministically 
find the correct attribute and properly interpret the data it contains.

* CVRF does provide some features that are not present in XCCDF/OVAL, 
so, yeah, there is that argument.

---

From: Chris Inacio <[email-masked]>
Date: Wed, 19 Nov 2014 22:37:46 +0000

So I’m much more familiar with OVAL than I am with IF-TNCCS-SOH.  That said, I know I can get both OVAL in various products and I can get an awful lot of IF-TNCCS-SOH (simply because its in pretty much every MS client OS in use).  So can someone educate me on the differences between these capabilities.  And can someone correct me (assuming I’m making a faulty assumption,) that IETF NEA is based on the TCG protocols, IF-TNCCS-SOH.

So what impacts to the information model (how we think in high level terms about how to deal with the data - not in the details, right) does choosing OVAL vs. IF-TNCCS-SOH vs. NEA vs. ALL make?

And for those who don’t appreciate it, yes, I’m *trying really hard* to be a devil's advocate.

--
Chris Inacio
[email-masked]

> On Nov 19, 2014, at 4:54 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> An opinion:  possibly.  But I don't see it as being necessary for the first iteration of SACM.
> 
> This is divided into two sections where the topmost is in a prose format and the bottom is in a format that is machine-executable.
> 
> Guidance:  The high-level security goals, such as "password settings are sufficient."  HIPAA, SOX, 800-53 and PCI would be examples at this level.
> 
> Policy:  The detailed items for each platform needed to fulfill that guidance item, such as password length, complexity, aging, etc.  The DISA prose STIGs or other hardening guides are examples at this level.
> 
> Evaluation:  The logic rules that, when applied to the endpoint attributes, are able to make a valuation for each policy item, such as pass or fail.  XCCDF and OVAL work at this level.
> 
> 
> The thing is, all of these are interdependent, especially in the automation section.  The ability to automate the evaluation means that the endpoint attributes must be in a format that can be used within an evaluation expression.
> 
> The format used for evaluation also needs to be able to drive collection so that the complete set of attributes needed for evaluation are collected.
> 
> 
> XCCDF and OVAL comprise an ecosystem that already does all of this, hence my response to Chris Inacio's question.  They also are their own results formats, so CVRF would be mostly* redundant.
> 
> 
> The majority of SACM's charter can be achieved using XCCDF and OVAL, standards that are publicly available and have already been implemented.  And while I would term them non-ideal, using CVRF would mean a change or addition to those standards.
> 
> We could, of course, choose to use something other than XCCDF/OVAL and CVRF could be part of that.  But keep in mind that whatever does the evaluation would then need to have the information necessary to produce results as CVRF.  And the format that is used to express the evaluation logic would also need to be able to communicate the complete and unambiguous set of items to collect to whatever mechanism is doing collection, which then needs to do that collection and return the attribute set in such a manner that the evaluation can deterministically find the correct attribute and properly interpret the data it contains.
> 
> 
> 
> * CVRF does provide some features that are not present in XCCDF/OVAL, so, yeah, there is that argument.
> 
>

---

From: Chris Inacio <[email-masked]>
Date: Wed, 19 Nov 2014 22:43:42 +0000

I forgot - how do OVAL, NEA, IF-TNCCS-SOH combine with passive measurements from things like FireSIGHT, Tenable PVS, etc.?

How does the info model handle an asset reporting about another asset on the network?  What is the common key that would be used to enable that?

--
Chris Inacio
[email-masked]

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 19 Nov 2014 18:02:35 -0500

> I forgot - how do OVAL, NEA, IF-TNCCS-SOH combine with passive measurements from things like FireSIGHT, Tenable PVS, etc.?

One of two ways:

1) The passive contributors would need to implement enough of the SACM 
standards to be able to communicate their data -- possibly to include 
SACM publishing requests.

2) A SACM component that acted as a translator.  This is the same 
approach needed as a bridge so a SACM collection requests can be made of 
an endpoint that does not implement the SACM standards (legacy 
equipment, for example).

> How does the info model handle an asset reporting about another asset on the network?  What is the common key that would be used to enable that?

Do you mean in the case where the first asset is a data store, such as a 
CMDB?  Or where the second asset (endpoint) cannot be directly queried 
so the first endpoint is used as a proxy?

Or are you talking about something else that I missed?

In any case, if the IM is OVAL-SC, then the key would be the OVAL object ID.

---

From: Chris Inacio <[email-masked]>
Date: Thu, 20 Nov 2014 04:22:41 +0000

> On Nov 19, 2014, at 6:02 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> 
> 1) The passive contributors would need to implement enough of the SACM standards to be able to communicate their data -- possibly to include SACM publishing requests.
> 
> 2) A SACM component that acted as a translator.  This is the same approach needed as a bridge so a SACM collection requests can be made of an endpoint that does not implement the SACM standards (legacy equipment, for example).
> 
> 
>> 
>> 
> Do you mean in the case where the first asset is a data store, such as a CMDB?  Or where the second asset (endpoint) cannot be directly queried so the first endpoint is used as a proxy?
> 

[cmi] Okay, I botched the question.  :)  Let me restate, hopefully in more intelligible english.  Let’s say I get an assessment report from and endpoint (let’s call it SAM.)  Presumably, whatever we do end up with in the information model we will be able to uniquely label SAM throughout our “universe”.  (Resolving later what the size and scope of the “universe” is here.)  SAM reported that everything is great, it has Windows 7 with all the patches, running IE 11 (that’s the latest, right?), host adapter with IP address 1.2.3.4 (or something really long if you like IPv6, ffc0::1:2:3:4 :)).  Then a passive monitor on the network finds a client with IP address 1.2.3.4  and it finds IE 9.  The passive monitor can’t give too much more information than that, it’s running at the border of the network.  So, restated, how does the report from the border sensor of {1.2.3.4, “IE 9”} get jammed back into the repository of information such that endpoint SAM gets noticed as suspicious, or at least inconsistent.

[cmi] So potentially there could be a search for that IP address through all reporting in the repository.  With DHCP or privacy addressing in IPv6 caution should be used to tie the report from the border to endpoint SAM.  The information model, in my mind, must support the provenance of the reports along with the temporal dimension, taking into account the various entities potentially limited context making those reports, while still leaving enough information for operations in the repository to fuse that reporting together to help the humans notice and resolve the true state of the universe now, and at previous point T.

[cmi] I think there is something standardized (and then more than 1 standardized) on how to ask a host to “tell me about yourself”.  I, personally, still don’t know enough about the differences between those standards to say “wow, I really want feature X,Y,Z from this std, but I want to keep A,B,C from that std” and I want to enable a bigger ecosystem, and I want to make sure this isn’t just the host based endpoint show, to create an information model for SACM that works.  Since the current requirements document states, SACM supports multiple std’s for this stuff, and things get negotiated in the protocol as to which std is common for the producer and consumer to communicate, it creates the problem of how to combine those various features and models into a coherent model allowing the transforms to happen.

[cmi] I’m very interested in the compare / contrast of OVAL and NEA and IF-TNCCS-SOH, but they cannot solve the IM definition problem for SACM in my opinion yet.  Maybe they can, but I certainly don’t know that to be the case at this point.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 20 Nov 2014 14:29:01 +0000

I know you are asking a general question here, but the first example is
seriously flawed.

Does that network use dynamic IP addresses?
Are there NATs in that network?
IP addresses are not host identities.

________________________________
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 Chris Inacio
Sent: Wednesday, November 19, 2014 11:23 PM
To: Gunnar Engelbach
Cc: Jan-Oliver Wagner; [email-masked]
Subject: Re: [sacm] Relation/relevance of CVRF to/for SACM?

> On Nov 19, 2014, at 6:02 PM, Gunnar Engelbach
<[email-masked]> wrote:
>> I forgot - how do OVAL, NEA, IF-TNCCS-SOH combine with passive
measurements from things like FireSIGHT, Tenable PVS, etc.?
> 1) The passive contributors would need to implement enough of the SACM
standards to be able to communicate their data -- possibly to include SACM
publishing requests.
> 
> 2) A SACM component that acted as a translator.  This is the same approach
needed as a bridge so a SACM collection requests can be made of an endpoint
that does not implement the SACM standards (legacy equipment, for example).
> 
> 
>> 
>> 
>> How does the info model handle an asset reporting about another asset on
the network?  What is the common key that would be used to enable that?
> Do you mean in the case where the first asset is a data store, such as a
CMDB?  Or where the second asset (endpoint) cannot be directly queried so
the first endpoint is used as a proxy?
> In any case, if the IM is OVAL-SC, then the key would be the OVAL object
ID.

[cmi] Okay, I botched the question.  :)  Let me restate, hopefully in more
intelligible english.  Let's say I get an assessment report from and
endpoint (let's call it SAM.)  Presumably, whatever we do end up with in the
information model we will be able to uniquely label SAM throughout our
"universe".  (Resolving later what the size and scope of the "universe" is
here.)  SAM reported that everything is great, it has Windows 7 with all the
patches, running IE 11 (that's the latest, right?), host adapter with IP
address 1.2.3.4 (or something really long if you like IPv6, ffc0::1:2:3:4
:)).  Then a passive monitor on the network finds a client with IP address
1.2.3.4  and it finds IE 9.  The passive monitor can't give too much more
information than that, it's running at the border of the network.  So,
restated, how does the report from the border sensor of {1.2.3.4, "IE 9"}
get jammed back into the repository of information such that endpoint SAM
gets noticed as suspicious, or at least inconsistent.

[cmi] So potentially there could be a search for that IP address through all
reporting in the repository.  With DHCP or privacy addressing in IPv6
caution should be used to tie the report from the border to endpoint SAM.
The information model, in my mind, must support the provenance of the
reports along with the temporal dimension, taking into account the various
entities potentially limited context making those reports, while still
leaving enough information for operations in the repository to fuse that
reporting together to help the humans notice and resolve the true state of
the universe now, and at previous point T.

[cmi] I think there is something standardized (and then more than 1
standardized) on how to ask a host to "tell me about yourself".  I,
personally, still don't know enough about the differences between those
standards to say "wow, I really want feature X,Y,Z from this std, but I want
to keep A,B,C from that std" and I want to enable a bigger ecosystem, and I
want to make sure this isn't just the host based endpoint show, to create an
information model for SACM that works.  Since the current requirements
document states, SACM supports multiple std's for this stuff, and things get
negotiated in the protocol as to which std is common for the producer and
consumer to communicate, it creates the problem of how to combine those
various features and models into a coherent model allowing the transforms to
happen.

[cmi] I'm very interested in the compare / contrast of OVAL and NEA and
IF-TNCCS-SOH, but they cannot solve the IM definition problem for SACM in my
opinion yet.  Maybe they can, but I certainly don't know that to be the case
at this point.

---

From: Ira McDonald <[email-masked]>
Date: Thu, 20 Nov 2014 09:43:27 -0500

Hi,

The fundamental problem of what is a reliable (over time, days or more)
endpoint identity attribute assertion is *unsolved*.

While endpoint posture agents and remote collectors (NEA or whatever)
may be able to see an endpoint UUID (for example), all of the traffic and
behavior monitoring appliances can never see that UUID.  Often the
apparent IPv4/IPv6 address (from the point of view of the external
observer)
is the only available endpoint identity attribute assertion.

Given NAT, network segmentation, dynamic IP addresses, and multiple
physical interfaces on a single "endpoint", this is the *hard* problem for
SACM.  Any downscoping to "modern" endpoints (with local posture
reporting agents) and a single "preferred" posture collection protocol
would make SACM useless.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Nov 20, 2014 at 9:29 AM, Michael Hammer <
[email-masked]> wrote:

> approach

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 20 Nov 2014 11:18:59 -0500

Unsolved, but it's a real problem that needs to be addressed.  The 
question is whether or not SACM should attempt to address it, at least 
at some level.

SACM implementers will need to account for this.  Without anything from 
SACM to address it, it will be entirely up to each implementer.  And 
that might, in fact, be the preferred approach.

--gun

On 11/20/2014 9:43 AM, Ira McDonald wrote:
> mailto: [email-masked] <mailto:[email-masked]>
> On Thu, Nov 20, 2014 at 9:29 AM, Michael Hammer
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>     Mobile: +1 408 202 9291 <tel:%2B1%20408%20202%209291>
>     542 Gibraltar Drive
>     Milpitas, CA 95035 USA
>     www.yaanatech.com <http://www.yaanatech.com>
>
>     From: sacm [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Chris Inacio
>     Cc: Jan-Oliver Wagner; [email-masked] <mailto:[email-masked]>
>      > In any case, if the IM is OVAL-SC, then the key would be the OVAL
>     object
>     ID.
>      >
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Chris Inacio <[email-masked]>
Date: Thu, 20 Nov 2014 22:01:13 +0000

> On Nov 20, 2014, at 9:29 AM, Michael Hammer <[email-masked]> wrote:
> 

;)

--
Chris Inacio
[email-masked]

---

From: Chris Inacio <[email-masked]>
Date: Thu, 20 Nov 2014 22:02:44 +0000

> On Nov 20, 2014, at 11:18 AM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> Unsolved, but it's a real problem that needs to be addressed.  The question is whether or not SACM should attempt to address it, at least at some level.
> 
> SACM implementers will need to account for this.  Without anything from SACM to address it, it will be entirely up to each implementer.  And that might, in fact, be the preferred approach.
> 
> 
> --gun
> 
> 

[cmi] If this is truly the case, then I cannot conceive of how to build the information model for SACM.

--
Chris Inacio
[email-masked]