Subject: [sacm] SACM Use Cases 06, Section 2

From: "Brian Ford (brford)" <[email-masked]>
Date: Wed, 2 Apr 2014 13:24:27 +0000

SACM Team;

In Endpoint Security Posture Assessment - Enterprise Use Cases (draft-ietf-sacm-use-cases-06) section 2 addresses Endpoint Posture Assessment.  In the typical workflow, step 4 defines a set of activities that might occur per target labeled A through G.
Steps E, F, and G read as below:
QUOTE
       E.  The application communicates target identity and (sets of)
           collected attributes to an evaluator, possibly an external
           process or external system.
       F.  The evaluator compares the collected posture attributes with
           expected values as expressed in policies.
       G.  The evaluator reports the evaluation result for the requested
           assessment, in a standardized or proprietary format, such as
           a report, a log entry, a database entry, or a notification.
UNQUOTE
I would suggest that another step is needed at or between F and G that where the target identifier and the collected attributes are recorded in their raw form to a data store.  This record should include a timestamp that represents the time closest to time the attributes were collected.  Some implementations may want to implement this as an evidentiary (write once, read only) data store.
Having a record of the raw data would be valuable for post event analysis by a analyst; running the attributes through the evaluator using different evaluation criteria; or running the attributes through a different evaluator.
Given the level of detail in step G I think this should be a new step inserted between E and F.  Having a record of the raw data would be valuable for post event analysis by a analyst; running the attributes through the evaluator using different evaluation criteria; or running the attributes through a different evaluator.

Proposed new F:

F. The evaluator writes the target identifier, the date and time collected as reported to the evaluator, and the collected posture attributes to a data store.  This record of the collected attributes can be used for post event analysis by a analyst; running the attributes through the evaluator using different evaluation criteria; or running the attributes through a different evaluator.  Some implementations may want to implement this as an evidentiary (write once, read only) data store.

Thoughts?

Liberty,

Brian

Brian Ford
Consulting Engineer, Security Specialist
Research & Advanced Development Group
Cisco Systems, Inc.
http://www.cisco.com/go/research

---

From: Adam Montville <[email-masked]>
Date: Wed, 2 Apr 2014 11:03:57 -0500

> F. The evaluator writes the target identifier, the date and time collected as reported to the evaluator, and the collected posture attributes to a data store.  This record of the collected attribut…

I wouldn’t have a problem adding the step of optionally storing unscathed actual values.  I would prefer to see the detail of your proposed F taken into consideration in either a new scenario or adopted by one of the existing scenarios.

What do others think (especially those of you who have contributed use cases and/or scenarios)?

If we agree that this proposal is something we should include in the use case draft, then the architecture/requirements draft will need to be updated and we can ensure we’ve captured the requisite detail.

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Apr 2014 13:28:46 -0400

Hi,

This doesn't strike me as something that is required by sacm workflow,
although I accept that it is an optional step that some implementations
might support.

The IETF typically designs protocols, data modeling languages, and data
models that support applications, but not the applications themselves; we
design SMTP, but not Outlook ... 

I'm an SNMP guy, so let me talk in those terms. In the SNMP design, we
defined how to collect data; we didn't specify what applications should do
with the data, even though many NMSes store the data in databases for
historical analysis, etc. This helps promote simplicity in the SNMP
protocol, the SMI, and the MIB data model. Complexity is handled by the
(NMS) applications that utilize the collected data. 

The proposal to save the raw data in a (write-once, read-many) database
seems to be an application concern, not a concern about the protocol and or
data modeling needed for sacm. Ergo, I'm not convinced we need to include
this in the sacm workflow, unless it places specific requirements on the
design/selection of the sacm protocol, DML, and data models.

David Harrington

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

+1-603-828-1401

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, April 02, 2014 12:04 PM
To: Brian Ford (brford)
Cc: [email-masked]
Subject: Re: [sacm] SACM Use Cases 06, Section 2

 

SACM Team;

