How To Argue That Open Source Software Is Secure?
Smidge207 writes "Lately there has been a huge push by Certified Microsoft Professionals and their companies to call (potential) clients and warn them of the dangers of open source. This week I received calls from four different customers saying that they were warned that they are dangerously insecure because they run open source operating systems or software, because 'anyone can read the code and hack you with ease.' Other colleagues in the area also have noticed that three local Microsoft Partners have been trying to strike fear in the minds of companies that respond, 'Yes, we use open source or Linux' when the sales call comes in. I know this is simply a sales tactic by these companies, but how do I fix the damage these tactics cause? I have several customers who now want more than my word about the security of systems that have worked for them flawlessly for 5-6 years, with minimal expense outside of upgrades and patching for security. Does anyone have a good plan or sources of reliable information that can be used to inform the customer?"
How about telling them that Microsoft has taken code from open-source operating systems like BSD (true) and people have discovered bugs which had been fixed long ago in the open-source versions, and missed in the closed-source versions BECAUSE they were closed-source?
Open source is verifiable. Closed source is not.
Open source is verified, by many people, who discuss it in public. Closed source is not.
Show them how quickly discovered vulnerabilities are patched and how much discussion each bug receives. Ask the competitors to provide access to their discussion groups and bug logs. Compare. Contrast.
I'd put the emphasis on 'Compare'.
Print two lists. One containing all the critical vulnerabilities that have been reported in the last twelve months, along with numbers of exploited machines worlwide. The other will be a list of how many of these vulnerabilities have affected your supported machines.
If you've been doing your job well, the second list will be a blank page.
Crumb's Corollary: Never bring a knife to a bun fight.
I don't think they are aiming to battle on the concept of 'security' but rather the easily exploitable human characteristics of fear and susceptibility. This is, to a knowledgeable person, an obvious attempt at spreading rumor/mudslinging to create a widescale negative buzz among the weeble peoples.
I also heard Obama is a Muslim?
Tell your customers that Microsoft is trying to sell them stuff. It has nothing to do with open source vs.closed source, just money.
Disagree. Security is not a static rating but a process; part of that process is fixing found problems. Guess which is easier to fix: the stuff you've got the source to, or the stuff you have to wait 6 months before the vendor acknowledges as flawed.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Don't discuss the attack, that's just playing into the hand they gave you.
What I would point out is the monthly patch cycle you buy into with MS.
Any vendor worth using releases patches as vulnerabilities are discovered, keeping software safe. MS doesn't do this, and claims it as a feature.
The rest of the world releases patches as soon as someone with eyes sees a flaw. This is a clear advantage and negates all the FUD you are seeing.
I wonder if that's because suddenly companies are trying to save money by moving to open source software? And this is a pre-emptive response by the people who have the most to lose?
"I think it would be a good idea" Gandhi, on Western Civilisation
I watched a "How's it Made" episode on combination locks. Knowing how a lock is made, didn't make it any easier to break into one. If the code is made correctly, the passwords can't just be bypassed. You can't just change the code and load it in for a fun filled night of hacking any more than you can with a closed source OS. That's how I'd explain it to a customer.
You don't "argue" security--you test security. Offer your clients periodic penetration tests as a routine part of your service.
You must stress that being able to _read_ the code is not the same as being able to _write to the released codebase_. This is an assumption I have encountered again and again and again.
The evil thing is, people don't ask about this, they assume it's fact and that's that.
"We" need to make sure this myth dies.