Tärkeää on huolto . Riippumatta siitä, oletko käyttänyt uudestaan ​​olemassa olevaa koodia vai kirjoittanut oman, saavutat kunnollisen turvallisuuden vain, jos jonnekin on joku, joka ymmärtää koodin ja pystyy pitämään sen yllä esimerkiksi kääntäjien ja alustojen kehityksen suhteen. Koodin saaminen ilman vikoja on parasta, mutta käytännössä sinun on luotettava seuraavaan parhaisiin asioihin, ts. Vikojen nopeaan korjaamiseen (etenkin virheelliseen käyttöön hyödynnettävissä oleviin virheisiin, jotka tunnetaan myös nimellä haavoittuvuudet ) lyhyt ajanjakso.

Jos kirjoitat oman koodisi, huoltotyö riippuu täysin omista harteistasi. Ja tämä työ voi olla erittäin aikaa vievää. Jos esimerkiksi päätät kirjoittaa ja ylläpitää omaa SSL / TLS-kirjastoa ja käyttää sitä tuotannossa, sinun on ymmärrettävä kaikki salauksen toteutuksen erityispiirteet, erityisesti vastustuskyky sivukanavan hyökkäyksille ja sinun on pidettävä silmällä julkaistuja hyökkäyksiä ja vastatoimia. Jos sinulla on siihen resursseja sekä ajallisesti että pätevyydeltään, niin hieno! Ylläpitokustannuksia ei kuitenkaan pidä aliarvioida. Olemassa olevan kirjaston, varsinkin laajasti käytetyn avoimen lähdekoodin, uudelleenkäyttö voi olla pitkällä tähtäimellä melko edullista, koska ylläpitoa tekevät muut ihmiset, ja laaja käyttö takaa ulkoisen valvonnan. Bonuksena on, että sinua ei voida syyttää ulkoisen kirjaston tietoturva-aukoista, jos puolet maailmasta jakaa ne.

Yhteenvetona voidaan todeta, että kysymys ei ole oikeastaan ​​ koodin uudelleenkäytöstä, mutta ylläpitotoimien uudelleenkäytöstä.

(Kirjoitan kaiken tämän riippumatta oman koodisi kirjoittamisen suurista pedagogisista ominaisuuksista. Kehotan teitä tekemään omat toteutuksenne - mutta ei varmasti niiden tosiasiallisesta käytöstä tuotannossa. Tämä on tarkoitettu oppimiseen .)

Vielä enemmän.

Suojakoodi on hankala . Salauskoodi on suorastaan ​​ kova , vaikka olisitkin koulutettu kryptografi - ja mahdotonta saada oikeaksi, jos et ole.

Jos niin monissa tärkeissä ohjelmistopaketeissa ja yrityksissä on niin paljon kriittisiä virheitä - mikä saa sinut ajattelemaan *, että pystyt tekemään parempaa työtä?

_{* Ellei tietenkään tämä ole sinun erityisosaamisalueesi, ja tietoturvaominaisuudet ovat ydin tuotteellesi ...}

Mielenkiintoinen kysymys! Haluaisin vastata siihen enemmän todennäköisyyden kuin parhaiden nykyisten käytäntöjen näkökulmasta.

Vaikka Thomas ja muut tarjoavat hyviä vastauksia, en usko, että he koskettavat ydinkysymystä - mikä on "ainutlaatuista" (tai vähemmän käytetty) koodi on joustavampi käytännössä kuin suosittu koodi ". Huomaa, että en ole tarkoituksella käyttänyt "turvallisempaa kuin suosittua koodia". Ja mitä tämä kiehuu, on erityistapaus "toimiikö turvallisuus epäselvyyksien kautta"?

Ja (ja tiedän, että tämä ei tule olemaan suosittu vastaus) Luulen, että kun korvataan "turvallinen" sanalla "joustava", vastausta ei välttämättä aina hyväksytä yleisesti "ei koskaan!"

