Subject: [Nea] REQ: Section 4

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jan 2007 00:14:58 -0500

NEA technology may be used for several purposes.  One use ...

 One use is documented, I can't find others.  Maybe re-assesment?  But
that's just part of NEA, and not a different purpose.  The purpose of
NEA could be stated simply: knowing who is on the network, and knowing
what they are running.  (Since remediation is out of scope)

      Without NEA technology, ensuring compliance of Endpoints to
      corporate policy is a time-consuming and difficult task.

  What about normal OS updates, as Bernard pointed out?  A toy idea for
implementing NEA would be an software integrated with a client-side
firewall that downloaded software updates every time the system
connected to a network.

  I understand that much of the on-list discussion happened while the
authors were busy writing the requirements document, but the points
raised are serious enough to warrant a response from the authors.  Is
there *ever* a need in NEA for anything other than "get me all of the
latest updates"?  Why would a system *ever* ask for less than all of the
updates?  At most, I could see the updates being version dependent
(updates for OS v1.2.3 versus OS v2.3.4).  But once that information is
propagated to the machine sourcing the updates, the next step is *still*
"download all updates".

      ... With NEA technology, the network is
      able to assess an Endpoint as soon as it requests access to
      the network or at any time after joining the network

  So we're assuming that the network will control what software is
running on the endpoint, but won't keep track of that information?  Why
bother asking the Endpoint what it has, when the network could simply
consult it's database, and say "machine X isn't up to date", and then go
tell it "download all of the latest updates".

  The assessment SHOULD NOT include querying.  I have not seen a
scenario where querying of endpoints is useful.  In fact, querying is
extremely inefficient, compared to simply telling the endpoint "download
all updates".

  Of course, the net result of that design is that most of the
complexity of NEA gets pushed into the remediation network, but that's
not necessarily a bad thing.

      ... This
      provides the corporation an opportunity to monitor compliance

  I don't understand "monitor compliance".  If a machine does NEA when
it connects, it is compliant.  If later changes mean a connected machine
is no longer compliant to the new policy, the network MUST know, or MUST
have a way to tell the machines to become compliant.  "monitoring
compliance" to me seems to indicate pro-active querying of machines, as
in "are you still compliant?".  Such querying is inefficient and
unnecessary.

      The decision of how to handle non-compliant Endpoints can be
      made by the network administrator ...

  s/can/MUST/, or s/can/can only/

      ... For example, re-assessment
      may be triggered by a NEA Client if a User disables a security
      application such as a host firewall on the Endpoint.

  I don't understand that.  If the network policy says he MUST run a
firewall, disabling the firewall MUST result in being kicked off of the
network.  I don't see why re-assessment is necessary: the user has
declared he is no longer in compliance.

      ... Re-
      assessment also assists in keeping Endpoints connected to the
      network up to date with fixes and patches published by
      security application vendors.

  As opposed to simple downloads of the updates?  It's a lot easier for
many endpoints to periodically query a server, than it is for a server
to poll many endpoints.

  Performing re-assessment to me indicates that NEA won't scale.

      ... Another use of NEA technology
      may be to supplement information in inventory databases.

  Is this a charter goal?  If not, why are we discussing it?  NEA *may*
result in additional information being available to the network admin,
but the maintenance and use of that information is out of scope of NEA.

      ... In
      organizations that attempt to keep track of their assets,
      inventory databases tend to be incomplete and out-of-date.
      NEA technology may be used to verify or supplement information
      stored about an organization's assets.

  I suggest deleting that text entirely.

      ... NEA
      technology can also be used to monitor and report compliance
      for Endpoints when they try to access certain mission critical
      applications within an enterprise by employing application
      triggered Assessment.

  Why?  The endpoint knows what posture it satisfies, and the network
admin knows the same thing if he caches the posture assessment from the
initial network access.  If the application knows what posture it
requires, why ask the potentially compromised host, when can instead ask
a trusted source: the network admin?  This approach could also catch the
case of lying endpoints.  If the network determines that an endpoint is
lying (i.e. by observing network traffic), it can update it's view of
the endpoints posture, and inform others on the network that the device
is not to be trusted.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Thu, 11 Jan 2007 11:54:26 -0800

Hi Alan,

Thanks for your comments. Please find my response inline. 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 9:15 PM
To: [email-masked]
Subject: [Nea] REQ: Section 4