In Endpoint Security Posture Assessment - Enterprise Use Cases
(draft-ietf-sacm-use-cases-06) section 2 addresses Endpoint Posture
Assessment.  In the typical workflow, step 4 defines a set of activities
that might occur per target labeled A through G.

QUOTE

UNQUOTE

I would suggest that another step is needed at or between F and G that where
the target identifier and the collected attributes are recorded in their raw
form to a data store.  This record should include a timestamp that
represents the time closest to time the attributes were collected.  Some
implementations may want to implement this as an evidentiary (write once,
read only) data store.

Having a record of the raw data would be valuable for post event analysis by
a analyst; running the attributes through the evaluator using different
evaluation criteria; or running the attributes through a different
evaluator.

Given the level of detail in step G I think this should be a new step
inserted between E and F.  Having a record of the raw data would be valuable
for post event analysis by a analyst; running the attributes through the
evaluator using different evaluation criteria; or running the attributes
through a different evaluator.

Proposed new F:

F. The evaluator writes the target identifier, the date and time collected
as reported to the evaluator, and the collected posture attributes to a data
store.  This record of the collected attributes can be used for post event
analysis by a analyst; running the attributes through the evaluator using
different evaluation criteria; or running the attributes through a different
evaluator.  Some implementations may want to implement this as an
evidentiary (write once, read only) data store.

I wouldn't have a problem adding the step of optionally storing unscathed
actual values.  I would prefer to see the detail of your proposed F taken
into consideration in either a new scenario or adopted by one of the
existing scenarios.

What do others think (especially those of you who have contributed use cases
and/or scenarios)?

If we agree that this proposal is something we should include in the use
case draft, then the architecture/requirements draft will need to be updated
and we can ensure we've captured the requisite detail.

Thoughts?

Liberty,

Brian

Brian Ford

Cisco Systems, Inc.

 <http://www.cisco.com/go/research> http://www.cisco.com/go/research

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

---

From: Adam Montville <[email-masked]>
Date: Wed, 2 Apr 2014 12:45:00 -0500

On Apr 2, 2014, at 12:28 PM, David Harrington <[email-masked]> wrote:

> Hi,
>  
> This doesn’t strike me as something that is required by sacm workflow, although I accept that it is an optional step that some implementations might support.
>  
> The IETF typically designs protocols, data modeling languages, and data models that support applications, but not the applications themselves; we design SMTP, but not Outlook ...
> I’m an SNMP guy, so let me talk in those terms. In the SNMP design, we defined how to collect data; we didn’t specify what applications should do with the data, even though many NMSes store the data in databases for historical analysis, etc. This helps promote simplicity in the SNMP protocol, the SMI, and the MIB data model. Complexity is handled by the (NMS) applications that utilize the collected data.

This is well-put, David, thank you.

>  
> The proposal to save the raw data in a (write-once, read-many) database seems to be an application concern, not a concern about the protocol and or data modeling needed for sacm. Ergo, I’m not convinced we need to include this in the sacm workflow, unless it places specific requirements on the design/selection of the sacm protocol, DML, and data models.

It’s probably the “evidentiary” piece that may generate requirements, if they’re not already taken into account.  

Without losing sight of how the data will be used, which will yield format requirements, we should not be defining what is done with the data post-collection/-evaluation beyond making it available.

Do we want to provide evidentiary support?  I think yes.  We get requests for increased evidentiary support in our CISCAT tool, I know other vendors have received similar requests in the past.

> [email-masked]

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 02 Apr 2014 13:50:05 -0400

