This chapter is from the book
This chapter is from the book
This chapter is from the book
5.6 Analysis
It is very clear that the trend towards decentralization is going to continue. Ever-cheaper processing power makes it possible to put CPUs more or less everywhere; increasingly, these CPUs have communications capabilities. Today, interacting with some of these varied computers is optional; more and more, it will become a necessity. A generation ago, an airplane flight required a paper ticket that you exchanged for a cardstock boarding pass at the airport. Today, tickets are electronic and you’re encouraged to print your own boarding pass, but if you want you can often display it as a 2-D barcode on your smart phone. In not very many years, smart phones will become the normal way to fly, with temperamental barcode scanners replaced by network communication with the passenger’s phone. Will corporate security policies permit installation of the necessary app on employees’ iToys? They’ll have to.
There are also considerations of physical laws. If you’re in Tokyo and trying to download some local content, routing your request via the corporate firewall in Rio de Janeiro will slow you down; neither DARPA nor the ITU can increase the speed of light, and bandwidth is intimately linked to latency. It’s not just that security policies that ignore reality will be ignored (though that will happen, too); rather, it’s that they’ll start to interfere very seriously with productivity. People derive inner satisfaction (and better merit reviews) if they’re more productive; they derive neither from obeying security policies they generally don’t understand. Only if there is a problem will there be consequences, but 99% of the time ignoring policy results in no harm whatsoever. It’s the last 1% that gets them—and their employers—in very big trouble.
Things might change. We’re currently at a point where there are three plausible, currently visible directions in which technology can move. First, it might move to a purely decentralized model, where there is no perimeter and any device can be used for anything. The rise of the “gig economy” [Editorial Board, New York Times 2015] will push in that direction. Second, a cloud plus random device solution may dominate. In that case, although today’s perimeter-and-firewall solution will vanish, the cloud-based servers can become a locus for logging, intrusion and extrusion detection, and other forms of protection against large-scale attacks. Finally, things can stay about the way they are today. I say “about” because there are too many advantages to the other two paths for the status quo to hold completely, but the extent to and rate at which it will erode remain unclear.
There’s a potential variant on the “lots of devices” model that might arise: the local ad hoc network scenario. In it, a user’s device (somehow) associates itself with other devices in the neighborhood. The obvious and probably non-threatening examples are things like hotel room displays, keyboards, and the like; perhaps more interestingly, one can imagine a laptop taking over some sort of mobile Wi-Fi hotspot or connecting to a local disk or neighboring laptop to share content. In scenarios like this one, the perimeter is fuzzier still.
The conclusion is that we have to figure out how to push our security policies towards the edges. This is not the simplistic “I don’t believe in firewalls” chant of 20 years ago; the need for good security policies—generally, organizational security policies—and mechanisms is stronger than ever; we just have to change how and where we enforce them. This may be the real conundrum of the “bring your own device” movement; it’s not that consumer devices are necessarily less secure than corporate-issued ones as it is the difficulty of an IT department installing its own policies on an employee’s widget. Quite likely, they have neither the authorization nor the knowledge to do so, especially for newer or rarer widgets.
Better virtualization and policy languages will help. If the work environment can be properly isolated from the play environment, and if a system-independent policy language can be devised (and of course implemented by consumer gadgetry purveyors), this issue can be avoided. It’s not an easy task, since it will be necessary to implement this functionality in such a way that malware can’t disable it.
Intrusion detection and its counterpart intrusion prevention are widely seen as the most promising avenues to pursue, given that purely defensive measures have not succeeded despite more than forty years of effort [Wulf and A. K. Jones 2009]. The challenge, though, is considerable; not only must an IDS cope with a change in people’s legitimate activities, it must cope with changing software and changing technology. A new release of a web browser might sandbox each tab or window, which would produce different patterns of system calls than the older versions did; similarly, the rise of mobile devices to, say, read email via a cellular network will reduce the contribution of LAN-based mailers to the total traffic mix and thus change its overall characteristics. These sorts of changes are legitimate and probably inevitable, but the same package that has to adapt to these changes must also detect the very subtle changes of a new “low and slow” attack.
Extrusion detection is even more challenging than policy enforcement. Generally speaking, physical access wins; it is very hard to prevent the owner of a device from getting at any or all of its contents. One thing that will help is if vendors implement a distributed logging system. Even in, say, a peer-to-peer distributed corporate file system, a request for a file should generate a log message back to some central correlator. I would argue that for security purposes, logging is even more important than delivering the data; a user will retry the download but won’t be similarly motivated to resend missed log messages.
It is hard to predict what other trends will take root even in the next five years, let alone ten or twenty. The human and organizational need for collaborative work will not change, but the mechanisms will. A generation ago, people swapped floppy disks. (Two generations ago, it was decks of punch cards.) We moved from there to central repositories and/or emailing files back and forth. Today, collaboration is moving towards the cloud. How long will that continue? Will peer-to-peer mechanisms take over instead? If I’m on a train or plane, I’d rather not have to deal with an intermediary when I’m working with someone a few rows back; I’d rather use a mobile network. That part looks feasible—but how will it be done securely, and how will transactions be logged?
What is really needed is a way for packets or messages of security interest to be flagged reliably, thus simplifying policy enforcement [Bellovin 2003]. Until that happens, all of these mechanisms will be imperfect.