They could start with learning how to code securely, it’s not a mystery.

As well, having a constant security testing cycle in the SDLC helps considerably.

Lastly, hiring outside companies to perform full penetration and exploit tests against the codebase prior to it’s release would also help.

But this would cut into the bottom line, and keep the board from receiving their extra .01% of share value.

No, no, can’t have that….

Pluheeze… I say make the software / vendor legally responsible for their code. That should shake things up a bit.

Like or Dislike: 0  0

I applaud you for your efforts. It sounds as though you’re trying to fight to retain the position of Sisyphus. You’re pushing that boulder uphill, and making progress with a FEW customers.

What about all of the vendors out there who will not responsibly review their own software/hardware/appliances before shipping them to the general IT Public? Who’s being irresponsible?

I’m 100% in favor of full and open disclosure, just as I am about finding out about tainted food.

Using your argument, I “should” go and sell my services testing everyone’s beef/chicken/pork in their home for contaminants before they eat it.

I say fix the problem at the source. Throw these lazy and self-righteous vendors under the bus.

Once the news gets out that your personal data has been released overseas due to a vendor who didn’t even test their own software, people will begin voting with their money.

It’s time to clean the IT Gene pool.

Like or Dislike: 0  0

Like or Dislike: 0  0

Like or Dislike: 0  0

Does anyone doubt that this is common in for-profit companies? There are only a few things that will cause companies to change were they draw the line between spending time and effort enhancing security vs. time-to-market + profits: 1) Bad press. Bad for business, bad for stock price. 2) Regulation. Most companies, if reluctantly, obey the law at least partly because failing to do so violates #1. 3) Customers and sales. If customers told companies they wanted better security in their products, they might get it, or if lots of people tell companies that they aren’t buying a product because it’s not secure, then it might have an effect. But people ask for product features and ASSume that it’s secure, so this virtually doesn’t happen in practice.

In the early days of cellphones, cloning was quoted as causing billions of dollars of lost revenue. The dirty little secret was that most of that “lost revenue” was calls that wouldn’t have ever been made if the caller had had to pay for them, and until the “real losses” caused by denying access to paying customers got big enough, the carriers really didn’t care enough to pay for fixing it. Fast-forward to the credit card industry now: As long as they can charge people 30% annual interest, why worry about a few percent of that being spent on fraud? Or to the Microsoft’s of the world: as long as people buy their software, and have to pay for upgrades to get higher security going forward, then full-steam-ahead on features, and minimum spending on improving security. As long as companies are making a profit, and especially if they can make their customers pay for the fixes to their mistakes, they have little incentive to fix their problems.

I don’t particularly like the idea of being hit by a 0day because my daily-use software is buggy, but my guess is that, statistically, early disclosure is likely to reduce the long-term damage caused by a 0day exploit more than it increases it (though it will do both) because it gets it out in front of the software vendor and the detection vendors without back-room rigamarole.

Like or Dislike: 0  0

Like or Dislike: 0  0

Like or Dislike: 0  1

Like or Dislike: 0  0

Like or Dislike: 0  1

Like or Dislike: 0  0