The Internet as Infrastructure

Today, when one connects an application, system, or network to the public networks, one is adding to the "system of public works," that is to "infrastructure," of the nation and the world. 

The standards for building infrastructure, such as bridges, tunnels, and dams, are different from those for other artifacts.  Infrastructure must not fall of its own weight, it should not fail in normal use or under normal load, and must resist "easily anticipated abuse and misuse."  A suspension bridge must not fall because a driver falls asleep and an eighteen wheeler goes over the side.

Notice that the abuse and misuse that can be easily anticipated today, is much worse than when we began the Internet.  Were it not so, we might have done many things differently.

We call the resultant necessary property of infrastructure resiliency, rather than security, but the properties are related.

For any artifact, there are limits to the complexity, scale, load, and simultaneous component failures that the mechanism can be expected to survive. How many simultaneous sleepy drivers and plunging eighteen wheelers must a bridge be designed to survive.

When those limits are reached, what we want to happen is that the mechanism fail in such a way that damage is limited and the mechanism can be restored to operation as quickly as possible.

The three Great Northeastern Blackouts, of which August 14, 2003 was the latest, are examples. It is interesting that engineers see these blackouts as successes while the public and their surrogates, journalists and politicians, see them as failures.

All three were caused by multiple simultaneous and cascading component failures under conditions of heavy load. In all three cases the system failed in such a way that it was restored to a ninety percent service level in a day. While all three were spectacular and exciting, the damage was not nearly so severe as one might expect from a major ice storm.

This is the way that we would like the public networks to fail. In fact, so far, that is what we have seen. We have had massive local failures of the PSTN where it took days to weeks to restore to a ninety percent service level. Most of these were fire related and local. We have had one that was national and caused by a software change. We recovered from this one in hours.

To date, we have had a number of local failures of the Internet, all man-made (mostly caused by the infamous "cable-seeking backhoes or boat anchors"); most were accidental. We recovered from all of these in days. SQL/Slammer was man-made, malicious, and software related; it caused a noticeable drop in service for hours. However, there was not really a discontinuity of service.

It should be noted that SQL/Slammer was a homogenous attack.  That is, every instance of it looked the same.  This made it relatively easy to construct and deploy filters that would resist its flow while not interfering with normal traffic.  However, it is fairly easy to visualize a heterogeneous attack that might overwhelm this remedy.

So, there is wide-spread concern that there might be a malicious software-based attack that would bring down the entire Internet. To some degree this is angst, an unfocused apprehension rooted in intuition or ignorance.  However, it is shared by many who are knowledgeable.  Their concern is rooted in the (often unidentified and un-enumerated) facts that:

* the Internet evolved; it was not designed and deployed
* switching in the network is software-based,
* operation of the components is homogenous
* operation of network management controls is in-band
* users often have default access to management controls
* the topology is both open and flat
* paths in the network are ad hoc and adaptive
* connection policy is permissive,
* most of the nodes in the network are un-trusted and a large number are under malicious control.
* access is open and cheap
* identity of both components and users is unreliable
* ownership and management is decentralized
* other

If the impact of these things on the resiliency of the Internet were as obvious prospectively as it is retrospectively, we might have done things differently.  On the other hand, we might not have.  A little discussion is in order.

Unlike the PSTN, the Internet is packet, rather than circuit, switched.  The intent of this was to make the network more resilient in the face of node or link failures.  

The routers and switches may be software running on von Neumann architecture general-purpose computers.  This may make the network more resistant to component failure while making the components more vulnerable to malicious attack.  

We have become accustomed to the idea that software processes are vulnerable to interference or contamination by their data, i.e., the software in the switch can be contaminated by its traffic.  This exposes us to attacks intended to exploit, interfere with, or take control of switches and routers. 

This may be aggravated by the fact that so many routers and switches look the same.  While there are hundreds of products, most of them present controls that are operated via the Border Gateway Protocol (BGP).  An attack that can take control of one might be able to take control of many.   

