Av Techopedia Staff, 14. september 2016
Takeaway: Vert Eric Kavanagh diskuterer revisjon og etterlevelse av databaser med analytikere Robin Bloor og Dez Blanchfield samt Bullett Manale fra IDERA i denne episoden av Hot Technologies.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hei og velkommen tilbake til Hot Technologies! Ja, 2016. Vi er i år tre av dette showet, det er veldig spennende greier. Vi har rocket og rullet i år. Dette er Eric Kavanagh, din vert. Temaet for i dag - dette er et flott tema, det har mange bruksområder over en rekke bransjer, helt ærlig - "Hvem, hva, hvor og hvordan: hvorfor du vil vite." Ja, vi kommer til å snakke om alt det morsomme. Det er et lysbilde om deg, slo meg opp på Twitter @eric_kavanagh. Jeg prøver å twitre alle omtaler og tweet på nytt alt som noen sender til meg. Ellers, så vær det.
Det er varmt, ja! Hele showet her er designet for å hjelpe organisasjoner og enkeltpersoner til å forstå spesiell teknologi. Vi designet hele programmet her, Hot Technologies, som en måte å definere en bestemt type programvare, eller en bestemt trend, eller en bestemt type teknologi. Årsaken er fordi ærlig talt, i programvareverdenen, vil du ofte få disse markedsføringsbetingelsene som blir båndet om og noen ganger kan de ærlig talt skjule konseptene de var ment å beskrive.
I dette showet prøver vi virkelig å hjelpe deg med å forstå hva en bestemt type teknologi er, hvordan den fungerer, når du kan bruke den, når du kanskje ikke skal bruke den, og gi deg så mange detaljer som vi muligens kan. Vi har tre presentatører i dag: vår helt egen Robin Bloor, sjefanalytiker her i Bloor Group; vår dataforsker som ringer inn fra Sydney, Australia på den andre siden av planeten, Dez Blanchfield, og en av favorittgjestene våre Bullett Manale, direktør for salgsteknikk i IDERA.
Jeg vil bare si et par ting her, og forstå hvem som gjør hva med hvilket stykke data, vel, det er liksom styring, ikke sant? Hvis du tenker på alle forskriftene rundt bransjer, som helsevesenet og finansielle tjenester, på disse domenene, er det sånt utrolig viktig. Du må vite hvem som berørte informasjonen, hvem som endret noe, hvem som fikk tilgang til den, hvem som lastet opp den, for eksempel. Hva er avstamningen, hva er forsynet med disse dataene? Du kan være trygg på at alle disse problemene kommer til å forbli fremtredende i årene fremover av alle slags grunner. Ikke bare for overholdelse, selv om HIPAA, og Sarbanes-Oxley, og Dodd-Frank, og alle disse forskriftene er veldig viktige, men også bare slik at du forstår i virksomheten din hvem som gjør hva, hvor, når, hvorfor og hvordan. Dette er gode ting, vi kommer til å være oppmerksom.
Ta det bort, Robin Bloor.
Robin Bloor: Ok, takk for introduksjonen, Eric. Dette området styresett er, mener jeg, styring i IT var ikke et ord du hørte før litt etter år 2000, tror jeg. Det skjedde først og fremst fordi, jeg tror uansett, det først og fremst skyldes at det er lov om etterlevelse som foregikk. Spesielt HIPAA og Sarbanes-Oxley. Det er faktisk mye av det. Derfor innså organisasjoner at de måtte ha et sett med regler og et sett med prosedyrer fordi det var nødvendig under loven å gjøre det. Lenge før det, spesielt i banksektoren, var det forskjellige initiativer du måtte følge, avhengig av hva slags bank du var, og spesielt de internasjonale bankfolkene. Hele Basel-kompatible startet på vei, langt før det spesielle settet med initiativer etter år 2000. Det hele kommer virkelig ned på styringen. Jeg trodde jeg skulle snakke om temaet styring som en introduksjon til fokus for å følge med på hvem som får dataene.
Datastyring, jeg pleide å se meg rundt, jeg tenkte for fem eller seks år siden, se meg om etter definisjoner og det var ikke bra definert i det hele tatt. Det er blitt tydeligere og tydeligere hva det faktisk betyr. Realiteten i situasjonen var at innenfor visse grenser var alle data faktisk tidligere styrt, men det var ingen formelle regler for det. Det var spesielle regler som ble laget spesielt i banknæringen for å gjøre slike ting, men igjen handlet det mer om etterlevelse. På en eller annen måte å bevise at du faktisk var en - det er slags forbundet med risiko, så det å bevise at du var en levedyktig bank var avtalen.
Hvis du ser på styringsutfordringen nå, begynner det med et faktum av big data-bevegelsen. Vi har stadig flere datakilder. Datavolum er selvfølgelig et problem med det. Spesielt begynte vi å gjøre mye, mye, mer med ustrukturerte data. Det begynte å bli noe som er en del av hele analysespillet. Og på grunn av analyser er dataprioritet og avstamninger viktig. Virkelig fra synspunktet om å bruke dataanalyse på noen måte som er relatert til noen form for etterlevelse, må du virkelig ha kunnskap om hvor dataene kom fra og hvordan det måtte bli hva det er.
Datakryptering begynte å bli et problem, bli et større problem så snart vi dro til Hadoop fordi ideen om en datasjø der vi lagrer mye data, plutselig betyr at du har et enormt sårbarhetsområde for mennesker som kan få på det. Kryptering av data ble mye mer fremtredende. Autentisering var alltid et problem. I det eldre miljøet, strengt mainframe-miljøet, hadde de en slik fantastisk sikkerhetsbeskyttelse; autentisering var egentlig aldri så mye av et problem. Senere ble det et større tema, og det er mye mer et tema nå fordi vi har så enormt distribuerte miljøer. Overvåking av datatilgang, det ble et problem. Jeg ser ut til å huske forskjellige verktøy som ble til for omtrent ti år siden. Jeg tror de fleste av disse var drevet av compliance-initiativer. Derfor har vi også fått alle overholdelsesreglene, samsvarsrapportering.
Det som har kommet i tankene er at selv tilbake på 1990-tallet, da du foretok kliniske studier i legemiddelindustrien, måtte du ikke bare være i stand til å bevise hvor dataene kom fra - tydeligvis er det veldig viktig, hvis du prøver ut et medikament i forskjellige sammenhenger, for å vite hvem som blir prøvd på og hva de kontekstuelle dataene rundt det - du måtte kunne gi en revisjon av programvaren som faktisk skapte dataene. Det er det alvorligste samsvaret jeg noensinne har sett hvor som helst, når det gjelder å bevise at du faktisk ikke roter ting bevisst eller tilfeldig. I nyere tid har spesielt styring av livssykluser for data blitt et problem. Alle disse er på en måte utfordringer fordi mange av disse ikke har blitt gjort bra. Under mange omstendigheter er det nødvendig å gjøre dem.
Dette er hva jeg kaller datapyramiden. Jeg har snakket gjennom dette før. Jeg synes det er en veldig interessant måte å se på ting på. Du kan tenke på data som å ha lag. Raw data, hvis du vil, er egentlig bare signaler eller målinger, opptak, hendelser, stort sett enkeltoppføringer. Muligens lager transaksjoner, beregninger og aggregeringer selvfølgelig nye data. De kan tenkes på på datanivå. Når du faktisk kobler data sammen, blir det informasjon. Det blir mer nyttig, men selvfølgelig blir det mer sårbart for folk som hacker det eller misbruker det. Jeg definerer det som å være skapt, virkelig gjennom strukturering av data, å kunne visualisere dataene med ordlister, skjemaer, ontologier på informasjonen. Disse to nedre lagene er det vi behandler på en eller annen måte. Over det kaller jeg kunnskapslaget som består av regler, retningslinjer, retningslinjer, prosedyre. Noen av dem kan faktisk skapes av innsikt oppdaget i analyser. Mange av dem er faktisk retningslinjer du må overholde. Dette er laget, hvis du vil, av styring. Det er her, på en eller annen måte, hvis dette laget ikke er riktig befolket, blir ikke de to lagene under administrert. Det siste poenget med dette er forståelse av noe som bare ligger i mennesker. Datamaskiner har ikke klart å gjøre det ennå, heldigvis. Ellers ville jeg være ute av jobb.
Styringsimperiet - Jeg har satt sammen dette, jeg tror det må ha vært rundt ni måneder siden, muligens mye tidligere enn det. I utgangspunktet forbedret jeg det, men så snart vi begynte å bli bekymret for styresett, så var det, når det gjelder bedriftens datahub, det ikke bare var datareservoar, ressurser til innsjøer, men også generelle servere av forskjellige slag, spesialiserte dataservere. Alt dette måtte styres. Når du faktisk så på den forskjellige dimensjonen også - datasikkerhet, rensing av data, oppdagelse av metadata og metadatastyring, oppretting av en virksomhetsordliste, datakartlegging, datalinje, styring av livssyklus for data - da, systemadministrasjon, som du kanskje ikke assosierer med styring, men en viss - nå som vi skal til en raskere og raskere verden med flere og flere dataflyt, er det faktisk en nødvendighet å kunne gjøre noe med en bestemt ytelse og begynner å bli en operasjonsregel fremfor noe annet.
Oppsummert når det gjelder vekst av samsvar, så jeg dette skje over mange, mange år, men den generelle databeskyttelsen kom faktisk på 1990-tallet i Europa. Det ble bare mer og mer sofistikert siden den gang. Deretter begynte alle disse tingene å bli introdusert eller blitt mer sofistikerte. GRC, det er styringsrisiko og etterlevelse, har pågått siden bankene gjorde Basel. ISO har laget standarder for forskjellige typer operasjoner. Jeg vet hele tiden at jeg har vært innen IT - det har vært lenge - USAs regjering har vært spesielt aktive i å lage forskjellige lovverk: SOX, det er Gramm-Leach-Bliley, HIPAA, FISMA, FERPA. Du har også den fantastiske NIST-organisasjonen som skaper mange standarder, spesielt sikkerhetsstandarder, veldig nyttige. Lovene om databeskyttelse i Europa har lokale avvik. Hva du kan gjøre med personopplysninger i Tyskland, for eksempel, er annerledes enn hva du kan gjøre i Slovakiske republikken, eller i Slovenien, eller hvor som helst. De introduserte nylig - og jeg trodde jeg skulle nevne dette fordi jeg synes det er morsomt - Europa introduserer ideen om retten til å bli glemt. Det vil si at det burde være en lov om begrensninger på data som har vært offentlig, og som faktisk er personopplysninger. Jeg synes det er morsomt. Fra et IT-synspunkt vil det være veldig, veldig vanskelig hvis det begynner å bli effektiv lovgivning. Oppsummert vil jeg si følgende: Fordi IT-data og styring utvikler seg raskt, må styring også utvikle seg raskt og det gjelder alle styringsområdene.
Når det er sagt, skal jeg sende ballen til Dez.
Eric Kavanagh: Ja, så Dez Blanchfield, ta den bort. Robin, jeg er med deg, jeg er i ferd med å se hvordan denne retten til å bli glemt spiller ut. Jeg tror at det ikke kommer til å være bare utfordrende, men i utgangspunktet umulig. Det er bare et brudd på å vente på å bli utøvd av offentlige etater. Desember, ta den bort.
Dez Blanchfield: Det er det, og det er et tema for en annen diskusjon. Vi har en veldig lignende utfordring her i Asia-Stillehavet, og spesielt i Australia hvor transportører og Internett-leverandører er pålagt å logge alt relatert til internett og kunne registrere og oppfylle det hvis noen av interessene gjør noe galt. Det er en lov, og du må overholde den. Utfordringen, akkurat som noen i Google i USA kan få beskjed om å slette søkehistorikken min eller hva som helst, kan det være å overholde europeisk lov, særlig tysk personvernlovgivning. Hvis et byrå ønsker å se på deg i Australia, må en transportør kunne gi detaljer om samtaler og søkehistorikk som er gjort, noe som er utfordrende, men det er den verden vi lever i. Det er mange grunner til det. La meg bare hoppe inn i min.
Jeg gjorde bevisst tittelsiden min vanskelig å lese. Du må virkelig se hardt på den teksten. Overholdelse, i samsvar med et sett med regler, spesifikasjoner, kontroller, retningslinjer, standarder eller lover, med en tullete, rotete bakgrunn. Det er fordi du virkelig må se på det vanskelig å få detaljene og trekke ut informasjon fra det den er lagt, som er en serie tabeller og rader og kolonner, enten en database, et skjema eller en mock-up i Visio. Det er slik samsvar føles som dag til dag. Det er ganske vanskelig å dykke ned i detaljene og trekke ut relevante informasjonsbiter du trenger for å kunne bekrefte at du er kompatibel. Rapporter om det, overvåke det og test det.
Jeg trodde faktisk en veldig god måte å visualisere dette når vi stiller oss spørsmålet: "Er du kompatibel?" "Er du sikker?" "Vel, bevis det!" Det er en veldig morsom ting som kanskje er litt mer anglo-keltisk, men jeg er sikker på at den har kommet seg rundt i verden til USA, så det er: "Where's Wally?" Wally er en liten karakter som kommer inn i disse tegneserietegningene i form av bøker. Vanligvis veldig store bilder av A3 eller større. Så, tabeller i størrelse. Han er en liten karakter som har på seg en beanie og en rødhvit stripet skjorte. Ideen med spillet er at du ser på dette bildet, og du ser deg rundt i sirkler for å prøve å finne Wally. Han er på det bildet der et sted. Når du tenker på hvordan du oppdager og beskriver og rapporterer om samsvar, er det på mange måter som å spille "Where's Wally." Hvis du ser på det bildet, er det nesten umulig å finne karakteren. Barn bruker timer på det, og jeg hadde det veldig moro med å gjøre det selv i går. Når vi ser på det, finner vi en hel haug mennesker i disse tegneseriene, som bevisst er plassert der med lignende biter av Wally-antrekket fra en stripet beanie og en trøye eller ulltopp. Men de viser seg å være falske positive.
Dette er en lignende utfordring med overholdelse. Når vi ser på ting, noen ganger noe vi tror at dette er tilfelle, er det ikke i det hele tatt. Noen kan ha tilgang til en database og de skal ha tilgang til en database, men måten de bruker den på er litt forskjellig fra hva vi forventer. Vi bestemmer oss kanskje for at det er noe vi trenger å se på. Når vi ser på det, finner vi, faktisk, det er en veldig gyldig bruker. De gjør bare noe sære. Kanskje det er en PC-forsker eller hvem vet det. I andre tilfeller kan det være motsatt. Virkeligheten, når jeg går fremover, er det Wally. Hvis du så veldig hardt ut i denne høye oppløsningen, er det en karakter som faktisk har på seg riktig antrekk. Alle de andre er bare lookalikes og feel-alikes. Etterlevelse føles veldig sånn. De fleste jeg kjenner, de jobber med kontroller og etterlevelse og policyer for virksomheter. På en rekke områder, enten det er teknologi, enten det er økonomi, eller drift, og risiko. Ofte er det veldig vanskelig å se Wally på bildet, du vil se trærne eller treverket.
Spørsmålet vi stiller oss, når vi tenker på ting som compliance, er "Big deal, hva kan muligens gå galt hvis vi ikke helt oppfyller overholdelsen?" I forbindelse med dagens diskusjon, spesielt rundt database og kontroll av tilgang til data, skal jeg gi deg noen veldig virkelige eksempler på våkne oppgaver om hva som kan gå galt i veldig kort kortfattet form. Hvis vi tenker på datainnbrudd, og vi er kjent med datainnbrudd, hører vi dem i media, og vi stopper og ler, fordi folk tror det er markeder. Det er personlige ting. Det er Ashley Madison og mennesker som er ute etter å få datoer utenfor sine forhold og ekteskap. Det er kastkontoer. Det er alle disse rare tingene, eller en tilfeldig europeisk eller russisk ISP eller et vertsfirma blir hacket. Når det gjelder ting som MySpace og disse topp ti, når du ser på disse tallene, hva jeg vil at du skal innse er dette: 1, 1 milliarder menneskers detaljer i disse ti beste bruddene. Og ja, det er overlapp, det er sannsynligvis folk som har en MySpace-konto, og en Dropbox-konto og en Tumblr-konto, men la oss bare runde den opp til en milliard mennesker.
Disse ti største bruddene i løpet av det siste tiåret eller så - ikke engang et tiår, i de fleste tilfeller, oppsummerer omtrent en syvendedel av verdens befolkning av mennesker, men mer realistisk sett er rundt 50 prosent av antall mennesker koblet til internett, over en milliard individer. Disse oppstår fordi samsvar ikke er oppfylt i noen tilfeller. I de fleste tilfeller var det kontroller med tilgang til database, kontroll av tilgang til bestemte datasett og systemer og nettverk. Dette er en skummel reality sjekk. Hvis det ikke skremmer deg, når du ser på de ti beste og du kan se at dette er en - eller kan se at dette er en milliard individer, ekte mennesker akkurat som oss, på denne samtalen akkurat nå. Hvis du har en LinkedIn-konto, hvis du hadde en Dropbox-konto, eller en Tumblr-konto, eller hvis du kjøpte fra Adobe-produkter eller til og med registrerte, last ned gratis Adobe Viewer. Det er helt sannsynlig, ikke mulig, det er helt sannsynlig at dine opplysninger, fornavn, etternavn, e-postadresse, potensielt til og med arbeidsbedriftsadresse, eller hjemmeadresse eller kredittkort, faktisk er der ute på grunn av brudd som fant sted på grunn av kontrollene, som ikke nødvendigvis ble klart bra i form av datahåndtering, datastyring.
La oss se på det når vi ser på det i detalj. Det er en skjerm av dem, det er omtrent 50-noe der. Det er en annen 15. Det er omtrent en annen 25. Dette er datainnbrudd som er oppført på et nettsted som heter haveibeenpwned.com. Dette er hva som muligens kan gå galt hvis ikke noe enkelt som å kontrollere hvem som har hatt tilgang til data i databaser i forskjellige felt og rader og kolonner og forskjellige applikasjoner i virksomheten, ikke administreres ordentlig. Disse organisasjonene er nå datadrevet. De fleste data lever i en database i en eller annen form. Når du tenker på det, den listen over brudd som vi nettopp har sett på, og forhåpentligvis har den gitt deg litt kald dusj på en måte, på den måten at du tenkte “Hmm, det er veldig ekte”, og det potensielt har påvirket deg. I 2012, for eksempel bruddet på LinkedIn, har de fleste fagpersoner en LinkedIn-konto i disse dager, og det er sannsynlig at detaljene dine går tapt. De har vært ute på internett siden 2012. Vi har bare blitt fortalt om det i 2016. Hva skjedde med informasjonen din i de fire årene? Vel, det er interessant, og vi kan snakke om det hver for seg.
Database og systemadministrasjon - Jeg snakker ofte om hva jeg anser som de fem beste utfordringene i å håndtere disse tingene. Helt øverst, og jeg rangerer disse i rekkefølgen av meg selv, men også rekkefølgen av innvirkning, nummer én er sikkerhet og etterlevelse. Kontrollene og mekanismene, og policyene for å kontrollere hvem som har tilgang til hvilket system, av hvilken grunn og formål. Rapportering om det og overvåke det, se på systemene, se i databasene og se hvem som faktisk kan få tilgang til poster, enkeltfelt og poster.
Tenk på dette i en veldig enkel form. La oss snakke om bank- og formuesforvaltning som et eksempel. Når du registrerer deg for en bankkonto, la oss si en vanlig kontantkonto for et EFTPOS-kort, eller en kontantkonto eller en sjekkekonto. Du fyller ut et skjema, og det er mye privat informasjon i det papiret du fyller ut, eller du gjør det online, og som går inn i et datasystem. Hvis noen i markedsføring ønsker å kontakte deg og sende deg en brosjyre, skal de få lov til å se fornavnet og etternavnet ditt og din personlige adresse, for eksempel og potensielt telefonnummeret ditt hvis de vil ringe deg og selger deg noe. De burde sannsynligvis ikke se det totale beløpet du har i banken av mange grunner. Hvis noen ser på deg fra et risikosynspunkt, eller prøver å hjelpe deg med å gjøre noe som å få bedre renter på kontoen din, vil den bestemte personen sannsynligvis se hvor mye penger du har i banken, slik at de kan tilby deg passende nivåer av avkastning på pengene dine. Disse to individene har veldig forskjellige roller og veldig forskjellige grunner for disse rollene, og formål for disse rollene. Som et resultat, må du se annen informasjon i posten, men ikke all posten.
Disse kontrollene rundt de forskjellige rapportene om vanlige skjermer eller skjemaer som de har i applikasjonene som brukes til å administrere kontoen din. Utviklingen for dem, vedlikeholdet av dem, administrasjonen av dem, rapporteringen rundt dem, og styringen og overholdelsen som er pakket rundt de som bobleplast, er alle en veldig, veldig stor utfordring. Det er bare den største utfordringen når det gjelder håndtering av data og systemer. Når vi går dypere ned i bunken i ytelse og overvåking, og forekomstregistrering og respons, styring og administrasjon av systemet, og samsvar rundt dem, blir utformingen og utviklingen av systemene fra overholdelsen, mye vanskeligere.
Håndtere hele problemet med å redusere risiko og forbedre sikkerheten. De fem beste utfordringene mine på dette stedet - og jeg liker bildene som følger med en tollskranke når du kommer til et land - de presenterer passet ditt, og de sjekker deg ut, og de ser på datasystemet deres for å se om du bør bestått eller ikke. Hvis du ikke skulle gjøre det, satte de deg på neste fly hjem. Ellers lar de deg komme inn igjen og spør deg spørsmål som "Kommer du på ferie? Er du her turist? Er du her for å jobbe? Hva slags arbeid skal du se? Hvor skal du bo "Hvor lenge kommer du etter? Har du nok penger til å dekke utgiftene og kostnadene? Eller kommer du til å bli en risiko for landet du befinner deg i, og at de kanskje må passe på deg og gi deg mat?"
Det er noen problemer rundt dette rommet med data, administrering av databeskyttelse. For eksempel i databasearealet, må vi tenke på å dempe databaseomganger. Hvis dataene er i databasen, i et normalt miljø og det er kontroller og mekanismer rundt det i systemet. Hva skjer hvis en dump av dataene blir gjort i mer SQL og sikkerhetskopiert til tape? Databasene dumpes i rå form og sikkerhetskopieres noen ganger. Noen ganger er det gjort av tekniske grunner, av utviklingshensyn. La oss bare si at en DB-dump ble tatt og den er sikkerhetskopiert til tape. Hva skjer hvis jeg tilfeldigvis får tak i det båndet og gjenopprette det? Og jeg har fått en rå kopi av databasen i SQL. Det er en MP-fil, det er tekst, jeg kan lese den. Alle passordene som er lagret i det dumpet har ingen kontroll over meg fordi jeg nå får tilgang til det faktiske innholdet i databasen uten at databasemotoren beskytter den. Så jeg kan teknisk omgå sikkerheten til databaseplattformen som er bygget i motoren med overholdelse, og risikostyring for å stoppe meg med å se på dataene. Fordi potensielt utvikleren, systemadministratoren, har jeg fått hendene på en full dump av databasen som skal brukes til sikkerhetskopiering.
Misbruk av dataene - potensielt få noen til å logge inn som den forhøyede kontoen og la meg sitte ved skjermen, lete etter informasjon eller lignende ting. Eiendomsrevisjon, tilgang og bruk av dataene, og visning av dataene eller endringer i dataene. Deretter rapporteringen rundt den kontrollen og samsvaret som kreves. Overvåke trafikken og tilgangen og så videre, blokkerer trusler som kommer fra eksterne steder og servere. For eksempel hvis dataene blir presentert via et skjema på en webside på internett, har deres SQL-injeksjoner blitt beskyttet gjennom brannmurer og konseptkontroller? Det er en lang detaljert historie som ligger bak dette. Du kan her se at bare noen av disse helt grunnleggende tingene som vi tenker på for å dempe og håndtere risiko rundt data i databaser. Det er faktisk relativt enkelt å komme seg rundt noen av disse hvis du er på forskjellige nivåer av stabler av teknologiene. Utfordringen blir vanskeligere og vanskeligere etter hvert som du får mer og mer data, og flere databaser. Mer og mer utfordrende med folk som må administrere systemene, og overvåke bruken av dem, spore de relevante detaljene som spesifikt angår ting som Robin snakket om, rundt ting som personlig etterlevelse. Enkeltpersoner har kontroller og mekanismer rundt seg som følger - hvis du gjør noe galt, blir du potensielt sparken. Hvis jeg logger inn som kontoen min og lar deg se den, bør det være en brennbar krenkelse. Nå har jeg gitt deg tilgang til data som du ikke burde sett normalt.
Det er personlig etterlevelse, det er bedrifters etterlevelse, selskaper har retningslinjer og regler, og kontroller som de har satt på seg, bare slik at selskapet løper godt og gir avkastning og en god avkastning til investorer og aksjonærer. Så er det ofte bydeler eller statlig eller nasjonalt, føderalt som du sa amerikanske kontroller og lover. Så er det globale. Noen av de større hendelsene i verden, der slike som Sarbanes-Oxley, to personer som blir bedt om å komme med måter å beskytte data og systemer på. Det er Basel i Europa, og det er en rekke kontroller i Australia, spesielt rundt børs og legitimasjonsplattformer, og deretter personvern på individuell eller bedriftsnivå. Når hver av disse er stablet som du så på et av stedene som Robin hadde, blir de nesten et nesten umulig fjell å klatre på. Kostnadene blir høye, og vi er på et punkt der den originale tradisjonelle tilnærmingen du kjenner, som mennesker som måler kontroll, ikke lenger er en passende tilnærming fordi omfanget er for stort.
Vi har et scenario der samsvar er det jeg kaller nå et alltid pågående spørsmål. Og det er at vi pleide å ha et tidspunkt, enten månedlig eller kvartalsvis eller årlig, der vi ville gjennomgå vår nasjonalstat og bidra til etterlevelse og kontroll. Å sørge for at visse mennesker hadde viss tilgang og ikke hadde viss tilgang, avhengig av hva tillatelsene deres var. Nå er det snakk om hastigheten på ting som ting beveger seg med, tempoet som tingene endres i, omfanget som vi jobber med. Etterlevelse er et alltid aktuelt spørsmål, og den globale finanskrisen var bare ett eksempel der relevante kontroller, og tiltak i sikkerhet og etterlevelse potensielt kunne ha unngått et scenario der vi hadde et løpende godstog med viss oppførsel. Bare å skape en situasjon med hele verden effektivt og vite at den ville gå brakk og gå konkurs. For å gjøre det trenger vi de riktige verktøyene. Å kaste mennesker på toget og kaste kropper er ikke lenger en gyldig tilnærming fordi skalaen er for stor og ting beveger seg for fort. Diskusjonen i dag, tror jeg vi kommer til å ha, handler om hvilke typer verktøy som kan brukes på dette. Spesielt verktøyene som IDERA kan tilby oss som bør gjøre det. Og med det i tankene, overlater jeg det til Bullett å gå gjennom materialet hans og vise oss deres tilnærming og verktøyene de har for å løse dette problemet som vi har lagt frem nå for deg.
Med det, Bullett, vil jeg gi deg.
Bullett Manale: Høres bra ut, takk. Jeg vil snakke om noen lysbilder, og jeg vil også vise deg et produkt som vi bruker til SQL Server-databaser spesielt for å hjelpe deg med samsvarssituasjoner. Virkelig, utfordringen i mange tilfeller - jeg kommer til å hoppe gjennom noen få av disse - dette er bare vår portefølje av produkter, jeg kommer til å gå gjennom det ganske raskt. Når det gjelder hvor dette produktet kommer til å bli adressert og hvordan det forholder seg til overholdelse, trekker jeg alltid opp dette som på det første lysbildet fordi det er et slags generisk, "Hei, hva er ansvaret for en DBA?" En av tingene kontrollerer og overvåker brukertilgang og kan også generere rapporter. Det kommer til å knytte seg til når du snakker med revisoren din, hvor vanskelig prosessen kan være kommer til å variere avhengig av om du skal gjøre det på egen hånd eller om du skal bruke en tredjepart verktøy for å hjelpe.
Generelt sett når jeg snakker med databaseadministratorer, mange ganger har de aldri vært involvert i en revisjon. Du må slags utdanne dem til virkelig hva det er som du virkelig trenger å gjøre. Relatert til hvilken type samsvar som må oppfylles og å kunne bevise at du faktisk følger reglene, da de gjelder for dette nivået av samsvar. Mange mennesker får det ikke til å begynne med. De tenker: "Å, jeg kan bare kjøpe et verktøy som vil gjøre meg kompatibel." Realiteten er at det ikke er tilfelle. Jeg skulle ønske jeg kunne si at produktet vårt på en magisk måte, ved å trykke på den enkle knappen, ga deg muligheten til å sørge for at du overholder kravene. Realiteten er at du må ha miljøet ditt satt opp med tanke på kontrollene, når det gjelder hvordan folk får tilgang til dataene, at alt må utarbeides med applikasjonen du har. Hvor følsomme dataene lagres, hvilken type lovkrav er det. Da må du også jobbe med en intern overholdelsesansvarlig for å være sikker på at du følger alle reglene.
Dette høres veldig komplisert ut. Hvis du ser på alle myndighetskrav, vil du tro at det ville være tilfelle, men virkeligheten er at det er en fellesnevner her. I vårt tilfelle med verktøyet som jeg skal vise deg i dag, Compliance Manager-produktet, ville prosessen i vår situasjon være at vi først og fremst må sørge for at vi samler inn revisjonsspor-data, relatert hvor dataene er i databasen som er følsom. Du kan samle alt, ikke sant? Jeg kunne gå ut og si at jeg vil samle alle transaksjoner som skjer i denne databasen. Realiteten er at du sannsynligvis bare har en liten brøkdel eller en liten prosentandel av transaksjoner som faktisk er relatert til sensitive data. Hvis det er PCI-overholdelse, vil det dreie seg om kredittkortinformasjonen, eierne av kredittkortene og deres personlige opplysninger. Det kan være mange andre transaksjoner når det gjelder søknaden din, som egentlig ikke har noen betydning for PCI-kravet.
Fra det ståstedet, er det første jeg snakker med DBA om at jeg sier: “Utfordringen som nummer én prøver ikke å få et verktøy for å gjøre disse tingene for deg. Det er bare å vite hvor er de sensitive dataene og hvordan låser vi disse dataene? ”Hvis du har det, hvis du kan svare på det spørsmålet, er du halvveis hjemme når det gjelder å kunne vise at du er i samsvar, forutsatt at du følger de riktige kontrollene. La oss si et øyeblikk at du følger de riktige kontrollene og at du sa til revisorene at det er tilfelle. Den neste delen av prosessen er åpenbart å kunne tilby en revisjonsspor som viser og validerer at kontrollene faktisk fungerer. Deretter følger du opp med å sørge for at du lagrer dataene. Vanligvis med ting som PCI og HIPAA-overholdelse, og slike ting, snakker du syv års oppbevaring. Du snakker om mange transaksjoner og mye data.
Hvis du holder på med å samle hver transaksjon, selv om bare fem prosent av transaksjonene er relatert til sensitive data, snakker du om en ganske stor kostnad forbundet med å måtte lagre disse dataene i syv år. Det er en av de største utfordringene, tror jeg, er å få folks hode rundt det å si, det er en virkelig unødvendig kostnad, åpenbart. Det er også mye enklere hvis vi bare kan fokusere granulært på de sensitive områdene i databasen. I tillegg til at du også ønsker kontroller rundt noe av sensitiv informasjon også. Ikke bare for å vise når det gjelder en revisjonsspor, men også å kunne knytte ting tilbake til handlinger som skjer og kunne bli varslet i sanntid, slik at du kan bli gjort oppmerksom på det.
Eksemplet bruker jeg alltid, og det er muligens ikke nødvendigvis relatert til noen form for myndighetskrav, men bare å kunne spore, for eksempel var det noen som droppet tabellen knyttet til lønningslisten. Hvis det skjer, er måten du finner ut om det, hvis du ikke sporer det, ingen som får betalt. Det er for sent. Du vil vite når tabellen faller, rett når den blir droppet, for å unngå dårlige ting som skjer som følge av at noen misfornøyde ansatte går og sletter tabellen som er bundet direkte til lønningslisten.
Når det er sagt, er trikset å finne fellesnevneren eller bruke den fellesnevneren for å kartlegge hva nivået for samsvar er. Det er slags hva vi prøver å gjøre med dette verktøyet. Vi tar utgangspunktet, vi skal ikke vise deg en rapport som er spesifikk for PCI, spesifikk for aksjer; Fellesnevneren er at du har et program som bruker SQL Server til å lagre sensitive data i databasen. Når du først er kommet over at du sier: "Ja, det er virkelig det viktigste vi trenger å fokusere på - hvor er de sensitive dataene, og hvordan får du tilgang til dem?" Når du har det, er det massevis av rapporter som vi tilbyr som kan gi bevis på at du er innenfor overholdelse.
Når jeg går tilbake til spørsmålene som blir stilt av en revisor, vil det første spørsmålet være: Hvem har tilgang til dataene, og hvordan får de tilgangen? Kan du bevise at de riktige personene får tilgang til dataene og at feil mennesker ikke er det? Kan du også bevise at selve revisjonssporet er noe jeg kan stole på som en uforanderlig informasjonskilde? Hvis jeg gir deg en revisjonsspor som er produsert, gjør det meg ikke så bra som revisor å lappe revisjonen din hvis informasjonen er produsert. Vi trenger bevis på det, typisk fra et revisjonsperspektiv.
Å gå gjennom disse spørsmålene, litt mer detaljerte. Utfordringen med det første spørsmålet er, du må vite, som sagt, hvor sensitive data er for å kunne rapportere om hvem som får tilgang til dem. Det er vanligvis en type funn, og virkelig har du tusenvis av forskjellige applikasjoner som finnes der ute, du har mange forskjellige forskriftskrav. I de fleste tilfeller vil du samarbeide med din compliance compliance officer hvis du har en, eller i det minste noen som vil ha litt ekstra innsikt i forhold til hvor mine sensitive data ligger i applikasjonen. Vi har et verktøy som vi har, det er et gratis verktøy, det kalles et SQL Column Search. Vi forteller våre potensielle kunder og brukere som er interessert i det spørsmålet, de kan laste det ned. Hva det kommer til å gjøre er at det i utgangspunktet vil se etter informasjonen i databasen som sannsynligvis vil være sensitiv.
Og når du først har gjort det, må du også forstå hvordan folk får tilgang til disse dataene. Og det kommer til å være nok en gang, hvilke kontoer som Active Directory-grupper, hvilke databasebrukere er involvert i, er en rolle medlemskap knyttet til dette. Og selvfølgelig huske på at alle disse tingene som vi snakker om, må godkjennes av revisoren, så hvis du sier: "Dette er hvordan vi låser opp dataene, " kan revisorene komme tilbake og si: "Vel, du gjør det galt." Men la oss si at de sier: "Ja, det ser bra ut. Du låser dataene tilstrekkelig. "
Hvis du går videre til neste spørsmål, som kommer til å bli, kan du bevise at de rette personene får tilgang til disse dataene? Med andre ord kan du fortelle dem at kontrollene dine er, dette er kontrollene du følger, men dessverre er ikke revisorene tillit til enkeltpersoner. De vil ha bevis på det, og de vil kunne se det innenfor revisjonssporet. Og dette går igjen i hele den nevnte tingen. Enten det er PCI, SOX, HIPAA, GLBA, Basel II, hva som er, realiteten er, er at de samme typene spørsmål typisk vil bli stilt. Objektet med sensitiv informasjon, hvem har tilgang til det objektet i løpet av den siste måneden? Dette skulle kartlegge kontrollene mine, og jeg skal kunne passere tilsynet mitt etter hvert ved å vise de typer rapporter.
Og det vi har gjort er at vi har samlet rundt 25 forskjellige rapporter som følger på de samme områdene som den fellesnevneren. Så vi har ikke en rapport for PCI eller for HIPAA eller for SOX, vi har rapporter om at de nok en gang går opp mot den fellesnevneren. Så det spiller ingen rolle hvilket regulatorisk krav du prøver å oppfylle, i de fleste tilfeller vil du kunne svare på hvilket spørsmål som revisor har stilt deg. Og de skal fortelle deg hvem, hva, når og hvor av hver transaksjon. Du vet, brukeren, tidspunktet transaksjonen skjedde, selve SQL-setningen, applikasjonen som den kom fra, alt det gode, og deretter også kunne automatisere leveringen av denne informasjonen til rapporter.
Og så, igjen, når du har kommet deg forbi det, og du har gitt det til revisoren, så beviser det neste spørsmål. Og når jeg sier bevis det, mener jeg bevise at selve revisjonssporet er noe vi kan stole på. Og måten vi gjør det på i verktøyet vårt, er at vi har hasjverdier og CRC-verdier som knytter seg direkte tilbake til hendelsene i revisjonssporet. Og så er tanken at hvis noen går ut og sletter en post, eller hvis noen går ut og fjerner eller legger til noe i revisjonssporet eller endrer noe i selve revisjonssporet, kan vi bevise at disse dataene, integriteten til selve dataene ble krenket. Og så 99, 9 prosent av tiden, hvis du har låst vår revisjonsspor-database, vil du ikke støte på det problemet fordi når vi kjører denne integritetssjekken, beviser vi i hovedsak overfor revisoren at selve dataene ikke har vært endret og slettet eller lagt til siden den opprinnelige skrivingen fra selve administrasjonstjenesten.
Så det er en generell oversikt over de typiske spørsmålene du vil bli stilt. Nå, verktøyet som vi må adressere mye av, kalles SQL Compliance Manager, og det gjør alle de tingene når det gjelder å spore transaksjonene, hvem, hva, når og hvor av transaksjonene, å kunne gjøre det på en antall forskjellige områder også. Innlogging, mislykkede pålogginger, skjemaendringer, åpenbart datatilgang, velg aktivitet, alle de tingene som skjer i databasemotoren. Og vi kan også varsle brukerne om spesifikke, veldig kornete forhold, om nødvendig. Noen går for eksempel ut og ser faktisk på tabellen som inneholder alle kredittkortnumrene mine. De endrer ikke dataene, de ser bare på dem. I den situasjonen kan jeg varsle, og jeg kan fortelle folk at det skjer, ikke seks timer senere når vi skraper logger, men i sanntid. Det er i utgangspunktet så lang tid som det tar for oss å behandle den transaksjonen gjennom en administrasjonstjeneste.
Som jeg nevnte før, har vi sett dette brukt i en rekke forskjellige forskriftskrav, og det gjør det ikke - du vet, noe regulatorisk krav, nok en gang, så lenge fellesnevnerne, har du sensitive data i en SQL Server database, er dette et verktøy som vil hjelpe i den typen situasjoner. For de 25 rapportene som er innebygd, er realiteten nå at vi kan gjøre dette verktøyet bra for revisoren og svare på hvert eneste spørsmål de stiller, men DBA-er er de som må få det til å fungere. Så det er også det å tenke på, du vet godt, fra et vedlikeholdsperspektiv må vi sørge for at SQL fungerer slik vi ønsker. Vi må også kunne gå inn og se på tingene som skal være i stand til å gå ut og se på andre opplysninger, du vet, så langt som arkivering av data, automatisering av dette og overhead selve produktet. Det er ting som vi åpenbart tar hensyn til.
Noe som bringer opp selve arkitekturen. Så på høyre side av skjermen har vi forekomstene av SQL som vi administrerer, alt fra 2000 helt frem til 2014, og gjør oss klare til å gi ut en versjon for 2016. Den største takeawayen på denne skjermen er at ledelsen serveren selv gjør alt det tunge løftet. Vi samler bare inn dataene, bruker sporings-API, innebygd med SQL Server. Denne informasjonen siver opp til administrasjonsserveren vår. Den administrasjonsserveren i seg selv identifiserer og hvis det er noen hendelser knyttet til noen typer transaksjoner som vi ikke ønsker, sender vi ut varsler og den slags ting, og deretter fyller dataene i et depot. Derfra kan vi kjøre rapporter, ville vi være i stand til å gå ut og faktisk se den informasjonen i rapportene eller til og med innenfor programmets konsoll.
Så det jeg skal gå foran og gjøre er at jeg kommer til å ta oss gjennom, virkelig raskt, og jeg vil bare påpeke en rask ting før vi hopper inn i produktet, det er en lenke på nettstedet akkurat nå, eller på presentasjonen, vil det ta deg til det gratis verktøyet jeg nevnte tidligere. Det gratis verktøyet er, som sagt, det skal gå ut og se på en database og prøve å finne områdene som ser ut som sensitive data, personnummer, kredittkortnummer, basert på navnene på kolonnene eller tabellene, eller basert på hvordan dataformatet ser ut, og du kan tilpasse det også, så bare for å påpeke det.
Nå, i mitt tilfelle, la meg gå videre og dele ut skjermen, gi meg ett sekund her. OK, og så, det jeg ønsket å ta deg med først, er at jeg vil ta deg til selve Compliance Manager-applikasjonen, og jeg kommer til å gå igjennom dette ganske raskt. Men dette er applikasjonen, og du kan se at jeg har et par databaser her, og jeg skal bare vise deg hvor enkelt det er å gå inn og fortelle det du vil revidere. Ut fra skjemaendringer, sikkerhetsendringer, administrative aktiviteter, DML, Velg, har vi alle disse alternativene tilgjengelig for oss, vi kan også filtrere det ned. Dette går tilbake til den beste fremgangsmåten for å kunne si: “Jeg trenger egentlig bare denne tabellen fordi den inneholder kredittkortnummerene mine. Jeg trenger ikke de andre tabellene som har produktinformasjon, alle de andre tingene som ikke er i forhold til nivået for samsvar jeg prøver å oppfylle. "
Vi har også muligheten til å fange opp data og vise dem når det gjelder verdiene til feltene som endrer seg. I mange verktøy har du noe som vil gi deg muligheten til å fange SQL-setningen, vise brukeren, vise applikasjonen, klokkeslettet og datoen, alt det gode. Men i noen tilfeller vil ikke selve SQL-setningen gi deg nok informasjon til å kunne fortelle deg hva verdien av feltet var før endringen skjedde, og verdien av feltet etter endringen skjedde. Og i noen situasjoner trenger du det. Det kan være lurt å spore for eksempel en leges doseringsinformasjon for reseptbelagte medisiner. Det gikk fra 50 mg til 80 mg til 120 mg, det ville jeg kunne spore før og etter.
Følsomme kolonner er en annen ting som vi møter mye på, for eksempel med PCI-samsvar. I situasjonen her har du data som er så følsomme at bare ved å se på den informasjonen, trenger jeg ikke å endre den, slette den eller legge til den, kan jeg forårsake uopprettelig skade. Kredittkortnumre, personnummer, alle den slags gode ting vi kan identifisere sensitive kolonner og knytte varsler til det. Hvis noen går ut og ser på den informasjonen, vil vi selvsagt kunne varsle og sende en e-post eller generere en SNMP-felle og den slags ting.
I noen tilfeller vil du komme i en situasjon der du kan ha et unntak. Og hva jeg mener med det, du har en situasjon hvor du har en bruker som har en brukerkonto som kan være bundet til en type ETL-jobb som kjører midt på natten. Det er en dokumentert prosess, og jeg trenger rett og slett ikke å ta med den transaksjonelle informasjonen for den brukerkontoen. I så fall ville vi ha en pålitelig bruker. Og så i andre situasjoner vil vi bruke funksjonen til Privilegert brukerrevisjon, som egentlig er, hvis jeg har, la oss si for eksempel et program, og at applikasjonen allerede gjør revisjon, av brukerne som går gjennom applikasjonen, det er bra, jeg har allerede noe å referere til når det gjelder tilsynet mitt. Men for de tingene som er knyttet til, for eksempel de privilegerte brukerne mine, gutta som kan gå inn i SQL Server management studio for å se på dataene i databasen, er det ikke til å kutte det. Og det er her vi kan definere hvem våre privilegerte brukere er, enten gjennom rollemedlemskap, eller gjennom deres Active Directory-kontoer, grupper, deres SQL-autentiserte kontoer, hvor vi kan velge alle de forskjellige typene alternativer og derfra, sørg for at for de privilegerte brukerne kan vi spesifisere hvilke typer transaksjoner vi er interessert i å revidere.
Dette er alle slags forskjellige alternativer du har, og jeg har ikke tenkt å gå gjennom alle de forskjellige typer ting basert på tidsbegrensningene her for denne presentasjonen. Men jeg vil vise deg hvordan vi kan se dataene, og jeg tror du vil like hvordan dette fungerer fordi det er to måter vi kan gjøre det på. Jeg kan gjøre det interaktivt, og når vi snakker med folk som er interessert i dette verktøyet for kanskje deres egne interne kontroller, vil de bare vite hva som skjer i mange tilfeller. De har ikke nødvendigvis revisorer som kommer på stedet. De vil bare vite, "Hei, jeg vil følge dette bordet og se hvem som har rørt det den siste uken eller forrige måned eller hva som måtte være." I dette tilfellet kan du se hvor raskt vi kan gjøre det.
Når det gjelder helsevesenet, har jeg en tabell som heter Pasientjournaler. Og det tabellen, hvis jeg bare skulle gruppere etter objekt, kunne det veldig raskt begynne å smale der vi leter etter. Kanskje jeg vil gruppere etter kategori og deretter kanskje etter arrangement. Og når jeg gjør det, kan du se hvor raskt det dukker opp, og der er tabellen over pasientjournaler der. Og når jeg borer i, kan vi nå se DML-aktiviteten, kan vi se at vi har hatt tusen innlegg av DML, og når vi åpner for en av disse transaksjonene kan vi se relevant informasjon. Hvem, hva, når, hvor transaksjonen er, SQL-setningen, åpenbart, den faktiske applikasjonen som brukes til å utføre transaksjonen, kontoen, klokkeslettet og datoen.
Hvis du ser på den neste fanen her, kategorien Detaljer, går dette tilbake til det tredje spørsmålet vi snakker om, og beviser at integriteten til dataene ikke er blitt brutt. Så i bunn og grunn har vi en hemmelig beregning av hasjverdien for hver hendelse, og dette kommer til å binde seg til når vi gjør vår integritetssjekk. Hvis jeg for eksempel skulle gå ut til verktøyet, gå inn i revisjonsmenyen, og jeg skulle gå ut og si, la oss sjekke repository integritet, kunne jeg peke på databasen der revisjonssporet er, det vil løpe gjennom en integritetskontroll som samsvarer med disse hasjverdiene og CRC-verdiene til de faktiske hendelsene, og den vil fortelle oss at det ikke har blitt funnet noen problemer. Med andre ord, dataene i revisjonssporet har ikke blitt tuklet med siden de opprinnelig ble skrevet av ledelsestjenesten. Det er tydeligvis en måte å samhandle med dataene på. Den andre måten ville være gjennom selve rapportene. Og så skal jeg bare gi deg et raskt eksempel på en rapport.
Og nok en gang er disse rapportene, slik vi kom frem til dem, ikke spesifikke for noen type standard som PCI, HIPAA, SOX eller noe sånt. Nok en gang er det fellesnevneren for hva vi gjør, og i dette tilfellet, hvis vi går tilbake til det pasientregistereksemplet, ville vi være i stand til å gå ut og si, i vårt tilfelle her, ser vi i helsevesenets database og i vårt tilfelle ønsker vi å fokusere spesifikt på den tabellen som vi vet inneholder privat informasjon, i vårt tilfelle, relatert til våre pasienter. Og så, la meg se om jeg kan skrive den her, så skal vi fortsette og kjøre rapporten. Og vi kommer til å se da, derfra, alle relevante data knyttet til det objektet. Og i vårt tilfelle viser det oss i en måneds tid. Men vi kan gå tilbake seks måneder, et år, uansett hvor lenge vi har oppbevart dataene.
Dette er den typen måter du faktisk kan bevise, hvis du vil, overfor revisoren at du følger kontrollene dine. Når du har identifisert det, er det tydeligvis en god ting når det gjelder å passere tilsynet og kunne vise at du følger kontrollene og alt fungerer.
Den siste tingen å snakke om det jeg ønsket å demonstrere er i administrasjonsseksjonen. Det er også kontroller fra synspunktet i dette verktøyet å kunne stille inn kontroller for å være i stand til å sikre at hvis noen gjør noe som de ikke skal gjøre, kan jeg bli gjort oppmerksom på det. Og jeg vil gi deg et par eksempler der. Jeg har en innloggingskonto som er knyttet til en tjeneste og som tjenesten trenger forhøyede tillatelser for å gjøre det den gjør. Det jeg ikke vil er at noen skal gå inn og bruke den kontoen i Management Studio, og deretter, vet du, bruke den til ting den ikke var beregnet på. Vi vil ha to kriterier som vi kan bruke. Jeg kan si: "Se, vi er virkelig interessert i at dette fungerer, si med PeopleSoft-applikasjonen vår, " bare som et eksempel, ok?
Nå som jeg har gjort det, det jeg sier her, er jeg nysgjerrig på å vite hvilke innlogginger som er knyttet til kontoen jeg gjør meg klar til å spesifisere, hvis applikasjonen som blir brukt til å logge på med denne kontoen. er ikke PeopleSoft, da kommer det til å øke alarmen. Og selvfølgelig må vi spesifisere kontonavnet selv, så i vårt tilfelle la oss bare kalle denne Priv-kontoen, for det faktum at den er privilegert. Når vi først har gjort det, når vi gjør dette her, vil vi nå kunne spesifisere hva vi vil ha skal skje når det skjer, og for hver eneste type hendelse, eller jeg må si, varsling, kan du ha en egen varsling til personen som er ansvarlig for det bestemte stykke data.
Hvis det for eksempel er lønnsinformasjon, kan det gå til min direktør for HR. I dette tilfellet, når du arbeider med PeopleSoft-applikasjonen, blir det administratoren av den applikasjonen. Uansett hva tilfellet måtte være. Jeg ville være i stand til å legge inn e-postadressen min, tilpasse den faktiske varselmeldingen og alle de slags gode ting. Nok en gang går dette tilbake til å være i stand til å sikre at du kan vise at du følger kontrollene dine, og at kontrollene fungerer slik de er ment. Fra det siste perspektivet her, bare når det gjelder vedlikehold, har vi muligheten til å ta disse dataene og legge dem offline. Jeg kan arkivere dataene, og jeg kan planlegge dem, og vi vil kunne gjøre disse tingene veldig enkelt i den forstand at du faktisk kunne være i stand til å bruke dette verktøyet som en DBA, sette den opp og slags gå bort fra det. Det er ikke mye håndholding som vil finne sted når du har satt den opp slik den skal være. Som jeg sa, den vanskeligste delen av noe av dette, tror jeg, er ikke å sette opp det du vil ha revisjon, det er å vite hva du vil sette opp til revisjon.
Og som sagt, dyrets natur med revisjon, du må oppbevare dataene i syv år, så det er bare fornuftig å fokusere på de områdene som er sensitive i naturen. Men hvis du vil gå tilnærming til å samle alt, kan du absolutt, det er bare ikke ansett som den beste praksis. Så fra det synspunktet vil jeg bare minne folk om at hvis dette er noe som er interessant, kan du gå inn på nettstedet på IDERA.com og laste ned en prøveversjon av dette og leke med det selv. Når det gjelder gratisverktøyet som vi snakket om tidligere, er det vel, det er gratis, du kan laste ned det og bruke det for alltid, uansett om du bruker Compliance Manager-produktet. Og det kule med det søyleverktøyet for kolonnene er at funnene du kommer frem til, og jeg faktisk kan vise at jeg tror er at du vil kunne eksportere disse dataene og deretter kunne importere dem til Compliance Manager også. Jeg ser det ikke, jeg vet at det er her, der er det. Dette er bare et eksempel på det. Det er her du finner de relaterte sensitive dataene.
Nå har denne saken gått ut og jeg har virkelig sett på alt, men du har bare mange ting vi kan se etter. Kredittkortnumre, adresser, navn, alle den slags ting. Og vi identifiserer hvor den er i databasen, og derfra kan du ta beslutningen om du faktisk vil revidere den informasjonen eller ikke. Men det er definitivt en måte å gjøre det mye enklere for deg å definere omfanget av revisjon når du ser på et verktøy som dette.
Jeg vil bare fortsette og lukke med det, og jeg vil gå videre og gi det tilbake til Eric.
Eric Kavanagh: Det er en fantastisk presentasjon. Jeg elsker måten du virkelig får inn i de grisete detaljene der og viser oss hva som skjer. For på slutten av dagen er det et system som kommer til å få tilgang til noen poster, som kommer til å gi deg en rapport, som vil få deg til å fortelle historien din, enten det er til en regulator eller en revisor eller noen i teamet ditt, så det er bra at du vet at du er forberedt på om og når, eller som og når, den personen banker på, og det er selvfølgelig den ubehagelige situasjonen du prøver å unngå. Men hvis det skjer, og det sannsynligvis vil skje i disse dager, vil du være sikker på at du har dine I-punkter og T er krysset.
Det er et godt spørsmål fra et publikummedlem jeg vil kaste ut til kanskje deg først, Bullett, og så hvis en programleder kanskje ønsker å kommentere det, føl deg fri. Og så kan Dez stille et spørsmål og Robin. Så spørsmålet er, er det rettferdig å si at for å gjøre alle de tingene du har nevnt, må du starte en innsats med dataklassifisering på et grunnleggende nivå? Du må kjenne dataene dine når de fremstår som en verdifull potensiell eiendel og gjøre noe med det. Jeg tror du vil være enig, Bullett, ikke sant?
Bullett Manale: Ja, absolutt. Jeg mener, du må kjenne dataene dine. Og jeg er klar over at jeg er klar over at det er mange applikasjoner som finnes der og at det er mange forskjellige ting som har bevegelige deler i organisasjonen din. Kolonne søkeverktøyet er veldig nyttig når det gjelder å gå et skritt i retning av å forstå disse dataene bedre. Men ja, det er veldig viktig. Jeg mener, du har muligheten til å gå på brannslangetilnærmingen og kontrollere alt, men det er bare mye mer utfordrende på den måten logistisk når du snakker om å måtte lagre disse dataene og rapportere mot disse dataene. Og så trenger du fremdeles å vite hvor den datadelen er, fordi når du kjører rapportene dine, trenger du å vise revisorene den informasjonen også. Så jeg tror at, som sagt, den største utfordringen når jeg snakker med databaseadministratorer er å vite, ja.
Eric Kavanagh: Ja, men kanskje Robin tar vi deg raskt inn. Det virker som om 80/20 regelen gjelder her, ikke sant? Du kommer sannsynligvis ikke til å finne hvert system med poster som betyr noe om du er i en mellomstor eller stor organisasjon, men hvis du fokuserer på - som Bullett antydet her - for eksempel PeopleSoft, eller andre systemer for opptak som er dominerende i bedriften, det er der du fokuserer 80 prosent av innsatsen din, og så er 20 prosent på de andre systemene som kan være der et sted, ikke sant?
Robin Bloor: Jeg er sikker, ja. Jeg mener, du vet, jeg tror problemet med denne teknologien, og jeg tror det sannsynligvis er verdt å ha en kommentar om den, men problemet med denne teknologien er, hvordan implementerer du den? Jeg mener, det er veldig definitivt mangel på kunnskap, la oss si, i de fleste organisasjoner om til og med antall databaser som er der ute. La oss si det er veldig mangel på varelager. Du vet, spørsmålet er, la oss tenke oss at vi begynner i en situasjon der det ikke er en særlig godt administrert samsvar, hvordan tar du denne teknologien og sprøyter den inn i miljøet, ikke bare i, du vet, teknologi vilkår, sette opp ting, men som hvem som klarer det, hvem bestemmer hva? Hvordan begynner du å gjøre dette til en ekte, gjør sin jobb?
Bullett Manale: Det mener jeg er, det er et godt spørsmål. Utfordringen i mange tilfeller er at, jeg mener, du må begynne å stille spørsmålene helt i begynnelsen. Jeg har støtt på mange selskaper der de, du vet, kanskje de er et privat selskap og de har skaffet seg, det er en første, slags, første, slags road bump, hvis du vil kalle det det. For eksempel, hvis jeg nettopp har blitt et børsnotert selskap på grunn av oppkjøpet, må jeg gå tilbake og sannsynligvis finne ut noe.
Og i noen tilfeller snakker vi med organisasjoner som, vet du, selv om de er private, de følger SOX-regler for overholdelse, ganske enkelt fordi de i tilfelle at de ønsker å bli anskaffet de vet at de må overholde. Du vil definitivt ikke ta tilnærmingen til bare “Jeg trenger ikke å bekymre meg for dette nå.” Enhver form for lovgivningsmessig samsvar som PCI eller SOX eller hva som helst, du vil gjøre investeringer i å gjøre forskningen eller forståelse for hvor sensitiv informasjon er, ellers kan du finne på å håndtere noen betydelige, heftige bøter. Og det er mye bedre bare å investere den tiden, du vet, finne de dataene og kunne rapportere mot dem og vise at kontrollene fungerer.
Ja, når det gjelder å sette den opp, som sagt, det første jeg vil anbefale til folk som gjør seg klar til å møte en revisjon, er å bare gå ut og gjøre en kortfattet undersøkelse av databasen, og finne ut, du kjenner, i sin beste innsats, å prøve å finne ut hvor de sensitive dataene er. Og den andre tilnærmingen vil være å starte med kanskje et større nett med tanke på hva omfanget av revisjon er, og så sakte bremse deg ned når du, på en måte, finner ut hvor områdene i systemet er som er relatert til sensitiv informasjon. Men jeg skulle ønske jeg kunne fortelle deg at det er et enkelt svar på det spørsmålet. Det kommer sannsynligvis til å variere ganske fra organisasjon til organisasjon og type samsvar, og hvordan, du vet, hvor mye struktur de har innen applikasjonene og hvor mange har forskjellige applikasjoner de har, noen kan være tilpassede skriftlige applikasjoner, så det kommer virkelig til å avhenge av situasjonen i mange tilfeller.
Eric Kavanagh: Fortsett, Dez, jeg er sikker på at du har et spørsmål eller to.
Dez Blanchfield: Jeg er opptatt av å bare få litt innsikt i observasjonene dine rundt virkningen for organisasjonene fra et folkemessig synspunkt, faktisk. Jeg tror at et av områdene der jeg ser størst verdi for akkurat denne løsningen, er at når folk våkner om morgenen og går på jobb på forskjellige nivåer i organisasjonen, våkner de opp med en serie med, eller en kjede av, ansvar som de har å gjøre med. Og jeg er opptatt av å få litt innsikt i hva du ser der ute med og uten hvilke typer verktøy du snakker om. Og konteksten jeg snakker om her, er fra styreleder til styrets nivå til administrerende direktør og CIO og C-suiten. Og nå har vi sjefrisikobetjenter, som tenker mer på hva slags ting vi snakker om her i samsvar og styring, og så har vi nå fått nye sjefer for rollespill, sjefdateansvarlig, hvem er, du vet, enda mer opptatt av det.
Og på siden av hver av dem, rundt CIO, har vi IT-ledere på en side med, slags du vet, tekniske kundeemner og deretter databaselinjer. Og i det operative rommet har vi utviklingsledere og utviklingsledere og deretter individuell utvikling, og de sløyfer også tilbake til databaseadministrasjonssjiktet. Hva ser du rundt reaksjonen fra hver av disse forskjellige delene av virksomheten til utfordringen med overholdelse og forskriftsrapportering og deres tilnærming til den? Ser du at folk kommer med dette med en inderlighet og kan se fordelen med det, eller ser du at de motvillig drar føttene til denne tingen og bare, vet du, gjør det for en hake i boksen? Og hva er slags svar du ser når de ser programvaren din?
Bullett Manale: Ja, det er et godt spørsmål. Jeg vil si at dette produktet, salget av dette produktet, stort sett er drevet av noen som sitter i det varme setet, hvis det er fornuftig. I de fleste tilfeller er det DBA, og fra vårt perspektiv, med andre ord, de vet at det kommer en revisjon og at de kommer til å være ansvarlige, fordi de er DBAene, for å kunne gi informasjonen som revisor kommer til spørre. Det kan de gjøre ved å skrive sine egne rapporter og lage sine egne tilpassede spor og alle de slags ting. Realiteten er at de ikke vil gjøre det. I de fleste tilfeller ser ikke DBA-er virkelig frem til å få disse samtalene med revisor til å begynne med. Du vet, jeg vil heller fortelle deg at vi kan gå til et selskap og si: "Hei, dette er et flott verktøy, og du kommer til å elske det, " og vise dem alle funksjonene, og de vil kjøpe det.
Realiteten er at de vanligvis ikke kommer til å se på dette verktøyet med mindre de faktisk kommer til å bli konfrontert med en revisjon, eller den andre siden av den mynten er at de har hatt en revisjon og feilet det elendig, og nå er de får beskjed om å få litt hjelp, eller så blir de bøtelagt. Jeg vil si at når du viser dette produktet til folk når det gjelder dette, vet du absolutt verdien av det fordi det sparer dem masse tid i forhold til å måtte finne ut hva de vil rapportere om., den slags ting. Alle disse rapportene er allerede innebygd, varslingsmekanismene er på plass, og da med det tredje spørsmålet kan det også i mange tilfeller være en utfordring. Fordi jeg kan vise deg rapporter hele dagen, men med mindre du kan bevise for meg at disse rapportene faktisk er gyldige da, vet du, er det mye tøffere forslag for meg som DBA å kunne vise det. Men vi har utarbeidet teknologien og hashing-teknikken og alle de slags ting for å være i stand til å sikre at dataene i integriteten til revisjonssporene blir oppbevart.
Og slik er det tingene, det er mine observasjoner når det gjelder de fleste vi snakker med. Du vet, det er definitivt, i forskjellige organisasjoner, du vet om, du vil høre om, du vet som, mål, for eksempel, hadde et datainnbrudd, og du vet, jeg mener, når andre organisasjoner hører om bøtene og de slags ting folk begynner, det hever et øyenbryn, så forhåpentligvis som svarer på spørsmålet.
Dez Blanchfield: Ja, definitivt. Jeg kan tenke meg noen DBA-er når de endelig ser hva som kan gjøres med verktøyet, bare er klar over at de også har fått sene kvelder og helger tilbake. Tids- og kostnadsreduksjoner og andre ting jeg ser når passende verktøy blir brukt på hele dette problemet, og det er at jeg satt tre uker i en bank her i Australia. De er en global bank, en topp tre bank, de er enorme. Og de hadde et prosjekt der de måtte rapportere om overholdelse av formuesforhold og særlig risiko, og de så på 60 ukers arbeid for et par hundre mennesker. Og da de ble vist slike som et verktøy som deg som bare kunne automatisere prosessen, denne sansen, utseendet på ansiktene deres da de skjønte at de ikke måtte bruke X antall uker med hundrevis av mennesker som gjorde en manuell prosess var på samme måte som de hadde funnet Gud. Men den utfordrende tingen da var hvordan man faktisk kunne sette den i plan, som Dr. Robin Bloor antydet, du vet, dette er noe som blir en blanding av atferdsmessig, kulturelt skifte. På nivåene du har å gjøre med, og som arbeider med dette direkte på applikasjonsnivå, hva slags endring ser du når de begynner å ta i bruk et verktøy for å utføre den typen rapportering og revisjon og kontroller du kan tilby, som i motsetning til hva de kan ha gjort manuelt? Hvordan ser det ut når de faktisk utøves?
Bullett Manale: spør du, hva er forskjellen når det gjelder håndtering av dette manuelt kontra bruk av dette verktøyet? Er det spørsmålet?
Dez Blanchfield: Vel, spesifikt virkningen av virksomheten. Så hvis vi for eksempel prøver å levere samsvar i en manuell prosess, vet du, tar vi alltid lang tid med mange mennesker. Men jeg antar, for å sette litt kontekst rundt spørsmålet, snakker vi, som du vet, om en enkelt person som kjører dette verktøyet som erstatter potensielt 50 personer, og kan gjøre det samme i sanntid eller i timer kontra måneder? Er det den slags, hva viser det seg å være?
Bullett Manale: Jeg mener, det kommer ned på et par ting. Den ene har muligheten til å svare på disse spørsmålene. Noen av disse tingene vil ikke bli gjort så lett. Så ja, tiden det tar å gjøre tingene hjemmelaget, å skrive rapportene på egen hånd, å sette opp sporene eller de utvidede hendelsene for å samle inn data manuelt, kan ta mye tid. Egentlig skal jeg gi deg noen, jeg mener, dette har egentlig ikke forhold til databaser generelt, men som rett etter at Enron skjedde og SOX ble utbredt, var jeg hos et av de større oljeselskapene i Houston, og vi regnet med, Jeg tror det var som om 25 prosent av forretningskostnadene våre var relatert til SOX-samsvar.
Nå var det rett etter, og det var liksom det første første trinnet hos SOX, men tingen med, vil jeg si, du vet, du får mye utbytte av å bruke dette verktøyet i den forstand at det ikke krever mye mennesker som gjør dette, og mange forskjellige mennesker som gjør det. Og som sagt, DBA er ikke typisk den fyren som virkelig ser frem til å ha de samtalene med revisorene. Så i mange tilfeller vil vi se at DBA kan laste av dette og kunne gi rapporten grensesnitt til revisoren, og de kan fjerne seg fullstendig ut av ligningen i stedet for å måtte være involvert. Så, du vet, det er en enorm besparelse også når det gjelder ressurs når du kan gjøre det.
Dez Blanchfield: Du snakker om enorme kostnadsreduksjoner, ikke sant? Organisasjonene fjerner ikke bare risikoen og omkostningen av den, men jeg mener egentlig at du snakker om en betydelig reduksjon i kostnadene, A) operasjonelt og også B) i det faktum at du vet om de faktisk kan gi reell- rapportering om overholdelse av tid om at det er betydelig redusert risiko for brudd på data eller juridisk bot eller innvirkning for ikke å være kompatibel, ikke sant?
Bullett Manale: Ja, absolutt. For at jeg ikke er kompatibel, er det alle slags dårlige ting som skjer. De kan bruke dette verktøyet, og det ville være flott eller ikke, og de vil finne ut hvor ille det egentlig er. Så ja, det er ikke bare verktøyet tydeligvis, du kan gjøre sjekkene dine og alt uten et verktøy som dette. Som jeg sa, det vil bare ta mye mer tid og kostnader.
Dez Blanchfield: Det er flott. Så Eric, jeg kommer til å gi meg tilbake til deg fordi jeg tror at takeaway for meg er at, du vet, markedet er fantastisk. Men også, i hovedsak, er tingen verdt sin vekt i gull på grunnlag av at det å kunne unngå den kommersielle effekten av et problem som finner sted eller å kunne redusere tiden det tar å rapportere og administrere etterlevelse, bare gjør at du vet verktøyet betaler for seg selv med lyden av ting.
Eric Kavanagh: Det er helt riktig. Tusen takk for tiden din i dag, Bullett. Takk til dere alle der ute for deres tid og oppmerksomhet, og Robin og Dez. Nok en flott presentasjon i dag. Takk til vennene våre på IDERA for å la oss gi deg dette innholdet gratis. Vi vil arkivere denne webcasten for senere visning. Arkivet er vanligvis oppe i løpet av omtrent en dag. Og la oss få vite hva du synes om den nye nettsiden vår, insideanalysis.com. Et helt nytt design, et helt nytt utseende og preg. Vi vil gjerne høre tilbakemeldingene dine, og med det kommer jeg til å ta farvel, folkens. Du kan sende meg e-post. Ellers får vi tak i deg neste uke. Vi har syv web-sendinger i løpet av de neste fem ukene, eller noe sånt. Vi kommer til å være opptatt. Og vi vil være på Strata Conference og IBM Analyst Summit i New York senere denne måneden. Så hvis du er der rundt, kan du stikke innom og si hei. Ta vare, folkens. Ha det.
