36C3 - The Case for Scale in Cyber Security

Karen: Vincezo Izzo on yrittäjä ja
sijoittaja jolla on fokus kyberturvallisuudessa. Hän

on aloittanut, hänet on ostettu, ja
hän on toistanut tämän muutaman kerran, ja nyt hän on

neuvonantaja joka opastaa ihmisiä yritysten
perustamisessa, ostetuksi tulemisessa, ja

sen toistamisessa. Hän on lisäksi johtaja
CrowdStrikellä ja hän on kumppani MIT Media

Labissä.
Tarkistan vain ajan varmistaakseni että

aloitamme ajoissa, ja tämä on, aloita
puhumaan nyt. Kyberturvallisuuden

skaalasta. Toivottakaa lämpimästi tervetulleeksi
Vincenzo.

Aplodeja

Vincenzo Izzo: Joten, hei, kaikki, kiitos kun
olette täällä. Kuten Karen sanoi, olen tehnyt

muutamia muutoksia urallani, mutta minun
taustani on alunperi tekninen, ja

mitä halusin tehdä tänään on puhua
trendistä jota pidämme ikäänkuin

itsestäänselvyytenä ja se on tiettyyn pisteeseen asti ilmeinen
mutta myös aliarvostettu. Ja se on

pilvialustojen skaala turvallisuudessa. Erityisesti
kun sanon pilvialustojen skaala, tarkoitan

kykyä prosessoida erittäin suuria määriä
informaatiota ja myös luoda laskentatehoa

helposti, ja millainen rooli sillä on ollut
alallamme viimeisellä vuosikymmenellä. Mutta

ennenkuin puhun siitä, luulen että jonkinlainen
konteksti on tärkeää. Joten tulin

alalle noin 15 vuotta sitten ja aikoinaan,
paikat kuten

kongressi olivat paljon pienempiä paikkoja. Ne olivat
tiettyyn pisteeseen asti mukavampia ja yhteisö

oli pieni. Ala oli melko kapea.
Sitten jotain tapahtui noin vuonna 2010.

Ihmiset alkoivat ymmärtää että
enemmän ja enemmän valtioiden rahoittamia hyökkäyksiä

tehtiin. Operaatio Aurorasta Googlea vastaan,
APT1:den Mandiant raporttiin, joka oli

ensimmäinen raportoitu asiakirja siitä miten Kiinan
PLA hakkeroi länttä- kutsutaan sitä

läntisen mailman infrastruktuuriksi IP varkauksille.
Ja se muutti paljon

alan osalta. On tapahtunut kaksi merkittävää
muutosta kaiken tämän huomion takia.

Ensimmäinen on pahamaineisuus. Menimme
kuten sanottua, suhteellisen tuntemattomasta

alasta johonkin sellaiseen josta jokainen
puhuu. Jos avaat minkä tahansa

sanomalehden, se sisältää lähes aina
artikkelin kyberturvallisuudesta, johtajisto puhuu

kyberturvallisuudesta... ja tietyssä mielessä,
taas, silloin kun liityin, kyberturvallisuus

ei ollut juttu. Sitä kutsuttiin nimellä
infosec. Nyt erittäin harvat ihmiset tietävät mitä

infosec edes tarkoittaa. Joten pahamaineisuus on yksi
asia, mutta pahamaineisuus ei ole ainut asia

joka muuttui. Toinen asia joka muuttui
on rahan määrä jota sektorilla

otettiin käyttöön. Eli, vuonna 2004, riippuen
arviosta johon luotat siellä, rahan

kokonais-käyttömäärä kyberturvallisuuteen oli väliltä
3.5 ja 10 miljardia dollaria.

Nykyään se on 120 miljardia dollaria. Ja siten
se tavallaan näyttää erittäin nopealta. Mutta

rahan kulutukseen tuli melkeinpä... Ikään kuin
erittäin merkittävä muutos sen osalta minkä tyyppisiä

pelureita alalla on nykyään.
Joten monet perinteisistä myyjistä jotka

myivät turvallisuuteen liittyviä sovelluksia ovat tavallaan
kadonneet. Ja mitä nykyisin on olemassa

on kahdenlaisia pelaajia laajalti. On olemassa
isoja teknologian myyjiä. Joten on olemassa

yrityksiä kuten Google, Amazon, Apple ja
niin edespäin, jotka ovat ikäänkuin

päättäneet suhtautua turvallisuuteen vakavammin.
Jotkut niistä yrittävät kaupallistaa

turvallisuutta. Jotkut yrittävät käyttää sitä
ikään kuin sloganina myydäkseen enemmän puhelimia.

Toinen ryhmä ihmisiä tai entiteettejä ovat
isoja pilvipohjaisia turvallisuusmyyjiä. Ja

mitä molemmilla ryhmillä on yhteistä, on se että
ne käyttävät enemmän ja enemmän

