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., N0. 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.
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., N0. 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.
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