<Kaushik> The use cases provide further detail about the usage of NEA
technology,the primary driver is assessment but deployments can use an
incremental approach; for e.g. certain deployments might start with
endpoint detection and creation of an inventory of endpoints before they
start to apply policies for assessment. This usage of NEA was discussed
during the last IETF meeting.

<Kaushik> 

I am not sure this statement really constraints the use of NEA; it is
conceivable that deployments have security  policies around OS versions
and patch levels. However I would like to point out that general purpose
software distribution is not intended to a primary driver for NEA and
there are other technologies that deal with problem of patch management.

</Kaushik>

<Kaushik>  

I think there is a fundamental assumption in your statement that all
assessment use cases are tied to software updates, that's certainly not
true. There might compliance policies dealing with certain applications
such as host firewalls, P2P applications being enabled/disabled on
endpoints that are admitted to the network, in such a scenario the NEA
server is required to request endpoint with specific Posture Attributes
that deal with such applications. 

I am not sure of your statement that "the network won't keep track of
the information about a prior assessment", we have described the use of
assertions as a means to re-use information from prior assessments.

</Kaushik>

      ... This

<Kaushik> 

The term "monitor compliance" does not intend to convey that the network
is actively polling the endpoint. It is intended to cover the use case
wherein the reassessment can be triggered while the endpoint is
connected to the network either via a trigger from the NEA client or the
NEA server. There are use cases are described in section 6.2.1 and 6.2.2

We will try to use an alternative term.

</Kaushik>

<Kaushik> 

The disabling of the firewall represents a change in posture, the NEA
server is required to assess the compliance of the endpoint in the light
of the modified posture which is why reassessment is necessary. The
network access layer (which is out of scope for NEA discussions) may use
the decision of the reassessment to implement a policy to boot the user
from the network. 

Section 6.2.1 describes such a use case.

</Kaushik> 

      ... Re-

<Kaushik> 

The document describes two models of reassessment, i.e. NEA client
triggered and NEA server triggered, it is upto deployments to determine
the most optimum mechanism to employ.

</Kaushik>

<Kaushik> 

The text purely reflecting a usage of NEA technology to detect endpoints
and supplement inventory information. I don't think the text intends to
suggest that the NEA will describe the definition and maintaince of
inventory databases. Building an inventory of endpoints is an important
pre-cursor in enterprise deployments of NEA technology. 

</Kaushik>

      ... In

<Kaushik>

Please refer to above comment 

</Kaushik>

      ... NEA

<Kaushik> 

This text is not intended to suggest the exchange of posture information
between the NEA server and applications. This text covers use cases
wherein assessment can be triggered when Layer 5-7 services are
accessed; Section 6.1.2 provides an example of this use case.

Regards,
  kaushik

</Kaushik>

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Thu, 11 Jan 2007 14:53:17 -0800

Greetings,

      Please see my comments also inserted in line.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

             "Kaushik Narayan                                              
             \(kaushik\)"                                                  
             <[email-masked]                                          To 
             m>                        "Alan DeKok"                        
                                       <[email-masked]>,        
             01/11/2007 11:54          <[email-masked]>                      
             AM                                                         cc 
                                                                           
                                                                   Subject 
                                       RE: [Nea] REQ: Section 4            

                                                                           

Hi Alan,

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Wednesday, January 10, 2007 9:15 PM
To: [email-masked]
Subject: [Nea] REQ: Section 4

<Kaushik>

</Kaushik>

<FYeh>

      IMHO, trying to drive the requirements of the protocol based on all
of the anticipated potential uses of the protocol is a fool's errand.

      The fundamental value of the protocol is to allow the transmission of
any conceivable data on a client to a server that can validate that data
against some set of rules and to do in a secure way that can preclude
highler levels of access. Being able to do this at layer 2 allows us to
constrain layer 3 traffic until the admission decision is made.

      People will find all sorts of ways to use the protocol for uses that
it was not intended for. All we need to do is create a way for them to pass
their data from one endpoint of the tunnel to the other, and provide a
means for the network to allow or deny access based on the decision that is
made on the server side of that tunnel.

      What types of data are passed, how it is consumed anc acted on, are
not within the scope of the protocol.

<?FYeh>

<Kaushik>

</Kaushik>

<FYeh>

Even in the context of software and patch management, a single "apply all
patches and updates" profile is extremely limiting. Large organizations
need a little more granularity than this. The assumption that all endpoints
will have the exact same requirements for Software and patches is not a
sound one. Making the network keep track of this is also not a real
scalable idea.

