Adam over at EC, responding to an entry by Phill, is banging the drum on breach data collection and distribution, which is well needed. I first saw this point in a paper from around 2004, and it has been a well trodden theme in the now popular field of Sec&Econ. All well and good. We need more breach data.
However, collecting the data is not the be-all and end-all. It's not for example what would have saved Enron, which is what Adam alludes to:
SarBox is what we get when we have no data with which to push back.
Sarbanes-Oxley collects lots of data, but doesn't change the problem space, and it arguably makes the problem space worse.
Sarbanes-Oxley is what you get when (a) systems get too complex and (b) businesses don't implement Financial Cryptography techniques to reduce and eliminate those complexities. Under these two conditions, what you get first is fraud -- keep in mind that fraud comes out of complexity and lack of reliable systems. The lack of reliability means the systems can be perverted, and the complexity means the perversions can be hidden.
What you get second is Sarbanes-Oxley, as well-meaning accountants discover that they can set themselves up for a *lot* of work and provide a veneer of cover for frauds like Enron.
In contrast, in FC, we have patterns and methods to tighten up all that transaction stuff. RAH's old saw about it being 2 orders of magnitude cheaper is in the right ballpark, except that it might be conservative. FC creates both reliability --- cryptographically based real time non-pervertable reliability -- and removes complexity, as whole layers at a time can be dispensed with because we can simply write automatic audit processes that show 100% conformance.
But these aspects are also why FC didn't get implemented. In a regulated industry, there is incentive to corporate business model cloning (economists call this 'herding'), which leads to cartel behaviour (see paper for another angle) and this then leads to an incentive to raise costs, not lower costs. The banks are a canonical case, as they are so highly regulated that all banks are almost always clones of each other.
If that doesn't make sense, consider it this way. Ask an accountant whether he would recommend a system (say, FC) that would halve his account, or whether he'd recommend a system (like Sarbanes-Oxley) that would double his account.
Add to these effects of fraud and we find another barrier to FC: the experience of those who work at the systemic level to try to put in simpler, more cost-effective systems that eliminate fraud is that they also run slap-bang into those people who perpetuate fraud. These people are very hard to dislodge, for very good reason: they are making a lot of money out of the complexity and poor reliability systems. They are prepared to spend a lot of money keeping systems complex and unreliable.
The answer then is not to increase regulation a la Sarbanes-Oxley, but to decrease regulation, and let things like SOX (or AADS or other similar systems) innovate and drive costs and complexity down. Every time the regulation increases, expect more complexity and therefore more fraud and more costs. Decrease regulation and expect the reverse. Simple.
Economists have known this for decades, we don't need to re-invent the wheel in the security industry with calls for this or that regulation.
Posted by iang at August 9, 2006 10:21 AM | TrackBackthere is slightly different point that i made in a EU conference last fall regarding the sox audit process ... aka audit has been used to check corporate books for inconsistency (typically independent physical books) ... as potential indication of wrong doing.
i asserted that with books moving to IT technology ... the IT technology could be programmed to generate consistent books.
SOX then asks for information in ever increasing detail. This can aid business people in understanding their business ... if they don't otherwise have the understanding.
However, from the standpoint of catching things wrong ... the assertion is that IT technology could be leveraged to generate single source, consistent numbers to any level of detail (just increasing the level of reporting detail won't necessarily create independent sources that can be examined for inconsistencies).
at a conference recently in june, somebody commented that for a small to medium size company the sox bill is currently running $800k.
the issue isn't so much that it is a matter of more regulation or less regulation ... again, yet, still ... it is a matter of looking at what the threat model and whether the selected countermeasure(s) are effective for that threat model.
past posts on the subject:
http://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006j.html#28 Password Complexity
http://www.garlic.com/~lynn/2006n.html#32 The System/360 Model 20 Wasn't As Bad As All That
Sorry, you lost me when you said SOX collects lots of data. Please to explain?
Adam: "Sarbanes-Oxley collects lots of data" is a shorthand really. More precisely Sarbanes-Oxley causes more checks, more rules, more auditing, all of which lead to more data as a sideeffect.
This data is not about breaches, it could be processed for breaches, but even this is missing the point. It is possible to confuse external breaches (as those in the "security" world are faced with routinely) with governance failures, which is what Sarbanes-Oxley addresses. A governance failure occurs when insiders have more information about the internal checks and balances, and work out that certain tricks can be played. In this sense, we can see a scenario where what we might agree is a breach in governance is not treated as a breach at all because it is simply too complex to understand.
Pop quiz #1 - what was the fraud behind Refco? what was the fraud behind Enron? How many people know this?
Pop quiz #2 - what was the breach behind Choicepoint? VA?
The number of people who can understand #2 is massively larger than the people who understand #1.
Lynn asks what the threat model is. One can characterise it as this: insiders know more than auditors. Does Sarbanes-Oxley address that? Not really, it makes the auditing more comprehensive, but it makes it more complex; and auditors remain outside, coming in on infrequent basies, and more and more predictable checking. More regulation, more Sarbanes-Oxley, and more checks do not address the fundamental flaw that insiders know more.
Hence, less regulation is an answer, and that may even mean that in the short term you seem to get more fraud, but it also means that the market place will be pushed to innovation in fraud, and efficiency.
Posted by: Iang at August 10, 2006 11:38 AMthe other way of looking at is that the insiders generate the books, the auditors check the books for mistakes or inaccuracies.
in iso9000 type scenario ... they are looking for whether you have gotten it correct.
the sox scneario is more looking for whether somebody has gotten it wrong, possibly purposefully wrong. when there were independent records from independent sources ... the auditors could look for inconsistencies.
the possiblility exists if all the records are being generated by a single IT system ... there is no longer independent sources allowing auditors cross-checking, looking for inconsistencies ... possibly making it extremely difficult to identify purposeful incorrect records.
increasing the amount of data examined doesn't directly address the issue of having independent sources to check for inconsistencies (of possibly purposeful incorrect records)
ref:
http://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
the breach issue can be looked at differently. the issue here frequently involves financial account numbers. the problem is on one hand, financial account numbers need to be available in hundreds of business processes for correct functioning. At the same time, exposure of the financial account number may be sufficient to perform fraudulent transactions.
this can create diametricly opposing objectives ... on one hand, the account number has to be generally available for the correct functioning of business processes and on the other hand the account number has to be kept confidential and never exposed.
this is somewhat my old risk proportional to security item
http://www.garlic.com/~lynn/2001h.html#61
the other part of it is the work in the x9a10 financial standard working group from the mid-90s that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
part of the x9.59 standard eliminates just having knowledge of the account number as a threat for fraudulent transactions (eliminating the diametricly opposing objectives for treatment of account numbers; readily available and never available).
this is part of my periodic postings about the existing infastructure and even if the planet was buried miles deep in crypto ... it still couldn't prevent account number leakage
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/2001.html#45 what is UART?
http://www.garlic.com/~lynn/2003k.html#11 humor in source code
http://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
Sounds like a good time to bring in my work on open governance. The philosophy of Ricardo was to reduce costs dramatically in both support and governance; as we intended to field it in low cost areas.
For this reason I developed 5PM - five parties model - for governance of the total amount of issued value. The publication of the balance sheet in the broad means that the public can audit the big numbers anytime. To get to the small numbers -- every detailed transaction -- we hit the naked but not vulnerable payments issue as there is the privacy angle.
Open Governance relies/requires that all transactions are fixed at the authority in time of the transaction (hence, signed by the payer account, and the resultant transaction enacted by a signed receipt by authority/issuance server, which includes former so it is not forgeable/changeable after the fact).
Hence, we end up with a tree of transactions where all tx refer back up the tree to a single tx. (with the addition of a hash chain/entanglement) it would be possible to show that we have the entire set of tx from t0 to now. Which then means we can automatically audit the whole issuance with a program and prove that no tx were changed/inserted/dropped.
This all leads into triple-entry accounting ...
So when I say, you get Sarbanes-Oxley when you don't do FC, what I mean is if you use these techniques you simply don't need any additional human checking to cover a whole set of books / a whole corporate accounting system, etc etc. Slight caveat is that this applies to hard asset issuance which more or less applies to many internal corperate accounting tasks, but in detail and in particular I have not covered more than a fraction of them. So there may be some corner cases where we have to phone up KPMG again.
Posted by: Iang (Open Governance ... draft paper to finish one day) at August 10, 2006 07:33 PMThanks for your followup. I don't think that companies generate (useful) data as a reult of Sarbox, because of the base rate falacy. Breaches are still rare enough that most companies can't do the analysis internally.
a couple news things from yesterday
Strategic Innovation >
http://www.bizintelligencepipeline.com/showArticle.jhtml?articleId=191801849
Finance company finds way though Basel II maze
http://www.silicon.com/financialservices/0,3800010322,39161291,00.htm
...
and
Basel II: Revised international capital framework
http://www.bis.org/publ/bcbsca.htm
ref:
http://www.garlic.com/~lynn/aadsm25.htm#13
Basel II then is somewhat more like iso9000 than sox ... i.e. it isn't trying to identify corporate misdeeds.
it is more trying to assess how well a financial institution is doing its business ... which then results in "risk adjusted capital" ... based on the risk assessed by Basel II, the financial institution has to set aside capital to cover the evaluated risk.
basel II is a lot of quantative measurements of the risks for a financial institution. it is more along the lines of parameterized risk management ... mentioned in these posts
http://www.garlic.com/~lynn/aadsm25.htm#1
http://www.garlic.com/~lynn/aadsm25.htm#2
the original basel II draft had a whole new section titled qualitative measurements ... which was mostly dropped in subsequent iterations. qaulitative measurements was somewhat more along the lines could you describe all your end-to-end business processes ... such that the board of directors knew what all the business was (and possibly was there a risk factor if it didn't)
Then there is the issue of metadata and data quality ... do you understand your data, what it means, and is it accurate and correct (as opposed to possibly purposefully incorrect). we've been periodically involved in such metadata and data quality stuff with our knowledge base stuff
http://www.garlic.com/~lynn/
oh, and a sox related news item from today:
Compliance Newsflashes: SEC Eases Up on SOX for Small and Foreign Companies
http://www.financetech.com/news/showArticle.jhtml?articleID=191901528
... and for a little drift on the basel II topic
http://www.garlic.com/~lynn/aadsm25.htm#13
inactive funds held in (risk adjusted) capital reserves can represent a significant hit on institution's bottom line. as a result, there can be significant financial incentive for a financial institution to do as well as possible in basel ii evaluation.
for some other drift on capital reserves ... the following is a long winded discussion on the thread between risk management and information security
http://www.garlic.com/~lynn/aepay3.htm#riskm
but has some discussion about the sequence of events that followed the capital reserve requirement for savings and loans being cut in half in the 80s.
Posted by: Lynn Wheeler at August 11, 2006 10:48 AMReading this posted old reference by Lynn, I was struck by this gem:
http://www.garlic.com/~lynn/aepay3.htm#riskm
"Digital bond trading will be created out of this body of knowlegde. Without the ECC, AADS, X9.59, pki's, secure chip cards, hardware accelerators, intrusion detection capabilities, information security valuation models, secure information technology architectures ( digital distributors), digital rights management systems, etc. you can't create the cashflows and the contracts to create the bonds."
Well, so someone was paying attention. Who wrote that? FTR, you can do digital bond trading without most of that. Bond trading was what Ricardo was literally designed to support as a payment system, and its key features include none of the above. Instead it relies on the Ricardian Contract, the document that allows the specification of complex conditions that then feeds in to every transaction, end to end.
The next section says:
"Two [problems] for me are; 1) corrupting the integrity of the secondary market by altering term contracts via intrusion and 2) a trading desk environment via intrusion. The second problem while painful and probable is manageable. It is the first problem and the lack of a proper methodology to address the problem that I find challenging."
The first is utterly solved by the Ricardian Contract. The second is of course a user problem.
Earlier, the (first) author says:
"Once Regulators pick this up in the US or for that matter any other country the attitude towards information security will radically shift in the direction we are leading it. The shift will be powerful and overnight."
The author is right in that Regulators pick up the difference, this has been clear in that the BoE, SEC and Fed people who've looked at Ricardo have realised it solves their issues. I imagine they had the same realisation with AADS. But the second part is wrong, regulators are also relatively powerless -- they have not the budget nor the power to force intransigent FIs to employ technology that FIs don't want to employ. The old thing about orders of magnitudes of efficiency improvement means orders of magnitudes less jobs, too.
Posted by: iang (Ricardian Contract) at August 13, 2006 06:03 PM