On 4/2/2014 1:45 PM, Adam Montville wrote:
>
> On Apr 2, 2014, at 12:28 PM, David Harrington <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>> This doesn’t strike me as something that is required by sacm workflow,
>> although I accept that it is an optional step that some
>> implementations might support.
>> The IETF typically designs protocols, data modeling languages, and
>> data models that support applications, but not the applications
>> themselves; we design SMTP, but not Outlook ...
>> I’m an SNMP guy, so let me talk in those terms. In the SNMP design, we
>> defined how to collect data; we didn’t specify what applications
>> should do with the data, even though many NMSes store the data in
>> databases for historical analysis, etc. This helps promote simplicity
>> in the SNMP protocol, the SMI, and the MIB data model. Complexity is
>> handled by the (NMS) applications that utilize the collected data.
>
>> The proposal to save the raw data in a (write-once, read-many)
>> database seems to be an application concern, not a concern about the
>> protocol and or data modeling needed for sacm. Ergo, I’m not convinced
>> we need to include this in the sacm workflow, unless it places
>> specific requirements on the design/selection of the sacm protocol,
>> DML, and data models.
>
> Without losing sight of how the data will be used, which will yield
> format requirements, we should not be defining what is done with the
> data post-collection/-evaluation beyond making it available.
>
> Do we want to provide evidentiary support?  I think yes.  We get
> requests for increased evidentiary support in our CISCAT tool, I know
> other vendors have received similar requests in the past.

As David says, it still comes down to whether or not this creates 
requirements for SACM.  I don't think it does, but I'm willing to 
include the suggested text, edited a bit, just to be sure.

>
>
>
>> David Harrington
>> [email-masked] <mailto:[email-masked]>
>> +1-603-828-1401
>> *From:*sacm [mailto:[email-masked]]*On Behalf Of*Adam Montville
>> *Sent:*Wednesday, April 02, 2014 12:04 PM
>> *To:*Brian Ford (brford)
>> *Cc:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [sacm] SACM Use Cases 06, Section 2
>> On Apr 2, 2014, at 8:24 AM, Brian Ford (brford) <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>> SACM Team;
>> Assessment.  In the typical workflow, step 4 defines a set of
>> activities that might occur per target labeled A through G.
>> I would suggest that another step is needed at or between F and G that
>> where the target identifier and the collected attributes are recorded
>> in their raw form to a data store.  This record should include a
>> timestamp that represents the time closest to time the attributes were
>> collected.  Some implementations may want to implement this as an
>> Having a record of the raw data would be valuable for post event
>> analysis by a analyst; running the attributes through the evaluator
>> using different evaluation criteria; or running the attributes through
>> a different evaluator.
>> inserted between E and F.  Having a record of the raw data would be
>> valuable for post event analysis by a analyst; running the attributes
>> through the evaluator using different evaluation criteria; or running
>> the attributes through a different evaluator.
>> Proposed new F:
>> F. The evaluator writes the target identifier, the date and time
>> collected as reported to the evaluator, and the collected posture
>> attributes to a data store.  This record of the collected attributes
>> can be used for post event analysis by a analyst; running the
>> attributes through the evaluator using different evaluation criteria;
>> or running the attributes through a different evaluator.  Some
>> implementations may want to implement this as an evidentiary (write
>> once, read only) data store.
>> I wouldn’t have a problem adding the step of optionally storing
>> unscathed actual values.  I would prefer to see the detail of your
>> proposed F taken into consideration in either a new scenario or
>> adopted by one of the existing scenarios.
>> If we agree that this proposal is something we should include in the
>> use case draft, then the architecture/requirements draft will need to
>> be updated and we can ensure we’ve captured the requisite detail.
>>
>>
>> Thoughts?
>> Liberty,
>> Brian
>> Brian Ford
>> [email-masked] <mailto:[email-masked]>

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 2 Apr 2014 14:13:07 -0400

If evidentiary support is needed, then we might want to be considering
"signing" the content, such as is done with syslog-sign (RFC5848). 

There is little to assert that the "raw" data is what is received by an
application, especially in the presence of proxies, NATs,
application-level-gateways, and so on in the system. If you really want to
meet an evidentiary requirement, then I think we  need a means to ensure the
chain of custody from the origin of the data, not an intermediate collection
point. I think that would imply a requirement for evidentiary support in the
sacm protocols and possibly data models.

(As co-chair of record for the syslog WG that developed syslog-sign) I have
not seen strong demand for the syslog-sign standard, nor have I seen demand
for comparable capabilities in the other major IETF network management
standards, such as SNMP, ipfix, or  Netconf. If we are adding an evidentiary
requirement to sacm, that could eliminate a lot of existing protocols from
consideration, unless they were supplemented with something comparable to
syslog-sign.

