Just like proprietary software, Open Source has plenty of pros and cons. Critics of open source software often say that its broad development base and open source code are a security risk. But that assessment is unfair, according to Dr Ian Levy, technical director of CESG, a division of the UK's intelligence agency GCHQ, which advises the British government on IT security.
Open source is no worse or better than proprietary software when it comes to security, according to Levy, who debunked some open source security myths and spoke in detail about the real security challenges at the Open Source, Open Standards conference held earlier in London.
Yesterday we mentioned the myths about Open Source.
Today we will talk about the challenges:
Software distribution
The online distribution methods used by many open source projects are vulnerable as genuine executable files are replaced with counterfeit products containing malicious code, Dr Ian Levy said at the same conference.
“How do I get confirmation for the online distribution, because a SHA-1 hash and a PGP key exist on the same server, and the distribution itself doesn’t do it for me. There have been attacks on distribution servers before. No one touched the source code, but they touched the binary, the MD5, the SHA-1, and the PGP code.
“You downloaded the hash check, but you got the hash from the same place you got the binary. Where is the trust?”
Patching or repairs
The same question that applies to the origin of code applies to updates to open source software.
"If I use Windows Update, I know it's signed by a process that works inside Microsoft. What can I know about Mint updates?"
“What can I know about software coming from a “secure” HTTP Server?”
Exploit visibility or Visible Exploits
“For Open source patches you have to release the source code. This allows malicious users to inherently reveal the underlying problem. A binary patch released to fix a security vulnerability in a product can be used to reverse engineer it. In open source, the source code of the patch is available and shows the attacker exactly where the problem is.
“This is not necessarily a bad thing, in the sense of continuous patching. Continuous patches reduce the time it takes for exploits to run.”
So open source projects have people and teams tracking active bugs in the code, which makes these potentially unpatched bugs even more visible.
“Since it's open to everyone you can have zero day exploits because there's no patch.”
Code supply chain control
“How do I know who wrote the code I'm using, how do I know what they wrote, and how do I know what else is out there?” Levy said.
Commercial software modules can be reviewed by a legal team to ensure they comply with the license.
"How can I have the same credibility as free software? What can I say about its legality? How can I know that someone has reviewed the licenses of these software modules?"
"I'm not saying you can't do it, I'm saying how do we do it? It's a different set of challenges."
Splitting the Group
“Changing the personality can have a much bigger impact on an open source product than it can on a commercial product. A commercial product has a brand value, whereas an open source product is driven by a group of people. I would like to hope that they are all aligned on some broad lines but there have been and are ghettos in open source projects, that radically change direction.”
Developer Relations
Being able to assess software security depends largely on how well you know the developers and whether you have any information about their future plans for the software, according to Levy.
"Security assessment is more about the relationship that developers have and not the source code," he said.
“Anyone who thinks that a security assessment requires checking every line of code for vulnerabilities is absolutely wrong. The evolution at the level we are talking about is for the developer to know what the others are doing, to have a long-term plan for maintaining security, and to have an incident management plan.
“Designing the architecture of the product from the code is incredibly difficult. If you don’t have a relationship with the developer, ask: Why are you designing it this way? Continuity of development is really difficult and often requires third parties.”
Developer identities are generally non-existent
“For some projects the developer identity is a Gmail address. Who wants to bet their security on someone’s Gmail account? There are other ways to authenticate developers, but they are things we need to think about.”
The lack of development of standardized and common security infrastructures
“I can audit a company and say: ‘You have these standards and you are implementing them and yes you have incidents, but are you managing them well?’”
How can we do this for a diverse set of developers on their own hardware?
