Section 3.4. Build a Secure Internet

3.4. Build a Secure Internet

We are now engaged in the transition from isolated one-person computers to the concept of a personal network, enabling people to tap into their personal cyberspace from any point on the globe.

The most fundamental requirement of such a personal network is that individuals be able to maintain the most private of information without worry, no matter where their travels might take them. They further need to be able to monitor and control access of others both to their information and to themselves. Before that can occur, we will have to build a multiplicity of new, secure walls.

The original ARPANET , forerunner to today's Internet, was the exclusive domain of university scientists and the U.S. military. The world was neatly divided into "We" and "They." "We," the "good guys," had access to ARPANET. "They," everyone else in the world, did not. Security, in those days, consisted of keeping the "bad guys" from gaining physical access of any kind to the network.

DESIGN CHECKLIST

Achieving balance:

• Are you exploiting the differences between users and attackers?

  • Users know what they are typing inthey are only looking for errors.

  • Eavesdroppers, meanwhile, have to reconstruct every character accurately.

  • Users are closer to the screen and therefore can read with lower contrast and can differentiate better between green and blue (unless they are colorblind).

• Are you detecting and exploiting differences in physical location?

  • Home

  • Office

  • Airport and other public venues

• Are you providing a way that your software can track location changes or the user can casually indicate such changes?

• Are you varying security with the task?

  • Temporary versus archival security

  • "Here" versus "there" versus "en route"

  • "Hide from co-workers" versus "Hide from competitors"

• Does your design exploit the special skills of your user population?

• Does it serve to reduce the user's burden?

Authentication:

• Are your passwords restrictive because of:

  • Low upper-limits on password length

  • Passwords that are system generated

  • Other password rules that encourage posting the password on a yellow sticky note

• Is it quick and easy to obtain or replace a password?

Methodology:

• Did you begin with a comprehensive field study?

• Have you set up regular usability studies?

• Do you have systems in place to capture user feedback after release?

Privacy:

• Will your users enjoy greater privacy while using your design than they did before?

The transition to a public Internet suddenly allowed every bad guy in the world complete access, but ARPANET's decision to have virtually no internal security was never revisited. As a result, per Symantec,^[2] by the close of 2004, more than 60,000 viruses , worms , etc., were crawling the Internet in search of Windows machines. An additional 60 such creatures were looking for Macs. These amateur attacks have been joined by the professional attacks of spammers , phishers, and spyware makers, rendering the character of the Internet something akin to that semi-abandoned strip mall just out of town, the one not to be visited after dark.

^[2] As reported in "Computers: Shiny Apple," Consumer Reports (Dec. 2004).

Today, individual application and OS developers are working frantically to secure their products, even as the "bad guys" develop more sophisticated methods of attack. This is akin to our leaving the doors to our houses wide open while expecting our flatware manufacturers to frantically develop ever-better self-protecting silverware. Patch, patch, patch is not working now, and it's never going to work. We need a fundamentally different approach.

3.4.1. Ringworld

Individuals need a private network presenting a series of secure, concentric walls that surround the user and his information, with each outward wall presenting a more restrictive boundary.

Today, we have virtual private networks, or VPNs. They tend to focus on "We," with the "We" being large corporations that want their employees to continue to work at home and abroad. Everyone else in the world is the new "They." These VPNs restore the binary security model of the ARPANET era, except on a corporate rather than global level. It's a good stopgap measure, but far short of what is needed.

The computer world needs something that is at once both more personal and more general than today's VPNs, consisting of four or more separate and distinct rings. Such a system once existed in the physical world. We need only look back to the future.

3.4.1.1 Within the Castle Keep

The "Castle Keep" of medieval times was the private realm of the castle owner and only the castle owner. This small tower in the center of the castle grounds formed the last bastion should the castle be overrun.

Each individual's VPN must be a personal Castle Keep, offering refuge from all assaults by an increasingly dangerous and aggressive cyberworld. This will be a difficult wall to construct, for the owner must be given free and easy access to his personal cyberspace from an airplane seat, a cell phone, or a hotel room in Nairobi, while at the same time, every other human being and machine on the planet, at the user's command, can be absolutely locked out. People should be able to adjust the porosity of this wall without raising the ire of those being further restricted, something that will be a good trick.

