Af Techopedia Staff, 27. oktober 2016
Takeaway: Værten Eric Kavanagh diskuterer databasesikkerhed med Robin Bloor, Dez Blanchfield og IDERAs Ignacio Rodriguez.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Hej og velkommen, igen, til Hot Technologies. Jeg hedder Eric Kavanagh; Jeg vil være din vært for webcast i dag, og det er et varmt emne, og det vil aldrig være et varmt emne. Dette er et varmt emne nu på grund af ærligt talt alle de overtrædelser, vi hører om, og jeg kan garantere dig, at det aldrig vil forsvinde. Så emnet i dag, den nøjagtige titel på showet, som jeg burde sige, er "The New Normal: Deal with the Reality of a Unsecure World." Det er præcis, hvad vi har at gøre med.
Vi har din vært, din virkelig, lige der. Fra et par år siden, skal du huske, jeg skulle sandsynligvis opdatere mit foto; det var 2010. Tiden flyver. Send mig en e-mail med, hvis du vil komme med nogle forslag. Så dette er vores standard "hot" dias til Hot Technologies. Hele formålet med dette show er virkelig at definere et bestemt rum. Så i dag taler vi naturligvis om sikkerhed. Vi tager en meget interessant vinkel på det, faktisk med vores venner fra IDERA.
Og jeg vil påpege, at du som vores publikumsmedlemmer spiller en betydelig rolle i programmet. Vær ikke sky. Send os et spørgsmål når som helst, og vi står i kø til spørgsmål og svar, hvis vi har tid nok til det. Vi har tre mennesker online i dag, Dr. Robin Bloor, Dez Blanchfield og Ignacio Rodriguez, der ringer ind fra et ikke afsløret sted. Så først og fremmest Robin, du er den første præsentant. Jeg giver dig nøglerne. Tage det væk.
Dr. Robin Bloor: Okay, tak for det, Eric. Sikring af database - Jeg formoder, at vi kunne sige, at sandsynligheden for, at de mest værdifulde data, som enhver virksomhed faktisk præsiderer for, er i en database. Så der er en hel række sikkerhedsmæssige ting, vi kunne tale om. Men hvad jeg troede, jeg ville gøre, var at tale om emnet med at sikre databasen. Jeg vil ikke fjerne noget fra den præsentation, som Ignacio vil give.
Så lad os starte med, det er let at tænke på datasikkerhed som et statisk mål, men det er det ikke. Det er et bevægende mål. Og det er slags vigtigt at forstå i den forstand, at de fleste menneskers it-miljøer, især store virksomheds-IT-miljøer, ændrer sig hele tiden. Og fordi de ændrer sig hele tiden, ændrer angrebsoverfladen, de områder, hvor nogen kan forsøge på en eller anden måde, enten indefra eller udefra, til at kompromittere datasikkerhed hele tiden. Og når du gør noget i det, opgraderer du en database, har du ingen idé om, om du bare har oprettet en slags sårbarhed for dig selv. Men du er ikke opmærksom på og måske aldrig finde ud af, før noget elendigt sker.
Der er en kort oversigt over datasikkerhed. For det første er datatyveri ikke noget nyt, og data, der er værdifulde, målrettes. Det er normalt let at arbejde for en organisation, hvad de data, de har brug for at lægge mest beskyttelse på, er. En mærkelig kendsgerning er, at den første eller hvad vi kunne hævde at være den første computer, blev bygget af britisk efterretning under anden verdenskrig med et formål for øje, og det var at stjæle data fra tysk kommunikation.
Så tyveri af data har været en del af IT-branchen stort set siden det begyndte. Det blev meget mere alvorligt med fødslen af internettet. Jeg kiggede på en log over antallet af dataovertrædelser, der opstod år efter år efter år. Og antallet var raket over 100 i 2005 og fra det tidspunkt var det en tendens til at blive værre og værre for hvert år.
Større mængder data bliver stjålet og et større antal hacks finder sted. Og det er de hacks, der rapporteres. Der er et meget stort antal hændelser, der forekommer, hvor virksomheden aldrig siger noget, fordi der ikke er noget, der tvinger det til at sige noget. Så det holder dataovertrædelsen stille. Der er mange spillere i hackingbranchen: regeringer, virksomheder, hackergrupper, enkeltpersoner.
En ting, som jeg bare synes, det er interessant at nævne, da jeg tog til Moskva, tror jeg, det var engang for ca. fire år siden, det var en softwarekonference i Moskva, jeg talte med en journalist, der specialiserede sig inden for datahacking. Og han hævdede - og jeg er sikker på, at han har ret, men jeg ved det ikke andet end at han er den eneste person, der nogensinde har nævnt det for mig, men - der er en russisk virksomhed, der hedder The Russian Business Network, den har sandsynligvis en russisk navn, men jeg tror, det er den engelske oversættelse af det, der faktisk hyres til at hacke.
Så hvis du er en stor organisation overalt i verden, og du vil gøre noget for at skade din konkurrence, kan du ansætte disse mennesker. Og hvis du ansætter disse mennesker, får du meget troværdig fornøjelse med hensyn til, hvem der stod bag hacket. For hvis det overhovedet opdages, hvem der er bag hacket, vil det indikere, at det sandsynligvis er nogen i Rusland, der gjorde det. Og det ser ikke ud som om du forsøgte at skade en konkurrent. Og jeg tror, at det russiske forretningsnetværk faktisk er blevet hyret af regeringer til at gøre ting som at hacke ind i banker for at prøve at finde ud af, hvordan terroristpenge bevæger sig rundt. Og det gøres med plausibel afviselighed fra regeringer, der aldrig vil indrømme, at de faktisk nogensinde har gjort det.
Teknologien til angreb og forsvar udvikler sig. For længe siden plejede jeg at gå til Chaos Club. Det var et sted i Tyskland, hvor du kunne registrere dig, og du kunne bare følge samtalerne fra forskellige mennesker og se, hvad der var tilgængeligt. Og det gjorde jeg, da jeg kiggede på sikkerhedsteknologi, jeg tænker omkring 2005. Og jeg gjorde det bare for at se, hvad der gik ned, og det, der forbløffede mig, var antallet af vira, hvor det dybest set var et open source-system Jeg gik videre, og folk, der havde skrevet vira eller forbedrede vira, holdt bare koden derop for nogen at bruge. Og det forekom mig på det tidspunkt, at hackere kan være meget, meget smarte, men der er en frygtelig masse hackere, der ikke nødvendigvis er smarte overhovedet, men de bruger smarte værktøjer. Og nogle af disse værktøjer er bemærkelsesværdige smarte.
Og det sidste punkt her: Virksomheder har en pligt til at passe på deres data, uanset om de ejer dem eller ej. Og jeg tror, det bliver mere og mere realiseret, end det plejede at være. Og det bliver mere og mere, lad os sige, dyrt for en virksomhed at faktisk gennemgå et hack. Om hackerne kan de være placeret overalt, måske vanskelige at bringe for retten, selvom de er korrekt identificeret. Mange af dem meget dygtige. Betydelige ressourcer, de har botnets overalt. Det nylige DDoS-angreb, der fandt sted, antages at være kommet fra over en milliard enheder. Jeg ved ikke, om det er sandt, eller om det kun er en reporter, der bruger et rundt nummer, men bestemt blev et stort antal robotanordninger brugt til at angribe DNS-netværket. Nogle rentable virksomheder, der er regeringsgrupper, der er økonomisk krigføring, der er cyberwarfare, alt foregår derude, og det er usandsynligt, jeg tror, vi sagde i formuen, det er usandsynligt, at det nogensinde vil ende.
Overholdelse og forskrifter - der er en række ting, der faktisk foregår. Der er mange overholdelsesinitiativer, der er sektorbaserede, du ved - lægemiddelsektoren eller banksektoren eller sundhedssektoren - kan have specifikke initiativer, som folk kan følge, forskellige former for bedste praksis. Men der er også mange officielle regler, som fordi de er lovlige, har sanktioner knyttet til enhver, der overtræder loven. De amerikanske eksempler er HIPAA, SOX, FISMA, FERPA, GLBA. Der er nogle standarder, PCI-DSS er en standard for kortselskaber. ISO / IEC 17799 er baseret på at forsøge at få en fælles standard. Dette er ejerskab af data. Nationale regler adskiller sig fra land til land, også i Europa, eller man måske måske sige, især i Europa, hvor det er meget forvirrende. Og der er en GDPR, en global databeskyttelsesforordning, der i øjeblikket forhandles mellem Europa og De Forenede Stater for at forsøge at harmonisere i reglerne, fordi der er så mange, ofte som de faktisk er internationale, og så er der skytjenester, som du måske tror ikke dine data var internationale, men de gik internationale, så snart du gik ind i skyen, fordi de flyttede ud af dit land. Så det er et sæt regler, der på en eller anden måde forhandles for at beskæftige sig med databeskyttelse. Og det meste af det har at gøre med dataene fra et individ, som naturligvis indeholder stort set alle identitetsdata.
Ting at tænke på: databasesårbarheder. Der er en liste over sårbarheder, der er kendt og rapporteret af databaseleverandører, når de bliver opdaget og lappet så hurtigt som muligt, så der er alt det. Der er ting, der vedrører det med hensyn til at identificere sårbare data. Et af de store og mest succesrige hacks med betalingsdata blev gjort til et betalingsforarbejdningsfirma. Det blev senere overtaget, fordi det måtte gå i likvidation, hvis det ikke gjorde det, men dataene blev ikke stjålet fra nogen af de operationelle databaser. Dataene blev stjålet fra en testdatabase. Det skete bare så, at udviklerne netop havde taget en undergruppe af de data, der var rigtige data, og brugte dem, uden nogen som helst beskyttelse, i en testdatabase. Testdatabasen blev hacket, og en frygtelig masse menneskers personlige økonomiske detaljer blev taget fra den.
Sikkerhedspolitikken, især i relation til adgangssikkerhed for databaser, hvem der kan læse, hvem der kan skrive, hvem der kan give tilladelser, er der nogen måde, hvorpå nogen kan omgå noget af dette? Så er der naturligvis krypteringer fra databaser det. Der er omkostningerne ved et sikkerhedsbrud. Jeg ved ikke, om det er standardpraksis inden for organisationer, men jeg ved, at nogle ligesom øverste sikkerhedsofficerer forsøger at give lederne en idé om, hvad udgifterne til et sikkerhedsbrud faktisk er, før det sker snarere end efter. Og de skal slags gøre det for at sikre, at de får det rigtige budgetmængde for at kunne forsvare organisationen.
Og derefter angrebets overflade. Angrebets overflade ser ud til at vokse hele tiden. Det ser ud til år, at angrebets overflade bare vokser. Så i resuméet er rækkevidde et andet punkt, men datasikkerhed er normalt en del af DBA's rolle. Men datasikkerhed er også en samarbejdsaktivitet. Du skal have, hvis du udfører sikkerhed, skal du have en fuld idé om sikkerhedsbeskyttelsen for organisationen som helhed. Og der er brug for en politik på dette område. Hvis der ikke er virksomhedspolitikker, ender du bare med stykkevise løsninger. Du ved, gummibånd og plast, slags forsøg på at stoppe sikkerheden, der sker.
Så når det er sagt, tror jeg, jeg overleverer Dez, som sandsynligvis vil give dig forskellige krigshistorier.
Eric Kavanagh: Tag den væk, Dez.
Dez Blanchfield: Tak, Robin. Det er altid en hård handling at følge. Jeg vil komme til dette fra den modsatte ende af spektret bare for, antager jeg, at give os en fornemmelse af omfanget af den udfordring, du står overfor, og hvorfor vi skal gøre mere end bare at sidde op og være opmærksomme på dette . Den udfordring, vi ser nu med skalaen og mængden og lydstyrken, den hastighed, hvorpå disse ting sker, er, at den ting, jeg hører rundt på stedet nu med en masse CXO'er, ikke kun CIO'er, men bestemt CIO'er er dem, der er til stede, hvor sorteperen stopper, er at de anser dataovertrædelser for hurtigt at blive normen. Det er noget, de næsten forventer at ske. Så de ser på dette ud fra ”Okay, når vi bliver brudt - ikke hvis - når vi bliver brudt, hvad skal vi have gjort ved dette?” Og så begynder samtalerne, hvad laver de i de traditionelle kantmiljøer og routere, switches, servere, intrusionsdetektion, indtrængen inspektion? Hvad laver de i systemerne selv? Hvad laver de med dataene? Og så kommer det hele tilbage til, hvad de gjorde med deres databaser.
Lad mig bare røre ved et par eksempler på nogle af disse ting, der har fanget en masse folks fantasi og derefter bore ned til, slags bryde dem op lidt. Så vi har hørt i nyheden, at Yahoo - sandsynligvis det største antal, som folk har hørt, er omkring en halv million, men det viser sig faktisk, at det er uofficielt mere som en milliard - jeg hørte et udlandskt tal på tre milliarder, men det er næsten halvdelen af verdens befolkning, så jeg synes, det er lidt højt. Men jeg har fået det bekræftet fra et antal folk i relevante rum, der mener, at der er lidt over en milliard poster, der er blevet brudt ud af Yahoo. Og dette er bare et forbløffende nummer. Nu ser og tænker nogle spillere, det er bare webmail-konti, ingen big deal, men så tilføjer du det faktum, at mange af disse webmail-konti, og et underligt højt tal, højere end jeg havde forventet, faktisk er betalte konti. Det er her folk lægger deres kreditkortoplysninger i, og de betaler for at fjerne annoncerne, fordi de bliver trætte af annoncerne, og derfor er $ 4 eller $ 5 om måneden villige til at købe en webmail og cloud-lagringstjeneste, der ikke har annoncer, og jeg er en af dem, og det har jeg på tværs af tre forskellige udbydere, hvor jeg tilslutter mit kreditkort.
Så så får udfordringen lidt mere opmærksomhed, fordi det ikke bare er noget derude som en smidrig linje med at sige: ”Nå, Yahoo har mistet, lad os sige, mellem 500 millioner og 1.000 millioner konti, ” gør 1.000 millioner det lyder meget stort og webmail-konti, men kreditkortoplysninger, fornavn, efternavn, e-mail-adresse, fødselsdato, kreditkort, pinkode, hvad du end vil, adgangskoder, og så bliver det et meget mere skræmmende koncept. Og igen siger folk til mig, ”Ja, men det er bare webservice, det er bare webmail, ingen big deal.” Og så siger jeg, ”Ja, ja, at Yahoo-konto muligvis også er blevet brugt i Yahoo-penge-tjenester til at købe og sælge aktier. ”Så bliver det mere interessant. Og når du begynder at bore ned i det, er du klar over, at okay, dette er faktisk mere end bare mødre og far hjemme, og teenagere med messaging-konti, dette er faktisk noget, hvor folk har foretaget forretningstransaktioner.
Så det er den ene ende af spektret. Den anden ende af spektret er, at en meget lille sundhedsudbyder i Australien havde omkring 1.000 poster stjålet. Var et internt job, nogen forlod, de var bare nysgerrige, de gik ud af døren, i dette tilfælde var det en 3, 5 tommers diskett. Det var for lidt siden - men du kan fortælle medienes æra - men de handlede om gammel teknologi. Men det viste sig, at grunden til, at de tog dataene, var, at de bare var nysgerrige efter, hvem der var derinde. Fordi de havde ganske mange mennesker i denne lille by, som var vores nationale hovedstad, som var politikere. Og de var interesseret i, hvem der var derinde, og hvor deres liv var, og al den slags information. Så med et meget lille dataovertrædelse, der blev foretaget internt, var angiveligt et betydeligt stort antal politikere i den australske regerings detaljer angiveligt offentligt.
Vi har to forskellige ender af spektret der at overveje. Nu er virkeligheden, at den rene skala af disse ting bare er svimlende, og jeg har et dias, som vi vil springe til meget, meget hurtigt her. Der er et par websteder, der viser alle slags data, men netop denne er fra en sikkerhedsspecialist, der havde webstedet, hvor du kan gå og søge efter din e-mail-adresse eller dit navn, og det viser dig enhver datahændelse overtrædelse i løbet af de sidste 15 år, som han har været i stand til at få sine hænder på, og derefter indlæse i en database og verificere, og det vil fortælle dig, om du var blevet pwned, som ordet er. Men når du begynder at se på nogle af disse numre, og dette skærmbillede er ikke blevet opdateret med hans seneste version, der inkluderer et par, såsom Yahoo. Men tænk bare på de typer tjenester her. Vi har Myspace, vi har LinkedIn, Adobe. Adobes interessante, fordi folk ser og tænker, hvad betyder Adobe? De fleste af os der downloader Adobe Reader af en eller anden form, mange af os har købt Adobe-produkter med et kreditkort, det er 152 millioner mennesker.
Nu, til Robin's punkt tidligere, er dette meget store tal, det er let at blive overvældet af dem. Hvad sker der, når du har fået 359 millioner konti, der er blevet brudt? Der er et par ting. Robin understregede det faktum, at disse data altid findes i en database af en eller anden form. Det er den kritiske meddelelse her. Næsten ingen på denne planet, som jeg er opmærksom på, der kører et system af enhver form, gemmer det ikke i en database. Men hvad der er interessant er, at der er tre forskellige typer data i denne database. Der er sikkerhedsrelaterede ting såsom brugernavne og adgangskoder, som normalt er krypterede, men altid er der masser af eksempler, hvor de ikke er. Der er de faktiske kundeoplysninger omkring deres profil og data, de har oprettet, uanset om det er en sundhedsrekord, eller om det er en e-mail eller en onlinemeddelelse. Og så er der den faktiske indlejrede logik, så dette kunne lagres procedurer, det kan være en hel masse regler, hvis + dette + så + det. Og altid er det bare ASCII-tekst, der sidder fast i databasen, meget få mennesker sidder der og tænker: ”Dette er forretningsregler, det er sådan, vores data flyttes rundt og kontrolleres, vi bør potentielt kryptere disse, når de er i ro, og når de er i bevægelse måske dekrypterer vi den og opbevarer den i hukommelsen, ”men ideelt skal det også være.
Men det kommer tilbage til dette centrale punkt, at alle disse data er i en database af en eller anden form, og oftere end ikke er fokuset, historisk set, været på routere og switches og servere og endda lagring, og ikke altid på databasen på bagenden. Fordi vi tror, at vi har dækket kanten af netværket, og det er, slags, en typisk gammel, slags, bor i et slot, og du lægger en vollgrav omkring det, og du håber, at de slemme fyre ikke vil være i stand til at svømme. Men så pludselig arbejdede de slemme fyre ud på, hvordan man kunne lave udstrakte stiger og kaste dem over voldgraven og klatre over voldgraven og klatre op på væggene. Og pludselig er din vollgrav temmelig ubrugelig.
Så vi er nu i det scenarie, hvor organisationer er i indhentningstilstand i en sprint. De er bogstaveligt talt sprint på tværs af alle systemer, efter min mening, og bestemt min oplevelse, idet det ikke altid er bare disse webhjørner, som vi ofte henviser til dem, oftere end ikke det er traditionelle virksomhedsorganisationer, der bliver brudt. Og du behøver ikke have meget fantasi for at finde ud af, hvem de er. Der er websteder som en, der kaldes pastebin.net, og hvis du går til pastebin.net, og du bare indtaster e-mail-liste eller adgangskodeliste, ender du med hundreder af tusinder af poster om dagen, der tilføjes, hvor folk viser eksempler på datasæt af op til tusind poster med fornavn, efternavn, kreditkortoplysninger, brugernavn, adgangskode, dekrypterede adgangskoder, forresten. Hvor folk kan gribe den liste, gå og verificere tre eller fire af dem og beslutte, at ja, jeg vil købe den liste, og der er normalt en form for mekanisme, der leverer en slags anonym gateway til den person, der sælger dataene.
Hvad der nu er interessant, er, at når den tilknyttede iværksætter er klar over, at de kan gøre dette, behøver det ikke så meget fantasi at indse, at hvis du bruger 1.000 $ til at købe en af disse lister, hvad er den første ting, du gør med det? Du går ikke og forsøger at spore konti, du lægger en kopi af det tilbage på pastbin.net og du sælger to eksemplarer for $ 1.000 hver og tjener $ 1.000. Og dette er børn, der gør dette. Der er nogle ekstremt store professionelle organisationer over hele verden, der gør dette for at leve. Der er endda statsnationer, der angriber andre stater. Du ved, der er en masse tale om, at Amerika angriber Kina, Kina angriber Amerika, det er ikke helt så enkelt, men der er bestemt regeringsorganisationer, der overtræder systemer, der uundgåeligt er drevet af databaser. Det er ikke kun et tilfælde af små organisationer, det er også lande kontra lande. Det bringer os tilbage til det spørgsmål om, hvor er dataene gemt? Det er i en database. Hvilke kontroller og mekanismer er der? Eller altid er de ikke krypterede, og hvis de er krypterede, er det ikke altid alle data, måske er det bare adgangskoden, der er saltet og krypteret.
Og pakket rundt om dette har vi en række udfordringer med hvad der findes i disse data, og hvordan vi giver adgang til data og SOX-overholdelse. Så hvis du tænker på formuesstyring eller bankvirksomhed, har du organisationer, der bekymrer dig om den legitime udfordring; du har organisationer, der bekymrer dig om overholdelse i virksomhedsområdet; du har regeringens overholdelse og lovgivningsmæssige krav; du har nu scenarier, hvor vi har databaser på stedet; vi har databaser i tredjepartsdatacentre; Vi har databaser, der sidder i skymiljøer, så skymiljøerne altid ikke altid er i landet. Og så dette bliver en større og større udfordring, ikke kun fra det rene sikkerhed-lad-ikke-få-hacket synspunkt, men også, hvordan kan vi imødekomme alle de forskellige niveauer af overholdelse? Ikke kun HIPAA- og ISO-standarderne, men der er bogstaveligt talt dusinvis og snesevis og snesevis af disse på statsniveau, nationalt niveau og globalt niveau, der krydser grænser. Hvis du handler med Australien, kan du ikke flytte regeringsdata. Eventuelle australske private data kan ikke forlade nationen. Hvis du er i Tyskland er det endnu strengere. Og jeg ved, at Amerika også bevæger sig meget hurtigt på dette af forskellige årsager.
Men det bringer mig tilbage til hele denne udfordring om, hvordan ved du, hvad der sker i din database, hvordan overvåger du den, hvordan fortæller du, hvem der gør hvad i databasen, hvem der har oversigt over forskellige tabeller og rækker og kolonner og felter, hvornår læser de den, hvor ofte læser de den, og hvem sporer den? Og jeg tror, det bringer mig til mit sidste punkt, før jeg overleverer til vores gæst i dag, der vil hjælpe os med at tale om, hvordan vi løser dette problem. Men jeg vil overlade os til denne ene tanke, og det vil sige, at meget af fokus er på omkostningerne for virksomheden og omkostningerne for organisationen. Og vi vil ikke dække dette punkt i detaljer i dag, men jeg vil bare lade det være i vores sind for at overveje, og det er, at der er et skøn på ca. mellem $ 135 og 585 $ pr. Rekord for at rydde op efter et brud. Så den investering, du foretager i din sikkerhed omkring routere og switches og servere, er alt sammen godt og godt og firewalls, men hvor meget har du investeret i din databasesikkerhed?
Men det er en falsk økonomi, og da Yahoos overtrædelse skete for nylig, og jeg har det med god autoritet, er det omtrent en milliard konti, ikke 500 millioner. Da Verizon købte organisationen for noget som 4, 3 mia., Så snart overtrædelsen skete, bad de om en milliard dollars tilbage eller en rabat. Hvis du nu laver matematikken, og du siger, at der er nogenlunde en milliard poster, der blev brudt, en milliardrabat, bliver $ 135 til $ 535-estimatet for oprydning af en post nu $ 1. Hvilket igen er farcical. Det koster ikke $ 1 at rydde op i en milliard poster. Til $ 1 pr. Rekord for at rydde op i en milliard poster for et brud på den størrelse. Du kan ikke engang udsætte en pressemeddelelse for den slags omkostninger. Og så fokuserer vi altid på de interne udfordringer.
Men en af tingene, tror jeg, og det skal os tage dette meget alvorligt på databaseniveau, hvorfor dette er et meget, meget vigtigt emne for os at tale om, og det er det, vi snakker aldrig om det menneskelige afgift. Hvad er den menneskelige vejafgift, som vi pådrager os her? Og jeg vil tage et eksempel, før jeg hurtigt går sammen. LinkedIn: i 2012 blev LinkedIn-systemet hacket. Der var et antal vektorer, og det vil jeg ikke gå ind på. Og hundreder af millioner af konti blev stjålet. Folk siger ca. 160 mio. Millioner, men det er faktisk et meget større antal, det kan være så mange som omkring 240 millioner. Men denne overtrædelse blev først annonceret. Det er fire år, at hundreder af millioner af folks poster er derude. Nu var der nogle mennesker, der betalte for tjenester med kreditkort, og nogle mennesker med gratis konti. Men LinkedIn er interessant, fordi de ikke kun fik adgang til dine kontooplysninger, hvis du blev overtrådt, men de fik også adgang til alle dine profiloplysninger. Så hvem du var forbundet med og alle de forbindelser, du havde, og hvilke typer job, de havde, og hvilke typer af færdigheder, de havde, og hvor længe de havde arbejdet hos virksomheder og al den slags information og deres kontaktoplysninger.
Så tænk på den udfordring, vi har med at sikre dataene i disse databaser, og sikre og styre databasesystemerne selv, og strømmen på påvirkning, den menneskelige vejafgift for disse data, der er derude i fire år. Og sandsynligheden for, at nogen kan komme til en ferie et eller andet sted i Sydøstasien, og de har haft deres data derude i fire år. Og nogen har måske købt en bil eller fået et boliglån eller købt ti telefoner i løbet af året på kreditkort, hvor de oprettede en falsk id på de data, der var derude i fire år - fordi selv LinkedIn-dataene gav dig nok information til Opret en bankkonto og et falskt ID - og du kommer på flyet, du rejser til en ferie, du lander og du bliver smidt i fængsel. Og hvorfor kastes du i fængsel? Fordi du fik dit ID stjålet. En person oprettede en falsk id og handlede som dig og hundreder af tusinder af dollars, og de gjorde dette fire år, og du vidste ikke engang om det. Fordi det er derude, skete det bare.
Så jeg tror, det bringer os til denne centrale udfordring om, hvordan ved vi, hvad der sker på vores databaser, hvordan sporer vi det, hvordan overvåger vi det? Og jeg ser frem til at høre, hvordan vores venner på IDERA har fundet en løsning på det. Og med det vil jeg aflevere.
Eric Kavanagh: Okay, Ignacio, ordet er dit.
Ignacio Rodriguez: Okay. Velkommen alle sammen. Mit navn er Ignacio Rodriguez, bedre kendt som Iggy. Jeg er hos IDERA og en produktchef for sikkerhedsprodukter. Virkelig gode emner, vi lige har dækket, og vi er virkelig nødt til at bekymre os om dataovertrædelserne. Vi er nødt til at have hærdede sikkerhedspolitikker, vi er nødt til at identificere sårbarheder og vurdere sikkerhedsniveauer, kontrollere brugerrettigheder, kontrollere serversikkerhed og overholde revisioner. Jeg har foretaget revision i min tidligere historie, mest på Oracle-siden. Jeg har lavet nogle på SQL Server og gjort dem med værktøjer eller dybest set hjemmearbejde scripts, hvilket var fantastisk, men du er nødt til at oprette et depot og sørge for, at depotet var sikkert, og konstant skulle vedligeholde scripts med ændringer fra revisorerne, hvad har du.
Så hvis jeg havde vidst, at IDERA var derude og havde et værktøj, ville jeg mere end sandsynligt have købt det. Men under alle omstændigheder skal vi tale om Secure. Det er et af vores produkter i vores sikkerhedsproduktlinje, og hvad det dybest set gør, er at vi ser på sikkerhedspolitikkerne og kortlægger dem til lovgivningsmæssige retningslinjer. Du kan se en komplet historie med SQL Server-indstillinger, og du kan også dybest set foretage en baseline af disse indstillinger og derefter sammenligne med fremtidige ændringer. Du er i stand til at oprette et snapshot, som er en basislinje for dine indstillinger, og derefter være i stand til at spore, om nogen af disse ting er blevet ændret, og også blive underrettet, hvis de ændres.
En af de ting, vi gør godt, er at forhindre sikkerhedsrisiko og krænkelser. Sikkerhedsrapportkortet giver dig et overblik over de øverste sikkerhedssårbarheder på serverne, og derefter kategoriseres også hver sikkerhedskontrol som høj, mellem eller lav risiko. På disse kategorier eller sikkerhedskontrol kan alle disse nu ændres. Lad os sige, at hvis du har nogle kontroller og bruger en af de skabeloner, som vi har, og du beslutter, ja, angiver eller ønsker vores kontroller virkelig, at denne sårbarhed ikke virkelig er et højt, men et medium, eller omvendt. Du har måske nogle, der er mærket som medium, men i din organisation er de kontroller, du vil mærke dem, eller betragter dem som høje, alle disse indstillinger kan konfigureres af brugeren.
Et andet kritisk problem, som vi er nødt til at se på, er at identificere sårbarhederne. At forstå, hvem der har adgang til hvad, og identificere hver af brugerens effektive rettigheder på tværs af alle SQL Server-objekter. Med værktøjet vil vi være i stand til at gennemgå og se på rettighederne på tværs af alle SQL Server-objekter, og vi ser snart et skærmbillede af dette her. Vi rapporterer og analyserer også bruger-, gruppe- og rolletilladelser. En af de andre funktioner er, at vi leverer detaljerede sikkerhedsrisikorapporter. Vi har out-of-the-box rapporter og indeholder fleksible parametre til dig for at oprette de typer rapporter og vise de data, som revisorer, sikkerhedsansvarlige og ledere har brug for.
Vi kan også sammenligne ændringer i sikkerhed, risiko og konfiguration over tid, som jeg nævnte. Og de er med snapshots. Og disse snapshots kan konfigureres, så vidt du vil gøre dem - månedligt, kvartalsvis, årligt - der kan planlægges i værktøjet. Og igen kan du foretage sammenligninger for at se, hvad der har ændret sig, og hvad der er rart ved det, er, at hvis du havde en overtrædelse, kunne du oprette et øjebliksbillede efter det blev korrigeret, foretage en sammenligning, og du ville se, at der var et højt niveau risiko forbundet med det forrige snapshot og derefter rapportere, ser du faktisk i det næste snapshot, efter at det blev korrigeret, at det ikke længere var et problem. Det er et godt revisionsværktøj, som du kunne give revisoren, en rapport, som du kunne give revisorerne og sige: ”Se, vi havde denne risiko, vi afbød den, og nu er det ikke længere en risiko.” Og igen, jeg nævnt med de snapshots, du kan advare, når en konfiguration ændres, og hvis en konfiguration ændres og opdages, der udgør en ny risiko, får du også besked om det.
Vi får nogle spørgsmål om vores SQL Server Arkitektur med Secure, og jeg vil gerne foretage en korrektion af diaset her, hvor det står "Collection Service." Vi har ikke nogen tjenester, det burde have været "Management and Collection Server. ”Vi har vores konsol og derefter vores Management og Collection Server, og vi har en agentløs fangst, der går ud til de databaser, der er blevet registreret og indsamler dataene gennem job. Og vi har et SQL Server Repository, og vi arbejder sammen med SQL Server Reporting Services for også at planlægge rapporter og oprette brugerdefinerede rapporter. Nu på et sikkerhedsrapportkort er dette den første skærm, du vil se, når SQL Secure startes. Du kan nemt se, hvilke kritiske elementer du har, som det registreres. Og igen har vi det høje, det medie og det laveste. Og så har vi også de politikker, der spiller med den særlige sikkerhedskontrol. Vi har en HIPAA-skabelon; vi har IDERA-sikkerhedsniveau 1, 2 og 3 skabeloner; vi har PCI-retningslinjer. Dette er alle skabeloner, som du kan bruge, og igen kan du oprette din egen skabelon baseret på dine egne kontroller også. Og igen, de kan ændres. Du kan oprette dine egne. Enhver af de eksisterende skabeloner kan bruges som en basislinje, så kan du ændre dem, som du vil.
En af de dejlige ting at gøre er at se, hvem der har tilladelser. Og med denne skærm her vil vi være i stand til at se, hvad SQL Server-logins er på virksomheden, og du vil være i stand til at se alle de tildelte og effektive rettigheder og tilladelser på serverdatabasen på objektniveau. Vi gør det her. Du kan igen vælge databaserne eller serverne og derefter være i stand til at hente rapporten om SQL Server-tilladelser. Så i stand til at se, hvem der har adgang til hvad. En anden dejlig funktion er, at du vil kunne sammenligne sikkerhedsindstillinger. Lad os sige, at du havde standardindstillinger, der skulle indstilles på tværs af din virksomhed. Du kan derefter sammenligne alle dine servere og se, hvilke indstillinger der blev indstillet på tværs af de andre servere i din virksomhed.
Igen politikskabeloner, dette er nogle af de skabeloner, vi har. Du bruger dybest set igen en af disse, opret din egen. Du kan oprette din egen politik, som det ses her. Brug en af skabelonerne, og du kan ændre dem efter behov. Vi er også i stand til at se effektive rettigheder på SQL Server. Dette vil verificere og bevise, at tilladelser er korrekt indstillet til brugere og roller. Igen kan du gå derude og se og se og kontrollere, at tilladelsen er korrekt indstillet til brugere og roller. Derefter med SQL Server Object Access Rights kan du derefter gennemse og analysere SQL Server-objekttræet ned fra serverniveau ned til objektniveauets roller og slutpunkter. Og du kan med det samme se de tildelte og effektive nedarvede tilladelser og sikkerhedsrelaterede egenskaber på objektniveau. Dette giver dig et godt overblik over de adganger, du har på dine databaseobjekter, og hvem der har adgang til dem.
Vi har igen vores rapporter, som vi har. Det er konserverede rapporter, vi har flere, som du kan vælge imellem for at gøre din rapportering. Og mange af disse kan tilpasses, eller du kan få dine kunderapporter og bruge dem sammen med rapporteringstjenesterne og være i stand til at oprette dine egne tilpassede rapporter derfra. Nu sammenligning af snapshot, dette er en temmelig cool funktion, tror jeg, hvor du kan gå derude, og du kan foretage en sammenligning af dine snapshots, som du har taget, og se for at se, om der var nogen forskelle i antallet. Er der tilføjet objekter, var der tilladelser, der er ændret, alt hvad vi måske kunne se, hvilke ændringer der er foretaget mellem de forskellige snapshots. Nogle mennesker vil se på disse på et månedligt niveau - de foretager et månedligt snapshot og foretager derefter en sammenligning hver måned for at se, om noget er ændret. Og hvis der ikke var noget, der skulle være blevet ændret, noget, der gik til ændringskontrolmøderne, og du ser, at nogle tilladelser er ændret, kan du gå tilbage for at se, hvad der er sket. Dette er en temmelig flot funktion her, hvor du igen kan sammenligne alt, hvad der er revideret inden for snapshot.
Derefter din vurdering af sammenligningen. Dette er en anden dejlig funktion, som vi har, hvor du kan gå derude og se på vurderingerne og derefter foretage en sammenligning af dem og bemærke, at sammenligningen her havde en SA-konto, der ikke var deaktiveret i det nylige øjebliksbillede, som jeg har gjort - det er nu rettet. Dette er en temmelig dejlig ting, hvor du kan vise, at okay, vi havde en vis risiko, de blev identificeret ved hjælp af værktøjet, og nu har vi afbødet disse risici. Og igen, dette er en god rapport, der viser revisorerne, at disse risici faktisk er blevet afbødet og er taget hånd om.
Kort sagt, databasesikkerhed, det er kritisk, og jeg tror, mange gange vi ser på brud, der kommer fra eksterne kilder, og sommetider er vi ikke rigtig opmærksomme på interne overtrædelser, og det er nogle af de ting, som vi har brug for at passe på. Og Secure vil hjælpe dig der for at sikre dig, at der ikke er nogen privilegier, som ikke behøver at blive tildelt. Du ved, sørg for, at al denne sikkerhed er indstillet korrekt til konti. Sørg for, at dine SA-konti har adgangskoder. Kontrollerer også, indtil dine krypteringsnøgler er blevet eksporteret? Bare flere forskellige ting, som vi tjekker for, og vi vil advare dig om det faktum, om der var et problem, og på hvilket niveau af emission det er. Vi har brug for et værktøj, mange fagfolk har brug for værktøjer til at administrere og overvåge tilladelser til databaseadgang, og vi ser faktisk på at give en omfattende kapacitet til at kontrollere databasetilladelser og spore adgangsaktiviteter og mindske risiko for overtrædelse.
Nu er en anden del af vores sikkerhedsprodukter, at der er en WebEx, der blev dækket, og en del af den præsentation, som vi har talt om tidligere, var data. Du ved, hvem der får adgang til hvad, hvad har du, og det er vores SQL Compliance Manager-værktøj. Og der er en optaget WebEx på dette værktøj, og det vil faktisk give dig mulighed for at overvåge, hvem der har adgang til hvilke tabeller, hvilke kolonner, du kan identificere tabeller, der har følsomme kolonner, så langt som fødselsdato, patientinformation, disse typer tabeller og faktisk se, hvem der har adgang til disse oplysninger, og hvis der er adgang til dem.
Eric Kavanagh: Okay, så lad os dykke ned i spørgsmålene, antager jeg, her. Måske, Dez, kaster jeg det først til dig, og Robin kaster dig ind, som du kan.
Dez Blanchfield: Ja, jeg har kløet og stillet et spørgsmål fra 2. og 3. dias. Hvad er den typiske brugssag, du ser for dette værktøj? Hvem er de mest almindelige typer brugere, som du ser, der vedtager dette og sætter det i spil? Og på bagsiden af den typiske, anvendte sagsmodel, hvordan foregår de det? Hvordan implementeres det?
Ignacio Rodriguez: Okay, den typiske brugssag, vi har, er DBA'er, der har fået tildelt ansvaret for adgangskontrol til databasen, som sørger for, at alle tilladelser er indstillet til den måde, de skal være, og derefter holder styr og deres standarder på plads. Du ved, disse bestemte brugerkonti kan kun have adgang til disse bestemte tabeller osv. Og hvad de laver med det, er at sikre, at disse standarder er blevet sat, og at disse standarder ikke er ændret gennem tiden. Og det er en af de store ting, som folk bruger det til, er at spore og identificere, om der foretages ændringer, som ikke er kendt om.
Dez Blanchfield: Fordi de er de skræmmende, ikke sandt? Er det måske, at du har et, lad os sige, et strategidokument, har du politikker, der understøtter det, har du overholdelse og regeringsførelse under det, og du følger politikkerne, du overholder regeringen og det får et grønt lys og så pludselig en måned senere ruller nogen en ændring ud og af en eller anden grund gennemgår den ikke det samme ændringspanel eller ændringsproces, eller hvad det måtte være, eller projektet er bare gået videre og ingen ved.
Har du nogle eksempler, som du kan dele - og jeg ved, selvfølgelig, det er ikke altid noget, du deler, fordi klienter er lidt bekymrede for det, så vi behøver ikke nødvendigvis at navngive navn - men give os et eksempel på hvor du måske har du set dette faktisk, ved du, en organisation har sat dette på plads uden at indse det, og de fandt bare noget og indså, “Wow, det var værd ti gange, vi har lige fundet noget, vi ikke vidste.” Har du fået noget eksempel, hvor folk har implementeret dette og så opdaget, at de havde et større problem eller et reelt problem, som de ikke vidste, at de havde, og så bliver du straks tilføjet på julekortlisten?
Ignacio Rodriguez: Jeg tror, at den største ting, vi har set eller har rapporteret, er, hvad jeg lige har nævnt, for så vidt angår adgangen, som nogen havde haft. Der er udviklere, og da de implementerede værktøjet, vidste de virkelig ikke, at X-mængden af disse udviklere havde så meget adgang til databasen og havde adgang til bestemte objekter. Og en anden ting er skrivebeskyttede konti. Der var nogle skrivebeskyttede konti, som de havde, kom til at finde ud af, at disse skrivebeskyttede konti faktisk var, havde indsat data og slet privilegier. Det er her, vi har set en vis fordel for brugerne. Den store ting, igen, som vi har hørt, at folk kan lide, er i stand til igen at spore ændringerne og sørge for, at intet blinder for dem.
Dez Blanchfield: Som Robin fremhævede, har du scenarier, som folk ikke ofte tænker igennem, ikke? Når vi ser frem, vi, slags tænker, ved du, hvis vi gør alt efter reglerne, og jeg finder, og jeg er sikker på, at du også ser det - fortæl mig, hvis du er uenig i det - organisationer fokuserer så stærkt på at udvikle strategi og politik og overholdelse og regeringsførelse og KPI'er og rapportering, at de ofte bliver så fikserede over, at de ikke tænker på outliers. Og Robin havde et rigtig godt eksempel, som jeg vil stjæle fra ham - undskyld Robin - men eksemplet er den anden gang, hvor en live kopi af databasen, et snapshot og sætte den i udviklingstest, ikke? Vi udfører dev, vi udfører tests, vi udfører UAT, vi udfører systemintegration, alt det slags, og så udfører vi en masse overensstemmelse tests nu. Ofte har dev-test, UAT, SIT faktisk en overholdelseskomponent på det, hvor vi bare sørger for, at det hele er sundt og sikkert, men ikke alle gør det. Dette eksempel, som Robin gav med en kopi af en live-kopi af databasen, der blev sat i en test med udviklingsmiljø for at se, om den stadig fungerer med live-data. Meget få virksomheder læner sig tilbage og tænker, ”sker det endda, eller er det muligt?” De er altid fikserede på produktionsmaterialet. Hvordan ser implementeringsrejsen ud? Taler vi om dage, uger, måneder? Hvordan ser en regelmæssig implementering ud for en gennemsnitlig størrelse?
Ignacio Rodriguez: dage. Det er ikke engang dage, jeg mener, det er bare et par dage. Vi har lige tilføjet en funktion, hvor vi er i stand til at registrere mange, mange servere. I stedet for at skulle gå ind der i værktøjet og sige, at du havde 150 servere, var du nødt til at gå ind der individuelt og registrere serverne - nu behøver du ikke gøre det. Der er en CSV-fil, du opretter, og vi fjerner den automatisk, og vi opbevarer den ikke der på grund af sikkerhedsmæssige problemer. Men det er en anden ting, vi skal overveje, er at du har en CSV-fil derude med brugernavn / adgangskode.
Det, vi gør, er at vi automatisk sletter det igen, men det er en mulighed, du har. Hvis du vil gå ind der individuelt og registrere dem og ikke ønsker at tage den risiko, kan du gøre det. Men hvis du vil bruge en CSV-fil, skal du placere den på en placering, der er sikker, pege applikationen til den placering, den kører den CSV-fil, og derefter er den automatisk indstillet til at slette den fil, når den er færdig. Og det skal gå og sørge for og kontrollere, at filen er fjernet. Den længste pol i sandet, som vi havde så langt som implementering, var registrering af de faktiske servere.
Dez Blanchfield: Okay. Nu talte du om rapporter. Kan du give os lidt mere detaljeret og indsigt i, hvad der kommer forudbundet, så vidt vi rapporterer, antager jeg, opdagelseskomponenten ved at se på hvad der er der og rapportere om det, den aktuelle tilstand i nationen, hvad der kommer før- bygget og forbagt så langt som rapporter omkring den aktuelle tilstand af overholdelse og sikkerhed, og hvor let kan de så udvides? Hvordan bygger vi på dem?
Ignacio Rodriguez: Okay. Nogle af de rapporter, vi har, vi har rapporter, der beskæftiger sig med cross-server, login-kontrol, dataindsamlingsfiltre, aktivitetshistorik og derefter risikovurderingsrapporter. Og også alle mistænkelige Windows-konti. Der er mange, mange her. Se mistænkelige SQL-logins, serverlogins og brugerkortlægning, brugertilladelser, alle brugertilladelser, serverroller, databaseroller, en vis mængde sårbarhed, vi har, eller blandet tilstand-godkendelsesrapporter, gæstaktiverende databaser, OS-sårbarhed via XPS'er, de udvidede procedurer, og derefter de sårbare faste roller. Det er nogle af de rapporter, vi har.
Dez Blanchfield: Og du nævnte, at de er betydningsfulde nok, og en række af dem, hvilket er en logisk ting. Hvor let er det for mig at skræddersy det? Hvis jeg kører en rapport, og jeg får denne fantastiske store graf, men jeg vil tage nogle stykker ud, som jeg ikke er så interesseret i og tilføje et par andre funktioner, er der en rapportforfatter, er der en slags grænseflade og værktøj til at konfigurere og skræddersy eller endda potentielt opbygge en anden rapport fra bunden?
Ignacio Rodriguez: Vi vil derefter henvise brugerne til at bruge Microsoft SQL Report Services til at gøre det, og vi har mange kunder, der rent faktisk vil tage nogle af rapporterne, tilpasse og planlægge dem, når de vil. Nogle af disse fyre ønsker at se disse rapporter på månedlig basis eller ugentlig basis, og de vil tage de oplysninger, vi har, flytte dem ind i Reporting Services og derefter gøre det derfra. Vi har ikke en rapportforfatter integreret med vores værktøj, men vi drager fordel af rapporteringstjenesterne.
Dez Blanchfield: Jeg tror, det er en af de største udfordringer med disse værktøjer. Du kan komme derinde og finde ting, men så skal du være i stand til at trække det ud, rapportere det til folk, der ikke nødvendigvis er DBA'er og systemingeniører. Der er en interessant rolle, der er skabt i min erfaring, og det er, du ved, at risikobetjente altid har været i organisationer, og at de overvejende har været omkring og en helt anden række af risici, som vi har set for nylig, mens nu med data brud bliver ikke bare en ting, men en faktisk tsunami. CRO er gået fra at være, du ved, HR og overholdelse og arbejdsmiljø og sikkerhedstypefokus nu til cyberrisiko. Du ved, brud, hacking, sikkerhed - meget mere teknisk. Og det bliver interessant, fordi der er mange CRO'er, der kommer fra en MBA-stamtavle og ikke en teknisk stamtavle, så de er nødt til at få deres hoveder rundt, slags, hvad det betyder for overgangen mellem cyberrisikoen til at flytte til en CRO osv. Men den store ting, de ønsker, er bare synlighedsrapportering.
Kan du fortælle os noget omkring placeringen med hensyn til overholdelse? Det er klart, at en af de store styrker ved dette er, at du kan se, hvad der foregår, du kan overvåge det, du kan lære, du kan rapportere om det, du kan reagere på det, du kan endda undgå nogle ting. Den overordnede udfordring er regeringsoverholdelse. Er der centrale dele af dette, der bevidst knytter sig til eksisterende overholdelseskrav eller industriens overholdelse som PCI, eller noget lignende i øjeblikket, eller er det noget, der kommer ned ad køreplanen? Passer den, slags, inden for rammerne af ligesom COBIT, ITIL og ISO standarder? Hvis vi implementerer dette værktøj, giver det os en række kontroller og balancer, der passer ind i disse rammer, eller hvordan bygger vi det ind i disse rammer? Hvor er positionen med den slags ting i tankerne?
Ignacio Rodriguez: Ja, der er skabeloner, som vi har, som vi leverer med værktøjet. Og vi kommer til det punkt, hvor vi revurderer vores skabeloner, og vi vil tilføje, og der kommer flere snart. FISMA, FINRA, nogle yderligere skabeloner, som vi har, og vi gennemgår typisk skabeloner og ser for at se, hvad der har ændret sig, hvad skal vi tilføje? Og vi vil faktisk komme til det punkt, hvor du ved, sikkerhedskravene har ændret sig en del, så vi ser på en måde at gøre dette ekspanderbart på farten. Det er noget, vi ser på i fremtiden.
Men lige nu ser vi måske på at oprette skabeloner og være i stand til at hente skabeloner fra et websted; du kan downloade dem. Og det er sådan vi håndterer det - vi håndterer dem gennem skabeloner, og vi leder efter måder i fremtiden her for at gøre det let udvideligt og hurtigt. For når jeg plejede at foretage revision, ved du, ting ændrer sig. En revisor ville komme en måned, og den næste måned vil de se noget andet. Så er det en af udfordringerne med værktøjerne, at være i stand til at foretage disse ændringer og få det, du har brug for, og det er, slags, hvor vi ønsker at komme til.
Dez Blanchfield: Jeg gætter på, at en revisors udfordring ændres regelmæssigt i lyset af, at verden bevæger sig hurtigere. Og en gang i tiden ville kravet fra et revisionssynspunkt efter min erfaring blot være ren kommerciel overholdelse, og så blev det teknisk overholdelse, og nu er det operationel overholdelse. Og der er alle disse andre, ved du, hver dag dukker nogen op, og de måler dig ikke bare på noget som ISO 9006 og 9002, de ser på alle slags ting. Og jeg ser nu, at de 38.000 serier bliver en stor ting også i ISO. Jeg kan forestille mig, at det bare bliver mere og mere udfordrende. Jeg er ved at udlevere til Robin, fordi jeg har tagget båndbredden.
Mange tak, se det, og jeg vil bestemt bruge mere tid på at kende det, fordi jeg faktisk ikke var klar over, at det faktisk var helt i dybden. Så tak, Ignacio, jeg vil give Robin nu. En dejlig præsentation, tak. Robin, overfor dig.
Dr. Robin Bloor: Okay Iggy, jeg vil kalde dig Iggy, hvis det er okay. Hvad der forvirrer mig, og jeg tror i lyset af nogle af de ting, som Dez sagde i sin præsentation, er der meget forfærdeligt derude, som du skal sige, at folk virkelig ikke passer på dataene. Du ved, især når det kommer til det faktum, at du kun ser en del af isbjerget, og der er sandsynligvis meget, der foregår, at ingen rapporterer. Jeg er interesseret i dit perspektiv med hensyn til, hvor mange af de kunder, du er opmærksom på, eller potentielle kunder, som du er opmærksom på, har det beskyttelsesniveau, som du, slags tilbyder med ikke bare dette, men også din datatilgangsteknologi? Jeg mener, hvem derude er korrekt udstyret til at tackle truslen, er spørgsmålet?
Ignacio Rodriguez: Hvem er ordentligt udstyret? Jeg mener, mange kunder, som vi virkelig ikke har behandlet nogen form for revision, ved du. De har haft nogle, men den store ting er at forsøge at holde trit med det og forsøge at vedligeholde det og sørge for. Det store spørgsmål, vi har set, er - og selv det har jeg, når jeg gjorde overholdelsen, er - hvis du kørte dine scripts, ville du gøre det en gang hvert kvartal, når revisorerne ville komme ind, og du har fundet et problem. Gæt hvad, det er allerede for sent, revision er der, revisorerne er der, de vil have deres rapport, de markerer den. Og så får vi enten et mærke, eller vi fik at vide, hey, vi er nødt til at løse disse problemer, og det er her, dette ville komme ind. Det ville være mere en proaktiv type, hvor du kan finde din risiko og afbøde risikoen, og det er hvad vores kunder leder efter. En måde at være noget proaktiv i modsætning til at være reaktiv, når revisorer kommer ind og finder, at nogle af adgangerne ikke er, hvor de har brug for, andre mennesker har administrative privilegier, og de skulle ikke have dem, disse typer ting. Og det er her, vi har set en masse feedback fra, at folk kan lide værktøjet og bruger det til.
Dr. Robin Bloor: Okay, et andet spørgsmål, jeg har, er på en måde også et oplagt spørgsmål, men jeg er bare nysgerrig. Hvor mange mennesker kommer faktisk til dig i kølvandet på et hack? Hvor, du ved, du får virksomheden, ikke fordi de kiggede på deres miljø og regnede med, at de skulle sikres på en meget mere organiseret måde, men faktisk er du der, bare fordi de allerede har lidt noget af smerte.
Ignacio Rodriguez: I min tid her på IDERA har jeg ikke set en. For at være ærlig med dig, er det meste af det interaktion, jeg har haft med de kunder, som jeg har været involveret i, mere et blik frem og forsøger at starte revision og begyndte at se på privilegier osv. Som sagt har jeg selv ikke oplevet i min tid her, at vi har haft nogen der er kommet efter overtrædelse, som jeg kender.
Dr. Robin Bloor: Åh, det er interessant. Jeg ville have troet, at der havde været mindst et par stykker. Jeg ser faktisk på dette, men tilføjer også det alle de kompleksiteter, der faktisk gør dataene sikre på tværs af virksomheden på enhver måde og i enhver aktivitet, du udfører. Tilbyder du rådgivning direkte for at hjælpe folk? Jeg mener, det er klart, at du kan købe værktøjer, men efter min erfaring køber folk ofte sofistikerede værktøjer og bruger dem meget dårligt. Tilbyder du specifik konsulentbistand - hvad skal man gøre, hvem man skal træne og lignende ting?
Ignacio Rodriguez: Der er nogle tjenester, som du kunne, for så vidt angår supporttjenester, der gør det muligt for noget af det at ske. Men for så vidt angår konsulentbistand, leverer vi ikke nogen konsulenttjenester, men uddannelse, du ved, hvordan man bruger værktøjer og lignende ting, noget af det vil blive adresseret med supportniveauet. Men i og for sig har vi ikke en serviceafdeling, der går ud og gør det.
Dr. Robin Bloor: Okay. Med hensyn til den database, du dækker, nævner præsentationen her bare Microsoft SQL Server - gør du også Oracle?
Ignacio Rodriguez: Vi udvider først til Oracle-området med Compliance Manager. Vi vil starte et projekt med det, så vi vil se på at udvide dette til Oracle.
Dr. Robin Bloor: Og vil du sandsynligvis tage et andet sted?
Ignacio Rodriguez: Ja, det er noget, vi er nødt til at se på i køreplanerne og se, hvordan tingene er, men det er nogle af de ting, vi overvejer, er, hvilke andre databaseplatforme vi også har brug for at angribe.
Dr. Robin Bloor: Jeg var også interesseret i opdelingen, jeg har ikke fået et forudfattet billede af dette, men hvad angår indsættelser, hvor meget af dette der faktisk bliver sat i skyen, eller er det næsten alt på stedet ?
Ignacio Rodriguez: Alt på stedet. Vi ser også på at udvide Secure til at dække Azure, ja.
Dr. Robin Bloor: Det var Azure-spørgsmålet, du er ikke der endnu, men du skal der, det giver en masse mening.
Ignacio Rodriguez: Ja, vi skal der meget snart.
Dr. Robin Bloor: Ja, min forståelse fra Microsoft er, at der er en frygtelig masse handling med Microsoft SQL Server i Azure. Det bliver, hvis du vil, en vigtig del af, hvad det er, de tilbyder. Det andet spørgsmål, som jeg er interesseret i - det er ikke teknisk, det er mere som et hvordan-gør-du-engagere-spørgsmål - hvem er køberen for dette? Er du kontaktet af IT-afdelingen, eller bliver du kontaktet af CSO'er, eller er det en anden række mennesker? Når noget som dette overvejes, er det en del af at se på en hel række ting for at sikre miljøet? Hvad er situationen der?
Ignacio Rodriguez: Det er en blanding. Vi har CSO'er, mange gange vil salgsteamet nå ud og tale med DBA'er. Og så er DBA'erne igen blevet chartret med at få en slags revisionsprocesspolitikker på plads. Og derefter derfra vil de evaluere værktøjerne og rapportere kæden op og træffe en beslutning om, hvilken del de vil købe. Men det er en blandet pose, hvem der kontakter os.
Dr. Robin Bloor: Okay. Jeg tror, jeg vil give tilbage til Eric nu, fordi vi har gjort timen, men der kan være nogle spørgsmål fra publikum. Eric?
Eric Kavanagh: Ja, vi har brændt igennem meget godt indhold her. Her er et rigtig godt spørgsmål, jeg vil smide over til dig fra en af de deltagende. Han taler om blockchain, og hvad du snakker om, og han spørger, er der en mulig måde at migrere en skrivebeskyttet del af en SQL-database til noget, der ligner det blockchain tilbyder? Det er lidt hårdt.
Ignacio Rodriguez: Ja, jeg vil være ærlig med dig, jeg har ikke noget svar på det.
Eric Kavanagh: Jeg kaster det over til Robin. Jeg ved ikke, om du hørte det spørgsmål, Robin, men han spørger bare, er der en måde at migrere den skrivebeskyttede del af en SQL-database til noget, der ligner det blockchain tilbyder? Hvad mener du om det?
Dr. Robin Bloor: Det er som, hvis du vil migrere databasen, vil du også migrere databasetrafikken. Der er et helt sæt kompleksitet involveret i at gøre det. Men du ville ikke gøre det af anden grund end at gøre dataene ukrenkelige. Fordi en blockchain vil være langsommere at få adgang til, så ved du, hvis hastighed er din ting - og det næsten altid er tinget - så ville du ikke gøre det. Men hvis du ville give, slags, nøglet krypteret adgang til en del af det til nogle mennesker, der laver den slags ting, kunne du gøre det, men du skulle have en meget god grund. Det er meget mere sandsynligt, at du forlader det, hvor det er og sikrer det, hvor det er.
Dez Blanchfield: Ja, det er jeg enig i, hvis jeg hurtigt kan veje ind. Jeg tror, udfordringen med blockchain, endda blockchain, der er offentligt derude, den bruges på bitcoin - vi har svært ved at skalere det ud over, slags fire transaktioner i minuttet på en fuldt distribueret måde. Ikke så meget på grund af den computere-udfordring, selvom den er der, synes de fulde noder bare at være svært at holde trit med databasevolumener, der bevæger sig baglæns og fremad, og mængden af data, der kopieres, fordi det er optræden nu, ikke bare megs.
Men også, jeg tror, at den vigtigste udfordring er, at du er nødt til at ændre arkitektur for applikationen, fordi det i en database overvejende handler om at bringe alt til et centralt sted, og du har den klient-server-type model. Blockchain er det inverse; det handler om distribuerede kopier. Det ligner mere BitTorrent på mange måder, og det er, at der er masser af kopier derude af de samme data. Og du ved, ligesom Cassandra og databaser i hukommelsen, hvor du distribuerer det, og masser af servere kan give dig kopier af de samme data ud af et distribueret indeks. Jeg tror, at de to vigtigste dele, som du sagde, Robin, er: den ene, hvis du vil sikre den og sikre dig, at den ikke kan blive stjålet eller hacket, det er fantastisk, men det er ikke nødvendigvis en transaktionsplatform endnu, og vi Det har jeg oplevet med bitcoin-projektet. Men i teorien har andre løst det. Men også arkitektonisk ved mange applikationer derude bare ikke ved, hvordan man spørger og læser fra en blockchain.
Der er meget arbejde, der skal gøres der. Men jeg tror, at det centrale punkt med spørgsmålet der, bare hvis jeg kan, er grunden til at flytte det til en blockchain, jeg tror, at det spørgsmål, der stilles, er, kan du tage data ud af en database og placere dem i en eller anden form, mere sikker? Og svaret er, at du kan lade den være i databasen og bare kryptere den. Der er masser af teknologier nu. Krypter bare dataene i hvile eller i bevægelse. Der er ingen grund til, at du ikke kan have krypterede data i hukommelsen og i databasen på disken, hvilket er en langt enklere udfordring, fordi du ikke har en eneste arkitektonisk ændring. Uundgåeligt de fleste databaseplatforme, det er faktisk bare en funktion, der bliver aktiveret.
Eric Kavanagh: Ja, vi har et sidste spørgsmål, jeg skal smide over til dig, Iggy. Det er en ret god. Fra et SLA- og kapacitetsplanlægningsperspektiv, hvilken skat er der ved at bruge dit system? Med andre ord, enhver yderligere forsinkelse eller gennemstrømningsomkostning, hvis nogen i et produktionsdatabasesystem ønsker nogen at involvere IDERAs teknologi her?
Ignacio Rodriguez: Vi ser virkelig ikke meget af indflydelse. Igen, det er et middel uden produkt, og det hele afhænger af, som jeg nævnte før, snapshots. Sikker er baseret på snapshots. Det vil gå derude og faktisk oprette et job, der vil gå derude baseret på de intervaller, du har valgt. Enten vil du gøre det igen, ugentligt, dagligt, månedligt. Den går derude og udfører dette job og samler derefter dataene fra forekomsterne. På det tidspunkt kommer belastningen derefter tilbage til administrations- og indsamlingstjenesterne, når først du begynder at foretage sammenligninger og alt det, spiller belastningen på databasen ikke nogen rolle i det. Al denne belastning er nu på administrations- og indsamlingsserveren, hvad angår sammenligninger og al rapportering og alt det. Den eneste gang, du rammer databasen, er altid, når den udfører den faktiske snapshotting. Og vi har ikke haft nogen rapporter om, at det virkelig skader produktionsmiljøerne.
Eric Kavanagh: Ja, det er et rigtig godt punkt, du gør der. Grundlæggende kan du bare indstille, hvor mange snapshot du nogensinde tager, hvad tidsintervallet er, og afhængigt af hvad der kan ske, men det er meget intelligent arkitektur. Det er gode ting, mand. Nå, I er ude på frontlinjerne og prøver at beskytte os mod alle disse hackere, vi talte om i de første 25 minutter af showet. Og de er derude, folk, gør ingen fejl.
Nå, lyt, vi sender et link til denne webcast, arkiverne, på vores site insideanalysis.com. Du kan finde ting på SlideShare, du kan finde det på YouTube. Og folk, gode ting. Tak for din tid, Iggy, jeg elsker dit kaldenavn, forresten. Med det giver vi dig farvel, folkens. Tak så meget for din tid og opmærksomhed. Vi henter dig næste gang. Hej hej.
