Kysymys:
Avoimen lähdekoodin vs. suljetun lähdekoodin järjestelmät
blunders
2011-06-08 23:10:07 UTC
view on stackexchange narkive permalink

Ymmärrän, että avoimen lähdekoodin järjestelmien uskotaan yleisesti olevan turvallisempia kuin suljetun lähdekoodin järjestelmien.

Syyt joko lähestymistapaan tai Niiden yhdistelmään kuuluvat: kulttuurinormit, taloudellinen, oikeudellinen asema, kansallinen turvallisuus jne. - jotka kaikki liittyvät jollakin tavalla kulttuurin näkemykseen järjestelmän avoimen tai suljetun lähdekoodin vaikutuksesta.

Yksi keskeisistä huolenaiheista on turvallisuus. Yhteinen kanta avoimen lähdekoodin järjestelmiin on, että hyökkääjä saattaa hyödyntää järjestelmän heikkoutta, jos se tiedetään. Yhteinen kanta suljettujen lähdekoodien järjestelmiä vastaan ​​on, että tietoisuuden puute on parhaimmillaan heikko turvatoimenpide; kutsutaan yleisesti tietoturvaksi epäselvyydellä.

Kysymys on, ovatko avoimen lähdekoodin järjestelmät keskimäärin parempia tietoturvaa kuin suljettujen lähdekoodien järjestelmät? Jos mahdollista, mainitse analyysi mahdollisimman monilta toimialoilta, esimerkiksi: ohjelmistot, sotilaalliset, rahoitusmarkkinat jne.

Tämä kysymys oli Viikon tietoturvakysymys .
Lue 25.5.2012 blogimerkintä lisätietoja tai lähetä oma Viikon kysymys.

Ennen kuin vastaamme "kuinka turvallista tämä on", tarvitsemme mittausjärjestelmän. Kuinka mitataan haavoittuvuuksien määrää? Tämä on vaikeampi suljetun lähdekoodin kohdalla, minkä vuoksi ihmiset mielestäni usein ** tuntevat olonsa turvallisemmiksi avoimen lähdekoodin kanssa.
Kun näytät jollekulle, kuinka lukko tehdään, on vain ajan kysymys, ennen kuin hän lukitsee sen.
Seitsemän vastused:
#1
+50
Jesper M
2011-06-09 01:22:01 UTC
view on stackexchange narkive permalink

Ajatus siitä, että avoimen lähdekoodin ohjelmistot ovat luonnostaan ​​turvallisempia kuin suljetun lähdekoodin ohjelmistot - tai päinvastoin - on hölynpölyä. Ja kun ihmiset sanovat jotain sellaista, se on usein vain FUD eikä vie keskustelua mielekkäästi eteenpäin.

Tämän perustelemiseksi sinun on rajoitettava keskustelu tiettyyn projektiin. Ohjelmistopala, joka naarmuttaa tiettyä kutinaa, on tietyn tiimin luoma ja jolla on hyvin määritelty kohdeyleisö. Tällaisessa erityistapauksessa voi olla mahdollista pohtia, palvelevatko avoimen lähdekoodin vai suljetun lähdekoodin projektia parhaiten.

Ongelma kaikkien "avoimen lähdekoodin" ja kaikkien "suljetun lähdekoodin" toteutusten asettamisessa. ei ole vain verrata lisenssejä. Käytännössä avoimen lähdekoodin suosivat vapaaehtoistyöntekijät, ja suljettu lähde on yleisin kaupallisessa toiminnassa. Joten vertaamme itse asiassa:

  • lisenssejä.
  • pääsy lähdekoodiin.
  • hyvin erilaisia ​​ kannustinrakenteita, esimerkiksi -voitto vs. huvin vuoksi.
  • Hyvin erilaiset oikeudelliset vastuutilanteet.
  • Erilaiset ja vaihtelevat joukkuekoot ja joukkuetaidot.
  • jne.

Yritä arvioida, miten kaikki tämä toimii kaikkien avoimen tai suljetun lähdekoodin muodossa julkaistujen ohjelmistojen turvallisuuden kannalta. Siitä tulee mielipide, ei tosiasia.

