4. Missing Link Discovered

We’ve decided to take a different look at how to solve our problem, and in the preceding chapter we talked about how a different viewpoint can help shape what our solution will eventually look like. But, what is the link between having a secure network and having to deal with the traditional problems of security? In the preceding chapter, we clearly saw that as an engineering domain, security hasn’t developed as quickly as we would have hoped. As a matter of fact, a great number of very smart people have developed a huge number of products, but we still have the same day-to-day problems plaguing us.

As engineers, we need to ask ourselves what common element we have throughout all of this that will enable us to solve this problem? It is the very thing that some folks are claiming has disappeared: the endpoints that define the perimeter. More specifically, it is the relationship between the endpoints and the network that has been ignored.

Précis

No network security solution can work in a vacuum. There is always something pulling security in one direction while users are pushing it in another. The solution du jour grabs our attention, and we hope upon hope that this is the one. But, always present in the corner of our minds is the knowledge that there is no silver bullet. Looming in that same dark corner is the reminder that we must solve the problem and solve it soon.

Our previous discussions regarding process control in Chapter 3, “Something Is Missing,” led us in a direction that helps us unify our solution concept in a way that has never been done before. We saw in that chapter that a complex summation process was missing from our security solution.

We can now represent our networks schematically, as represented in Figure 4-1. Doing so enables us to focus on the functions rather than the artwork.

Figure 4-1. A pictorial and schematic representation of a typical network perimeter. We have represented one user, two endpoints, a switch, a firewall, and an Internet connection.

We’re going to look at how the secure endpoint and process control can work together to form the backbone of our security process. By leveraging the endpoint’s capability to self-assess and to communicate that assessment with the network, and the network’s ability to dynamically reconfigure itself, we can form the foundation of a proportional control that will ensure that our networks are secure and reliable.

Special Points of Interest

As we begin this chapter, keep your existing network architecture and your business practices in mind. As you begin to understand how the solution is going to work, you’re going to have to manage the differences.

New technology will allow the endpoint to play a much more important role in ensuring enterprise security than it does today. Instead of being the source of malware, the endpoint can be the point at which a decision is made that prevents untrusted systems from gaining access.

While on the subject of trust, a slightly different concept of trust versus risk needs to be examined. Instead of using risk as a decision point, we will discuss how trust can be used instead.

Two Data Points Hint at a Solution

Chapter 2, “Why Security Fails,” discussed how much damage there was and how worms and viruses were running rampant on our networks. In subsequent chapters, we examined what hasn’t worked in conventional networks and have postulated a possible solution concept that might work to our advantage. Because we’ve been looking at the 50K-foot level, it’s time we lost some altitude and begin looking at some of the details of our solution.

From the discussion in Chapter 3, we learned that an analysis of our networks based on process control tells us that we’re missing a central proportional control that we can hang our other security tools off of. We have many security tools that can function as integral and derivative controls, but these tools are acting independently of each other and are not tied to a central controllable proportional process.

So, the question becomes, where do we find this proportional control? Are we going to have to completely reengineer our networks for them to work securely? Where should we start? Well, it seems to me that the logical answer is that we start with the endpoint itself, because all the other technology is there to support it. Yes, some networks are going to require some rework, but for the most part we should be able to make this work with what we already have (with some minor additions).

Because we’re going to use a process control model as the basis for our solution, it stands to reason that we need to understand what the set point is going to be and how we’re going to set it. In our examples, that was easy. We set a temperature on the thermostat, or we set a level of water in the bowl. It isn’t going to be that easy here because of how many different interpretations there are for the proposed metric for our set point: risk. The nice thing about risk is that how much you’re willing to accept is based on your particular situation. Some organizations are willing to accept more, whereas others aren’t as predisposed to allowing as much as a camera phone into their facilities.

As the title of this section implies, we have two data points that we can use to craft our solution. First, we have a mechanism that acts as a source of “energy” for our system. If we think about how evil things are introduced into our networks, we can consider this as potential risk in much the same way that the plumbing represents the potential for water. Second, our network can function as a valve, controlling how much “risk” is introduced into the network.

Attack Vectors

