Av Techopedia Staff, 27. oktober 2016
Takeaway: Vert Eric Kavanagh diskuterer databasesikkerhet med Robin Bloor, Dez Blanchfield og IDERAs Ignacio Rodriguez.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Hei og velkommen tilbake til Hot Technologies. Jeg heter Eric Kavanagh; Jeg vil være din vert for webcasten i dag, og det er et hett tema og det kommer aldri til å bli et hett tema. Dette er et hett tema nå på grunn av ærlig talt alle bruddene vi hører om, og jeg kan garantere deg at det aldri kommer til å forsvinne. Så emnet i dag, den nøyaktige tittelen på showet jeg burde si, er “The New Normal: Dealing with Reality of a Usecure World.” Det er akkurat det vi har å gjøre med.
Vi har din vert, din virkelig, akkurat der. Fra noen få år siden burde jeg nok oppdatere bildet mitt. det var 2010. Tiden flyr. Send meg en e-post med hvis du vil komme med noen forslag. Så dette er vår vanlige "hot" lysbilde for Hot Technologies. Hele hensikten med dette showet er virkelig å definere et bestemt rom. Så i dag snakker vi åpenbart om sikkerhet. Vi tar en veldig interessant vinkel på det, faktisk, med våre venner fra IDERA.
Og jeg vil påpeke at du som publikumsmedlemmer spiller en betydelig rolle i programmet. Vær ikke sjenert. Send oss et spørsmål når som helst, så står vi i kø for spørsmål og svar hvis vi har nok tid til det. Vi har tre mennesker online i dag, Dr. Robin Bloor, Dez Blanchfield og Ignacio Rodriguez, som ringer inn fra et ikke avslørt sted. Så først og fremst, Robin, du er den første programlederen. Jeg gir deg nøklene. Ta den bort.
Dr. Robin Bloor: Ok, takk for det, Eric. Sikring av database - Jeg antar at vi kan si at sannsynligheten for at de mest verdifulle dataene som noe selskap faktisk presiderer over er i en database. Så det er en hel serie sikkerhets ting vi kan snakke om. Men det jeg trodde jeg skulle gjøre, er å snakke rundt temaet for å sikre databasen. Jeg vil ikke ta noe bort fra presentasjonen som Ignacio kommer til å gi.
Så la oss starte med, det er lett å tenke på datasikkerhet som et statisk mål, men det er det ikke. Det er et bevegelig mål. Og dette er litt viktig å forstå i den forstand at de fleste menneskers IT-miljøer, særlig store selskapets IT-miljøer, endrer seg hele tiden. Og fordi de endrer seg hele tiden, endres angrepsoverflaten, områdene der noen kan prøve på en eller annen måte, enten fra innsiden eller utsiden, til å kompromittere datasikkerheten, hele tiden. Og når du gjør noe sånt, oppgraderer du en database, har du ingen anelse om du bare har opprettet en slags sårbarhet for deg selv. Men du er ikke klar over og kanskje aldri finne ut av det før noe elendig skjer.
Det er en kort oversikt over datasikkerhet. For det første er datatyveri ikke noe nytt, og data som er verdifulle er målrettet. Det er normalt enkelt å jobbe for en organisasjon hva dataene de trenger å sette mest beskyttelse på er. Et merkelig faktum er at den første, eller det vi kan hevde å være den første datamaskinen, ble bygget av britisk etterretning under den andre verdenskrig med ett formål for øye, og det var å stjele data fra tysk kommunikasjon.
Så datatyveri har vært en del av IT-bransjen ganske mye siden det begynte. Det ble mye mer alvorlig med fødselen av internett. Jeg så på en logg over antall datainnbrudd som skjedde år etter år etter år. Og antallet hadde raket over 100 innen 2005 og fra det tidspunktet hadde det en tendens til å bli verre og verre for hvert år.
Større mengder data blir stjålet og et større antall hacks finner sted. Og det er hacks som blir rapportert. Det er et veldig stort antall hendelser som skjer der selskapet aldri sier noe fordi det ikke er noe som tvinger det til å si noe. Så det holder datainnbruddet stille. Det er mange aktører i hackingvirksomheten: regjeringer, bedrifter, hackergrupper, enkeltpersoner.
En ting som jeg bare synes det er interessant å nevne, da jeg dro til Moskva, tror jeg det var en gang for rundt fire år siden, det var en programvarekonferanse i Moskva, jeg snakket med en journalist som spesialiserte seg innen datahacking. Og han hevdet - og jeg er sikker på at han har rett, men jeg vet ikke det annet enn at han er den eneste personen som noensinne har nevnt det for meg, men - det er en russisk virksomhet som heter The Russian Business Network, den har sannsynligvis en russisk navn, men jeg tror det er den engelske oversettelsen av den, som faktisk er ansatt for å hacke.
Så hvis du er en stor organisasjon hvor som helst i verden og vil gjøre noe for å skade konkurransen din, kan du ansette disse menneskene. Og hvis du ansetter disse menneskene, får du veldig sannsynlig fornøyelighet med hensyn til hvem som var bak hackingen. For hvis det i det hele tatt blir oppdaget hvem som er bak hackingen, vil det indikere at det sannsynligvis er noen i Russland som gjorde det. Og det vil ikke se ut som om du prøvde å skade en konkurrent. Og jeg tror at The Russian Business Network faktisk har blitt ansatt av regjeringer for å gjøre ting som å hacke seg inn i banker for å prøve å finne ut hvordan terroristpenger beveger seg rundt. Og det gjøres med plausibel avvikelighet fra regjeringer som aldri vil innrømme at de faktisk har gjort det.
Teknologien til angrep og forsvar utvikler seg. For lenge siden gikk jeg til Chaos Club. Det var et nettsted i Tyskland hvor du kunne registrere deg, og du bare kunne følge samtalene til forskjellige mennesker og se hva som var tilgjengelig. Og det gjorde jeg da jeg så på sikkerhetsteknologi, tror jeg rundt 2005. Og jeg gjorde det bare for å se hva som gikk ned da, og det som overrasket meg var antallet virus, der det i utgangspunktet var et open-source system Jeg var på gang, og folk som hadde skrevet virus eller forbedrede virus bare stakk koden der oppe for noen å bruke. Og det skjedde for meg den gangen at hackere kan være veldig, veldig smarte, men det er utrolig mange hackere som ikke nødvendigvis er smarte i det hele tatt, men de bruker smarte verktøy. Og noen av disse verktøyene er bemerkelsesverdig smarte.
Og det siste poenget her: bedrifter har en plikt til å ta vare på dataene sine, enten de eier dem eller ikke. Og jeg tror det blir mer og mer realisert enn det pleide å være. Og det blir mer og mer, la oss si, dyrt for en bedrift å faktisk gjennomgå et hack. Om hackerne kan de være plassert hvor som helst, kanskje vanskelig å bringe for retten selv om de er korrekt identifisert. Mange av dem veldig dyktige. Betydelige ressurser, de har botnett overalt. Det nylige DDoS-angrepet som skjedde antas å ha kommet fra over en milliard enheter. Jeg vet ikke om det er sant eller om det bare er en reporter som bruker et rundt nummer, men absolutt ble et stort antall robotenheter brukt til å angripe DNS-nettverket. Noen lønnsomme bedrifter, det er regjeringsgrupper, det er økonomisk krigføring, det er cyberwarfare, alt skjer der ute, og det er usannsynlig, tror jeg vi sa i preshowet, det vil neppe ende.
Overholdelse og forskrifter - det er en rekke ting som faktisk foregår. Det er mange samsvarsinitiativer som er sektorbasert, du vet - legemiddelsektoren eller banksektoren eller helsesektoren - kan ha spesifikke initiativer som folk kan følge, ulike typer beste praksis. Men det er også mange offisielle forskrifter som fordi de er lov, har straff for alle som bryter loven. De amerikanske eksemplene er HIPAA, SOX, FISMA, FERPA, GLBA. Det er noen standarder, PCI-DSS er en standard for kortselskaper. ISO / IEC 17799 er basert på å prøve å få en felles standard. Dette er eierskap til data. Nasjonale forskrifter skiller seg fra land til land, også i Europa, eller man burde kanskje si, særlig i Europa der det er veldig forvirrende. Og det er en GDPR, en global databeskyttelsesforordning som nå forhandles mellom Europa og USA for å prøve å harmonisere i forskrifter fordi det er så mange, ofte som de faktisk er internasjonale, og så er det skytjenester som du kanskje tror ikke dataene dine var internasjonale, men de gikk internasjonale så snart du gikk inn i skyen, fordi de flyttet ut av landet ditt. Så dette er et regelverk som forhandles på en eller annen måte for å håndtere databeskyttelse. Og det meste av dette har å gjøre med dataene til en person, som selvfølgelig inkluderer ganske mye alle identitetsdata.
Ting å tenke på: sårbarheter i databasen. Det er en liste over sårbarheter som er kjent og rapportert av databaseleverandører når de blir oppdaget og lappet så raskt som mulig, så det er alt dette. Det er ting som har tilknytning til det når det gjelder å identifisere sårbare data. Et av de store og mest vellykkede hackingene med betalingsdata ble gjort til et betalingsbehandlingsfirma. Det ble senere overtatt fordi det måtte gå i likvidasjon hvis det ikke gjorde det, men dataene ble ikke stjålet fra noen av de operative databasene. Dataene ble stjålet fra en testdatabase. Det skjedde bare slik at utviklerne nettopp hadde tatt en undergruppe av dataene som var reelle data og brukt den, uten noen som helst beskyttelse, i en testdatabase. Testdatabasen ble hacket, og det var hentet mange mennesker personlige økonomiske detaljer.
Sikkerhetspolitikken, spesielt i forhold til tilgangssikkerhet når det gjelder databaser, hvem som kan lese, hvem som kan skrive, hvem som kan gi tillatelser, er det noen måte som noen kan omgå noe av dette? Så er det selvfølgelig krypteringer fra databaser som tillater det. Det koster et sikkerhetsbrudd. Jeg vet ikke om det er standard praksis i organisasjoner, men jeg vet at noen, som hoved sikkerhetsansvarlige, prøver å gi lederne noen ide om hva kostnadene ved et sikkerhetsbrudd faktisk er før det skjer i stedet for etter. Og de trenger slags å gjøre det for å sikre at de får riktig budsjettmengde for å kunne forsvare organisasjonen.
Og så angrepsoverflaten. Angrepsflaten ser ut til å vokse hele tiden. Det er år etter år at angrepflaten bare ser ut til å vokse. Så i sammendrag er rekkevidde et annet poeng, men datasikkerhet er vanligvis en del av DBAs rolle. Men datasikkerhet er også en samarbeidsaktivitet. Du må ha, hvis du gjør sikkerhet, må du ha en full ide om sikkerhetsbeskyttelsen for organisasjonen som helhet. Og det må være selskapspolitikk for dette. Hvis det ikke er selskapspolitikk, ender du opp med stykkevise løsninger. Du vet, gummibånd og plast, slags forsøk på å stoppe sikkerheten.
Så når det er sagt, tror jeg at jeg overleverer Dez som sannsynligvis kommer til å gi deg forskjellige krigshistorier.
Eric Kavanagh: Take it away, Dez.
Dez Blanchfield: Takk, Robin. Det er alltid en tøff handling å følge. Jeg kommer til å komme til dette fra motsatt ende av spekteret, bare for å, antar vi, gi oss en følelse av omfanget av utfordringen du står overfor, og hvorfor vi bør gjøre mer enn å bare sitte opp og ta hensyn til dette . Utfordringen vi ser nå med omfanget og mengden og volumet, hastigheten som disse tingene skjer, er at det jeg hører rundt på stedet nå med mange CXO-er, ikke bare CIO-er, men absolutt CIO er de som deltar der pengene stopper, er at de anser datainnbrudd for å raskt bli normen. Det er noe de nesten forventer å skje. Så de ser på dette fra synspunktet: "Ok, vel, når vi blir brudd - ikke hvis - når vi blir brudd, hva trenger vi å ha gjort med dette?" Og så begynner samtalene rundt, hva gjør de i tradisjonelle kantmiljøer og rutere, brytere, servere, inntrengingsdeteksjon, inntrengingsinspeksjon? Hva gjør de i systemene selv? Hva gjør de med dataene? Og så kommer det hele tilbake til det de gjorde med databasene sine.
La meg bare berøre et par eksempler på noen av disse tingene som har fanget mye menneskers fantasi og så bore ned til, slags, ødelegge dem litt. Så vi har hørt i nyhetene at Yahoo - sannsynligvis det største antallet som folk har hørt er omtrent en halv million, men det viser seg faktisk at det er uoffisielt mer som en milliard - jeg hørte et utlandstall på tre milliarder, men det er nesten halve verdensbefolkningen, så jeg tror det er litt høyt. Men jeg har fått bekreftet det fra en rekke folk i relevante områder som mener det er litt over en milliard poster som er blitt brutt ut av Yahoo. Og dette er bare et overveldende tall. Nå ser og tenker noen spillere, vel, det er bare webmail-kontoer, ikke så farlig, men så legger du til at mange av disse webmail-kontoene, og et nysgjerrig høyt antall, høyere enn jeg hadde forventet, faktisk er betalte kontoer. Det er her folk legger inn kredittkortdetaljene sine, og de betaler for å fjerne annonsene, fordi de blir lei av annonsene, og så $ 4 eller $ 5 i måneden er de villige til å kjøpe en webmail og skylagringstjeneste som ikke har annonser., og jeg er en av dem, og jeg har det på tvers av tre forskjellige leverandører der jeg kobler inn kredittkortet mitt.
Så da får utfordringene litt mer oppmerksomhet, fordi det ikke bare er noe der ute som en kaster en linje med å si: “Vel, Yahoo har tapt, la oss si, mellom 500 millioner og 1000 millioner kontoer, ” gjør 1000 millioner det høres veldig stort ut, og webmail-kontoer, men kredittkortdetaljer, fornavn, etternavn, e-postadresse, fødselsdato, kredittkort, pin-nummer, hva du måtte ønske, passord, og da blir det et mye mer skremmende konsept. Og igjen sier folk til meg: "Ja, men det er bare nettjeneste, det er bare nettpost, ikke noe særlig." Og så sier jeg: "Ja, vel, Yahoo-kontoen kan også ha blitt brukt i Yahoo-pengetjenestene for å kjøpe og selg aksjer. ”Da blir det mer interessant. Og når du begynner å bore ned i det, skjønner du at, ok, dette er faktisk mer enn bare mødre og pappaer hjemme, og tenåringer, med meldingskontoer, dette er faktisk noe der folk har drevet forretningstransaksjoner.
Så det er den ene enden av spekteret. Den andre enden av spekteret er at en svært liten, generell praksis, helsetjenesteleverandør i Australia hadde omtrent 1000 poster stjålet. Var en intern jobb, noen igjen, de var bare nysgjerrige, de gikk ut av døra, i dette tilfellet var det en 3, 5 tommers diskett. Det var for litt siden - men du kan fortelle medienes tid - men de var på gammel teknologi. Men det viste seg at grunnen til at de tok dataene, var at de bare var nysgjerrige på hvem som var der inne. Fordi de hadde ganske mange mennesker i denne lille byen, som var vår nasjonale hovedstad, som var politikere. Og de var interessert i hvem som var der og hvor deres liv var og all den slags informasjon. Så med et veldig lite datainnbrudd som ble gjort internt, var angivelig et betydelig stort antall politikere i den australske regjeringens detaljer ute i offentligheten.
Vi har to forskjellige ender av spekteret der å vurdere. Nå er virkeligheten at størrelsen på disse tingene bare er svimlende, og jeg har fått et lysbilde som vi kommer til å hoppe til veldig veldig her. Det er et par nettsteder som viser alle slags data, men denne er fra en sikkerhetsspesialist som hadde nettstedet der du kan gå og søke etter e-postadressen din, eller navnet ditt, og det vil vise deg alle datahendelser brudd i løpet av de siste 15 årene at han har vært i stand til å få hendene sine på, og deretter laste den inn i en database og bekrefte, og det vil fortelle deg om du hadde blitt pwned, slik uttrykket er. Men når du begynner å se på noen av disse tallene, og dette skjermbildet har ikke blitt oppdatert med den nyeste versjonen hans, som inkluderer et par, for eksempel Yahoo. Men bare tenk på hvilke typer tjenester som er her. Vi har Myspace, vi har LinkedIn, Adobe. Adobes interessante fordi folk ser og tenker, vel, hva betyr Adobe? De fleste av oss som laster ned Adobe Reader av en eller annen form, mange av oss har kjøpt Adobe-produkter med kredittkort, det er 152 millioner mennesker.
Nå, til Robins poeng tidligere, er dette veldig store tall, det er lett å bli overveldet av dem. Hva skjer når du har fått 359 millioner kontoer som er blitt brutt? Det er et par ting. Robin fremhevet det faktum at data alltid er i en database av en eller annen form. Det er den kritiske meldingen her. Nesten ingen på denne planeten, som jeg er klar over, som kjører et system av noen form, lagrer det ikke i en database. Men det interessante er at det er tre forskjellige typer data i den databasen. Det er sikkerhetsrelaterte ting som brukernavn og passord, som vanligvis er kryptert, men alltid er det mange eksempler der de ikke er. Det er den faktiske kundeinformasjonen rundt profilen deres og dataene de har laget, enten det er en helsejournal eller om det er en e-post eller en øyeblikkelig melding. Og så er det den faktiske innebygde logikken, så dette kan lagres prosedyrer, det kan være en hel haug med regler, hvis + dette + så + det. Og alltid er det bare ASCII-tekst som sitter fast i databasen, veldig få mennesker sitter der og tenker: “Vel, dette er forretningsregler, dette er hvordan dataene våre beveget seg rundt og kontrollert, vi bør potensielt kryptere disse når de er i ro, og når de er i bevegelse kanskje vi dekrypterer den og holder den i minnet, ”men ideelt sett burde det også være det.
Men det kommer tilbake til dette viktige punktet at alle disse dataene er i en database av en eller annen form, og oftere enn ikke er fokuset bare historisk sett på rutere og brytere og servere og til og med lagring, og ikke alltid på databasen på bakenden. Fordi vi tror at vi har fått kanten av nettverket dekket, og det er liksom, en typisk gammel, slags bor i et slott, og du legger en vollgrav rundt det, og du håper skurkene ikke kommer til å kunne svømme. Men så plutselig regnet skurkene ut hvordan de kunne lage utvidede stiger og kaste dem over vollgraven og klatre over vollgraven og klatre oppover veggene. Og plutselig er vollgraven din ganske mye ubrukelig.
Så vi er nå i scenariet der organisasjoner er i fangstmodus i en sprint. De spretter bokstavelig talt over alle systemer, etter mitt syn, og absolutt min erfaring, ved at det ikke alltid er bare disse enhjørningene på nettet, som vi ofte refererer til dem, oftere enn ikke det er tradisjonelle bedriftsorganisasjoner som blir brutt. Og du trenger ikke å ha mye fantasi for å finne ut hvem de er. Det finnes nettsteder som en som heter pastebin.net, og hvis du går til pastebin.net, og du bare skriver inn e-postliste eller passordliste, vil du ende opp med hundretusener av oppføringer om dagen som blir lagt til der folk viser eksempler på datasett med opptil tusen poster med fornavn, etternavn, kredittkortdetaljer, brukernavn, passord, dekrypterte passord, forresten. Der folk kan hente den listen, gå og bekrefte tre eller fire av dem og bestemme at jeg, ja, jeg vil kjøpe den listen, og det er vanligvis en form for mekanisme som gir en slags anonym inngangsport til personen som selger dataene.
Hva som er interessant er at når den tilknyttede gründeren innser at de kan gjøre dette, trenger det ikke så mye fantasi å innse at hvis du bruker 1000 dollar på å kjøpe en av disse listene, hva er det første du gjør med det? Du går ikke og prøver å spore regnskapet, du legger igjen en kopi av det på pastbin.net og du selger to eksemplarer for $ 1000 hver og tjener $ 1000. Og dette er barn som gjør dette. Det er noen ekstremt store profesjonelle organisasjoner rundt om i verden som gjør dette for en levende. Det er til og med statlige nasjoner som angriper andre stater. Du vet, det er mye snakk om at Amerika angriper Kina, Kina angriper Amerika, det er ikke så enkelt, men det er definitivt statlige organisasjoner som bryter systemer som alltid er drevet av databaser. Det er ikke bare et tilfelle av små organisasjoner, det er også land kontra land. Det bringer oss tilbake til det problemet med, hvor er dataene lagret? Det er i en database. Hvilke kontroller og mekanismer er der? Eller alltid er de ikke kryptert, og hvis de er kryptert, er det ikke alltid alle dataene, kanskje er det bare passordet som er saltet og kryptert.
Og pakket rundt dette har vi en rekke utfordringer med hva som ligger i disse dataene og hvordan vi gir tilgang til data og SOX-samsvar. Så hvis du tenker på formuesforvaltning eller bankvirksomhet, har du organisasjoner som bekymrer deg for den legitime utfordringen; du har organisasjoner som bekymrer seg for samsvar i bedriftsområdet; du har myndigheters krav og myndighetskrav; du har scenarier nå hvor vi har databaser på stedet; vi har databaser i tredjeparts datasentre; Vi har databaser som sitter i skymiljøer, så skymiljøene deres er alltid ikke alltid i landet. Og slik at dette blir en større og større utfordring, ikke bare fra rent sikkerhet la oss ikke bli hacket synspunkt, men også, hvordan oppfyller vi alle de forskjellige nivåene i samsvar? Ikke bare HIPAA- og ISO-standardene, men det er bokstavelig talt dusinvis og titalls og dusinvis av disse på statlig nivå, nasjonalt nivå og globalt nivå som krysser grenser. Hvis du driver med Australia, kan du ikke flytte regjeringsdata. Eventuelle australske private data kan ikke forlate nasjonen. Hvis du er i Tyskland er det enda strengere. Og jeg vet at Amerika også beveger seg veldig raskt på dette av mange årsaker.
Men det bringer meg tilbake til hele utfordringen om hvordan vet du hva som skjer i databasen, hvordan overvåker du den, hvordan forteller du hvem som gjør hva i databasen, hvem som har utsikt over forskjellige tabeller og rader og kolonner og felt, når leser de den, hvor ofte leser de den og hvem sporer den? Og jeg tror det bringer meg til mitt endelige poeng før jeg overleverer til vår gjest i dag som kommer til å hjelpe oss med å snakke om hvordan vi løser dette problemet. Men jeg vil overlate oss med denne tanken, og det vil si at mye av fokuset er på kostnadene for bedriften og kostnadene for organisasjonen. Og vi kommer ikke til å dekke dette punktet i dag, men jeg vil bare la det ligge i bakhodet for å gruble over, og det er at det er et estimat på omtrent mellom $ 135 og 585 $ per rekord for å rydde opp etter et brudd. Så investeringen du gjør i sikkerheten din rundt rutere og brytere og servere er vel og bra og brannmurer, men hvor mye har du investert i databasesikkerheten?
Men det er en falsk økonomi, og da Yahoos brudd skjedde nylig, og jeg har det på god autoritet, er det omtrent en milliard kontoer, ikke 500 millioner. Da Verizon kjøpte organisasjonen for noe som 4, 3 milliarder kroner, ba de om en milliard dollar tilbake, eller en rabatt, så snart bruddet skjedde. Hvis du nå gjør matematikken og sier at det er omtrent en milliard poster som ble brutt, en milliardrabatt, blir anslaget mellom 135 og 535 dollar for å rydde opp i rekorden nå 1 dollar. Noe som igjen er farskisk. Det koster ikke 1 dollar å rydde opp i en milliard poster. For $ 1 per rekord for å rydde opp i en milliard poster for et brudd på den størrelsen. Du kan ikke en gang legge ut en pressemelding for den slags kostnader. Og slik fokuserer vi alltid på de interne utfordringene.
Men en av tingene, tror jeg, og det trenger oss å ta dette veldig alvorlig på databasenivå, og det er derfor dette er et veldig, veldig viktig tema for oss å snakke om, og det er at vi aldri snakker om det menneskelige toll. Hva er den menneskelige avgiften vi pådrar oss dette? Og jeg tar et eksempel før jeg raskt pakker sammen. LinkedIn: i 2012 ble LinkedIn-systemet hacket. Det var en rekke vektorer, og det vil jeg ikke gå inn på. Og hundrevis av millioner av kontoer ble stjålet. Folk sier omtrent 160-odde millioner, men det er faktisk et mye større antall, det kan være så mange som rundt 240 millioner. Men det bruddet ble ikke kunngjort før tidligere i år. Det er fire år som hundrevis av millioner av folks plater er der ute. Nå var det noen som betalte for tjenester med kredittkort og noen mennesker med gratis kontoer. Men LinkedIn er interessant, for ikke bare fikk de tilgang til kontoinformasjonen din hvis du ble brutt, men de fikk også tilgang til all din profilinformasjon. Så hvem du var koblet til og alle forbindelsene du hadde, og hvilke jobber de hadde, og hvilke ferdigheter de hadde, og hvor lenge de hadde jobbet i selskaper og all den slags informasjon, og deres kontaktinformasjon.
Så tenk på utfordringen vi har med å sikre dataene i disse databasene, og sikre og administrere databasesystemene selv, og strømmen på innvirkning, mens menneskelig toll av dataene er der ute i fire år. Og sannsynligheten for at noen kan komme til en ferie et sted i Sørøst-Asia og at de har hatt dataene sine der i fire år. Og noen kan ha kjøpt en bil eller fått et boliglån eller kjøpt ti telefoner i løpet av året på kredittkort, der de opprettet en falsk ID på de dataene som var der ute i fire år - fordi til og med LinkedIn-dataene ga deg nok informasjon til opprett en bankkonto og en falsk ID - og du kommer på flyet, du drar på ferie, du lander og du blir kastet i fengsel. Og hvorfor kastes du i fengsel? Vel, fordi du hadde ID-en din stjålet. Noen opprettet en falsk ID og handlet som deg og hundretusenvis av dollar, og de gjorde dette fire år, og du visste ikke engang om det. Fordi det er der ute, skjedde det bare.
Så jeg tror det bringer oss til denne kjerneutfordringen om hvordan vet vi hva som skjer på databasene våre, hvordan sporer vi det, hvordan overvåker vi det? Og jeg gleder meg til å høre hvordan vennene våre på IDERA har kommet frem til en løsning for å løse det. Og med det skal jeg overrekke.
Eric Kavanagh: OK, Ignacio, gulvet er ditt.
Ignacio Rodriguez: OK. Velkommen alle sammen. Jeg heter Ignacio Rodriguez, bedre kjent som Iggy. Jeg er hos IDERA og en produktsjef for sikkerhetsprodukter. Virkelig gode emner som vi nettopp har dekket, og vi må virkelig bekymre oss for datainnbruddene. Vi må ha herdede sikkerhetspolicyer, vi må identifisere sårbarheter og vurdere sikkerhetsnivåene, kontrollere brukertillatelser, kontrollere serversikkerhet og overholde revisjoner. Jeg har holdt på med revisjon i min tidligere historie, mest på Oracle-siden. Jeg har gjort noen på SQL Server og gjorde dem med verktøy eller, i utgangspunktet, hjemmelagte skript, noe som var bra, men du må lage et depot og sørge for at depotet var sikkert, og hele tiden måtte vedlikeholde skriptene med endringer fra revisorene, hva har du.
Så hvis jeg hadde visst at IDERA var der ute og hadde et verktøy, ville jeg mer enn sannsynlig ha kjøpt det. Men uansett, vi kommer til å snakke om Secure. Det er et av produktene våre i sikkerhetsproduktlinjen, og hva det i utgangspunktet gjør er at vi ser på sikkerhetspolicyene og kartlegger disse til forskriftsmessige retningslinjer. Du kan se en fullstendig historie med SQL Server-innstillinger, og du kan også i utgangspunktet gjøre en grunnlinje av disse innstillingene og deretter sammenligne med fremtidige endringer. Du kan lage et øyeblikksbilde, som er en grunnleggende av innstillingene dine, og deretter kunne spore om noen av disse tingene er endret, og også bli varslet hvis de blir endret.
Noe av det vi gjør godt er å forhindre sikkerhetsrisiko og brudd. Sikkerhetsrapportkortet gir deg en oversikt over topp sikkerhetssårbarheter på serverne, og da blir også hver sikkerhetskontroll kategorisert som høy, middels eller lav risiko. Nå, på disse kategoriene eller sikkerhetskontroller, kan alle disse endres. La oss si at hvis du har noen kontroller og bruker en av malene vi har, og du bestemmer deg, vel, kontrollene indikerer eller ønsker at dette sikkerhetsproblemet ikke egentlig er et høyt, men et medium, eller omvendt. Du har kanskje noen som er merket som medium, men i organisasjonen kan kontrollene du vil merke dem, eller anser dem som høye, alle disse innstillingene kan konfigureres av brukeren.
En annen kritisk sak som vi må se på er å identifisere sårbarhetene. Å forstå hvem som har tilgang til hva og identifisere hver av brukerens effektive rettigheter på tvers av alle SQL Server-objekter. Med verktøyet vil vi kunne gjennomgå og se på rettighetene på alle SQL Server-objektene, og vi vil se et skjermbilde av det her ganske snart. Vi rapporterer og analyserer bruker-, gruppe- og rolletillatelser. En av de andre funksjonene er at vi leverer detaljerte sikkerhetsrisikorapporter. Vi har out-of-the-box rapporter og inneholder fleksible parametere for deg for å opprette typer rapporter og vise dataene som revisorer, sikkerhetsansvarlige og ledere krever.
Vi kan også sammenligne endringer i sikkerhet, risiko og konfigurasjon over tid, som jeg nevnte. Og de er med øyeblikksbildene. Og disse øyeblikksbildene kan konfigureres så langt du vil gjøre dem - månedlig, kvartalsvis, årlig - som kan planlegges i verktøyet. Og igjen, du kan gjøre sammenligninger for å se hva som har endret seg, og hva som er fint med det, er at hvis du hadde et brudd, kan du lage et øyeblikksbilde etter at det ble korrigert, gjøre en sammenligning, og du ville se at det var et høyt nivå risiko forbundet med forrige øyeblikksbilde og deretter rapportere, ser du faktisk i neste øyeblikksbilde etter at det ble korrigert at det ikke lenger var et problem. Det er et godt revisjonsverktøy som du kan gi til revisor, en rapport du kan gi revisorene og si: "Se, vi hadde denne risikoen, vi avbøt den, og nå er det ikke en risiko lenger." Og igjen, jeg nevnt med øyeblikksbildene du kan varsle når en konfigurasjon endres, og hvis en konfigurasjon blir endret, og blir oppdaget, som utgjør en ny risiko, vil du også bli varslet om det.
Vi får noen spørsmål om SQL Server Architecture med Secure, og jeg vil gjøre en korreksjon på lysbildet her hvor det står “Collection Service.” Vi har ingen tjenester, det burde ha vært “Management and Collection Server. ”Vi har vår konsoll og deretter vår Management and Collection Server, og vi har en agentløs fangst som vil gå ut til databasene som er registrert og samle dataene gjennom jobber. Og vi har et SQL Server Repository, og vi jobber sammen med SQL Server Reporting Services for også å planlegge rapporter og lage tilpassede rapporter. Nå på et sikkerhetsrapportkort er dette det første skjermbildet du vil se når SQL Secure startes. Du vil enkelt se hvilke kritiske elementer du har oppdaget. Og igjen har vi høydepunktene, mediene og lavene. Og så har vi også retningslinjene som spilles med den aktuelle sikkerhetskontrollen. Vi har en HIPAA-mal; vi har IDERA sikkerhetsnivå 1, 2 og 3 maler; vi har PCI-retningslinjer. Dette er alle maler du kan bruke, og igjen kan du lage din egen mal, basert på dine egne kontroller også. Og igjen er de modifiserbare. Du kan lage dine egne. Hvilken som helst av de eksisterende malene kan brukes som en grunnlinje, så kan du endre dem som du vil.
Noe av det fine man kan gjøre er å se hvem som har tillatelser. Og med dette skjermbildet her vil vi kunne se hvilke SQL Server-pålogginger som er på bedriften, og du vil kunne se alle tildelte og effektive rettigheter og tillatelser på serverdatabasen på objektnivå. Det gjør vi her. Du vil kunne velge igjen databasene eller serverne, og deretter kunne hente rapporten om SQL Server-tillatelser. Så i stand til å se hvem som har tilgang til hva. En annen fin funksjon er at du skal kunne sammenligne sikkerhetsinnstillinger. La oss si at du hadde standardinnstillinger som måtte settes i hele bedriften. Du kan deretter sammenligne alle serverne dine og se hvilke innstillinger som ble satt for de andre serverne i bedriften.
Igjen, policymalene, dette er noen av malene vi har. I utgangspunktet bruker du en av disse, lager din egen. Du kan opprette din egen policy, som du ser her. Bruk en av malene, og du kan endre dem etter behov. Vi kan også se effektive rettigheter for SQL Server. Dette vil bekrefte og bevise at tillatelser er riktig angitt for brukere og roller. Igjen, kan du gå ut der og se og se og bekrefte at tillatelse er riktig angitt for brukere og roller. Deretter kan du med SQL Server Object Access Rights bla gjennom og analysere SQL Server-objekttreet ned fra servernivå ned til objektnivårollene og sluttpunktene. Og du kan øyeblikkelig se tildelte og effektive arvede tillatelser og sikkerhetsrelaterte egenskaper på objektnivå. Dette gir deg en god oversikt over tilgangene du har på databaseobjektene dine, og som har tilgang til disse.
Vi har igjen våre rapporter som vi har. Dette er hermetiske rapporter, vi har flere som du kan velge mellom for å kunne rapportere. Og mange av disse kan tilpasses, eller du kan ha kundrapportene dine og bruke dem i forbindelse med rapporteringstjenestene og kunne opprette dine egne tilpassede rapporter derfra. Nå er snapshot-sammenligningene, dette er en ganske kul funksjon, tror jeg, der du kan dra ut der, og du kan gjøre en sammenligning av øyeblikksbildene dine som du har tatt, og se om det var noen forskjeller i antallet. Er det lagt til noen objekter, var det tillatelser som har endret seg, alt vi kan se hvilke endringer som er gjort mellom de forskjellige øyeblikksbildene. Noen mennesker vil se på disse på et månedlig nivå - de vil gjøre et månedlig øyeblikksbilde og deretter gjøre en sammenligning hver måned for å se om noe har endret seg. Og hvis det ikke var noe som skulle ha blitt endret, noe som gikk til endringskontrollmøtene, og du ser at noen tillatelser er endret, kan du gå tilbake for å se hva som har skjedd. Dette er en ganske fin funksjon her hvor du kan gjøre sammenligningen igjen av alt som er revidert i øyeblikksbildet.
Deretter din vurdering sammenligning. Dette er en annen fin funksjon som vi har der du kan gå der ute og se på vurderingene og deretter gjøre en sammenligning av dem og legge merke til at sammenligningen her hadde en SA-konto som ikke ble deaktivert i dette siste øyeblikksbildet som jeg har gjort - det er nå korrigert. Dette er en ganske fin ting der du kan vise at vi hadde en viss risiko, ok, de ble identifisert av verktøyet, og nå har vi redusert risikoen. Og igjen, dette er en god rapport for å vise revisorene at faktisk er risikoen blitt dempet og blir ivaretatt.
Oppsummert, databasesikkerhet, er det kritisk, og jeg tror mange ganger vi ser på brudd som kommer fra eksterne kilder, og noen ganger legger vi ikke så mye oppmerksomhet til interne brudd, og det er noe av det vi trenger å passe på. Og Secure vil hjelpe deg der for å forsikre deg om at det ikke er noen privilegier som ikke trenger å bli tildelt, vet du, sørg for at all denne sikkerheten er riktig satt til kontoene. Forsikre deg om at SA-kontoene dine har passord. Sjekker også så langt krypteringsnøklene dine, har de blitt eksportert? Bare flere forskjellige ting vi ser etter, og vi vil varsle deg om det faktum om det var et problem, og på hvilket nivå det er. Vi trenger et verktøy, mange fagpersoner trenger verktøy for å administrere og overvåke tilgangsrettigheter for databaser, og vi ser faktisk på å gi en omfattende mulighet til å kontrollere databasetillatelser og spore tilgangsaktiviteter og dempe risiko for brudd.
Nå er en annen del av sikkerhetsproduktene våre at det er en WebEx som ble dekket og en del av presentasjonen som vi snakket om tidligere var data. Du vet hvem som får tilgang til hva, hva har du, og det er vårt SQL Compliance Manager-verktøy. Og det er en innspilt WebEx på det verktøyet, og som faktisk lar deg overvåke hvem som får tilgang til hvilke tabeller, hvilke kolonner, du kan identifisere tabeller som har følsomme kolonner, så langt som fødselsdato, pasientinformasjon, hvilke typer tabeller og faktisk se hvem som har tilgang til den informasjonen, og om den blir brukt.
Eric Kavanagh: OK, så la oss dykke inn i spørsmålene, antar jeg, her. Kanskje Dez, jeg skal kaste det til deg først, og Robin, kime inn som du kan.
Dez Blanchfield: Ja, jeg har klørt å stille et spørsmål fra 2. og 3. lysbilde. Hva er den typiske bruksaken du ser for dette verktøyet? Hvem er de vanligste typene brukere du ser som tar i bruk dette og setter det i spill? Og på baksiden av den typiske, typiske, bruk saksmodellen, hvordan har de det med det? Hvordan implementeres det?
Ignacio Rodriguez: Ok, den typiske brukssaken som vi har er DBAer som har fått tildelt tilgangskontrollansvaret for databasen, som sørger for at alle tillatelsene er satt slik de trenger å være og deretter holde oversikt, og deres standarder på plass. Du vet, disse bestemte brukerkontoer kan bare ha tilgang til disse tabellene osv. Og hva de gjør med det, er å sørge for at disse standardene er blitt satt og at standardene ikke har endret seg gjennom tid. Og det er noe av det store som folk bruker det til er å spore og identifisere om det blir gjort endringer som ikke er kjent om.
Dez Blanchfield: Fordi de er de skumle, ikke sant? Er det at du kan ha et, la oss si, et strategidokument, har du retningslinjer som underbygger det, har du overholdelse og styring under det, og du følger retningslinjene, holder deg til styringen og den får grønt lys og så plutselig en måned senere, ruller noen ut en endring, og av en eller annen grunn ikke går gjennom det samme endringsgjennomgangstavlen eller endringsprosessen, eller hva det måtte være, eller at prosjektet bare har gått videre og ingen vet.
Har du noen eksempler som du kan dele - og jeg vet tydeligvis at det ikke alltid er noe du deler fordi kunder er litt opptatt av det, så vi trenger ikke nødvendigvis å navngi - men gi oss et eksempel på hvor du kanskje du har sett dette faktisk, vet du, en organisasjon har satt dette på plass uten å innse det, og de fant bare noe og skjønte, “Wow, det var verdt ti ganger, vi fant bare noe vi ikke var klar over.” Har du fått noe eksempel der folk har implementert dette og så oppdaget at de hadde et større problem eller et reelt problem som de ikke visste at de hadde, og så blir du umiddelbart lagt til på julekortlisten?
Ignacio Rodriguez: Vel, jeg tror at det største vi har sett eller har rapportert, er det jeg nettopp nevnte, så langt som tilgangen noen hadde hatt. Det er utviklere, og da de implementerte verktøyet, var de virkelig ikke klar over at X-mengden av disse utviklerne hadde så mye tilgang til databasen og hadde tilgang til bestemte objekter. Og en annen ting er skrivebeskyttet kontoer. Det var noen skrivebeskyttede kontoer som de hadde, for å finne ut at disse skrivebeskyttede kontoene faktisk var, hadde sett inn data og slett privilegier også. Det er der vi har sett en viss fordel for brukerne. Den store tingen, igjen, at vi har hørt at folk liker, er i stand til å, igjen, spore endringene og sørge for at ingenting gjør dem blindt.
Dez Blanchfield: Vel som Robin fremhevet, har du scenarier som folk ikke ofte tenker gjennom, ikke sant? Når vi gleder oss, tenker vi, om vi gjør alt i henhold til reglene, og jeg finner, og jeg er sikker på at du ser det også - fortell meg om du er uenig i det - organisasjoner fokuserer så tungt på å utvikle strategi og politikk og overholdelse og styring og KPIer og rapportering, at de ofte blir så fiksert på at de ikke tenker på utliggerne. Og Robin hadde et veldig flott eksempel som jeg kommer til å stjele fra ham - beklager Robin - men eksemplet er den andre gangen hvor en live-kopi av databasen, et øyeblikksbilde og satt den i utviklingstest, ikke sant? Vi gjør dev, vi gjør tester, vi gjør UAT, vi gjør systemintegrasjon, alle den slags ting og så gjør vi en haug med samsvarstester nå. Ofte har dev test, UAT, SIT faktisk en samsvarskomponent på det der vi bare sørger for at det hele er sunt og trygt, men ikke alle gjør det. Dette eksemplet som Robin ga med en kopi av en live kopi av databasen satt i en test med utviklingsmiljø for å se om den fortsatt fungerer med live data. Svært få selskaper lener seg og tenker: "Skjer det til og med, eller er det mulig?" Hvordan ser implementeringsreisen ut? Snakker vi om dager, uker, måneder? Hvordan ser en vanlig distribusjon ut for en organisasjon i gjennomsnittstørrelse?
Ignacio Rodriguez: Dager. Det er ikke engang dager, jeg mener, det er bare et par dager. Vi har nettopp lagt til en funksjon der vi kan registrere mange, mange servere. I stedet for å måtte gå inn der i verktøyet, og si at du hadde 150 servere, måtte du gå inn der individuelt og registrere serverne - nå trenger du ikke gjøre det. Det er en CSV-fil du oppretter, og vi fjerner den automatisk, og vi holder den ikke der på grunn av sikkerhetsmessige problemer. Men det er en annen ting vi må vurdere, er at du har en CSV-fil der ute med brukernavn / passord.
Det vi gjør er at vi automatisk sletter det, men det er et alternativ du har. Hvis du vil gå inn der enkeltvis og registrere dem og ikke ønsker å ta den risikoen, kan du gjøre det. Men hvis du vil bruke en CSV-fil, kan du plassere den på et sikkert sted, peke applikasjonen til den plasseringen, den vil kjøre den CSV-filen, og deretter er den automatisk satt til å slette den filen når den er ferdig. Og det vil gå og sørge for og sjekke at filen er fjernet. Den lengste polen i sanden som vi hadde så langt som implementering var registrering av de faktiske serverne.
Dez Blanchfield: Ok. Nå snakket du om rapporter. Kan du gi oss litt mer detalj og innsikt i hva som kommer forhåndsbuntet så langt som rapportering rundt, antar jeg, oppdagelseskomponenten ved å se på hva som er der og rapportere om det, nåværende tilstand i nasjonen, hva som kommer før- bygget og ferdigbakt så langt som rapporter rundt gjeldende tilstand for samsvar og sikkerhet, og hvor lett kan de utvides? Hvordan bygger vi videre på disse?
Ignacio Rodriguez: OK. Noen av rapportene som vi har, vi har rapporter som omhandler kryssserver, innloggingskontroller, datainnsamlingsfilter, aktivitetshistorikk og deretter risikovurderingsrapportene. Og også alle mistenkte Windows-kontoer. Det er mange, mange her. Se mistenkte SQL-pålogginger, serverpålogginger og brukerkartlegging, brukertillatelser, alle brukerrettigheter, serverroller, databaseroller, noe sårbarhet vi har eller autentiseringsrapporter for blandet modus, gjesteaktivere databaser, OS-sårbarhet via XPS, de utvidede prosedyrene, og deretter de sårbare faste rollene. Dette er noen av rapportene som vi har.
Dez Blanchfield: Og du nevnte at de er betydningsfulle nok og en rekke av dem, som er en logisk ting. Hvor lett er det for meg å skreddersy det? Hvis jeg kjører en rapport og jeg får denne fantastiske store grafen, men jeg vil ta ut noen brikker som jeg ikke er så interessert i og legge til et par andre funksjoner, er det en rapportforfatter, er det et slags grensesnitt og verktøy for å konfigurere og skreddersy eller til og med potensielt bygge en ny rapport fra bunnen av?
Ignacio Rodriguez: Vi vil deretter be brukerne om å bruke Microsoft SQL Report Services for å gjøre det, og vi har mange kunder som faktisk vil ta noen av rapportene, tilpasse og planlegge dem når de vil. Noen av disse karene ønsker å se disse rapportene på månedlig basis eller ukentlig, og de vil ta den informasjonen vi har, flytte den til Reporting Services og deretter gjøre det derfra. Vi har ikke en rapportforfatter integrert med verktøyet vårt, men vi drar fordel av rapporteringstjenestene.
Dez Blanchfield: Jeg tror det er en av de største utfordringene med disse verktøyene. Du kan komme inn dit og finne ting, men da må du kunne trekke det ut, rapportere det til folk som ikke nødvendigvis er DBA-er og systemingeniører. Det er en interessant rolle som har oppstått i min erfaring, og det er, du vet, at risikobetjenter alltid har vært i organisasjoner og at de overveiende har vært rundt og et helt annet spekter av risikoer som vi har sett nylig, mens nå med data brudd blir ikke bare en ting, men en faktisk tsunami, CRO har gått fra å være, du vet, HR og etterlevelse og arbeidsmiljø og sikkerhetsfokus nå til cyberrisiko. Du vet, brudd, hacking, sikkerhet - mye mer teknisk. Og det blir interessant fordi det er mange CRO-er som kommer fra en MBA-stamtavle og ikke en teknisk stamtavle, så de må få hodene rundt, slags hva dette betyr for overgangen mellom cyber-risikoen til å flytte til en CRO, og så videre. Men det store de ønsker er bare synlighetsrapportering.
Kan du fortelle oss noe rundt posisjoneringen når det gjelder overholdelse? Selvfølgelig er en av de store styrkene med dette at du kan se hva som skjer, du kan overvåke det, du kan lære, du kan rapportere om det, du kan reagere på det, du kan til og med forhindre noen ting. Den overordnede utfordringen er overholdelse av styresett. Er det sentrale deler av dette som bevisst knytter seg til eksisterende krav til overholdelse eller bransjeansvar som PCI, eller noe sånt for tiden, eller er det noe som kommer ned i veikartet? Passer det, slags, inn i rammen av slike som COBIT, ITIL og ISO standarder? Hvis vi bruker dette verktøyet, gir det oss en serie kontroller og balanser som passer inn i disse rammene, eller hvordan bygger vi det inn i disse rammene? Hvor er posisjonen med den slags ting i tankene?
Ignacio Rodriguez: Ja, det er maler som vi har som vi leverer med verktøyet. Og vi kommer til punktet igjen der vi revurderer malene våre, og vi kommer til å legge til, og det kommer flere snart. FISMA, FINRA, noen ekstra maler som vi har, og vi gjennomgår typisk malene og ser for å se hva som har endret seg, hva trenger vi å legge til? Og vi ønsker faktisk å komme til det punktet, hvor du vet, sikkerhetskravene har endret seg ganske mye, så vi ser på en måte å gjøre dette utvidbart på flukt. Det er noe vi ser på i fremtiden.
Men akkurat nå ser vi på å lage maler og kunne få malene fra et nettsted; du kan laste dem ned. Og det er slik vi håndterer det - vi håndterer dem gjennom maler, og vi leter etter måter i fremtiden her for å gjøre det enkelt utvidbart og raskt. For når jeg pleide å gjøre revisjon, vet du, ting endrer seg. En revisor ville komme en måned, og neste måned vil de se noe annerledes. Da er det en av utfordringene med verktøyene, å kunne gjøre de endringene og få det du trenger, og det er, slags hvor vi vil komme til.
Dez Blanchfield: Jeg antar at en revisors utfordring endres regelmessig i lys av det faktum at verdens beveger seg raskere. Og en gang i tiden ville kravet fra et revisjonssyn, etter min erfaring, bare være ren kommersiell etterlevelse, og da ble det teknisk etterlevelse og nå er det driftsoverholdelse. Og det er alt dette andre, du vet, hver dag dukker det opp noen, og de måler deg ikke bare på noe som ISO 9006 og 9002, de ser på alle slags ting. Og jeg ser at de 38.000 seriene blir en stor ting også i ISO. Jeg ser for meg at det bare kommer til å bli mer og mer utfordrende. Jeg er i ferd med å overlate til Robin fordi jeg har hogget båndbredden.
Tusen takk for at du ser det, og jeg kommer garantert til å bruke mer tid på å bli kjent med det fordi jeg faktisk ikke visste at det faktisk var ganske så i dybden. Så takk, Ignacio, jeg skal gi Robin nå. En flott presentasjon, takk. Robin, overfor deg.
Dr. Robin Bloor: OK Iggy, jeg skal kalle deg Iggy, hvis det er i orden. Hva som forvirrer meg, og jeg tror i lys av noen av tingene Dez sa i presentasjonen hans, er det veldig mye der ute som du må si at folk virkelig ikke passer på dataene. Du vet, spesielt når det kommer til at du bare ser en del av isfjellet, og det er sannsynligvis mye som skjer uten at noen rapporterer. Jeg er interessert i perspektivet ditt til hvor mange av kundene du er klar over, eller potensielle kunder som du er klar over, har det beskyttelsesnivået som du, slags tilbyr, ikke bare dette, men også datatilgangsteknologien din? Jeg mener, hvem der ute er skikkelig rustet til å takle trusselen, er spørsmålet?
Ignacio Rodriguez: Hvem er ordentlig utstyrt? Jeg mener, mange kunder som vi egentlig ikke har adressert noen form for tilsyn, vet du. De har hatt noen, men det store er å prøve å følge med og prøve å vedlikeholde det og sørge for det. Det store problemet vi har sett er - og selv det har jeg da jeg fulgte etterlevelsen, er - hvis du kjørte skriptene dine, ville du gjort det en gang hvert kvartal når revisorene skulle komme inn og du har funnet et problem. Gjett hva, det er allerede for sent, revisjonen er der, revisorene er der, de vil ha rapporten, de flagger den. Og så får vi enten et merke, eller så ble vi fortalt, hei, vi må løse disse problemene, og det er der dette ville komme inn. Det ville være mer en proaktiv type der du kan finne risikoen og dempe risikoen, og det er hva kundene våre ser etter. En måte å være litt proaktiv i motsetning til å være reaktiv når revisorer kommer inn og finner ut at noen av tilgangene ikke er der de trenger å være, andre mennesker har administrative privilegier og de burde ikke ha dem, de slags ting. Og det er der vi har sett mye tilbakemeldinger fra, som folk liker verktøyet og bruker det til.
Dr. Robin Bloor: Ok, et annet spørsmål jeg har, som er på en måte et åpenbart spørsmål også, men jeg er bare nysgjerrig. Hvor mange mennesker kommer faktisk til deg i kjølvannet av et hack? Hvor, du vet, får du virksomheten, ikke fordi de så på miljøet og tenkte at de måtte sikres på en mye mer organisert måte, men faktisk er du der ganske enkelt fordi de allerede har lidd noe av smerte.
Ignacio Rodriguez: I min tid her på IDERA har jeg ikke sett en. For å være ærlig med deg, er det meste av samspillet jeg har hatt med kundene som jeg har vært involvert i, mer en gleder meg til og prøver å begynne revisjon og begynte å se på privilegier osv. Som sagt har jeg selv ikke opplevd i min tid her, at vi har hatt noen som har kommet etter brudd som jeg kjenner til.
Dr. Robin Bloor: Å, det er interessant. Jeg hadde trodd at det hadde vært minst noen få. Jeg ser faktisk på dette, men legger også til det alle kompleksitetene som faktisk gjør data sikre over hele bedriften på alle måter og i alle aktiviteter du gjør. Tilbyr du rådgivning direkte for å hjelpe folk? Jeg mener, det er tydelig at du kan kjøpe verktøy, men etter min erfaring er det ofte folk som kjøper sofistikerte verktøy og bruker dem veldig dårlig. Tilbyr du spesifikk rådgivning - hva du skal gjøre, hvem du skal trene og sånt?
Ignacio Rodriguez: Det er noen tjenester du kan gjøre, så langt som støttetjenester, som vil tillate at noe av det skjer. Men så langt som konsulenttjenester, tilbyr vi ingen konsulenttjenester, men opplæring, vet du hvordan du bruker verktøyene og sånt, noe av det vil bli adressert med støttenivået. Men per se har vi ikke en serviceavdeling som går ut og gjør det.
Dr. Robin Bloor: OK. Når det gjelder databasen du dekker, nevner presentasjonen her bare Microsoft SQL Server - gjør du Oracle også?
Ignacio Rodriguez: Vi kommer til å utvide til Oracle-riket med Compliance Manager først. Vi kommer til å starte et prosjekt med det, så vi kommer til å se på å utvide dette til Oracle.
Dr. Robin Bloor: Og kommer du sannsynligvis andre steder?
Ignacio Rodriguez: Ja, det er noe vi må se på i veikartene og se hvordan ting er, men det er noe av det vi vurderer, er hva andre databaseplattformer trenger vi å angripe også.
Dr. Robin Bloor: Jeg var også interessert i splittelsen, jeg har ikke fått noe forutinntatt bilde av dette, men når det gjelder distribusjoner, hvor mye av dette som faktisk blir distribuert i skyen, eller er det nesten alt på stedet ?
Ignacio Rodriguez: Alt på stedet. Vi ser på å utvide Secure også til å dekke Azure, ja.
Dr. Robin Bloor: Det var Azure-spørsmålet, du er ikke der ennå, men du drar dit, det gir mye mening.
Ignacio Rodriguez: Ja, vi skal dit veldig snart.
Dr. Robin Bloor: Ja, vel, min forståelse fra Microsoft er at det er veldig mye action med Microsoft SQL Server i Azure. Det blir, hvis du vil, en sentral del av det de tilbyr. Det andre spørsmålet som jeg er interessert i - det er ikke teknisk, det er mer som et spørsmål hvordan du skal gjøre - hvem er kjøperen for dette? Blir du kontaktet av IT-avdelingen, eller blir du kontaktet av CSO-er, eller er det en annen rekke mennesker? Når noe slikt vurderes, er det en del av å se på en hel rekke ting for å sikre miljøet? Hva er situasjonen der?
Ignacio Rodriguez: Det er en blanding. Vi har CSO-er, mange ganger salgsteamet vil nå ut og snakke med DBA-er. Og så har DBA, igjen, blitt chartret med å få på plass en slags revisjonsprosess. Og derfra vil de evaluere verktøyene og rapportere opp kjeden og ta en beslutning om hvilken del de vil kjøpe. Men det er en blandet pose med hvem som vil kontakte oss.
Dr. Robin Bloor: OK. Jeg tror jeg vil gi tilbake til Eric nå fordi vi har gjort timen, men det kan være noen spørsmål fra publikum. Eric?
Eric Kavanagh: Ja, vi har brent gjennom mye godt innhold her. Her er ett virkelig godt spørsmål jeg vil kaste over til deg fra en av de fremmøtte. Han snakker om blockchain og hva du snakker om, og han spør, er det en mulig måte å migrere en skrivebeskyttet del av en SQL-database til noe som ligner det blockchain tilbyr? Det er litt tøft.
Ignacio Rodriguez: Ja, jeg skal være ærlig med deg, jeg har ikke noe svar på den.
Eric Kavanagh: Jeg skal kaste den over til Robin. Jeg vet ikke om du har hørt det spørsmålet, Robin, men han bare spør, er det en måte å migrere den skrivebeskyttede delen av en SQL-database til noe som ligner det blockchain tilbyr? Hva synes du om at?
Dr. Robin Bloor: Det er som, hvis du skal migrere databasen, vil du også migrere databasetrafikken. Det er et helt sett med kompleksitet involvert i å gjøre det. Men du ville ikke gjort det av andre grunner enn å gjøre dataene ukrenkelige. Fordi en blockchain kommer til å være tregere å få tilgang til, så vet du, hvis hastighet er din greie - og det nesten alltid er tingen - så ville du ikke gjort det. Men hvis du ønsket å gi, slags kodet kryptert tilgang til deler av det til noen mennesker som gjør den slags ting, kan du gjøre det, men du må ha en veldig god grunn. Det er mye mer sannsynlig at du lar den ligge der den er og sikre den der den er.
Dez Blanchfield: Ja, jeg er enig i det hvis jeg kan veie inn raskt. Jeg tror utfordringen med blockchain, til og med blockchain som er offentlig der ute, den brukes på bitcoin - vi har vanskelig for å skalere den utover, slags, fire transaksjoner i minuttet på en full distribuert måte. Ikke så mye på grunn av den beregnede utfordringen, selv om den er der, er det bare vanskelig å følge med på databasevolumene frem og tilbake og mengden data som blir kopiert fordi det er spillejobber nå, ikke bare megs.
Men også, jeg tror den viktigste utfordringen er at du trenger å endre arkitekturen til applikasjonen, fordi det i en database hovedsakelig handler om å bringe alt til et sentralt sted, og du har den klient-server-modellen. Blockchain er det inverse; det handler om distribuerte eksemplarer. Det er mer som BitTorrent på mange måter, og det er at mange eksemplarer er der ute av de samme dataene. Og du vet, som Cassandra og databaser i minnet der du distribuerer det og mange servere kan gi deg kopier av de samme dataene fra en distribuert indeks. Jeg tror de to viktige delene, som du sa, Robin, er: en, hvis du vil sikre den og sørge for at den ikke kan bli stjålet eller hacket, er det flott, men det er ikke nødvendigvis en transaksjonsplattform ennå, og vi Det har jeg opplevd med bitcoin-prosjektet. Men i teorien har andre løst det. Men også, arkitektonisk, mange av applikasjonene der ute vet bare ikke hvordan jeg skal spørre og lese fra en blockchain.
Det er mye arbeid som skal gjøres der. Men jeg tror at hovedpoenget med spørsmålet der, bare hvis jeg kan, er begrunnelsen for å flytte det til en blockchain, jeg tror spørsmålet som blir stilt er, kan du ta data ut av en database og legge dem inn i en eller annen form som mer sikkert? Og svaret er at du kan la den ligge i databasen og bare kryptere den. Det er mange teknologier nå. Bare krypter dataene i ro eller i bevegelse. Det er ingen grunn til at du ikke kan ha krypterte data i minnet og i databasen på disken, noe som er en langt enklere utfordring fordi du ikke har en eneste arkitektonisk endring. Uten tvil de fleste databaseplattformer, det er faktisk bare en funksjon som blir aktivert.
Eric Kavanagh: Ja, vi har et siste spørsmål jeg skal kaste over til deg, Iggy. Det er ganske bra. Fra et SLA- og kapasitetsplanleggingsperspektiv, hva slags skatt er det ved å bruke systemet ditt? Med andre ord, noen ekstra forsinkelser eller gjennomstrømningskostnader hvis noen i et produksjonsdatabasesystem ønsker å involvere IDERAs teknologi her?
Ignacio Rodriguez: Vi ser virkelig ikke så veldig mye. Igjen, det er et middelfritt produkt, og det avhenger av, som jeg nevnte før, øyeblikksbildene. Sikker er basert på øyeblikksbilder. Den vil gå ut der og faktisk lage en jobb som vil gå ut der basert på intervallene du har valgt. Enten vil du gjøre det, igjen, ukentlig, daglig, månedlig. Den vil gå der ute og utføre jobben og deretter samle inn dataene fra forekomstene. På det tidspunktet kommer belastningen deretter tilbake til administrasjons- og innsamlingstjenestene. Når du først har gjort sammenligningene og alt det, spiller ikke belastningen på databasen noen rolle i det. All den belastningen er nå på administrasjons- og innsamlingsserveren, så langt som å gjøre sammenligninger og alt av rapportering og alt det der. Den eneste gangen du treffer databasen er alltid når den gjør selve øyeblikksbildet. Og vi har ikke hatt noen rapporter om at det virkelig er skadelig for produksjonsmiljøene.
Eric Kavanagh: Ja, det er et veldig bra poeng du gjør der. I utgangspunktet kan du bare angi hvor mange øyeblikksbilder du tar, hva tidsintervallet er, og avhengig av hva det kan hende, men det er veldig intelligent arkitektur. Det er gode ting, mann. Vel, dere er ute på frontlinjen og prøver å beskytte oss mot alle hackerne vi snakket om i løpet av de første 25 minuttene av showet. Og de er der ute, folk, gjør ingen feil.
Vel, hør, vi legger ut en lenke til denne webcasten, arkivene, på nettstedet insideanalysis.com. Du kan finne ting på SlideShare, du kan finne det på YouTube. Og folkens, gode ting. Takk for tiden din, Iggy, jeg elsker kallenavnet ditt, forresten. Med det tar vi farvel, folkens. Tusen takk for din tid og oppmerksomhet. Vi henter deg neste gang. Ha det.
