1. Defining Endpoints

As with any process, to understand it, you first must define the elements that comprise the process. Consider, for example, the temperature-control system in your house or office. The system is composed of the building, doors, windows, insulation, heater, cooler, thermostat, fans, and ducting (see Figure 1-1). The thermostat is used as the control point; the building, doors, and windows define the perimeter. The thermostat controls the heater, cooler, ducting, and fans, and, you hope, the building (assuming that the windows and doors are closed) stays at a constant temperature.

Figure 1-1. A basic heating, ventilation, and air-conditioning (HVAC) system takes air in, heats it, cools it, and then pumps it back into the room. The thermostat controls the entire process. Room components such as walls, doors, windows, and insulation control how efficient the process is.

Unfortunately, defining the process for the purposes of endpoint security is not as clear-cut as this air-conditioning example. Folks in the building industry have a few advantages over us. First, they have a fairly well-defined set of nomenclature that allows them to capture and express their ideas in a universally accepted manner. Second, they have a fairly well-defined set of requirements and success criteria: to keep the room at a constant temperature. The result is easy to see; you just have to look at the thermometer.

The diverse nature of our industry leads to disparate definitions of what an endpoint is. Therefore, this chapter defines what we mean by an endpoint. We increase our spectrum of defined endpoints because to do otherwise would do us a disservice by ignoring those endpoints that could cause the most harm.

Précis

Whatever we decide an endpoint is, we have to come to grips with the fact that because of technology and how our applications deal with data as a programming language, our security perimeter is constantly changing. For instance, PostScript is really a language for defining how a printer is supposed to render a document on paper. Many applications, such as databases and Web browsers, allow programming commands to be embedded in the data to format or manipulate data.

As devices connect to or leave the network, the perimeter changes, and so our security policy must adapt. There has been talk about the death of the security perimeter, and some have even given it a cool name: deperimeterization.¹ However, the arguments that they use to make their case also prove my point that the endpoint is the new perimeter.

If we make a first attempt at a traditional definition, an endpoint seems to be those systems that people sit in front of: the desktops and laptops that we use to create, store, manipulate, and destroy data. These are endpoints. But, a simple look around a busy Starbucks will show you that folks are really doing those tasks on all sorts of systems. Laptops, Personal Digital Assistants (PDAs), smartphones, and Blackberrys—all are part of the latté scene. Furthermore, ubiquitous purpose-built systems, many of which we might not even be aware of, also generate, process, and share data. All these systems have one thing in common: They are at the end of a network connection. The connection might be a wire, or it might be wireless. It might be fast EVDO² or the older and slower General Packet Radio Service (GPRS), but it is still a network connection.

And, by implication, if it is sitting on a network, someone is going to try to hack into it, infect it, or otherwise use it as a spam launching point. The only way to prevent this is to ensure that the target system configuration has some capability to prevent a successful attack. Some systems we might be able to control; others perhaps not. Those systems that we control will obviously be easier to deal with; those that we do not control will have to use other corrective or protective means (such as firewalls).

So now the problem becomes determining which systems we can influence and which ones we must accept as less secure. Clearly, the ubiquitous system, Windows, is an endpoint and one that we can control. Usually. Entire industries have sprung up to meet the needs of Windows users over the past 20 years. I say “usually” because, unfortunately none of these industries has been able to deal with what is often referred to as the “hidden problem”—the elephant in the room, the one system that always seems to elude any and all efforts to secure it, the one system that ends up in the news as “a single computer containing critical information.” Yes, I’m referring to the CEO’s notebook.

Other systems, such as the printers and network-enabled power strips, are another story all together. That’s right, network-enabled power strips are used in data centers so that help desk workers can recycle the power on a single computer (and thus not risk contracting pneumonia in the giant freezer that is most data centers). They have a basic operating system and usually have a Web server on them for easy access. I once did an assessment of a data center only to discover that the entire population of network-controlled power strips lived outside of the network firewall, meaning that any 14-year-old script kiddie with a basic understanding of Web server vulnerabilities could gain access to them. I like scaring CEOs, and it was fun demonstrating the “feature set” of that configuration.

Speaking of pneumonia, how about the systems embedded in medical respirators and integrated circuit (IC) manufacturing plants? Network connections are being used at an ever-increasing rate to provide data for management purposes or control. The medical systems can’t be changed without violating their certification, and the folks in the IC plants are loath to turn off any functioning systems lest profits fall. These are examples of endpoints that can’t be directly secured, so some other method has to be used to protect them.