After much painful research, it becomes clear that the attack vector of choice is the endpoint. I know that a bunch of you are laughing your heads off and saying that it’s pretty obvious that it’s the endpoint, but I hope that you appreciated the sarcasm nonetheless. The fact is that sometimes you just have to say the obvious thing for the record even if it sounds sarcastic. The thing that’s not so obvious is how the endpoint will play a role in our process control model. I believe that it has something to do with risk entropy, or the introduction of risk into the network environment.

In the discussion of risk, we talk about ways to reduce it and ways of quantifying it, but we never talk about where the risk enters the environment. We kind of talk around it by saying that we’re doing scans and patch management, but we never say it. And yes, many types of risk are associated with our information systems, but clearly the endpoint is above and beyond the largest contributor to loss and therefore risk.

Why? Because most endpoints are general-purpose computers equipped with the tools necessary to generate, manipulate, store, send, and receive digital data. Hackers use this general-purpose functionality to their own advantage, and there’s no reason we shouldn’t be able to use it to our advantage, too.

We shouldn’t ignore the other potential attack vectors, such as social engineering and outright breaking and entering; but if we can force the evil ones to use these other vectors, we’ll have succeeded in our goal of securing the endpoint.

Process Control Analysis

I remember when I first started down the path of analyzing the network with process control eyes. When I started, it was with the intention of understanding how the network security process control function worked. I was astonished when I discovered that there was no underlying proportional control. What I found was a number of pieces of technology that were strung together with the good intention of solving the problem.

My work told me that we needed something capable of linking the side of the system that introduces risk pressure with the side of the system that controlled or mitigated risk to create a functional proportional control. In our present model, we allow the risk to be introduced onto the network, and then we try to identify it and eliminate it through the application of our security tools. The problem with that is that if there’s a leak, the entire system breaks down. In short, we had no way of closing the loop in the process because we still really hadn’t identified where that loop was and how it worked.

Endpoints Look Like the Link

In all of our networks, whether they’re Windows based, Linux, or Blackberrys, the one thing they have in common is the link between user and network. The endpoint is that link. It forms the interface between the user and the resources that the network represents. For that reason, the endpoint is also the starting point in our quest to find a proportional control.

We can’t ignore that the endpoint is probably the smartest node on our networks. It has the capability to know more about itself than any other endpoint. Sure, network infrastructure devices know about operational statistics, and a few of them can tell you the fingerprint of the build on them, but how many of them can tell you whether they comply with corporate policy?

That knowledge—the knowledge of compliance—is what we need to have if we’re going to build secure networks. We can secure an endpoint; but if we can’t keep it secure, we’re going to lose in the end. We need to use that inherent intelligence of the endpoint to our advantage if we’re going to ensure that our endpoints, and thus our networks, stay secure.

Target of Malware

We know that endpoints are definitely the link to introducing malware into the network. As you may recall from earlier discussions, the endpoint is the target of choice for most attacks. Some involve the user; some do not. Even if the user’s not involved, the endpoints can wind up being the host of some pretty evil activity if the botnets get a foothold.

We usually only think about the network when we start thinking about security. We’ve gotten so used to hearing about how worms and viruses propagate that we’ve forgotten about the multitude of other ways that a system can be infected. For example, a little over a year ago, my CEO came to me with what he called a really cool toy. It was a secure USB drive that he’d received from the CEO of another company. It was in a really neat box and looked like a thick pen that I could picture in the pocket protector of a geek (before I could see it in the pocket of a $300 fitted CEO shirt). I asked him, “Did you stick this into your notebook?” He replied, “No! You’ve got me way too scared to plug anything into my USB.” Because the system was designed for Windows, I figured that I could plug it into my non-Windows system and watch the fun. Imagine my surprise when all I could see was a mere 256K! Now my suspicion was aroused, and I had to find out what was going on. As it turned out, this cute little device automatically loaded a system driver that performed the duty of encrypting and decrypting data to a much larger, and otherwise invisible, 256M data partition. I thought to myself, what if this had been a malicious device? My CEO had heeded my warning and was glad he did after I showed him what I’d found. It was a legitimate product, but what if it hadn’t been?

