Subject: Re: WG Review: Network Endpoint Assessment (nea)

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 10 Oct 2006 16:29:53 -0400

I have seen a lot of discussion about whether NEA provides
"network protection". In fact, it has been suggested that
the charter be revised to say "NEA must not be considered
a protection mechanism for networks." I don't agree.

Let's start by examining this concept of "network protection".
It's an awfully broad concept. No single security technology
can provide total protection for a network against all attacks.
Instead, a careful threat analysis must be done and layered
countermeasures put in place: firewalls, malware scanning,
intrusion detection and prevention, strong authentication and
authorization, strong encryption for data at rest and in transit,
user education, etc.

In the context of an overall security program and when combined
with other security technologies, NEA can help protect networks.
Let me list the ways.

First, NEA can help improve the security of cooperating, truthful
endpoints. When a cooperating, truthful endpoint connects to the
network, its health can be checked and any problems fixed before
it can come under attack. This helps protect networks by keeping
endpoints healthy so that fewer endpoints become infected and
potentially impact the network through port scanning and other
misbehavior.

The protection provided by NEA alone is not absolute. Healthy
endpoints can be vulnerable to a zero day attack. And NEA on its own
provides no protection against lying endpoints and no protection
against hosts that don't participate in NEA protocols. But it's
a lot better than today's situation where some endpoints are
completely unprotected with patches or anti-virus software.

Second, NEA can be used with technology for detecting lying
endpoints. This prevents compromised systems from lying to
gain access to the network, thus providing a huge improvement
in network security.

I recognize that technology for detecting lying endpoints is
out of scope for the NEA effort but we shouldn't pretend that
it doesn't exist. Without NEA or similar protocols, it will be
hard to integrate lying endpoint detection systems into network
access control. That's why the NEA BOF in Montreal agreed to
include language in the charter saying that "the protocols developed
by the NEA WG must be designed to accommodate emerging technologies
for identifying and dealing with lying endpoints."

Third, endpoints that don't initially participate in NEA protocols
can be quarantined for further examination with an external
vulnerability
scanner or a dynamically downloaded NEA client. Again, this is not part
of the proposed NEA WG charter but it is another example of ways that
NEA
can be used with other security technologies to improve network
security.

To summarize, the NEA protocols will increase network security
on their own. When combined with other technologies, the increase
in network security is much greater. But either way it is not
accurate to say that NEA is not a protection mechanism for networks.

Thanks,

Steve

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 10 Oct 2006 20:01:29 -0700

Hi Steve,
Let me start with a couple of fundamental points that have already been
stated before. 

A. Any network is exposed to threats from lying endpoints, compromised
endpoints and unknown vulnerabilities even on NEA-compliant endpoints. 

B. A network needs to be protected against such generic threats (as
listed in A). 

I am rather confused by this attempt to make NEA fit into some kind of a
network protection mechanism. I keep hearing that NEA is *one* of a
suite of protocols that may be used for protecting networks. Let's dig a
bit deeper into what a network may employ as protection mechanisms in
order to protect against all kinds of general threats. 

i) Access control mechanisms such as authentication and authorization
(to ensure only valid endpoints are allowed on the network)
ii) Ingress address filtering to prevent packets with topologically
incorrect IP addresses from being injected into the network
iii) VPNs to provide remote access to clients
iv) Firewalls to provide advanced filtering mechanisms
v) IDS/IPS to detect and prevent intrusions 
vi) Application level filtering where applicable (e.g., detecting and
discarding email spam)

A combination of the above (or the like) needs to be used to address the
general threats mentioned above (in B, for e.g.). Given that, what does
NEA bring to the network that isn't already provided by such mechanisms
that need to be employed anyway? It is not like we can stop using some
of these mechanisms if NEA is present, since the threats that NEA may
protect against (from the network perspective) are a small subset of the
general threats that a network operator must consider. And, when the
general threats are addressed, any subset of those threats are also
addressed. 

The effectiveness of NEA is tied to the type of endpoint (i.e.,
truthful, compliant endpoints with known vulnerabilities). A network,
OTOH, needs mechanisms that protect against all kinds of endpoints. I
fail to understand why a particular category of endpoints that NEA
addresses is not viewed as a subset of the general category of "all
endpoints". 

Some further comments inline. 

> -----Original Message-----
> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Tuesday, October 10, 2006 1:30 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
> 
> "network protection". In fact, it has been suggested that the 
> charter be revised to say "NEA must not be considered a 
> protection mechanism for networks." I don't agree.
> 
> authorization, strong encryption for data at rest and in 
> transit, user education, etc.
> 
> In the context of an overall security program and when 
> combined with other security technologies, NEA can help 
> protect networks.
> Let me list the ways.
> 
> First, NEA can help improve the security of cooperating, 
> truthful endpoints. 