Special Points of Interest

Network configurations are changing at a frenetic pace. Every day, new devices are added to our networks that extend the notion of what an endpoint is and where the perimeter is. As more of the user community becomes mobile, we’re going to rely more heavily on wireless technology and smaller, easier-to-lose handheld devices. Add to that more “smart” devices that don’t look like computers, and what is actually on your network begins to get fuzzy. It’s not just Windows or UNIX anymore.

So, now we face these important questions: What is an endpoint, and where is my perimeter? How can you protect something that you can’t see? Keep these questions in mind as you read this chapter.

Windows Endpoints

A Windows endpoint is any system that is running any version of the Microsoft Windows operating system, from Windows 95 on up. Why not an earlier system? Because before Windows 95, Windows was essentially a Disk Operating System (DOS) with a Windows manager that acted as an interface to the operating system. Granted, some native 16-bit applications existed, but when the Windows manager became integrated into the operating system, things changed.

We can debate whether this change was for the better, but what can’t be debated is that the ease of use and the large number of applications made Windows the de facto standard for businesses and home users. (By all accounts, the Microsoft operating system represents more than 90 percent of all installed operating systems.³) Consequentially, Windows is also the biggest target for hackers, crackers, and malware.

That’s a pretty big target. Scott Granneman⁴ reported that in late 2003 there were more than 60,000 viruses for Windows compared to about 40 for the Mac and Linux, and a grand total of 5 for commercial UNIX versions. Total virus counts for late November 2006 seem to have leveled off at almost 73,000 according to Symantec.⁵ I did a search for Macintosh and Linux viruses and didn’t find anything contemporary. We can be sure, however, that there are folks working on them. SANS reported on proof-of-concept code that loads spyware on a Mac.⁶ Discovered by F-Secure, the malware loads as a system library and doesn’t require root access to do so.

In the early days of computing, the Mac was the target. As a young security engineer for Lockheed, the first thing I did in my daily security assessments was to make sure that the antivirus software was loaded on the Macintoshes. Time and market share can be the enemy.

Another change to Windows was the integration of a usable IP stack. Even as late as Windows 3.1, the IP stack was an add-in that could easily be changed. I remember more than a few discussions that revolved around the efficacy of the Microsoft stack, and many opted to replace it with another stack.

On a positive note, the nice thing about Windows—well, most versions of Windows—is that it does have a great deal of things that you can do to harden it without spending any money. To that end, we will be looking at the following:

• Is there a firewall?

• Is the firewall up and configured properly?

• Are unknown or unnecessary services running?

• Are patches up-to-date?

• Have basic security settings been made?

I’ve spent some time looking into the third question, and you would be surprised at what is running under the hood! A number of Web sites are dedicated to identifying services and helping you understand whether they can safely be removed. We cover those resources in the section “Initial Health Check” in Chapter 8, “Microsoft Windows.”

We can add to the basic strength by adding some third-party programs that look for viruses and spyware, and thereby significantly increase the endpoint’s resilience to attack.

Non-Windows Endpoints

Anything not a Windows machine is a non-Windows endpoint. I know what you’re thinking: “This covers a lot of territory.” However, we’re going to narrow this somewhat broad expanse of territory by saying that we’re talking about human-driven computers in the traditional sense (such as desktops, notebooks, and servers). We’re going to exclude other systems because they can be classified in other ways, as discussed in this section.

So, for the purposes of our discussion, non-Windows endpoints include all variants of UNIX: BSD, XENIX, IRIX, HP-UX, AIX, Solaris, and Linux. Granted, not all of these are direct decedents of AT&T, but many, if not all, of these operating systems have been used in nearly every environment. Remember the network-enabled power strip? It was running Linux and a Web server called Apache.

Like Windows, these types of endpoints do have a great deal of resilience if configured properly. They have built-in firewalls and plenty of tools that enable them to substantially increase their security posture.

Embedded Endpoints

Embedded systems aren’t really all that well known to most IT people because the whole purpose is to bury the operating system functionality in such a way that it is non-apparent to the end user. As mentioned previously, things as innocuous as power strips⁷ can have a stripped-down version of an operating system, and possibly a Web server, helping with the network interface via a graphical user interface (GUI). Just for fun, pop the IP address of one of your big printers into your browser and see what happens. Most printers now have a network interface that enables you to gather status information or set configuration parameters. As you can see in Figure 1-2, embedded systems are common office/home network appliances.

