RE: [Nea] WG Review: Network Endpoint Assessment (nea)
> -Original Message- > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 07, 2006 10:43 AM > To: Harald Alvestrand; Narayanan, Vidya > Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > At 01:42 AM 10/7/2006, Harald Alvestrand wrote: > >> > >Many universities require their students to buy their own > laptops, but > >prohibit certain types of activity from those laptops (like > spamming, > >DDOS-attacks and the like). They would love to have the > ability to run > >some kind of NEA procedure to ensure that laptops are reasonably > >virus-free and free from known vulnerabilities, and are important > >enough in their students' lives that they can probably enforce it > >without a complaint about "violation of privacy". > > > >Just pointing out that there's one use case with > user-managed endpoints > >where NEA is not obviously a bad idea. > > My email ventures into a bit of non-IETF territory, but we > are discussing use cases, and so I guess it's on topic. > Universities should be the last places to try antics like > NEA. Whereas an operational network would be a priority to > them, it is also important that they allow students to > experiment with new applications. If we are believing that > general purpose computing will be taken away from college > students, we are indeed talking about a different world. > I agree. Even in a controlled environment, there is bound to be software/hardware that does not quite support NEA or specific posture attributes. In a university environment, while some basic posture reporting is feasible, there is bound to be a lot of software/hardware that does not support any NEA parameters. The protection that even the endhost may be getting from NEA is quite limited. > In any event, the bottomline is NEA as a solution to "network > protection" is a leaky bucket at best. > The charter must be clarified to dispel this myth about NEA protecting the network from anything. Vidya > NEA at best *may* raise the bar in attacking a "closed" > network where endpoints are owned and tightly controlled by > the organization that owns the network. > > Lakshminath > > > >Harald > > > > > >___ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
> -Original Message- > From: Susmit Panjwani [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 07, 2006 5:04 PM > To: Harald Alvestrand > Cc: Narayanan, Vidya; [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > Third, I > > simply can't see what the organization's > interests would be in > > > protecting a device that doesn't even belong to it. > > An organization might not be interested in protecting a > device that does not belong to it but would definitely be > interested in preventing the attacks originating from such > device (if compromised) when it joins the organization > network. It appears that the NEA charter is completely misleading to some people from what is stated in this email. As the NEA charter alludes to, NEA does nothing to protect against compromised devices. Also, as has been agreed, NEA is not a protection mechanism for the network - it is meant to be a protection mechanism for compliant, truthful and as yet uncompromised end hosts against known vulnerabilities. Any network, in its own best interests, must assume that it has lying and compromised endpoints connecting to it and that there are unknown vulnerabilities on any NEA-compliant devices connecting to it. Any kind of protection that addresses these general threats that the network may be exposed to at any time will simply obviate the need for NEA from the network perspective. A network operator that thinks the network is getting any protection by employing NEA is clearly ignoring the obvious real threats that the network is exposed to at any time. This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. Vidya > To cite a study that we performed at > UMD: we did a cost-benefit analysis based on the captured > attacks from within the organization, and it turns out that > the organization would benefit significantly if they > implement any trusted network access technology. > > I do realize that there would be issues in terms of user > privacy and interoperability(which this charter is trying to > tackle) but just wanted to mention that there would be > significant benefits if they can implement it. This is > especially true for university environment. As a matter of > fact I am aware of some universities/departments that were > planning to implement a home grown solution for this. > > Susmit > > -- > Susmit Panjwani > > PhD Candidate, > Center for Risk and Reliability, > University of Maryland > Cell: 240-460-9782 > > > On 10/7/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote: > > > > > > The reason we left it open is to allow the working group to spend > > > more > > > > time exploring the range of use cases in this area to better > > > > determine requirements and applicability. For example, > it may be > > > > useful to classify endpoints as network-managed versus > > > > user-managed versus 3rd-party managed. A user-managed > endpoint may > > > > want the choice to opt in or opt out, say. > > > > > > > > > > > > > Not only do I not see anything in the charter or milestones that > > > indicates that the WG is going to spend time exploring this, I > > > strongly believe this WG should not be spending any time > looking at > > > this. The trust models for the cases where the devices > are not owned > > > by the organization performing NEA are hugely different > and can take > > > up its own WG to actually find something that applies > there, if at > > > all. For one, this could be considered a violation of > privacy by the > > > user of the device. Secondly, the end user's perspective > of attacks > > > may be entirely different from the organization's perspective in > > > this case. Third, I simply can't see what the organization's > > > interests would be in protecting a device that doesn't > even belong > > > to it. Last but not the least, this requires the endpoint to be > > > running an NEA client (that is interoperable with the NEA > server of > > > the organization) - which in itself is often an > unrealistic requirement. > > Many universities require their students to buy their own > laptops, but > > prohibit certain types of activity from those laptops (like > spamming, > > DDOS-attacks and the like). They would love to have the > ability to run > > some kind of NEA procedure to ensure that laptops are reasonably > > virus-free and free from known vulnerabilities, and are important > > enough in their students' lives that they can probably enforce it > > without a complaint about "violation of privacy". > > > > Just pointing out that there's one use case with user-managed > > endpoints where NEA is not obviously a bad idea. > > > > Harald > > > > > > ___ > > Nea mailing list > > [EMAIL PROTECTED]
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 01:42 AM 10/7/2006, Harald Alvestrand wrote: Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about "violation of privacy". Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to "network protection" is a leaky bucket at best. NEA at best *may* raise the bar in attacking a "closed" network where endpoints are owned and tightly controlled by the organization that owns the network. Posture checking is certainly a leaky bucket. It doesn't protect all kinds of endpoint, it doesn't protect the endpoints against all kinds of threats, and it doesn't protect much of anything against a smart, resourceful attacker who is deeply familiar with the NEA system in use and is interested in investing considerable resources in attacking or circumventing it. But (to recycle a very old simile) the fact that I can open the locks of most doors with a crowbar doesn't mean that locks are not useful. Organizations that have deployed products that do something like what NEA is talking about have reported that their TCO is reduced. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Vidya Narayanan, Vidya wrote: >>> -Original Message- >>> From: Susmit Panjwani [mailto:[EMAIL PROTECTED] >>> Sent: Saturday, October 07, 2006 5:04 PM >>> To: Harald Alvestrand >>> Cc: Narayanan, Vidya; [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org >>> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >>> > Third, I simply can't see what the organization's interests would be in > protecting a device that doesn't even belong to it. >>> An organization might not be interested in protecting a device that does not belong to it but would definitely be interested in preventing the attacks originating from such device (if compromised) when it joins the organization network. >> >> It appears that the NEA charter is completely misleading to >> some people from what is stated in this email. As the NEA >> charter alludes to, NEA does nothing to protect against >> compromised devices. Also, as has been agreed, NEA is not a >> protection mechanism for the network - it is meant to be a >> protection mechanism for compliant, truthful and as yet >> uncompromised end hosts against known vulnerabilities. True the NEA doesn't "do" anything to protect against compromised devices but it does assist in limiting the known compromises on endpoint devices by being a mechanism for the checking and reporting on compliance to what ever network policy is in place including virus and patch levels. As a network administrator I already deploy mechanisms for doing just this, but at a higher level than the NEA charter indicates. To me the difference is between being reactive or proactive. Compliance testing I already run occurs after an end node has joined the network, with NEA the possibility is for compliance checking before being allowed onto the network so isolation and immediate remediation is possible. >> Any network, in its own best interests, must assume that it >> has lying and compromised endpoints connecting to it and >> that there are unknown vulnerabilities on any NEA-compliant >> devices connecting to it. Any kind of protection that >> addresses these general threats that the network may be >> exposed to at any time will simply obviate the need for NEA from the >> network perspective. Reliance on one protection or reporting mechanism is not enough. We need a lot of varied tools to cover all the bases and minimise risk. >> A network operator that thinks the network is getting any >> protection by employing NEA is clearly ignoring the obvious >> real threats that the network is exposed to at any time. No, NEA would just be one more tool used to improve overall security and minimise risk. It would be at a different level to the tools some of already deploy. >> This is what I meant when I said that the charter is unclear >> and it must explicitly state that NEA is not meant as a >> protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Vidya
Inline ...
>
> How about adding this text - "It should be noted that the networks at
> large are exposed to attacks from lying endpoints and
> external entities
> attaching to the networks as well as any problems arising from unknown
> vulnerabilities on NEA compliant endpoints. Hence, NEA must not be
> considered a protection mechanism for networks. Further, mechanisms
> needed to protect the network from all kinds of vulnerabilities are
> expected to be a superset of any protection that may be achieved by
> employing NEA"?
>
It seems to me that this better belongs in a security considerations
section of the NEA spec, especially given where we are in the review
cycle and the amount of time spent on this specific section already.
> >
> > Bearing the original motivation in mind, would the following
> > work better?
> > "An organization may make a range of policy decisions based
> > on the posture of an endpoint. NEA is not intended to be
> > prescriptive in this regard. For example, potential
> > deployment scenarios may include,but are not limited to,
> > providing normal access regardless of compliance with
> > recommendations for remediation ("advisory mode"), as well as
> > providing restricted access sufficient for remediation
> > purposes and any essential services until an endpoint is in
> > compliance ("mandatory mode").
> >
>
> I'm not sure that the charter actually needs to get into the modes at
> all - I'm guessing what happens after NEA (i.e., what is done with the
> results from NEA) has zero impact on any work being done in
> NEA itself.
> So, why not simply state something like "Once NEA is conducted on an
> endpoint, the results may be used by an organization in
> accordance with
> any policies of the organization itself."?
>
Again, the text was added at the request of the security AD. I have no
problem with Sam Hartman's modification to the text I proposed, your
text above, or none at all.
> That is not necessarily putting any requirements in the choice of the
> mandatory to implement protocol itself, as I see it. I believe that
> stating something like "The mandatory to implement PT protocol must be
> generic enough to allow the execution of the NEA procedure without
> forcing the need to re-execute network access procedures".
>
I think protocol requirements belong in the requirements I-D.
> Not only do I not see anything in the charter or milestones that
> indicates that the WG is going to spend time exploring this,
> I strongly
> believe this WG should not be spending any time looking at this. The
> trust models for the cases where the devices are not owned by the
> organization performing NEA are hugely different and can take
> up its own
> WG to actually find something that applies there, if at all. For one,
> this could be considered a violation of privacy by the user of the
> device. Secondly, the end user's perspective of attacks may
> be entirely
> different from the organization's perspective in this case. Third, I
> simply can't see what the organization's interests would be in
> protecting a device that doesn't even belong to it. Last but not the
> least, this requires the endpoint to be running an NEA client (that is
> interoperable with the NEA server of the organization) -
> which in itself
> is often an unrealistic requirement.
>
> Organizations that provide services in their networks to end users are
> worried about protecting their resources (i.e., networks, servers,
> etc.). As we have agreed, NEA does not protect such resources anyway.
> Plus, there is absolutely no reason such organizations should believe
> that devices they don't own are in fact, truthful endpoints.
>
> So, thinking that this WG must be looking into resolving this seems
> flawed at several levels. In the interest of having a focused WG that
> can get something useful accomplished, this does not make sense.
>
No argument with your gist here. The point I was trying to make is that
I think applicability may not be quite as "black and white" as your
original text suggests, and it would be better if the applicability and
security considerations associated with NEA be addressed in the WG and
specified in the appropriate NEA documents.
The charter could express itself better in this regard. If the last
sentence was replaced with something like: "NEA can be limited in its
applicability when the endpoint and the organization providing network
access are owned by different parties. NEA applicability and security
considerations will be described in the appropriate NEA documents."
Would this work?
Thanks
Susan
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
WG Review: Network Endpoint Assessment (nea)
I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
