Who really needs a 2 or 3 GHz computer with 512MB of memory? Now that I'm working on a review of a 1.6 GHz 512MB ThinkPad T40, I see from the CPU usage meter in Windows Task Manager that I'm not even making this system break a sweat. Will anything ever come along to absorb our computers' spare horsepower?
The answer is: probably yes. And then some.
More and more malicious infiltrations are finding their way past the perimeter security or, worse, are inside jobs perpetrated by someone who was thought to be trusted.
If there's one class of applications that's on the verge of a demand swing, one that will require significant horsepower at most if not all network endpoints --- be they desktops, notebooks, handhelds servers, or otherwise --- it's security.
Note to Bay Area Readers
Would you like to be part of a live webcast event on security?
To join ZDNet's Dan Farber for Digital Defense Test 2003 on September 24,
The best designed security solutions will involve measures deployed close to the application execution and communication endpoints deep inside those perimeters. Why? Ask yourself this question: Whom can you trust? Your answer determines the list of endpoints with which all communications and connections can be allowed and should be secured. More importantly, the endpoint that needs securing is not just the physical system itself. Even that is too close to the perimeter and, like firewalls, creates a single physical barrier to multiple resources when outside processes or people typically don't need access to more than one of those resources. For example, should someone with the authority to send you an instant message also have access to the documents on your hard drive?
Most experts I talk to agree that security will ultimately involve encryption and that the encrypted links won't be only between machines, but also between processes For many, the idea of Web services--where software components that talk to each other can be in the same or different systems--brings home this notion of where the endpoints are and how deep into a system the encrypted channels must penetrate.
It isn't difficult to imagine a couple of different encryption-based security models for application-to-application communications. For example, two physical systems could establish an encrypted session using version 6 of the Internet Protocol (IPv6). Within that encrypted tunnel, the communication taking place between applications residing on both systems could also be relying on their own encryption agreement. Or, since IPv6 expands the available number of addressable entities on the Internet to a limit that an additional populous planet couldn't tax, perhaps every single process capable of establishing a link to another process (on the same or separate systems) is assigned its own IPv6 address and is therefore maintaining its own IPv6-based encrypted communications.
Add to all that encryption a healthy dose of personal- and application-level stateful firewalling, anti-virus, and intrusion detection to keep the bad stuff out, and it's not hard to imagine these and other security measures swallowing your spare CPU cycles.
Jeff Austin, Intel's Desktop Platforms Group marketing manager, agrees with my theory that security measures will absorb spare CPU cycles.
"You can build a fence or a wall, but it only takes one penetration to get free reign, not to mention if the attack is from an insider," says Austin. "Most of the data that traverses the network eventually goes through a client. Consider all the different types of encryption: SSL, IPSEC and other VPNs, etc. Clients will need to be able to support all of these, and all of these will need to run in the background without impacting the end user. The same goes for virus scanners. As you run these virus scanners, looking at every piece of information that comes in an out of your system, it starts to tax the platform as well as the user. Our benchmarks show that running multiple applications at the end of just one encrypted pipe requires more processing power than running just one application. To handle that load, we'll be looking to provide better performance through megahertz, hyperthreading, and multitasking. Particularly hyperthreading. Hyperthreading is what can separate the user experience from all this stuff happening in the background."
Intel isn't alone in looking at the performance hit that security measures are likely to incur on systems. Kevin Knox, AMD worldwide enterprise business development director, tells me:"The reason that security has not taken off is that it's slow and it's interrupting users. How long have we been looking at backup? Why doesn't it happen? Because it slows things down. The only way to go is to make it transparent. The same goes for security measures. Between encryption, anti-virus and other security measures, more stuff is going on in the background than before and they will eat up a lot of cycles that are sitting idle on a lot of computers."
Intel's Austin caution, however, that more CPU horsepower won't be enough to support software-based security measures. "Software-based storage of the keys that are used for encrypted communications are not impregnable," says Austin. "To address that, we worked with IBM, HP, AMD, Microsoft and others in the Trusted Computing Group to deliver the Trusted Platform Module (TPM)."
The TPM is a motherboard-based authentication system that can add a cryptographically unique identifier to every system. To the end user, TPM will serve as a hardware-based storage mechanism for holding any keys that might be needed to manage encrypted activities. To the IT department, it will serve as a unique identifier on which to base access control. "For example," says Austin, "not only can it help to manage a situation where I move from machine to machine (or device to device) and it knows that I'm Jeff Austin, but it helps the IT department manage whether a particular system or device is allowed to access the network. When you combine those two things, an IT department can set rules for what systems or devices Jeff Austin is permitted to access the network from."
Working with the TCG on projects like the TPM isn't Intel's only security offensive. The chipmaker is cooking a technology in its labs with the code-name LeGrande. Instead of relying on operating systems to create software-based protected memory spaces in which applications and their data reside, LeGrande will create hardware-based protection where the partitions correspond to different instances of the host's operating environment.
"LeGrande is about two to three years from delivery, " says Austin. "Access of the functionality would be via an API and today's operating environments would have to be rewritten to take advantage of it."
"Doing anything from a client perspective," reiterates Austin, "whether it be anti-virus, encryption, Trusted Platform Modules, or something like LeGrande --- it will take up processing cycles." To prepare for this scenario, Austin recommends that IT managers look for hyperthreading support. "Our 2.6 GHz and lower gear doesn't have it. At 3.0 GHz and up, you have the choice. We're recommending corporate builds have hyperthreading."
AMD is working on its own security extensions. According to Knox, "We're working with the various operating system and BIOS vendors, as well as a few others, and over the next 12 to 18 months, we'll be delivering some exciting stuff that's a combination of hardware and software. While I can't provide the details, I can tell you that hardware will play a much bigger role in security than it has in the past."
How much of a role? Time will tell. In time, the different hardware and software-based solutions will come to fruition. In time, we will see what sort of demands these solutions place on system resources. In time, those with malicious intent will figure out their countermeasures. In time, we will figure out how to manage what will amount to a very complicated security stack.
What do you think the security stack of the future will look like? Share your thoughts and ideas with your fellow readers using ZDNet's TalkBack. Or write to me at email@example.com. If you're looking for my commentaries on other IT topics, check the archives.