The security industry is starting to develop new tools that control just how the user interfaces with the system. USB drives and memory sticks have been used to install Trojans and viruses, so our reaction is to limit their use. Key-logging devices have been placed between the keyboard and the system to steal passwords. These, and their software cousins, have been responsible for all manner of havoc.

Embedded systems are also at risk here. As dedicated function endpoints, they tend to be the most overlooked systems. As the future rolls on, we’re going to have to embrace a methodology that incorporates how we address the risk associated with these kinds of endpoints.

Medical systems also need to be included in this solution. I’m not going to go into the long, laborious process of describing the medical certification process, but suffice it to say that without some sort method for ensuring that they meet some minimal level of trust, we’re going to have to segregate them from the rest of the endpoints.

Enable Network Access

I suppose that this is the “if you’re a carpenter, every problem looks like a nail” kind of thing. It depends on your perspective as to where network access begins. If you talk to network engineers, they may tell you that it happens at the port on the switch. If you talk to Microsoft engineers, they may tell you that network access begins after you’ve been authenticated with the Active Directory.

There may even be those who say that network access begins when you can see bits from the network. Their argument is that, in essence, you have access to the digital data even though you haven’t been authenticated. This is pretty much a security person’s view of the world. If you can get physical access, all bets are off! I can’t tell you how many times I’ve heard the phrase “if I can get to the keyboard, I can own the system.”

The key point here is that you have to control access to the stream of bits somehow. We look at the endpoint as a way to do that by requiring authentication prior to giving access to the system. However, as we know from the previous paragraphs, we need the network to help if we’re going truly prevent unauthorized access to the bit stream. We may not be able to prevent someone from gaining access to the keyboard, but we can surely prevent that keyboard from gaining access to the rest of the endpoint population.

What Needs to Happen

For our solution to work, a number of things need to happen pretty much in parallel. We need to make sure that the system doesn’t get infected with unwanted software, we need to ensure that the software that we want on the endpoint is installed and configured correctly, and we need some way of guaranteeing that the system complies with our stated policies. We need a way to ensure the integrity of the system.

As I stated early in the chapter, we haven’t built our networks around the Proportional, Integral, and Derivative (PID) process, so we really don’t have a basic proportional control. Add to that that defining risk is a series of books in its own right, and the problem begins to get complicated pretty fast. However, I think that we can craft a proportional control if we make the basic statement that we know what we don’t want on our networks. At a minimum, we don’t want the following:

• Viruses

• Worms

• Illegal software

• Spyware

• Unauthorized users

• Unauthorized endpoints

From these basic desires, we can start to drill down and get some details.

Basic Blocking and Tackling

Before we go any further, we need to get the basics out of the way. These are the basic blocking and tackling drills that have to be done, and done properly, before we can even begin to think about complicating things. I’m going to assume that you have a basic build process (if you don’t, you’re going to need to buy another book). So, at the minimum, we need to make sure that each system has up-to-date antivirus software and that it’s configured with the latest data files, that the system is patched and updated, and that the endpoint has a functioning firewall.

We can look at the huge number of worms and viruses and be safe in the conclusion that unpatched unprotected systems will be attacked, but for the most part we know that if our endpoints are patched, and we have detection and remediation tools, the exposure, and therefore the risk, is kept to a minimum.

When I say “minimum,” there are some things that are difficult, if not impossible, to protect against. Closely guarded vulnerabilities, also called 0-days, are difficult to protect against because nobody knows that they’re there until it’s too late.

Manage Host Integrity

Now that we have something to work with, we can deconstruct our basic requirements a bit. When we do, we come to the conclusion that each endpoint needs to do the following:

• Ensure operating system integrity

• Validate system configuration

• Be remotely manageable

The aspect of remote management is a critical factor for success. You need to be able to designate and enforce a minimum configuration regardless of user protests. We need a policy that says that any endpoint that doesn’t comply with our requirements is denied access to the network. I know that this is going to start many an argument, but the reality is that it only takes one noncompliant system to screw up our network.

