- 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.
- 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.
Monday, November 23, 2015
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
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.
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.
Labels:
banking,
Cryptography,
encryption,
protection,
security,
strong authentication
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.
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.
Subscribe to:
Posts (Atom)