WindowsNetworking.com Monthly Newsletter of April 2011 Sponsored by: SpiceWorks
Welcome to the WindowsNetworking.com newsletter by Debra Littlejohn Shinder, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: firstname.lastname@example.org
I recently received an email from a reader named Eric, and I thought his questions (and my responses) might be interesting to others. Here's what Eric wrote:
"I read your interesting article on 'Death of the DMZ' and was curious as to what your take is on NAC? Is it passé? Is it the answer? Does it solve any of the current problems/gaps in endpoint/desktop security?
NAC years ago was focused on network isolation of intruders, guests, and non-essential personnel. NAC supposedly is now used to verify/validate patches to eliminate CVE issues? Supposed to help secure wireless networking? Is this unique or redundant? What value do todays' organizations derive from NAC products?
Is there a second generation of NAC coming? What would you envision that might look like?"
Of course most of you know that NAC (Network Access Control) and NAP (Network Access Protection, which is Microsoft's implementation) were introduced several years ago with the idea that you should be able to secure your network from rogue client machines at the network level. If a machine didn't meet the security requirements set by your organization, you could prevent the host from reaching any network resources. You could do this in a number of ways, such as by blocking access to a switch port, by moving that client to a "guest" network, or by enforcing IPsec logical segmentation. Each method has its own advantages and disadvantages.
Like many great ideas, NAC/NAP failed to catch on with many organizations because of the complexity of the deployment. Not only were the deployments complex, but they often led to inadvertent denial of service to legitimate users - which naturally generated a large number of help desk calls and created major headaches for IT. The end result was that NAC/NAP customers found that they spent a lot of time trying to get the solution to work, and then when it did work, it often worked "too well" and blocked too many non-malicious users, which ran up help desk and associated costs.
Worldwide deployment of NAC/NAP ended up being very small. I heard someone say that total NAC/NAP sales has been less than $300M US - a paltry sum when you think about how excited people were about this security technology back in 2004. There is a lesson to be learned here: if you're going to create a product, make sure it's easy (or at least relatively easy) to deploy, and make it user-friendly. IT Pros are dancing as fast as they can these days and they don't just have a lot of free cycles to devote to figuring out how the latest and greatest Rube Goldberg machine works.
I was one of those folks who was excited about NAC "back then". But as the man said, the world moved on. My opinion of NAC today is related to what most of us are trying to accomplish. I think as we move forward toward networks with increasingly porous perimeters, we are going to need to focus our resources on security more and more at the server and data levels. That means that firewalls on the servers themselves will replace perimeter firewalls, and the data itself must be protected at all times - when it's at rest on the server, traveling over the wire (or over the air), and during "consumption". This "consumption" piece refers to protecting data as it's being read by authorized users and preventing them from sharing it with those who aren't authorized (rights management).
Is NAC/NAP going to go away? I don't think so, but I think it - like so many of our technologies - will change to fit our evolving needs. I imagine a next generation of NAC/NAP will focus on enforcing access controls on the data itself, instead of just access controls on the client computers over the network. When a machine tries to connect to a server to access a piece of content, the machine will still need to be able to pass a health inspection in a way similar to NAC/NAP. If the machine can't pass the inspection, then the machine is denied access and perhaps is offered an opportunity to remediate. After the machine remediates, end assessment is performed again, and if the machine meets corporate security requirements, then it's allowed access to the data.
This approach would allow you to do what you most want to do - secure the data from attack. Sure, you also care about the network being attacked, because there are network exploits, but if the data is secure, you're way more than half the way home to security nirvana. And, much as you might hate the process, an OS or application that's brought down can be rebuilt. Data that's lost may be irreplaceable. So what you care about most is your data being attacked, stolen and disseminated to unauthorized individuals. This approach should be a lot easier to implement, since you don't need to create and manage multiple policies on multiple network devices. You could possibly set the file access NAC/NAP policy through Group Policy, enable the feature on the OS, and away you go.
Combine this with encrypting the data on the disk with technologies like EFS and BitLocker, encrypting the information in transit using IPsec or TLS (HTTPS, etc.), and controlling access during consumption using rights management, and you've moved a complex network-centric security approach to a more streamlined, and arguably more effective, information based security focus.
Do you think that this data-centric approach is more effective than a network-centric approach? Do you think there is a third approach that might be even better? Would you use this kind of second-generation NAC/NAP that I'm proposing?
Let me know! Send me a note at email@example.com and I'll share your comments.
See you next month! - Deb.
By Debra Littlejohn Shinder, MVP
Quote of the Month - "Can you imagine what I would do if I could do all I can?" - Sun Tzu
3. WindowsNetworking.com Articles of Interest
Create a Bootable USB Flash Drive for Windows 7 Installation
If you have a netbook or other computer that isn't loaded with a DVD drive, you might run into problems when upgrading or reinstalling Windows 7, as it comes on a DVD disc. However, if you have a USB flash drive you can load it with the installation files from a disc, using another computer, or from an ISO disc image. Here are the basic steps:
For more administrator tips, go to WindowsNetworking.com/WindowsTips
You have an emergency situation and you need to shut down your servers as fast as possible. Of course, you’re nowhere near the datacenter. How can you remotely shut down your Windows servers? Well, there are a number of ways you can do this, but my favorite is the shutdown.exe command. You’ve probably used shutdown.exe at your Windows 7 workstation plenty of times, but did you know it works on servers, too, and that you can execute the command remotely?
/s tells it to shutdown the computer
To make it short, I studied a bit IP v6 and played with IPv6 native routing, ISATAP&Teredo (all in windows 2008).
What I did not understand is how to tell the computers that get their IPv6 configurations from a router or ISATAP what the DNS's IPv6 address is. Without this, I cannot imagine how hosts using their IPv6 addresses could be able to communicate and function in an AD environment.
I did it using IPv6 DHCP but then, I don't see the need to have routers do the configuration (even stateless).
In the figure 2 in part 2 of your article, DNS shows registered ipv6 addresses but you did not say how ISATAP clients know about that IPv6 DNS.
Thank you for helping me understand this. Thanks! --Thomas.
On IPv6 networks, as with IPv4 networks, DHCP is used to assign options such as the DNS server address. You could also manually assign a DNS server to IPv6 clients. However, the router doesn't assign options like DNS server settings.
In my article series on ISATAP, I showed you how to configure the ISATAP router. Remember, ISATAP allows you to tunnel IPv6 messages over IPv4, which means that the ISATAP messages are actually encapsulated with an IPv4 header. The machines on the network were configured with IPv4 addressing information, which included an IPv4 address for the DNS server. The DNS server was configured to enable dynamic name registrations.
This is how the ISATAP addresses found themselves in the DNS server. Since the clients knew the IPv4 address of the DNS server, they were able to use this address to register both their IPv4 and IPv6 ISATAP addresses.
If the network were a native IPv6 network, then clients would have needed an IPv6 address for the DNS server. In that situation, we would have needed to use DHCP or manually assign a DNS server address to the clients so that they could find the DNS server and register themselves in DNS.