Jeff Williams, OWASP:n ja Contrast Securityn perustaja ja CTO – Haastattelusarja

Jeff Williams, OWASP:n perustaja ja Contrast Securityn perustaja ja CTO, on laajalti tunnustettu yksi vaikuttavimmista hahmoista modernissa sovellus turvallisuudessa. Viimeisten useiden vuosikymmenien aikana hän on auttanut muotoilemaan, miten organisaatiot lähestyvät turvallista ohjelmistokehitystä, haavoittuvuuden hallintaa ja suorituksen aikaisen sovelluksen suojaa. Williamsilla oli keskeinen rooli rakentamassa OWASP:ia pienestä vapaaehtoisesta aloitteesta maailmanlaajuisesti tunnustetuksi turvallisuus säätiöksi, osallistuen merkittäviin projekteihin kuten OWASP Top Ten, WebGoat, ESAPI, ASVS ja XSS Prevention Cheat Sheet. Ennen Contrast Securityn perustamista vuonna 2014 hän perusti myös Aspect Securityn, yhden varhaisimmista yrityksistä, jotka omistautuivat yksinomaan sovellusten turvallisuuden konsultoinnille, koulutukselle, penetraatiotestaukselle ja turvallisen kehityksen käytännöille yrityksille.

OWASP on voittoa tavoittelematon säätiö, joka keskittyy parantamaan ohjelmistoturvallisuutta avoimien lähteiden projektejen, globaalin yhteisön yhteistyön, koulutuksen ja teollisuuden standardien kautta. Perustettu vuonna 2001, organisaatio on tullut yhdeksi tärkeimmistä viranomaisista sovellusten turvallisuudessa, sadoilla paikallisilla luvilla, tuhansilla osallistujilla ja laajalti hyväksyttyjen resurssien kanssa, joita kehittäjät, turvallisuus ammattilaiset, yritykset ja hallitukset käyttävät maailmanlaajuisesti. OWASP on parhaiten tunnettu projekteista kuten OWASP Top Ten, joka tunnistaa kriittisimmät web-sovelluksen turvallisuus riskit, useiden turvallisuus kehyksien, testaus työkalujen, dokumentaatio projektejen ja koulutus aloitteiden ohella. Organisaatio toimii myyntipolitiikalla, joka tekee koulutus resursseja ja turvallisuus ohjeita vapaasti saatavilla globaalille teknologiayhteisölle.

Contrast Security on sovellusten turvallisuus yritys, joka keskittyy suojelemaan ohjelmistoa itse suoritettavasta sovelluksesta sen sijaan, että se riippuisi ainoastaan ulkoisista skannaus työkaluista. Yrityksen alusta käyttää suorituksen aikaisen instrumentaation teknologiaa tarjoamaan reaaliaikaisen näkyvyyden haavoittuvuuksiin, hyökkäyksiin, API:hin, avoimen lähdekoodin riippuvuuksiin ja sovelluksen käyttäytymiseen kehitys- ja tuotantoympäristöissä. Sen tarjonta kattaa alueita kuten Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) ja ohjelmiston koostumisen analyysi. Contrast Security on asettanut itsensä yhdistämään turvallisuuden suoraan moderniin DevSecOps -työkiertoon, mahdollistaen kehittäjille, AppSec -joukoille ja turvallisuus operaatiotiimille tunnistaa ja korjata haavoittuvuuksia nopeammin ylläpitäen nopeita ohjelmistojakelukykyjä.

Autettuasi muotoilemaan modernia sovellusten turvallisuutta työskentelylläsi avoimen web-sovelluksen turvallisuus projektin (OWASP) parissa, mikä aukko teollisuudessa johti sinut perustamaan Contrast Securityn, ja miten alkuperäinen teesi on kestänyt turvallisuus haasteiden kehittyessä?