Olen samaa mieltä. Tärkeintä on, kuinka moni tietoturva-alan osaamista ja kokemusta omaava henkilö suunnittelee, toteuttaa, testaa ja ylläpitää ohjelmistoa aktiivisesti. Kaikissa projekteissa, joissa kukaan ei katso turvallisuutta, on merkittäviä haavoittuvuuksia riippumatta siitä, kuinka monta ihmistä projektissa on.
Totta, mutta "pääsyn lähdekoodiin" antaminen on mahdollisesti erittäin arvokasta. Kun ulkopuoliset silmät katsovat koodiasi, saat uusia näkökulmia, jotka saattavat puuttua kehitystiimistä. Voisit jopa tehdä jotain, kuten https://stripe.com/blog/capture-the-flag, aidolla projektilla ja palkintoja parhaasta löydetystä virheestä (tietenkään julkaisematta yksityiskohtia ennen kuin korjaus on poissa!)
Heartbleed on hyvä esimerkki tästä. OpenSSL on ollut hyvä, avoin jo vuosia. Silti tämä valtava turva-aukko jäi havaitsematta ikuisesti.
@SameerAlibhai Mutta se havaittiin.Suljetun lähdekoodin ohjelmistoilla emme yksinkertaisesti tiedä, onko tällaisia virheitä.Heille on paljon vaikeampaa testata (vaikka voimme tehdä rajoitetun dynaamisen analyysin).Tällaisia vikoja voi esiintyä suosituissa suljetun lähdekoodin ohjelmistoissa, joilla on paljon suurempi taajuus ... tai ehkä ei.Emme vain tiedä.
Suljettu lähde ei tee mitään lieventääkseen loppukäyttäjien huolta mahdollisesta takaovesta, mikä on kelvollinen turvallisuusuhka.
Kannustimilla ei ole juurikaan tekemistä sen kanssa.Sanominen, että suljettu lähde on voittoa tavoitteleva ja avoimen lähdekoodin oma huvin vuoksi, ei ole vain harhaanjohtavaa, mutta suorastaan virheellistä.Täysin avoimen lähdekoodin yritys, Red Hat, on Fortune 500: ssa. Google työskentelee vahvasti avoimen lähdekoodin (esim. Chromium ja AOSP) kanssa, ja niitä käytetään miljardeja.
@Geremia Kuuluisa esimerkki myyjän asettamasta takaovesta olisi [Sony rootkit] (https://fi.wikipedia.org/wiki/Sony_rootkit).Joten IMO, se riippuu todella uhkamallista.Jos uhkamallisi sisältää suojautumisen myyjältä, FOSS on parempi valinta.
#2
+37
Thomas Pornin
2011-06-09 01:20:23 UTC
view on stackexchange narkive permalink

Ylläpidetty -ohjelmisto on turvallisempi kuin ei-ohjelmisto. Ylläpitovaatimukset ovat tietysti suhteessa mainitun ohjelmiston monimutkaisuuteen ja sitä katselevien ihmisten määrään (ja taitoihin). Avoimen lähdekoodin järjestelmien turvallisuuden teoria on, että lähdekoodia tarkastelevat "monet silmät". Mutta tämä riippuu melko paljon järjestelmän suosiosta.

Esimerkiksi vuonna 2008 löydettiin OpenSSL: stä useita puskurin ylivuotoja, joista osa johti koodin etäsuorittamiseen. Nämä viat olivat valehtaneet koodissa useita vuosia. Joten vaikka OpenSSL oli avoimen lähdekoodin ja sillä oli huomattava käyttäjäkunta (tämä on loppujen lopuksi HTTPS-verkkosivustojen pääasiallinen SSL-kirjasto), lähdekooditarkastajien lukumäärä ja taito eivät riitä voittamaan luontaista ASN.1-dekoodauksen (OpenSSL: n osa, jossa virheet piiloutuivat) ja OpenSSL-lähdekoodin (suoraan sanottuna tämä ei ole kaikkien aikojen luettavin C-lähdekoodi) monimutkaisuus.

Suljetuissa lähdekoodijärjestelmissä on, keskimäärin , paljon vähemmän ihmisiä tekemään Q&A: ta. Monissa suljetun lähdekoodin järjestelmissä on kuitenkin maksettuja kehittäjiä ja testaajia, jotka voivat sitoutua työhön kokopäiväisesti. Tämä ei ole oikeastaan ​​luontaista avoimelle / suljetulle kysymykselle; jotkut yritykset työllistävät ihmisiä avoimen lähdekoodin järjestelmien kehittämiseen, ja ajatellen voisi tuottaa suljetun lähdekoodin ohjelmistoja ilmaiseksi (tämä on suhteellisen yleistä Windows-ilmaisohjelmien tapauksessa). Palkkaisten testaajien ja suljetun lähdekoodin välillä on kuitenkin edelleen vahva korrelaatio (korrelaatio ei tarkoita syy-yhteyttä, mutta tämä ei tarkoita, että korrelaatiot tulisi myös jättää huomiotta).

Toisaalta oleminen suljetun lähdekoodin avulla on helpompaa salata tietoturvakysymyksiä, mikä on tietenkin huono .

On esimerkkejä sekä avoimista että suljetuista lähdekoodijärjestelmistä, joissa on paljon tai hyvin vähän tietoturvaongelmia. OpenSource-ohjelmiston * BSD-käyttöjärjestelmillä ( FreeBSD, NetBSD ja OpenBSD ja muutamilla muilla) on tietoturvan suhteen erittäin hyvä kokemus. Samoin kuin Solaris, vaikka se olisi suljetun lähdekoodin käyttöjärjestelmä. Toisaalta Windowsilla on (ollut) kauhea maine tässä asiassa.

Yhteenveto: Mielestäni "opensource implises security" -idee on yliarvostettu. Tärkeää on turvallisuuskysymysten seurantaan ja korjaamiseen varattu aika (ja taito), ja tämä on enimmäkseen kohtisuoraa lähteen avoimuutta koskevaan kysymykseen. Et kuitenkaan halua vain turvallista järjestelmää, vaan myös järjestelmän, jonka tiedät positiivisesti tiedät turvallisen (murtamattomuus on tärkeää, mutta voit nukkua yöllä myös). Tässä roolissa avoimen lähdekoodin järjestelmillä on pieni etu: on helpompaa olla vakuuttunut siitä, että järjestelmässä ei ole tarkoituksellisesti piilotettua suojausreikää, kun järjestelmä on avoimen lähdekoodin. Mutta luottamus on räikeä asia, kuten kävi ilmi viimeaikaisesta tragikomediasta väitetyn OpenBSD: n takaovien ympärillä (sikäli kuin tiedän, se osoittautui punaiseksi silliksi, mutta käsitteellisesti en voi olla varma, ellet tarkista koodia itse).

Tietenkin kuinka tärkeä turvallisuus on ohjelmiston ylläpitäjälle, on kriittinen. Se voidaan ylläpitää käytettävyyden kannalta ylläpitämättä turvallisuutta.
+1 huoltokysymyksen nostamiseksi. Myös "tarpeeksi silmämunien" teoria (tunnetaan myös nimellä Linuksen laki) riippuu suuresti siitä, onko sinulla * koulutettuja * silmämunia - ja mitä tulee hienovaraisiin turvallisuusvirheisiin, niitä on paljon vähemmän.
#3
+17
user2213
2011-06-09 03:22:09 UTC
view on stackexchange narkive permalink

Mielestäni helpoin ja yksinkertaisin valinta tähän on ohjelmistosuunnittelu. Argumentti seuraa yleensä: avoimen lähdekoodin ohjelmisto on turvallisempi, koska voit nähdä lähteen !

Onko sinulla ohjelmistotekniikan osaamista ytimen ymmärtämiseksi ylhäältä alas? Toki, voit katsoa tällaista kuljettajaa, mutta onko sinulla täydelliset tiedot siitä, mitä tapahtuu, jotta todella sanoisit "kyllä, siellä täytyy olla vika"?

Tässä on mielenkiintoinen esimerkki: ei niin kauan sitten yhdessä beta-ytimessä ilmestyi tyhjä osoittimen poikkeamavirhe, joka oli melko iso juttu, jonka kaveri löysi grsecurity-palvelusta (PaX-korjaustiedostot):

Se otettiin käyttöön tällaisella koodilla:

  pointer = struct->otherptr; jos (osoitin == NULL) {/ * virheenkäsittely * /} / * -koodi jatkuu, viitaten siihen osoittimeen, joka optimoidun tarkistuksen yhteydessä voi olla NULL. Ongelma. * /  

ja kääntäjä optimoi pointer == NULL -tarkistuksen oikein - koska nollaosoittinta ei voida viitata jäseniä sisältävään rakenteeseen, se ei ole mitään järkeä funktion osoittimen olevan koskaan tyhjä. Kääntäjä poistaa sitten tarkistuksen, jonka kehittäjän odotetaan olevan siellä.

Ergo, vis vis, vastaavasti, niin suuren projektin lähdekoodi saattaa hyvinkin näyttää oikealta - mutta ei oikeastaan ​​ole.

Ongelma on tässä tarvittava tietotaso. Paitsi että sinun on oltava melko perehtynyt (tässä tapauksessa) C: hen, kokoonpanoon, tiettyyn ytimen alijärjestelmään, kaikkeen ytimien kehittämiseen liittyvään, sinun on myös ymmärrettävä, mitä kääntäjäsi tekee.

Älä ymmärrä minua väärin, olen samaa mieltä Linusin kanssa siitä, että kaikki viat ovat matalat riittävällä silmällä. Ongelma on tieto aivoissa silmien takana. Jos maksat 30 whiz lapselle kehittääksesi tuotteesi, mutta avoimen lähdekoodin projektissasi on vain 5 henkilöä, joilla on todellinen tieto koodipohjasta, niin suljetun lähdekoodin versiossa on todennäköisempää vähemmän virheitä olettaen suhteellisen samanlainen monimutkaisuus .

Tämä on selvää myös jokaiselle projektille, joka on ohimenevä ajan myötä, kuten Thomas Pornin kertoo.

Päivitä muokattu poistamaan viitteet gcc: n virheellisyyteen, koska se ei ollut.

+1, olen aina ehdottanut muutosta Linuksen lakiin: "Kun otetaan huomioon tarpeeksi * koulutettuja * silmämunia, useimmat viat ovat suhteellisen matalia".
from isc.sans.edu/diary.html?storyid=6820 "Toisin sanoen kääntäjä tuo binäärikoodiin haavoittuvuuden, jota ei ollut lähdekoodissa." tämä on räikeästi absurdi merkityksetön lausunto. ** Lähdekoodi on buginen, joten se on haavoittuva. ** Tapa, jolla kääntäjä tuottaa koodin, määrittää, mitkä hyödyntämismahdollisuudet ovat mahdollisia.
Okei reilu, olet oikeassa, olin väärässä - hän viittaa `` tuntiin '', kun `` tun '' voi olla `` NULL '' - mikä on suorastaan ​​huono asia. Ymmärrän kyllä. Poistan viittauksen loukkaavaan gcc-vaihtoehtoon, koska se ei ollut ongelma. Loppuosa esimerkistä on esimerkkinä hyvä.
Jos tuijotat koodinäytettä ja ihmettelet, miten se on koodausvirhe, älä tuhlaa aikaa.Koodinäyte on hajotettu eikä se vastaa todellista koodia.Muokkaukseni hylättiin, koska "Tämä muokkaus poikkeaa viestin alkuperäisestä tarkoituksesta."Luulen, että alkuperäinen tarkoitus on sekoittaa.
#4
+13
Ori
2011-06-12 06:27:34 UTC
view on stackexchange narkive permalink

Mielestäni tilat, joita käytetään eniten suljetun ja avoimen lähdekoodin erottamiseen, on melko hyvin määritelty. Monet näistä on lueteltu tässä, molemmilla on puolisonsa. Ei ole yllättävää, että suljetun lähteen kannattajat ovat niitä, jotka myyvät sitä. Avoimen lähdekoodin kannattajat ovat myös tehneet siitä mukavan ja siistin yrityksen (muutaman ulkopuolella, jotka ovat ottaneet sen uskonnoksi.)

Pro Open Source -liike puhuu perusasioista ja tietoturva yleensä tässä ovat ne kohdat, jotka sopivat keskusteluun eniten:

  1. Mukautus-lähtökohta
  2. Lisenssien hallinnan lähtökohta
  3. Avoin muoto -teema
  4. Monien silmien lähtökohta
  5. Pikakorjauksen lähtökohta

Joten hajottamalla tämän lähtökohdalla, mielestäni kaksi viimeistä on käsitelty melko ytimekkäästi muiden täällä, joten jätän heidät yksin.

  1. Räätälöintiprosessi
    Turvallisuuden osalta Räätälöintiprosessi antaa yrityksille, jotka ottavat ohjelmiston käyttöön, mahdollisuuden rakentaa ylimääräisiä suojauksen hallinta olemassa olevalle alustalle tarvitsematta hankkia lisenssiä tai vakuuttaa myyjää korjaamaan jotain heidän omastaan. Se antaa organisaatioille, jotka tarvitsevat tai näkevät aukon, lisätä tuotteen yleistä turvallisuutta. SELinux on täydellinen esimerkki, voit kiittää NSA: ta sen palauttamisesta yhteisölle.

  2. Lisenssinhallinnan lähtökohta
    Usein tuodaan esiin, että jos käytät F / OSS-tekniikoita, sinun ei tarvitse hallita tekniikan lisenssejä kolmansien osapuolten kanssa (tai jos teet niin, on paljon vähemmän), ja tämä voi päteä täysin avoimen lähdekoodin ekosysteemeihin. Mutta monet lisenssit (erityisesti GPL) asettavat vaatimuksia jakelijoille, ja useimmat todellisessa ympäristössä ovat heterogeenisiä sekoituksia suljetuista ja avoimen lähdekoodin tekniikoista. Joten vaikka se lopulta vähentää ohjelmistokustannuksia, lähteen saatavuus voi johtaa siihen, että jotkut yritykset rikkovat OSS-lisenssejä pitämällä lähteen yksityisenä, kun heillä on velvollisuus vapauttaa lähde. Tämä voi lopulta muuttaa lisenssinhallinnan lähtökohdaksi vastuun (joka on suljetun lähdekoodin argumentti vastaan ​​ lisenssejä, kuten GPL.)

  3. Avomuotoinen tila
    Tämä on iso, ja olen yleensä samaa mieltä, joten pidän sen lyhyenä, jotta en saarnaisi. 30 vuoden päästä haluan pystyä avaamaan kirjoittamani tiedoston. Jos tiedosto on "suojattu" omilla DRM-ohjaimilla ja tarvitsemaani ohjelmistoa ei enää myydä, vaikeudet oman sisällön käytössä ovat lisääntyneet dramaattisesti. Jos asiakirjani luomiseen on käytetty muotoa, joka on avoin ja saatavana 30 vuoden takaisessa avoimen lähdekoodin tuotteessa, pystyn todennäköisesti löytämään sen ja pystyn laillisesti käyttämään sitä. Jotkut yritykset hyppäävät "Open Formats" -bändivaunuun hyppäämättä avoimen lähdekoodin vankkurille, joten tämä väite on mielestäni melko järkevä.

On kuudes oletus, jota en listannut, koska siitä ei keskustella hyvin. Minulla on taipumus juuttua siihen (kutsumme sitä vainoharhaisuudeksi). Luulen, että kuudes lähtökohta on höyhen puolustusministeriöiden korkissa ympäri maailmaa. Se kerrottiin maailmalle, kun osa Windows 2000 -lähteestä vuotaa.

Suljetun lähteen vastuun lähtökohta
Jos yritys on tuottanut suljetun lähdekoodin kirjastoa tai sovellusliittymää useiden julkaisujen kautta vuosikymmenien ajan, pienillä ihmisryhmillä on ollut pääsy kyseiseen lähteeseen koko tuotannossaan. Jotkut näistä ovat kolmannen osapuolen tarkastusryhmiä ja kehittäjiä, jotka ovat siirtyneet muihin yrityksiin / hallituksiin. Jos kyseinen koodi on riittävän staattinen, yhteensopivuuden ylläpitämiseksi, kuten suljetun lähdekoodin etu on, jotkut heikkoudet voivat jäädä ilmoittamatta monien vuosien ajan. Niillä, joilla on pääsy suljettuun lähdekoodiin, on vapaus käyttää koodianalyysityökaluja sitä vastaan ​​tutkiakseen näitä heikkouksia. Näiden ohjelmistokehityskeskusten virhevarastot ovat täynnä "pieniä" virheitä, jotka voivat johtaa hyödyntämiseen. Kaikki nämä tiedot ovat monien sisäisten henkilöiden käytettävissä.

Hyökkääjät tietävät tämän ja haluavat nämä tiedot itselleen. Tämä asettaa jättimäisen tavoitteen yrityksesi sisäiselle infrastruktuurille, jos olet yksi näistä kaupoista. Kehitysprosesseistasi tulee nykyisin tietoturvavastuu. Jos yrityksesi on riittävän suuri ja koodipohjasi on jaettu riittävän hyvin, voit olla jopa kohde ihmisten soluttautumiselle. Tässä vaiheessa Charlie Miller -tekniikka: lahjoita kehittäjälle tarpeeksi rahaa ja hän kirjoittaa sinulle huomaamattoman virheen, josta tulee erillinen mahdollisuus.

Tämä ei tarkoita, ettei se pääse OSS-tuotteisiin samalla tavalla. Se tarkoittaa vain sitä, että sinulla on joukko tietoja, ja vapautettuasi ne voivat paljastaa heikkouksia asennuskannassasi. Yksityisyyden pitäminen on luonut koodausvelan asiakkaidesi asennettuihin järjestelmiin, joita et voi maksaa takaisin heti.

+1 @Ori: Tiedätkö OSS: istä, joilla oli löytynyt takaovi ja joka oli selvästi suunniteltu yhdeksi? Charlie Miller on myös se, joka tarkoittaa wikipedia-sivua tai jotain vastaavaa.
Hän on "turvallisuustutkija", joka on kuuluisa Pwn2Own-hyväksikäytöistään. Hän mainitsee koodauksen hyödyntämisen inhimillisen elementin Defcon 2010 -puheessaan, joka on tarpeeksi humoristinen katsomaan sitä yksin. http://www.youtube.com/watch?v=8AB3NcCkGNQ
+1 @Ori: Ah, ajattelin, että tarkoitit ehkä ostettua, sitten löydettyä "Charlie Milleria". Ihmisten hyväksikäyttö ei ole mitään uutta, joten sen kutsuminen "Charlie Miller -tekniikaksi" saattaa olla joustavaa. Tiedätkö OSS: stä, jolla oli löytynyt takaovi ja joka oli selvästi suunniteltu sellaiseksi?
@blunders Mikään sellainen ei ole tunnistettu ja julkistettu. Voisin mennä kaivamaan joitain yksityiskohtia, mutta hyvin suunnitellun "virheen" ongelmana on, ettei onnettomuuden ja tahallisen sijoittamisen pitäisi olla helppoa erottaa toisistaan.
@Ori: Olen samaa mieltä, ja ihmettelin vain, jos tiesit sellaisia ​​jo, sinun ei tarvitse etsiä sellaista. Kiitos!
@blunders-väitteet lentivät tässä tapauksessa, mutta näyttävät minusta epäilyttäviltä: [Mikä on väitetyn OpenBSD IPSEC -hyökkäyksen mahdollinen vaikutus? - IT-turvallisuus] (http://security.stackexchange.com/questions/1166/what-is-the-potential-impact-of-the-alleged-openbsd-ipsec-attack)
@blunders, kuten @nealmcb mainitsi, OpenBSD: n IPSecin väitetty "hyökkäys" oli epäilyttävä, mutta epäilyttävä, mutta mielikuvituksen ulottumattomissa, ja sen uskottiin pitävän paikkansa lyhyen aikaa. Lisäksi alkuperäinen "rootkit" oli avoimen lähdekoodin paketissa ja suosittu siinä (http://fi.wikipedia.org/wiki/Rootkit#History). Täten takaovet OSS: ssä ovat selvä mahdollisuus.
@Ori,, jota kutsut "Charlie Miller -tekniikaksi", on paljon paremmin tunnistettu "[Kevin Mitnick] (http://en.wikipedia.org/wiki/Kevin_Mitnick) -tekniikaksi".
@Ori, sinun 3. pisteesi - avoimen muodon lähtökohta - vaikka se onkin hyvä asia, ei välttämättä ole pelkästään F / OSS-ohjelmiston etu. Todellakin, viimeinen lausuntosi kyseisessä kappaleessa on ristiriidassa muun kanssa: "" Jotkut yritykset hyppäävät "Open Formats" -vankkuriin hyppäämättä avoimen lähdekoodin vankkureille ", mikä osoittaa, että sillä ei ole merkitystä. (Tosin joissakin mielissä näin ei ole, mutta se ei ole totta.)
@AvID Olen lukenut Kevinin kirjoittamat kirjat, tutkinut hänen väitettyjä tekojaan, ja kuulin Charlien sanovan (lähinnä) "Tässä on kasa kassaa, koodaa minulle takaovi" oli minulle ensimmäinen. Luulen, että voit kutsua sitä käteisrahaksi tai vastaavaksi, jotta se olisi puolueeton.
@Avid avoimen muodon taistelua taistelevat suurelta osin samat ihmiset, en yritä esittää argumenttia omana, vain että se esitetään usein avoimen lähdekoodin argumenttina. Olen täysin samaa mieltä siitä, että myös suljetut ja avoimen lähdekoodin puolustajat ovat irrottaneet tuotannosta ja hyväksyneet sen.
#5
+3
Bruce Ediger
2012-06-27 22:24:39 UTC
view on stackexchange narkive permalink

Haluat tarkastella näitä asiakirjoja:

Tulos on, että avoin tai suljettu on suunnilleen vastaava riippuen siitä, miten paljon testejä tehdään heille. Ja "testaamalla" en tarkoita sitä, mitä keskimääräinen yrityksesi drone-testaajasi tekee, vaan pikemminkin kuin kenttäkokemuksessa.

#6
  0
knocte
2016-04-12 15:59:35 UTC
view on stackexchange narkive permalink

Olkaamme rehellisiä, kun joku väittää avoimen lähdekoodin olevan turvallisempaa kuin suljettu lähdekoodi, hän yleistää palvelimen / työpöydän käyttöjärjestelmissä, kuten Linuxissa (avoin lähdekoodissa) tai Macissa / Windowsissa (oma, suljettu lähdekoodi), mitä tapahtuu tänään. ).

Miksi haittaohjelmat vaikuttavat todennäköisemmin jälkimmäiseen eikä ensimmäiseen? Useista syistä, joista mielestäni tärkein on ensimmäinen (lainattu tältä vastaukselta kysymykseen, joka on merkitty tämän kopiona):

  1. Käyttäjän asentama ohjelmisto Linux-jakelun (tai muun avoimen lähdekoodin käyttöjärjestelmän) tapauksessa on pakattu keskitetyn organisaation toimesta (ts. Ubuntun tapauksessa sen tekee Canonical ja isännöi sitä) se), joka isännöi binäärejä, jotka on koottu avoimen lähdekoodin yhteisön kuratoimista / valvomista lähteistä. Tämä tarkoittaa, että tartunnan saaneiden ohjelmistojen asentavan käyttäjän todennäköisyys tai haittaohjelmakoodimuutoksia hyväksyvän avoimen lähdekoodin yhteisön todennäköisyys on paljon pienempi kuin Mac- / Windows-käyttöjärjestelmissä, joissa käyttäjä yleensä asentaa ohjelmistoja monista eri paikoista verkossa tai useilta eri toimittajilta AppStoresilta. On myös riski, että organisaation palvelimet (esim. Canonical) hakkeroidaan, mutta tämä riski on pieni, koska nämä organisaatiot palvelevat huipputason IT-asiantuntijoita palvelimiensa ylläpitoon.
  2. Linuxin (tai muut avoimen lähdekoodin käyttöjärjestelmät) käyttäjien määrä on paljon pienempi kuin Windows / Mac-käyttäjien , joten haittaohjelmien luojat eivät halua kohdistaa heitä (koska hyöty / kustannussuhde on tässä tapauksessa pienempi).
  3. Linux on vain ydin, saatavana useina eri jakeluina, joista voit valita , joten haittaohjelmien luojien olisi käytettävä enemmän vaivaa, jotta haittaohjelmakoodinsa olisi yhteensopiva monien kanssa (joten hyöty / kustannussuhde on pienempi tässä tapauksessa).
  4. Linuxin (tai muiden avoimen lähdekoodin käyttöjärjestelmien) lähteet ovat kaikkien nähtävissä / muokattavissa. Tämä tarkoittaa, että kun tietoturva-aukko löytyy, kuka tahansa voi kirjoittaa siihen korjauksen (toimittajan lukitusta ei ole, et ole sidottu tiettyyn organisaatioon, jota sinun on odotettava, jotta voit kehittää korjauksen), joten teoriassa tietoturvakorjaukset tapahtuvat nopeammin kuin patentoitujen ohjelmistojen tapauksessa. (Käytännössä ei kuitenkaan yleensä ole eroa, koska yritykset, jotka ylläpitävät omia alustoja, kuten Windows ja MacOS, ovat suuryrityksiä, jotka satunnaisesti ovat riittävän päteviä.)
#7
  0
Geremia
2016-09-13 04:55:43 UTC
view on stackexchange narkive permalink

Jim Fruchtermanin OpenSource.com-artikkeli " Onko avoimen lähdekoodin tietoturvaohjelmisto vähemmän turvallinen?" antaa erittäin hyvän analogian siitä, kuinka avoimen lähdekoodin avulla ohjelmisto on turvallisempi huolimatta siitä, että hyökkääjät tietävät, miten se toimii. loppukäyttäjät:

Ajattele salausta lukittuna yhdistelmänä, joka on turvallinen tietojesi kannalta. Saatat olla ainoa, jolla on yhdistelmä, tai voit antaa sen valita muutama läheinen kumppani. Tallelokeron tavoitteena on estää luvattomia ihmisiä pääsemästä käsiksi sen sisältöön. He voivat olla murtovarkaita, jotka yrittävät varastaa arvokasta yritystietoa, työntekijät, jotka yrittävät oppia luottamuksellisia palkkatietoja ikäisistään, tai petos, joka haluaa saada luottamuksellisia tietoja huijauksen tekemiseksi. Kaikissa tapauksissa haluat, että kassakaappi pitää tavarasi turvassa ja estää luvattomat ihmiset.

Oletetaan, että valitsen kassakaapin arvoesineilleni. Valitsenko Safe Number One -lehden, jolla on puolen tuuman terässeinät, tuuman paksuinen ovi, kuusi lukitusruuvia ja riippumaton virasto on testannut sen varmistamiseksi, että sisältö säilyy kahden tunnin ajan tulipalossa? Vai valitsenko kassanumeron kaksi, kassakaappi myyjä yksinkertaisesti sanoo luottavansa, koska kassakaapin suunnittelun yksityiskohdat ovat liikesalaisuus? Se voi olla turvallinen numero kaksi on valmistettu vanerista ja ohuesta metallilevystä. Tai voi olla, että se on vahvempi kuin Safe Number One, mutta asia on se, että minulla ei ole aavistustakaan.

Kuvittele, että sinulla on turvallisen numero yksi -asiakirjan yksityiskohtaiset suunnitelmat ja tekniset tiedot, jotka riittävät rakentamaan tarkka kopion kassakaapista, jos sinulla on oikeat materiaalit ja työkalut. Tekeekö se turvallista numero yhtä vähemmän turvallista? Ei, se ei. Safe Number One -turvallisuus perustuu kahteen suojaan: suunnittelun vahvuuteen ja vaikeuteen arvata yhdistelmääni. Yksityiskohtaisten suunnitelmien saaminen auttaa minua tai turvallisia asiantuntijoita määrittämään, kuinka hyvä suunnittelu on. Se auttaa varmistamaan, että kassakaapissa ei ole suunnitteluvikoja tai toista "takaoven" yhdistelmää kuin oma valitsemani yhdistelmä, joka avaa kassakaapin. Muista, että hyvä turvallinen muotoilu antaa käyttäjälle mahdollisuuden valita oma yhdistelmänsä satunnaisesti. Suunnittelun tuntemisen ei pitäisi ollenkaan auttaa hyökkääjää arvaamaan tietyn kassakaapin satunnainen yhdistelmä kyseisen mallin avulla.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...