Meillä oli 2 koodianalysaattoria, 4 dynaamista testaustyökalua, omat käsityömme ja 250 skriptiä. Ei sillä, että tätä kaikkea tarvittiin nykyisessä prosessissa, mutta kun aloitit DevSecOpsin käyttöönoton, sinun on mentävä loppuun.
. Justin Roilandin ja Dan Harmonin luomat hahmot.
Mikä SecDevOps on? Entä DevSecOps? Mitkä ovat erot? Sovellusturvallisuus – mistä on kyse? Miksi klassinen lähestymistapa ei toimi enää? Kaikki nämä kysymykset tietävät vastauksen Juri Shabalin ja Swordfish Security. Yuriy vastaa kaikkeen yksityiskohtaisesti ja analysoi klassisesta Application Security -mallista DevSecOps-prosessiin siirtymisen ongelmia: kuinka lähestyä turvallisen kehitysprosessin integrointia DevOps-prosessiin ja olla rikkomatta mitään, kuinka käydä läpi päävaiheet tietoturvatestauksesta, mitä työkaluja voidaan käyttää, miten ne eroavat toisistaan ja kuinka ne määritetään oikein sudenkuoppien välttämiseksi.
Tietoja kaiuttimesta: Juri Shabalin - Yrityksen turvallisuuspäällikkö Swordfish Security. Vastaa SSDL:n käyttöönotosta, sovellusanalyysityökalujen kokonaisvaltaisesta integroinnista yhdeksi kehitys- ja testausekosysteemiksi. 7 vuoden kokemus tietoturvasta. Työskenteli Alfa-Bankissa, Sberbankissa ja Positive Technologiesissa, joka kehittää ohjelmistoja ja tarjoaa palveluita. Kansainvälisten konferenssien puhuja ZerONights, PHDays, RISSPA, OWASP.
Sovellusturvallisuus: mistä on kyse?
Sovellusten suojaus on tietoturvaosasto, joka vastaa sovellusten turvallisuudesta. Tässä ei ole kyse infrastruktuurista tai verkon turvallisuudesta, vaan siitä, mitä kirjoitamme ja mitä kehittäjät työskentelevät - nämä ovat itse sovelluksen puutteita ja haavoittuvuuksia.
suunta - Tietoturvan kehityksen elinkaari - Microsoftin kehittämä. Kaavio esittää kanonista SDLC-mallia, jonka päätehtävänä on turvallisuuden osallistuminen jokaiseen kehitysvaiheeseen vaatimuksista julkaisuun ja tuotantoon. Microsoft tajusi, että tanssiaisissa on liikaa bugeja, niitä on enemmän ja asialle on tehtävä jotain, ja he ehdottivat tätä lähestymistapaa, josta tuli kanoninen.
Application Securityn ja SSDL:n tarkoituksena ei ole havaita haavoittuvuuksia, kuten yleisesti uskotaan, vaan estää niiden esiintyminen. Ajan myötä Microsoftin kanonista lähestymistapaa on parannettu, kehitetty, ja siinä on syvempi yksityiskohtainen upotus.
Kanoninen SDLC on erittäin yksityiskohtainen eri menetelmissä - OpenSAMM, BSIMM, OWASP. Menetelmät vaihtelevat, mutta ovat yleensä samanlaisia.
Rakennusturvakysymysmalli
Pidän siitä eniten BSIMM - . Metodologian perustana on Application Security -prosessin jakaminen neljään toimialueeseen: Hallinto, Intelligence, SSDL Touchpoints ja Deployment. Jokaisella toimialueella on 4 käytäntöä, jotka on esitetty 12 toimintona.
Jokaisella 112 toiminnasta on 3 kypsyysastetta: aloittelija, keskitason ja edistynyt. Voit opiskella kaikkia 12 käytäntöä osioissa, valita sinulle tärkeitä asioita, miettiä niiden toteuttamista ja lisätä asteittain elementtejä, esimerkiksi staattista ja dynaamista koodianalyysiä tai koodin tarkistusta. Laadit suunnitelman ja työskentelet sen mukaan rauhallisesti osana valittujen toimintojen toteuttamista.
Miksi DevSecOps
DevOps on kaiken kaikkiaan suuri prosessi, jossa turvallisuudesta on huolehdittava.
Ensin mukana turvatarkastukset. Käytännössä turvatiimien määrä oli huomattavasti nykyistä pienempi, eivätkä ne toimineet prosessin osallistujina, vaan valvonta- ja valvontaelimenä, joka asettaa sille vaatimuksia ja tarkastaa tuotteen laadun julkaisun lopussa. Tämä on klassinen lähestymistapa, jossa turvallisuustiimit olivat kehityksen seinän takana eivätkä osallistuneet prosessiin.
Suurin ongelma on, että tietoturva on erillään kehityksestä. Yleensä tämä on jonkinlainen IB-piiri ja se sisältää 2-3 isoa ja kallista työkalua. Kuuden kuukauden välein lähdekoodi tai sovellus saapuu testattavaksi ja kerran vuodessa . Kaikki tämä johtaa siihen, että alan julkaisupäiviä lykätään, ja kehittäjälle putoaa valtava määrä automaattisten työkalujen haavoittuvuuksia. Kaikkea tätä on mahdotonta purkaa ja korjata, koska edes edellisen kuuden kuukauden aikana tuloksia ei purettu, ja tässä on uusi erä.
Yrityksemme työssä näemme, että turvallisuus kaikilla alueilla ja toimialoilla ymmärtää, että on aika ottaa kiinni ja pyörittää kehitystä yhdessä pyörässä - in . DevSecOps-paradigma sopii täydellisesti ketterään kehitysmetodologiaan, toteutukseen, tukeen ja osallistumiseen jokaiseen julkaisuun ja iteraatioon.
Siirtyminen DevSecOpsiin
Turvallisuuden kehittämisen elinkaaren tärkein sana on "käsitellä asiaa". Sinun on ymmärrettävä tämä ennen kuin harkitset työkalujen ostamista.
Pelkkä työkalujen sisällyttäminen DevOps-prosessiin ei riitä - viestintä ja ymmärrys prosessin osallistujien välillä on tärkeää.
Ihmiset ovat tärkeämpiä kuin työkalut
Usein turvallisen kehitysprosessin suunnittelu alkaa työkalun valinnasta ja ostamisesta ja päättyy yrityksiin integroida työkalu nykyiseen prosessiin, jotka jäävät yrityksiksi. Tämä johtaa surullisiin seurauksiin, koska kaikilla työkaluilla on omat ominaisuutensa ja rajoituksensa.
Yleinen tapaus on, kun tietoturvaosasto valitsi hyvän, kalliin työkalun, jossa on laaja valikoima ominaisuuksia ja tuli kehittäjien luo sisällyttämään sitä prosessiin. Mutta se ei toimi - prosessi on suunniteltu siten, että jo ostetun instrumentin rajoitukset eivät sovi nykyiseen paradigmaan.
Kuvaile ensin, minkä tuloksen haluat ja miltä prosessi näyttää. Tämä auttaa ymmärtämään työkalun ja turvallisuuden roolia prosessissa.
Aloita siitä, mikä on jo käytössä
Ennen kuin ostat kalliita työkaluja, katso mitä sinulla on jo. Jokaisella yrityksellä on kehitystä koskevat turvallisuusvaatimukset, on tarkastuksia, tunkeutumistestejä - miksi ei muuttaisi kaikkea tätä kaikille ymmärrettävään ja kätevään muotoon?
Yleensä vaaditaan paperista Talmud, joka makaa hyllyllä. Oli tapaus, kun tulemme yritykseen katsomaan prosesseja ja pyytämään näyttämään ohjelmiston turvallisuusvaatimukset. Tämän tehnyt asiantuntija etsi pitkään:
- Nyt jossain muistiinpanoissa oli polku, jolla tämä asiakirja sijaitsee.
Tämän seurauksena saimme asiakirjan viikkoa myöhemmin.
Vaatimuksia, shekkejä ja muuta varten luo sivu, esimerkiksi osoitteessa yhtymäkohta - se on kätevä kaikille.
On helpompi alustaa jo olemassa oleva uudelleen ja käyttää sitä aloittamiseen.
Käytä Security Championsia
Yleensä 100-200 kehittäjän keskimääräisessä yrityksessä on yksi turvapäällikkö, joka suorittaa useita tehtäviä, eikä hänellä ole fyysisesti aikaa tarkistaa kaikkea. Vaikka hän yrittää parhaansa, hän ei yksin tarkista kaikkea kehitystyön luomaa koodia. Tällaisia tapauksia varten on kehitetty konsepti - .
Security Champions on kehitystiimiin kuuluva henkilö, joka on kiinnostunut tuotteesi turvallisuudesta.
Security Champion on sisääntulopiste kehitystiimiin ja turvallisuusevankelista, joka on yhdistetty yhdeksi.
Yleensä kun turvapäällikkö tulee kehitystiimiin ja huomauttaa virheestä koodissa, hän saa yllättyneen vastauksen:
- Ja kuka sinä olet? Näen sinut ensimmäistä kertaa. Minun kanssani kaikki on hyvin - vanhempi ystäväni laittoi "hae" koodin tarkistukseen, jatketaan!
Tämä on tyypillinen tilanne, koska paljon enemmän luottamusta senioreihin tai vain tiimitovereihin, joiden kanssa kehittäjä on jatkuvasti vuorovaikutuksessa töissä ja kooditarkasteluissa. Jos vartijan sijasta Turvamestari huomauttaa virheestä ja sen seurauksista, hänen sanallaan on enemmän painoarvoa.
Lisäksi kehittäjät tuntevat koodinsa paremmin kuin mikään tietoturvamies. Henkilölle, jolla on vähintään 5 projektia staattisessa analyysityökalussa, on yleensä vaikea muistaa kaikkia vivahteita. Tietoturvamestarit tuntevat tuotteensa: mikä on vuorovaikutuksessa minkä kanssa ja mitä kannattaa ensinnäkin katsoa - he ovat tehokkaampia.
Harkitse siis Security Champions -ohjelman käyttöönottoa ja turvallisuustiimin vaikutusvallan laajentamista. Tästä on hyötyä myös mestarille itselleen: ammatillinen kehittyminen uudella alalla, teknisen näköpiirin laajentaminen, teknisten, johtamis- ja johtamistaitojen pumppaus, markkina-arvon kasvattaminen. Tämä on osa sosiaalista suunnittelua, sinun "silmäsi" kehitystiimissä.
Testausvaiheet
sanoo, että 20 % ponnisteluista tuottaa 80 % tuloksista. Nämä 20 % ovat sovellusanalyysikäytäntöjä, jotka voidaan ja pitäisi automatisoida. Esimerkkejä tällaisista toiminnoista ovat staattinen analyysi − SAST, dynaaminen analyysi - DAST и avoimen lähdekoodin ohjaus. Kerron sinulle lisää toiminnoista sekä työkaluista, mitä ominaisuuksia yleensä kohtaamme, kun ne otetaan prosessiin, ja kuinka se tehdään oikein.
Tärkeimmät työkaluongelmat
Korostan ongelmia, jotka koskevat kaikkia huomiota vaativia välineitä. Analysoin niitä tarkemmin, jotta en toista enempää.
Pitkä analyysiaika. Jos sitoutumisesta julkaisuun kuluu kaikkiin testeihin ja kokoonpanoon 30 minuuttia, tietoturvatarkastukset vievät päivän. Joten kukaan ei hidasta prosessia. Harkitse tätä ominaisuutta ja tee johtopäätökset.
Korkea väärä negatiivinen tai väärä positiivinen. Kaikki tuotteet ovat erilaisia, kaikki käyttävät erilaisia kehyksiä ja omaa koodaustyyliään. Eri koodipohjaisilla ja teknologioilla työkalut voivat näyttää eri tasoja vääriä negatiivisia ja vääriä positiivisia. Joten katso mitä sisältää teidän yrityksille ja varten sinun sovellukset näyttävät hyvän ja luotettavan tuloksen.
Ei integraatioita olemassa oleviin työkaluihin. Tarkastele työkaluja integraatioina jo käyttämiesi ohjelmien kanssa. Jos sinulla on esimerkiksi Jenkins tai TeamCity, tarkista työkalujen integrointi tähän ohjelmistoon, älä GitLab CI:hen, jota et käytä.
Räätälöinnin puute tai liiallinen monimutkaisuus. Jos työkalulla ei ole API:ta, miksi sitä tarvitaan? Kaiken, mitä käyttöliittymässä voidaan tehdä, tulee olla saatavilla API:n kautta. Ihannetapauksessa työkalulla pitäisi olla mahdollisuus mukauttaa tarkastuksia.
Ei tuotekehityssuunnitelmaa. Kehitys ei pysähdy, käytämme aina uusia kehyksiä ja toimintoja, kirjoitamme vanhaa koodia uusille kielille. Haluamme varmistaa, että ostamamme työkalu tukee uusia puitteita ja teknologioita. Siksi on tärkeää tietää, että tuotteella on todellinen ja oikea kehitystä.
Prosessin ominaisuudet
Harkitse työkalujen ominaisuuksien lisäksi kehitysprosessin ominaisuuksia. Esimerkiksi kehitykseen häiritseminen on tyypillinen virhe. Katsotaan, mitä muita ominaisuuksia tulisi ottaa huomioon ja mihin turvallisuustiimin tulisi kiinnittää huomiota.
Jotta et häiritse kehitystä ja vapauttamaan määräaikoja, luo erilaisia sääntöjä ja erilaisia näytä tulpat - kriteerit rakennusprosessin pysäyttämiseksi haavoittuvuuksien esiintyessä - erilaisiin ympäristöihin. Ymmärrämme esimerkiksi, että nykyinen haara on menossa kehitysosastolle tai UAT:lle, joten emme pysähdy sanomaan:
- Sinulla on täällä haavoittuvuuksia, etkä pääse minnekään pidemmälle!
Tässä vaiheessa on tärkeää kertoa kehittäjille, että on olemassa tietoturvaongelmia, joihin on kiinnitettävä huomiota.
Haavoittuvuuksien esiintyminen ei ole este lisätestauksille: manuaalinen, integrointi tai manuaalinen. Toisaalta meidän on jotenkin parannettava tuotteen turvallisuutta ja jotta kehittäjät eivät arvosta sitä, mitä tietoturva löytää. Siksi joskus teemme näin: osastolla, kun se leviää kehitysympäristöön, ilmoitamme kehitykselle:
- Kaverit, teillä on ongelmia, kiinnittäkää niihin huomiota.
UAT-vaiheessa näytämme jälleen varoituksia haavoittuvuuksista, ja promin poistumisvaiheessa sanomme:
"Kaverit, varoitimme teitä useita kertoja, ette tehneet mitään - emme päästä teitä ulos tästä.
Jos puhumme koodista ja dynamiikasta, on tarpeen näyttää ja varoittaa vain niiden ominaisuuksien ja koodin haavoittuvuuksista, jotka juuri kirjoitettiin tähän ominaisuuteen. Jos kehittäjä siirsi painiketta 3 pikseliä ja kerromme hänelle, että hänellä on siellä SQL-injektio ja siksi se on korjattava kiireellisesti, tämä on väärin. Katso vain sitä, mitä nyt on kirjoitettu, ja sovellukseen tulevaa muutosta.
Oletetaan, että meillä on jokin toiminnallinen vika - tapa, jolla sovelluksen ei pitäisi toimia: rahaa ei siirretä, kun napsautat painiketta, ei siirry seuraavalle sivulle tai tuote ei lataudu. Turvallisuusvirheet - nämä ovat samat viat, mutta eivät sovelluksen, vaan turvallisuuden yhteydessä.
Kaikki ohjelmiston laatuongelmat eivät ole tietoturvaongelmia. Mutta kaikki tietoturvaongelmat liittyvät ohjelmiston laatuun. Sherif Mansour, Expedia.
Koska kaikki haavoittuvuudet ovat samoja vikoja, ne tulisi sijoittaa samaan paikkaan kuin kaikki kehitysvirheet. Joten unohda raportit ja pelottavat PDF-tiedostot, joita kukaan ei lue.
Kun olin töissä kehitysyhtiössä, sain raportin staattisen analyysin työkaluista. Avasin sen, kauhistuin, keitin kahvia, selailin 350 sivua, suljin sen ja jatkoin töitä. Suuret raportit ovat kuolleita raportteja. Yleensä ne eivät mene minnekään, sähköpostit poistetaan, unohdetaan, katoavat tai yritys sanoo ottavansa riskejä.
Mitä tehdä? Muunnamme löydetyt vahvistetut viat yksinkertaisesti kehittämiseen sopivaan muotoon, esimerkiksi lisäämme ne Jiran ruuhkaan. Viat priorisoidaan ja eliminoidaan tärkeysjärjestyksessä sekä toiminnalliset viat ja testivirheet.
Staattinen analyysi - SAST
Tämä on haavoittuvuuksien koodianalyysiä., mutta se ei ole sama kuin SonarQube. Emme tarkista vain kuvioita tai tyyliä. Analyysissä käytetään useita lähestymistapoja: haavoittuvuuspuun mukaan, by , analysoimalla asetustiedostoja. Siinä kaikki itse koodille.
Lähestymistavan plussat: koodin haavoittuvuuksien tunnistaminen varhaisessa kehitysvaiheessakun ei ole telineitä ja valmiita työkaluja, ja inkrementaalinen skannausominaisuus: skannaa muuttuneen koodin osan ja vain parhaillaan tekemämme ominaisuuden, mikä lyhentää skannausaikaa.
Miinukset on tuen puute vaadituille kielille.
Vaaditut integraatiot, jonka pitäisi subjektiivisen mielipiteeni mukaan olla työkaluissa:
- Integrointityökalu: Jenkins, TeamCity ja Gitlab CI.
- Kehitysympäristö: Intellij IDEA, Visual Studio. Kehittäjän on kätevämpää olla kiipeämättä käsittämättömään käyttöliittymään, joka on vielä muistettava, vaan nähdä kaikki tarvittavat integraatiot ja haavoittuvuudet, jotka hän on löytänyt aivan työpaikalta omassa kehitysympäristössään.
- Koodin tarkistus: SonarQube ja manuaalinen tarkistus.
- Vikajäljittimet: Jira ja Bugzilla.
Kuvassa on joitain staattisen analyysin parhaita edustajia.
Työkaluilla ei ole merkitystä, vaan prosessilla, joten on olemassa avoimen lähdekoodin ratkaisuja, jotka sopivat myös prosessin suorittamiseen.
SAST Open Source ei löydä valtavaa määrää haavoittuvuuksia tai monimutkaista DataFlowia, mutta niitä voidaan ja pitäisi käyttää prosessin rakentamisessa. Ne auttavat ymmärtämään, miten prosessi rakennetaan, kuka vastaa virheisiin, kuka raportoi, kuka raportoi. Jos haluat suorittaa koodisi suojauksen rakentamisen alkuvaiheen, käytä avoimen lähdekoodin ratkaisuja.
Kuinka tämä voidaan integroida, jos olet matkan alussa, sinulla ei ole mitään: ei CI:tä, Jenkinsiä tai TeamCityä? Harkitse prosessien integrointia.
Integrointi CVS-tasolla
Jos sinulla on Bitbucket tai GitLab, voit tehdä integroinnin tasolla .
Tapahtuman mukaan vedä pyyntö, sitoudu. Skannaat koodin ja näytät koontiversiossa, että turvatarkastus läpäisi tai epäonnistui.
Palaute. Toki palautetta tarvitaan aina. Jos teit sen vain turvallisuuspuolella, laitoit sen laatikkoon etkä kertonut siitä kenellekään mitään ja sitten heitit joukon bugeja kuun lopussa, tämä ei ole oikein eikä hyvä.
Integrointi koodintarkistusjärjestelmään
Kerran asetimme AppSecin teknisen käyttäjän oletusarvostelijaksi useissa tärkeissä projekteissa. Riippuen siitä, löytyikö uudesta koodista virheitä vai ei virheitä, tarkistaja asettaa vetopyynnön tilan "hyväksy" tai "töitä tarvitaan" - joko kaikki on kunnossa tai sinun on viimeisteltävä ja linkitettävä mitä tarkalleen. viimeistelemään. Julkaisevan version kanssa integroimiseksi olemme poistaneet yhdistämisen käytöstä, jos IS-testiä ei läpäisisi. Sisällytimme tämän manuaaliseen koodien tarkasteluun, ja muut prosessin osallistujat näkivät tämän prosessin suojaustilat.
Integrointi SonarQubeen
Monilla on koodin laadun suhteen. Se on sama täällä - voit tehdä samat portit vain SAST-instrumenteille. Siellä on sama käyttöliittymä, sama laatuportti, vain sitä kutsutaan turvaportti. Ja myös, jos olet määrittänyt prosessin SonarQubella, voit helposti integroida kaiken sinne.
Integrointi CI-tasolla
Tässäkin kaikki on melko yksinkertaista:
- Autotestien tasolla, yksikkötestit.
- Jako kehitysvaiheiden mukaan: dev, testi, prod. Mukana voi olla erilaisia sääntöjä tai erilaisia vikatilanteita: pysäytämme kokoonpanon, emme pysäytä kokoonpanoa.
- Synkroninen / asynkroninen käynnistys. Odotamme turvatestien loppua tai emme odota. Eli käynnistimme ne ja siirrymme eteenpäin, ja sitten saamme tilan, että kaikki on hyvin tai huonosti.
Kaikki on täydellisessä vaaleanpunaisessa maailmassa. Tosielämässä näin ei ole, mutta pyrimme. Turvatarkastusten tulosten tulee olla samanlaiset kuin yksikkötestien tulokset.
Otimme esimerkiksi suuren projektin ja päätimme, että nyt skannaamme sen SASTilla - OK. Työnsimme tämän projektin SASTiin, se antoi meille 20 000 haavoittuvuutta ja teimme vahvan tahdon päätöksen, että kaikki on hyvin. 20 000 haavoittuvuutta on tekninen velkamme. Laitamme velan laatikkoon, haravoimme sen hitaasti ja käynnistämme vikoja vikaseurantajärjestelmissä. Palkkaa yritys, tee kaikki itse tai anna Security Champions auttamaan meitä, niin tekninen velka pienenee.
Ja kaikki uuden koodin uudet haavoittuvuudet tulisi poistaa samalla tavalla kuin virheet yksikössä tai automaattisissa testeissä. Suhteellisesti sanottuna kokoonpano käynnistyi, ajoi pois, kaksi testiä ja kaksi turvatestiä putosivat. OK - mentiin, katsottiin mitä tapahtui, korjattiin yksi, korjattiin toinen, ajeltiin seuraavan kerran - kaikki on kunnossa, uusia haavoittuvuuksia ei ole ilmaantunut, testit eivät ole epäonnistuneet. Jos tämä tehtävä on syvempi ja sinun on ymmärrettävä se hyvin, tai haavoittuvuuksien korjaaminen vaikuttaa suuriin kerroksiin konepellin alla: vika tuodaan vikaseurantaan, se priorisoidaan ja korjataan. Valitettavasti maailma ei ole täydellinen ja testit epäonnistuvat joskus.
Esimerkki turvaportista on laatuportin analogi, mitä tulee koodin haavoittuvuuksien esiintymiseen ja lukumäärään.
Integroimme SonarQubeen - laajennus on asennettu, kaikki on erittäin kätevää ja siistiä.
Kehitysympäristön integrointi
Integrointivaihtoehdot:
- Skannauksen aloittaminen kehitysympäristöstä jo ennen sitoutumista.
- Näytä tulokset.
- Tulosten analyysi.
- Synkronointi palvelimen kanssa.
Tältä näyttää tulosten saaminen palvelimelta.
Kehitysympäristössämme se vain näyttää lisäkohteen, joka sanoo, että tällaisia haavoittuvuuksia löydettiin tarkistuksen aikana. Voit heti muokata koodia, nähdä suosituksia ja . Kaikki tämä sijaitsee kehittäjän työpaikalla, mikä on erittäin kätevää - sinun ei tarvitse seurata muita linkkejä ja katsella jotain ylimääräistä.
Open Source
Tämä on suosikkiaiheeni. Kaikki käyttävät avoimen lähdekoodin kirjastoja - miksi kirjoittaa nippu kainalosauvoja ja polkupyöriä, kun voi ottaa valmiin kirjaston, jossa kaikki on jo toteutettu?
Tämä on tietysti totta, mutta myös kirjastot ovat ihmisten kirjoittamia, sisältävät myös tiettyjä riskejä, ja on myös haavoittuvuuksia, joista raportoidaan säännöllisesti tai jatkuvasti. Siksi sovellusten suojauksessa on seuraava vaihe - tämä on avoimen lähdekoodin komponenttien analyysi.
Avoimen lähdekoodin analyysi - OSA
Työkalu sisältää kolme päävaihetta.
Haavoittuvuuksien etsiminen kirjastoista. Työkalu esimerkiksi tietää, että käytämme jonkinlaista kirjastoa, ja että se sisältää tai vianseurantaohjelmissa on joitain haavoittuvuuksia, jotka liittyvät tähän kirjaston versioon. Jos yrität käyttää sitä, työkalu varoittaa, että kirjasto on haavoittuvainen, ja neuvoo käyttämään toista versiota, jossa ei ole haavoittuvuuksia.
Lisenssin puhtauden analyysi. Tämä ei ole vielä kovin suosittua meillä, mutta jos työskentelet vieraan maan kanssa, voit ajoittain saada hyökkäyksen avoimen lähdekoodin komponentin käytöstä, jota ei voi käyttää tai muokata. Lisensoidun kirjaston käytännön mukaan emme voi tehdä tätä. Tai jos olemme muokanneet sitä ja käytämme sitä, meidän on lähetettävä koodimme. Kukaan ei tietenkään halua julkaista tuotteidensa koodia, mutta voit myös suojautua siltä.
Teollisuusympäristössä käytettävien komponenttien analyysi. Kuvittele hypoteettinen tilanne, että olemme vihdoin saaneet päätökseen kehitystyön ja julkaisseet mikropalvelumme uusimman julkaisun teollisuudelle. Hän asuu siellä ihanasti - viikon, kuukauden, vuoden. Emme kerää sitä, emme tee turvatarkastuksia, kaikki näyttää olevan kunnossa. Mutta yhtäkkiä, kaksi viikkoa julkaisun jälkeen, avoimen lähdekoodin komponentin kriittinen haavoittuvuus ilmestyy, jota käytämme tässä nimenomaisessa kokoonpanossa, teollisuusympäristössä. Jos emme tallenna mitä ja missä käytämme, tätä haavoittuvuutta ei yksinkertaisesti nähdä. Jotkin työkalut pystyvät tarkkailemaan haavoittuvuuksia kirjastoissa, joita tällä hetkellä käytetään prom. Se on erittäin hyödyllistä.
ominaisuudet:
- Erilaiset politiikat eri kehitysvaiheille.
- Tarkkaile komponentteja teollisuusympäristössä.
- Kirjastojen ohjaus organisaation ääriviivassa.
- Tuki erilaisille rakennusjärjestelmille ja kielille.
- Docker-kuvien analyysi.
Muutama esimerkki alan johtajista, jotka ovat mukana avoimen lähdekoodin analysoinnissa.
Ainoa ilmainen on OWASP:ltä. Voit ottaa sen käyttöön ensimmäisissä vaiheissa, nähdä, miten se toimii ja mitä se tukee. Pohjimmiltaan nämä ovat kaikki pilvituotteita tai on-premise-tuotteita, mutta perustansa takana ne menevät silti Internetiin. He eivät lähetä kirjastojasi, vaan tiivisteitä tai laskemiaan arvoja ja sormenjälkiä palvelimelleen saadakseen uutisia haavoittuvuuksista.
Prosessien integrointi
Kehäkirjaston ohjausjotka on ladattu ulkoisista lähteistä. Meillä on ulkoiset ja sisäiset arkistot. Meillä on esimerkiksi Nexus Event Centralissa, ja haluamme varmistaa, ettei tietovarastossamme ole haavoittuvuuksia, joiden tila on "kriittinen" tai "korkea". Voit määrittää välityspalvelimen käyttämällä Nexus Firewall Lifecycle -työkalua, jotta tällaiset haavoittuvuudet leikataan pois eivätkä sisälly sisäiseen tietovarastoon.
CI-integraatio. Samalla tasolla autotestien, yksikkötestien ja kehitysvaiheisiin jakautumisen kanssa: dev, testi, prod. Jokaisessa vaiheessa voit ladata mitä tahansa kirjastoa, käyttää mitä tahansa, mutta jos "kriittisessä" tilassa on jotain vaikeaa, sinun pitäisi luultavasti kiinnittää kehittäjien huomio tähän promilleaation vaiheessa.
Artefakttien integrointi: Nexus ja JFrog.
Integroituminen kehitysympäristöön. Valitsemiesi työkalujen tulee olla integroituja kehitysympäristöihin. Kehittäjällä on oltava pääsy skannaustuloksiin työpaikaltaan tai mahdollisuus skannata ja tarkistaa koodi haavoittuvuuksien varalta ennen kuin se tekee sen CVS:ssä.
CD-integrointi. Tämä on hieno ominaisuus, josta pidän todella ja josta olen jo puhunut - uusien haavoittuvuuksien syntymisen seuranta teollisuusympäristössä. Se toimii näin.
Meillä on Julkiset komponenttivarastot - Jotkut työkalut ulkopuolelta ja sisäinen arkistomme. Haluamme, että siinä on vain luotettavia komponentteja. Välityspalvelinta lähetettäessä tarkistamme, ettei ladatussa kirjastossa ole haavoittuvuuksia. Jos se kuuluu tiettyjen määrittämiemme ja kehitystyön kanssa koordinoimiemme käytäntöjen piiriin, emme lataa sitä ja saamme vastalauseen toisen version käyttämisestä. Vastaavasti, jos kirjastossa on jotain todella kriittistä ja huonoa, kehittäjä ei saa kirjastoa edes asennusvaiheessa - anna hänen käyttää uudempaa tai alempaa versiota.
- Rakentaessamme tarkistamme, ettei kukaan ole luiskahtanut mitään pahaa, että kaikki komponentit ovat turvallisia eikä kukaan ole tuonut mitään vaarallista muistitikulle.
- Meillä on vain luotettavia komponentteja arkistossa.
- Käyttöönoton yhteydessä tarkistamme vielä kerran itse paketin: war, jar, DL tai Docker image, että se noudattaa käytäntöä.
- Teollisuusympäristöön tullessamme seuraamme, mitä teollisuusympäristössä tapahtuu: kriittisiä haavoittuvuuksia ilmaantuu tai ei esiinny.
Dynaaminen analyysi - DAST
Dynaamisen analyysin työkalut eroavat olennaisesti kaikesta, mitä on sanottu aiemmin. Tämä on eräänlainen jäljitelmä käyttäjän työstä sovelluksen kanssa. Jos kyseessä on verkkosovellus, lähetämme asiakkaan työtä jäljitteleviä pyyntöjä, napsautamme etupuolella olevia painikkeita, lähetämme lomakkeesta keinotekoisia tietoja: lainausmerkkejä, sulkumerkkejä, merkkejä eri koodauksissa nähdäksemme kuinka sovellus toimii ja käsittelee ulkoista tiedot.
Saman järjestelmän avulla voit tarkistaa avoimen lähdekoodin mallien haavoittuvuuksia. Koska DAST ei tiedä, mitä avointa lähdekoodia käytämme, se yksinkertaisesti heittää "haitallisia" malleja ja analysoi palvelimen vastaukset:
- Kyllä, tässä on deserialisaatio-ongelma, mutta ei täällä.
Tässä on suuria riskejä, koska jos teet tämän turvatestin samalla telineellä, jonka kanssa testaajat työskentelevät, voi tapahtua epämiellyttäviä asioita.
- Suuri kuormitus sovelluspalvelinverkossa.
- Ei integraatioita.
- Mahdollisuus muuttaa analysoitavan sovelluksen asetuksia.
- Tarvittavia teknologioita ei tueta.
- Asetuksen vaikeus.
Meillä oli tilanne, kun vihdoin käynnistimme AppScanin: tyrmäsimme sovelluksen pääsyn pitkäksi aikaa, saimme 3 tiliä ja olimme iloisia - vihdoinkin tarkistamme kaiken! Aloitimme tarkistuksen, ja ensimmäinen asia, jonka AppScan teki, oli päästä hallintapaneeliin, lävistää kaikki painikkeet, muuttaa puolet tiedoista ja sitten tappaa palvelimen kokonaan omalla -pyynnöt. Kehitys testaamalla sanoi:
"Kaverit, vitsailetko minulle?! Annoimme sinulle tilit, ja sinä laitoit kantaa!
Harkitse mahdollisia riskejä. Ihannetapauksessa valmista tietoturvan testaamiseen erillinen osasto, joka ainakin jollakin tavalla eristetään muusta ympäristöstä ja ehdollisesti tarkasta hallintapaneeli, mieluiten manuaalisessa tilassa. Tämä on pentest - ne jäljellä olevat prosenttiosuudet ponnisteluista, joita emme nyt harkitse.
On syytä harkita, että voit käyttää tätä kuormitustestauksen analogina. Ensimmäisessä vaiheessa voit kytkeä dynaamisen skannerin päälle 10-15 säikeessä ja katsoa mitä tapahtuu, mutta yleensä, kuten käytäntö osoittaa, ei mitään hyvää.
Muutamia resursseja, joita yleensä käytämme.
Korostamisen arvoinen on "sveitsiläinen veitsi" kaikille turvallisuusalan ammattilaisille. Kaikki käyttävät sitä ja se on erittäin kätevä. Yritysversiosta on nyt julkaistu uusi demoversio. Jos aiemmin se oli vain itsenäinen apuohjelma laajennuksilla, niin nyt kehittäjät ovat vihdoin tekemässä suurta palvelinta, josta on mahdollista hallita useita agentteja. Se on siistiä, suosittelen kokeilemaan.
Prosessien integrointi
Integrointi on melko hyvä ja yksinkertainen: aloita skannaus onnistuneen asennuksen jälkeen sovelluksia jalustalla ja skannaus onnistuneen integrointitestin jälkeen.
Jos integroinnit eivät toimi tai niissä on typpejä ja pilkkutoimintoja, se on merkityksetöntä ja hyödytöntä - lähetämme millaisen kaavan tahansa, palvelin vastaa silti samalla tavalla.
- Ihannetapauksessa erillinen testipenkki.
- Ennen kuin testaat, kirjoita kirjautumisjärjestys muistiin.
- Hallintojärjestelmän testaus on vain manuaalista.
prosessi
Hieman yleistetty prosessista yleensä ja kunkin työkalun toiminnasta erityisesti. Kaikki sovellukset ovat erilaisia - yksi toimii paremmin dynaamisen analyysin kanssa, toinen staattisen analyysin kanssa, kolmas OpenSource-analyysin, pentestien tai jotain muuta yleensä, esimerkiksi tapahtumien kanssa .
Jokaista prosessia on valvottava.
Ymmärtääksesi, miten prosessi toimii ja missä sitä voidaan parantaa, sinun on kerättävä mittareita kaikesta, mitä voit saada käsiisi, mukaan lukien tuotantomittaukset, työkalujen tiedot ja vianseurantalaitteet.
Kaikki tiedot ovat hyödyllisiä. On tarpeen tarkastella eri osissa, missä tätä tai toista työkalua käytetään paremmin, missä prosessi erityisesti laskee. Kehityksen vasteaikoja kannattaa tarkastella, jotta nähdään, missä prosessia voitaisiin parantaa ajan perusteella. Mitä enemmän dataa, sitä enemmän leikkauksia voidaan rakentaa ylätasolta kunkin prosessin yksityiskohtiin.
Koska kaikilla staattisilla ja dynaamisilla analysaattoreilla on omat API:t, omat käynnistysmenetelmänsä, periaatteensa, joillain on ajastimia, toisilla ei - kirjoitamme työkalua AppSec Orchestrator, jonka avulla voit luoda yhden syöttöpisteen koko prosessiin tuotteesta ja hallita sitä yhdestä pisteestä.
Johtajilla, kehittäjillä ja tietoturvainsinööreillä on yksi sisääntulopiste, josta he voivat nähdä, mitä on käynnissä, määrittää ja suorittaa tarkistuksia, saada tarkistustuloksia ja lähettää vaatimuksia. Yritämme siirtyä pois paperinpaloista, kääntää kaiken inhimillisiksi, joita kehitys käyttää - sivut Confluencesta tilalla ja mittareilla, viat Jirassa tai erilaisissa vikaseurantaohjelmissa tai upottaminen synkroniseen / asynkroniseen prosessiin CI / CD: ssä.
Keskeiset ostokset
Työkaluilla ei ole väliä. Ajattele ensin prosessia ja ota sitten käyttöön työkalut. Työkalut ovat hyviä, mutta kalliita, joten voit aloittaa prosessista ja hienosäätää kehityksen ja turvallisuuden välistä vuorovaikutusta ja ymmärrystä. Turvallisuuden näkökulmasta kaikkea peräkkäin ei tarvitse "pysäyttää". Kehityksen kannalta jos on jotain korkeaa mega superkriittistä, niin tämä pitää poistaa, eikä sulkea ongelmalta. .
Tuotteen laatu - yhteinen päämäärä sekä turvallisuudesta että kehityksestä. Teemme yhden asian, yritämme varmistaa, että kaikki toimii oikein, eikä maineriskiä tai taloudellisia menetyksiä aiheudu. Siksi edistämme lähestymistapaa DevSecOpsiin ja SecDevOpsiin luodaksemme viestintää ja tehdäksemme tuotteesta paremman.
Aloita siitä, mitä on jo olemassa: vaatimukset, arkkitehtuuri, osatarkastukset, koulutukset, ohjeet. Kaikkia käytäntöjä ei tarvitse heti soveltaa kaikkiin projekteihin - liikkua iteratiivisesti. Ei ole olemassa yhtä standardia koe ja kokeilla erilaisia lähestymistapoja ja ratkaisuja.
IS-virheiden ja toimintahäiriöiden välinen yhtäläisyysmerkki.
Automatisoi kaikkijoka liikkuu. Kaikki mikä ei liiku, liikkuu ja automatisoituu. Jos jotain tehdään käsin, tämä ei ole hyvä osa prosessia. Ehkä sekin kannattaa harkita uudelleen ja automatisoida.
Jos IB-joukkueen koko on pieni - käytä Security Championsia.
Ehkä se, mistä puhuin, ei sovi sinulle ja keksit jotain omaa - ja se on hyvä. Mutta Valitse työkalut prosessisi vaatimusten perusteella. Älä katso, mitä yhteisö sanoo, että tämä työkalu on huono ja tämä hyvä. Ehkä tuotteesi on toisinpäin.
Työkaluvaatimukset.
- Matala Väärä positiivinen.
- Riittävä analyysiaika.
- Helppokäyttöisyys.
- Integraatioiden saatavuus.
- Tuotekehityksen tiekartan ymmärtäminen.
- Mahdollisuus muokata työkaluja.
Jurin raportti valittiin yhdeksi parhaista DevOpsConf 2018 -tapahtumassa. Tutustuaksesi vieläkin mielenkiintoisiin ideoihin ja käytännön tapauksiin, tule Skolkovoon 27. ja 28. toukokuuta. sisällä . Vielä parempi, jos olet valmis jakamaan kokemuksesi Lähetä raporttisi 21. huhtikuuta mennessä.
Lähde: will.com