Teollisuus oli hukkumassa teoreettisiin staattisiin löydöksiin eikä pystynyt keskittymään niitä asioita, jotka todella merkitsevät. Turvallisuus tiimit olivat saaneet skannereiden avulla valtavat takaiskut ilman tietoa siitä, mitkä haavoittuvuudet olivat saavutettavissa, hyökkäyksille alttiita tai hyökkäyksien kohteena tuotannossa. Perustimme Contrastin yksinkertaiselle idealle: turvallisuus päätökset tulisi tulla suoraan havainnoimasta itse suoritettavasta sovelluksesta, eikä arvaamalla ulkoa.

Lopulta toivon, että teollisuus edistyy siihen pisteeseen, jossa pääsemme pois hamsterin pyörästä ongelmien löytämisestä, korjaamisesta ja uusien löytämisestä ikuisesti. Toivon, että voimme aloittaa turvallisen ohjelmiston luomisen, jolla on vahva turvallisuus arkkitehtuuri ja todellinen argumentti siitä, että sillä on oikeat puolustukset odotetuille uhille. Suorituksen aikaisen turvallisuuden ja tekoälyn yhdistelmällä on potentiaalia, mutta olemme vuosia siitä.

Olet kuvannut “mytologisen tason” haavoittuvuuksien syntymisen. Mitä määrittelee tämän uuden riskin luokan, ja miksi ne ovat niin vaikeita perinteisten turvallisuus työkalujen havaitseville?

Mytologisen tason haavoittuvuudet ovat virheitä, jotka syntyvät modernin ohjelmistopinon monimutkaisuudesta. Yhteys kehyksen käyttäytymisen, riippuvuuksien ja arkkitehtonisten mallien välillä on niin monimutkainen, että kehittäjät usein eivät ymmärrä sitä täysin. Perinteiset työkalut ovat edelleen optimoituja suhteellisen yksinkertaisiin tunnettuihin malleihin ja havaittaviin tapahtumiin. Mytologisen tyyppiset haavoittuvuudet usein vaativat sovelluksen käyttäytymisen, suorituksen virtausta ja suorituksen aikaisen kontekstin ymmärtämistä paljon syvemmällä tasolla.

Miksi kokonaiset haavoittuvuuksien luokat eivät laukaista hälytyksiä modernissa turvallisuus operaatiokeskuksissa (SOC), ja mitä se paljastaa siitä, miten turvallisuus tiimit mitattavat nykyisin riskiä?

Useimmat SOC:t ovat rakennettu havaittavien tapahtumien ympärille: lokit, signatuurit, verkkoliikenne, päätepistetoiminta. Mutta monet sovelluskerroksen hyökkäykset eivät tuota merkittäviä signaaleja näissä järjestelmissä. Kehittäjä ei tiennyt haavoittuvuudesta eikä lisännyt lokimerkintöjä, jotka paljastaisivat hyökkäyksen. Joten useimmat sovelluksen hyökkäykset ovat täysin näkymättömiä lokissa. SOC -tiimit voivat vain reagoida siihen, mitä he voivat nähdä. Niinpä sovellus- ja API -kerroksen tultua yhä tärkeämmäksi on kriittinen varustaa se turvallisuus antureilla, jotka voivat havaita ja raportoida epänormaalia käyttäytymistä.

Modernit sovellus arkkitehtuurit, kuten mikropalvelut, API:t ja serverless -järjestelmät, ovat kehittyneet nopeasti. Missä nämä arkkitehtuurit jättävät nykyiset havaintopohjaiset turvallisuus lähestymistavat?

Nämä arkkitehtuurit rikkoivat vanhan reuna mallin. Pyynnöt kulkevat nyt kymmenien palvelujen, eheiden funktioiden, API:en, jonon ja kolmannen osapuolen riippuvuuksien läpi ennen kuin ne suorittavat transaktion. Useimmat havaintojärjestelmät näkevät edelleen paloja eikä kokonaisia suoritus polkuja. Ne voivat tarkastella paketteja tai lokitiedostoja, mutta eivät ymmärrä aikomusta, tietovirtaa tai sitä, onko vaarallinen koodi todella suoritettu. Turvallisuus on kontekstista, joten meidän on rakennettava malli, digitaalinen kaksoiskappale, sovellus infrastruktuuristamme, joka mahdollistaa meille (tai tekoäly agentteja) päättelyä siitä, mitä me näemme tapahtuvan.