Even most non-switch nodes in the network look the same, that is, like Windows or Unix (rather than, for example, MVS or OS/400.)   These two operating systems are open, historically broken, and have a commitment to backward compatibility that makes them difficult to fix.  Historically they have shipped with unsafe defaults and have been corrupted within minutes of being connected to the Internet.  The result has been that there are millions of corrupt nodes in the Internet that are under the control of malicious actors.

Operation of the routers and switches (and other network nodes) is via the network itself; they can be operated from almost any node in the network.  Many are hidden, if at all, only by a password, often weak or even default.  Thus, it might be possible to coordinate simultaneous mis-operation of many nodes at the same time. 

The Internet is open as to user, attachment, protocol, and application.  The cost of a connection to the Internet is a function of the bandwidth or load but the cost of a relatively fast persistent connection is in the tens of dollars per month, about the same as a dial connection a decade ago.  

While one must demonstrate the ability to pay, usually with a credit card, the credit card may be stolen, and, depending on the provider, the name in which the connection is registered may not have to be the same as that on the credit card.  In short, almost anyone can add a node to the Internet with minimal checks on their identity or bona fides.  There will be bad actors. 

The only thing that is required to add a new protocol or application to the Internet is that at least two nodes agree on it and that it can be composed from IP packets.  Use of load-intensive protocols and applications for streaming audio and video were added to other protocols and applications with no changes to the underlying infrastructure.  We have seen DoS attacks that relied upon minor changes to protocols and their use.

At least in theory, the topology of Internet is "flat," as opposed to structured or hierarchical.  That is, at least in theory and with few exceptions, any node in the Internet can send a packet to any other node in the Internet.  The time and cost to send a packet between any two nodes chosen at random is roughly the same as for any other pair of nodes.  

Said another way, both the time and cost to send a packet are independent of distance.  One implication of this is that attacks are cheap, can originate anywhere, and can attack anything attached. 

Paths in the Internet are determined late, possibly on a packet by packet basis, and adapt to changes in load or control settings.  The intent is that there be so many potential paths between A and B that at least one will always be available and that it will be discovered and used.  While the intent is to make the network resistant to node and link failures, an unintended consequence is that it is difficult to resist the flow of attack traffic. 

The original policies of the Internet were promiscuous (as opposed to permissive or restrictive); not only was any packet and flow permitted but there were no controls in place to resist them.  This was essential to the its triumph over competitors like SNA and may have been necessary to its success.  

While controls have been added as the scale has grown, the policy is still permissive, rather than restrictive, i.e., everything is allowed that is not explicitly forbidden.  

Said another way, all traffic is presumed to be benign until shown otherwise.  Attack traffic can flow freely until identified and restricted.

Finally, while most of the nodes in the Internet are un-trusted, and we know that many are corrupted and under hostile control, all are given the benefit of the doubt.  To date there has been little effort to identify and eliminate those that have been corrupted.  Therefore there remains a possibility that these corrupt systems can be marshaled in such a way as to deny the use of network to all, or some targeted group, of users. 

The Internet is robust, not fragile.  It is resistant to both natural and accidental artificial events.  However, To the extent that the above things are, and remain, true, the Internet, and indirectly, the nations, economies, institutions and individuals that rely upon, it are vulnerable to abuse and misuse; concern is justified, if not proportionate.  

While these characteristics are pervasive and resistant to change, while they were often chosen for good reason, they are not fixed or required and can be changed.  Understanding them and how they  might be changed is key to making the Internet as resistant to abuse and misuse as it is to component failure or destruction. 

It suggests that the network must become both less open, not to say, closed, and more structured. The management controls must be protected and taken out of band.  The policy must become much more restrictive.  We must identify our users and customers and hold them accountable for their traffic.

To bring the Internet to infrastructure standards, we must overcome not only inertia but also culture.  Each of us must exercise our influence on our  employers, clients, and vendors to move the Internet to the same standards that we expect of skyscrapers, bridges, tunnels, and dams.  Since there is no one else to do it, we are called professionals and are paid the big bucks. 

All "Things" are not the Same

