A bank is going to have a different threat profile from that of a car dealership. Because banks deal with currency and funds, you can skip a great deal of risk (as an attacker) by going for the money rather than the painful and labor-intensive activities required to sell or to part out a stolen car.
If you have a bank and the bank relies heavily on the Internet for account transfers or funds management, you have a remote target. Once again, our car dealership is going to rely on the Internet for fleet orders, customer inquiries, and the occasional car sale. Really big thinkers are going to find some way to manipulate the system to have cars delivered to some fictitious business where they can be "disappeared." However, even that doesn't come close to being in the same league as a financial institution. Different businesses, different threats, different return on, well, nefarious investment.
While someone on your team is off finding out about business profiles, someone else from your team has done some research and discovered that the target has a network assigned to it. So, what is the next step? To scan it, of course! Let's get the low-hanging fruit out of the way and see whether they have any endpoints that we can touch from the Internet. That means a scan. The very same kind of scan that an organization is going to do in the course of a VA scan.
Now we come to the conclusion that there is no low-hanging fruit, and attacking the technology directly isn't going to work. So what do you do? You attack the people and the processes that they rely on to get their jobs done. Chat with some employees and get the help desk number. With a little more ingenuity and some dumpster diving, you can learn quite a bit about a small number of employees. People are generally very proud of what they do or very angry with someone "inside," and both emotions can be used against them.
You can also intimidate them if you're really good. We used the information that we learned from a company newsletter and some intimidation to get a help desk engineer to change the virtual private network (VPN) password of the CIO of a Fortune 100 company over the phone. We were then able to access the network via the CIO's VPN connection. How did this happen? The help desk person didn't follow procedure.
The purpose of this discussion is to underline the fact that not all vulnerabilities have to do with technology. Human-driven processes are the next target on the list when the technology pushes an attacker to try something else. Because human-driven processes can take more time, the fact that they have been penetrated will also take more time. Some vulnerabilities merely make the technology available to attackers.
Contractors and Visitors
What good is a solution if it doesn't address your real-world needs? Well, one of those needs for many of us is the requirement that contractors and visitors must have some sort of Internet access. In some, if not many cases, contractors and visitors will be reluctant to install your client-based solution onto their system. I know that I would have some heartburn installing a remotely managed client on my private notebook!
The good news is that CLPC-based solutions such as those discussed in this chapter allow for this very condition. When you configure your process, you can say that systems that don't comply will be relegated to an Internet-access-only network if they fail the remediation process. Systems are given a chance to participate, and those that choose not to cannot access internal resources but can still access the Internet.
Key Points
Know Your Architecture
You must be keenly aware of your network infrastructure and what capabilities it represents before you decide on a CLPC path. If you have an older network infrastructure, you may have to turn to other technologies to implement a CLPC solution. Older infrastructure may not be capable of supporting 802.1x without a sizable infusion of budget, so you may need to turn to DHCP or other forms of compartmentalization in the interim.
You must also keep in mind that there are going to be devices on your network that won't be able to operate properly if they are isolated, such as printers, so you must plan your solution around them. With that in mind, other network enclaves must also be considered when you start forcing them into a new access control model. Different security controls might have to be placed on these systems.
Three Basic NAC Models
The three basic NAC models are 802.1x, DHCP, and compartmentalization. 802.1x has the benefit of being a standard and forms a nice proportional control that is difficult to bypass. However, some of the tools needed, mainly a host integrity checker, are only offered by a few vendors. In addition, 802.1x-enabled devices may not be completely deployed throughout your network, creating "attack holes" that can be used to gain entry.
DHCP offers the advantage of being easy to implement while being relatively inexpensive to deploy. All enterprise endpoints have a DHCP client that can be easily configured and managed. The downside to DHCP enforcement is that it is easily bypassed by a skillful attacker.
The last method is compartmentalization, or the breaking up of your network into security zones. Many networks already use this design philosophy to separate production, development, intranet, and extranet networks. Although it does require a modification to the network fabric, it does reduce the speed that viruses and worms can spread at by forcing them through chokepoints such as ACLs.
You need to keep in mind a dark side of compartmentalization: When you have a secure compartmentalized network, you need to address the reality that different users and different applications are going to require access between compartments for business purposes. You're going to have to build an exception process that evaluates these requests based on a balance between security and business need.
It gets darker when you realize that at some point the complexity of your security architecture will create a situation in which the processing of exceptions becomes a major task that requires a small army to manage. At this point, the complexity and lack of visibility has completely eroded the security you were seeking. You will have to craft a solution that just manages the exception process, and I say that's when exceptions become the rule—thousands of firewall rules, to be exact.
You also have to consider that over compartmentalizing will break some basic functions on your network. For example, a basic element of large networks is that they have a group that monitors service. Most of us have to live with service level agreements (SLAs) that dictate how fast we respond or how often service is provided. In a large network with lots of applications separated by lots of firewalls, you can find yourself with service monitoring problems.
Select Vendors Carefully
NAC is still young, and vendors are still wrestling with the "model." By "model," I mean the marketing and messaging model. When you consider a vendor, make sure that the components they sell will work and play well with the components on your network. Will the proposed solution work with your RADIUS server? Will you need to build a proxy? How will the supplicants and host integrity modules get on the endpoints?
Don't Believe in Futures
Lots of ideas never make it from marketing to engineering. I know because I've been stung by them as well as been the one pushing them. For this reason, you need to stick with what's in front of you today. Make plans that can incorporate proposed features, but don't stake the security of your design on futures.
Allowing Controlled Access Is Important
In some cases, you will have to provide access to contractors and guests. It's best to provide this access in a way that reduces or eliminates the exposure your network has to unknown threats. By effectively using the automated features of a NAC solution, untrusted systems can be allowed to attach to your network and gain restricted access to services such as the Internet.
VM Has a Place in the Process
For a VM solution to work properly, it must have controls that ensure that the correct decision is being implemented and that the implementation is correct. Simple discovery and patch methodologies can present problems for existing applications and even introduce new vulnerabilities. They also don't ensure that the critical patches have been reviewed and implemented on the critical systems. By layering a control process that incorporates the build and regression process onto your VM process, you can be assured that patches and fixes are being implemented in an auditable and repeatable fashion.
Penetration testing can also be a useful tool for verifying that procedures are being followed and to discover vulnerabilities in your processes. Keep in mind that many of our processes are driven by people, and people have short memories. These memories can be "updated," however, through training and regular exercise such as that provided by penetration testing.
Technology, Process, and Closing the Loop
Closing the loop means more than just throwing some technology at the problem. NAC does have a place, but if you don't understand where your vulnerabilities are (both technical and nontechnical), you're leaving a very critical portion of the loop wide open.
Knowing where your vulnerabilities are and understanding how they affect your overall security processes is critical to understanding exactly where all the loops that need to be closed are. Some methods are faster and more closely approximate real time than others, whereas some operate at a much lower frequency, such as vulnerability scanning. Some processes, especially those with humans in them, are very slow and are potentially the weakest link.
However, by effectively merging the technologies associated with endpoint security into a well-engineered, self-managing, trust-based CLPC solution, you can mitigate many of these problems before they become liabilities.
Footnotes
Symantec bought Sygate in 2005. SEP, Sygate Enterprise Protection, was renamed to Symantec Enterprise Protection.
D. Bell & L. LaPadula, Secure computer systems: Mathematical foundations. Technical report ESD-TR-73-278, The MITRE Corp, Bedford, MA, 1973
http://en.wikipedia.org/wiki/Bell-LaPadula_model (The original paper at MITRE is hard to get.)
RFC 2131
http://www.microsoft.com/technet/security/Bulletin/MS06-014.mspx
Copyright © 2007 Pearson Education. All rights reserved.