</FYeh>

      ... This

<Kaushik>

</Kaushik>

<FYeh>

      Another term is seriously needed her.

      First of all, we are not enabling companies to monitor compliance
with this protocol, we are giving them the ability to constrain network
access based on a compliance decision. There are any number of ways to
monitor compliance that have nothing to do with NEA or the network at all.

</FYeh>

<Kaushik>

</Kaushik>

<FYeh>

      ReAssessment is typically a post-admission event. We are not talking
about users who though to be non-compliant coming baclk to retry the
admission, we are talking about users who are thought to be compliant and
have already been admitted.

</FYeh>

      ... Re-

<Kaushik>

</Kaushik>

<Kaushik>

</Kaushik>

<FYeh>

      And it is not the normal realm of the Network Amdinistrator. What
will be required is for one group to manage the identities and policy
reqiurements and another to manage the network and the various levels of
network access. Then the two will have to agree on how to set policies so
that each host is sent to the right network based on identity and
compliance.

</FYeh>

      ... In

<Kaushik>

</Kaushik>

<FYeh>

      I agree with deleting the text. It is far too presumptious!

</FYeh>

      ... NEA

<FYeh>

      IMHO this perspective places far too much responsibility and
authority on the "network admin". In most large organizations, there are
teams of network admins each responsible for different sections of the
network. Expecting these tea0s to suddenly become the arbiters of who on
which endpoint should be running what is completely unrealistic. There a
other departments that deal with that data and it should be left to them.

</FYeh>

<Kaushik>

Regards,
  kaushik

</Kaushik>

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jan 2007 22:33:09 -0500

> during the last IETF meeting.

  As I asked before, is inventory control part of the charter?  If not,
why is it being discussed?  The potential costs, benefits and risks of
using NEA for inventory control are a large subject in themselves, and I
don't think we have time to cover that in addition to the charter work.

> and patch levels.

  Can you give concrete examples?

> However I would like to point out that general purpose

  My comments were not about patch management.  My request was for
scenarios where the endpoint did anything *other* than download all
available updates.  Do you have a concrete response to that request?

> that deal with such applications. 

  My assumption was not about *software* updates, so much as *policy*
updates.  One policy is to download all software updates.  Another
policy might contain rule updates for a firewall, as you pointed out.

  Again, is there a need for the endpoint to do anything other than
download and apply all of the policies associated with a firewall or P2P
application?  Who cares what policy the endpoint has *prior* to it's
network connection attempt?

  As has been discussed on the list at length, there appears to be
little need for querying of the endpoints.

> assertions as a means to re-use information from prior assessments.

  I can't find such a statement in my message.  I am therefore not sure
what comment you are addressing.

> the decision of the reassessment to implement a policy to boot the user

  It would be simpler to say that non-compliant endpoints MUST not be
permitted full network access until the NEA server has assessed their
posture.  A system MAY become non-compliant as a result of configuration
changes while it is (or is not) connected.

> the most optimum mechanism to employ.

  I'm not sure how an NEA client triggered re-assesment is different
from a client requesting network access for the first time after a long
disconnection

> Please refer to above comment 

  Discussions of inventory control concern me, as I detailed in my first
paragraph of this message.

> accessed; Section 6.1.2 provides an example of this use case.

  The network should know the current posture of the device before it
accesses an application.  If the posture is sufficient to access the
application, no assessment is necessary.  If the posture is
insufficient, then the initial posture assessment could have included
requests for sufficient information to make later decisions about
application access.

  The alternative is a security violation: When someone accesses an
application, they get contacted, and asked if they're running software
X, Y, and Z, which are prerequisites for access.

  Alan DeKok.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Thu, 11 Jan 2007 20:28:31 -0800

Hi Frank,
 
Please find my response inline. I have used the tag <Kaushik-Response>

<snipped>

<Kaushik> 

</Kaushik>

<FYeh>

IMHO, trying to drive the requirements of the protocol based on all of
the anticipated potential uses of the protocol is a fool's errand.

People will find all sorts of ways to use the protocol for uses that it
was not intended for. All we need to do is create a way for them to pass
their data from one endpoint of the tunnel to the other, and provide a
means for the network to allow or deny access based on the decision that
is made on the server side of that tunnel.