Vaikuttaa siltä, ​​että se on todennäköisesti vähemmän turvallinen (eli on hyvin todennäköistä, että oma turvakoodisi on helpompi / nopeampi murtaa kuin suosittu, joka oli aiemmin käynyt läpi useita hyökkäyksiä ja jonka älykkäämpiä ihmisiä kuin sinä).

Joten jos kysymys ei ole "mikä on turvallisempi", mutta "joka on vähemmän todennäköisesti murtunut", vastaus saattaa olla "se riippuu". Tässä on muutama esimerkki:

Esimerkki 1: Kuvittele Microsoft Windows 8.1 (tai mikä tahansa nykyään suosittu) tietokone, jossa ei tällä hetkellä ole tunnettuja tietoturva-aukkoja, ostettu mutta ei koskaan päivitetty ja kytketty Internetiin. Kuvittele myös vuosikymmenien vanha Windows 3.11, jossa on Winsock, jota ei ole koskaan korjattu, tunnettujen satojen suojausreikien kanssa, joka on kytketty Internetiin. Molempia käytetään samalla tavalla. Ohita keskustelun pääsyn laadun vuoksi ... Kysymys on, mihin hajotetaan aikaisemmin?

Vaikka on ilmeistä, että 3.11 on paljon vähemmän turvallinen, siihen kohdistuvassa villissä on tuskin mitään hyökkäyksiä. . Joten voi hyvinkin olla, että 8.1: n kohdalla olisi massiivisesti suosittua 0 päivän hyväksikäyttöä, ennen kuin 3.11 osuu jokin arkaainen hyväksikäyttö, joka onnistuu suorittamaan sitä. Kuvittele, että sinulla on uusin Joomla CMS yhdessä verkkopalvelimessa, jossa ei ole tunnettuja nykyisiä hyödyntämistoimia, ja käsintehty perl-komentosarja, joka tekee CMS: n kaltaisia ​​asioita tunnetuilla hyödynnettävissä olevilla virheillä (mutta mikään niistä ei ole epäilyttävä tällä hetkellä käytettävissä oleville automaattisille testeille). Kummalla on vuoden kuluttua suuremmat mahdollisuudet hyödyntää sitä?

Vaikka anekdootteja todisteita onkin ollut, muutamassa kymmenessä (satoihin) tapauksiin, joita minulla on ollut viime vuosikymmeninä, suurin osa tapauksista oli suosittuja ohjelmistoa hyödynnettiin, kun taas vanhentuneet jatkavat häiriötöntä toimintaa tähän päivään asti.

Muita huomioitavia asioita:

• jos suosittu ohjelmisto päivittää automaattisesti (tai jos järjestelmänvalvojat päivittävät AINA nopeasti), niin suosittujen koodien heikkoudet vähenevät huomattavasti (mutta niitä ei poisteta 0 päivän ja julkaisemattomien hyödykkeiden takia), ja sillä on siten suuri etu
• päinvastoin, jos ohjelmisto ei saa ylläpitoa, ei-suosittu (kuten itse kirjoittama) saattaa olla epäilevämpi ongelmista
• syyttää - suosittujen ohjelmistojen käyttö voi olla usein edullista. Jos se vaikuttaa puoleen maailmaan, et saa melkein yhtä paljon syytä kuin jos olisit yksin ohjelmoija. Tämä on erityisen tärkeää, jos työskentelet rahalla. Usein on "parempi" olla vähemmän turvallinen, mutta pystyä siirtämään syyllisyys kuin olemaan turvallisempi, mutta sinun on kannettava kustannukset itse, kun hyödyntäminen osuu.
• työ - toiset mainitsevat, suosittu ohjelmisto korjaa valtaosassa tapauksia, sinun tarvitsee vain päivittää - mikä on paljon vähemmän työtä kuin itse löytää ja korjata vikoja (mutta vaatii silti jonkin verran ylläpitoa)
• toinen Itse kirjoittamien ohjelmistojen etu on usein massakoodien vähentäminen (mikä johtaa vähemmän virheitä), koska et yleensä tarvitse suurinta osaa ominaisuuksista tai muokattavuudesta. Esimerkiksi ihmiset käyttävät Joomlaa, vaikka he tarvitsevat vain yksinkertaisen "malliuutissivuston", joka käytännössä voitaisiin saavuttaa muutamalla kymmenellä koodirivillä. Vaikka et ohjelmoijana olisikaan puoliksi yhtä hyvä kuin saavutetut, jotka työskentelevät suosittujen ohjelmistojen parissa (joten virheitä on huomattavasti enemmän koodiriviä kohden), voit usein voittaa suurella marginaalilla johtuen suuruusluokasta ( tai vähän!) vähemmän koodia kirjoitettavaksi / ylläpidettäväksi