Looking at Figure 4-2, we can modify our draconian rules a bit if we incorporate the notion of remediation and compartmentalization. Looking at this another way, we can ask this question: How does the network know that it can trust the endpoint?

Figure 4-2. Basic network access should be quarantined if the endpoint can’t pass four simple tests.

Control Access to the Network

In short, if the network and the endpoint don’t converse, there’s no way that the network can tell whether a system is trustworthy. You have to manually get in the process to prevent rogue connections.

The “simple” way to accomplish this is a thing that many security people do already: They turn off any unused ports. I say “simple” because in theory all one has to do is to remove a patch cable from the wiring closet or send a command to the switch to “down” the port. In reality, this usually requires a call to the network folks, an email request, or the opening of the dreaded trouble ticket.

Disconnecting unused ports is one of those things that is deemed “best practices”—because our physical security systems aren’t perfect, and anyone who manages to slip through the door can just plug into an unused jack. An additional benefit is that those who want to gain legitimate access to the network must verify with the security group that they have met the proper requirements and that the system they want to connect to the network is trustworthy.

Like I said at the beginning, this is a manual and sometimes time-consuming process. However, this is a small price to pay for the benefit of a decision point that we can use to control access to our network. The basic idea is referred to as network access control, or NAC, and there are some new ways to accomplish this same functionality without the manual labor.

Network Access Control

The goal of NAC is to ensure that only systems that meet our stated level of trust gain access to our information resources. It relies on the idea that a system must comply with policy prior to connecting to the network. Present access control methodologies are varied, and some are proprietary, but the end result is that they all prevent unauthorized systems from connecting to the network.

Trusted Network Connect (TNC), Network Admission Control (NAC), Cisco Network Access Control (CNAC), and Network Access Protection (NAP) are all different flavors of the same idea.

The protocols from the TCG are a proposed open standard that many vendors are already generating products for. Although its core authentication mechanism is based on their notion of a “trusted platform”—that is, hardware-based system identification—the basic model is a good one that can be deployed across large enterprises.

The Cisco and Microsoft efforts are, of course, proprietary and are designed to leverage the strengths of their respective product lines. In addition, they use a version of the Extensible Authentication Protocol¹ (EAP) called the Protected Extensible Authentication Protocol (PEAP) that was jointly developed by Cisco, Microsoft, and RSA Security.

The NAC method uses the 802.1x protocol and a client-side agent called a supplicant (see Figure 4-3). The supplicant communicates with an 802.1x-enabled network device, such as a switch or an access point, and the switch communicates with an authentication server running RADIUS.² If the RADIUS server can authenticate the user, it sends a message back to the switch, permitting the connection. Once connected to the network, the normal process of getting an IP address and authenticating with services such as Active Directory (AD) takes place. A quick peek at Figure 4-4 will show you how 802.1x and EAP sit on top of the Ethernet protocols. RADIUS is compliant with PPP, CHAP, PAP, and UNIX authentication protocols but must use EAP extensions to the RADIUS protocol to do NAC.

Figure 4-3. How NAC works on the network. A system can be allowed access, denied access, or directed to specific quarantined networks.

Figure 4-4. EAP can use Tunneled Transport Layer Protocol, thus simplifying the authentication overhead required from certificates in regular TLS.

Other methods of controlling access to the network don’t require a change in infrastructure. Dynamic Host Configuration Protocol (DHCP) enforcement is another way to accomplish a similar outcome. The basic premise is simple: If the system doesn’t meet the minimum standards, it isn’t given an IP address.

Verify a Minimum Level of Trust

Although we can authenticate the user, the 802.1x protocol by itself isn’t sufficient to provide us with the detailed information that we need to determine whether we trust the requesting endpoint. 802.1x tells us about the user attempting to gain access to the network, and TNC associates the user to that endpoint, but it still tells us nothing about the state of the endpoint’s security.

Prior to allowing a system to connect to our network, we must somehow verify some level of compliance with our policy. Some vendors have extended the functionality of 802.1x by using extensions provided in the RADIUS protocol and enhancing the amount of information sent to the network.

Allow Only Trusted Systems