What types of data are passed, how it is consumed anc acted on, are not
within the scope of the protocol.

<?FYeh> 

<Kaushik-Response>
 
I think we are in agreement; as I mentioned in my previous email, NEA
protocols cannot limit what attributes that get validated since that is
part of the policies of the organization that deploys NEA. My statement
about patch management was that use cases from that area are not going
to primarily drive protocol requirements.
 
</Kaushik-Response>

<Kaushik>  

</Kaushik>

<FYeh>

Even in the context of software and patch management, a single "apply
all patches and updates" profile is extremely limiting. Large
organizations need a little more granularity than this. The assumption
that all endpoints will have the exact same requirements for Software
and patches is not a sound one. Making the network keep track of this is
also not a real scalable idea.

</FYeh> 
 
<Kaushik-Response>
 
That's true. I do believe that "apply all patches" is just a policy and
the NEA protocols need to support posture attribute requests and
assessment policies at different levels of granularity. 
 
The network won't really keep track of what software patches, I was
pointing out that NEA might not necessarily discard decisions from prior
assessments and the Reference Model specifies assertion attributes that
can be used to reflect decisions from a prior assessment.
 
</Kaushik-Response>

      ... This

<Kaushik> 

</Kaushik>

<FYeh>

First of all, we are not enabling companies to monitor compliance with
this protocol, we are giving them the ability to constrain network
access based on a compliance decision. There are any number of ways to
monitor compliance that have nothing to do with NEA or the network at
all.

</FYeh> 

<Kaushik-Response>
 
Agree. The term "monitor" is misleading.
 
</Kaushik-Response> 

<Kaushik> 

</Kaushik> 

<FYeh>

ReAssessment is typically a post-admission event. We are not talking
about users who though to be non-compliant coming baclk to retry the
admission, we are talking about users who are thought to be compliant
and have already been admitted.

</FYeh>
 
<Kaushik-Response>
 
I am not sure we need to narrow down the definition of reassessment to
just cover the cases when the endpoint is compliant; Reassessment might
occur for a non-compliant endpoint post remediation.
 
</Kaushik-Response>

     ... Re-

<Kaushik> 

</Kaushik>

<Kaushik> 

</Kaushik>

<FYeh>

And it is not the normal realm of the Network Amdinistrator. What will
be required is for one group to manage the identities and policy
reqiurements and another to manage the network and the various levels of
network access. Then the two will have to agree on how to set policies
so that each host is sent to the right network based on identity and
compliance.

</FYeh>

     ... In

<Kaushik>

</Kaushik>

<FYeh>

</FYeh> 
 
<Kaushik-Response> 
 
You are right, my comment to Alan was based on the relevance of the use
case. I do agree that this sentence is not properly worded.
 
regards,
  kaushik
 
</Kaushik-Response>

     ... NEA

<FYeh>

IMHO this perspective places far too much responsibility and authority
on the "network admin". In most large organizations, there are teams of
network admins each responsible for different sections of the network.
Expecting these tea0s to suddenly become the arbiters of who on which
endpoint should be running what is completely unrealistic. There a other
departments that deal with that data and it should be left to them.

</FYeh>

<Kaushik> 

Regards,
 kaushik

</Kaushik>

 Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Jan 2007 10:13:46 -0500

Frank Yeh Jr wrote:
> organizations need a little more granularity than this.

  Examples, please.

> The assumption
> and patches is not a sound one.

  In the absence of examples to the contrary, I'm assuming that all
endpoints have software and policies that need periodic changes.  In the
absence of examples to the contrary, I'm assuming that connected
endpoints have software and policies that are kept up to date with
respect to network requirements.

  If one use of NEA is to take out-of-date (i.e. non-compliant)
endpoints and give them network access, then I don't understand why we
need NEA.  We already allow non-compliant endpoints on the network...
which was the problem NEA was created to solve.

> Making the network keep track of this is

  As per previous discussions on the list, the network does not have to
keep track of that information.

> monitor compliance that have nothing to do with NEA or the network at all.

  I agree.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 12 Jan 2007 11:46:53 -0800

Greetings,

> > organizations need a little more granularity than this.

      OK, here is an actual customer scenario that we identified...

      The organization's network supports various groups of users, each of
which has different access rights. The major groups of users were: Internal
Employees with low-level access (rank and file employees), Internal
Employees with high-level access (network and sys admins), Internal
Employees with Financial Systems access, Contractors with low-level access,
Contractors with High-level access, Contractors with Financial Systems
access, and Untrusted.

      This set of groups each had different network access and each group