My mentor, Robert H. Courtney, Jr.  was one of the great original thinkers in security.  He taught me a number of useful concepts some of which I have codified and call "Courtney's Laws."  At key inflection points in information technology I find it useful to take them out and consider the problems of the day in their light.  The emergence of what has been called the Internet of Things (IoT) is such an occasion. 

Courtney's First Law cautioned us that "Nothing useful can be said about the security of a mechanism except in the context of a specific application and environment."  This law can be usefully applied to the difficult, not to say intractable, problem of the Internet of things (IoT).  All "things" are not the same and, therefore do not have the same security requirements or solutions.

What Courtney does not address is what we mean by "security."  The security that most seem to think about in this context is resistance to interference with the intended function of the "thing" or appliance.  The examples de jour include interference with the operation of an automobile or with a medical device.   However, a greater risk is the that general purpose computer function in the device will be subverted and used for denial of service attacks or brute force attacks against passwords or cryptographic keys.

Key to Courtney's advice are "application" and "environment."  Consider application first.  The security we expect varies greatly with the intended use of the appliance.  We expect different security properties, features, and functions from a car, a pacemaker, a refrigerator, a CCTV camera, a baby monitor, or a "smart"  TV.  This is critical.  Any attempt to treat all these things  the same is doomed to failure.  This is reflected in the tens of different safety standards that the Underwriters Laboratories has for electrical appliances.  Their list includes categories that had not even been invented when the Laboratories were founded at the turn of the last century.

Similarly our requirements vary with the environment in which the device is to be used.  We have different requirements for devices intended to be used in the home, car, airplane, hospital, office, plant, or infrastructure.  Projecting the requirements of any one of these on any other can only result in ineffectiveness and unnecessary cost.  For example, one does not require the same precision, reliability, or resistance to outside interference in a GPS intended for use in an automobile as for one intended for use in an airliner or a cruise ship.  One does not require the same security in a device intended for connection only to private networks as for those intended for direct connection to the public networks.

When I was at IBM, Courtney's First Law became the basis for the security standard for our products.  Product managers were told that the security properties, features, and functions of their product should meet the requirements for the intended application and environment.  The more things one wanted one's product to be used for and the more, or more hostile, the environments that one wanted it to be used in, the more robust the security had to be.  For example, the requirements for a large multi-user system were higher than those for a single user system.  The manager  could assert any claims  or disclaimers that she liked; what she could not do was remain silent.  Just requiring the manager to describe these things made a huge difference.   This was reinforced by requiring her to address this standard in all product plans, reviews, announcements, and marketing materials.  While this standard might not have accomplished magic, it certainly advanced the objective.

Achieving the necessary security for the Internet of things will require a lot of thought, action and, in some cases, invention.  Applying Courtney's First Law is a place to start.  A way to start might be to expect all vendors to speak to the intended application and environment of his product.  For example, is the device intended "only for home use on a home network; not intended for direct connection to the Internet."  While the baby monitor or doorbell must be able to access the Internet, attackers on the Internet should not be able access the baby monitor.

"Women and Children First"

As we approach autonomous cars, some have posed the question "In accident avoidance should the car prefer its passenger or the pedestrian?"  It is posed as a difficult ethical dilemma.  I even heard an engineer suggest that not only does he not want to make the decision but that he would like Congress to make it as a matter of law.  

This is really just another instance of an ethical dilemma that humanity has faced forever.  It has many illustrations but one that has been used in teaching ethics is called the "life boat" problem.  If there is not enough room in the lifeboat for everyone, who gets in?  If there is not enough food and water, who gets preference?

The simple answer is "women and children first."  Human drivers will steer away from a woman with a baby carriage even if they do not have time to evaluate the alternative.  It is built into the culture, all but automatic, but the reason is that it is pro life.  Children are the future of the species.  Women can nurture and reproduce.  Men can sow but they cannot reap.  While the male role takes minutes, the female role takes months.  Life needs more females than males.

The reason that we do not apply this pro life rationale to the autonomous automobile is that we assume that the consideration is beyond its capability.  However, most of what one expects of an autonomous car today was beyond its capability a decade ago.  For the moment, most may not be able to consider all the factors we might like.  For example, they may not recognize age and gender, much less consider them.  Ten years from now, they certainly will.  