Figure 1-2. An embedded system is designed to be operated remotely (anything from a printer, to a wireless access point, to a remotely managed power strip).

One of the biggest sources of embedded pain besides printers is access points (APs). APs are the devices that provide wireless network connections over the 802.11 specification, thus allowing wireless-equipped endpoints to connect to your network. APs have two sides to them: the wireless radio-based side and the hardwired side. Some APs have a switch or hub on the wired side that allows multiple devices to connect via Ethernet cables. Most APs have a setting that only allows the Web server to be accessed from one of those internal hardwired connections.

An emerging use for embedded systems is supporting Voice over IP (VoIP). Many of you have seen the applications that turn your computer into a telephone, but few of us have seen the handsets that use the network to connect voice sessions. These handsets differ from the old telephone handsets in that they have an embedded operating system in them. The digital phones have analog-to-digital converters and support electronics that manage the digital signals. These systems use a private branch exchange (PBX) to route calls in much the same way that the old-style analog phones did. The use of digital data just makes them more efficient. IP-based phones replace the analog switching technology and the PBX with an IP stack, switches, and routers. Figure 1-3 contrasts a large, manned, old-style PBX with a modern automated version.

Figure 1-3. Old-style manual PBX (on the left) contrasted with a modern PBX and VoIP handsets. Many PBXs now support VoIP. Modern PBX photo courtesy of PBXpress.

One of the most common yet hidden applications of embedded Windows is in a system that most of us come in contact with often: automated teller machines (ATMs). ATMs use a version of Windows to drive the motors and widgets that take your card, process your request, and drop money into your hands. You’ll be pleased to know that the makers of these machines realize the critical nature of their business, so they’ve taken many steps toward ensuring that their embedded applications are as secure as possible.

Popular versions of embedded operating systems include the following:

• Windows NT (older systems)

• Windows XP

• Windows CE

• Linux

• Purpose-built operating systems

Consider the last one the catchall, because some systems are just too small to be able to utilize even the small footprint of Windows CE.

As you can see, embedded endpoints have the interesting trait of being operating system agnostic—in that Windows, Linux, and Cisco have been used as the base operating system. Add to that the fact that some embedded operating systems are proprietary, and you begin to get a sense of the problem. Because of their somewhat closed environment and lack of vendor-supported patches, these systems represent an interesting, but not insurmountable, challenge.

We explore classes of embedded systems, which systems can be upgraded and patched, and how to protect systems in Chapter 12, “Embedded Devices.”

Mobile Phones and PDAs

Now the endpoint is starting to get interesting because it’s mobile. As you can see in Figure 1-4, mobile phones and PDAs come in all sizes and configurations—not the kind of mobile that says, “Unpack your notebook at the local Starbucks and do your email,” but the “I just got a text message read to me over my wireless headset from my auto-answering voice-recognizing smartphone while I was in the restroom” kind of mobile. This has created all kinds of problems in our society, not from the phone itself, but from the extra features that have been tacked on to them. Who would have thought five years ago that while you were having your email read to you while in the restroom that you would have to be watchful for camera phones or, worse yet, Bluetooth packet snarfing! Bluetooth is a short-range radio connection that enables wireless headsets and synchronization. Packet snarfing is the process of capturing packets. This is potentially a bad combination of capabilities if you can’t keep track of how they’re being used.

Figure 1-4. Mobile phones and PDAs have evolved in a way that enables a PDA to be a phone and a phone to be a PDA. Cameras, voice recorders, Bluetooth, and network connectivity are standard features.

I regularly attend an annual security convention called the Black Hat Briefings, and in 2004, one demonstration showed how to identify and track people from their Bluetooth-enabled cell phones and PDAs.⁸ How could they do this? Don’t the vendors claim that the signal only works for 3 or 4 yards? Yes, they do. And, for most of us, that’s where it ends. I’ve been more than annoyed when I’ve walked 15 feet away from my phone only to discover that my Bluetooth headset has lost the signal and terminated the call. These things only use very low-powered transceivers that put out on the order of about a tenth of a watt. Remember, however, that NASA uses transmitters on deep space probes that only use a few watts of power. The strength is in the receivers and their capability to separate a good signal from the noise. Hacking isn’t just about breaking into computers; it’s about understanding and coercing the protocols and technology to suit your own, sometimes evil, means.

Palm

