One of the things that I love about blogging is that it often puts you directly touch with those people who are influencing your thinking. This is just what happened when Microsofts Shawn Hernan sent me an email response to my recent blog post about the security of Open Source Healthcare Software. As it turns out, he also spent some time at the Air Force Information Warfare Center in San Antonio, we probably passed each other in the hall at some point.
Shawns original article, Microsoft’s Many Eyeballs and the Security Development Lifecycle had spurred me both to kibitz some of his points, and to consider their implications in Open Source healthcare software.
Shawn wrote the following to me and gave me permission to quote him here:
I saw your comments on my blog, and just wanted to write a quick note to thank you for the positive comments and the constructive and reasonable criticism.
It is of course unfair to lump all open source projects under one umbrella, and I regret leaving that impression. The various fights that people have over the different open licenses is all the evidence that anyone needs to see to realize that the only thing that many FOSS projects have in common is their “FOSSness.” And it’s clearly true that there is some highly competitive FOSS software.
I also like your characterization of “the game” for developers. I ran the security training program at Microsoft for a while, and while it was successful, I quickly learned that a corporate training program leaves a lot to be desired. We have a team called “Engineering Excellence” and they turned me on to the ideas of human-performance management, and I wrote about some of my experiences here: http://blogs.msdn.com/sdl/archive/2008/05/29/sdl-training.aspx. I think this is not too far from your idea of “the game” as I understand it.
I will quibble some with your ranking, though, and the implicit assumption that Microsoft is all a single culture. While the cultures differ from team to team (Windows v Office v SQL), all the big teams have a security-obsessed subculture and are all subject to at least the minimum SDL requirements, and I feel confident in saying that all our teams are at the very least competitive with the best open-source projects. I would invite you to look at the security track records of SQL Server, vs. MySQL for example.
But I do agree that the #6-style vendors may try to adopt my argument; I’m not trying to claim that proprietary software is inherently more secure than open source, but merely trying to challenge the meme that openness, all by itself, conveys magic security properties.
I agree with Shawns point here. The meme that openess all by itself is a magic bullet for security improvement is dangerous precisley because it interferes with “games” that can make Open Source more secure.
When someone says “The Many Eyeball effect” the right counter should probably be, “The Many Eyeballs Actually Looking”. Secure Open Source does not happen because people merely can look, it happens when they use their rights under the license to actually take a look. Openess is a critical first step in the process, but only the first step. Often, as I look at how money is being spent in Open Source in healthcare, I see far too little being explicitly spent of efforts to make things more secure. I think part of the reason is that people just assume that it will happen. When it doesnt you end up with insecure code that people trust more, because it is open.
I hope it is clear why this is an especially bad problem for Open Source Health Information Software. People really need to be able to rely on Health Information being private. There are two reasons for this. First, it could actually hurt someone if their health information got out. Second, our culture reacts really poorly to violations of trust, and, even if a software developer is not directly at fault for private information getting out, the reputation consequences are very serious.
Our community has already been damaged by this effect. The VA’s reaction to security breaches was part of the motivation for centralizing VistA development, which has lead to a serious stagnation in VistA development within the VA. The current VA administration is slowly reversing many of those decisions and opening development back up, but “security drama” has already seriously damaged VistA development.
We should be listening carefully to Shawn here. His point is, very simply, that merely being Open Source does not ensure security. We need to find a way to create a “game” for Open Source healthcare developers that automatically improves security. Without some kind of built-in incentives, we run the risk of creating trust without justification. We need to take page from Microsofts book here, at least to a certain extent.
We need to work to convince those of us who are “feature-focused” to balance that with a “security-focus” if we are to be succesful long-term.