pilvialustojen skaalaa ja pilven resursseja yrittäessään
puuttua turvallisuus ongelmiin. Joten se mistä haluan

keskustella tänään on lähtöisin jokseenkin
teknisestä näkökulmasta, skaalamme on aiheuttanut

merkittäviä vaikutuksia siihen millä tavalla
lähestymme ongelmia, mutta myös siihen millaisia

ihmisiä meillä on alalla nykyään.
Joten mitä aijon tehdä on antaa teille muutamia

esimerkkejä muutoksista joita olemme
kokeneet. Ja yksi, mielestäni yksi

tärkeimmistä asioista jota pitää mielessä on
mitä skaala on tehnyt, ainakin

viime vuosikymmenellä, on että se on antanut puolustukselle
merkittävän edun hyökkäystä vastaan. Se ei ole

välttämättä tullut tänne jäädäkseen, mutta luulen että se on
tärkeä trendi joka on jokseenkin

unohdettu. Joten antakaa, kun aloitan päätepisteen
turvallisuuden osalta. Eli 80 luvulla, muutamat ihmiset

aloittivat leikittelemään ajatuksella IDS
järjestelmistä. Ja idea IDS järjestelmän taustalla

on melko suoraviivainen. Haluat
luoda lähtötason hyväntahtoista käytöstä

koneelle, ja sitten jos se kone alkaa
näyttää epänormaalia käytöstä, tulisit

merkkaamaan sen mahdollisesti haitaliseksi. Tämä
oli ensimmäinen tutkimus joka on julkaistu isäntään

perustuvista IDS järjestelmistä. Nyt, ongelma
isäntään perustuvissa IDS järjestelmissä on että ne eivät koskaan

tosiasiassa menestyneet kaupallisena
tuotteena. Ja syy tälle on… Oli

olemassa laajalti kaksi syytä tälle:
Ensimmäinen on se että oli erittäin vaikeaa

tulkita tuloksia. Eli oli erittäin vaikeaa
hoksata: ”Hei, tässä on poikkeama ja

tämän takia tämä poikkeama voi mahdollisesti olla
tietoturvasattuma.” Toinen ongelma

oli, että oli paljon vääriä positiivisia ja
oli tavallaan vaikeaa muodostaa hyväntahtoista

perustasoa yhdellä koneella, koska sen osalta
oli niin paljon vaihtelua miten yksittäinen

kone käyttäytyy. Joten mitä tapahtui on
että kaupallisesti me tavallaan jäimme jumiin

antiviruksien, antivirus myyjien, ja
allekirjoitusten kanssa todella pitkäksi aikaa. Nyt,

pikakelataan vuoteen 213. Kuten mainitsin, APT1
raportti tuli ulos ja Antivirus yritykset jopa

myönsivät että he eivät olleet niin hyödyllisiä
havaitsemaan asioita kuten Stuxnet tai Flame. Ja

sitten kaupunkiin ilmestyi ikäänkuin uusi
mies, ja muotisana sille oli

EDR. Joten, päätepisteen havaitseminen ja reaktio.
Mutta kun EDR erotellaan niinkuin

markkinoinnin nukasta, mitä EDR oikeastaan on, on
tosiasiassa isäntäpohjainen tunkeutumisen havaitsemis

järjestelmä skaala. Joten toisinsanoen, skaala
ja pilvien skaalauksen kyky on tehnyt mahdolliseksi

IDS järjestelmät kahdella tavalla.
Ensimmäinen tapa on että nyt itse asiassa on mahdollista

saada tietyn tyyppinen data-allas jossa on
lukuisia koneita, käytettävissä on paljon suurempia

tietoaineistoja kouluttamista ja havaitsemisen testaamisia varten.
MItä se tarkoittaa on, että on paljon helpompaa

määritellä suotuisa perustaso, ja on
paljon helpompaa aikaansaada kunnon havaitsemista, jotta

ne eivät havaitse pelkästään haittaohjelmia, vaan myös
ikäänkuin haittaohjelmittomia hyökkäyksiä.

toinen juttu on että EDR myyjät ja myös
Yrityksillä joilla on sisäiset EDR järjestelmät

omaavat suurelta osin skaalaetua.
Ja mitä se tarkoittaa on että teillä voi

olla tiimi analyytikkoja jotka voivat luoda
selityksiä ja tavallaan filosofiaa jolla

selittää millä tavalla jokin tietty havainto voi itseasiassa
esittää turvallisuustapahtumaa. Sen lisäksi

koska teillä on nyt data-altaita, te
voitte nyt louhia sitä tietoa varten

jolla voitte keksiä uusia hyökkäyskaavoja joista te
ette olleet tietoisia menneisyydessä. Joten tämä

itsessään on melko merkittävä
saavutus, koska olemme viimeinkin onnistuneet

