The Desktop, our Achilles Heel

During the last three or four years the number and rate of enterpirse wide breaches have increased dramatically.  Successful attacks have relied upon duping users into clicking on bait malicious objects in e-mail messages and web pages.  The malicious objects capture user credentials and then use them to attack peer systems in the enterprise network, spreading the compromise laterally.  These attacks exploit user gullibility, re-usable credentials, the default desktop access control rule of ”read/write,”  and flat enterprise networks.  Therefore, many security practitioners recommend user training, multi-factor user authentication, and structured networks.  Resistance to all three of these measures is high and their effectiveness limited.  Moreover, they do not address the vulnerability of the desktops to have their procedures modified by their data.   We are left with a high level of risk.

E-mail and browsing are the Achilles Heel of the desktop and the desktop is the Achilles Heel of the enterprise.  One of these two applications are involved in a large percentage of all breaches.  Note that while Achilles was vulnerable on only one heel, small attack surface, the enterprise may be vulnerable on many desktops.                                                            

One obvious defense would be to isolate these two applications from the system on which they run and those systems from the other applications and systems of the enterprise.  Neither of those applications should have the capability to make persistent changes to the procedures of the systems on which they run.  

In a world of cheap hardware, one way to do this would be to run these two applications on sacrifical hardware dedicated to these two applications.  In a world of reliable process-to-process isolation, another would be to use that isolation to protect the system on which the applications run from any changes originating in those porous applications.  The first solution is resisted because IT culture sees hardware as expensive, this in spite of the fact that its cost halves every two years.  The second is resisted because user culture prefers convenience, generality, flexiblity, and ”dancing pigs” to security.  As a consequence, most desktops are configured to offer read-write access to most objects and  few provide reliable protective isolation.  

It does not have to be this way.  Ten years ago Steve Jobs and Apple introduced us to iOS, with very limited capabilities but with very strong process-to-process isolation and strong protection from anything done at the user interface.  As it has matured its capabilities have increased.  Controlled application-to-application communication has been introduced while maintaining strong isolation and protection.  Some generality and flexibility have been sacrificed to usability and security but less than the defenders of the status quo predicted.  Nonetheless, resistance to iOS was so strong that it provoked Android, a more traditional system.  

However, iOS has been adopted by a large population of users that enjoy ”most, but not all, of the benefits offered by the traditional general purpose system.” (Fred Cohen)  At the user application interface, it appears as a single user single application-only machine.  While it can maintain application state, iOS is resistant to any persistent change to itself from the application or the user.  

Said another way, iOS protects itself from its data, its user, and its user’s data.  While the application may be vulnerable to a ”bait” attack, the system is not.  Therefore, it is a preferred environment in which to run vulnerable applications like e-mail and browsing, and sensitive applications like banking and healthcare.   

Personal computers can be configured with hypervisors to provide strong process to process isolation.  They can be configured with the ”least privilege” access control rule to resist contamination of procedures by their data.  Said another way, they can be configured such that simply clicking on a bait object is not sufficient to compromise the system.  Indeed they can even be configured in such a way that, as in iOS, nothing done with the keyboard and mouse is sufficient to compromise the system. 

This brings us to the ”flat enterprise network.”  Traditionally, enterprise networks have been configured for any-to-any connectivity; any node in the network could send a message to any other node.  The latency and bandwidth between any two nodes was roughly the same as the average across all nodes.  Often, and at least by default, they have been operated at a single level of trust.  That is to say, all nodes in the network were assumed to be benign, orderly, and well behaved. Nodes were not expected to have to protect themselves from traffic that originated on the network or question the origin address.  It is this configuration that leaves the enterprise vulnerable to lateral compromise with little more than one compromised system or user credentials.  

The alternative and safer network is referred to as ”zero trust.”  All nodes are assumed to be mutually hostile.  Traffic may flow only between specified pairs, e.g., user to application or client to server. Origin addresses are not trusted but must be authenticated.  Some cost in latency or bandwidth is tolerated for authorization of the connection and mutual authentication of the nodes. This kind of network is resistant to lateral compromise; a compromised node can attack only the nodes to which it is allowed to send traffic.  Even those nodes will treat it with suspicion and may require evidence as to its identity.  

There are a number of ways to restrict the flow of traffic to accord to this policy.  The first and most obvious is to provide only links between authhorized nodes; easy for two nodes, illustrative, but it does not scale even to a small enterprise.   However, the others simulate this illustration, usually through the use of encryption, e.g.,virtual local area networks, VLANs. virtual private networks, VPNs, and software defined networks, SDNs.  Note that in SDNs, users are included as ”nodes.”  Note also that to be most resistant to attack, connections should be at the application layer.  Applications are the nodes of interest and, contrasted to, for example, operating systems, have the smallest attack surface, i.e., the user interface.  

So, to summarize, the traditional use and configuration of desktops leave the enterprise vulnerable.  While awareness and strong authentication, remain essential practices they are limited in their effectiveness.  E-mail and browsing should be isolated from mission critical or otherwise sensitive applications.  The environment should be resistant to persistent changes to programs or procedures from application data; least privilege access control.  Network traffic should be encrypted end-to-end at the application layer; prefer software defined networks to VPNs to VLANs.  

 

