Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Douglas Otis [EMAIL PROTECTED] wrote: It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. Maybe you're saying that a complete systems check would take too long. That is true, but that isn't how the NEA variants are being designed or deployed. Bad actors will always be able to falsify this information, so the NEA does not offer protection. This issue has already been discussed. The NEA should be viewed as a process that eliminates many of the security related support calls. That is not a priority for any customers I talked to. I've never head this as a justification for NEA from anyone. It seems impractical to expect NEA will prevent bad actors from producing the expected results. Which is why recent discussions on the NEA list made it clear that no one was expecting that from NEA. There are anti-virus and OS updating services that could produce a certificate that includes: ... Which is a good idea, and substantially similar to validation and remediation services currently offered. That information still has to be propogated to the device that controls network access. It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. People are doing something similar to this today with quarantine networks, and remediation sites. But it's ad-hoc, and not automated. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. Pretty much, yes. With the addition of a protocol to carry that information from the end point to elsewhere in the network. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. My opinion. I concur. I will also add that my concerns about this work being used outside it's domain of applicability (which as a practical matter we have little control over) pale in comparison to concerns about there being mulitple proprietary schemes for this sort of thing. The last thing we need to be doing is encouraging monocultures through the work we do (or don't) do. I also think this discussion is well over the line of charter debate and into the realm of protocol design. Let's finalize the charter (I thought the latest proposed text regarding scope looked fine) and do the protocol work in the WG. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Narayanan, Vidya wrote: Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. I'm not sure who is missing what point at this time note that the term network does NOT mean ISP network. People who use it as if it means that contribute to confusion. Also, the term network has been used both in the meaning of layer 3 network and in the meaning of the set of interconnected devices that make up the computing environment of an enterprise. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. My opinion. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. Lakshminath My opinion. 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] Re: WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 12:29 AM 10/17/2006, Harald Alvestrand wrote: Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip snip NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Ok. For the benefit of the editor: Let us replace: There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Extreme clipping below: 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Eliot Lear wrote: Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here. Eliot Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Greetings, todd glassey [EMAIL PROTECTED] wrote on 10/13/2006 05:56:42 AM: So then this is an attempt by Cisco and IBM and several others to qualify a SOX reporting and compliance tool - get real. Todd Glassey I'm not sure I follow how you can infer that post-admission status checks are Cisco and IBM's attempt to qualify a SOX reporting and compliance tool. That's one of the wildest leaps of (il)logic I have seen. While my comments here do not represent IBM in any official capacity I can say that IMHO, a Sox compliance and reporting tool based solely on NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the data collected for an NEA posture check be stored as part of an audit trail and would this data be useful? Absolutely! Does that make this a Sox compliance and reporting tool? No way! It would just become another trail of interesting information that would be aggregated in a REAL compliance and reporting tool. One might also consider that the original post concerned post-admission integrity checking as opposed to checking at admission only. The data collected during the admission process would be just as suitable for compliance and reporting as post-admission data. So why does the addition of post-admission checking suddenly make this a compliance and reporting tool? While logic can sometimes be dangerous (my logic is undeniable), I tend to rely on it in the absence of anything better. I don't understand the logic behind your statement. Regards, Frank Yeh - Original Message - From: Frank Yeh Jr To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ; ietf@ietf.org Sent: Thursday, October 12, 2006 3:32 PM Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to terminate the user's current admission session and restart the admission process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software [image removed] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] 10/12/2006 02:27 PM Please respond to [EMAIL PROTECTED] [image removed] To [image removed] [EMAIL PROTECTED] [image removed] cc [image removed] ietf@ietf.org [image removed] Subject [image removed] RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) [image removed] [image removed] Douglas Otis wrote: 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. 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 ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Vidya -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 6:24 AM To: Alan DeKok Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. Harald Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
On Oct 12, 2006, at 2:27 PM, Darryl ((Dassa)) Lynch wrote: Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. NEA should be seen more as a notification process with the goal of avoiding self inflicted trouble tickets. Bad actors will always be able to falsify this information, so the NEA does not offer protection. As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. Agreed. When these other tools withdraw services after bad behavior is detected, NEA can notify the endpoint nothing is malfunctioning, but rather these services have been withheld. A selection of certificates may then be required before additional (or any) services are subsequently granted. The NEA should be viewed as a process that eliminates many of the security related support calls. 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. It seems impractical to expect NEA will prevent bad actors from producing the expected results. There is little that prevents the NEA from providing falsified information. There are anti-virus and OS updating services that could produce a certificate that includes: 1) certificate creator for validation 2) a time-stamp 3) class 4) the user/host identifier 5) resources required for updating the certificate It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. The NEA should also be helpful in deciding whether a range of services are acceptable, and how this can be changed. Perhaps different certificates are required before specific services are granted. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. 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. It seems that the NEA charter delves into too many details. The NEA can act as a bidirectional notification of services. From the access standpoint, these are services granted and compliance services required to upgrade what is being granted. From the endpoint standpoint, their certificates indicate which compliance services have been previously obtained, and the resources needed to renew these certificates when they are considered out-of-date by the access point. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald Alvestrand wrote: A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Harald Andy Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to terminate the user's current admission session and restart the admission process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software Darryl \(Dassa\) Lynch [EMAIL PROTECTED] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] 10/12/2006 02:27 PM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc ietf@ietf.org Subject RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Douglas Otis wrote: 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. 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 ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Alan DeKok writes: The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. I think the requirements document and/or charter would do well to stress this. Perhaps even exclude the 1% case explicitly. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
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) 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) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Douglas Otis wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
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. What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? The first case is certainly current practice, and the second one could arrive any day. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: 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. One of the points that has been made here several times is that the rosy promise of a sandbox for remediation has a number of thorns, even in the case where a posture assessment method has identified a potential issue. As it stands, there are commonly multiple ways to work around a vulnerability, including base-levels upgrades (from OS Foo v3 to v4) specific patches (either to the OS or to the application), and, in some cases, configurations (turning off functionality BAR). Assessing those is difficult; offering remediation is trickier yet, especially when one or more of the systems which may need remediation may not even been active at the time of attachment. As I have expressed before, I have serious doubts that the standardized parameters will be sufficient to do any reasonable assessment, and the same carries through in spades for remediation, since that involves a check that none of the remediations has already been applied. Maintaining a valid, *current* set of patches, OS upgrades, and the like for remediation is going to be a very big task; managing the licensing on it a nasty problem; and handling the potential liability of applying the *wrong* remediation a nightmare. Handling unknown states (even for those running recognized assessors) is an even more problematic issue, but you may not care that some folks run development drops of OSes and applications, since you can always remediate them by offering a downgrade. In your example, the contractor presumably also agrees to your mucking with their laptop configuration as part of the contract, but the number of cases in which this is going to be wise is clearly a subset of all cases and it may be a tiny subset. If I came into your network and offered to work with you, my corporate IT folks would be upset if I allowed you to do any of the updates discussed above, so the sandbox is effectively a denial of network access. That's a policy decision you are welcome to make (it's your network), but it's a complex and risky way to make it. I continue to think that the core of this work (passing an opaque string prior to attachment) has some benefits snip 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. And I believe others agree with your tool in the toolkit view. But if you advertise a saw as a hammer, someone is going to get cut. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hi Darryl, Your email indicates that you would: a) somehow require that a visitor's laptop run an NEA client, b) expect the device to support PAs that the server requires to be checked, and c) trust data coming out of it, rather than treat that endpoint as an unknown endpoint and do IDS/IPS in the network. Other than finding this a rather bizzarre trust model, I have to say that there will be a very small set of such endpoints where the owner of that endpoint is going to be thrilled to allow you to place such clients on his/her device and perform updates on it. In short, this is exactly the type of endpoint I wouldn't imagine NEA being useful for! Vidya -Original Message- From: Darryl (Dassa) Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:56 AM To: Narayanan, Vidya; ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
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. Vidya Narayanan wrote: 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). Agreed. There are plenty of other threats but that's enough for now. 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. 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. 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. 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: 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*. Network security is improved because fewer cooperating, truthful endpoints turn into uncooperative, infected endpoints that then flood the network with attacks. 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. 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? See my comments above. 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? 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
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Brian E Carpenter wrote: 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. What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? The first case is certainly current practice, and the second one could arrive any day. Hello Brian I would be monitoring for unusual behaviour on the network and would be warned if the laptop started to behave in ways not expected. NEA would only save time in getting the system onto the network as instead of physically inspecting it I'd be relying on automated means to judge compliance. It would be an acceptable risk. The risk of someone wishing to hack in or being infected with a virus as you describe is low. I'd mainly be using NEA to assist in those situations where the trust isn't total but there isn't harmful intent. If you know of a system that provides total protection, is easy for users to perform their duties and doesn't have me or IT staff doing physical checks I'd be more than willing to look at it. Let's face it, there will always be a risk of someone getting around any informational or protection mechanism put into play, we all have to judge that risk and set up networks accordingly. If we really want to be secure we wouldn't allow any ad hoc connections at all. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hello Ted Comments inline as appropriate. Ted Hardie wrote: At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: 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. One of the points that has been made here several times is that the rosy promise of a sandbox for remediation has a number of thorns, even in the case where a posture assessment method has identified a potential issue. As it stands, there are commonly multiple ways to work around a vulnerability, including base-levels upgrades (from OS Foo v3 to v4) specific patches (either to the OS or to the application), and, in some cases, configurations (turning off functionality BAR). Assessing those is difficult; offering remediation is trickier yet, especially when one or more of the systems which may need remediation may not even been active at the time of attachment. As I have expressed before, I have serious doubts that the standardized parameters will be sufficient to do any reasonable assessment, and the same carries through in spades for remediation, since that involves a check that none of the remediations has already been applied. Very true, any remediation is difficult. It may be there will be options provided so once a system fails to meet NEA compliance they are offered a number of options instead of remediation, perhaps limited access, no access or intervention by IT staff, all this is beyond the scope of NEA at this stage IMHO. Maintaining a valid, *current* set of patches, OS upgrades, and the like for remediation is going to be a very big task; managing the licensing on it a nasty problem; and handling the potential liability of applying the *wrong* remediation a nightmare. Handling unknown states (even for those running recognized assessors) is an even more problematic issue, but you may not care that some folks run development drops of OSes and applications, since you can always remediate them by offering a downgrade. What is the difference to maintaining the network nodes already on the system. They all have to be maintained and kept in compliance already. NEA just provides some information on what may be needed. In your example, the contractor presumably also agrees to your mucking with their laptop configuration as part of the contract, but the number of cases in which this is going to be wise is clearly a subset of all cases and it may be a tiny subset. If I came into your network and offered to work with you, my corporate IT folks would be upset if I allowed you to do any of the updates discussed above, so the sandbox is effectively a denial of network access. That's a policy decision you are welcome to make (it's your network), but it's a complex and risky way to make it. If they don't agree to the network policy then alternatives would need to be available such as providing a trusted system for them to use. Hackers and theives wouldn't agree to abide by any policy in place but that doesn't mean I have to provide methods to make their life easier :). I continue to think that the core of this work (passing an opaque string prior to attachment) has some benefits I don't disagree. snip 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. And I believe others agree with your tool in the toolkit view. But if you advertise a saw as a hammer, someone is going to get cut. Most accidents occur in the home. People do have to take some responsibility for themselves. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hi Vidya Comments inline as appropriate. Narayanan, Vidya wrote: Your email indicates that you would: a) somehow require that a visitor's laptop run an NEA client, b) expect the device to support PAs that the server requires to be checked, and c) trust data coming out of it, rather than treat that endpoint as an unknown endpoint and do IDS/IPS in the network. You are limiting my options to a small subset of what I would have available. I may sandbox systems that don't have an NEA client and are unwilling to install one, they would be treated as an unknown node and given very limited access, they wouldn't be allowed onto the trusted network for instance. I would expect some information to be available which I would then be able to check against my policy. I would assume a limited amount of trust but would continue to have other mechanisms in place to be informed where that limited trust has been abused. Other than finding this a rather bizzarre trust model, I have to say that there will be a very small set of such endpoints where the owner of that endpoint is going to be thrilled to allow you to place such clients on his/her device and perform updates on it. If they wish to join my network they have to abide by the policies I have in place, they don't like it, they don't get to play. In short, this is exactly the type of endpoint I wouldn't imagine NEA being useful for! NEA is a means to automate the information gathering about this endpoint, if they don't agree to the policies, they will have options to. If a person or device doesn't agree with the policies in place, it doesn't mean I should still provide full access for them. Risk management will dictate what will or will not be allowed. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
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 PROTECTED] Sent: Tuesday, October 10, 2006 1:30 PM To: ietf@ietf.org; [EMAIL PROTECTED]; iesg@ietf.org Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea) 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. 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. 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. 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? 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