Yksinkertainen vastaus on: älä heitä omaa suojaustasi.

Tässä on kaksi osaa. Algoritmi ja toteutus.

Mitä tulee algoritmiin, oman salausalgoritmin luominen on kauheaa. Vaikka olisit perehtynyt salauksen alaan, et silti pysty luomaan uutta algoritmia. Ellei sinulla ole alan asiantuntijoiden tiimiä, et kehitä omaa algoritmiasi. Voit ajaa kotiin tässä vaiheessa katsomalla joitain viimeaikaisia ​​algoritmeja, jotka on murtunut ja miten ne on murtunut. Sillä, mikä nimellisarvoltaan näyttää hyvältä, on heikkouksia, joita en olisi koskaan ajatellut.

Toteutuksen osalta oman algoritmin oman toteutuksen luominen ei ole yhtä kauheaa kuin oman algoritmin luominen, mutta ellet ole ammattilainen siinä, älä tee sitä. Yksi virhe toteutuksessa, eikä sillä ole väliä kuinka hyvä ydinalgoritmi oli. Tässä tapauksessa sinun on esitettävä kysymys, oletko parempi kuin monet asiantuntijat, jotka työskentelivät kootakseen huipputason tietoturvakirjaston.

Mikä on todennäköisempää. Voitko kääntää oman algoritmin ja toteutuksen ilman virheitä tai heikkouksia tai että käyttämällesi algoritmille ja toteutukselle asetetaan takaovi?

Jos voisit luoda täydellisen algoritmin toteutuksella, riski takaoven ovi ei olisi ongelma. Mutta se ei ole realistista.

On myös kysymys, jonka haluat selittää esimiehellesi / osakkeenomistajillesi /? Se, että luotettuun ohjelmistopakettiin on asennettu takaovi, jossa koko ala toimii, tai että henkilökohtainen yrityksesi parantaa tietoturvaa epäonnistui kauheasti. Henkilökohtaisesti haluaisin selittää mieluummin, että tein valinnan, jonka ammattilaiset tekivät koko toimialalta, ja ainoa syy, miksi se epäonnistui, oli jokin massiivinen asia, joka vaikuttaa jopa monikansallisiin yrityksiin.

Olen kuitenkin samaa mieltä Thomasin kanssa siitä, että yrittää tehdä se itse on hyvä oppimiskokemus, kunhan se ei koskaan näe tuotannon valoa.

Suojausta ei välttämättä paranneta yksinkertaisesti, jos koodi kootaan hieman erilaisiksi ohjeiksi. Suojaus on:

1. algoritmi
2. toteutus
3. tarkastus
4. ylläpito

jos et kirjoita parempia, turvallisempia algoritmeja - mikä voi viedä vuosia tutkimusta - etkä tarkista koodiasi ja korjaa sitä vastaavasti, yksinkertaisesti hieman erilainen toteutus ei todennäköisesti tee sinusta turvallista.

Heartbleed, Shellshock, BEAST, POODLE ja muita viimeisiä useita merkittäviä SSL / TLS-ongelmia on esiintynyt CRC: n ja itseohjaavien algoritmien luonteenomaisten ongelmien ja kokeneiden kooditarkastusten puutteen vuoksi, ei johtuen käyttöönottoon.

Jos et oikein ymmärrä, kuinka ne epäonnistuivat, sinun ehdottomasti ei pitäisi kirjoittaa omaa turvakoodiasi. Lisää enemmän ongelmia kuin ratkaiset.