required a different policy. Anyone Untrusted really had no requirement and
was given access only to the DMZ. The low-level internal employees and
Contractors were basically able to use the "Apply all patches" policy but
there were other things being enforced such as the age and length of the
Windows Password. So even these low-level accessors were required to change
their passwords periodically. In addition, a record that these low-level
users had signed the Company's EULA before proceeding into their network
can be recorded and used as a condition for access (we did not roll it
out).

      The next sets of users, the admins with privileged access, were
required to have stronger security settings on their endpoints and also had
some additional scanning and client firewall software that had to be
running in order to get into the administrative network. The final set,
with access to the Financial Systems, were required to have the right
client software loaded and that also had to be patched and licensed.

      So each set of users had a different set of requirements to meet for
access to different parts of the network.

      Is that enough or do you want more?

> endpoints have software and policies that need periodic changes.

      Hopefully, the example of the untrusted host who can have access to a
corporate web site will work. The lowest level of endpoint will have
absolutely no compliance to policy. A great example of this is when events
have onsite network access for reporters who bring in their own laptops. It
is pretty easy to say that if you do not have the right client software
that you are an untrusted host and get left in the public network.
Simultaneously, you might have an admin with his own laptop that is in the
press room supporting someone and he needs administrative access from the
press room. He plugs in and since he is running the right software and is
authenticated as an admin, he gets in with a whole different level of
network access than the reporter plugged into the next port. Wireless makes
this even more valuable.

>  In the

      I believe that many will but it cannot be assumed that this software
is under management or a condition of access for all deployments.

> which was the problem NEA was created to solve.

      Strong Agreement!!!

> keep track of that information.

      I wish it were not even implied that this is doable. I think it is a
bad idea that will never scale, but I've been wrong before_ lots of times,
so maybe someone will prove me wrong in this case. My personal experience
is that this implication will cause more trouble than it is worth.

Regards,
Frank Yeh

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 12 Jan 2007 12:11:59 -0800

Greetings Kaushik,

      Thanks for your comments, I understand your points  much better now
and I am pretty much in agreement.

      Severely stripped down version of the thread follows with my in-line
comments.

Regards,
Frank Yeh

"Kaushik Narayan \(kaushik\)" <[email-masked]> wrote on 01/11/2007
08:28:31 PM:

> I think we are in agreement; as I mentioned in my previous email,
> NEA protocols cannot limit what attributes that get validated since
> that is part of the policies of the organization that deploys NEA.
> My statement about patch management was that use cases from that
> area are not going to primarily drive protocol requirements.
>
> </Kaushik-Response>
>

      Well Said. I confused your previous statement to mean that they
would! LOL

<SNIP>

>
> <Kaushik-Response>
>
> That's true. I do believe that "apply all patches" is just a policy
> and the NEA protocols need to support posture attribute requests and
> pointing out that NEA might not necessarily discard decisions from
> prior assessments and the Reference Model specifies assertion
> attributes that can be used to reflect decisions from a prior assessment.
>
> </Kaushik-Response>

      DOH! I had repressed the prior assessments part. I am still very much
a proponent of the network doing as little decision making as possible and
the server-side validator making all possible decisions.

      OK, my bad on that one.

<SNIP>

>
> <Kaushik-Response>
>
> I am not sure we need to narrow down the definition of reassessment
> to just cover the cases when the endpoint is compliant; Reassessment
> might occur for a non-compliant endpoint post remediation.
>
> </Kaushik-Response>
>

      Fair enough. So reassessment can simply have the normal english
definition of being assessed again. We can further differentiate
pre-admission and post-admission reassessment with pre-admission implying
hosts that have previusly been denied network access going through the
admission process again and post-admission implying hosts already admitted
on the network being checked for state changes after admission. I'm not
sure there is a lot of value in differentiating pre-admission reassessment
and pre-admission initial assessment unless we wanted to implement some
sort of failure threshold like timing out a session after too many failed
attempts.

Regards,
Frank

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Sun, 14 Jan 2007 08:29:27 -0800

Hi Frank,
 
Please find my reply inline. 
 
 <snipped> 

