Thinking of Security Vulnerabilities As Defects

SecureThroughObscure writes "ZDNet Zero-Day blogger Nate McFeters has asked the question, 'Should vulnerabilities be treated as defects?' McFeters claims that if vulnerabilities were treated as product defects, companies would have an effective way of forcing developers and business units to focus on security issue. McFeters suggests providing bonuses for good developers, and taking away from bonuses for those that can't keep up. It's an interesting approach that if used, might force companies to take a stronger stance on security related issues."

Comments

Re:Of course vulnerabilities are defects

[kesuki]

but then what do you call design features like windows networking telling you if you got the first letter of your password right, even without the rest of the password, and then letting you do that for the next letter, and so on and so on.

it was a feature of early windows networking, to do just that! like people might 'forget' their password, so they would 'need' a feature that would tell them letter by letter, if they were getting warmer on remembering the password! hackers had a FIELD day with various 'features' of Microsoft products.

Edward Deming would disagree

[stephanruby]

ZDNet Zero-Day blogger Nate McFeters has asked the question, 'Should vulnerabilities be treated as defects?' McFeters claims that if vulnerabilities were treated as product defects, companies would have an effective way of forcing developers and business units to focus on security issue. McFeters suggests providing bonuses for good developers, and taking away from bonuses for those that can't keep up. It's an interesting approach that if used, might force companies to take a stronger stance on security related issues.

When I think of defects and total quality management, I think of Edward Demings.

Edward Demings saw the problem of defects as a systems issue, not an individual performance issue. And his theory was that paying someone based on performance would have the unintended consequence of increasing the number of defects, not decrease them (Here is the list of Deming's 14 principles with my emphasis added in bold).

Deming offered fourteen key principles for management for transforming business effectiveness. The points were first presented in his book Out of the Crisis (p. 23-24)[19].

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.
2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease cost.
6. Institute training on the job.
7. Institute leadership (see Point 12 and Ch. 8 of "Out of the Crisis"). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
8. Drive out fear, so that everyone may work effectively for the company. (See Ch. 3 of "Out of the Crisis")
9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
11. a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
    b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
12. a. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
    b. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective (See CH. 3 of "Out of the Crisis").
13. Institute a vigorous program of education and self-improvement.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's work.

Re:No. They'd get sued

[nine-times]

The article (at least in my reading) isn't saying that they should be held legally accountable as selling a defective product. Instead it's about how companies should approach a bug report of a vulnerability. He's saying, when someone reports a vulnerability, consider it something that you're obligated to fix, not as a feature request.

But then, I think most people do. It seems like he hit a bad support person.

I ran into a similar problem once with Citrix, actually. Their software was relying on some library that it assumed was installed, even though recent Linux releases (at the time) had stopped using that library. The result was that the software didn't work until you tracked down that library, dropped it in the right place, and then it worked fine.

So I went to their website to give feedback, just to let them know. I mean, I'm sure they would have figured it out, but I thought, "may as well give them a heads up" because it was happening on major linux distros almost a year after their release. Citrix had released several updates to their software, and never fixed this problem. I couldn't find anyplace on their website to provide feedback, except for a form to give feedback about the website itself.

So I wrote up a little feedback, trying to explain the situation briefly (i.e. "I wanted to drop some feedback to your development team letting them know there's a problem, how to fix it, but I can't find any contact information on your website. Is there any way to submit this sort of feedback). The response came back quickly, "If you want support, you'll have to pay for a support contract."

I wrote back again, trying to explain, "No, see, I'm not looking for help, I'm trying to be helpful. I'm letting you know that there's a problem I already know how to fix. I was just wondering if there was a place to submit this sort of feedback."

Again, the response came in, "I'm sorry sir, but if you want us to help you with this problem, you'll need to buy our support contract."

At that point, I gave up.

Re:Of course vulnerabilities are defects

[kesuki]

keep in mind the original RFC for SMB file sharing had nothing about encrypting the password, networks were new, the internet non existent, we're talking 1979 or earlier here... the original windows SMB filesharing was over netbios, not even over tcp/ip (because windows had no tcp/ip stack) so having SMB tell you each letter of the password was individually correct was more along the lines of 'routers' coming with the default password of 'admin' before they're configured or if they're manually reset...

it seems too boneheaded to be true, but SMB was started early in the windows 3 days, when 640k was still enough for most people.

Re:Of course vulnerabilities are defects

[Nullav]

The reality is that CHMOD is a basic form of DRM.

I must say, my keyboard would be absolutely soaked if I was drinking something right now. My maildirs and private keys? Not yours and I'm not setting public read. httpd.conf? Sure, I'll set public read and owner write so you can look at it and even copy it for non-disruptive editing for whatever reasons. It's also worth noting that a lot of 'users' don't even have people behind them on a typical home system.
It would be DRM if RO access meant you couldn't edit the copy. Moreover, all current incarnations of DRM would try to get in the way of copying files in the first place (usually by having the file behave differently on other systems). DRM is for enforcing artificial scarcity, permissions are for keeping systems intact and protecting private information on shared systems. I suppose you're going to call passwords DRM, too?

I'm not really in disagreement with the post as a whole, but the first paragraph really made me cringe.