OWASP Top Ten jatkaa korostamista asioita kuten epäturvaallinen suunnittelu ja haavoittuvat komponentit. Miksi nämä riskit säilyvät laajasti tunnetuista ja työkaluista huolimatta?

Tietoisuus ei korjaa kannustimia tai monimutkaisuutta. Useimmat organisaatiot mitattavat edelleen menestystä skannaus määrän, lipun sulkemisen tai vaatimusten täyttymisen perusteella eikä todellista altistumisen vähentämistä.

Samalla ohjelmistojen toimitusketjut räjähtivät kooltaan. Kehittäjät kokoavat sovellukset tuhansista komponenteista, joita he eivät ole kirjoittaneet ja joita he eivät ole arvioineet turvallisuuden kannalta. Turvallisuus tiimit ovat ylitsepäänsä yrittäessään karsia teoreettisia riskejä eivätkä voi keskittyä 1-2 %:iin, jotka todella merkitsevät. Ilman suorituksen aikaisia todisteita, priorisointi menee rikki. Ja voimakkaiden tekoäly mallien ja käsittelyjen myötä tilavuus kasvaa eksponentiaalisesti.

Miten organisaatioiden tulisi uudelleenarvioida riippuvuuttaan lokien ja hälytysten suhteen, kun jotkut kriittisimmistä haavoittuvuuksista eivät jätä näkyviä merkkejä?

Lokit ovat todisteita siitä, mitä sovellukset valitsevat raportoida, eivät välttämättä todisteita siitä, mitä todella tapahtuu. Se on vaarallinen ero. Organisaatioiden on siirryttävä epäsuorasta havainnosta suoraan havainnoimiseen. Sen sijaan, että toivovat hyökkäyksen luovan havaittavan artefaktin, turvallisuus järjestelmien on tunnistettava haavoittuvat käyttäytymiset ja hyökkäyskäyttäytyminen suorituksen aikana. Jos vaarallinen koodi suoritetaan, järjestelmän on tiedettävä siitä välittömästi – riippumatta siitä, onko lokimerkintä olemassa.

Olet puolustanut suorituksen aikaisen näkyvyyden ratkaisua. Mitä todellinen suorituksen aikainen näkyvyys näyttää käytännössä, ja miten se muuttaa turvallisuus tiimien toimintaa päivittäin?

Todellinen suorituksen aikainen näkyvyys tarkoittaa ymmärtämistä siitä, mitä sovellus todella tekee tuotannossa: mitkä reitit ovat alttiina, mitkä kirjastot ovat aktiivisia, minne herkkä tieto virtaa, mitä koodia suoritetaan ja onko hyökkäys saavuttanut haavoittuvan toiminnallisuuden. Toiminnallisesti se muuttaa turvallisuutta reaktiivisesta metsästys harjoituksesta tarkkuuslajiin. Tiimit lopettavat jahdaten valtavat haavoittuvuus takaiskut ja alkavat keskittyä pienen prosentin altistumiseen, joka on saavutettavissa, kriittistä ja aktiivisesti kohdistettua. Se parantaa merkittävästi signaali-kohina suhdetta ja reagointi nopeutta. Keskimäärin vain 38 % avoimen lähdekoodin kirjastoista, jotka on pakattu sovellukseen, ladataan muistiin ja suoritetaan. Ja ei kaikki koodi tässä alajoukossa ole käytössä. Niinpä yksi yksinkertainen asia, jonka suorituksen aikainen turvallisuus mahdollistaa, on keskittyminen koodiin, joka todella suoritetaan, eikä kaikkiin käyttämättömiin kirjastoihin ja funktioihin, jotka tulevat sovelluksen mukana.