Fair enough. So reassessment can simply have the normal english
definition of being assessed again. We can further differentiate
pre-admission and post-admission reassessment with pre-admission
implying hosts that have previusly been denied network access going
through the admission process again and post-admission implying hosts
already admitted on the network being checked for state changes after
admission. I'm not sure there is a lot of value in differentiating
pre-admission reassessment and pre-admission initial assessment unless
we wanted to implement some sort of failure threshold like timing out a
session after too many failed attempts.

<Kaushik-Response-II>
 
I am not sure we need to differentiate between pre-admission and
post-admission. Essentially reassessment is triggered when either the
NEA client or NEA server detects a change in the posture on the
endpoint. The endpoint can either be compliant or non-compliant prior to
the reassessment.
 
regards,
  kaushik
 
<Kaushik-Response-II>

Regards,
Frank

---

From: Alan DeKok <[email-masked]>
Date: Sun, 14 Jan 2007 12:18:46 -0500

Frank Yeh Jr wrote:
...
> OK, here is an actual customer scenario that we identified...
...
> Is that enough or do you want more?

  Those are good scenarios, but not quite what I was getting at.  You
described different classes of users, each of whom had differing
policies that were enforced.  However, what I was getting at was the
*status* of the endpoints.

  My question is:  For any given class of users, what happens when the
NEA server determines that the endpoint is not up to date with respect
to the policy for that class?

> I believe that many will but it cannot be assumed that this software is
> under management or a condition of access for all deployments.

  Then any machines that are *not* up to date are in many respects
treated the same as machines not using NEA, right?  After all, if a
machines virus scanner is out of date, it could very well be running
that virus.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 15 Jan 2007 13:07:03 -0800

Greeting,

> machines virus scanner is out of date, it could very well be running

Frank Yeh
Security & Privacy Technology Integration Team
IBM
Tivoli Software

---

From: Frank Yeh Jr <[email-masked]>
Date: Mon, 15 Jan 2007 13:25:30 -0800

Greetings,

      Oops, hit send by mistake on the previous email before I actually got
any content in. DOH!

      Here is my real rely. :-D

"Kaushik Narayan \(kaushik\)" <[email-masked]> wrote on 01/14/2007
08:29:27 AM:

> through the admission process again and post-admission implying
> hosts already admitted on the network being checked for state
> changes after admission. I'm not sure there is a lot of value in
> differentiating pre-admission reassessment and pre-admission initial
> assessment unless we wanted to implement some sort of failure
> threshold like timing out a session after too many failed attempts.
>
>
> <Kaushik-Response-II>
>
> post-admission. Essentially reassessment is triggered when either
> the NEA client or NEA server detects a change in the posture on the
> endpoint. The endpoint can either be compliant or non-compliant
> prior to the reassessment.
>
> regards,
>   kaushik
>
> <Kaushik-Response-II>
>
>
> Regards,
> Frank

      I think post VS pre admission is relevant. Pre-admission cases can be
inferred to be users who do not have the proper conditions when they first
attach. This will be typical when new patches come out., black Tuesdays
being a prime example. Post-admission cases are typically users who have
met the conditions for admission but then decide to disable or remove
something so that they are no longer compliant but already have access. The
two are significant from a governance standpoint. The first is a normal
consequence of doing business, the second is a violation of corporate
policies. The responses to these different cases should be different.

Regards,
Frank Yeh
IBM
Global Technology Services
Security & Privacy Integration Team

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 15 Jan 2007 20:27:42 -0800

Hi Frank,
 