How is this network protection? As you state above, it is about
improving the security of co-operating, truthful *endpoints*. 

> When a cooperating, truthful endpoint 
> connects to the network, its health can be checked and any 
> problems fixed before it can come under attack. This helps 
> protect networks by keeping endpoints healthy so that fewer 
> endpoints become infected and potentially impact the network 
> through port scanning and other misbehavior.
> 
> endpoints can be vulnerable to a zero day attack. And NEA on 
> its own provides no protection against lying endpoints and no 
> protection against hosts that don't participate in NEA 
> protocols. But it's a lot better than today's situation where 
> some endpoints are completely unprotected with patches or 
> anti-virus software.
> 

Once again, given that a network operator must really protect against
many generic threats, what kind of improvement is NEA bringing to the
security of the network? 

> it doesn't exist. Without NEA or similar protocols, it will 
> be hard to integrate lying endpoint detection systems into 
> network access control. That's why the NEA BOF in Montreal 
> agreed to include language in the charter saying that "the 
> protocols developed by the NEA WG must be designed to 
> accommodate emerging technologies for identifying and dealing 
> with lying endpoints."
> 
> Third, endpoints that don't initially participate in NEA 
> protocols can be quarantined for further examination with an 
> external vulnerability scanner or a dynamically downloaded 
> NEA client. Again, this is not part of the proposed NEA WG 
> charter but it is another example of ways that NEA can be 
> used with other security technologies to improve network security.
> 

I'm confused by the above - what is the role of NEA here? 

> To summarize, the NEA protocols will increase network 
> security on their own. When combined with other technologies, 
> the increase in network security is much greater. But either 
> way it is not accurate to say that NEA is not a protection 
> mechanism for networks.
> 

I continue to remain puzzled on the above points! 

Vidya

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Wed, 11 Oct 2006 19:55:34 +1000

Narayanan, Vidya wrote:
<SNIP>
>> I continue to remain puzzled on the above points!

Hello Vidya

Perhaps if I put forward an example of how NEA may benefit me it would go
some way to clear the puzzle.

I run a very closed network, ports are closed and not opened unless there is
a validated request, external drives are disabled etc etc.  A contractor
comes in with a notebook and needs to work on some files located on our
internal secure network.  A trusted staff member rings in with the request
to open a specified port.  The port is opened and the contractor hooks up
the laptop to it.  NEA does it's thing and if the laptop doesn't match the
requirements of the internal network policy it is directed to a sandbox
network for remediation.  If the laptop does meet the policy then it allowed
onto the internal network.  I have not had to physically interface with the
laptop or needed to allow it onto the internal network before some basic
checks have been carried out.  If the laptop met the policy requirements it
was quickly allowed into the internal network and the contractor hasn't had
to prove to me their device could be trusted except through automated means
using NEA.  If I wish, I can run some more checks as the laptop joins the
internal network including additional authentication and other hoops to
ensure the system hasn't lied through NEA.

Really I see NEA as providing additional information to a network
administrator so they automate more decisions on the network.  In the above
situation, if I felt NEA provided all the information I needed I'd leave
ports open and be reasonably confident there was little risk in doing so as
unknown systems would be directed to the sandbox network if necessary and if
a lying system was able to make it to the internal network my normal
protection/security measures would catch it out or warn me of the
possibility within a reasonable time.

Just another tool to give network administrators information and systems
they can use to ensure the majority of users get their requirements met in a
reasonable and timely manner.

Darryl (Dassa) Lynch

---

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 11 Oct 2006 16:15:56 -0400

Vidya,

Thanks for your response. I think we may be getting closer to
understanding each other's perspectives. That's a good thing.

Let me respond to your comments inline below. I hope you won't
mind if I clip a bit since this thread is starting to get long.

> B. A network needs to be protected against such generic threats (as

Agreed. There are plenty of other threats but that's enough for now.

> general threats are addressed, any subset of those threats are also

NEA is another network security tool. Like the others, it has some
special advantages but does not remove the need for the others.

What does NEA provide that isn't provided by the others? NEA can

1) identify unhealthy endpoints (vulnerable or infected)
2) quarantine unhealthy endpoints before they can infect others
   or become infected (optionally)
3) repair unhealthy endpoints (optionally)

Yes, NEA cannot provide all these functions itself. NEA provides a
framework for passing messages about endpoint health. Other security
products use that framework to collect, send, and validate specific
posture attributes and then to send remediation instructions and/or
quarantine unhealthy endpoints.

> addresses is not viewed as a subset of the general category of "all

With the aid of technology for detecting lying endpoints, NEA can
also handle that class of endpoints. But I agree that NEA will
probably never apply to every endpoint on the network. For endpoints
that support NEA, the network operator can provide better security.
For endpoints that don't support NEA, it will be status quo.