There's a delicacy about separating from family and friends. We usually depend on such subterfuges as telephone answering machine announcements claiming we're out when we're really watching the game. This approach should be extended into the VPN arena.

Because most of the impetus for VPNs is coming from big business, individuals have had few choices for a conveniently portable information space. A business opportunity exists for innovators to move into this space, selling to individuals the same capabilities that other companies are now offering big business.

3.4.1.2 Within the Ramparts

The next wall surrounding the Castle Keep is the Ramparts, that outer defensive barrier (just before the crocodile-infested moat) shaping the extent of the castle grounds.

Typically, today's users will live simultaneously within two castles, their home castle and their work or school castle. Within these virtual walls of the home castle, for instance, Dad will be able to communicate freely with other members of the family residing in the castle, subject only to restrictions set by other family members' personal Castle Keeps. This will be equally true should Dad be in the living room or on safari in Nairobi. These connections will typically be more liberal than those between the family and the outside world.

Many people will elect to keep their two castles separated, dividing home/leisure from work or school. Others may encourage both to flow together, viewing their home and work lives as a continuum, rather than as two distinct activities. What will be important is to offer people the permissions and the tools to make these choices themselves, simply and fluidly.

Work on VPNs supporting the work castle (corporation) has already come to fruition, although more must be done to smooth and define the walls. Home and school lag far behind.

3.4.1.3 The Town Wall

The area between the Ramparts and the Town Wall will represent a sharply reduced connection.

In the case of the family castle, these connections include access to trusted friends and relatives, along with businesses ranging from banks to e-commerce outlets to health care resources (all of which maintain their own private networks).

In the case of the business castle, it includes access to clients, suppliers, distributors, accounting firms, banks, etc. Much of this infrastructure for corporations, in the form of one-off efforts, has been in place for years. Wal-Mart is perhaps the best example.^[3]

^[3] Sam Walton and John Huey, Made in America (Doubleday, 1992). If you have never read a "business book," this is the one to read. It is fun, engaging, and enlightening. (If you do read business books, you've already read this one.)

3.4.1.4 Beyond the Town Wall

Finally, we have the connection between the greater private sphere represented by the Town Wall and the "outside world." No one lacking specific permission to enter either town or castle property must be able even to begin to breach these walls. They might send entreaties, in the form of, for example, television commercials with clickable links, but they cannot get in. No way, no how.

In addition, those begging an audience should be subject to certain rules. For example, one of my rules would be that a merchant must promise not to spam me. Tools such as the Platform for Privacy Preferences (P3P), discussed in Chapter 22, and Acumen, discussed in Chapter 25, are a start on just such a wall.

Our job in cybersecurity will not be complete until we have provided people, when in cyberspace, with greater protections than they now enjoy in physical space. This is an achievable goal, and this generation of security specialists will attain it.

3.4.2. Ringworld Interface

The ideal interface is no interface at all, and most of the complexity of a multilayered security scheme could and should be hidden from the user. Those parts that are visible should enable the user to simply and flexibly change security parameters.

The top level could present the very metaphor I have, with the various elements of the medieval town, presented visually. If the user wants to add an email correspondent to his town, for example, he should be able to drag-and-drop his attached avatar onto the image of the town. (The builders of Ringworld would define these avatars.) Similarly, he could later promote that person by dragging his avatar inside the castle walls.

As users' populations grow, users could, instead, choose to see entities in text lists or iconic groupings, similar to traditional folder views. Users could fine-tune the permissions of individual entities by opening their avatars or icons, displaying a simple and compact permissions panel.

The settings of this panel and even the avatar's location in the ring would also reflect implied changes brought about, for example, by a user refusing further email from a suddenly bothersome merchant. Depending on the ramifications of the change, the user would be prompted for confirmation before making an adaptation.

Fine-tuning to the proposal will, of course, prove necessary. The goal, however, is clear: provide a multi-ring, high-security environment that supports, rather than restricts, the user, one that requires minimal setup and casual, flexible modification.