Loading ...
Shostack’s paper/presentation rests on the following assumptions:
1. Security Breaches normally do not have much of an impact
2. Security Breaches increase transparency
3. Information Security Transparency is good
4. Transparency allows us to collect data which in turn allows us to create knowledge which in turn allow us to “learn something” (science)
While I agree with points 1 ,2 and 4, I do not always agree with point 3 (even if taken together with 4).
I have long maintained point one. My research in 2005 roughly outdates the 2006 research Adam cites by about a year. OK, so mine isn’t academic and I have a smaller data set, but I was correct in predicting most breach patterns.
I agree with point two. After being breached, one must disclose various aspects of that breach. This disclosure certainly increases transparency.
I agree with point four: collecting data and knowledge creation are quite important. Science is important. Science can help us to strategize about the best way to increase security for our organization.
But I do not always agree with the third point, even when taken together with the four point. There are plenty of information security practices as well as security information that we do not want to see disclosed and should not be disclosed.
Our surveillance and detection techniques for monitoring, preventing and detecting intruders should not be disclosed. It’s like giving a blue print to the attacker. Secrecy is a valid security practice(!) in the context of a larger set of functioning, well designed security mechanisms. (It is in this way that security is much different than the investigation of cholera.)
Turning back to security breaches, what really do we learn from them? There was an error (human or mechanical), that an attacker (insider/outsider) found a security weakness, that non-public personal data was exposed and to what extent.
Some of this breach information, while important, may not be best suited for direct public disclosure. Shostack’s best counter argument is point one: if breaches really do not create much of an impact, what’s the harm of disclosing the details of the breach? Well my reply is that it’s generally bad business practice to disclose the details of one’s operations: one should not engage in practices which may diminish one’s source of competitive advantage.
(Are there cases where full disclosure is necessary, absolutely.)
Rather than direct and inconsistent corporate/government breach disclosures, a more apt way to do it is as following: by law, a breached organization must report the breaches to a centralized authorized repository which will collect specific details of the breach in order to begin to amass worthwhile breach statistic for both public and private use. The specifics of what must be reported are universal standards required by all breach filers. Most specifics are kept confidential, but the relevant information about each particular breach is publicly disclosed depending upon the nature (category of severity) of the breach. An additional independent body (which could already exist) should have oversight of this centralized breach repository. The repository should be audited by an additional third party to ensure accuracy of information. The aggregated information should be tabulated, scrubbed of any organizational specifics and released publicly so that all organizations and individuals may benefit.
Disclosure of information security practices, mechanisms and the like should be disclosed in a gray box fashion, not a translucent one.
Again, if the breach is so egregious, full disclosure may be necessary. These conditions would be spelled out in advance.
If one really wants a good example of the cross between science, society and disclosure, I suggest reading American Prometheus: The Triumph and Tragedy of J. Robert Oppenheimer. The conversation between the government and US scientists regarding Russia and the atomic bomb are much closer to our field of information security than the investigation of cholera.
5 Comments
Hi Ken,
Thanks for the analysis and commentary!
It deserves a fuller response than I have time for this morning, but I did want to quickly address two points:
First, I don’t believe that disclosure, or anything else, is a pure good. The road to hell, after all, isn’t paved with evil intent. I think that disclosure tends to be good, and I’ll say more on this.
Second, since I was giving a talk, rather than writing a formal paper,I chose to cite very lightly without meaning to give offense or dismiss ideas. I had actually mentioned your work briefly on emergentchaos when I ran across it.
Adam,
Thanks for the reply and the provocative presentation.
I agree: disclosure tends to be good. It’s more a question on process and what one discloses. The devil in in the details and as such this is particularly tricky.
You’re welcome! I’ve posted more thoughts on the issues you raise: http://www.emergentchaos.com/archives/2007/04/response_to_ken_belva_on.html
Your suggestion about involving a centralised authority to filter breaches simply won’t work, if your goal is breach disclosure leading to analysis. It will work if the goal is suppression.
Unfortunately, the larger companies will lobby for the authority to close off all info and we’ll be back where we started. No centralised authority will be able to deal with the money thrown at it, and the salaries will be such that all you’ll get are bureaucrats working there, trying to swap into a good private sector job.
As for auditors, that won’t work either because the audit will be confidential, so it won’t be relevant.
You wrote:
But that is not what is being done! The breach disclosure is the disclosure of a failure of operations. The actual operations remain obscured, and they are going to be changed anyway.
(Old army trick: do not encrypt the location of an attack, because the enemy knows that already, and can use it against you.)
(And, I agree with Adam on the point about competitive advantage. We should challenge the managers that bring up such big words to explain the competitive advantage in terms that a competitor might extract some advantage out of.)