> Steve Hanna wrote:

Network security is improved because fewer cooperating,
truthful endpoints turn into uncooperative, infected
endpoints that then flood the network with attacks.

> many generic threats, what kind of improvement is NEA bringing to the

See my comments above.

> I'm confused by the above - what is the role of NEA here? 

I'm pointing out that endpoints that don't initially participate
in NEA protocols can be quarantined and directed to a web page
where they can run a dynamically downloaded NEA client. So this
expands the set of endpoints that can be handled by NEA.

> I continue to remain puzzled on the above points!

I was previously confused by your perspective but I think
I now see where you're coming from. I think you want to
provide a network that's as secure as possible without having
any involvement in how endpoints are configured. That's
one valid perspective but it's not the only valid one.

Many enterprises want to know about the configuration of
endpoints connected to their networks. They may or may not
restrict network access for endpoints that don't comply with
their policies. Some ISPs want to provide endpoint security
services for their customers and therefore want to know about
endpoint configuration. Do you now see the value of NEA
for these network operators? And maybe you see how NEA
can help them make their networks more secure?

Thanks,

Steve

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Oct 2006 22:29:03 +0200

In the end, I believe all NEA can do is help good hosts stay good.  Bad
hosts will stay bad, and may or may not be identifyable as such.  Still,
the former ain't nothing.  But I agree with Ted at least in part that a
standardization effort for the content within NEA is challenging.  I do
not think the licensing issues are quite so severe, however.  If people
understand the limits of NEA, then the liability should be a solvable
problem, but then I'm really so not a lawyer.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Oct 2006 22:29:03 +0200

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Oct 2006 08:59:07 -0700

On Tue, 2006-10-10 at 20:01 -0700, Narayanan, Vidya wrote:
> I am rather confused by this attempt to make NEA fit into some kind of
> a network protection mechanism. I keep hearing that NEA is *one* of a
> suite of protocols that may be used for protecting networks. Let's dig
> a bit deeper into what a network may employ as protection mechanisms
> in order to protect against all kinds of general threats. 
> 
> i)   Access control mechanisms such as authentication and
>      authorization (to ensure only valid endpoints are allowed on the
>      network)
>

If an application happens to be malware, it seems it would be unlikely
stop these applications.  How about: 

vi)   Provide application level advisory information pertaining to
      available services.

Points that seem to be missing are:

vii)  Notification of non-compliance. (Perhaps this could become a
      restatement of i.)

viii) Time or sequence sensitive compliance certificates provided
      following a remediation process or service.

Often bad behavior is detected, such as scanning or sending spam which
may violate AUPs.  These violations may trigger a requirement for the
endpoint to use a service that offers remedies the endpoint might use.
There could then be a time-sensitive certificate of compliance offered
following completion of a check-list and an agreement to comply with the
recommendations.

Those that remain infected after remediation, or that ignore the AUPs
and are again detected, may find this process a reason to correct the
situation or their behavior, or the provider may wish to permanently
disable the account. 

-Doug

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Fri, 13 Oct 2006 07:27:53 +1000

Douglas Otis wrote:
>> 
>> If an application happens to be malware, it seems it would
>> be unlikely stop these applications.  How about:
>> 
>> Often bad behavior is detected, such as scanning or sending
>> spam which may violate AUPs.  These violations may trigger a
>> requirement for the endpoint to use a service that offers
>> remedies the endpoint might use.
>> There could then be a time-sensitive certificate of
>> compliance offered following completion of a check-list and
>> an agreement to comply with the recommendations.
>> 
>> Those that remain infected after remediation, or that ignore
>> the AUPs and are again detected, may find this process a
>> reason to correct the situation or their behavior, or the
>> provider may wish to permanently disable the account.

Am I mistaken or is NEA intended to be a compliance check before a node is
allowed onto the network?  As such, observed behaviour and application abuse
would seem to be issues that would be dealt with by other tools.  NEA may be
used to ensure certain applications are installed and some other
characteristics of the node but actual behaviour may not be evident until
such time as the node has joined the network and would be beyond the scope
of detection by NEA IMHO.  NEA may be used to assist in limiting the risk of
such behaviour but that is about the extent of it that I see.

My reading of the charter gives me the impression NEA is only intended for a
specific task and some of what we have been discussing seems to extend well
beyond the limited scope proposed.

Darryl (Dassa) Lynch

---

From: Leif Johansson <[email-masked]>
Date: Mon, 16 Oct 2006 11:00:59 +0200

> v) IDS/IPS to detect and prevent intrusions 
NEA might help here by providing a common semantics for communicating the
result of IDS scans of hosts to policy decision points.

    Cheers Leif