Miten instrumentaatio perustuva turvallisuus vertautuu perinteisiin lähestymistapoihin, kuten SAST, DAST tai reuna seuranta, tehokkuuden ja skaalautuvuuden suhteen?

Perinteiset työkalut johtavat riskiä ulkoa. Instrumentaatio havainnoi todellisuutta havainnoimalla itse koodin suorittamisen. Instrumentaatio voi nähdä todelliset suoritus polut, kehyksen käyttäytymisen, todennus kontekstin, tietovirran ja hyökkäyksen onnistumisen reaaliajassa. Se poistaa valtavat kategoriat vääriä positiivisia ja paljastaa haavoittuvuuksia, joita reuna työkalut kokonaan väistävät. Skaalautuvuuden suhteen tämä tarkkuus on kriittistä. Organisaatiot eivät voi enää manuaalisesti karsia miljoonia teoreettisia löytöjä. Suorituksen aikaiset todisteet tulevat ainoaksi kestäväksi suodattimeksi. Suorituksen aikainen toiminta on parempi sopiva kehitys- ja CI/CD -putkistoihin kuin skannaus ja karsinta. Ja suorituksen aikainen toiminta on jatkuva, joten et ole rajoitettu yksittäiseen kohtaan aikajanassa turvallisuuden näkymään.

Kun tekoäly järjestelmät ja autonomiset sovellukset tulevat yleisemmiksi, tulevatko nämä näkymättömät haavoittuvuudet vaarallisemmiksi, ja miten tiimit tulisi valmistautua?

Teckoäly tekee näkymättömistä haavoittuvuuksista paljon vaarallisempia, koska se kiihdyttää molempia ongelmien puolia. Kehittäjät luovat ohjelmistoa nopeammin, ja hyökkääjät löytävät ja hyökkäävät heikkouksiin nopeammin. Mutta useimmat turvallisuus ohjelmat riippuvat edelleen ihmisen osallistumisesta prosesseissa, jotka eivät voi toimia tekoälyn nopeudella. Tiimit tulisi valmistautua kahtella tavalla. Ensinnäkin, rakentaa vahvemmat suorituksen aikaiset puolustukset, jotka voivat havaita, estää ja rajoittaa hyökkäyksiä tuotannossa haavoittuvuuksia korjattaessa. Se antaa organisaatioille ilmasuojan. Toiseksi, käytä tekoälyä ja automaatiota kirjoittamaan turvallisempaa koodia alusta alkaen – paremmalla suunnittelulla, testauksella, tarkastelulla ja verifioinnilla. Muuten luomme riskejä nopeammin kuin voimme hallita.

Jos olisit neuvomassa modernia turvallisuus operaatiokeskuksen (SOC) johtajaa tänään, mitkä ovat ensimmäiset konkreettiset toimet, joita heidän tulisi tehdä sulkeakseen tämän näkyvyyden aukon ennen kuin se johtaa suureen vuotoon?

Ensinnäkin, hyväksy, että reuna telemetria yksin on riittämätön modernille sovellusten turvallisuudelle. Itse asiassa on mahdotonta nähdä tai estää monia sovellus- ja API -hyökkäyksiä reuna alueella. SOC: n on oltava näkyvyyttä suoritettavissa sovelluksissa, eikä ainoastaan infrastruktuurissa, joka isännöi niitä. Toiseksi, priorisoi suorituksen aikaiset todisteet teoreettisista löydöistä. Keskity haavoittuvuuksiin, jotka ovat aktiivisessa koodissa, tunnista aktiiviset hyökkäysreitit ja paljastetut palvelut, jotka suoritetaan todella tuotannossa. Lopulta, yhdistä sovellusten turvallisuuden ja havainto suunnittelun. Tulevaisuuden SOC ei voi enää käsitellä sovelluksia läpinäkymättöminä mustina laatikoina. Sovellukset ovat nyt ensisijainen hyökkäyspinta-ala, ja ne tarvitsevat ensiluokkaisen näkyvyyden suorituksen aikana.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla OWASP: ssä tai Contrast Security: ssä.