Wireless Security Demands More than Technology

by Chris S. Thomas, George Moakley, Regina Lynn Preciado, and Matt Gillespie


Introduction

Perpetual tension exists between new functionality and the security required to support it. This tension is manifest in the challenge to fully implement wireless technology while not compromising the data on the client device or the rest of its home network.

This article is the first installment of a two-part series in which Intel® Sofware Network solicits opinions from two veterans in their respective roles at Intel to weigh in on topics of note. The other article in the series provides a similar treatment of the topic of manageability in wireless environments.

Intel Chief Strategist Chris S. Thomas is considered one of Intel's visionaries, charting future directions for industry and computing. George Moakley is Director of Enterprise Architecture at Intel and is the lead architect for Intel’s e-Business Solutions Lab. Their different business roles shape and inform their discussions, which together form a whole that is more than the sum of its considerable parts.


Chris S. Thomas on Reversing the Philosophy of Security

The first part of this article presents the strategic and philosophical point of view held by Chris S. Thomas toward addressing the security challenges presented by widespread deployment of wireless technology.

As Thomas has intimated in his (http://www.intel.com/ids/chrissthomas) previous columns, a huge change in how we do business and how we architect is upon us. Emerging business models based on what George Moakley calls “active mobility” – the ability to stay connected while moving from hotspot to hotspot and protocol to protocol – are inspiring us to re-think the way we conceptualize and realize security.

Thomas sees three major shifts happening:

  • Moving to a “security provider” model
  • Segmentation replacing end-to-end security
  • An architectural, rather than technological, approach to security

 


Home Base: Security as a Service

We are moving toward a sign-on philosophy in which users sign on to one location – a security provider – through which they connect to everything else. This connection might become a permanent VPN or fixed-line connection between user and service provider. For example, if AT&T is my security provider, and I need to connect to Intel, I would sign on to my AT&T account. From there, AT&T* would connect to the corporate LAN. That connection would always be the same. I always return to my “home base” (AT&T) to get to my communication path.

Unlike technologies like Passport*, the security provider model simply provides you with access. Passport assumes a play in the content; for example, it provides a wallet for brokering money. You register to do what you want to do.

In a security-provider relationship, users register their devices with the provider. You no longer have to negotiate between end points, just the one connection with the provider. Your security provider then connects you to other systems.

In this kind of arrangement, corporate IT does not have to worry about users logging on to the network where they might gain access to sensitive information. Malefactors have a much harder time sneaking through with viruses or denial of service attacks. Working offline and synching through intermediaries significantly reduces the number of problems for IT by eliminating the log on.

The asynchronous model is unlikely to reduce performance. Even when you are online in a synchronous mode, there is a delay (network latency), whether you measure it in milliseconds, seconds, minutes, or hours. And synchronous is really asynchronous when you are hitting routers in between. It is not an issue of whether synchronous will go faster; rather, it is a matter of architecture.


Security Segmentation: Trusted Relationships Do Not Log On

Trusted relationships do not log on. They do not initiate processes. They do not even enter into the environment. A trusted business relationship is a messaging relationship with clear boundaries.

Here is what I mean by this:

  • I do not want to create a door in my environment for you to come in.
  • I do not want to have user IDs and passwords.
  • I do not want to have you capable of initiating a business process on my side of the firewall.

 

In most corporate environments, if you remove inter-employee communication from the equation, most employees lack a compelling reason to log into the corporate network and services. Instead, we could set up messaging relationships, perhaps through individual users’ service providers. Once an account is identified and secure, the employees can get everything they need through messaging.

The subset of people who will be inside the corporate applications, who need a login to function, are a small number in very controlled islands.

The industry has not yet adopted this thought process overall. But in 2002, 40 million people submitted their taxes this way. They used TurboTax* to fill out their forms, which they submitted to Intuit* in a trusted relationship. Intuit then sent the forms to the government in another trusted relationship. The government sent refunds to the individuals directly. Everybody has a trusted destination for the information. If someone submits my tax form to Intuit who should not have, it is obvious, and I have to deal with it because that falls into my segment of security.

In his section of this article, George Moakley points out that you will have information on your device that needs to be protected from anyone who may invade, steal, or break into the box. That is true, because the malefactors will continue to figure out where to place their dirty deeds (which is one reason I do not advocate procedural-based Web services).

If, however, I instead send you a document that you can scan, and you are expecting a certain payload, it is very difficult for that payload to be corrupted. If data is being moved in an XML document, you are not worried about the application because you can scan the data as it is moving. In a segmented security model, the user’s computer is not part of the network. It is simply a messaging partner.


Closed Loop Security: Architecting for a Secure Future

I look at security as an onion, with layers of physical and logical security. The device is the core and contains some level of ID. The user provides the next layers of logical security, protecting the data with encryption, passwords, and so on. Another layer of logical security identifies the user when he or she uses a different computer or device to access the same data.

Aysnchronous architecture changes the security risks but does not eliminate them. What mitigates risk is the contractual relationships between parties. We have already reached the limits of what end-to-end security can provide. Segmented security can pick up where end-to-end leaves off. With a segmented security model, each layer of protection is owned by somebody. That somebody is contractually bound – by business and service agreements – to provide security for its segment. I believe this will be the most secure architecture for an actively mobile computing population.

Corporations do not have as big an architectural challenge with internal security, as they can be a trusted intermediary. They can implement single sign-on and security policies to secure wireless devices and networks. However, as an enterprise begins to work with not just one entity but dozens, it gets harder for one point to secure all those entities. Over time, I think we will see intermediaries that manage access – and there is a new model, a new philosophy, and a new approach to security. It is an architectural approach rather than a technology approach.

Of course, we need technology to provide security – and that is the underlying value proposition – but it is not sufficient in itself. The business models we apply to security are equally relevant. Securing the user does not establish the contractual and business commitments that companies really need, and it does not make the business environment function.

Closed-loop security means developing an agreed-upon legal environment within which we work, instead of coming in each time and establishing our ID and user environment before we can function. I might not even do the transaction myself. I may designate a proxy. Alternatively, I may have agreed with my service provider to some number of dollars worth of service, paid for dynamically or automatically. Because I have authorized them to proxy for me, all of these transactions are contractually valid.


Opportunities for Developers to Design the New World

Developers have many opportunities to design this new architecture.

  • Solution architect – Start with the security architecture in your workflow and business process flow, regardless of what technology lies underneath.
  • Software architect – Establish clearly where the security handoffs are between you and other elements, including networks, databases, user devices, peer devices, etc. Develop a clean definition of who owns the security of the information and when that is no longer your responsibility. (Otherwise, you will continue to be the owner and implicated in security issues even if you handed off to another sec urity segment.)
  • Middleware architect – You have a massive opportunity to secure the information (the payload) and to secure the processes that are traveling through the middleware. This environment is begging for support right now.
  • Hardware architect – The security performance algorithms you design are crucial to devices not slowing down or draining the batteries during pre-processing of packets and data elements. I/O is going to be tied to more and more security functions.

 


Silicon: Powering a Secure Architecture

I am espousing a network architecture in which silicon plays a huge role at every point on the path. A set of performance improvements has to occur to process each message in an asynchronous architecture. A device will need to be able to query other devices to ensure that the devices are not corrupted. Being able to move seamlessly through hot spots is going to require a lot of performance, and Intel® processors are going to provide that edge.

On the service side, processing the payloads, Intel processors will provide the performance to parse and process XML, to scan and secure data, and perhaps even to create keys and other safeguards for the user environment.

Silicon is in the equation in all shapes and sizes, from the smallest handheld device to the biggest intermediate messaging appliance.

I believe that the nature of standards we have driven for the last seven or eight years and the change to service-oriented architectures and XML are fundamentally reversing the philosophy of security. Security becomes a wonderful opportunity to architect differently and to create new business models.


George Moakley on Actively Mobile Users Raising the Bar

The remainder of this article responds to Thomas's comments from George Moakley's perspective, that of a hands-on architect working on individual solutions.

In a previous article, Moakley identified "actively mobile users" as that class of mobile users who use applications continuously while moving around, among, and between networks.

Those networks may be of different topologies, and they may be owned by separate providers. The challenges represented by maintaining a session as the user moves between those networks are clear, but they are accompanied by security challenges that we are only beginning to work on.

As a user moves between connection points with a connected PIM device, PDA, or laptop, the security scheme must include the security linkage handoff between those connection points. This challenge is becoming more complex in the emerging wireless-applications environment. For instance, if you are in a 3G cellular mode and a Wi-Fi access point becomes available, your device should be smart enough to drop the cellular connection in favor of the Wi-Fi network.

Not only must the systems make that switch without losing the application session, but they must determine whether they can do so without compromising security, identify the appropriate security system for that environment, and seamlessly adjust functionality accordingly. Application architects must address all of these concerns.


New Means Are Needed to Maintain Security across Multiple Networks

There is, at present, a lack of tools available that can maintain a security session (such as a single VPN connection) for an active user moving between networks. This lack corresponds to an opportunity for service and software providers alike.

One possibility is for something to be embedded in the device itself that uniquely identifies it, so that as it moves around, it can perform a handshake with distributed equipment to identify itself, obtaining authorization to continue the security session. Moreover, these systems must support a dependable mechanism that conveys the fact that the system has not been compromised, to guard against session hijack or spoofing.

The situation presents an interesting trust relationship between a corporate network and its mobile users. Not only must the network be able to confirm that the user and device are trusted parties, but it must also be able to verify that their activity since last connecting does not threaten security on the overall network.

Thus, the network must be able to scan the device for viruses and other compromising effects. Moreover, devices should be security managed in the disconnected state; the continuity of management can then be attested to upon reconnection, potentially obviating the need for actual on-connect scans, which could require a lot of resources and time.

Ultimately, devices need to be identifiable, both from the standpoint of asset management and from that of security, and there is a lot of overlap between those two issues. That identification requires a consistent method to communicate the information to other entities, including other users, as well as services.

From a customer point of view, that role should be filled by the carriers, which implies the need for standards between carriers that do not exist yet. The bottom line is that, the more we depend on this type of communication, the more robust our security requirements must become, and there is a substantial lag in satisfying those requirements that will certainly worsen before it starts to get better.


Client-Network Trust Relationships Place Large Demands on Devices

As mentioned above, part of the burden of maintaining secure sessions between providers falls to the applications themselves. At the same time, however, it is impractical to depend on every wireless application being designed (or redesigned) to accommodate this requirement.

While there is a role for the equipment itself and a role for the software running on that on equipment, much of the security must be associated with a one-on-one trust relationship between the client and the network.

Whether there is a single session and applications that presume that they are on a network, or between applications on a per-message asynchronous architecture, there is a need for trust between them. As Chris Thomas discusses in his discussion, the ideal situation is to move all applications to service-oriented architectures.

One further challenge is that highly granular payloads can create high levels of overhead. More and more applications send very small events to trigger large responses. For instance, a very small data set that represents a pricing update could trigger a relatively large amount of processing on the client side.

A large number of such transactions will be accompanied by a large amount of security-oriented computation per message to verify, for instance, that they come from a trusted source. This scenario ultimately increases the demand for intelligence in the device.


Secure Your Environment, but Expect it to be Compromised

Network administrators want something in the mobile devices that they can touch with their automation systems to positively identify those devices and the users who are operating them. Unfortunately, the same small size that makes handheld devices convenient also makes them very easy to lose or to have stolen.

Whatever data exists on a device, it must be secured well enough that the person who stole it cannot access it, even with a crowbar and a supercomputer, nor can they get back onto the host network. Therefore, when the device comes back online, the network needs to be able to ensure that it is the same device and the same user.

Multi-factor authentication, wherein the network requires, for instance, both 'something you have' (i.e., a token) and 'something you know' (i.e., a password), is an especially good idea in the mobile world. As the technology progresses, we will be looking at adding a third layer, 'something you are' (i.e., biometrics).

We used to think almost exclusively about how to keep security threats out of the environment. A more current way of looking at the issue is to recognize that threats will get in, and so we spend an equal amount of energy identifying them when they do and isolating the extent of the damage.

We are in an arms race in the security space. Every time you give users more powerful tools, you also give malefactors more powerful tools with which to attack your environment. Chris Thomas looks at this issue from a strategic point of view in his section of this article, and the two perspectives are vitally linked. That is, you must address the threats posed by tools as you deploy them, and you must also let the deployment strategy itself be informed by a unifying philosophical vision.

New security solutions represent tremendous opportunity for ISVs, OEMs, and service providers, and ultimately, these issues will be solved. In the mean time, senior executives in particular are today having e-mail forwarded over wireless pathways to non-secure devices, and we need to do what we can to secure them in the near term. It is going to be an interesting few years.


Conclusion

Consider this a call to action for both the user community and for developers. Mobility represents a radical shift in how people can work, and that shift creates a lot of opportunity and a lot of risk. Ultimately, the benefits outweigh the risks, and these technologies will (and should) continue to flourish.

Adopters can either insist that all risk be eliminated before they will adopt the tech nology, or they can identify and fill in the gaps where the largest risks lie. Success generally comes to those who adopt the latter approach.

Developers should start to bear in mind that users will want to use their applications while they are moving about. IT managers should recognize that, as new mobile applications arise, users are going to put them on the network no matter what, and we had better anticipate how to secure them.

Finally, we must provide similar security controls for PDAs and PIMs as we do for notebooks. Virus scanning, intrusion prevention, and host firewall functions are all capabilities that must eventually be part of a complete mobile solution, regardless of the device form factor.


Additional Resources

Intel, the world's largest chipmaker, also provides an array of value-added products and information to software developers:

  • Intel® Software Partner Home provides software vendors with Intel's latest technologies, helping member companies to improve product lines and grow market share.
  • Intel® Developer Zone offers free articles and training to help software developers maximize code performance and minimize time and effort.
  • Intel Software Development Products include Compilers, Performance Analyzers, Performance Libraries and Threading Tools.
  • IT@Intel, through a series of white papers, case studies, and other materials, describes the lessons it has learned in identifying, evaluating, and deploying new technologies.

For more complete information about compiler optimizations, see our Optimization Notice.

Comments