David Harrington

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

+1-603-828-1401

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, April 02, 2014 1:45 PM
To: David Harrington
Cc: [email-masked]; Brian Ford (brford)
Subject: Re: [sacm] SACM Use Cases 06, Section 2

On Apr 2, 2014, at 12:28 PM, David Harrington <[email-masked]>
wrote:

Hi,

 

It's probably the "evidentiary" piece that may generate requirements, if
they're not already taken into account.  

Without losing sight of how the data will be used, which will yield format
requirements, we should not be defining what is done with the data
post-collection/-evaluation beyond making it available.

Do we want to provide evidentiary support?  I think yes.  We get requests
for increased evidentiary support in our CISCAT tool, I know other vendors
have received similar requests in the past.

 

David Harrington

+1-603-828-1401

 

On Apr 2, 2014, at 8:24 AM, Brian Ford (brford) < <mailto:[email-masked]>
[email-masked]> wrote:

SACM Team;

QUOTE

UNQUOTE

Proposed new F:

 

Thoughts?

Liberty,

Brian

Brian Ford

Cisco Systems, Inc.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 02 Apr 2014 14:49:16 -0400

This goes beyond just evidentiary support, all the way back to an early 
discussion about dealing with lying endpoints.  The desire is that the 
whole chain of interaction starting with assessment request, data 
collection, and so on, be done in an environment of established mutual 
trust, so I don't see that evidentiary support adds any new requirements.

I also don't see this as imposing a limit on which protocols we can 
interact with, just a limit on which can be used for trusted interactions.

Unless you're saying that one of these existing protocols be what is 
used to communicate between SACM components.  It would be nice to not 
have to invent yet another, but I've never held out any real hope that 
that would be possible.  Being that SACM is about security I see the 
capability of establishing mutual trust as a hard requirement.  If that 
eliminates some existing protocols as the SACM protocols I'm already 
fine with that.

