It is a persistent plaint of the security managers that they do not have sufficient budget to do what they think should be done. One wonders where they think budget comes from. There is no budget fairy that comes down and confers budget on good little boys and girls. Those managers who have budget all got it the same way; they asked for it.
Security managers are peculiarly loath to ask for budget for fear they will be told no. (A "no" in the record might look bad but it is an implicit acceptance of any risk that the proposal was intended to reduce. It should be in the record.) Those who ask for budget get told no a lot. Those who have budget did not take no for an answer. They re-did their proposal or their justification and asked again. And again. As many times as necessary to get to yes.
Note that almost anyone in the hierarchy can say no. Those who have budget, find the executive or manager who can also say yes. They never accept no for an answer until they are sure that they have proposed to someone who can say yes if she wants to. Note that while we may sometimes get budget from senior staff, it is usually the line of business executives who control most of the resources and incur losses. (Senior line of business executives often have "budget" or "plans and controls" staff, who manage budget, understand the process, and know how much discretion the executive has. These staff can be very helpful.)
Those who have budget are the same managers who are being promoted. General management likes few things better than managers who will tell them how to spend money profitably.
Security initiatives are usually justified either by a reduction, at least over time, in the cost of security or the cost of losses. These reductions have the advantage that they fall through to the bottom line as profit. It is useful to budget for "losses;" while they occur irregularly, they do occur. At least at the level of the enterprise or business unit, they can be estimated; all budgets are estimates but get more accurate with experience. Increases in the budget for initiatives can be justified in part by a reduction in the budget for losses.
Managers often see budget as a restriction on their ability to spend. Rather they should see it as permission.
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Friday, August 23, 2019
Limitations of Biometrics
It is Blackhat/Defcon time so it should not surprise anyone that the media is full of hacks. While the hackers pretend to demonstrate that the security mechanism is useless, most of the attacks are so expensive as to be impractical. What they really demonstrate is the limitations of the mechanism. Regular readers of this blog know that all security mechanisms have limitations; understanding those limitations are part of our stock in trade and I write about them often.
A recent demonstration spoofed Apple's FaceID in only "120 seconds," as though that were the only cost of attack. They omitted the special knowledge and access. A recent article in BankInfoSecurityNews raised alarms over the discovery of a database of fingerprint images for sale.
First, keep in mind that biometrics are really about convenience, not security. That is why they are best used as one factor in multi-factor systems.
Second, they do not rely upon the secrecy of the reference but upon their resistance, at least in context, to counterfeiting. Your visage is an authenticator for your drivers license. It is public information. While a photograph of you might be able to fool a computer, no other person would be likely to confuse the photo with you. There is too little information in the photo for it to be mistaken for you. The more information that the implementation uses, the lower the risk of false positives but the higher that of false negatives and the more power and time required for a check.
Finally, as this article suggests, just like passwords, biometrics are fundamentally vulnerable to spoofing and replay attacks; implementations must resist them. For example, Apple's FaceID uses tests of "liveness" to distinguish between a real person and a photo of the person or a replay of an earlier submission. Perhaps they are better used on mobiles, where possesion of the mobile is one factor and where the instant data is compared to the reference locally and does not go across a network where it could be captured for replay.
A recent demonstration spoofed Apple's FaceID in only "120 seconds," as though that were the only cost of attack. They omitted the special knowledge and access. A recent article in BankInfoSecurityNews raised alarms over the discovery of a database of fingerprint images for sale.
First, keep in mind that biometrics are really about convenience, not security. That is why they are best used as one factor in multi-factor systems.
Second, they do not rely upon the secrecy of the reference but upon their resistance, at least in context, to counterfeiting. Your visage is an authenticator for your drivers license. It is public information. While a photograph of you might be able to fool a computer, no other person would be likely to confuse the photo with you. There is too little information in the photo for it to be mistaken for you. The more information that the implementation uses, the lower the risk of false positives but the higher that of false negatives and the more power and time required for a check.
Finally, as this article suggests, just like passwords, biometrics are fundamentally vulnerable to spoofing and replay attacks; implementations must resist them. For example, Apple's FaceID uses tests of "liveness" to distinguish between a real person and a photo of the person or a replay of an earlier submission. Perhaps they are better used on mobiles, where possesion of the mobile is one factor and where the instant data is compared to the reference locally and does not go across a network where it could be captured for replay.
Wednesday, April 3, 2019
The Universal Serial Bus
This weekend there was a report out of Mar-a-Lago that a Chinese national had been apprehended while trying to enter this resort while carrying a laptop, 4 mobiles, and a USB thumb drive containing malicious software. While thumb drives are an efficient attack vector, where the attacker has physical access to a computer, we continue to hear reports of people surprised at how easy it is.
It is important to decode, to understand, “USB.” It stands for “Universal Serial Bus.” “Universal” refers to the standard; thousands of different devices employ the standard for interoperability. It is a standard interface but it is more than that. It attaches to the bus of the host device as peer with processors, memory, and other external input/output devices. The standard provides for the device to contain executable software to facilitate its attachment to and interaction with the host device. Think of it this way; any device attached to the bus is logically an internal, not external, device.
Like many standards, this one is popular, in large part, because it is convenient. It is an open interface for attaching cameras, scanners, printers, speakers, microphones, head sets, monitors, and storage devices. As is often, not to say usually, the case, convenience trumps security. Any control that limited the attachment, i.e., was more secure, would make it less convenient.
It is a privileged form of attachment; no authentication, no cryptography, no control. It is subject only to physical access control. Simply plugging a USB “thumb drive” into the bus of another device is sufficient to alter the fundamental operation of, not to say corrupt, that device in, perhaps, as little as tens of seconds. As we have seen, compromise of a single device on a network may reduce the cost of attack against all other devices on that network.
Since most, not to say all, personal computers expose their bus via the USB standard, it is essential to prevent unauthorized physical access to all such computers. (Indeed the interface is so ubiquitous and so vulnerable that some security professionals advocate filling the port with superglue. This measure should be considered for sensitive systems and applications and hostile environments.)
Wednesday, February 21, 2018
Law Enforcement vs. Security and Privacy
A recent report quoted the Director of the FBI as complaining that he had more than 7000 mobiles for which he has established probable cause to believe contain evidence of a crime, but that their security is so good that he cannot be sure. Well, perhaps his emphasis was different than mine but you get the gist.
Of course, a decade ago he did not have any. The modern mobile has given him a rich source of evidence that he has never had before. Instead of saying ”thank you,” he complains that the source is not even richer than it is. He neglects to say how many mobiles that he has opened while finding the few that he cannot. He neglects to address what percentage of those contained useful, much less admissable, evidence of crimes, a number that might give us some idea of any probative value of the contents of the 7000.
What he is really complaining about is that the default security of these devices raises his cost of investigation. He does not even speak to the resistance to crimes against the tens of millions of legitimate devices, users applications, data, and information that that security provides. Therefore, he cannot even get to the idea that in the absence of such security, there would be fewer devices, users, and applications, much less that his rich source of evidence might not even exist.
He argues that, in order to reduce his cost, the default security of the devices should be reduced. In spite of all the testimony against this proposition, and the absence of any in its favor, he argues that the purveyors of the mobiles can reduce his cost while maintaining the security against all others. Without specifying what would satisfy him, he argues that this is simply a small technical problem that the industry can solve any time it wants to.
While the Director talks in terrms of ”capability,” that he does not have, I talk in terms of ”cost.” I assert that if one has a cryptogram, the method, and the key, all of which are on the mobile device, then, at some price, one can recover the clear text. Depending upon the design of the device, the cost may be high but it is finite. The Bureau demonstrated this for us in the San Bernardino case. After asserting that Apple could, but that they could not, they turned to the Israelis, who for a million dollars, recovered the data. Incidentally it proved to be worth considerably less; it provided neither evidence nor intelligence. On the other hand, on a wholesate basis, the cost per device would be significantly less.
One problem is that, whatever the cost, the Bureau prefers to transfer it to the purveyor and the user than to just pay it. It hopes to do this by sowing enough fear, uncertainty, and doubt that a law and order Congress will pass coercive legislation forcing the uninvolved and unwilling to become arms of law enforcement. If the purveyor is coerced into reducing the security, i.e., a value, of his product, he will lose sales and profit. Remaining users will lose security and privacy, experience costly breaches, and incur costs for compensating controls.
The net is that, while the Director may not be able to read every mobile for which he has a warrant, he can read most of them. While he knows what he cannot read, he bears the burden of proof that reading it would yield evidence or intelligence; he has the data, he must share. We are not talking about cryptography in general but only about the security of mobile devices. We are not talking about capabitlity but cost. Not so much about how much as about who will pay; will we pay by taxation on all or coercion of a few? The Director may have a case, but he has not made it yet.
Of course, a decade ago he did not have any. The modern mobile has given him a rich source of evidence that he has never had before. Instead of saying ”thank you,” he complains that the source is not even richer than it is. He neglects to say how many mobiles that he has opened while finding the few that he cannot. He neglects to address what percentage of those contained useful, much less admissable, evidence of crimes, a number that might give us some idea of any probative value of the contents of the 7000.
What he is really complaining about is that the default security of these devices raises his cost of investigation. He does not even speak to the resistance to crimes against the tens of millions of legitimate devices, users applications, data, and information that that security provides. Therefore, he cannot even get to the idea that in the absence of such security, there would be fewer devices, users, and applications, much less that his rich source of evidence might not even exist.
He argues that, in order to reduce his cost, the default security of the devices should be reduced. In spite of all the testimony against this proposition, and the absence of any in its favor, he argues that the purveyors of the mobiles can reduce his cost while maintaining the security against all others. Without specifying what would satisfy him, he argues that this is simply a small technical problem that the industry can solve any time it wants to.
While the Director talks in terrms of ”capability,” that he does not have, I talk in terms of ”cost.” I assert that if one has a cryptogram, the method, and the key, all of which are on the mobile device, then, at some price, one can recover the clear text. Depending upon the design of the device, the cost may be high but it is finite. The Bureau demonstrated this for us in the San Bernardino case. After asserting that Apple could, but that they could not, they turned to the Israelis, who for a million dollars, recovered the data. Incidentally it proved to be worth considerably less; it provided neither evidence nor intelligence. On the other hand, on a wholesate basis, the cost per device would be significantly less.
One problem is that, whatever the cost, the Bureau prefers to transfer it to the purveyor and the user than to just pay it. It hopes to do this by sowing enough fear, uncertainty, and doubt that a law and order Congress will pass coercive legislation forcing the uninvolved and unwilling to become arms of law enforcement. If the purveyor is coerced into reducing the security, i.e., a value, of his product, he will lose sales and profit. Remaining users will lose security and privacy, experience costly breaches, and incur costs for compensating controls.
The net is that, while the Director may not be able to read every mobile for which he has a warrant, he can read most of them. While he knows what he cannot read, he bears the burden of proof that reading it would yield evidence or intelligence; he has the data, he must share. We are not talking about cryptography in general but only about the security of mobile devices. We are not talking about capabitlity but cost. Not so much about how much as about who will pay; will we pay by taxation on all or coercion of a few? The Director may have a case, but he has not made it yet.
Friday, October 20, 2017
MasterCard to Eliminate Signatures
MasterCard has announced that in the US and Canada, it will no longer require signatures on credit card transactions. (PINs will continue to be required on debit card transactions.) MC says that this will be more convenient for the customer and that it will rely on other (unnamed) mechanisms and processes for security. Let us look at some.
First, many issuers use computer aided mechanisms to detect fraudulent use by looking at such clues as location and other patterns of use. Most of us have had calls from our banks checking on the legitimacy of activity.
In theory, the required signature resists fraudulent use of lost or stolen cards. In practice, not so much. Even when clerks reconciled the signature on the check to the one on the card, it was an imperfect mechanism. In modern systems, where no one really reconciles the signature, the best that the mechanism can do is to permit the consumer to recognize disputed items that he really did sign. However, for the most part, issuers simply accept the word of the consumer that a transaction is fraudulent. The signature does not come into play.
The best way to resist the fraudulent use of lost or stolen cards is to check that a proffered card has not been reported lost or stolen. This works well in the US and Canada, where most transactions take place on line. In countries where many transactions take place off line, PINs are used.
American Express CEO, Kenneth Chennault told President Obama that Am Ex detects many fraudulent transactions within 60 seconds by sending a notification of use to the consumer’s mobile or e-mail in real time.
Bank of America and others resist fraudulent use by permitting the consumer to turn the card on and off using an app. Again, works well where most transactions are on line.
Android, Apple, and Samsung Pay resist fraudulent use by simply taking the card out of the transaction and substituting a digital token for the credit card number. Lost mobile phones resist fraudulent reuse with PINs for security and biometrics, e.g. facial and fingerprint recognition, for convenience.
On line merchants have never had the benefit of signatures but can resist fraud by using PayPal or other proxies instead of accepting credit cards at check out. Where the merchants cooperate and the consumer uses Ámerican Express at checkout, AmEx will prompt the user for a one-time-password sent to the users mobile. This protects the merchant, the consumer and AmEx. All of these resist “card not present” fraud.
Only the brands and issuers really know how necessary and effective signatures and PINs are: they take the risk when they are not required.
The fundamental vulnerability in the retail payment system is the credit card number in the clear on the magnetic stripe. Remains a risk to merchants and issuers but is only a nuisance to the consumer.
In short, the future is mobile, tokenized, cordless, contactless, signature and Pin less, and secure.
First, many issuers use computer aided mechanisms to detect fraudulent use by looking at such clues as location and other patterns of use. Most of us have had calls from our banks checking on the legitimacy of activity.
In theory, the required signature resists fraudulent use of lost or stolen cards. In practice, not so much. Even when clerks reconciled the signature on the check to the one on the card, it was an imperfect mechanism. In modern systems, where no one really reconciles the signature, the best that the mechanism can do is to permit the consumer to recognize disputed items that he really did sign. However, for the most part, issuers simply accept the word of the consumer that a transaction is fraudulent. The signature does not come into play.
The best way to resist the fraudulent use of lost or stolen cards is to check that a proffered card has not been reported lost or stolen. This works well in the US and Canada, where most transactions take place on line. In countries where many transactions take place off line, PINs are used.
American Express CEO, Kenneth Chennault told President Obama that Am Ex detects many fraudulent transactions within 60 seconds by sending a notification of use to the consumer’s mobile or e-mail in real time.
Bank of America and others resist fraudulent use by permitting the consumer to turn the card on and off using an app. Again, works well where most transactions are on line.
Android, Apple, and Samsung Pay resist fraudulent use by simply taking the card out of the transaction and substituting a digital token for the credit card number. Lost mobile phones resist fraudulent reuse with PINs for security and biometrics, e.g. facial and fingerprint recognition, for convenience.
On line merchants have never had the benefit of signatures but can resist fraud by using PayPal or other proxies instead of accepting credit cards at check out. Where the merchants cooperate and the consumer uses Ámerican Express at checkout, AmEx will prompt the user for a one-time-password sent to the users mobile. This protects the merchant, the consumer and AmEx. All of these resist “card not present” fraud.
Only the brands and issuers really know how necessary and effective signatures and PINs are: they take the risk when they are not required.
The fundamental vulnerability in the retail payment system is the credit card number in the clear on the magnetic stripe. Remains a risk to merchants and issuers but is only a nuisance to the consumer.
In short, the future is mobile, tokenized, cordless, contactless, signature and Pin less, and secure.
Wednesday, January 4, 2017
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.
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.
Wednesday, June 29, 2016
The Role of Risk Assessment in Digital Security
The very idea of Risk Assessment has always been controversial. I have been engaged in the controversy for fifty years. My ideas on the subject are well considered if otherwise no better than anyone else's. I record them here.
I attribute the application of this idea to what was then called Computer Security to my mentors, later colleagues, Robert H. Courtney, Jr. and Robert V. Jacobson. They did it in an attempt to rationalize decision making, more specifically the allocation of scarce security resources, to the then nascent field. They did it in response to their observation that many, not to say most, security decisions were being made based upon the intuition of the decision maker and their belief, and a tenet of this blog, that security is a space in which intuition does not serve us well. They wanted to bring a little reason to the process.
They could not possibly have known that in a mere fifty years that the resources applied to this effort would grow to the tens to hundreds of billions of dollars, that the safety and liberty of the individual, the health of public and private enterprise, the efficiency and resilience of our economy, and the security of the nations would turn on how effectively and efficiently we used those resources.
So, at its core risk assessment is a decision making tool. It is a tool that we use to answer the question "where to spend the next dollar of our limited resources?" Courtney's Second Law says one should "Never spend more mitigating a risk than tolerating it will cost you." We will, do, make this decision, with or without tools. We make it intuitively or we make it rationally but we do make it.
At its most elaborate risk assessment is a very expensive tool requiring significant knowledge, skill, ability, and experience to use, more than most of us enjoy. It should be used only for expensive decisions, decisions that are expensive to reverse if we get them wrong. At its simplest, it protects us from making decisions based solely upon the threat, attack, vulnerability, or consequence de jour. It protects us from intuition, from fear.
All that said, few of us are confronting expensive or difficult decisions, decisions requiring sophisticated decision making tools, risk assessment or otherwise.. We have yet to implement all those measures that we know to be so effective and efficient as to require no further justification. They are what Peter Tippett calls essential practices. Anyone can do them, with available resources, they are about 0.8 effective but work synergistically to achieve an arbitrary level of security. They fall in that category that we call "no brainers." All we need is the will.
Monday, February 22, 2016
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.
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.
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.
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.
Saturday, February 7, 2015
Crypto Wars Redux
This morning, while researching another question, I found the following from Aaron Schumann to alt.security, quoting a post to the Risk Forum from me. While written a quarter of a century ago, it might have been written this morning.
From: schuman@sgi.com (Aaron Schuman)
Newsgroups: alt.security
Subject: Congress to order crypto trapdoor?
Message-ID: <1991apr11 .231215.19779="" dragon.wpd.sgi.com="">
Date: 11 Apr 91 23:12:15 GMT
The United States Senate is considering a bill that would require
manufacturers of cryptographic equipment to introduce a trap door,
and to make that trap door accessible to law enforcement officials.
If you feel, as I do, that the risk of abuse far outweighs the
potential benefits, please write to Senators Joseph Biden and Dennis
DeConcini, and to the Senators that represent your state, asking that
they propose a friendly amendment to their bill removing this
requirement.
I don't have exact addresses for Senators Biden and DeConcini, and
I hope someone will post them here, but the Washington DC post office
can deliver letters addressed to
Senator Joseph Biden Senator Dennis DeConcini
United States Senate and United States Senate
Washington, DC 20510 Washington, DC 20510
------------------------------
RISKS-LIST: RISKS-FORUM Digest Wednesday 10 April 1991 Volume 11 : Issue 43
Date: Wed, 10 Apr 91 17:23 EDT
From: WHMurray@DOCKMASTER.NCSC.MIL
Subject: U.S. Senate 266, Section 2201 (cryptographics)
Senate 266 introduced by Mr. Biden (for himself and Mr. DeConcini)
contains the following section:
SEC. 2201. COOPERATION OF TELECOMMUNICATIONS PROVIDERS WITH LAW ENFORCEMENT
It is the sense of Congress that providers of electronic communications
services and manufacturers of electronic communications service equipment shall
ensure that communications systems permit the government to obtain the plain
text contents of voice, data, and other communications when appropriately
authorized by law.
------------------------------
The referenced language requires that manufacturers build trap-doors
into all cryptographic equipment and that providers of confidential
channels reserve to themselves, their agents, and assigns the ability to
read all traffic.
Are there readers of this list that believe that it is possible for
manufacturers of crypto gear to include such a mechanism and also to reserve
its use to those "appropriately authorized by law" to employ it?
Are there readers of this list who believe that providers of electronic
communications services can reserve to themselves the ability to read all the
traffic and still keep the traffic "confidential" in any meaningful sense?
Is there anybody out there who would buy crypto gear or confidential services
from vendors who were subject to such a law?
David Kahn asserts that the sovereign always attempts to reserve the use of
cryptography to himself. Nonetheless, if this language were to be enacted into
law, it would represent a major departure. An earlier Senate went to great
pains to assure itself that there were no trapdoors in the DES. Mr. Biden and
Mr. DeConcini want to mandate them. The historical justification of such
reservation has been "national security;" just when that justification begins
to wane, Mr. Biden wants to use "law enforcement." Both justifications rest
upon appeals to fear.
In the United States the people, not the Congress, are sovereign; it should not
be illegal for the people to have access to communications that the government
cannot read. We should be free from unreasonable search and seizure; we should
be free from self-incrimination. The government already has powerful tools of
investigation at its disposal; it has demonstrated precious little restraint in
their use.
Any assertion that all use of any such trap-doors would be only
"when appropriately authorized by law" is absurd on its face. It is not
humanly possible to construct a mechanism that could meet that
requirement; any such mechanism would be subject to abuse.
I suggest that you begin to stock up on crypto gear while you can still get it.
Watch the progress of this law carefully. Begin to identify vendors across the
pond.
William Hugh Murray, Executive Consultant, Information System Security 21
Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769
We fought this battle once and thought that we won the war.
Monday, January 25, 2010
Exploiting the Rational Attacker
Attackers are often portrayed as irrational, fundamentally evil, or even demonic. They do what they do without regard to the damage that they may do. This is particularly true of amateurs doing mischief. They are simply unable to appreciate the value of public trust and confidence and the cost of the damage that they may do to it.
However, while one would not argue that rogue hackers understand that even they have an interest in an orderly world, one may argue that, at least collectively and across time and events, even they are rational. In the short run, they may underestimate the cost of attack and over-estimate the value of success, they may spend more than they gain. However, they will not do so over and over again. While an angry individual may deliberately spend more to damage another, than any psychic value to himself or even the cost of the remedy to his victim, there is some cost that will deter him, that he is unwilling or unable to pay.
Given two attacks to achieve a particular value of success, at least collectively, attackers will choose the cheaper of the two.
None of this is to suggest that the rogues are any better at estimating cost and value than any of the rest of us. They make their decisions in a "market" like the rest of us. However, within our tolerance for risk, our estimates of his cost of attack and value of success provide us with a guide for our spending on security. To the extent that we believe that his value of success is higher than his cost of attack, we should increase the cost of attack. We call that "security."
However, while one would not argue that rogue hackers understand that even they have an interest in an orderly world, one may argue that, at least collectively and across time and events, even they are rational. In the short run, they may underestimate the cost of attack and over-estimate the value of success, they may spend more than they gain. However, they will not do so over and over again. While an angry individual may deliberately spend more to damage another, than any psychic value to himself or even the cost of the remedy to his victim, there is some cost that will deter him, that he is unwilling or unable to pay.
Given two attacks to achieve a particular value of success, at least collectively, attackers will choose the cheaper of the two.
None of this is to suggest that the rogues are any better at estimating cost and value than any of the rest of us. They make their decisions in a "market" like the rest of us. However, within our tolerance for risk, our estimates of his cost of attack and value of success provide us with a guide for our spending on security. To the extent that we believe that his value of success is higher than his cost of attack, we should increase the cost of attack. We call that "security."
Monday, January 18, 2010
Welcome to "Thinking about Security"
This is the first entry in this blog, Thinking about Security.
A legitimate reaction would be, "Just what I need, one more blog about security." So, how is this blog different? Why should anyone care?
First, unlike most on this subject, this blog is not topical. While I may sometimes use a current report to illustrate an idea, this blog is not about what happened today. Indeed, in part, it is about "today not." It is not about the patch, attack, threat, or vulnerability of the day.
Rather, this blog is about a context and perspective in which to view and respond to the events of the day. It is about:
It responds to my observation that security is a space in which intuition does not serve us well and in which rational thinking is difficult. There are many variables, some of which are un-identified. Even for the identified variables, the range of possible values, much less the exact or current value, may be unknown, or even unknowable. So, this blog will stress making hard decisions in the face of uncertainty.
The tools that we use to make these decisions include the language of risk assessment. We must keep these tools sharp and practice our skill in using them However, few security professionals, much less others, use the terms of this language (e.g., risk, threat, attack, vulnerability) in a consistent and mutually exclusive way. For example, when asked by a reporter to enumerate threats confronting the enterprise in the coming year, a famous security guru (in the literal sense of guru) quickly listed three vulnerabilities, novel, interesting (at least to the two of us) and totally irrelevant to the average enterprise. So in this blog we will practice the use of these tools.
Because this is such a hard subject to talk about, your feeback will be necessary and welcome.
A legitimate reaction would be, "Just what I need, one more blog about security." So, how is this blog different? Why should anyone care?
First, unlike most on this subject, this blog is not topical. While I may sometimes use a current report to illustrate an idea, this blog is not about what happened today. Indeed, in part, it is about "today not." It is not about the patch, attack, threat, or vulnerability of the day.
Rather, this blog is about a context and perspective in which to view and respond to the events of the day. It is about:
- Decision Making
- Governance
- Policy
- Strategy
- Priorities
- Management System
- Rules and Tools
It responds to my observation that security is a space in which intuition does not serve us well and in which rational thinking is difficult. There are many variables, some of which are un-identified. Even for the identified variables, the range of possible values, much less the exact or current value, may be unknown, or even unknowable. So, this blog will stress making hard decisions in the face of uncertainty.
The tools that we use to make these decisions include the language of risk assessment. We must keep these tools sharp and practice our skill in using them However, few security professionals, much less others, use the terms of this language (e.g., risk, threat, attack, vulnerability) in a consistent and mutually exclusive way. For example, when asked by a reporter to enumerate threats confronting the enterprise in the coming year, a famous security guru (in the literal sense of guru) quickly listed three vulnerabilities, novel, interesting (at least to the two of us) and totally irrelevant to the average enterprise. So in this blog we will practice the use of these tools.
Because this is such a hard subject to talk about, your feeback will be necessary and welcome.
Subscribe to:
Posts (Atom)
Posts
