"Open source te onveilig voor zakelijk gebruik"
Open source software is niet veilig genoeg om binnen bedrijven gebruikt te worden, dat concludeert security consultant Larry Suto die in onderzoek van beveiligingsbedrijf Fortify een onderzoek uitvoerde. "De meest gebruikte open source software pakketten voor bedrijven stellen gebruikers bloot aan behoorlijke en onnodige zakelijke risico's," zo waarschuwt het bedrijf, dat verder opmerkt dat de open source gemeenschap gebruikers geen security expertise biedt om deze beveiligingsrisico's en kwetsbaarheden weg te nemen.
Doordat security processen ontbreken zorgt dit voor een groeiend aantal beveiligingsproblemen binnen open-source producten. Bedrijven en overheden die voor open-source kiezen moeten daarom voor gebruik eerst risico analyses uitvoeren en de code uitgebreid controleren.
Volgens Fortify voldoet open source ontwikkeling niet aan de beveiligingsstandaarden die bedrijven stellen. Dit neemt tevens verborgen kosten met zich mee, omdat er ook op security bugs gezocht moet worden. "Open source pakketten beweren dat ze over 'enterprise-class' eigenschappen beschikken, maar gebruiken niet eens, of overwegen zelfs, om industrie best-security practices te volgen. Ernstige beveilgingsdreigingen die uit talloze applicatielekken afkomstig zijn, zijn een direct gevolg van de slechte of niet-bestaande security processen," zo is in het rapport te lezen.
Reacties (23)
Security processen worden gemeten aan de hand van drie parameters,
waarvan onderstaande twee wel iets duidelijk maken;
"a dedicated email alias for users to report security vulnerabilities, or easy
access to internal security experts to discuss security issues."
Het eerste stelt een eis dat er voor 'security' bugs een ander mailadres is. Nu
is dit een eis van niks, en is ook zo geregeld. Maar als meetpunt is het wel
helder. Maar wat is de toegevoegde waarde van een apart mail adres - een
bug is een bug en is een stabiliteitsissue minder erg dan een security issue.
En wat is eigenlijk een security issue? Een meetpunt van niets dus,.
De tweede is nog mooier: easy acces tot een 'interne' medewerker is vereist.
Tja, als je security niet als een separaat feestje definieert (nogmaals: een bug
is een bug), dan heb je dat niet. Bovendien: In een community, wat is intern?
Ergo: Fortify vind een boel bugs met hun eigen toolie en 'meet' verondersteld
noodzakelijke security processen tegen een kromme meetlat en trekt dan
voornoemde conclusies. Nu ja, hun toolie zal wel fantastable zijn, hun hype is
met dank aan security.nl weer geslaagd.
Beetje jammer.
waarvan onderstaande twee wel iets duidelijk maken;
"a dedicated email alias for users to report security vulnerabilities, or easy
access to internal security experts to discuss security issues."
Het eerste stelt een eis dat er voor 'security' bugs een ander mailadres is. Nu
is dit een eis van niks, en is ook zo geregeld. Maar als meetpunt is het wel
helder. Maar wat is de toegevoegde waarde van een apart mail adres - een
bug is een bug en is een stabiliteitsissue minder erg dan een security issue.
En wat is eigenlijk een security issue? Een meetpunt van niets dus,.
De tweede is nog mooier: easy acces tot een 'interne' medewerker is vereist.
Tja, als je security niet als een separaat feestje definieert (nogmaals: een bug
is een bug), dan heb je dat niet. Bovendien: In een community, wat is intern?
Ergo: Fortify vind een boel bugs met hun eigen toolie en 'meet' verondersteld
noodzakelijke security processen tegen een kromme meetlat en trekt dan
voornoemde conclusies. Nu ja, hun toolie zal wel fantastable zijn, hun hype is
met dank aan security.nl weer geslaagd.
Beetje jammer.
ja want propietary pakketten hebben stuk voor stuk een
uitmuntende reputatie op het gebied van veiligheid.
uitmuntende reputatie op het gebied van veiligheid.
Alsof veiligheid afhangt van de vraag of een pakket open danwel closed
source is.
Windows is dus "veilig", want windows is closed source, en openBSD
is "onveilig", want openbsd is open source ?
source is.
Windows is dus "veilig", want windows is closed source, en openBSD
is "onveilig", want openbsd is open source ?
Ah ja, en dankzij al die processen die voornamelijk veel papierzooi opleveren
en er voor zorgt dat mensen ingedekt zijn als het fout gaat ("was niet mijn
schuld") produceert de closed-source industrie nooit software met security
bugs. Klinkt als iemand die met z'n dure certificeringen geen geld kan
verdienen met open source software en het daarom maar afkraakt.
en er voor zorgt dat mensen ingedekt zijn als het fout gaat ("was niet mijn
schuld") produceert de closed-source industrie nooit software met security
bugs. Klinkt als iemand die met z'n dure certificeringen geen geld kan
verdienen met open source software en het daarom maar afkraakt.
22-07-2008, 13:11 door
Nomen Nescio
Door Anoniem
Alsof veiligheid afhangt van de vraag of een pakket open danwel closed
source is.
Windows is dus "veilig", want windows is closed source, en
openBSD
is "onveilig", want openbsd is open source ?
En waar lees je dat dan?Alsof veiligheid afhangt van de vraag of een pakket open danwel closed
source is.
Windows is dus "veilig", want windows is closed source, en
openBSD
is "onveilig", want openbsd is open source ?
22-07-2008, 13:23 door
SirDice
Er is alleen naar Java application servers en aanverwante zaken gekeken.
Door SirDice
Er is alleen naar Java application servers en aanverwante
zaken gekeken.
Er is alleen naar Java application servers en aanverwante
zaken gekeken.
Is JBOSS met support van Red Hat dan niet nog steeds de
beste oplossing?
22-07-2008, 13:35 door
Jachra
Door Anoniem
Security processen worden gemeten aan de hand van drie parameters, waarvan onderstaande twee wel iets duidelijk maken;
"a dedicated email alias for users to report security vulnerabilities, or easy access to internal security experts to discuss security issues."
Het eerste stelt een eis dat er voor 'security' bugs een ander mailadres is. Nu is dit een eis van niks, en is ook zo geregeld. Maar als meetpunt is het wel helder. Maar wat is de toegevoegde waarde van een apart mail adres - een bug is een bug en is een stabiliteitsissue minder erg dan een security issue.
En wat is eigenlijk een security issue? Een meetpunt van niets dus,.
Security processen worden gemeten aan de hand van drie parameters, waarvan onderstaande twee wel iets duidelijk maken;
"a dedicated email alias for users to report security vulnerabilities, or easy access to internal security experts to discuss security issues."
Het eerste stelt een eis dat er voor 'security' bugs een ander mailadres is. Nu is dit een eis van niks, en is ook zo geregeld. Maar als meetpunt is het wel helder. Maar wat is de toegevoegde waarde van een apart mail adres - een bug is een bug en is een stabiliteitsissue minder erg dan een security issue.
En wat is eigenlijk een security issue? Een meetpunt van niets dus,.
Een bug is een bug, maar sommige bugs zijn vele malen belangrijker.
Dus zal je voor sommige bugs iets meer moeten doen en beter werk afleveren. Het hebben van een email-adres om security gerelateerde bugs aan te melden is handiger dan ze op een of andere forum of buglists te moeten posten.
De tweede is nog mooier: easy acces tot een 'interne' medewerker is vereist. Tja, als je security niet als een separaat feestje definieert (nogmaals: een bug is een bug), dan heb je dat niet. Bovendien: In een community, wat is intern?
Een bug is een bug, maar sommige bugs zijn vele malen belangrijker.
Bij de community kan je intern zien als de core-developer(s). In het geval van de Linux-kernel kan je dan denken aan Alan Cox of Linus Torvald.
De pakketten waar ze gedetailleerde gegevens van laten zien
vertonen nogal een variatie in de hoeveelheid bugs per kilo
lines of code, een factor 650 tussen de slechtste en de
beste. In de tekst wordt echter alles over een kam
geschoren: open source doet het niet goed.
Met dermate grote verschillen kan je dat moeilijk zo
ongenuanceerd brengen en verwachten dat je serieus wordt
genomen, wat mij betreft.
vertonen nogal een variatie in de hoeveelheid bugs per kilo
lines of code, een factor 650 tussen de slechtste en de
beste. In de tekst wordt echter alles over een kam
geschoren: open source doet het niet goed.
Met dermate grote verschillen kan je dat moeilijk zo
ongenuanceerd brengen en verwachten dat je serieus wordt
genomen, wat mij betreft.
Er wordt in het artikel enkel gekeken naar Java application servers en
aanverwante zaken zoals SirDice al opmerkt. Daarnaast wordt er geen
vergelijk gemaakt met vergelijkbare closed source projecten/producten. Er is
wel een vegelijking van A met B maar van B worden geen cijfers gegeven.
Blijkbaar wil Fortify graag zijn product verkopen aan open source projecten.
Interesant detail dat niet meegenomen wordt in het rapport is dat ongeveer de
helft van de projecten onder apache vallen.
aanverwante zaken zoals SirDice al opmerkt. Daarnaast wordt er geen
vergelijk gemaakt met vergelijkbare closed source projecten/producten. Er is
wel een vegelijking van A met B maar van B worden geen cijfers gegeven.
Blijkbaar wil Fortify graag zijn product verkopen aan open source projecten.
Interesant detail dat niet meegenomen wordt in het rapport is dat ongeveer de
helft van de projecten onder apache vallen.
Few open source projects provide documentation that
covers the security implications and secure deployment of
the software they develop
Raar, maar op websites en in veel readme's en overige
documentatie vind ik juist veel waarschuwingen over
veiligheidsaspecten van bijvoorbeeld bepaalde instellingen.
En b.v. ook in de help van b.v. menuconfig bij het aanpassen
van de linux-kernel.
... a dedicated email alias for users to report security
vulnerabilities, or easy access to internal security experts
to discuss security issues ...
Zoals de 1e anoniem al zei, voegt dit weinig toe aan de
veiligheid. Bovendien kan je altijd bugs en security issues
melden op de websites van de diverse producten.
The continued presence of a large number of security
issues not only represents an immediate security risk, it
also demonstrates that the projects have not adopted a
successful secure development process.
Net als Micro$oft kijkt de beste man alleen naar aantallen
fouten. Een fout die een junior consultant al niet meer mag
maken lijkt me.
Om nou op een paar producten uitspraken te baseren die dan
voor alle open source zouden gelden, lijkt mij niet erg
wetenschappelijk. Suto slaat m.i. de plank dan ook volledig
mis en ik hoop voor de Fortune 500 companies dat ze niet
alleen op zijn oordeel afgaan.
Suto lijkt mij een Amerikaanse Frits Bom. Een ordinaire
broodschrijver die onzin verkoopt met een mooi
pseudo-wetenschappelijk sausje.
Nomen Nescio heeft er vermoedelijk weer een held bij.
covers the security implications and secure deployment of
the software they develop
Raar, maar op websites en in veel readme's en overige
documentatie vind ik juist veel waarschuwingen over
veiligheidsaspecten van bijvoorbeeld bepaalde instellingen.
En b.v. ook in de help van b.v. menuconfig bij het aanpassen
van de linux-kernel.
... a dedicated email alias for users to report security
vulnerabilities, or easy access to internal security experts
to discuss security issues ...
Zoals de 1e anoniem al zei, voegt dit weinig toe aan de
veiligheid. Bovendien kan je altijd bugs en security issues
melden op de websites van de diverse producten.
The continued presence of a large number of security
issues not only represents an immediate security risk, it
also demonstrates that the projects have not adopted a
successful secure development process.
Net als Micro$oft kijkt de beste man alleen naar aantallen
fouten. Een fout die een junior consultant al niet meer mag
maken lijkt me.
Om nou op een paar producten uitspraken te baseren die dan
voor alle open source zouden gelden, lijkt mij niet erg
wetenschappelijk. Suto slaat m.i. de plank dan ook volledig
mis en ik hoop voor de Fortune 500 companies dat ze niet
alleen op zijn oordeel afgaan.
Suto lijkt mij een Amerikaanse Frits Bom. Een ordinaire
broodschrijver die onzin verkoopt met een mooi
pseudo-wetenschappelijk sausje.
Nomen Nescio heeft er vermoedelijk weer een held bij.
ik denk dat ie bedoelt dat je bij open source zelf onderzoek
moet doen (door het lezen van de documentatie, en de
readme's), terwijl je bij propietary oplossingen alleen maar
in de white paper hoeft te kijken. Als er daar staat dat het
allemaal heel veilig is is het alvast niet meer jouw schuld.
moet doen (door het lezen van de documentatie, en de
readme's), terwijl je bij propietary oplossingen alleen maar
in de white paper hoeft te kijken. Als er daar staat dat het
allemaal heel veilig is is het alvast niet meer jouw schuld.
22-07-2008, 15:23 door
Eerde
Een groot nadeel van open source is dat een kop als:
"Open source te onveilig voor zakelijk gebruik"
niet zal leiden tot een aanklacht wegens smaad of laster :(
22-07-2008, 15:26 door
Eerde
Precies een jaar geleden...
Red Hat Linux gets top government security rating
Last week IBM was able to achieve EAL4 Augmented with ALC_FLR.3
certification for Red Hat Enterprise Linux, putting it on a par with Sun
Microsystems' Trusted Solaris operating system, said Dan Frye, vice
president of open systems with IBM.
According to Frye, the certification is "big news for the Linux industry"
because it shows that open source software can be used for sensitive
computing tasks. "If anyone had any doubts that you could do this with
an open source operating system, we've proved them wrong."
Bron: http://www.infoworld.com/article/07/06/15/red-hat-linux-gets-top-Last week IBM was able to achieve EAL4 Augmented with ALC_FLR.3
certification for Red Hat Enterprise Linux, putting it on a par with Sun
Microsystems' Trusted Solaris operating system, said Dan Frye, vice
president of open systems with IBM.
According to Frye, the certification is "big news for the Linux industry"
because it shows that open source software can be used for sensitive
computing tasks. "If anyone had any doubts that you could do this with
an open source operating system, we've proved them wrong."
22-07-2008, 17:40 door
SirDice
Linux heeft niets met dit "onderzoek" te maken, dat is totaal niet aan de orde..
Lees die PDF maar eens, kijk even naar tabel 1. Daar staan de pakketten die bekeken zijn. De uitspraak dat "open source te onveilig voor zakelijk gebruik" is is volledig uit z'n context gerukt. Het kopt lekker maar dekt de lading van het onderzoek totaal niet.
Lees die PDF maar eens, kijk even naar tabel 1. Daar staan de pakketten die bekeken zijn. De uitspraak dat "open source te onveilig voor zakelijk gebruik" is is volledig uit z'n context gerukt. Het kopt lekker maar dekt de lading van het onderzoek totaal niet.
22-07-2008, 17:59 door
Eerde
Dice
Dat is ook precies wat ik duidelijk probeer te maken voor de begrijpende
lezert.
Overigens is GNU/Linux open source dus die opmerking dat het er niets
me te maken heeft slaat nergens op, net als de kop boven het artikel.
Stelliger als men aan open source denkt, denkt men aan GNU/Linux.
De kop is dan ook niet: "Open source op MS windows groot gevaar
voor veiligheid !"
En ja, ik heb die .pdf gedowload en gelezen !
Dat is ook precies wat ik duidelijk probeer te maken voor de begrijpende
lezert.
Overigens is GNU/Linux open source dus die opmerking dat het er niets
me te maken heeft slaat nergens op, net als de kop boven het artikel.
Stelliger als men aan open source denkt, denkt men aan GNU/Linux.
De kop is dan ook niet: "Open source op MS windows groot gevaar
voor veiligheid !"
En ja, ik heb die .pdf gedowload en gelezen !
22-07-2008, 18:40 door
spatieman
die man is zeker pro windows.........
22-07-2008, 18:50 door
Eerde
Een fiks aantal gestiekte $$$ doet wonderen...
Ik verdoe mijn tijd liever niet aan het lezen van blabla. Goed, heel even dan: het
ziet eruit dat dit een man-met-een-tool onderzoek is:
1. Laat tool los.
2. Afschuwelijk veel fouten gevonden
3. Geteste software is slecht en Fortify heeft ons behoed voor een natuurramp!
Het gaat mis bij #1, want kennis van "wat bennik hier aan het doen?" is niet
inbegrepen. Wordt duidelijk bij #2, want context wordt niet bekeken. Over de
conclusie hoeven we het verder niet meer te hebben.
Op mijn code laat ik regelmatig tooltjes los, inclusief "slimme" compilers.
>99% van de meeste issues zijn te verklaren door het gebrek aan diepgang.
Zo wordt een functie strcpy al bij voorbaat afgekeurd want gevaarlijk. Als je niet
weet hoe je het moet gebruiken is het inderdaad gevaarlijk. Dat geldt toevallig
ook voor tools als Fortify.
ziet eruit dat dit een man-met-een-tool onderzoek is:
1. Laat tool los.
2. Afschuwelijk veel fouten gevonden
3. Geteste software is slecht en Fortify heeft ons behoed voor een natuurramp!
Het gaat mis bij #1, want kennis van "wat bennik hier aan het doen?" is niet
inbegrepen. Wordt duidelijk bij #2, want context wordt niet bekeken. Over de
conclusie hoeven we het verder niet meer te hebben.
Op mijn code laat ik regelmatig tooltjes los, inclusief "slimme" compilers.
>99% van de meeste issues zijn te verklaren door het gebrek aan diepgang.
Zo wordt een functie strcpy al bij voorbaat afgekeurd want gevaarlijk. Als je niet
weet hoe je het moet gebruiken is het inderdaad gevaarlijk. Dat geldt toevallig
ook voor tools als Fortify.
22-07-2008, 20:59 door
Nomen Nescio
Door spatieman
die man is zeker pro windows.........
Jij bent in ieder geval anti-windows...die man is zeker pro windows.........
23-07-2008, 11:53 door
[Account Verwijderd]
[Verwijderd]
Door Nomen Nescio
Door spatieman
die man is zeker pro windows.........
Jij bent in ieder geval anti-windows...die man is zeker pro windows.........
*zucht* altijd maar die eindeloze en toch ook wel kansloze discussie over
windows en linux. Ik ben opzich wel blij met windows want voor mij zorgt het
voor eten op de plank maar dat wil niet zeggen dat ik er altijd even blij mee ben
Inderdaad. Dit hele onderzoek snijdt totaal geen hout.
Business, Open Source communities, Security Best Practices worden hier
allemaal ongestructureerd door elkaar gehaald.
Daarnaast is Open Source een software licentie model, niets meer, niets
minder. Dit betekent dat iedereen het kan gebruiken, Einstein tot
boerenpummel.
Dus de conclusie van dit onderzoek kan ook zijn dat "Er meer regen in het
noorden valt"
Business, Open Source communities, Security Best Practices worden hier
allemaal ongestructureerd door elkaar gehaald.
Daarnaast is Open Source een software licentie model, niets meer, niets
minder. Dit betekent dat iedereen het kan gebruiken, Einstein tot
boerenpummel.
Dus de conclusie van dit onderzoek kan ook zijn dat "Er meer regen in het
noorden valt"
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