Blockchain Revealed

Many of you must be frustrated following so many links about blockchain without finding out what it is, how it works, or what it is good for.  While it was invented a quarter of a century ago by Haber and Stornetta, it has recently been popularized by its most famous application, Bitcoin.

One might well ask why anyone might choose to write on something where so much has already been written.  The answer is that finding the answer to my three questions has proved to be difficult.  In this blog, I will attempt to answer those three questions but to the extent that I fail, I hope that readers will follow up with questions.

A blockchain is a collection of digital objects related in such a way that changing any one of the objects will be obvious and changing all of them in a non-obvious way is computationally infeasible.   Thus, it is a data integrity mechanism.  It is an example of a zero knowledge proof, i.e., making a demonstration without prior knowledge or pre-arrangement.

The objects are “chained” in such a way that object N includes a hash of object N-1 and its hash is included in object N+1.   The hash of the last, or latest, object in the chain depends upon, is an arithmetic function of, the content of every object in the chain.  Therefore, one can demonstrate that the chain is complete and that no objects have been altered.   We also know that object N-1 existed before N and N before N+1.

This works for any set of similar digital data objects.  The objects determine the application.  For a simple example, the objects might be the entries in a journal, or entries in a database.  More complex examples might include a digital record for all the transactions of a digital currency, bills of lading, warehouse receipts, or public records.

Blockchains enable anyone to demonstrate, by recomputing the hash of the last object, the integrity of the data. Therefore many applications may not require or rely upon a trusted party or access control of the data.  On the other hand, demonstrating the integrity of the chain is computationally intensive so blockchains work best for applications where the number and size of objects is low.  Said another way, blockchains may not scale well.

Note that trusted third parties, such as banks, often assume risk and collect fees for their role; disintermediating them can reduce cost.  For example, one might be able to transfer large sums internationally more cheaply using digital currency than by using orders on central or correspondent banks.

Internet Vulnerability

On March 24, 2017 Gregory Michaelidis wrote in Slate on "Why America’s Current Approach to Cybersecurity Is So Dangerous."

He cited an article by Bruce Schneier.

In response, I observed to a number of colleagues, proteges, and students that "One takeaway from this article and the Schneier article that it points to is that we need to reduce our attack surface.  Dramatically.  Perhaps ninety percent.  Think least privilege access at all layers to include application white-listing, safe dcfaults, end-to-end application layer encryption, and strong authentication."

One colleague responded "I think one reason the cyber attack surface is so large is that the global intel agencies hoard vulnerabilities and exploits..."  Since secret "vulnerabilities and exploits" account for so little of our attack surface, I fear that he missed my point.

While it is true that intelligence agencies enjoy the benefits of our vulnerable systems and are little motivated to reduce the attack surface, the "hoarded vulnerabilities and exploits" are not the attack surface and the intel agencies are not the cause.  

The cause is the IT culture. There is a broad market preference for open networks, systems, and applications. TCP/IP drove the more secure SNA/SDLC from the field. The market prefers Windows and Linux to OS X, Android to iOS, IBM 360 to System 38, MVS to FS, MS-DOS to OS/2, Z Systems to iSeries, Flash to HTML5, von Neumann architecture [Wintel systems] to almost anything else.  

One can get a degree in Computer Science, even in Cyber Security, without ever even hearing about a more secure alternative architecture to von Neumann's [e.g. IBM iSeries. Closed, finite state architecture (operations can take the system only from one valid state to another), limited set of strongly-typed (e.g., data can not be executed, programs cannot be modified) objects, single level store, symbolic only addressing, etc.)]

We prefer to try and stop leakage at the end user device or the perimeter rather than administer access control at the database or file system. We persist in using replayable passwords in preference to strong authentication, even though they are implicated in almost every breach. We terminate encryption on the OS, or even the perimeter, rather than the application. We deploy user programmable systems where application only systems would do.  We enable escape mechanisms and run scripts and macros by default.

We have too many overly privileged users with almost no multi-party controls. We discourage shared UIDs and passwords for end users but default to them for the most privileged users, where we most need accountability. We store our most sensitive information in the clear, as file system objects, on the desktop, rather than encryptied, in document management systems, on servers. We keep our most sensitive data and mission critical apps on the same systems where we run our most vulnerable applications, browsing and e-mail. We talk about defense in depth but operate our enterprise networks flat, any to any connectivity and trust, not structured, not architected. It takes us weeks to months just to detect breaches and more time to fix them.  

I can go on and I am sure you can add examples of your own. Not only is the intelligence community not responsible for this practice, they are guilty of it themselves. It was this practice, not secret vulnerabilities, that was exploited by Snowden. It is this culture, not "hoarded vulnerabilities and exploits," that is implicated in the breaches of the past few years. It defies reason that one person acting alone could collect the data that Snowden did without being detected.  

Nation states do what they do; their targets of choice will yield to their overwhelming force. However, we need not make it so easy. We might not be able to resist dragons but we are yielding to bears and brigands. I admit that the culture is defensive and resistant to change but it will not be changed by blaming the other guy. "We have seen the enemy and he is us."

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.