Timeline for Security considerations in providing VPN access to non-company issued computers
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2012 at 16:26 | comment | added | Mark Beadles | @EvanAnderson I wish things were always that simple. If IT/security always had the final say on who connects to the network, then we could always choose the path of least risk. But we also have to be prepared to be overruled by the business - and when we are, we should offer solutions to help protect the environment as much as we can when that happens. If DNUCKLES has the authority to say "no" to those users, great. But if he doesn't, then he's got to do something. | |
| Apr 13, 2012 at 14:54 | comment | added | Evan Anderson | I don't mean to sound uncivil. I don't pull punches w/ my observations either. NAC in an environment w/o "trustworthy computing" (enforced by hardware TPMs, etc) doesn't provide any real security. You can assign a "fuzzy" trust value to the data you get back from a NAC system's assessment conducted in the absense of trust, but all that's doing is ignoring the fact that the source of that assessment is untrustworthy. "Mitigating" risk with strategies that are based on a false assumption don't sit right with me, and I don't consider a "good feeling" to count as security. | |
| Apr 13, 2012 at 1:22 | comment | added | Mark Beadles | @EvanAnderson If you are interpreting my answer as saying "NAC will solve all your problems" you're getting me wrong. As I stated quite clearly, it's an option. As for your "joke"/"false sense of security"/"security theatre" comments, I have so say I'm surprised at your vehemence. I'm relatively new to this particular site and if that is a common way to respond to answers made in good faith, I may visit here less. | |
| Apr 13, 2012 at 0:58 | comment | added | Evan Anderson | NAC only has value because it isn't widely deployed. Just like Trojan horses on Macs, if a target gets big enough it will be attacked. Personally I don't see NAC as having value on any device that doesn't have hardware-based countermeasures against running arbitrary code, and as console systems have shown, even then that's typically not enough. Incorporating a false sense of security into a risk management strategy is, to me, just security theatre. | |
| Apr 13, 2012 at 0:04 | comment | added | Mark Beadles | @EvanAnderson What you say is not looking at things from a risk-management point of view. If financial or business reasons dictate that unmanaged devices sometimes need to connect to your network, you can't just throw up your hands and say "NAC is a joke". You need to minimize the risks they present, and NAC is one mechanism for doing so. You mention "untrusted devices", but even machines you own and manage aren't completely trusted, right? Even machines you own can be infected or used maliciously. I think NAC can be valuable as one element of minimizing risk of untrusted devices. | |
| Apr 12, 2012 at 22:09 | comment | added | Evan Anderson | NAC on untrusted devices is a joke. You can't trust an untrusted device to tell you about itself. Scanning an device for vulnerabilities externally only tells you what it is exposing to the world-- nothing about what's inside it (think honeypots or vulnerable machines behind host-based firewalls). | |
| Apr 12, 2012 at 17:07 | history | answered | Mark Beadles | CC BY-SA 3.0 |