Window Snyder, Mozilla's chief security something-or-other (her official title), wants to bring open source practices to the security community.
"At a lot of companies," she told me recently, "there's fear around security: you don't want to talk about what you're doing around security because one might deem it not enough--or might want to criticize it." She said most companies have a lot of reasons to keep what you're doing in security quite, but not Mozilla. "We benefit from being open; it's the model for us and it's been successful for us."
Snyder started her security work at @Stake (now a part of Symantec) then went to Microsoft and later Matasano Security. She describes her journey as moving toward open source with each environment. At Mozilla, makers of the popular Firefox browser, Thunderbird e-mail client, and other open software, she's pretty much at ground zero.
Snyder said the idea of opening up security came about by asking, "What are we doing internally that we can make publicly available to help somebody else in some other project."
They decided to start out small. "We're starting off with secure programs and practices for C and C++. There is a focus on how to make it useful for a browser, but there is of course a general aspect to this. It's training materials, it's syllabi, exercises, it's a workshop-style class. Hopefully we'll be able to do video as well." The idea is that one employee from a company can attend these workshops and then take the training back home to train even more people.
Johnathan Nightingale of Mozilla echoed this. "It's pretty brittle if there's only one person who is the security guy or gal that always solves a problem. It's better to get that knowledge out there--whether it's working on Mozilla or some other project. By working at understanding the good habits and the bad habits, you've made a huge step forward."
In addition to training sessions, Mozilla will be making a variety of tools available. Last year Mozilla released a protocol fuzzer created by Michael Eddington, and a Javascript fuzzer created by Jesse Ruderman. Further, Mozilla admitted that these tools had found vulnerabilities within Firefox. Accepting that openness, Opera reported that the tools had also discovered a flaw within its browser product. Microsoft, maker of Internet Explorer, and Apple, maker of Safari, haven't revealed whether they used the tool to detect any flaws in their products.
Snyder says often the security story isn't that a company created a tool that found 14 vulnerabilities in it own product, it's that there were 14 vulnerabilities in the product in the first place. "Why would they want to share this tool? Maybe they want to demonstrate how successful it was because it found a vulnerability. That's something that we can do that other companies cannot."
In addition to training and tools, Mozilla wants to talk more about security metrics and threat modeling.
"Threat modeling is a methodology for identifying security vulnerabilities, for identifying the risks of a security vulnerability within that application," Snyder said. "Making a threat model available shows other development environments how a complex application like Firefox gets deconstructed into threats, along with the mitigations that we've implemented to address those specific threats.
"But it also gets us feedback on whether or mitigations are sufficient. It gets the research community engaged in another point in the development process. Instead of looking for vulnerabilities at the end of the lifecycle, they're able to get involved in the threat modeling process which is between design and implementation, ideally. You want to be able to do it early enough in the process so that you can actually change at the architectural level as the result of threat modeling."
The goal, she said, is to remove whole categories of vulnerabilities. "Here's a pattern, and if we implement one architectural change we can eliminate all these vulnerabilities."
Threat modeling is more theoretical; it's abstract. "So, instead of saying concretely if you do this that and the other thing, that will result in an actual vulnerability, threat modeling, says there is no input validation mechanism, for example. If you send a request this way, you end up bypassing the input validation mechanism and you're sending content, unvalidated to this audio decoder. That would be scary. So the threat would be unvalidated content is being passed directly to the audio decoder if it comes in this way. A vulnerability would be there's an overflow in the audio decoder that an attacker is able to trigger if they craft a URL this way, and because it bypasses the input validation mechanism, all these other mechanisms that would have protected from an exploit are bypassed as well."
She concludes that the training, the tools, and the threat modeling is "good for peer reviews, it's good for testers, it's good for developers." She sees it as delivering on a promise to "to make the Web more secure."
Mozilla has been steadily demonstrating how open source projects can make money without betraying their community goals. At Mozilla, she says "we absorb the costs in criticism and we tolerate that in security because the benefit for us far outweighs everything else."
No comments:
Post a Comment