Osana ammatillista toimintaansa kehittäjät, testaajat ja tietoturva-ammattilaiset joutuvat käsittelemään prosesseja, kuten Vulnerability Management (VM) ja (Secure) SDLC.
Näiden lauseiden alla on erilaisia käytäntöjä ja käytettyjä työkaluja, jotka kietoutuvat toisiinsa, vaikka niiden käyttäjät ovat erilaisia.
Tekninen kehitys ei ole vielä edennyt siihen pisteeseen, että yksi työkalu voi korvata ihmisen infrastruktuurin ja ohjelmistojen turvallisuuden analysoinnissa.
On mielenkiintoista ymmärtää, miksi näin on ja mitä ongelmia on kohdattava.
prosessit
Haavoittuvuuden hallintaprosessi on suunniteltu valvomaan jatkuvasti infrastruktuurin turvallisuutta ja korjaustiedostojen hallintaa.
Secure SDLC -prosessi ("suojattu kehityssykli") on suunniteltu ylläpitämään sovellusten suojausta kehityksen ja käytön aikana.
Samanlainen osa näitä prosesseja on Vulnerability Assessment -prosessi - haavoittuvuuden arviointi, haavoittuvuuden tarkistus.
Suurin ero VM- ja SDLC-tarkistuksen välillä on, että ensimmäisessä tapauksessa tavoitteena on löytää tunnetut haavoittuvuudet kolmannen osapuolen ohjelmistoista tai kokoonpanosta. Esimerkiksi vanhentunut Windowsin versio tai oletusarvoinen yhteisömerkkijono SNMP:lle.
Toisessa tapauksessa tavoitteena on havaita haavoittuvuuksia ei vain kolmannen osapuolen komponenteissa (riippuvuuksissa), vaan ensisijaisesti uuden tuotteen koodissa.
Tämä aiheuttaa eroja työkaluissa ja lähestymistavoissa. Mielestäni tehtävä löytää uusia haavoittuvuuksia sovelluksesta on paljon mielenkiintoisempaa, koska se ei rajoitu versioiden sormenjälkiin, bannereiden keräämiseen, salasanan raa'an voiman käyttöön jne.
Laadukas automaattinen sovellushaavoittuvuuksien tarkistus vaatii algoritmeja, jotka ottavat huomioon sovelluksen semantiikan, sen tarkoituksen ja tietyt uhat.
Infrastruktuuriskanneri voidaan usein korvata ajastimella, kuten . Asia on siinä, että puhtaasti tilastollisesti voit pitää infrastruktuuriasi haavoittuvana, jos et ole päivittänyt sitä esimerkiksi kuukauteen.
Työkalut
Skannaus sekä turvallisuusanalyysi voidaan suorittaa mustana tai valkoisena laatikkona.
Black Box
Blackbox-skannauksessa työkalun on kyettävä toimimaan palvelun kanssa samojen rajapintojen kautta, joiden kautta käyttäjät työskentelevät sen kanssa.
Infrastruktuuriskannerit (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose jne.) etsivät avoimia verkkoportteja, keräävät "bannereita", tunnistavat asennetut ohjelmistoversiot ja etsivät tietokannastaan tietoja näiden versioiden haavoittuvuuksista. He yrittävät myös havaita määritysvirheet, kuten oletussalasanat tai julkisen pääsyn tietoihin, heikot SSL-salaukset jne.
Verkkosovellusskannerit (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP jne.) voivat myös tunnistaa tunnetut komponentit ja niiden versiot (esim. CMS, puitteet, JS-kirjastot). Tärkeimmät indeksoinnin vaiheet ovat indeksointi ja fuzzing.
Indeksoinnin aikana indeksointirobotti kerää tietoja olemassa olevista sovellusliittymistä ja HTTP-parametreista. Fuzzingin aikana kaikki havaitut parametrit korvataan mutatoiduilla tai luoduilla tiedoilla virheen aiheuttamiseksi ja haavoittuvuuden havaitsemiseksi.
Tällaiset sovellusskannerit kuuluvat DAST- ja IAST-luokkiin - vastaavasti Dynamic ja Interactive Application Security Testing.
valkoinen Box
Whitebox-skannauksessa on enemmän eroja.
Osana VM-prosessia skannereille (Vulners, Insecurity Couch, Vuls, Tenable Nessus jne.) annetaan usein pääsy järjestelmiin suorittamalla todennettu tarkistus. Näin skanneri voi ladata asennetut pakettiversiot ja konfigurointiparametrit suoraan järjestelmästä arvaamatta niitä verkkopalvelubannereista.
Skannaus on tarkempi ja täydellisempi.
Jos puhumme sovellusten whitebox-skannauksesta (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs jne.), niin puhumme yleensä staattisesta koodianalyysistä ja vastaavien SAST-luokan työkalujen käytöstä - Static Application Security Testing.
Ongelmat
Skannauksessa on monia ongelmia! Useimpien kanssa joudun olemaan tekemisissä henkilökohtaisesti osana skannaus- ja turvallisten kehitysprosessien rakentamispalvelua sekä turvallisuusanalyysityötä tehdessäni.
Nostan esiin 3 pääasiallista ongelmaryhmää, jotka vahvistavat myös keskustelut eri yritysten insinöörien ja tietoturvapäälliköiden kanssa.
Verkkosovellusten skannausongelmat
- Toteutuksen vaikeus. Skannerit on otettava käyttöön, konfiguroitava, mukautettava jokaiselle sovellukselle, osoitettava testiympäristö skannauksille ja otettava käyttöön CI/CD-prosessissa, jotta ne ovat tehokkaita. Muuten se on turha muodollinen menettely, joka antaa vain vääriä positiivisia tuloksia
- Skannauksen kesto. Skannerit tekevät jopa vuonna 2019 huonosti rajapintojen kopioimisen poistamisen ja voivat skannata tuhansia sivuja 10 parametrilla päivien ajan pitäen niitä erilaisina, vaikka niistä vastaa sama koodi. Samalla päätös tuotantoon siirtymisestä kehityssyklin sisällä on tehtävä nopeasti.
- Huonoja suosituksia. Skannerit antavat melko yleisiä suosituksia, eikä kehittäjä aina pysty nopeasti ymmärtämään niistä, miten riskitasoa voidaan pienentää, ja mikä tärkeintä, pitääkö se tehdä heti, vai ei se ole vielä pelottavaa
- Haitallinen vaikutus sovellukseen. Skannerit voivat helposti tehdä DoS-hyökkäyksen sovellukselle, ja ne voivat myös luoda suuren määrän entiteettejä tai muuttaa olemassa olevia (esimerkiksi luoda kymmeniätuhansia kommentteja blogiin), joten sinun ei kannata harkitsemattomasti suorittaa tarkistusta tuotteessa.
- Heikkolaatuinen haavoittuvuuden havaitseminen. Skannerit käyttävät yleensä kiinteää joukkoa hyötykuormia, ja ne voivat helposti missata haavoittuvuuden, joka ei sovi niiden tunnettuun sovelluskäyttäytymiseen.
- Skanneri ei ymmärrä sovelluksen toimintoja. Skannerit eivät itse tiedä, mitä "Internet-pankki", "maksu", "kommentti" on. Heille on olemassa vain linkkejä ja parametreja, joten valtava kerros mahdollisista liiketoimintalogiikkahaavoittuvuuksista jää täysin paljastamatta, he eivät arvaa tehdäkseen kaksinkertaista poistoa, kurkkiakseen muiden tietoja tunnuksella tai päättävänsä saldoa pyöristämällä.
- Skannerin ymmärtämä väärin sivun semantiikan. Skannerit eivät osaa lukea UKK:ta, eivät tunnista captcheja, he eivät arvaa itse, miten rekisteröityä ja sitten kirjautua uudelleen sisään, että et voi klikata "logout" ja kuinka allekirjoittaa pyyntöjä parametriarvoja muuttaessa. Tämän seurauksena suurin osa sovelluksista voi jäädä tarkistamatta ollenkaan.
Lähdekoodin skannausongelmat
- Väärät positiiviset. Staattinen analyysi on monimutkainen tehtävä, joka sisältää monia kompromisseja. Usein joudut uhraamaan tarkkuuden, ja jopa kalliit yritysskannerit antavat valtavan määrän vääriä positiivisia tuloksia.
- Toteutuksen vaikeus. Staattisen analyysin tarkkuuden ja täydellisyyden lisäämiseksi on tarpeen tarkentaa skannaussääntöjä, ja näiden sääntöjen kirjoittaminen voi olla liian aikaa vievää. Joskus on helpompaa löytää koodista kaikki paikat, joissa on jokin bugi ja korjata ne, kuin kirjoittaa sääntö tällaisten tapausten havaitsemiseksi.
- Riippuvuustuen puute. Suuret projektit riippuvat suuresta määrästä kirjastoja ja kehyksiä, jotka laajentavat ohjelmointikielen ominaisuuksia. Jos skannerin tietokannassa ei ole tietoa vaarallisista paikoista ("nieluista") näissä kehyksissä, tästä tulee sokea piste, eikä skanneri yksinkertaisesti edes ymmärrä koodia.
- Skannauksen kesto. Haavoittuvuuksien löytäminen koodista on vaikea tehtävä myös algoritmien kannalta. Siksi prosessi voi hyvinkin viivästyä ja vaatia merkittäviä laskentaresursseja.
- Matala kattavuus. Huolimatta resurssien kulutuksesta ja skannauksen kestosta, SAST-työkalujen kehittäjien on silti turvauduttava kompromisseihin ja analysoitava kaikkia tiloja, joissa ohjelma voi olla.
- Toistettavuuden löytäminen. Haavoittuvuuteen johtavaan tiettyyn linja- ja puhelupinoon osoittaminen on hienoa, mutta itse asiassa skanneri ei useinkaan anna tarpeeksi tietoa ulkoisen haavoittuvuuden tarkistamiseksi. Vika voihan olla myös kuolleessa koodissa, johon hyökkääjä ei pääse käsiksi.
Infrastruktuurin skannausongelmat
- Riittämätön varasto. Suurissa infrastruktuureissa, erityisesti maantieteellisesti erillään olevissa, on usein vaikeinta selvittää, mitkä isännät skannataan. Toisin sanoen skannaustehtävä liittyy läheisesti omaisuudenhoidon tehtävään.
- Huono priorisointi. Verkkoskannerit tuottavat usein monia tuloksia, joissa on puutteita, joita ei käytännössä hyödynnetä, mutta muodollisesti niiden riskitaso on korkea. Kuluttaja saa ilmoituksen, jota on vaikea tulkita, eikä ole selvää, mikä on ensin korjattava
- Huonoja suosituksia. Skannerin tietokanta sisältää usein vain hyvin yleistä tietoa haavoittuvuudesta ja sen korjaamisesta, joten järjestelmänvalvojien on aseistauduttava Googlen avulla. Tilanne on hieman parempi whitebox-skannereilla, jotka voivat antaa tietyn komennon korjattavaksi
- Käsintehty. Infrastruktuurissa voi olla useita solmuja, mikä tarkoittaa, että niissä saattaa olla monia puutteita, joista raportit on jäsennettävä ja analysoitava manuaalisesti jokaisen iteroinnin yhteydessä.
- Huono kattavuus. Infrastruktuuriskannauksen laatu riippuu suoraan haavoittuvuuksia ja ohjelmistoversioita koskevan tietokannan koosta. Jossa, , edes markkinajohtajilla ei ole kattavaa tietopohjaa, ja ilmaisten ratkaisujen tietokannassa on paljon sellaista tietoa, jota johtajilla ei ole
- Ongelmia paikannuksen kanssa. Useimmiten infrastruktuurin haavoittuvuuksien korjaaminen on paketin päivittämistä tai määritystiedoston vaihtamista. Suuri ongelma tässä on, että järjestelmä, varsinkin vanha järjestelmä, voi käyttäytyä odottamattomasti päivityksen seurauksena. Itse asiassa joudut suorittamaan integraatiotestejä live-infrastruktuurissa tuotannossa.
Lähestymistapoja
Miten voi olla?
Käsittelen yksityiskohtaisemmin esimerkkejä ja kuinka käsitellä monia näistä ongelmista seuraavissa osissa, mutta toistaiseksi osoitan tärkeimmät alueet, joilla voit työskennellä:
- Erilaisten skannaustyökalujen yhdistäminen. Useiden skannerien oikealla käytöllä voidaan saavuttaa merkittävä lisäys tietopohjaan ja havaitsemisen laatuun. Löydät jopa enemmän haavoittuvuuksia kuin kaikkien yksittäin suoritettavien skannerien summa, samalla kun voit arvioida riskitason tarkemmin ja antaa enemmän suosituksia
- SAST- ja DAST-integraatio. On mahdollista lisätä DAST-kattavuutta ja SAST-tarkkuutta jakamalla tietoja niiden välillä. Lähteestä saat tietoa olemassa olevista reiteistä ja DAST:n avulla voit tarkistaa, näkyykö haavoittuvuus ulkopuolelta
- Koneoppiminen™. Vuonna 2015 I (ja ) tilastojen käyttämisestä hakkereiden intuition antamiseen ja niiden nopeuttamiseen. Tämä on ehdottomasti ruokaa automatisoidun tietoturva-analyysin kehittämiselle tulevaisuudessa.
- IAST-integraatio automaattisten testien ja OpenAPI:n kanssa. CI/CD-putken sisällä on mahdollista luoda skannausprosessi, joka perustuu HTTP-välityspalvelimena toimiviin työkaluihin ja HTTP:n yli toimiviin toiminnallisiin testeihin. OpenAPI/Swagger testit ja sopimukset antavat skannerille puuttuvat tiedot tietovirroista, mahdollistavat sovelluksen skannauksen eri tiloissa
- Oikea kokoonpano. Jokaiselle sovellukselle ja infrastruktuurille on luotava sopiva skannausprofiili, jossa otetaan huomioon rajapintojen määrä ja luonne sekä käytetyt tekniikat
- Skannerin mukauttaminen. Usein sovellusta ei voida skannata ilman skanneria muuttamalla. Esimerkki on maksuyhdyskäytävä, jossa jokainen pyyntö on allekirjoitettava. Ilman liittimen kirjoittamista yhdyskäytäväprotokollaan skannerit näkevät mielettömästi pyyntöjä, joissa on väärä allekirjoitus. On myös tarpeen kirjoittaa erikoisskannereita tietyntyyppisiin puutteisiin, kuten
- Riskienhallinta. Erilaisten skannerien käyttö ja integrointi ulkoisiin järjestelmiin, kuten Asset Managementiin ja Threat Managementiin, mahdollistaa useiden parametrien käyttämisen riskitason arvioinnissa, jotta johto saa riittävän kuvan kehityksen tai infrastruktuurin nykyisestä turvallisuustilasta.
Pysy kuulolla ja keskeytetään haavoittuvuustarkistus!
Lähde: will.com