Although not as popular as it once was, the Palm operating system is still fairly prevalent and will continue to be for the near future.⁹ A large number of sites offer downloaded applications, and thus lots of opportunity for compromise. A quick search of two popular Web sites, www.freewarepalm.com and www.palmgear.com, demonstrates that this is just as viable a software platform as anything you’ll find in your cube. Everything from astrology to adult applications is at your stylus tip.

A huge amount of productivity is packed into a very small place. The downside to this productivity-enhancing tool is that the Palm’s security is inextricably linked to the security of the endpoint to which it is bound. Through a tool called HotSync Exchange, email and files are synchronized with those on the desktop (whether it’s a Windows machine or a Macintosh). If the endpoint is compromised, so is the data going to the Palm. This link has been used as an attack vector in the past. The Palm/MTX_II.A virus dropped a fairly harmless but annoying application onto the Palm by compromising the host desktop.

A number of third-party suppliers of software allow Palm owners to directly access Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) servers. This access is great, but only as long as you understand that you can be connecting to a server and passing your password in the clear to anyone listening to your wireless traffic.

Research into recent attacks came up with little other than the fact that intellectual property can be removed from the device and that it can be used as a jumping-off point for an attack on the endpoint.

Windows CE—Windows Mobile

Once relegated to PDAs only, as you can see in Figure 1-5, the Windows CE operating system is being used more and more in smartphones. Typically taking the form of a PDA with phone capabilities, this operating system can support general-purpose programs such as Word, Excel, and PowerPoint, thus making it look more like a portable desktop than a smartphone. Can you say macro attack?

Figure 1-5. Windows Mobile, or Windows CE, is a small Windows computer in your hand. Some, like this example, come complete with a QWERTY keyboard.

Like Palm, Windows CE devices can bind through a trust mechanism to the endpoint to synchronize files and email. With a network connection, you can also sync with a mail server via the Internet. Some viruses and worms have worked their way into the wild recently. An example of this is Backdoor.Brador.A, a nasty little back door that gives the attacker the ability to do the following:

• List the directory contents

• Upload a file

• Display a message box

• Download a file

• Execute specified commands

With wireless connectivity via 802.11, various cell phone networks, and Bluetooth, it’s clear that the future looks bright for Windows Mobile malware.

Symbian Operating System

Part of the fun of writing a book is the endless hours of research required to confirm the accuracy of facts. I’m getting old, and my memory is starting to fail; therefore, I rely on the greatest collective memory device ever built: the Internet. With Internet research, every once in a while you have what I call a great moment. I had a great moment while working on this section. I went to the Symbian Web site and immediately found on its home page a list of quick links. At the top of this list was Security! I thought, “Wow, this is going to be easy!” So, I clicked the link to learn about Symbian security. This is what I got:¹⁰

Keeping mobile phones safe and secure is increasingly important for everyone involved in using or making a mobile phone. Symbian takes its responsibilities on security very seriously and works to ensure that Symbian OS continues to be the most secure operating system available to mobile phone makers.

Symbian OS is only one of the software components that mobile phone makers use to build mobile phones. For this reason, Symbian is unable to respond to security issues that individual users may have with phones that use Symbian OS. Should you experience any sort of problem with your phone you should contact your handset manufacturer or network operator/carrier to receive appropriate support and advice for your specific handset.

I guess this means that security, or the lack of it, is the problem of the handset manufacturers and the application providers. Now, to its credit, Symbian provides links to the handset vendors, application providers, and other third-party vendors that supply security-enhancing tools. However, they didn’t provide a link to information on EPOC.Cabir, also known as Symbian/Cabir.a.¹¹ EPOC.Cabir, first detected in 2004, is a proof-of-concept (POC) worm that tries to infect other phones via their Bluetooth connection. Proof of concept is just that: proving that you can make something work. From this POC work, we learned that our phones could be successfully attacked more than two years ago. Fortunately, the Symbian operating system requires the user to authorize the attack; unfortunately, however, there are users who will.

Blackberry

Blackberry owners have made it clear that they would rather lose an arm than their Blackberry. I’m not sure how they would type with only one thumb, but it’s clear that Research In Motion (RIM) is pleased that this fearsome loyalty has put them in the top spot of the PDA world.

A quick search of US-CERT¹² turned up 31 vulnerabilities that ranged from denial of service (DoS) attacks to execution of arbitrary code—not many, if you consider how long they’ve been around, but enough to require careful consideration of just how secure the Blackberry is. RIM was worried enough about it that they had @Stake perform a vulnerability test against the server and the handheld.¹³ @Stake gave both the BB Enterprise Server (BES) and the handheld a clean bill of health, saying that they weren’t able to break into either. (Data from the BES is encrypted in transit.)

