Monday, November 23, 2015

  • Recently the media has reported that, as the result of a gross failure of security at the U.S.  Office of Personnel Management, the service and security records of twenty-seven million Americans have been compromised, likely by a foreign power. The compromise of these records has broken faith with these brave Americans and put them at risk of every thing from credit fraud to coercion, blackmail, and extortion, More recently the reports have noted that these records include the fingerprints of the subjects of the compromised records and have speculated wildly about the risk that result from that.  

  • The real risk here is not that these fingerprint records can be used for impersonation but that they might be used for identification (for example of covert operatives) (from latent prints). Impersonating someone from a picture of their fingerprints is similar to impersonating them from a photo,of their face. Possession of such an image is useful but far from sufficient. 


      • The real risk here is not that these fingerprint records can be used for impersonation but that they might be used for identification (for example of covert operatives) (from latent prints). Impersonating someone from a picture of their fingerprints is similar to impersonating them from a photo,of their face. Possession of such an image is useful but far from sufficient.


          • We use four kinds of evidence to authenticate a claim of identity, something only one person knows, e.g., pass-phrase, is, e.g., visage, fingerprint, has i.e., custody, e.g., unique keys, tokens, or can do, e.g. speech, signature dynamics. Since all of these have fundamental limitations, we use them in combination such that one compensates for the limitations of another
        • We use four kinof evidence to authenticate a claim of identity, something only one person knows, e.g., pass-phrase, is, e.g., visage, fingerprint, has i.e., custody, e.g., unique keys, tokens, or can do, e.g. speech, signature dynamics. Since all of these have fundamental limitations, we use them in combination such that one compensates for the limitations of another.While it is somewhat counter-intuitive, biometrics are no less limited than the the other three Their fundamental limitation is that they can be copied and fraudulently re-used. We use them more for convenience than security. We use them in combination with other mechanisms in systems of strong authentication.
          Such demonstrations, in and of themselves, do not represent a risk. I am confident that no one is using such an attack against my mobile because I have custody of it. Touch ID, much like the PIN for which it may substitute, is used to resist the fraudulent use of the lost or stolen mobile only for,the short time until its loss is noticed and the phone disabled.
          Note that an attacker only gets five chances to spoof Touch ID and ten to,guess the PIN. Then my mobile erases,itself
          .

        • For example, while the ability to spoof Touch ID might be useful in gaining access to,the content and capabilities of my mobile, it is far from sufficient. First one must have the phone. While there have been demonstrations of retrieving latent prints using gelatin and using them to fool biometric system, that is an easier problem than trying to go from a paper record.

        On Resisting Payment Fraud

        A recent report suggested that credit card numbers captured by malware installed on point of sale devices at hospitality sites, including twenty at  Starwood Property Group hotels, are being used in fraudulent transactions.  The Verizon Data Breach Incident Report (DBIR) confirms that point of sale devices at hospitality sites frequently leak credit card numbers.

        But there is no shortage of compromised credit card numbers; their street price is approaching a dime a dozen. It is too late to address fraud by  keeping credit card numbers secret. We need a new strategy, similar to those being promoted by American Express and described by Ken Chenault at President Obama's Conference at Stanford University.

        Chenault told the conference that by confirming every card transaction to the customer's mobile, they are able to detect fraudulent transactions within sixty seconds. This is just one example of how we can use the mobile to resist fraud.

        American Express also confirms transactions by e-mall. In order not to overwhelm the mailbox, the customer can set thresholds. One switch is the "card not present" switch. If as expected mobile transactions and EMV cards drive fraud to CNP then the ability to detect fraud early, for example, before goods are shipped, will be key to,resisting fraud.

        We need a strategy that relies not on secrecy but on feedback. The default should be that the subject of a record be notified of any change or query to that record, that the owner of every account be notified of every transaction. The digital,networks not only make this possible but cheap enough to be efficient.

        Needless to say, the lobby of the credit reporting industry that is empowered by law to charge the consumer for telling him about the content of and activity to,his record will resist this strategy. Legislation will be required to change this but it is essential to to resisting application fraud.

        On the other hand, American Express and its competitors are embracing it. Even bankers are embracing it. My little three branch community bank uses SMS to notify me intra-day of all large (as defined by me) transactions to my account.

        Eventually competition and efficiency will force most enterprises to adopt these tactics. You can make it strategic rather than merely tactical

        Monday, November 16, 2015

        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.

        Security of the Internet of Things (Part III)

        As we said in Part I, "While the conversion of 'things' to malicious purposes makes for dramatic Hollywood scenarios,  most devices will not be vulnerable to either takeover or malicious use, much less both.  However, all those that are vulnerable to takeover can be exploited for their computer function or capacity. This function and capacity can be compromised and turned against the host network for a variety of attacks ranging from simple,spoofing through denial of service to brute attacks against passwords and cryptographic keys.  Moreover, the sheer number of things will dwarf the number of general.purpose computers. It is this that we will argue is the most serious risk."

        This risk results in part from the generality and flexibility of the "chips" used to implement the "things," the appliances.  Much of the design and implementation of the appliance will involve stripping away and hiding this gratuitous capability.

        It will result in part from the method chosen for installation, setup, initialization, administration, or to deal with implementation induced flaws or vulnerabilities. We have already seen a number of cases where the appliance itself, e.g., medication dispenser, worked as intended but the administration capability, dosage setting, was vulnerable to takeover.  The appliance function was purpose-built but the administration was done via capabilities, e.g., Telnet, ftp, optionally included in the underlying operating system.  This kind of gratuitous functionality, often included without proper consideration of its security or its impact on the security of its environment, the Internet, will dramatically weaken the Internet.

        This functionality will be used to mount denial of service attacks, spam, and brute force attacks against passwords and cryptographic keys. This is not speculation on my part; this vulnerability has been demonstrated and the attacks reported. This functionality will be included, in part, because developers and vendors are reluctant to give up control, realize that problems will arise in the future because consumers may look to them for remedies, and because it is cheap to do.  If the problem is in the software, we may just fix the software just like we have been doing in information technology for two generations.

        This is very different from the way that we have dealt with problems in traditional purpose built hardware-only appliances.  By default we have dealt with safety flaws in traditional appliances and other products with product "recalls,"sometimes by repair but even more often with replacement.  Often we have done this even where computer chips have been used.  We have simply replaced the chip.  We have not attempted to patch the software, either locally or remotely.  However, as "chips" have become cheaper and more powerful, we have succumbed to the temptation to treat them like personal computers.

        One must act locally but should think globally.  If one wishes to use the Internet, one should do so responsibly.  That includes not attaching weak, vulnerable, or even gratuitous capability to the Internet.  Problems will arise and we must deal with them but we should do so in the most conservative possible manner.  Consider the following strategies for fixing problems:

        • Replace hardware and software.
        • Replace all software and data (like iOS apps) from a secure server, recognized (VPN, public key) by the device.
        • Replace software only, retain data.
        • Patch software using a secure server.
        • Patch using remote control of function on the device.
        • Make patch available to owner to apply at his discretion.

        These are equal in terms of their ability to fix the problem. They vary in their economics.  However, they vary considerably in their security.  Even if the problem is limited to the software, in a world of cheap chips, replacing both as a package may be the most efficient way to repair it.  Moreover, as a strategy it can reduce the attack surface of the device to the minimum.


        Tuesday, October 13, 2015

        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.

        Friday, September 4, 2015

        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.

        Monday, August 3, 2015

        Security of the Internet of Things (Part I)

        This is the first of a contemplated three posts on the subject of the Internet of Things (IoT).  In this post we identify the space and the potential,security issues.  In subsequent parts we will make recommendations to address the issues.  Comment, feedback, explication, and even argument are invited.


        As the cost of information technology falls and the wireless Internet becomes more and more ubiquitous, we are witnessing the emergence of smart appliances, "things," that are connected to the public networks.  An early example was the smart printer; we have been living with these for almost a decade.  Others include baby monitors, front door monitors, lighting controls, and home security devices.

        Perhaps an even earlier example was the ATM  While early ATMs used proprietary operating systems, protocols, and network connections, at some point they began to use Windows, Internet protocol, and Ethernet connections because this was the cheapest way to build them. We now have wireless ATMs and wireless point of sale devices.  Other examples include the Nest thermostat, the smart TV, the Chromecast, and smart watches.

        One particularly interestiing example is the Samsung Smart Refrigerator that "will allow you to browse the web, access apps and connect to other Samsung smart devices – opening up a world of interactive communication and entertainment."  Note that none of these functions has anything to do with keeping food fresh.  They certainly distinguish this refrigerator from others but it appears that they are included mostly because this is a cheap way to do so.

        Perhaps the most ubiquitous thing to date is the mobile computer, popularly called the "smartphone." It is interesting in part because of its ubiquity, in part because of the number of different things that it implements.  Each of the hundreds of thousands of its application is a different thing, everything from toys to banking machines.  Because of its falling cost and increasing power, we use it for things that we could hardly contemplate as recently as a decade ago.

        These are real world examples but the technology is now so cheap that we must expect to see an accelerating flood of smart connected "things."  There will be smart things that are not connected, but connection will be so cheap and add so much value that most will be part of the Internet of things (IoT). While we are going to speak of "things" in the abstract, keep the examples in mind because they have things to teach us about the impact that they will have on our lives and our security.

        There are at least three security issues associated with the IoT.  The first is that malicious actors will take control the of the thing and misuse or abuse its application to do harm to the owner or user of the device.  The favorite example is that of an implanted medical device instructed to kill its user.  This example is supported by so-called "research" that concludes that many early connected medical devices have implementation-induced vulnerabilities that might be exploited for malicious purposes.  More about medical devices in a moment.

        The second security issue is that the underlying computer functionality or capacity of the device might be taken over to participate in attacks against other entities in the Internet.  The things might be co-opted into "botnets" and be used in denial of service attacks or brute force attacks against passwords or encryption keys.

        The final security issue is that instances of problems, no matter how sparse will be used to sow fear, uncertainty and doubt about things in general.  Take the example of smart printers, that is most of the printers that have been sold in the last decade.  Millions of them have been sold by a half a dozen or so manufacturers for prices ranging from as little as a hundred dollars to thousands.  They are used to scan, print, and store our most sensitive data along with the potential to leak it.  Collectively they present a huge attack surface.  However, the number of reported attacks is exceeded by the number of  attack scenarios and "proof of concepts" dreamed up by "researchers" and reported by the media.  At least so far, "things" and their applications dwarf the problems associated with their use.


        While the conversion of "things" to malicious purposes makes for dramatic Hollywood scenarios,  most devices will not be vulnerable to either takeover or malicious use, much less both.  However, all those that are vulnerable to takeover can be exploited for their computer function or capacity. This function and capacity can be compromised and turned against the host network for a variety of attacks ranging from simple,spoofing through denial of service to brute attacks against passwords and cryptographic keys.  It is this that we will argue is the most serious risk.