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.  

 

Encryption and National Security versus Liberty

In the 1990s, in what might be called the first battle of the Crypto War, the government classified encryption as a munition and restricted its export.  While opposing export in general, the government was licensing the export of implementations that were restricted to a forty bit key.  Of course, 56 bit was then the norm and, at the time, expensive for the NSA to crack.  

IBM had just purchased Lotus Notes and wanted to,export it.  In order to get a license, they negotiated an agreement under which they would encrypt 16 bits of the 56 bit message key under a public key provided by the government and attach it to the message or object.  This would mean that while the work factor anyone else would be 56 bits, for the government it would be only 40 bits.

Viewed today, 40 bit encryption is trivial; twenty years ago it was strong enough that, while the government could read any message that it wanted to, it could not read every message that it wanted to.  Said another way, it would be able to do intelligence, or even investigation, but it still would not be able to engage in mass surveillance.  

Moreover, we believed that the NSA only collected,traffic that crossed our borders, that it could not be used against citizens.  We believed that the government could keep,their private key secure. Of course, post "warrant-less surveillance," the routine breaches of government computers, including those of the NSA,and the exponential growth of computing power over a generation, this all seems very naive.  

However, I like,to think that it illustrates that it is possible to craft solutions that grant authorized access to the government, with a work factor measured in weeks to months per message, file, device or key, while presenting all,others with a cost of attack measured in decades or even centuries.   

It also illustrates the fundamental, application, and implementation-induced limitations of any such scheme, limitations that would have to be compensated for.  No such scheme will be fool-proof, nor need it be.  Like our other institutions and tools, it need only work well enough for each intended application and environment. 

US v. Apple

SUNDAY: Comey tries to downplay the dispute, arguing in his new statement that no precedent would be set if Apple would just go along.

"I hope folks will take a deep breath and stop saying the world is ending, but instead use that breath to talk to each other," he said.

"Although this case is about the innocents attacked in San Bernardino, it does highlight that we have awesome new technology that creates a serious tension between two values we all treasure — privacy and safety," he said, adding:

"We simply want the chance, with a search warrant, to try to guess the terrorist's passcode without the phone essentially self-destructing and without it taking a decade to guess correctly."

This sounds like capitulation to me. If this is now about the "victims," then the government made a serious mis-step in attacking Apple in the first place. However, the government's current position does not support a charge of "government over reach."

The issue of how far the government may go in coercing the unwilling and the un-involved to assist them in recovering evidence that they are otherwise entitled to is important and needs to be litigated. We should be glad that Apple is prepared to fight it. Perhaps not since Runnymede has the King had a more formidable adversary. However, this is not the right case to fight it on.

There is ample precedent for un-involved citizens to voluntarily assist the government. It would not be precedent setting for Apple to voluntarily assist with this one mobile in this one case. Apple should "declare victory and go home." It should do here what it can do and fight the government over reach issue when the government is more certainly guilty of it.

Lessons From the J P Morgan Chase Breach

A recent report suggested that the J P Morgan Chase breach teaches us the importance of encryption.

We know that information was recovered in the clear. What we do not know is whether encryption would have been effective in protecting it or even whether it was used but was not effective.

What we do know is that the credentials of authorized users were compromised and used to access the data. Authorization to the data includes the ability to see it in clear text even though it might be stored in encrypted form.

Encryption is not magic. It is a tool. Government propaganda to the contrary not withstanding, it is no more perfect security for the bank, than it is for the criminal.

Encryption is used to restrict access to data at rest, for example on file servers, from those who do not have credentials to access the server. It is used to protect data in transit, for example user credentials, as they cross networks. Properly used, it is very powerful. It is not effective against those with the credentials, the authorization, whether legitimate or otherwise, to access the data.

Are there many banks that are storing information in the clear that should be encrypted? Yes. Was JPMorganChase one of these? We do not know; that information has not been disclosed. Should all banks take to heart the lesson that they should be using encryption to protect data at rest? Yes. Does that lesson flow from the "breach" of JPMorganChase? No, but it does flow from the "attacks."

What we do know is that of the thousands of applications and servers at JPMorganChase, fewer than a hundred were compromised and none of those were using strong authentication. So, the first lesson that I want banks to take from the JPMorganChase breach is to use strong authentication, particularly for privileged users of applications, databases, and servers. Without this, encryption is not likely to be effective.

Strong authentication is policy at JPMorganChase and appears to have been effective where used.

A Leapfrog Enterprise Security Strategy

Recently I was quoted in an article on newly reported, but somewhat old, breaches.  In the report I was quoted as suggesting that these breaches suggest that security has fallen behind and that, just in order to catch up, we need a "leapfrog" strategy.  This post will suggest what such a strategy might contain.

Mine would start with strong authentication close to the users, i.e., at the end point. Strong authentication will start with privileged users and move to all employees. We have known about the limitations of passwords and what to do about them for thirty years. It is way past time to get on with it. Going forward, the end point of choice will be the mobile computer, colloquially referred to as a "smartphone."  This device already contains powerful sensors that can be used for authentication of claims to identity.  Apple Touch ID and Samsung Face Unlock are simply early examples of what can be done.  These are quick and easy to use and, in combination with possession of the device, constitute strong authentication.  

My strategy would include reducing the number of privileged users, the reduction of their privileges, and accountability for the use and exercise of privileges. It would include involving two or more people in the exercise of sensitive but rarely used privileges. We have too many privileged users and too little visibility into how those privileges are used.

It would include the automatic notification of the subjects of records and the owners and managers of accounts of all use, changes to, or transactions against those records or accounts. If we are to detect breaches on a timely basis, we must increase and improve transparency and accountability.

It will include isolating e-mail and browsing from mission critical and other sensitive systems and data. The intelligence is clear that many, not to say most, compromises begin by duping the users of these two applications.

It will include end-to-end end, end-point to application, not perimeter, not operating system, encryption. We cannot continue to operate large enterprise networks as flat spaces, as spaces in which any system may address any other system in the network.

It will include restrictive, i.e., "white list only," granular access control close to the applications and data. It will probably include access control at every layer, e.g. between the application and the database, between the database and the file system.

These measures are neither expensive nor disruptive. Google has demonstrated that even strong authentication can be flexible and convenient. They can be implemented in parallel. There are vendors recommending them and with products and services to implement them.

This is an "off-the-top of my head" list; I am sure I have omitted something important. However, it is informed by fifty years of thinking about this problem. I am sure that many of my colleagues have measures not on my list but which they would include in a leapfrog strategy.