During my research, I came across a presentation for the National Security Agency (NSA) on the Blackberry.¹⁴ The presentation concluded that although the Blackberry was a good platform, NSA-level security would require adding S/MIME and restricting modes of operation. Both @Stake and the NSA mentioned that Java-based handsets execute only digitally signed applications. That’s good, because it raises the bar on what a hacker has to do, but it seems that the bar has been lowered a few different ways. As recently as 2006, vulnerabilities that crash the handset and the BES were posted.¹⁵ One attacks the heap memory inside the handset; another attacks the BES, causing it to crash.

There is also the issue of email and data that don’t originate from inside the enterprise. If you send an email from your Blackberry at Foo.com to a friend at Bla.org, as the message traverses the Internet, it’s not encrypted. It makes sense why it works, but it’s still not optimal.

Disappearing Perimeter—Humbug!

A movement is afoot to eliminate the security perimeter and classify it as dead. Deperimeterization arguments focus on the idea that the notion of a network perimeter is old and should be jettisoned and replaced with new technology. The Jericho Forum claims that different technology—such as Identity Management and Intellectual Property Management—will replace the perimeter.¹⁶

This is not the first time a group of pundits decided that something was dead or obsolete. A Patent Office bureaucrat made the same declaration about the need for the Patent Office in the early 1900s. A more recent example of this is the Gartner announcement in 2003 that intrusion detection systems (IDSs) were useless and a waste of money.¹⁷ Thankfully, cooler heads prevailed, and the jet engine was patented, as was the computer, the television, and IDSs.

Being somewhat suspicious of claims of obsolescence, especially from competing vendors, I decided to chat with some folks who really understand security perimeters: the military. It would seem that the first thing you do when you secure an area is establish a perimeter. After you have established a security perimeter, you can begin the sordid task of ensuring that everything present within the perimeter is allowed (or, in our network vernacular, compliant with policy). Those that aren’t allowed within the perimeter are, as the military puts it, “prosecuted” or “neutralized” (interesting euphemisms for kill, remove, and arrest).

Establishing and maintaining a security perimeter is not an easy task for us (or for the military). However, the tragic security failures of the past few years don’t have the military claiming that the procedure of establishing a security perimeter is dead (and so they’re not going to bother establishing one). Far from it!¹⁸ The military admits that it’s difficult to establish a security perimeter that also allows day-to-day business activities to be carried out safely and securely. It takes constant vigilance, trained personnel, an adaptive policy, and attention to the smallest detail.

For a more personal view of the military model, all you have to do is look at any international airport. You go through a security checkpoint, and a determination is made as to your level of compliance with the policies that control access to the secure area. You must comply with search requests; otherwise, you’re not allowed to pass. Yes, they look in areas that you’d rather share only with your doctor, but it is for the safety of all those others, and yourself, while in the secure area. In that respect, the checkpoints are like firewalls, letting only permitted protocols through, and the gates are like routers and switches, guiding folks to their aircraft that in this model represent the network.

Looking at the military model and comparing it to our network model, we see a number of blatant similarities. First, by establishing a perimeter, they are attempting to provide a demarcation line where a method for discerning who is trusted and who is not trusted can be used. We call that the perimeter. Inside the perimeter is trusted; outside the perimeter is not. Second, they also have those individuals who are hell-bent on breaking through the perimeter to disrupt activity. So far, our network disruptions have created only productivity and financial losses, but more disastrous consequences may lurk in the future. Finally, we both have methods for identifying violations in policy and “prosecuting” the perpetrators. The military calls them guns and soldiers; we call them antivirus programs and IDSs.

The Perimeter Is Adapting

A nice thing about our present technology and the businesses that use it is businesses’ ability to adapt to the changing demands placed on them by adapting technology. We see an opportunity, and if the technology doesn’t exist, we create it or modify something we have to meet our needs. Over the years, our applications have adapted to leverage the network to make us faster and smarter, and our security tools have adapted to address these new additions of functionality and, in some cases, new technology altogether.

What this tells us is that as our application base adapts, our security must adapt with it. I have never been in a meeting in which someone said, “We have a multimillion-dollar deal, but we won’t be able to execute because of our security policy.” Someone who did say such a thing would be met with laughter. Business will always trump security, and businesses—successful businesses—will always adapt as required to meet the challenges they face. So, our security must continue to adapt. If not, security will be the first casualty in the search for increased profit.