Please find  my respone below (it's right at the end).
 
<snipped>

I think post VS pre admission is relevant. Pre-admission cases can be
inferred to be users who do not have the proper conditions when they
first attach. This will be typical when new patches come out., black
Tuesdays being a prime example. Post-admission cases are typically users
who have met the conditions for admission but then decide to disable or
remove something so that they are no longer compliant but already have
access. The two are significant from a governance standpoint. The first
is a normal consequence of doing business, the second is a violation of
corporate policies. The responses to these different cases should be
different. 

<Kaushik>

I just want to clarify that we are still talking about re-assessment. I
was suggesting that there may not be much value in trying to
differentiate between pre vs post admission scenarios for re-assessment
since unlike initial assessment where the network may have to play a
role (trigger) in the assessment (especially for scenarios of assessment
prior to network access), the process of  reassessment is completely
driven by the NEA client or server components. The NEA protocol
considerations for re-assessment probably need not influenced by whether
endpoint was assessed to be compliant as a result of the prior
assessment and provided regular access to the network or whether the
endpoint was assessed to be non-compliant and denied access or provided
access only to the quarantine network.

regards, 

  kaushik

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Jan 2007 07:51:33 +0100

Frank Yeh Jr wrote:
>... Post-admission cases are typically users

  How is the post-admission case different from a user who disables
something *prior* to obtaining network access?  How would the system
handle that case?

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 16 Jan 2007 10:42:20 -0800

Greetings,

> something *prior* to obtaining network access?  How would the system

      Basically because if the user has disabled it prior to access they
are caught before they ever have network access. When they do it
post-admission they have, by definition, been admitted and have had access
to the protected network for some period of time (as allowed by the
post-admission polling configurations). This can be significant from an
auditing and compliance perspective

>   Alan DeKok.

Regards,
Frank Yeh
IBM Global technology Services
Security & Privacy Technology Integration Team

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Jan 2007 20:30:30 +0100

Frank Yeh Jr wrote:
> Basically because if the user has disabled it prior to access they are
> caught before they ever have network access. When they do it
> post-admission they have, by definition, been admitted and have had
> access to the protected network for some period of time (as allowed by
> the post-admission polling configurations). This can be significant from
> an auditing and compliance perspective

  Why?

  If they have been in compliance, who cares how long they've had
network access?

  If they choose to no longer comply, why not just disconnect them until
they comply?

  I don't understand how the problem is more complicated than that.  The
discussions here indicate there are scenarios that are significant, but
there's little in the way of *quantitative* reasons as to why.  Detailed
examples would help me understand the explanations.  Hand waving
statements that it would be useful don't help move the discussion forward.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 16 Jan 2007 12:52:58 -0800

Greetings,

> statements that it would be useful don't help move the discussion
forward.

      Ok, this may start the whole Big Brother discussion again, but to me
the fact that someone is in compliance and admitted to the network and then
goes non-compliant indicates a willful act by the user. As you say, they
CHOOSE to no longer comply. This is a big thing when you start looking at
compliance and business conduct guidelines, Terms of Service, etc. When
they CHOOSE not to comply, they are in many cases breaking some Coporate
Policy and or ToS that they have agreed to. So legally there are huge
implications_ if someone is willfully violating a ToS, they are liable.

>   Alan DeKok.

Regards,
Frank Yeh
IBM Global Technology Services
Security & Privacy Technology Integration Team

---

From: Frank Yeh Jr <[email-masked]>
Date: Tue, 16 Jan 2007 12:58:08 -0800

Greetings,

      My reply is at the end  this time.

"Kaushik Narayan \(kaushik\)" <[email-masked]> wrote on 01/15/2007
08:27:42 PM:

> I think post VS pre admission is relevant. Pre-admission cases can
> be inferred to be users who do not have the proper conditions when
> they first attach. This will be typical when new patches come out.,
> black Tuesdays being a prime example. Post-admission cases are
> typically users who have met the conditions for admission but then
> decide to disable or remove something so that they are no longer
> compliant but already have access. The two are significant from a
> governance standpoint. The first is a normal consequence of doing
> business, the second is a violation of corporate policies. The
> responses to these different cases should be different.
> <Kaushik>
> I just want to clarify that we are still talking about re-
> assessment. I was suggesting that there may not be much value in
> trying to differentiate between pre vs post admission scenarios for
> re-assessment since unlike initial assessment where the network may
> have to play a role (trigger) in the assessment (especially for
> scenarios of assessment prior to network access), the process of
> reassessment is completely driven by the NEA client or server
> components. The NEA protocol considerations for re-assessment
> probably need not influenced by whether endpoint was assessed to be
> compliant as a result of the prior assessment and provided regular
> access to the network or whether the endpoint was assessed to be
> non-compliant and denied access or provided access only to the
> quarantine network.
> regards,
>   kaushik

      Hmmm... I suppose you could always consider any assessment an initial
assessment as well. So why are we differentiating re-assessment from
primary assessment? Let's say I have a client that has failed initial
assessment and has gone to a remediation network. When they want to
reattempt access, they can simply start the whole assessment from the top.
I don't typically comsier trhe network to initiate the conversation, it is
the client that initiates things by attempting to access a network.

Regards,
Frank Yeh

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Tue, 16 Jan 2007 23:16:31 -0800

Hi Frank,

<snipped>

Hmmm... I suppose you could always consider any assessment an initial
assessment as well. So why are we differentiating re-assessment from
primary assessment? Let's say I have a client that has failed initial
assessment and has gone to a remediation network. When they want to
reattempt access, they can simply start the whole assessment from the
top. I don't typically comsier trhe network to initiate the
conversation, it is the client that initiates things by attempting to
access a network.

 <Kaushik>

Re-assessment can be considered unique from a use case perspective since
the re-assessment might only check for relevant attributes and may also
utilize attributes values from the prior assessment,  for e.g.
re-assessment after remediation may not require a whole assessment but
only specific attributes may be checked based on the remediation
instructions that were issued by the NEA server. 

</Kaushik>

regards,

  kaushik

---

From: Alan DeKok <[email-masked]>
Date: Wed, 17 Jan 2007 13:45:38 +0100

Frank Yeh Jr wrote:
> Ok, this may start the whole Big Brother discussion again, but to me the
> fact that someone is in compliance and admitted to the network and then
> goes non-compliant indicates a willful act by the user.

  Or, a virus that is newer than the virus scanning rules.  There are
any number of reasons why a machine may suddenly be non-compliant.

> As you say, they
> CHOOSE to no longer comply. This is a big thing when you start looking
> at compliance and business conduct guidelines, Terms of Service, etc.
> When they CHOOSE not to comply, they are in many cases breaking some
> Coporate Policy and or ToS that they have agreed to. So legally there
> are huge implications_ if someone is willfully violating a ToS, they are
> liable.

  I would prefer to not discuss legal issues, as they are different in
every jurisdiction.

  From the point of view of the network, an endpoint machine can
suddenly become non-compliant with network policy due to:

  a) changes on the endpoint
  b) updated policy on the NEA server

  In both cases, the endpoint should have its network connection removed