Twelve years ago, Cheswick and Bellovin featured a comic strip by Wiley on the cover of their book, Firewalls and Internet Security: Repelling the Wily Hacker. The comic strip showed a bunch of barbarians standing in front of a carnival barker’s stand. The barker had a sign that said “must be at least this high to storm castle.” The height line was clearly set much taller than any of the barbarians, and was thus stopping them from sacking the king, who was peeking out the corner of a window. It was a valid notion then, and it’s a valid notion now. “Trust, but verify” seems to be the catchphrase for security lately. However, I prefer the phase “comply and connect” because it really says what we want to happen. Show me that you’re trustworthy, and you can come in.

Because the goal is to allow only trusted systems to gain access to our network, we need some way to determine whether the system is truly trustworthy. You might recall from Chapter 3 that the security information manager (SIM) can potentially contain some endpoint-related information. We could use this information, but why not go directly to the source of the information? Using an agent capable of examining the endpoint and sending the information via the extended protocol, we can determine whether the endpoint meets our minimum level of trust. We can ask the following:

• Are all the patches and updates installed?

• Is the firewall running and configured to policy?

• Is the antivirus (AV) running and updated?

• Are only authorized applications running?

• Is this an authorized user?

If these questions are answered “yes,” we can permit the endpoint access to the network. But, what do you do if the answer to any of those questions is “no?”

Remediation of Evil Things

Once again, I’m going to cite the manual process that we use so that we can examine ways to make it more efficient. If you come into work and your notebook won’t connect to the virtual private network (VPN), you call the help desk. In the fullness of time, someone will show up in your cube with a disc that has the latest VPN client configuration on it. After a few minutes, you’re back online. A good hour can go by before you’re fixed.

Worse, you might have an endpoint that doesn’t have the latest patch that prevents the “Want2HaveYourBaby” worm from sending itself and rude pictures of Paris Hilton to everyone in your address book. Which, by the way, your CEO has launched against everyone in your company.

Manual processes don’t work here.

What if when you connect to the network an agent checks your policy against one that lives on a server? If there is a newer one, the agent downloads it and uses it to check your system. The agent can determine whether you have the required patch. If you do not have the patch, the network automatically redirects you to a remediation server that ensures that you are up-to-date before the worm has a chance to attack.

Leverage Technology to Enforce Decision

When we have a decision about the level of trust we have in an endpoint trying to gain access to our network, we can enforce this decision through network configuration. Let’s suppose that a rogue endpoint is trying to attach to your network. Because it doesn’t have the requisite agent to tell the network that it’s trustworthy, the network assumes that this rogue endpoint is hostile and either blocks its access completely or only allows limited access. I know of a few companies that have a policy that says any endpoint that connects to the network gets Internet access by default.

By taking advantage of how the Internet protocol works and how switches and routers operate, we can enforce quarantines and prevent untrusted systems from gaining access to our networks.

Key Points

We can put together a solution that approximates a proportional control in our networks by using the endpoint and existing infrastructure that ensures that each and every endpoint complies with a minimum set of standards.

Endpoint Is Key

The endpoint can be smart enough to check itself and communicate that information to the network. Our network technology is capable enough to automatically and dynamically change virtual LAN (VLAN) configurations in switches and assign and reassign IP addresses to endpoints, thereby ensuring that only trusted systems gain access to critical network services. Endpoints can take advantage of Web-based update capabilities to download and install patches and required software.

Must-Leverage Technology

The various pieces of technology exist to form a basic proportional control that moderates the introduction of risk into our networks. Protocols, hardware and software, must be connected in such a way that they automatically reconfigure themselves based on our dictated policy. Protocols such as 802.1x, EAP, RADIUS, and DHCP can be used to provide access, restrict access, or completely deny access to noncompliant systems.

The Network Is Part of Proportional Solution

We have solutions for the endpoint. We have solutions for our network. What we need to do is embrace the fact that the endpoints and the network must be able to communicate with each other. The network is not the enemy of the endpoint, and the endpoint is not the enemy of the network. By taking some basic functionality afforded to us by our network devices, combining it with some functionality that exists on the endpoint, and adding a little glue, we now can build a functional proportional control.