Fast-Moving Isn’t Gone

Imagine something that is fast-moving and difficult to see. As a youngster back in the cold Midwest, I used to ride my bike back and forth to the nearest airport to beg rides from the local pilots. Pilots, being who they are, didn’t work to my schedule, so I spent a great many hours sitting around the terminal and fidgeting with my trusty ride, sometimes turning my bike upside down to adjust some aspect of it that I believed wasn’t performing properly. Adjust the brake, spin the wheel. Adjust the derailleur and give the tire a good yank and watch the spokes disappear while I adjusted some tension spring. It only takes slipping with the wrench one time to know that not visible doesn’t equate to not there.

I also hear people talk about getting a “snapshot” of the network. Good luck. If you’re still thinking of the network as something that you can take an effective snapshot of, you should consider new work. The network is more like a movie or TV program, with each still frame changing a little bit to the next. You need to perceive these changes in a way that allows you to see not just the big picture, but also the subtle nuances of the plot.

Therein lies my point: Just because we can’t see the changing picture doesn’t mean that it isn’t there.

As with virtually every other security subject, there is an opposing opinion. In an article in CSO Magazine,¹⁹ Simpson Garfinkle discusses the issues with the deperimeterization debate and makes some convincing arguments. First, perimeters perform a basic blocking function in acute situations. When something new is discovered, often the quickest way to stop the pain is to block it at the perimeter. Second, defense in depth is critical to dealing with the large, fast, and diverse security issues that we see every day.

The deperimeterization idea has some compelling arguments regarding the addition of new technology and how it will be applied eventually, but I don’t agree with the notion that the perimeter has disappeared. It’s just moving too fast to see.

Endpoints Are the New Perimeter

As discussed previously, as devices join, change, and leave our networks, our networks take on the characteristics of a movie rather than of a still photo. And, just like the difference between the tools that one uses to edit a photo versus a movie, our attitudes (and our tools) must adjust. We need to think of our network, and the network perimeter in particular, as a fast-moving, fluid entity that needs constant attention. Tools that only give us snapshots no longer suffice. We need an approach that embraces the fact that the perimeter is dynamic and fast. The way we’re going to approach that is by ensuring that all endpoints that connect to us are trustworthy.

Because so many of our devices can attach to our networks in so many different ways, it only stands to reason that the endpoint is now the perimeter that we need to protect. This isn’t a turn back to the hard, crunchy shell, soft gooey interior paradigm, but it is an admission that the endpoint is where all the damage is introduced. We have network firewalls that filter network protocols and control large-scale access to our networks, but it’s the small-scale access violations that are killing us. It’s the 5KB virus that comes into the network from a user and uses his or her endpoint as the launching point.

Protecting Data

A brief note on the present and a look into the not-so-distant future.

What we’re trying to do is provide a secure platform for people to get their work done. Period. I would like to talk about some esoteric philosophy about making the Internet a better place, but it would be garbage, because it’s really about the money. We’re trying to ensure that the data that people generate doesn’t get stolen, modified, or otherwise compromised in any way.

We’re trying to do that by validating and ensuring that an intruder cannot hijack the underlying operating system and applications. At the end of the day, however, it will be the authorized user doing unauthorized things that will compromise the data. What we’re talking about is providing a reliable platform for people to launch their ideas and to communicate those ideas with colleagues.

After the system is secure, we need to provide some protection for the data. We discuss this very point when we discuss some of the additional tools that are available from—dare I say it—the vendors.

Key Points

Endpoints can be defined in a number of different ways, but we have chosen to break them into Windows, non-Windows, embedded systems such as printers and ATMs, and mobile devices such as smartphones and PDAs. These devices represent the first point of attack for many different and virulent forms of malware. Without some form of protection, the data that these devices store and manage is at great risk of compromise. Because they are the subjects of attack, whatever kind of endpoint you’re looking at, it is now part of a quickly changing security perimeter.

Endpoints Are the New Battleground

We know that the network is about connecting endpoints, and if we don’t secure them, we’re going to lose the battle. The endpoint is the single most important aspect of the perimeter, and we need to ensure that it’s protected to the best of our ability.

New devices are going to be added to our networks, and chances are that if they’re not an infrastructure device, they’re going to be some kind of endpoint that will need to be managed.

Things Are Moving Too Fast for Humans

Because so many people seem to think that the perimeter has disappeared, one can only conclude that things are moving way too fast for human comprehension. What this means is that we need to look at our processes and tools to understand how they are helping or failing us.