On 4/2/2014 2:13 PM, ietfdbh wrote:
> “signing” the content, such as is done with syslog-sign (RFC5848).
>
> There is little to assert that the “raw” data is what is received by an
> application-level-gateways, and so on in the system. If you really want
> to meet an evidentiary requirement, then I think we  need a means to
> ensure the chain of custody from the origin of the data, not an
> intermediate collection point. I think that would imply a requirement
> for evidentiary support in the sacm protocols and possibly data models.
>
> (As co-chair of record for the syslog WG that developed syslog-sign) I
> have not seen strong demand for the syslog-sign standard, nor have I
> seen demand for comparable capabilities in the other major IETF network
> management standards, such as SNMP, ipfix, or  Netconf. If we are adding
> an evidentiary requirement to sacm, that could eliminate a lot of
> existing protocols from consideration, unless they were supplemented
> with something comparable to syslog-sign.
>
> David Harrington
>
> [email-masked] <mailto:[email-masked]>
>
> +1-603-828-1401
>
> *From:*sacm [mailto:[email-masked]] *On Behalf Of *Adam Montville
> *Sent:* Wednesday, April 02, 2014 1:45 PM
> *To:* David Harrington
> *Cc:* [email-masked]; Brian Ford (brford)
> *Subject:* Re: [sacm] SACM Use Cases 06, Section 2
>
> models that support applications, but not the applications themselves;
> we design SMTP, but not Outlook ...
>
> defined how to collect data; we didn’t specify what applications should
> do with the data, even though many NMSes store the data in databases for
>     protocol and or data modeling needed for sacm. Ergo, I’m not
>     convinced we need to include this in the sacm workflow, unless it
>     places specific requirements on the design/selection of the sacm
>     protocol, DML, and data models.
>
> where the target identifier and the collected attributes are recorded in
> their raw form to a data store.  This record should include a timestamp
> that represents the time closest to time the attributes were collected.
> Some implementations may want to implement this as an evidentiary (write
> using different evaluation criteria; or running the attributes through a
> different evaluator.
>
> attributes to a data store.  This record of the collected attributes can
> be used for post event analysis by a analyst; running the attributes
> the attributes through a different evaluator.  Some implementations may
> want to implement this as an evidentiary (write once, read only) data store.
>
> proposed F taken into consideration in either a new scenario or adopted
> by one of the existing scenarios.
>
> case draft, then the architecture/requirements draft will need to be
> updated and we can ensure we’ve captured the requisite detail.
>
>
>
>
> Thoughts?
>
> Liberty,
>
> Brian
>
> Brian Ford
>

---

From: Adam Montville <[email-masked]>
Date: Wed, 2 Apr 2014 14:05:44 -0500

Just want to point out that we may all be talking about evidence, but of what quality?  

I’m not sure we’d be looking for legal-quality evidence, but something that would at least substantiate the claim that a particular assessment was correct.  If we’re supporting that already, then there’s probably little else to discuss, unless Brian would like to argue a case for something with higher levels of assurance...

On Apr 2, 2014, at 1:49 PM, Gunnar Engelbach <[email-masked]> wrote:

> 
> This goes beyond just evidentiary support, all the way back to an early discussion about dealing with lying endpoints.  The desire is that the whole chain of interaction starting with assessment request, data collection, and so on, be done in an environment of established mutual trust, so I don't see that evidentiary support adds any new requirements.
> 
> I also don't see this as imposing a limit on which protocols we can interact with, just a limit on which can be used for trusted interactions.
> 
> Unless you're saying that one of these existing protocols be what is used to communicate between SACM components.  It would be nice to not have to invent yet another, but I've never held out any real hope that that would be possible.  Being that SACM is about security I see the capability of establishing mutual trust as a hard requirement.  If that eliminates some existing protocols as the SACM protocols I'm already fine with that.
> 
> 
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 2 Apr 2014 19:24:55 +0000

Does "substantiate that assessment was correct" mean that we can 

re-run the assessment on the original untampered/signed data?

Just trying to understand what is meant by that sentence.

________________________________

Michael Hammer

Principal Engineer

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

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

 <http://www.yaanatech.com/> www.yaanatech.com

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, April 02, 2014 3:06 PM
To: Gunnar Engelbach
Cc: David Harrington; David Harrington; [email-masked]; Brian Ford (brford)
Subject: Re: [sacm] SACM Use Cases 06, Section 2

Just want to point out that we may all be talking about evidence, but of
what quality?  

I'm not sure we'd be looking for legal-quality evidence, but something that
would at least substantiate the claim that a particular assessment was
correct.  If we're supporting that already, then there's probably little
else to discuss, unless Brian would like to argue a case for something with
higher levels of assurance...

On Apr 2, 2014, at 1:49 PM, Gunnar Engelbach
<[email-masked]> wrote:

This goes beyond just evidentiary support, all the way back to an early
discussion about dealing with lying endpoints.  The desire is that the whole
chain of interaction starting with assessment request, data collection, and
so on, be done in an environment of established mutual trust, so I don't see
that evidentiary support adds any new requirements.

I also don't see this as imposing a limit on which protocols we can interact
with, just a limit on which can be used for trusted interactions.

Unless you're saying that one of these existing protocols be what is used to
communicate between SACM components.  It would be nice to not have to invent
yet another, but I've never held out any real hope that that would be
possible.  Being that SACM is about security I see the capability of
establishing mutual trust as a hard requirement.  If that eliminates some
existing protocols as the SACM protocols I'm already fine with that.

David Harrington

+1-603-828-1401

Hi,

defined how to collect data; we didn't specify what applications should

   protocol and or data modeling needed for sacm. Ergo, I'm not

David Harrington

+1-603-828-1401

SACM Team;

QUOTE

UNQUOTE

Proposed new F:

I wouldn't have a problem adding the step of optionally storing
unscathed actual values.  I would prefer to see the detail of your
proposed F taken into consideration in either a new scenario or adopted
by one of the existing scenarios.

What do others think (especially those of you who have contributed use
cases and/or scenarios)?

If we agree that this proposal is something we should include in the use
case draft, then the architecture/requirements draft will need to be
updated and we can ensure we've captured the requisite detail.

Thoughts?

Liberty,

Brian

Brian Ford

Cisco Systems, Inc.

---

From: "Brian Ford (brford)" <[email-masked]>
Date: Wed, 2 Apr 2014 19:36:45 +0000

David,

Thanks for the reply.

In my read of the use case document I took away that there are assets with posture attributes and evaluators using some policy model.  The reason I called out holding the raw data is that if a trigger event occurs and suddenly assets fail evaluation I believe one of two things might have happened.  Either the asset changed (resulting in new posture attribute values) or the evaluator changed (maybe due to a new policy).

In the use case document section 2.1.3  'Endpoint Posture Value Collection' called out:

Posture Attribute Value Collection:  The accumulation of posture
         attribute values.  This may be based on collection guidance
         that is associated with the posture attributes.

   Once the posture attribute values are collected, they may be
   persisted for later use or they may be immediately used for posture
   evaluation.

My suggestion was aimed at making sure the raw data persists for later use by the evaluator.  Or by another evaluator.

>From an information model perspective if my SACM tool were to run and tell me that some number N of assets were non-compliant; how could I quickly try and determine this issue?  What changed?  If I compare the past attribute data and there is no change in the attributes I would quickly look to see if the evaluator or the policy changed.   Noting which attribute changed helps me zero in on what specific policies assess that posture attribute.  Yes, you could also look at the policy but my thought was the policy would likely be more complex that looking at raw data.

>From a compliance stand point I think having the raw data for later review would also be valuable.  If I have the raw data I can turn that over to a compliance officer who might use a different evaluator.  I added the evidentiary storage statement based on knowing how thorough some compliance officers can be.

Liberty,

Brian

From: David Harrington [mailto:[email-masked]]
Sent: Wednesday, April 02, 2014 1:29 PM
To: 'Adam Montville'; Brian Ford (brford)
Cc: [email-masked]
Subject: RE: [sacm] SACM Use Cases 06, Section 2

Hi,

This doesn't strike me as something that is required by sacm workflow, although I accept that it is an optional step that some implementations might support.

The IETF typically designs protocols, data modeling languages, and data models that support applications, but not the applications themselves; we design SMTP, but not Outlook ...
I'm an SNMP guy, so let me talk in those terms. In the SNMP design, we defined how to collect data; we didn't specify what applications should do with the data, even though many NMSes store the data in databases for historical analysis, etc. This helps promote simplicity in the SNMP protocol, the SMI, and the MIB data model. Complexity is handled by the (NMS) applications that utilize the collected data.

The proposal to save the raw data in a (write-once, read-many) database seems to be an application concern, not a concern about the protocol and or data modeling needed for sacm. Ergo, I'm not convinced we need to include this in the sacm workflow, unless it places specific requirements on the design/selection of the sacm protocol, DML, and data models.

David Harrington
[email-masked]<mailto:[email-masked]>
+1-603-828-1401
From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, April 02, 2014 12:04 PM
To: Brian Ford (brford)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM Use Cases 06, Section 2

On Apr 2, 2014, at 8:24 AM, Brian Ford (brford) <[email-masked]<mailto:[email-masked]>> wrote:

SACM Team;

Proposed new F:

I wouldn't have a problem adding the step of optionally storing unscathed actual values.  I would prefer to see the detail of your proposed F taken into consideration in either a new scenario or adopted by one of the existing scenarios.

If we agree that this proposal is something we should include in the use case draft, then the architecture/requirements draft will need to be updated and we can ensure we've captured the requisite detail.

Thoughts?

Liberty,

Brian

Brian Ford

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

---

From: Adam Montville <[email-masked]>
Date: Wed, 2 Apr 2014 14:55:59 -0500

On Apr 2, 2014, at 2:24 PM, Michael Hammer <[email-masked]> wrote:

> Does “substantiate that assessment was correct” mean that we can

Not necessarily.  It could.  I’m thinking more along the lines of a situation where a domain administrator has effected a central policy change but an assessment is still coming back as failed.  What evidence is there to discern where the problem is?  

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