Coding in corporate responsibility
Published: 16 May 2005 11:20 BST
Regulation is one option but there are other forces that could potentially correct the market. Specifically, customers being more demanding can help these market forces. (We need to) help customers ask their IT vendors the right questions before buying their products. Do the vendors run the software themselves? If they're not, then why should you take that bet? Do they run competitor's software? If so, why? Do they train their developers on secure coding practice? It's not that security is only about code quality, but most of the patches people have to apply are because somebody just did a poor job on building software. So ask your vendors if they train their developers in coding practices. Do they have a good development process that security is engineered in? Do they start thinking about security before they start writing codes? Do they vet their products against third-party standards, for example, do they pay for Common Criteria evaluation? Do they halt product shipping if there are security defects? It's nice to know if your vendor puts your safety first, and not try and ship you a piece of software that has a lot of holes in it just because they need to make their quarterly revenue numbers.
I'm not trying to blame customers for the state of bad security. Not at all. I think vendors need to step up to this plate. But at the same time, customers can help shape the market by pushing the vendors to do right thing by them, and to be an informed buyer. Informed buyers change the market.
That puts you in a unique position. How do you reconcile your role as the CSO of a company that's part of the software vendor community?
I don't actually think us as part of the problem, though I'm not saying we're perfect. We are recognised as having done a lot of good things for a long time. We've talked about this for years. In fact, a lot of what we've done has been in compliance. We release checklists before we ship products, and every component on the delivered material has to complete a questionnaire that we designed to weed out security faults.
But it's not just about us. If only Oracle built good quality software, good for us, but it doesn't actually help the larger ecosystem. We're not perfect but there's this industry myth that the vendor community is sitting around and waiting for researchers to find vulnerabilities in their software. That they only patch them reluctantly, and that they try and sit on it for as long as possible.
Nothing can be further from the truth. For Oracle, no more than one in four serious vulnerabilities were found by researchers and that number keeps dropping. We find most of them through running our own tests…we have our own ethical hacking team.
My job at Oracle is to make sure security is a product focus, and that we build secure products. We have [put in place] formal coding standards on risk-secure coding practices. My ethical hacking team developed this, and they know how things can be broken and how to write something such that they're secure-defensible. We're not just going to prove that a new [software] feature works properly, we're going to try and break it from a security standpoint. So if you're supposed to be entering a date as part of the input, we try entering data that it isn't expecting and see if it handles that gracefully.
We use our own software in the company. So if we don't do our job well, we'll be the first to suffer.
Previous
Did you find this article useful?
242 out of 428 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
