Open Source Challenges

Just like proprietary software, Open Source has plenty of plus and minus. The critics of the software coders often cite its broad development base and open source as a security risk. But that assessment is not fair, according to Dr Ian Levy, technical director of CESG, a division of the UK intelligence agency GCHQ, which advises the UK government on IT security.

Open source is no worse or better than proprietary software when it comes to security, according to Levy, who dismissed some open source security myths and spoke in detail about the real security challenges at the Open Source Open Standards conference. previously held in London.Open Source

Yesterday we mentioned myths about Open Source.

Today we will talk about the challenges:dr-ian-levy Open Source

Software distribution

The distribution methods used by many open source projects are vulnerable as genuine executables are replaced with knockoffs 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 are on the same server, and the distribution itself does not do it for me. Distribution has already taken place against distribution servers. No one touched the source code, but they touched the binary, MD5, SHA-1 and PGP code.

"You have downloaded the hash control, but you have the hash from the same position as the binary. Where is the trust? ”

Patching or repairs

The same question that applies to the source of the code also applies to open source software updates.

"If I use Windows Update, I know it's signed by a process that works within Microsoft. What can I know about Mint updates?

"What do I know about software coming from a 'secure' HTTP Server?"

Exploit visibility or Visible Exploits

“For Open source patches you should release the source code. So malicious they can inherently reveal the underlying problem. A binary patch released to fix a security vulnerability in a product can be used to reverse its functionality as well. 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, by the logic of continuous repair. Continuous repairs reduce the operating time of exploits. ”

Thus Open Source projects have individuals and groups that track active bugs in the code, which makes these potentially unpatched errors even more visible.

"Since they are open to everyone you can have zero day exploits because there is no patch."Open Source

Control of the supply chain of the code

"How do I know who wrote the code I use, how do I know what wrote it, and how do I know what else is there?" said Levy.

Commercial software modules can be checked by a legal team to determine that they comply with the license.

"How can I have the same reliability as free software? What can I say about its legality? How do I know if someone has reviewed the licenses of these software modules?

"I'm not saying you can't do it, I'm saying how to do it? It's a different set of challenges. "

Breaking up the Group

"Personality change can have a much greater impact on an open source product than it can on a commercial product. A commercial product has a brand value, while an open source product is driven by a group of people. I would like to hope that they are all aligned in some general terms but there have been and are ghettos in open source projects that are radically changing direction. ”

Relations of Developers

To be able to assess software security depends heavily on how much you know the developers and if you have some data on their future software plans, according to Levy.

"Security assessment is more relevant to developers than to source code," he said.

"Anyone who thinks that a security assessment requires checking every line of code to look for vulnerabilities is completely wrong. The development at the level we are talking about is that the developer knows what the others are doing, that there is a long-term plan for maintaining security and that there is an incident management plan.

"Designing the product architecture from code is incredibly difficult. If you have nothing to do with the developer ask: Why do you design it that way? "Continuing to grow is really difficult and often requires third parties."

Their identities they are generally non-existent

"For some projects the of the developer is a Gmail address. Who wants you 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.”

Lack of development of standardized and common security infrastructures

"I can check a company and say, 'Do you have these standards and apply them and yes you have incidents, but do you manage them well?'

How can we do this for a different set of developers on their own hardware?

iGuRu.gr The Best Technology Site in Greecefgns

every publication, directly to your inbox

Join the 2.100 registrants.

Written by giorgos

George still wonders what he's doing here ...

Leave a reply

Your email address is not published. Required fields are mentioned with *

Your message will not be published if:
1. Contains insulting, defamatory, racist, offensive or inappropriate comments.
2. Causes harm to minors.
3. It interferes with the privacy and individual and social rights of other users.
4. Advertises products or services or websites.
5. Contains personal information (address, phone, etc.).