You may be surprised at the number of companies I talk to that have mobile laptops that will never physically come back to the corporate LAN. These could be road warriors, people working from a home office, computers that act as kiosks or are customer-facing, and so on. Are these computers a threat to the corporate LAN? If the data they have on them ever goes back to systems on the corporate LAN, they sure can be. Also, if they ever connect back via a remote access solution, they could adversely affect the LAN.
So, how does a LAN-based NAC solution help protect against these devices? The answer is that they may not provide any protection. If the LAN-based NAC solution only assesses devices that are attempting to physically connect to the corporate LAN, then it may never be protected from these mobile devices. A possibility is that the NAC solution could perform its functionality while the laptop attempts to connect to the LAN via the remote access solution. That would provide some protection. Otherwise, no protection is provided.
N O T E You should be noticing a theme here. LAN-based NAC solutions need to be designed to perform their NAC functionality not only for devices that are attempting to gain access to the LAN while physically at an office location but also for remote devices attempting connections from outside of the physical office.
Employee-Owned Home Computers
There are a ton of companies out there that allow employee-owned home computers to connect to the corporate LAN. For many enterprises, it is a win-win situation:
Workers get to be productive while at home. This benefits both the worker and the employee.
LAN-Based NAC 65 The enterprise typically doesn’t necessarily have to pay for Internet
connectivity, as many business workers will have home Internet service. The enterprise doesn’t have to support the home computer.
For the longest time, if a home worker wanted to connect back to check e-mail or finish a project later in the evening from home, the worker would receive a VPN client from the IT department. This VPN client would be installed on the home computer and the user would simply have to double-click on the client, enter a username and password, and would then be connected back to the corporate LAN. The employee would then have access to e-mail, files and folders, internal systems, and so on. What a great situation! What a potential nightmare!
Why is this a potential nightmare? The main reason is that the enterprise is allowing a system of which it has no real knowledge Layer 3 access to its network. Essentially, this device can become another node on the network, just like one of the sedentary desktop computers that is actually sitting at the office.
The sedentary desktops have quite a bit of protection the whole time they are powered on. They sit behind firewalls, intrusion-prevention equip- ment, anti-spam, e-mail-filtering systems, URL and Internet-surfing control systems, and so on. All these systems are in place to protect that desktop computer and the corporate LAN from being compromised.
Then, seemingly out of nowhere, an employee-owned machine that spends 99 percent of its time directly connected to the Internet becomes a node on the LAN. This machine may not have a personal firewall, an antivirus application running and up to date, and an antispyware solution running and up to date; it may not have any critical Microsoft patches installed, and so on. The system is also used to surf the Internet freely; the teenage son uses it to download all kinds of free game applications, the husband uses it to view adult material, and so on. Essentially, this employee-owned system could be completely compromised and yet, it is allowed to be a node on the corporate LAN with the same access as that sedentary desk- top computer. I hope you see why this has the potential to be such a nightmare. If not, go to Chapters 4 and 5, and you’ll see exactly what can happen.
As mentioned in the previous section, a LAN-based NAC solution can help protect against these types of devices by applying its NAC functionality to the employee-owned device when it attempts to create a remote access VPN connection to the LAN. The NAC solution wouldn’t necessarily be able to tell if the employee-owned system had been compromised, but it could at least check to ensure that it had basic security applications installed, running, and up to date.
66 Chapter 3 ■ What Are You Trying to Protect?
In addition to performing NAC functions against the employee-owned system, there are a number of other best practices that can be implemented to protect the enterprise from these type of systems, including:
Segregate remote access systems from LAN-based systems— This can be done by only allowing devices accessing the network via VPN to access specific subnets. If employees using home computers only need to access specific systems, only give them access to those systems — don’t open up the entire network to them. This can easily be done using group attributes on the VPN devices.
Use an SSL VPN device instead of an IPSec VPN device— When an IPSec connection is established, the remote system is given an IP address on the corporate LAN, and it essentially becomes a node on the net- work. This exposes the LAN to a huge amount of risk. SSL VPN can be used to give the user working from home only browser-based access to internal resources. The users do not become nodes on the network and will only pose a limited threat to the systems that they are access- ing. SSL VPN devices have come a long way and offer a plethora of security and control options.
Use web-enabling e-mail systems— Many users working from home simply want to check their e-mail from their home computers. Giving them Layer 3 access via IPSec VPN is overkill for this type of situa- tion. Many corporations are utilizing Outlook Web Access (OWA) and I-Notes to allow employees to check their e-mail from any computer outside of the office. The employees would simply open their browsers, go to a specific URL (such aswebmail.companyname.com), then log into the web page with their network credentials and have access to their mail. It’s very similar to using Yahoo! or Hotmail web-based e-mail systems. Again, this exposes the LAN to much less risk than giving full Layer 3 access. OWA, I-Notes, and other web-enabling e-mail sys- tems can be used with SSL VPN devices to provide an extra layer of security.
Utilize two factor authentication (such as RSA tokens)— The enter- prise really has no way to know if a keylogger is installed on the employee’s home computer. A keylogger could have been installed via malware, or it could have been installed by a jealous spouse, and so on. I’ve seen reports that have stated as many as 1 in 15 computer systems has a system monitor, such as a keylogger, unknowingly installed. Even if the 1 in 15 figure is completely wrong, let’s say it’s more like 1 in 100, that is still a ton of systems that have keyloggers installed. This can be a serious problem for corporations. Most enterprises are have their infra- structures set up where the user’s domain username and password is the
LAN-Based NAC 67 same as the user’s username and password to access the LAN via IPSec
VPN, SSL VPN, OWA, and so on. This is for convenience and ease of administration. The problem arises when users attempt to access OWA, IPSec, or SSL VPN, and so on, from their home computer and a key- logger is installed. By entering the credentials to gain remote access to corporate resources, they are typing in their very valuable and sensitive domain username and password. These credentials can be captured by the keylogger and passed on to somebody who should not have these. This would give an unauthorized user or hacker all the information they would need to attack the corporate LAN by posing as the legitimate user via the key-logged credentials. If, however, the enterprise utilized RSA tokens, this wouldn’t really be a problem. Users would enter their usernames, their personal identification numbers (PINs), and then the random tokencode from their RSA token. Since the tokencode changes every minute or so, requires physical access to the token, is random, and can only be used one time, it wouldn’t matter much if the passcode (PIN plus tokencode) was captured by a keylogger. This is a perfect example of where two-factor authentication should be utilized.
When it comes to employee-owned systems, LAN-based NAC systems can provide a level of protection for the corporate LAN if designed properly. That proper design, coupled with the aforementioned best practices, can permit enterprises to give employees a form of access to corporate resources from the employee’s home computer.