siirtymään pois allekirjoituksista johonkin sellaiseen
joka toimii paljon paremmin ja pystyy

havaitsemaan laajemman alueen hyökkäyksiä. Mutta
toinen juttu jonka EDR järjestelmä ratkaisi,

tavallaan sivuvaikutuksena, on datan
jakamisen ongelman. Joten, jos olet ollut

alalla pitkään, on ollut
useita yrityksiä jakaa uhkiin liittyvää dataa

erilaisten tahojen välillä ja ne kaikki
tavallaan epäonnistuivat koska oli todella vaikeaa

perustaa tavallaan protokolla jolla
jakaa sitä dataa. Mutta epäsuorasti, mitä EDR

on tehnyt, on pakottaa ihmisiä jakamaan ja
keräämään uhkatiedustelun dataa ja vain

yleisellä tasolla olevaa dataa päätepisteistä. Joten nyt
myyjät ovat muuttuneet tavallaan

epäsuorasti luotetuksi kolmanneksi osapuoleksi joka voi
käyttää sitä dataa havaintojen kirjoittamiseksi joita

voidaan käyttää kaikissa järjestelmissä, ei pelkästään
yksittäisissä yrityksissä tai yksittäisissä

koneissa. Ja sen tulos siitä,
seuraus siitä on meemi että

hyökkääjän tarvitsee vain onnistua siinä
kerran ja että puolustajan tarvitsee onnistua

aina mikä itseasiassa ei ole niin
totta enää, koska menneisyydessä olitte

tilanteessa jossa jos teillä oli
hyökkäävä infrastruktuuri, olipa se

palvelimet, olipa se hyväksikäyttöketju,
voisitte useimmiten käyttää niitä uudelleen

uudestaan ja uudestaan. Vielä jos teillä olisi
haittaohjelmia, teidän tarvitsisi ainoastaan hieman

muuntaa näytettä ja läpäisisitte minkä
tahansa havaitsemisen. Mutta nykyään se ei ole

enää totta useimmiten. Jos teidät
havaitaan yhdellä koneella, yhtäkkiä

kaikki teidän hyökkäys
infrastruktuurinne täytyy romuttaa ja teidän

täytyy aloittaa alusta. Joten tämä on
ensimmäinen esimerkki ja on mielestäni itsessään

melko merkittävä. Toinen esimerkki josta
haluan puhua on fuzzaus. Ja

fuzzaus on mielenkiintoista myös muusta
syystä, joka on se että se antaa meille vilkaisun

siihen miltä luulen tulevaisuuden näyttävän.
Koska olette luultavasti tulleet tutuksi, jos

olette tehneet yhtään sovelluksen kaltaisia töitä
menneisyydessä, fuzzing on ollut tavallaan

päätuote sovelluksen kaltaisissa arsenaaleissa erittäin
pitkään. Mutta menneisyydessä, luultavasti noin viidessä

vuodessa, fuzzing on kokenut eräänlaisen
renesanssin siinä mielessä että kaksi

asiaa on muuttunut. Kaksi asiaa on
parantunut suuresti. Ensimmäinen on että

onnistuimme viimeinkin löytämään paremman tavan
arvioida sopivuustoimintoa jota käytämme

fuzzingin ohjaamisessa. Joten muutama vuosi sitten,
joku nimeltä Michal Zalewski julkaisi

fuzzaajan nimeltä AFL, ja yksi ensisijaisista
intuitioista AFL:n takana oli että pystyitte

itseasiassa sen sijaan että käyttäisitte koodin kattavuutta
fuzzerin ajamiseen, käyttämään polun

kattavuutta fuzzerin ajamiseen ja se
muutti fuzzingin enemmän, tiedättekö,

enemmän tehokkaaksi välineeksi bugien
löytämiseen. Mutta seuraava intuitio jonka luulen

olevan vielä tärkeämpi ja joka
muutti fuzzingia merkittävästi on fakta

mikä tulee fuzzingiin liittyen, nopeus
on paljon tärkeämpää kuin äly. Tiedättekö,

tavallaan. Ja mitä tarkoitan tällä on että
kun katsotte AFL:ää, AFL esimerkkinä,

on äärimmäisen tyhmä fuzzer. Se tekee asioita
kuten tavujen flippaamista, bittien flippaamista. Sillä on

erittäin, erittäin yksinkertaisia strategioita muuntautumiselle.
Mutta mitä AFL tekee erittäin hyvin on, se on

äärimmäisen optimoitu kappale C koodia ja se
skaalautuu erittäin hyvin. Joten jos olette

tilanteessa jossa teillä on kohtuullisen
hyvä palvelin, jolla voitte ajaa AFL:ää, te

voitte syntetisoida erittäin monimutkaisia tiedostoformaateja
erittäin vähäisillä iteraatioilla. Ja mitä pidän