In this context it is useful to consider how such systems make a decision.  They identify a number of scenarios, depending upon the time available, assign an outcome and a confidence level to each, and choose statistically.  The kind of ties implied by the strawman dilemma will be vanishingly rare, even more so as the computers become faster and the number of things the can consider increases.  

Compare the autonomous car to the human driver.  In the two tenths of a second that it takes a young adult to recognize and react, the autonomous car will evaluate dozens of possibilities with as many considerations.  Like the human driver, the autonomous car may confront instances when there are simply no good options but the whole reason for using them is that they are less likely than the human driver to overlook the least damaging.  

Security of the Internet of Things (IoT) Part II

This is the second in a planned series of three posts on the subject of the "Internet of things" (IoT).  This one will treat the security of the "thing" itself.  It is about how to ensure that the appliance can be used safely, how to protect it from outside interference, and how to use it to protect its data.


The problem of securing appliances is much more tractable than that of securing more open and general purpose systems like operating systems and browsers.  It should not be difficult to develop purpose-built appliances that do only what they are intended to do.  This idea is supported by the experience that we have with mobile computer (specifically iOS) "apps;" Most are orderly and well-behaved.  While there are millions that are connected to the Internet, only a handful have been turned against it.  While the attack surface of an iPhone might be quite large, that of an individual app is very small.  The value of a successful attack against an app is usually limited to that app.

While there have been reports of misuse of apps, they have been far more limited than our experience with PCs might have led us to expect.  While the number of mobile computers will soon exceed the number of more general purpose computers, the security problems have been much more limited. We have seen nothing approaching the kind of security problems that we have seen with Windows or Linux based personal computers.

The implication is that we can build safe things.  The fear is that we will not do so.  The fear is based in part upon the recent history with other kinds of computer systems.  It is amplified by reports of so-called "security researchers" who have found and reported on things that were not secure.  While we may have done okay with iOS, our experience with browsers has been frightening.  Even computers that are otherwise secure can be compromised by duping or baiting a user into simply pushing a button.

Let's look at the iOS experience to see what we might learn about how to build secure things.  First, things should run in a closed environment, either dedicated hardware, like a router, or in an environment isolated from other things like that provided by iOS.  Second, it should have a limited and easily understood application or use.

The app makes the device into an application only machine.  Unlike a personal computer, it does not present the function to make persistent changes to its own programming.  While it is a programmed device, it is not a programmable device.  The underlying computing functionality is hidden from the user.  The user should not be able to see or control the file system, write or execute an arbitrary program, or even make persistent changes to data by any means other than by operating the thing.

The program for the thing should be  written in an appropriate language and using an appropriate systems development kit (SDK).  One does not have to know the features of the iOS SDK to know that it makes it easier to do things right than otherwise.  If that were not so, we would not have well over a million apps with so few problems.

The thing should hide its computer from the network.  As with the user interface, the thing should hide its file and operating systems from the network interface.  Said another way, it should not answer on any standard "ports," but only those specific to the use or operation of the thing.

The thing's software should not present a multi-user interface.  As with the app, possession of the thing should be both necessary and sufficient for its use.  While many iOS apps do require "login" it is not for use of the app itself but to authenticate the user to a multi-user network application.

While the personal computer expects and supports late changes to its own programming, the app does not.  Late changes are made by replacing the app with a new version of itself rather than patching the existing one.  This is facilitated in part by the fact that the app is small and self-contained.  It is required because the limited function of the app does not contain the capability of making late and persistent changes to itself.

We should not conclude that building secure or "securable" things is easy but it is fair to conclude that it is possible and definitely easier than general purpose computers. However, while most "things" will work pretty much as intended, given the number of things and the number of sources, there will be broken things sold. Some of these will be in sensitive applications like healthcare, transportation, and banking.  These failures will not be seen as exceptions but as typical of the Internet of Things and maycause more fear, uncertainty, and doubt than diligence and care.