Re: A slight modification of my comments on PKI.
On Jul 29, 2010, at 22:23, Anne & Lynn Wheeler wrote: > On 07/28/2010 10:34 PM, d...@geer.org wrote: >> The design goal for any security system is that the number of >> failures is small but non-zero, i.e., N>0. If the number of >> failures is zero, there is no way to disambiguate good luck >> from spending too much. Calibration requires differing outcomes. >> Regulatory compliance, on the other hand, stipulates N==0 failures >> and is thus neither calibratable nor cost effective. Whether >> the cure is worse than the disease is an exercise for the reader. > > another design goal for any security system might be "security proportional > to risk". Warning: self-promotion (well, rather: project promotion) ahead. This is exactly what we are trying to do in an EU project in which I'm involved. The project, called MASTER, is more concerned with regulatory compliance than security, even though security of course plays a large role. The insight is that complex systems will probably never have N = 0 (in Dan's terms), so we will have to calibrate the controls so that the N becomes commensurate with the risk. To do this, we have two main tools: First, there is a methodology that describes in detail how to break down your high-level regulatory goals (which we call control objectives) into actionable pieces. This breakdown tells you exactly what you need to control, and how. It is controlled by risk analysis, so you can say at any point why you made certain decisions, and conversely, if a regulation changes, you know exactly which parts of your processes are affected (assuming the risk analysis doesn't have to be completely redone as part of the regulatory change). Second, as part of this breakdown process, you define, for each broken-down control objective, indicators. These are metrics that indicate (1) whether the process part you are currently looking at is compliant (i.e., has low enough N), and (2) whether this low N is pure luck or the result of well-placed and correctly functioning controls. One benefit of having indicators at every level of breakdown is that you get metrics that mean something *at this level*. For example, at the lowest level, you might get "number of workstations with outdated virus signatures", while at the top you might get "money spent in the last year on lawsuits asserting a breach of privacy". This forces one to do what Andrew Jaquith calls "contextualisation" in his book, and prevents the approach sadly taken by so many risk analysis papers, namely simply propagating "risk values" from the leaves of a risk tree to the root using some propagation rule, leaving the root with a beautifully computed, but sadly irrelevant, number. Another benefit is that if some indicator is out of some allowed band, the remedy will usually be obvious to a person working with that indicator. In other words, our indicators are actionable. The question of whether the cure is worse than the disease can't be settled definitively by us. We have done some evaluation of our approach, and preliminary results seem to indicate that users like it. (This is said with all the grains of salt usually associated with preliminary user studies.) How much it costs to deploy is unknown, since the result of our project will be a prototype rather than an industrial-strength product, but our approach allows you to deploy only parts. Best, Stephan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
for the fun of it ... from today ... Twenty-Four More Reasons Not To Trust Your Browser's "Padlock" http://blogs.forbes.com/firewall/2010/07/29/twenty-four-more-reasons-not-to-trust-your-browsers-padlock/?boxes=Homepagechannels from above: On stage at the Black Hat security conference Wednesday, Hansen and Sokol revealed 24 new security issues with SSL and TLS, the digital handshakes that browsers use to assure users they're at a trusted site and that their communication is encrypted against snoops. ... snip ... adding further fuel to long ago motivation that prompted me to coin the term "merchant comfort" certificates. ... as an aside, we were tangentially involved in the cal. data breach notification legislation. we had been brought in to help wordsmith the cal. electronic signature act ... and some of the participants were heavily involved in privacy issues. They had done in-depth consumer privacy studies and the number one issue came up "identity theft", namely the "account fraud" form where criminals use account &/or transaction information (from data breaches) to perform fraudulent financial transactions. It appeared that little or nothing was being done about such data breaches ... and they appeared to believe that the publicity from the data breach notifications would motivate corrective action to be taken (and as mention in previous post ... we took a slightly different approach to the problem in the x9.59 financial transaction standard ... eliminating the ability of crooks to use such information for fraudulent transactions). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
On 07/28/2010 10:34 PM, d...@geer.org wrote: The design goal for any security system is that the number of failures is small but non-zero, i.e., N>0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. another design goal for any security system might be "security proportional to risk". the major use of SSL in the world today is hiding financial transaction information ... currently mostly credit card transactions. One of the issues is that the value of the transaction information to the merchants (paying for majority of the infrastructure) is the transaction profit ... which can be a dollar or two. The value of the transaction information to the attackers is the associated account limit/balance, which can be several hundred to several thousand dollars. This results in a situation where the attackers can afford to outspend the defenders by 100 times or more. somewhat because of the work on the current payment transaction infrastructure (involving SSL, by the small client/server startup that had invented SSL), in the mid-90s, we were invited to participate in the x9a10 financial standard working group (which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments). the result was the x9.59 financial transaction standard. Part of the x9.59 financial transaction standard was slightly tweaking the paradigm and eliminating the value of the transaction information to the attackers ... which also eliminates the major use of SSL in the world today. It also eliminates the motivation behind the majority of the skimming and data breaches in the world (attempting to obtain financial transaction information for use in performing fraudulent financial transactions). note the x9.59 didn't do anything to prevent attacks on SSL, skimming attacks, data breaches, etc ... it just eliminated the major criminal financial motivation for such attacks. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
d...@geer.org wrote: Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. I do not believe regulations require that there be zero compromises to systems, Dan. On the contrary, I believe the goal of any regulation is to ensure that there is a minimum level of calibration across the industry. In the absence of regulation, calibration would be all over the map; while experienced companies with adequate resources might be better calibrated, the less-experienced or less-resourceful companies would start the dominoes falling and inadvertently bring down even the well calibrated companies. Regulations can help with preventing that first domino from falling if implemented effectively. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
> It is important to remember what we're trying to defend against. As > many of us have learned through bitter experience, the costs and > benefits of security systems we deploy are the important part. No one > needs perfect security in the face of no attackers at all, and even if > attackers are numerous, if a system has low enough failure/fraud > rates, no one will complain much. The design goal for any security system is that the number of failures is small but non-zero, i.e., N>0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
A slight modification of my comments on PKI.
A coda on today's voluminous discussion of X.509, browser security, etc. It is important to remember what we're trying to defend against. As many of us have learned through bitter experience, the costs and benefits of security systems we deploy are the important part. No one needs perfect security in the face of no attackers at all, and even if attackers are numerous, if a system has low enough failure/fraud rates, no one will complain much. The problem is that the system we've built to date is, in fact, yielding pretty high fraud rates. Attacking people is a full time profitable business for a lot of people, not a rare sort of thing. Stolen credentials are sold in the market for very low prices because there is a glut of them. Yes, the majority of online transactions are trouble free, but a shocking fraction of them are not, and the majority of people I know have had a card stolen at least once online. Things like bank account credential phishing are not only possible but prevalent. All this may get worse. The cost is a large fraction of the fees we all end up paying, directly and indirectly, to do business. What we would like is to get from the situation we are in now (which reminds me in certain ways of the days of analog cellphone service where cloning was trivial) to a situation where fraud still happens but is much more difficult to pull off. (Certainly phone fraud still happens, but it is no longer anything like it was in the NAMPS days and the cost is manageably low.) This would also have the benefit of radically reducing the number of people who can make a living as professional attackers, which would have all sorts of salutary effects. To lower the fraud rate by significant margins, I think we'll need to make some serious changes in the security systems we deploy. Logging in to your bank's web site using a password protected by an SSL session requires that too many things all go right and that the user pay attention to whether they have all gone right. We need simpler systems where, if the user is not paying attention, nothing much bad can happen to them anyway. No system can be perfect, but we could do a lot better than we are doing now. I think this is achievable in theory. Whether it can happen in practice, I have my doubts, though we can but try. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