hämmästyttävänä on että tämän havainto
ei päde pelkästään tiedosto formaatteihin. Tämä

havainto pätee myös moniin vielä monimutkaisemman
olotilan koneisiin. Joten toinen esimerkki josta

haluan puhua fuzzingiin liittyen, on
ClusterFuzz. ClusterFuzz on

fuzzing ohjelma jota Chromen tiimi käyttää
bugien löytämiseen Chromessa ja ClusterFuzz on

ollut maisemissa noin kuusi vuotta.
Kuuden vuoden jaksolla ClusterFuzz löysi

kuusitoista tuhatta bugia pelkästään Chromessa,
plus yksitoista tuhatta muuta bugia

joukossa avoimen lähdekoodin projekteja. Jos
vertaatte ClusterFuzzia toiseksi eniten

onnistuneisiin fuzzereihin joita on olemassa
JavaScript moottoreille, huomaatte että

toiseksi tullut fuzzer nimeltään jsfunfuzz löysi noin
kuusi tuhatta bugia aikajaksolla kahdeksasta

yhdeksään vuoteen. Ja jos katsotte koodia,
isoin ero näiden kahden välillä ei ole

muuntautumismoottori. Muuntautumismoottori
on itseasiassa melko samankaltainen. Ne eivät...

ClusterFuzz ei tee mitään
erityisen hienoa, mutta mitä ClusterFuzz

Tekee erittäin hyvin on että se skaalautuu suuresti.
Joten ClusterFuzz käyttää nykyään noin kaksikymmentäviisi

tuhatta ydintä. Joten fuzzauksessa
olemme sillä tasolla jossa bugien suoltaminen

on niin korkeaa että puolustuksella on jälleen
etu verrattuna hyökkäykseen koska

bugien korjaamisesta tulee paljon nopeampaa kuin
hyväksikäyttöketjujen korjaamisesta, mikä olisi

ollut käsittämätöntä vain muutama vuosi
sitten. Viimeinen esimerkki jonka haluan nostaa

esille on hieman erilainen. Eli, muutama
kuukausi sitten, Googlen TAG joukkue löysi

erämaasta palvelimen jota käytettiin
vesiaukko hyökkäyksessä, ja siitä ajateltiin

että palvelinta oli käytetty Kiinalaisia
Muslimi toisinajattelijoita vastaan. Mutta mikä on kiinnostavaa

on että se tapa jolla havaitsisitte tällaisen
hyökkäyksen menneisyydessä on että teillä olisi

vaarantunut laite ja te tulisitte
tavallaan työskentelemään takaperin siitä.

Yrittäisitte keksiä miten laite
on vaarantunut. Mikä on kiinnostavaa on

että tapa jolla he löysivätpalvelimen oli
tosiasiassa louhia heidän paikallista kopiota

Internetistä. Ja niin, taas, tämä on
taas yksi esimerkki skaalasta joka antaa heille

merkittävää etua puolustuksessa vastaan
hyökkäys. Joten, kaikissa näissä esimerkeissä

joita nostin esille, luulen että kun katsotte
niitä tarkemmin, ymmärrätte että ei ole niin

että turvallisuuden tila olisi
parantunut koska olisimme välttämättä tulleet

paremmaksi turvallisuudessa. Se on parantunut
koska olemme tulleet paremmaksi käsittelemään

suuria määriä dataa, tallentamaan suuria
määriä dataa, ja poikimaan laskenta

tehoa ja resursseja nopeasti tarvittaessa.
Joten, jos se on totta, sitten yksi...

muu ymmärrettävä asia on että monissa
näistä tapauksista, kun katsotte edellisiä

esimerkkejä joita toin esille, se on
itseasiassa niin että skaala näyttää

paljon erilaisemmalta ongelmaan liittyen
paljon pienemmällä skaalalla, ja ratkaisu

lopputuloksena on hyvin erilainen. Joten aijon
käyttää hassua esimerkkiä yrittääkseni ajaa

asian kotiin. Sanotaan että teidän työ on
auditoida tätä ominaisuutta. Ja teidän tarvitsee

löytää bugeja siinä. Jos
C koodi ei ole teille tuttu,

tässä ongelmaksi muodostuu että voitte ylivuotaa
tai alivuotaa puskuria mielenne mukaan

vain syöttämällä satunnaisen arvon "pos".
Nyt, jos manuaalisesti auditoisitte

tämän asian, tai jos työnne olisi auditoida
tämä funktio, selvästi, voisitte käyttää... teillä

olisi monia työkaluja joita voisitte käyttää. Te
voisitte tehdä manuaalista koodin auditointia. Voisitte

käyttää symbolista suoritusmoottoria. Voisitte
käyttää fuzzeria. Voisitte käyttää staattista

analyysiä.