Before going that far, we need a more effective way to get the vendors to care.
Symantec could have chosen to ship only the minimal filesystem interface code in the kernel and run the huge, complex inspection code in an isolated low-privilege thread, just like the Windows NT guides recommended in 1993.
Symantec could have performed basic diligence and updated their dependencies when security updates were released.
Symantec could have followed recommended practice for code auditing, fuzzing, etc.
In each case they chose not to spend the money it'd take to be minimally competent, correctly realizing that most of their customers will never check and are unlikely to change their buying habits. Based on my experience running their enterprise management tools and dealing with their support, I'm pretty sure someone just made the business decision not to spend the money because most of their customers have audit requirements to buy something and nobody else in the industry is significantly better.
If they had done things the way you say, their price point would have been higher, while everyone else who didn't do it is lower.
I've been in many budget meetings where Product X does A, and Product Y does A too. Both products let you put a check in the audit box. Product Y is 20% cheaper than Product X. Without a glaring fault in Product Y, nobody will spend the extra money for Product X.
The audit question is often worded: Is a centrally managed antivirus product installed on every PC? Are the definitions for the product kept up-to-date? Good! Pay us for verifying that(among other similarly useless questions) and here's your SAS70/SSAE16/SOC1 papers.
Customer says "are you audited? can I see your papers? Good. " -- due diligence is considered done.
The people performing the audits rarely have a clue other than knowing that there's supposed to be a check in that box.
It's all a game of CYA and security theater, with very little real security being practiced.
> If they had done things the way you say, their price point would have been higher, while everyone else who didn't do it is lower.
This statement is too strong unless they're currently running on a razor-thin profit margin and have cut every other possible source of waste in the company. We're talking about a company with 6+ billion dollars in revenue hiring a modest number of good security engineers – even if they paid them twice the industry rate, it seems unlikely that it'd need to affect the price at all, especially when you consider the long-term reduction in emergency patch releases.
You're right that it's usually theater but consider how different it could be if security really was top priority. A major vendor could turn it into a selling point by publicizing the spotlight on gaps in audit standards. All they'd need would be one big shift – finance, health care, .gov, etc. – and it'd suddenly be a selling point for them for a product release cycle in addition to being the right thing to do for their customers.
> This statement is too strong unless they're currently running on a razor-thin profit margin and have cut every other possible source of waste in the company.
These days, Profit margins tend to be maximised. If they can make a little more profit by cutting a little more corners, they will probably do it. It takes some ethics not to maximize profits at the expense of everything else.
If you want better security, you'll have to find a way to make it more profitable for them —if not as an individual, as a community, or even as a society. If better products aren't more profitable, you'll inevitably end up with lemons.
The other path, questioning the profits paradigm altogether, is not easy.
Agreed - I don't know whether that will be insurance requirements, regulators, etc. but we have little reason to think simple market forces will work better in the future.
Their response is very lack luster as well. I work in a enterprise environment where they run Symantec. I found out about this massive vulnerability though hacker news. No email from them, nothing. Go to their website now, not a mention of "Hey, you have to update right this second" just marketing speak about how they are the best. Mark my words somebody is going to worm this and it's going to be bad.
The ASPack emulator that was vulnerable was one of the few not inside of a virtual machine, hence why this overflow could be easily used to get code execution.
Have you heard any sign of them making a big push to clean up their legacy code similar to what Microsoft did with their Trustworthy Computing effort? I know Symantec employs good people so I've been assuming that the problem is getting time dedicated to something which doesn't deliver a new feature or marketing bullet-point.
Symantec could have chosen to ship only the minimal filesystem interface code in the kernel and run the huge, complex inspection code in an isolated low-privilege thread, just like the Windows NT guides recommended in 1993.
Symantec could have performed basic diligence and updated their dependencies when security updates were released.
Symantec could have followed recommended practice for code auditing, fuzzing, etc.
In each case they chose not to spend the money it'd take to be minimally competent, correctly realizing that most of their customers will never check and are unlikely to change their buying habits. Based on my experience running their enterprise management tools and dealing with their support, I'm pretty sure someone just made the business decision not to spend the money because most of their customers have audit requirements to buy something and nobody else in the industry is significantly better.