or downgraded until it becomes compliant. with the current policy.  This
is a problem we can solve in NEA.

  We cannot address local policies of what additional steps should be
taken with non-compliant endpoints, and I believe we shouldn't even try.
Those steps are up to local site policy, and are extremely difficult to
standardize.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Wed, 17 Jan 2007 11:18:03 -0800

Greetings,

> > Ok, this may start the whole Big Brother discussion again, but to me
the
> any number of reasons why a machine may suddenly be non-compliant.

      Yes, but they can all be summarized by "the endpoint state does not
match the required state" and the required state is defined by policy. So a
virus that is newer than virus scanning rules might make the endpoint
unsafe, but unless the policy has changed, it is still compliant.

>   I would prefer to not discuss legal issues, as they are different in

      Very wise of you. I agree.

> is a problem we can solve in NEA.

      Completely agree.

> Those steps are up to local site policy, and are extremely difficult to

      I agree again (the stars mut be aligned_ I am strangely agreeable
today ;-). I analogize this by saying we are creating a language or an
alphabet_ we cannot control what people will write or say with it. What we
can do is make it usable and rich enough to support anything they want to
say.

>   Alan DeKok.

      I get the feeling we are reaching some consensus on this point. Hope
you are too!

Regards,
Frank Yeh

---

From: Alan DeKok <[email-masked]>
Date: Sun, 21 Jan 2007 19:27:58 +0100

Frank Yeh Jr wrote:

> match the required state" and the required state is defined by policy.
> So a virus that is newer than virus scanning rules might make the
> endpoint unsafe, but unless the policy has changed, it is still compliant.

  Yes.

> I agree again (the stars mut be aligned_ I am strangely agreeable today
> ;-). I analogize this by saying we are creating a language or an
> alphabet_ we cannot control what people will write or say with it. What
> we can do is make it usable and rich enough to support anything they
> want to say.

  That worries me a little.

> I get the feeling we are reaching some consensus on this point. Hope you
> are too!

  Yes.  I will try to find time to write up a more detailed summary.

  Alan DeKok.

---

From: "todd glassey" <[email-masked]>
Date: Sun, 21 Jan 2007 13:56:32 -0800

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "Frank Yeh Jr" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, January 21, 2007 10:27 AM
Subject: Re: [Nea] REQ: Section 4

>  That worries me a little.

Why NEA is a tool to assure compliance with specific policies. If those 
policies are not updated to address specific Zero-Day issues then those 
issues will not be addressed by the NEA compliance model. But this is true 
for all systems of this type so being worried is about the operators not 
being able to react fast enough.

T.