Af Techopedia Staff, 14. september 2016
Takeaway: Værten Eric Kavanagh diskuterer databaserevision og overholdelse af analytikere Robin Bloor og Dez Blanchfield samt Bullett Manale fra IDERA i denne episode af Hot Technologies.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej og velkommen, igen, til Hot Technologies! Ja, 2016. Vi er i år tre af dette show, det er meget spændende ting. Vi har gynget og rullet i år. Dette er Eric Kavanagh, din vært. Emnet for i dag - dette er et godt emne, det har masser af applikationer overalt i en række industrier, helt ærligt - "Hvem, hvad, hvor og hvordan: hvorfor du vil vide." Ja, vi skal tale om alle de sjove ting. Der er et lysbillede om jer virkelig, slå mig op på Twitter @eric_kavanagh. Jeg prøver at gentweet alle omtaler og tweet om alt, hvad nogen sender til mig. Ellers, så vær det.
Det er varmt, ja! Hele showet her er designet til at hjælpe organisationer og enkeltpersoner med at forstå bestemte slags teknologier. Vi designet hele programmet her, Hot Technologies, som en måde at definere en bestemt type software, eller en bestemt tendens eller en bestemt type teknologi. Årsagen er, at ærligt talt, i softwareverdenen, får du ofte disse markedsføringsbetingelser, der bliver båndede om, og nogle gange kan de ærligt tæve de begreber, de var beregnet til at beskrive.
I dette show prøver vi virkelig at hjælpe dig med at forstå, hvad en bestemt type teknologi er, hvordan den fungerer, når du kan bruge den, når du måske ikke skal bruge den, og give dig så mange detaljer, som vi muligvis kan. Vi har tre præsentanter i dag: vores helt egen Robin Bloor, chefanalytiker her i Bloor Group; vores dataforsker indkalder fra Sydney, Australien på den anden side af planeten, Dez Blanchfield, og en af vores foretrukne gæster Bullett Manale, direktør for salgsteknik hos IDERA.
Jeg skal bare sige et par ting her og forstå, hvem der laver hvad med hvilket stykke data, ja, det er en slags lignende regeringsførelse, ikke? Hvis du tænker på alle reglerne i brancher, såsom sundhedspleje og finansielle tjenester, på disse domæner, er disse ting utroligt vigtige. Du skal vide, hvem der rørte ved informationen, hvem der har ændret noget, hvem der har adgang til den, hvem der uploade den for eksempel. Hvad er afstamningen, hvad er forsynet med disse data? Du kan være sikker på, at alle disse spørgsmål vil forblive fremtrædende i de kommende år af alle slags grunde. Ikke kun for overholdelse, skønt HIPAA, og Sarbanes-Oxley og Dodd-Frank, og alle disse regler er meget vigtige, men også bare så du forstår i din virksomhed, hvem der gør hvad, hvor, hvornår, hvorfor og hvordan. Dette er gode ting, vi vil være opmærksomme.
Gå videre, tag det væk, Robin Bloor.
Robin Bloor: Okay, tak for indledningen, Eric. Dette område med regeringsførelse er, mener jeg, regeringsførelse inden for IT var ikke et ord, som du hørte før lidt efter år 2000, tror jeg. Det skete først og fremmest, fordi jeg alligevel tror, at det primært skyldtes, at der er overholdelseslovgivning, der foregik. Især HIPAA og Sarbanes-Oxley. Der er faktisk meget af det. Derfor indså organisationer, at de måtte have et sæt regler og et sæt procedurer, fordi det var nødvendigt i henhold til loven at gøre det. Længe før det, især inden for banksektoren, var der forskellige initiativer, som du var nødt til at overholde, afhængigt af, hvilken slags bank du var, og især de internationale bankfolk. Hele Basel-kompatible startede måde, langt før det særlige sæt af initiativer efter år 2000. Det hele kommer virkelig ned på regeringsførelsen. Jeg troede, at jeg ville tale om styringsemnet som en introduktion til fokus for at holde øje med, hvem der får dataene.
Datastyring, jeg plejede at kigge rundt, jeg tænkte på for fem eller seks år siden, kiggede efter definitioner, og det var slet ikke godt defineret. Det er blevet klarere og klarere, hvad det faktisk betyder. Situationen var, at inden for visse grænser faktisk var alle data styret tidligere, men der var ingen formelle regler for det. Der var specielle regler, der blev lavet især i bankbranchen for at lave sådanne ting, men igen handlede det mere om overholdelse. På en eller anden måde at bevise, at du faktisk var en - det er slags forbundet med risiko, så det at bevise, at du var en levedygtig bank, var handlen.
Hvis man ser på regeringsudfordringen nu, begynder det med en kendsgerning om big data-bevægelsen. Vi har et stigende antal datakilder. Datamængde er selvfølgelig et problem med det. Især begyndte vi at gøre meget, meget og mere med ustrukturerede data. Det begyndte at blive noget, der er en del af hele analysespelet. Og på grund af analyser er dataprioritet og afstamning vigtigt. Virkelig set fra brug af dataanalyse på nogen måde relateret til enhver form for overholdelse, skal du virkelig have viden om, hvor dataene kommer fra, og hvordan det skal være, hvad det er.
Datakryptering begyndte at blive et problem, blive et større problem, så snart vi tog til Hadoop, fordi ideen om en datasø, hvor vi gemmer en masse data, pludselig betyder, at du har et enormt sårbarhedsområde for mennesker, der kan få i gang med det. Kryptering af data blev meget mere fremtrædende. Godkendelse var altid et problem. I det ældre miljø, strengt mainframe-miljø, havde de en sådan vidunderlig sikkerhedsbeskyttelse; godkendelse var aldrig rigtig meget af et problem. Senere blev det et større emne, og det er meget mere et problem nu, fordi vi har så enormt distribuerede miljøer. Overvågning af datatilgang, det blev et problem. Jeg ser ud til at huske forskellige værktøjer, der kom til for omkring ti år siden. Jeg tror, at de fleste af disse blev drevet af overholdelsesinitiativer. Derfor har vi også alle overholdelsesregler, overholdelsesrapportering.
Det, der er kommet i tankerne, er, at selv tilbage i 1990'erne, da du foretog kliniske forsøg i medicinalindustrien, var du ikke kun nødt til at være i stand til at bevise, hvor dataene kom fra - selvfølgelig er det meget vigtigt, hvis du prøver ud et lægemiddel i forskellige sammenhænge, for at vide, hvem der bliver prøvet på og hvad de kontekstuelle data omkring det - du måtte være i stand til at give en revision af den software, der faktisk oprettede dataene. Det er det mest alvorlige stykke overholdelse, jeg nogensinde har set overalt, med hensyn til at bevise, at du faktisk ikke rodder ting bevidst eller ved et uheld. I den seneste tid er især styring af livscyklus af data blevet et problem. Alle disse er på en måde udfordringer, fordi mange af disse ikke er blevet gjort godt. Under mange omstændigheder er det nødvendigt at gøre dem.
Dette er, hvad jeg kalder datapyramiden. Jeg har snakket om dette før. Jeg synes det er en meget interessant måde at se på tingene på. Du kan tænke på data som lag. Rå data, hvis du vil, er virkelig bare signaler eller målinger, optagelser, begivenheder, hovedsagelig enkelt poster. Muligvis skaber transaktioner, beregninger og aggregeringer naturligvis nye data. De kan tænkes på på dataniveau. Når du faktisk forbinder data sammen, bliver det information. Det bliver mere nyttigt, men naturligvis bliver det mere sårbart over for folk, der hacker det eller misbruger det. Jeg definerer det som skabt, virkelig gennem strukturering af data, ved at være i stand til at visualisere dataene med ordlister, skemaer, ontologier på informationen. Disse to nedre lag er det, vi behandler på en eller anden måde. Ovenfor det kalder jeg det viden, der består af regler, politikker, retningslinjer, procedure. Nogle af dem kan faktisk være skabt af indsigt opdaget i analytics. Mange af dem er faktisk politikker, som du skal overholde. Dette er laget, hvis du vil, af regeringsførelse. Det er her, på en eller anden måde, hvis dette lag ikke er ordentligt befolket, administreres de to lag nedenfor ikke. Det sidste punkt herom er forståelse i noget, der kun bor i mennesker. Computere har ikke formået at gøre det endnu, heldigvis. Ellers ville jeg være ude af et job.
Regeringsimperiet - Jeg sammensatte den slags, jeg tror, det må have været omkring ni måneder siden, muligvis meget tidligere end det. Grundlæggende forbedrede jeg det slags, men så snart vi begyndte at blive bekymrede for regeringsførelse, så var der, hvad angår virksomhedsdatahub, ikke kun datareservoir, data-søressourcer, men også generelle servere af forskellige slags, specialiserede dataservere. Alt dette skulle styres. Når du faktisk også kiggede på den forskellige dimension - datasikkerhed, rensning af data, opdagelse af metadata og metadatastyring, oprettelse af en virksomhedsordliste, datakortlægning, datalinje, styring af livscyklus for data - derefter, overvågning af ydelser, serviceniveaustyring, systemadministration, som du muligvis ikke forbinder med regeringsførelse, men en bestemt - nu hvor vi går til en hurtigere og hurtigere verden med flere og flere dataflow, er det faktisk nødvendigt at kunne gøre noget med en bestemt præstation begynder at blive en forretningsregel snarere end noget andet.
Sammenfattende med hensyn til væksten i overholdelse så jeg dette ske i mange, mange år, men den generelle databeskyttelse kom faktisk i 1990'erne i Europa. Det blev bare mere og mere sofistikeret siden da. Derefter begyndte alle disse ting at blive introduceret eller gjort mere sofistikerede. GRC, det er styringsrisiko og overholdelse, har været i gang siden bankerne gjorde Basel. ISO har skabt standarder for forskellige slags operationer. Jeg ved hele tiden, at jeg har været inden for IT - det har været lang tid - USA's regering har været særlig aktiv med at skabe forskellige lovgivninger: SOX, der er Gramm-Leach-Bliley, HIPAA, FISMA, FERPA. Du har også den vidunderlige NIST-organisation, der skaber mange standarder, især sikkerhedsstandarder, meget nyttige. Lovgivningen om databeskyttelse i Europa har lokale afvigelser. Hvad du for eksempel kan gøre med personoplysninger i Tyskland, er anderledes end hvad du kan gøre i Slovakiske republik eller Slovenien eller hvor som helst. De introducerede for nylig - og jeg troede, jeg ville nævne dette, fordi jeg synes det var underholdende - Europa introducerer ideen om retten til at blive glemt. Det vil sige, der burde være en statut for begrænsninger af data, der har været offentlig, og som faktisk er personoplysninger. Det synes jeg er sjove. Fra et it-synspunkt bliver det meget, meget vanskeligt, hvis det begynder at blive effektiv lovgivning. I resuméet vil jeg sige følgende: Da it-data og -styring udvikler sig hurtigt, skal styring også udvikle sig hurtigt, og det gælder for alle styringsområder.
Når det er sagt, sender jeg bolden videre til Dez.
Eric Kavanagh: Ja, så Dez Blanchfield, tag det væk. Robin, jeg er med dig, mand, jeg dør for at se, hvordan denne ret til at blive glemt spiller ud. Jeg tror, at det ikke bare vil være udfordrende, men dybest set umuligt. Det er bare en krænkelse af at vente på at blive udøvet af regeringsorganer. Dez, tag det væk.
Dez Blanchfield: Det er faktisk, og det er et emne til en anden diskussion. Vi har en meget lignende udfordring her i Asien-Stillehavet, og især i Australien, hvor luftfartsselskaber og internetudbydere kræves for at logge alt, der er relateret til internettet og være i stand til at registrere og regurgitere det, hvis nogen af interesser gør noget galt. Det er en lov, og du skal overholde den. Udfordringen, ligesom nogen i Google i USA måske får besked om at slette min søgehistorik eller hvad som helst, kan det være at overholde europæisk lovgivning, især tysk privatret. Hvis et agentur i Australien ønsker at undersøge dig, skal en transportør være i stand til at give detaljer om opkald og søgningshistorik, hvilket er udfordrende, men det er den verden, vi lever i. Der er en masse grunde til det. Lad mig bare hoppe ind i min.
Jeg gjorde bevidst min titelside svært at læse. Du skal virkelig se hårdt på den tekst. Overholdelse, i overensstemmelse med et sæt regler, specifikationer, kontroller, politikker, standarder eller love med en fjollet, rodet baggrund. Det skyldes, at du virkelig skal se på det svært at få detaljerne og hente oplysninger fra, hvad den er overlejret, som er en række borde og rækker og kolonner, enten en database, et skema eller en mock-up i Visio. Sådan føles overholdelsesformer dagligt. Det er ret svært at dykke ned i detaljerne og trække de relevante informationsdel, du har brug for, for at kunne bekræfte, at du overholder. Rapporter om det, overvåg det og test det.
Faktisk tænkte jeg en rigtig god måde at visualisere dette, når vi stiller os selv spørgsmålet, "Er du kompatibel?" "Er du sikker?" "Nå, bevis det!" Der er en virkelig sjov ting, der måske er lidt mere anglo-keltisk, men jeg er sikker på, at det er kommet rundt i verden ind i USA, så det er: "Where's Wally?" Wally er en lille karakter, der kommer ind i disse tegneserietegninger i form af bøger. Normalt meget store billeder af A3 eller større. Så tegninger i bordstørrelse. Han er en lille karakter, der bærer en beanie og en rød-hvid stribet skjorte. Idéen med spillet er, at du ser på dette billede, og du ser dig rundt i cirkler for at prøve at finde Wally. Han er på det billede der et eller andet sted. Når du tænker over, hvordan du opdager og beskriver og rapporterer om compliance, er det på mange måder som at spille "Where's Wally." Hvis du ser på det billede, er det næsten umuligt at finde karakteren. Børn bruger timer på det, og jeg havde det meget sjovt med at gøre det selv i går. Når vi ser på det, finder vi en hel flok mennesker i disse tegneserier, der bevidst er anbragt der med lignende stykker af Wally-tøjet fra en stribet beanie og en trøje eller uldtop. Men de viser sig at være falske positive.
Dette er en lignende udfordring, som vi har med overholdelse. Når vi ser på ting, er nogle gange noget, vi synes, dette er tilfældet, slet ikke tilfældet. Nogen har muligvis adgang til en database, og de skal have denne adgang til en database, men måden, de bruger den på, er lidt anderledes end hvad vi forventer. Vi beslutter måske, at det er noget, vi skal se på. Når vi ser på det, finder vi, faktisk, det er en meget gyldig bruger. De laver bare noget finurligt. Måske er det en pc-forsker, eller hvem ved det. I andre tilfælde kan det være det modsatte. Virkeligheden, når jeg går fremad, er der Wally. Hvis du så virkelig hårdt ud i denne høje opløsning, er der en karakter, der faktisk bærer den rigtige påklædning. Alle de andre er bare lookalikes og feel-alike. Overholdelse føles meget sådan. De fleste mennesker, jeg kender, arbejder inden for kontrol og overholdelse og politikområder for virksomheder. På en lang række områder, hvad enten det er teknologi, hvad enten det er finansiering, drift eller risiko og risiko. Ofte er det meget svært at se Wally på billedet, du vil se træerne eller træet.
Spørgsmålet, som vi stiller os selv, når vi tænker på ting som compliance, er "Big deal, hvad kan muligvis gå galt, hvis vi ikke helt overholder overholdelsen?" I forbindelse med dagens diskussion, specifikt omkring database og kontrol med adgang til data, vil jeg give dig nogle meget ægte eksempler på wake-up call om, hvad der kan gå galt i meget kort kortfattet form. Hvis vi tænker på dataovertrædelser, og vi alle er bekendt med dataovertrædelser, hører vi dem i medierne, og vi slags stopper og griner, fordi folk tror, det er markeder. Det er personlige ting. Det er Ashley Madison og mennesker, der søger at få datoer uden for deres forhold og ægteskaber. Det er smukke konti. Det er alle disse underlige ting eller en tilfældig europæisk eller russisk internetudbyder eller hostingfirma bliver hacket. Når det kommer til ting som MySpace og disse top ti, når du ser på disse tal, hvad jeg vil have dig til at indse er dette: 1, 1 milliarder menneskers detaljer i disse top ti overtrædelser. Og ja, der er overlapninger, der er sandsynligvis folk, der har en MySpace-konto, og en Dropbox-konto og en Tumblr-konto, men lad os bare runde den op til en milliard mennesker.
Disse top ti overtrædelser i det sidste årti eller deromkring - ikke engang et årti, i de fleste tilfælde - summerer cirka en syvendedel af verdens befolkning af mennesker, men mere realistisk er omkring 50 procent af antallet af mennesker forbundet med internet, over en milliard individer. Disse sker, fordi overholdelse ikke er opfyldt i nogle tilfælde. I de fleste tilfælde var der kontrol med adgang til database, kontrol med adgang til bestemte datasæt og systemer og netværk. Dette er en skræmmende realitycheck. Hvis det ikke skræmmer dig, når du ser på top ti, og du kan se, at dette er en - eller kan se, at dette er en milliard individer, ægte mennesker ligesom os, på dette opkald lige nu. Hvis du har en LinkedIn-konto, hvis du havde en Dropbox-konto, eller en Tumblr-konto, eller hvis du købte fra Adobe-produkter eller endda registrerede, download gratis Adobe-viewer. Det er helt sandsynligt, ikke muligt, det er helt sandsynligt, at dine detaljer, dit fornavn, dit efternavn, din e-mail-adresse, potentielt endda din arbejdsfirma-adresse, eller din hjemmeadresse eller dit kreditkort, faktisk er derude på grund af et brud der fandt sted på grund af kontrollerne, som ikke nødvendigvis lykkedes godt i form af datastyring, datastyring.
Lad os se på det, når vi ser på det i detaljer. Der er en skærm af dem, der er omkring 50-noget der. Der er en anden 15. Der er omkring en anden 25. Dette er dataovertrædelser, der er vist på et websted kaldet haveibeenpwned.com. Dette er, hvad der muligvis kan gå galt, hvis ikke noget enkelt som at kontrollere, hvem der har haft adgang til data i databaser i forskellige felter og rækker og kolonner og forskellige applikationer i din virksomhed, ikke administreres korrekt. Disse organisationer er nu datadrevet. De fleste data lever i en database i en eller anden form. Når du tænker over det, er den liste over brud, som vi lige kiggede på, og forhåbentlig giver den dig lidt koldt brusebad på en måde, idet du tænkte "Hmm, det er meget rigtigt", og det har potentielt haft indflydelse på dig. I 2012, for eksempel det brud på LinkedIn, har de fleste fagfolk en LinkedIn-konto i disse dage, og det er sandsynligt, at dine oplysninger går tabt. De har været ude på Internettet siden 2012. Vi er kun blevet fortalt om det i 2016. Hvad skete der med dig information i de fire år? Det er godt interessant, og vi kan tale om det separat.
Database og systemadministration - Jeg taler ofte om, hvad jeg betragter som de fem største udfordringer med at håndtere disse ting. Helt øverst, og jeg rangerer disse i rækkefølge af præference fra mig selv, men også rækkefølge af påvirkning, nummer et er sikkerhed og overholdelse. Kontrollerne og mekanismerne og politikkerne til at kontrollere, hvem der har hvilken adgang til hvilket system, af hvilken grund og formål. Rapporterer om det og overvåger det, ser på systemerne, ser i databaserne og ser, hvem der faktisk kan få adgang til poster, individuelle felter og poster.
Tænk over dette i en meget enkel form. Lad os tale om bank- og formuestyring som et eksempel. Når du tilmelder dig en bankkonto, lad os bare sige en normal kontantkonto til et EFTPOS-kort, eller en kontantkonto eller en check-konto. Du udfylder en formular, og der er masser af meget private oplysninger i det stykke papir, som du udfylder, eller du gør det online, og det går ind i et computersystem. Nu, hvis nogen i marketing ønsker at kontakte dig og sende dig en brochure, skal de have tilladelse til at se dit fornavn og efternavn og din personlige adresse, f.eks. Og potentielt dit telefonnummer, hvis de vil kalde dig og sælge dig noget. De burde sandsynligvis ikke se det samlede beløb, du har i banken af mange grunde. Hvis nogen ser på dig fra et risikosynspunkt eller forsøger at hjælpe dig med at gøre noget som at få bedre renter på din konto, vil den pågældende person sandsynligvis se, hvor mange penge du har i banken, så de kan tilbyde dig det passende niveau for renteafkast på dine penge. Disse to individer har meget forskellige roller og meget forskellige grunde til disse roller og formål med disse roller. Som et resultat skal du se forskellige oplysninger i din post, men ikke alle posterne.
Disse kontroller omkring de forskellige rapporter om sædvanlige skærme eller formularer, som de har i de applikationer, der bruges til at administrere din konto. Udviklingen for dem, vedligeholdelsen af dem, administrationen af dem, rapporteringen omkring dem og styringen og overholdelsen indpakket omkring dem som bobleindpakning, er alle en meget, meget stor udfordring. Det er bare den største udfordring i styring af data og systemer. Når vi går dybere ned i denne stak til ydeevne og overvågning, og forekomstregistrering og -respons, styring og administration af systemet og overholdelse omkring dem, design og udvikling af systemerne fra overholdelsen, bliver det meget meget sværere.
Håndtering af hele spørgsmålet om reduktion af risici og forbedring af sikkerhed. Mine top fem udfordringer i dette rum - og jeg kan godt lide billedet, der følger med et toldsted, når du rejser ind i et land - de præsenterer dit pas, og de tjekker dig ud, og de ser på deres computersystem for at se, om du burde bestå eller ej. Hvis du ikke skulle gøre det, sætter de dig på det næste fly derhjemme. Ellers lader de dig komme ind igen, og de stiller dig spørgsmål som "Kommer du på ferie? Er du her turist? Er du her for arbejde? Hvilken slags arbejde vil du se? Hvor skal du bo "Hvor længe kommer du efter? Har du nok penge til at dække dine udgifter og omkostninger? Eller vil du blive en risiko for det land, du befinder dig i, og de er muligvis nødt til at passe dig og fodre dig?"
Der er nogle problemer omkring dette rum med data, styring af databeskyttelse. For eksempel i databasepladsen er vi nødt til at tænke på at afbøde databaseomkørsler. Hvis dataene findes i databasen, i et normalt miljø, og der er kontroller og mekanismer omkring det i systemet. Hvad sker der, hvis der dumpes data i mere SQL og sikkerhedskopieres til tape? Databaserne dumpes i rå form og sikkerhedskopieres nogle gange. Nogle gange gøres det af tekniske grunde, udviklingsårsager. Lad os bare sige, at der blev taget en DB-dump, og den er sikkerhedskopieret til tape. Hvad sker der, hvis jeg tilfældigvis får fat i det bånd og gendanner det? Og jeg har en rå kopi af databasen i SQL. Det er en MP-fil, det er tekst, jeg kan læse den. Alle de adgangskoder, der er gemt i denne dump, har ingen kontrol over mig, fordi jeg nu får adgang til det faktiske indhold af databasen uden databasemotoren, der beskytter den. Så jeg kan teknisk omgå sikkerheden på databaseplatformen, der er bygget i motoren med overholdelse, og risikostyring for at stoppe mig med at se på dataene. Fordi potentielt udvikleren, systemadministrator, har jeg fået hænderne på en fuld dump af databasen, der skal bruges til sikkerhedskopier.
Misbrug af dataene - potentielt få nogen til at logge ind som deres forhøjede konto og lade mig sidde ved skærmen, leder efter information eller lignende ting. Egen revision, adgangen til og brugen af dataene og visning af dataene eller ændringer af dataene. Derefter rapporteringen omkring denne kontrol og den krævede overholdelse. Overvågning af trafikken og adgangen osv., Blokerer trusler fra eksterne placeringer og servere. Hvis data for eksempel præsenteres via en formular på en webside på internettet, er deres SQL-injektioner blevet beskyttet gennem firewalls og konceptkontroller? Der er en lang detaljeret historie, der går bag dette. Du kan her se, at bare nogle af disse absolut grundlæggende ting, som vi tænker over til at afbøde og styre risiko omkring data i databaser. Det er faktisk relativt let at komme rundt på nogle af disse, hvis du er på forskellige niveauer af stabler af teknologierne. Udfordringen bliver sværere og sværere, når du får flere og flere data og flere databaser. Mere og mere udfordrende med folk, der er nødt til at styre systemerne og overvåge brugen af dem, spore de relevante detaljer, der specifikt angår ting, som Robin talte om, omkring ting som personlig overholdelse. Enkeltpersoner har kontroller og mekanismer omkring dem, der overholder - hvis du gør noget forkert, bliver du potentielt fyret. Hvis jeg logger ind som min konto, så kan du se det, burde det være en brandbar handling. Nu har jeg givet dig adgang til data, som du ikke burde have set normalt.
Der er personlig overholdelse, der er virksomhedsoverholdelse, virksomheder har politikker og regler og kontroller, som de har sat på sig selv, så virksomheden kører godt og giver et afkast på overskud og et godt afkast til investorer og aktionærer. Så er der ofte bydækkende eller statsdækkende eller nationale, føderale, som du sagde amerikanske kontroller og love. Så er der globale. Nogle af de større hændelser i verden, hvor ligesom Sarbanes-Oxley, to personer, der bliver bedt om at finde ud af, hvordan man beskytter data og systemer. Der er Basel i Europa, og der er en række kontroller i Australien, især omkring børs og legitimationsplatforme, og derefter privatliv på individuelt niveau eller virksomhedsniveau. Når hver af disse er stablet, som du så på et af de steder, som Robin havde, bliver de næsten et næsten umuligt bjerg at klatre. Omkostningerne bliver høje, og vi er på det punkt, hvor original, traditionel tilgang, du kender, ligesom mennesker, der måler kontrol, ikke længere er en passende tilgang, fordi skalaen er for stor.
Vi har et scenarie, hvor overholdelse er det, jeg kalder nu et altid problem. Og det var, at vi plejede at have et tidspunkt, enten hver måned eller kvartal eller årligt, hvor vi ville gennemgå vores nation og være med til at overholde og kontrollere. At sikre sig, at visse mennesker havde bestemt adgang og ikke havde bestemt adgang, afhængigt af hvad deres tilladelser var. Nu er det tale om hastigheden af tingene, som tingene bevæger sig med, det tempo, som tingene ændrer sig, skalaen, som vi arbejder på. Overholdelse er et altid problem, og den globale finanskrise var blot et eksempel, hvor de relevante kontroller og foranstaltninger inden for sikkerhed og overholdelse potentielt kunne have undgået et scenarie, hvor vi havde et løbsk godstog med bestemt opførsel. Bare at skabe en situation med hele verden effektivt ved at vide, at den ville gå i stykker og gå i konkurs. For at gøre det har vi brug for de rigtige værktøjer. At kaste mennesker på toget og kaste kroppe er ikke længere en gyldig tilgang, fordi skalaen er for stor, og tingene bevæger sig for hurtigt. Diskussionen i dag, tror jeg, vi vil have, handler om, hvilke typer værktøjer der skal anvendes til dette. Især de værktøjer, som IDERA kan give os, som skal gøre det. Og med det i tankerne vil jeg give det til Bullett at gå gennem hans materiale og vise os deres tilgang og de værktøjer, de har til at løse dette problem, som vi har stillet nu for dig.
Med det, Bullett, vil jeg give dig.
Bullett Manale: Det lyder godt, tak. Jeg vil tale om et par lysbilleder, og jeg vil også vise dig et produkt, som vi bruger til SQL Server-databaser specifikt til at hjælpe med overholdelsessituationer. Virkelig, udfordringen i mange tilfælde - jeg vil springe gennem et par af disse - dette er bare vores portefølje af produkter, jeg vil gennemgå det ret hurtigt. Når det gælder hvor dette produkt kommer til at adressere, og hvordan det relaterer til overholdelse, trækker jeg altid dette op som det første lysbillede, fordi det er en slags generisk, "Hej, hvad er en DBA's ansvar?" En af tingene styrer og overvåger brugeradgang og er også i stand til at generere rapporter. Det kommer til at binde sig sammen med, når du taler med din revisor, hvor vanskelig denne proces kan være, vil variere afhængigt af, om du vil gøre det på egen hånd, eller hvis du vil bruge en tredjepart værktøj til at hjælpe.
Generelt set, når jeg taler med databaseadministratorer, mange gange har de aldrig været involveret i en revision. Du er nødt til at uddanne dem til virkelig, hvad det er, du virkelig skal gøre. Relateret til hvilken type overholdelse, der skal udføres og være i stand til at bevise, at du faktisk følger reglerne, da de gælder for dette niveau af overholdelse. Mange mennesker får det ikke til at begynde med. De tænker, "Åh, jeg kan bare købe et værktøj, der gør mig kompatibel." Virkeligheden er, at det ikke er tilfældet. Jeg ville ønske, at jeg kunne sige, at vores produkt magisk, ved du ved at trykke på den lette knap, gav dig muligheden for at sikre dig, at du overholder. Virkeligheden er, at du skal have dit miljø oprettet med hensyn til kontrollerne, hvad angår hvordan folk får adgang til dataene, at alt skal udarbejdes med den applikation, du har. Hvor der er følsomme data, der gemmes, hvilken type lovkrav er det. Derefter også at skulle arbejde med typisk en intern overholdelsesansvarlig for at være i stand til at sikre dig, at du følger alle reglerne.
Dette lyder virkelig kompliceret. Hvis du ser på alle lovgivningsmæssige krav, ville du tro, at det ville være tilfældet, men virkeligheden er, at der er en fællesnævner her. I vores tilfælde med det værktøj, som jeg vil vise dig i dag, Compliance Manager-produktet, ville processen i vores situation være, at vi først og fremmest er nødt til at sikre os, at vi samler data om revisionsspor, relateret hvor dataene er i databasen, der er følsom. Du kan samle alt, ikke? Jeg kunne gå ud og sige, at jeg vil samle alle transaktioner, der sker i denne database. Realiteten er, at du sandsynligvis kun har en lille brøkdel eller en lille procentdel af transaktioner, der faktisk er relateret til de følsomme data. Hvis det er PCI-overholdelse, vil det være omkring kreditkortoplysningerne, ejerne af kreditkortene og deres personlige oplysninger. Der kan være et væld af andre transaktioner, da det vedrører din ansøgning, som ikke rigtig har nogen betydning for PCI-lovgivningen.
Fra det synspunkt er den første ting, når jeg taler med DBA, at jeg siger: ”Den største udfordring prøver ikke at få et værktøj til at gøre disse ting for dig. Det er bare at vide, hvor er de følsomme data, og hvordan låser vi disse data? ”Hvis du har det, hvis du kan besvare det spørgsmål, så er du halvvejs hjemme i form af at kunne vise, at du overholder, forudsat at du følger de rigtige kontroller. Lad os sige et øjeblik, at du følger de rigtige kontroller, og du fortalte revisorerne, at det er tilfældet. Den næste del af processen er åbenlyst, at det er muligt at levere et revisionsspor, der viser og validerer, at disse kontroller faktisk fungerer. Derefter følges op med at sikre dig, at du gemmer disse data. Normalt med ting som PCI og HIPAA-overholdelse, og disse typer ting, taler du syv års værdi for tilbageholdelse. Du taler om en masse transaktioner og en masse data.
Hvis du holder, og indsamler hver transaktion, selvom kun fem procent af transaktionerne er relateret til de følsomme data, taler du om en temmelig stor omkostning forbundet med at skulle gemme disse data i syv år. Det er en af de største udfordringer, tror jeg, er at få folks hoved rundt om at sige, det er en virkelig unødvendig omkostning, åbenbart. Det er også meget lettere, hvis vi bare kan fokusere granulært på de følsomme områder i databasen. Derudover vil du også gerne have kontrol over nogle af de følsomme oplysninger. Ikke kun for at vise i form af en revisionsspor, men også at kunne binde tingene tilbage til handlinger, der sker, og være i stand til at blive underrettet i realtid, så du kan blive opmærksom på det.
Eksemplet bruger jeg altid, og det er muligvis ikke nødvendigvis relateret til nogen form for forskriftsmæssigt krav, men bare at være i stand til at spore, for eksempel skulle nogen droppe tabellen, der er knyttet til lønningslisten. Hvis det sker, er den måde, du finder ud af det på, hvis du ikke sporer det, ingen betalt. Det er for sent. Du vil vide, hvornår tabellen bliver tabt, lige når den falder, for at undgå dårlige ting, der sker som et resultat af, at en utilfredse medarbejder går og sletter tabellen, der er bundet direkte til lønningslisten.
Med det sagt er tricket at finde den fælles nævner eller bruge den fælles nævner til at kortlægge, hvad niveauet for overholdelse er. Det er slags, hvad vi forsøger at gøre med dette værktøj. Vi tager dybest set den tilgang, vi vil ikke vise dig en rapport, der er specifik for PCI, specifik for aktier; fællesnævneren er, at du har et program, der bruger SQL Server til at gemme de følsomme data i databasen. Når du først er kommet over, siger du: "Ja, det er virkelig den vigtigste ting, vi har brug for at fokusere på - hvor er de følsomme data, og hvordan får man adgang til dem?" Når du først har det, er der masser af rapporter, som vi tilbyder, der kan give beviset, at du er inden for overholdelse.
Når vi vender tilbage til de spørgsmål, der stilles af en revisor, vil det første spørgsmål være: Hvem har adgang til dataene, og hvordan får de adgang? Kan du bevise, at de rigtige personer får adgang til dataene, og at de forkerte mennesker ikke er det? Kan du også bevise, at selve revisionssporet er noget, som jeg kan stole på som en uforanderlig informationskilde? Hvis jeg giver dig et revisionsspor, der er fremstillet, gør det mig ikke rigtig godt som revisor at lappe din revision, hvis oplysningerne er fremstillet. Vi har brug for bevis på det, typisk set fra et revisionsperspektiv.
Går gennem disse spørgsmål, lidt mere detaljeret. Udfordringen med det første spørgsmål er, du skal vide, som jeg sagde, hvor de følsomme data er for at rapportere, hvem der får adgang til dem. Det er normalt en slags opdagelse, og virkelig har du tusinder af forskellige applikationer der er derude, du har mange forskellige lovgivningsmæssige krav. I de fleste tilfælde ønsker du at arbejde med din compliance officer, hvis du har en eller i det mindste nogen, der vil have en vis yderligere indsigt i forhold til hvor mine følsomme data er inden for applikationen. Vi har et værktøj, som vi har, det er et gratis værktøj, det kaldes en SQL Column Search. Vi fortæller vores potentielle kunder og brugere, der er interesseret i det spørgsmål, de kan hente det. Hvad det vil gøre, er at det dybest set kigger efter informationerne i databasen, der sandsynligvis vil være følsom.
Og så når du først har gjort det, skal du også forstå, hvordan folk får adgang til disse data. Og det bliver endnu engang, hvilke konti der er inden for hvilke Active Directory-grupper, hvilke databasebrugere er involveret, der er en rollemedlemskab, der er knyttet til dette. Og husk naturligvis, at alle disse ting, som vi taler om, skal godkendes af revisoren, så hvis du siger, "Sådan låser vi dataene op, " så kan revisorerne komme tilbage og sige, "Nå, du gør det forkert." Men lad os sige, at de siger, "Ja, det ser godt ud. Du låser dataene tilstrækkeligt. ”
Går du videre til det næste spørgsmål, som bliver, kan du bevise, at de rigtige personer får adgang til disse data? Med andre ord kan du fortælle dem, at dine kontroller er, dette er de kontroller, du følger, men desværre er revisorerne ikke reelle tillidsfulde enkeltpersoner. De vil have bevis på det, og de vil være i stand til at se det inden for revisionssporet. Og dette går tilbage til hele den fællesnævner ting. Uanset om det er PCI, SOX, HIPAA, GLBA, Basel II, uanset hvad, virkeligheden er, er, at de samme typer spørgsmål typisk vil blive stillet. Objektet med de følsomme oplysninger, hvem har adgang til dette objekt inden for den sidste måned? Det skulle kortlægge mine kontroller, og jeg skulle til sidst kunne videregive min revision ved at vise disse typer rapporter.
Og hvad vi har gjort, er, at vi har samlet omkring 25 forskellige rapporter, der følger på de samme slags områder som den fællesnævner. Så vi har ikke en rapport til PCI eller til HIPAA eller til SOX, vi har rapporter om, at de endnu en gang går imod den fælles nævner. Og så betyder det ikke rigtigt, hvilket lovkrav du prøver at opfylde, i de fleste tilfælde vil du være i stand til at besvare det spørgsmål, som denne revisor stiller dig. Og de vil fortælle dig, hvem, hvad, hvornår og hvor af hver transaktion. Du ved, brugeren, det tidspunkt, hvor transaktionen fandt sted, selve SQL-erklæringen, det program, det kom fra, alt det gode, og derefter også være i stand til at automatisere levering af disse oplysninger til rapporter.
Og så igen, når du kommer forbi det, og du har givet det til revisoren, så skal det næste spørgsmål bevise det. Og når jeg siger at bevise det, mener jeg at bevise, at selve revisionssporet er noget, vi kan stole på. Og måden vi gør det på i vores værktøj er, at vi har hashværdier og CRC-værdier, der binder direkte tilbage til begivenhederne i revisionssporet. Og så er tanken, at hvis nogen går ud og sletter en post, eller hvis nogen går ud og fjerner eller tilføjer noget til revisionssporet eller ændrer noget i selve revisionssporet, kan vi bevise, at disse data, integriteten af selve dataene blev overtrådt. Og så 99, 9 procent af tiden, hvis du har vores revisionsspor-database låst, vil du ikke løbe ind i det problem, fordi når vi kører denne integritetskontrol, beviser vi i virkeligheden overfor revisoren, at selve dataene ikke har været ændret og slettet eller tilføjet siden den oprindelige skrivning fra selve managementtjenesten.
Så det er en generel oversigt over de typiske slags spørgsmål, som du vil blive stillet. Nu kaldes det værktøj, vi er nødt til at tackle meget af dette, SQL Compliance Manager, og det gør alle disse ting med hensyn til sporing af transaktionerne, hvem, hvad, hvornår og hvor af transaktionerne, at være i stand til at gøre det i en antal forskellige områder også. Login, mislykkede login, skemaændringer, åbenbart datatilgang, vælg aktivitet, alle de ting, der sker inden i databasemotoren. Og vi er også i stand til at advare brugerne om specifikke, meget kornede forhold, om nødvendigt. For eksempel er der nogen, der går ud og faktisk ser tabellen, der indeholder alle mine kreditkortnumre. De ændrer ikke dataene, de ser bare på dem. I den situation kan jeg advare, og jeg kan fortælle folk, at det sker, ikke seks timer senere, når vi skraber logfiler, men i realtid. Det er dybest set, så længe det tager for os at behandle denne transaktion gennem en managementtjeneste.
Som jeg nævnte før, har vi set dette brugt i en række forskellige lovgivningsmæssige krav, og det gør det ikke - du ved, ethvert lovkrav, endnu en gang, så længe fællesnævnerne, har du følsomme data i en SQL Server database, dette er et værktøj, der kan hjælpe i den type situation. For de 25 rapporter, der er indbygget, er nu virkeligheden, at vi kan gøre dette værktøj godt for revisoren og besvare hvert eneste spørgsmål, de stiller, men DBA'erne er dem, der skal få det til at fungere. Så der er også det at tænke på, ved du godt, fra et vedligeholdelsesperspektiv er vi nødt til at sikre, at SQL fungerer som vi ønsker. Vi må også være i stand til at gå ind og se på de ting, der vil være i stand til at gå ud og se på andre oplysninger, du ved, så vidt angår arkivering af data, automatisering af det og overhead selve produktet. Det er ting, som vi naturligvis tager højde for.
Hvilket bringer selve arkitekturen op. Så på højre side af skærmen har vi forekomsterne af SQL, som vi administrerer, alt fra 2000 helt op til 2014, og gør os klar til at frigive en version til 2016. Den største afhentning på denne skærm er, at ledelsen serveren selv gør alt det tunge løft. Vi samler bare dataene ved hjælp af trace API, indbygget med SQL Server. Disse oplysninger løber op til vores administrationsserver. Denne management-server i sig selv identificerer, og hvis der er begivenheder, der er knyttet til nogen form for transaktioner, som vi ikke ønsker, udsendelse af advarsler og den slags ting og derefter udfyldes dataene i et depot. Derfra kan vi køre rapporter, vi ville være i stand til at gå ud og faktisk se disse oplysninger i rapporterne eller endda inden for programmets konsol.
Så hvad jeg vil gå videre og gøre er, at jeg vil tage os igennem, virkelig hurtigt, og jeg vil bare påpege en hurtig ting, før vi hopper ind i produktet, der er et link på webstedet lige nu, eller på præsentationen, vil det føre dig til det gratis værktøj, som jeg nævnte tidligere. Det gratis værktøj er, som sagt, det vil gå ud og se på en database og forsøge at finde de områder, der ligner følsomme data, personnummer, kreditkortnumre, baseret på navnene på kolonnerne eller tabellerne, eller baseret på den måde, dataformatet ser ud på, og du kan også tilpasse det, så bare for at påpege det.
Lad mig nu i vores tilfælde gå videre og dele min skærm, giv mig et sekund her. Okay, og så, hvad jeg ønskede at tage dig til først, er, at jeg vil tage dig til selve Compliance Manager-applikationen, og jeg vil gennemgå dette temmelig hurtigt. Men dette er applikationen, og du kan se, at jeg har et par databaser her, og jeg vil bare vise dig, hvor let det er at gå ind og fortælle det, hvad du ønsker at revidere. Set fra skemaændringer, sikkerhedsændringer, administrative aktiviteter, DML, Vælg, har vi alle disse muligheder tilgængelige for os, vi kan også filtrere det ned. Dette går tilbage til den bedste praksis med at kunne sige, ”Jeg har virkelig kun brug for denne tabel, fordi den indeholder mine kreditkortnumre. Jeg har ikke brug for de andre tabeller, der har produktinformation, alle de andre ting, der ikke er i forhold til niveauet for overholdelse, jeg prøver at opfylde. ”
Vi har også evnen til at fange data og vise dem i form af værdierne på de felter, der ændrer sig. I mange værktøjer har du noget, der giver dig muligheden for at fange SQL-sætningen, vise brugeren, vise applikationen, tid og dato, alt det gode. Men i nogle tilfælde vil SQL-sætningen ikke give dig nok information til at kunne fortælle dig, hvad værdien af feltet var, før ændringen skete, samt værdien af feltet efter ændringen skete. Og i nogle situationer har du brug for det. Jeg vil måske spore for eksempel en læges doseringsinformation til receptpligtige lægemidler. Det gik fra 50 mg til 80 mg til 120 mg, det kunne jeg spore ved hjælp af før og efter.
Følsomme kolonner er en anden ting, som vi støder på meget for eksempel med PCI-overholdelse. I situationen her har du data, der er så følsomme, at jeg bare ved at se på disse oplysninger ikke behøver at ændre dem, slette dem eller tilføje dem, jeg kan forårsage uoprettelig skade. Kreditkortnumre, personnummer, alt det slags gode ting, vi kan identificere følsomme kolonner og binde alarmer til det. Hvis nogen går ud og ser på disse oplysninger, ville vi selvfølgelig være i stand til at advare og sende en e-mail eller generere en SNMP-fælde og den slags ting.
I nogle tilfælde kommer du nu i en situation, hvor du måske har en undtagelse. Og hvad jeg mener med det, du har en situation, hvor du har en bruger, der har en brugerkonto, der muligvis er knyttet til en slags ETL-job, der kører midt på natten. Det er en dokumenteret proces, og jeg behøver simpelthen ikke at medtage de transaktionsoplysninger til den brugerkonto. I dette tilfælde ville vi have en betroet bruger. Og så i andre situationer ville vi bruge funktionen Privileged User Auditing, som i det væsentlige er, hvis jeg har, lad os sige for eksempel et program, og det program allerede foretager revision af de brugere, der gennemgår applikationen, det er fantastisk, jeg har allerede noget at henvise til i forbindelse med min revision. Men for de ting, der er knyttet til, for eksempel mine privilegerede brugere, fyre, der kan gå ind i SQL Server-administrationsstudie for at se på dataene i databasen, vil de ikke skære dem ned. Og det er her vi kunne definere, hvem vores privilegerede brugere er, enten gennem rollemedlemmer eller gennem deres Active Directory-konti, grupper, deres SQL-godkendte konti, hvor vi kan vælge alle disse forskellige typer muligheder og derefter derfra sørg for, at for de privilegerede brugere kan vi specificere de typer transaktioner, vi er interesseret i at revidere.
Dette er alle slags forskellige muligheder, som du har, og jeg vil ikke gennemgå alle de forskellige slags typer ting baseret på tidsbegrænsningerne her for denne præsentation. Men jeg vil gerne vise dig, hvordan vi kan se dataene, og jeg tror, du kan lide, hvordan dette fungerer, fordi der er to måder, vi kan gøre det på. Jeg kan gøre det interaktivt, og så når vi taler med mennesker, der er interesseret i dette værktøj til måske deres egen interne kontrol, vil de bare vide, hvad der foregår i mange tilfælde. De har ikke nødvendigvis revisorer der kommer på stedet. De vil bare vide, ”Hej, jeg vil følge denne tabel og se, hvem der har rørt den i den sidste uge eller sidste måned eller hvad der måtte være.” I dette tilfælde kan du se, hvor hurtigt vi kan gøre det.
Hvad angår databasen for sundhedsvæsenet, har jeg en tabel kaldet Patientjournaler. Og den tabel, hvis jeg bare skulle gruppere efter objekt, kunne det meget hurtigt begynde at indsnævre, hvor vi leder efter. Måske vil jeg gruppere efter kategori og derefter måske efter begivenhed. Og når jeg gør det, kan du se, hvor hurtigt det dukker op, og der er min patientjournal-tabel lige der. Og når jeg borer ind, kan vi nu se DML-aktiviteten, kan vi se, at vi har haft tusind indsæt DML, og når vi åbner en af disse transaktioner, kan vi se de relevante oplysninger. Hvem, hvad, hvornår, hvor transaktion hvor, SQL-sætning, åbenbart, den faktiske applikation, der bruges til at udføre transaktionen, kontoen, tidspunktet og datoen.
Hvis du nu ser på den næste fane herover, fanen Detaljer, går dette tilbage til det tredje spørgsmål, vi snakker om, hvilket beviser, at dataenes integritet ikke er blevet overtrådt. Så dybest set hver begivenhed, vi har en hemmelig beregning af vores hashværdi, og dette vil derefter binde sig tilbage til, når vi foretager vores integritetscheck. For eksempel, hvis jeg skulle gå ud til værktøjet, gå ind i revisionsmenuen, og jeg skulle gå ud og sige, lad os tjekke depotens integritet, kunne jeg pege på den database, hvor revisionssporet er, det kører gennem en integritetskontrol, der matcher disse hashværdier og CRC-værdier til de faktiske begivenheder, og det vil fortælle os, at der ikke er fundet nogen problemer. Med andre ord er der ikke blevet manipuleret med dataene i revisionssporet, da de oprindeligt blev skrevet af managementtjenesten. Det er åbenlyst en måde at interagere med dataene på. Den anden måde ville være gennem selve rapporterne. Og så vil jeg bare give dig et hurtigt eksempel på en rapport.
Og endnu en gang er disse rapporter, som vi kom frem til dem, ikke specifikke for nogen form for standard som PCI, HIPAA, SOX eller noget lignende. Endnu en gang er det fællesnævneren for hvad vi laver, og i dette tilfælde, hvis vi går tilbage til dette patientjournaleksempel, ville vi være i stand til at gå ud og sige, i vores tilfælde her, ser vi i databasen for sundhedsvæsenet, og i vores tilfælde ønsker vi at fokusere specifikt på den tabel, som vi ved indeholder private oplysninger, i vores tilfælde relateret til vores patienter. Og så, lad mig se, om jeg kan skrive den her, og vi vil fortsætte med at køre rapporten. Og vi vil naturligvis se derfra alle relevante data, der er knyttet til dette objekt. Og i vores tilfælde viser det os i en måneds periode. Men vi kunne gå tilbage seks måneder, et år, uanset hvor længe vi har opbevaret dataene i.
Det er den slags måder, som du faktisk kunne bevise, hvis du vil, overfor revisoren, at du følger dine kontroller. Når du først har identificeret det, er det naturligvis en god ting med hensyn til at bestå din revision og være i stand til at vise, at du følger kontrollerne og alt fungerer.
Den sidste ting at tale om, som jeg ønskede at demonstrere, er i administrationsafsnittet. Der er også kontroller set ud fra dette værktøj i at være i stand til at indstille kontroller for at være i stand til at sikre, at hvis nogen gør noget, som de ikke skal gøre, kan jeg blive opmærksom på det. Og jeg vil give dig et par eksempler der. Jeg har en login-konto, der er knyttet til en tjeneste, og som tjenesten har brug for forhøjede tilladelser for at gøre, hvad den gør. Det, jeg ikke ønsker, er, at nogen går ind og bruger den konto i Management Studio, og bruger du den til ting, som den ikke var beregnet til. Vi vil have to kriterier her, som vi kunne anvende. Jeg kunne sige, ”Se, vi er virkelig interesseret i at dette fungerer, siger vi med vores PeopleSoft-applikation, ” bare som et eksempel, okay?
Nu som jeg har gjort det, hvad jeg siger her, er jeg nysgerrig efter at kende alle logins, der er knyttet til den konto, jeg er klar til at specificere, hvis applikationen, der bruges til at logge ind med denne konto er ikke PeopleSoft, så vil det være en stigning i alarmen. Og selvfølgelig er vi nødt til at specificere selve kontonavnet, så i vores tilfælde skal vi bare kalde denne Priv-konto, for det faktum, at det er privilegeret. Når vi først har gjort det, når vi gør dette her, vil vi nu kunne specificere, hvad vi vil have, der skal ske, når dette sker, og for hver eneste type begivenhed, eller jeg skal sige, opmærksom, kan du have en separat anmeldelse til den person, der er ansvarlig for det bestemte stykke data.
For eksempel, hvis det er lønoplysninger, kan det gå til min direktør for HR. I dette tilfælde, der handler med PeopleSoft-applikationen, bliver det administratoren af denne applikation. Uanset hvad der er tilfældet. Jeg ville være i stand til at indsætte min e-mail-adresse, tilpasse den faktiske alarmmeddelelse og al den slags gode ting. Endnu en gang går dette tilbage til at være i stand til at sikre dig, at du kan vise, at du følger dine kontroller, og at disse kontroller fungerer som de er beregnet til. Fra det sidste perspektiv her, bare med hensyn til vedligeholdelse, har vi evnen til at tage disse data og sætte dem offline. Jeg kan arkivere dataene, og jeg kan planlægge dem, og vi ville være i stand til slags at gøre disse ting meget let i den forstand, at du faktisk ville være i stand til, som en DBA, der bruger dette værktøj, opsæt det og slags gå væk fra det. Der er ikke en masse håndholdelse, der finder sted, når du har sat den op, som den skal være. Som jeg sagde, den sværeste del af noget af dette, synes jeg, er ikke at oprette det, du vil have revision, men det er at vide, hvad du vil oprette til revision.
Og som sagt, dyrets art med revision, skal du opbevare dataene i syv år, så det giver kun mening at fokusere på de områder, der er følsomme i naturen. Men hvis du vil gå ind i indsamlingen af alt, kan du absolut, det er bare ikke betragtet som den bedste praksis. Så fra dette synspunkt vil jeg gerne minde folk om, at hvis dette er noget, der er af interesse, kan du gå ind på webstedet på IDERA.com og downloade en prøveversion af dette og lege med det selv. Med hensyn til det gratis værktøj, som vi talte om tidligere, er det, ja, det er gratis. Du kan downloade det og bruge det for evigt, uanset om du bruger Compliance Manager-produktet. Og den seje ting ved det kolonnesøgningsværktøj er, at vores fund, som du kommer frem til, og jeg faktisk kan vise, at jeg tror, er, at du vil være i stand til at eksportere disse data og derefter være i stand til at importere dem til Compliance Manager såvel. Jeg kan ikke se det, jeg ved, at det er her, der er det. Dette er bare et eksempel på det. Det er her det finder de relaterede følsomme data.
Nu er denne sag gået ud, og jeg har virkelig kigget på alting, men du har bare et væld af ting, som vi kan tjekke efter. Kreditkortnumre, adresser, navne, alle den slags ting. Og vi identificerer, hvor det er i databasen, og derefter derfra kan du tage beslutningen om, hvorvidt du rent faktisk ønsker at revidere disse oplysninger. Men det er bestemt en måde at gøre det meget lettere for dig at definere dit omfang af revision, når du ser på et værktøj som dette.
Jeg vil bare gå foran og lukke med det, og jeg vil gå videre og videregive det til Eric.
Eric Kavanagh: Det er en fantastisk præsentation. Jeg elsker den måde, du virkelig får ind i de grimme detaljer der og viser os, hvad der foregår. Fordi i slutningen af dagen er der et system, der får adgang til nogle poster, det vil give dig en rapport, det vil få dig til at fortælle din historie, hvad enten det drejer sig om en regulator eller en revisor eller nogen i dit team, så det er godt, at du ved, at du er forberedt på, om og hvornår, eller som og hvornår, den person kommer bankende, og det er selvfølgelig den ubehagelige situation, du prøver at undgå. Men hvis det sker, og det sandsynligvis vil ske i disse dage, vil du være sikker på, at du har dine I-punkter og dine T's krydset.
Der er et godt spørgsmål fra et publikummedlem, jeg vil smide ud til måske dig først, Bullett, og så hvis en præsentant måske ønsker at kommentere det, så føl dig fri. Og så kan Dez måske stille et spørgsmål og Robin. Så spørgsmålet er, er det rimeligt at sige, at for at gøre alle de ting, som du har nævnt, skal du starte en indsats med dataklassificering på et elementært niveau? Du skal kende dine data, når de fremstår som et værdifuldt potentielt aktiv og gøre noget ved det. Jeg tror, du ville være enig, Bullett, ikke?
Bullett Manale: Ja, absolut. Jeg mener, du er nødt til at kende dine data. Og jeg er klar over, jeg anerkender, at der er en masse applikationer, der er derude, og at der er en masse forskellige ting, der har bevægelige dele i din organisation. Kolonnesøgningsværktøjet er meget nyttigt med hensyn til at gå et skridt i retning af at forstå disse data bedre. Men ja, det er meget vigtigt. Jeg mener, du har muligheden for at gå i brandslangetilstanden og kontrollere alt, men det er bare meget mere udfordrende på den måde logistisk, når du taler om at skulle gemme disse data og rapportere mod disse data. Og så har du stadig et behov for at vide, hvor det stykke data er, for når du kører dine rapporter, skal du også vise dine revisorer disse oplysninger. Så jeg tror, som jeg sagde, den største udfordring, når jeg taler med databaseadministratorer, er at vide, ja.
Eric Kavanagh: Ja, men måske skal vi bringe Robin hurtigt ind. Det forekommer mig, at 80/20-reglen gælder her, ikke? Du finder sandsynligvis ikke ethvert postsystem, der betyder noget, hvis du er i en mellemstor eller stor organisation, men hvis du fokuserer på - som Bullett foreslog her - for eksempel PeopleSoft eller andre postsystemer, der er fremherskende i virksomheden, det er her, du fokuserer 80 procent af din indsats, og så er 20 procent på de andre systemer, der muligvis er derude et eller andet sted, ikke?
Robin Bloor: Jeg er sikker, ja. Jeg mener, du ved, jeg tror, problemet med denne teknologi, og jeg synes, det er sandsynligvis værd at have en kommentar til det, men problemet med denne teknologi er, hvordan implementerer du det? Jeg mener, der er meget bestemt mangel på viden, lad os sige, i de fleste organisationer med hensyn til endda antallet af databaser, der er derude. Du ved, der er meget frygtelig mangel på lager, lad os sige. Du ved, spørgsmålet er, lad os forestille os, at vi starter i en situation, hvor der ikke er en særlig velstyret overensstemmelse, hvordan tager du denne teknologi og sprøjter den ind i miljøet, ikke kun i, du ved, teknologi vilkår, opsætning af ting, men som hvem der administrerer det, hvem bestemmer hvad? Hvordan begynder du at skøre dette til en ægte ting, der gør sit job?
Bullett Manale: Det mener jeg godt, det er et godt spørgsmål. Udfordringen i mange tilfælde er, at jeg mener, du er nødt til at begynde at stille spørgsmålene lige i starten. Jeg har løbet ind i en masse virksomheder, hvor de, du ved, måske de er et privat firma, og de blev erhvervet, der er en indledende, slags, første, slags vejstød, hvis du vil kalde det sådan. For eksempel, hvis jeg lige nu er blevet et børsnoteret selskab på grund af overtagelsen, bliver jeg nødt til at gå tilbage og sandsynligvis finde ud af noget.
Og i nogle tilfælde taler vi med organisationer, som du ved, selvom de er private, de følger SOX-overholdelsesreglerne, simpelthen fordi i tilfælde af at de ønsker at blive erhvervet, ved de, at de skal overholde. Du ønsker bestemt ikke at tage fremgangsmåden til bare "Jeg behøver ikke at bekymre dig om dette nu." Enhver form for lovgivningsmæssig overholdelse som PCI eller SOX eller hvad som helst, du ønsker at investere i at udføre forskningen eller forståelse for, hvor de følsomme oplysninger er, ellers finder du måske dig selv at håndtere nogle betydelige, heftige bøder. Og det er meget bedre bare at investere den tid, ved du, finde de data og være i stand til at rapportere imod dem og vise kontrollerne fungerer.
Ja, hvad angår opsætning af det, som jeg sagde, er den første ting, jeg vil anbefale til folk, der er klar til at møde en revision, bare at gå ud og foretage en kortvarig undersøgelse af databasen og finde ud af, du ved i deres bedste indsats at prøve at finde ud af, hvor de følsomme data er. Og den anden tilgang ville være at starte med måske et større net med hensyn til, hvad omfanget af revision er, og derefter langsomt bremse din vej ned, når du, slags, finder ud af, hvor de områder i systemet er der er relateret til følsom information. Men jeg ville ønske, at jeg kunne fortælle dig, at der er et let svar på det spørgsmål. Det vil sandsynligvis variere en smule fra den ene organisation til den anden og typen af overholdelse og virkelig hvordan, du ved, hvor meget struktur de har inden for deres applikationer og hvor mange har, forskellige applikationer, de har, nogle kan være specialskrivede applikationer, så det kommer virkelig til at afhænge af situationen i mange tilfælde.
Eric Kavanagh: Gå videre, Dez, jeg er sikker på, at du har et spørgsmål eller to.
Dez Blanchfield: Jeg er meget interesseret i at bare få noget indblik i dine observationer omkring indvirkningen på organisationerne fra et folks synspunkt, faktisk. Jeg tror, et af de områder, hvor jeg ser den største værdi for netop denne løsning, er, at når folk vågner op om morgenen og går på arbejde på forskellige niveauer i organisationen, vågner de op med en række eller en kæde af ansvar som de har at gøre med. Og jeg er ivrig efter at få en vis indsigt i, hvad du ser derude med og uden de typer værktøjer, du taler om. Og den kontekst, jeg taler om her, er fra formand for bestyrelsesniveau til CEO og CIO og C-suite. Og nu har vi vigtigste risikobetjente, der tænker mere på de typer ting, vi taler om her i overensstemmelse og regeringsførelse, og så har vi nu fået nye rollespidschefer, chefdatamanister, hvem der er, du ved, endnu mere bekymret over det.
Og på siden af hver af dem, omkring CIO, har vi IT-ledere på den ene side med, slags du ved, tekniske kundeemner og derefter databaselinier. Og i det operationelle rum har vi udviklingsledere og udviklingsledere og derefter individuel udvikling, og de looper også tilbage i databaseadministrationslaget. Hvad ser du omkring reaktionen fra hver af disse forskellige dele af virksomheden på udfordringen med overholdelse og lovgivningsmæssig rapportering og deres tilgang til det? Ser du, at folk kommer på dette med en inderlighed og kan se fordelen ved det, eller ser du, at de modvilligt trækker deres fødder til denne ting og bare, ved du, gør det for et kryds i boksen? Og hvad er de slags svar, du ser, når de ser din software?
Bullett Manale: Ja, det er et godt spørgsmål. Jeg vil sige, at dette produkt, salget af dette produkt, stort set er drevet af nogen, der sidder i det varme sæde, hvis det giver mening. I de fleste tilfælde er det DBA, og fra vores perspektiv ved de med andre ord, at der kommer en revision, og de vil være ansvarlige, fordi de er DBAerne, for at kunne give de oplysninger, som revisor vil spørge. Det kan de gøre ved at skrive deres egne rapporter og oprette deres egne tilpassede spor og alle disse slags ting. Virkeligheden er, at de ikke ønsker at gøre det. I de fleste tilfælde ser DBA'er ikke rigtig frem til at have disse samtaler med revisor til at begynde med. Du ved, jeg vil hellere fortælle dig, at vi kan gå til et firma og sige, "Hej, dette er et godt værktøj, og du vil elske det, " og vise dem alle de funktioner, og de vil købe det.
Virkeligheden er, at de typisk ikke vil se på dette værktøj, medmindre de rent faktisk vil blive konfronteret med en revision, eller den anden side af denne mønt er, at de har haft en revision og fejlet den elendigt, og nu er de bliver bedt om at få hjælp eller ellers bliver de bøder. Jeg vil sige, at når man viser dette produkt til folk, når man viser dette produkt til mennesker, ser de bestemt værdien af det, fordi det sparer dem masser af tid med hensyn til at skulle finde ud af, hvad de vil rapportere om, den slags ting. Alle disse rapporter er allerede indbygget, alarmeringsmekanismerne er på plads, og med det tredje spørgsmål kan det også i mange tilfælde være en udfordring. Fordi jeg kan vise dig rapporter hele dagen, men medmindre du kan bevise for mig, at disse rapporter faktisk er gyldige, ved du, det er meget hårdere forslag for mig som DBA at kunne vise det. Men vi har udarbejdet teknologien og hashing-teknikken og alle disse slags ting for at være i stand til at sikre, at dataene i deres integritet af revisionssporene opbevares.
Og så det er de ting, det er mine iagttagelser med hensyn til de fleste af de mennesker, vi snakker med. Du ved, der er bestemt, i forskellige organisationer, du ved, du vil høre om, du ved ligesom, mål, for eksempel havde et dataovertrædelse, og du ved, jeg mener, når andre organisationer hører om bøder og disse slags ting folk starter, det hæver et øjenbryn, så forhåbentlig svarer det på spørgsmålet.
Dez Blanchfield: Ja, bestemt. Jeg kan forestille mig nogle DBA'er, når de endelig ser, hvad der kan gøres med værktøjet, bare er klar over, at de også har deres sene nætter og weekender tilbage. Tids- og omkostningsreduktioner og andre ting, jeg ser, når de passende værktøjer anvendes til hele dette problem, og det er, tre uger sad jeg med en bank her i Australien. De er en global bank, en top-tre-bank, de er massive. Og de havde et projekt, hvor de var nødt til at rapportere om deres overholdelse af velstand og især risiko, og de så på 60 ugers arbejde værd for et par hundrede mennesker. Og da de fik vist et lignende værktøj som dig selv, der bare kunne automatisere processen, denne sans, udseendet på deres ansigter, da de indså, at de ikke skulle bruge X antal uger med hundreder af mennesker, der lavede en manuel proces, var sådan som de havde fundet Gud. Men den udfordrende ting var, hvordan man rent faktisk sætter det i plan, som Dr. Robin Bloor antydede, du ved, at dette er noget, der bliver en blanding af adfærdsmæssigt, kulturelt skift. På de niveauer, du har at gøre med, og som håndterer dette direkte på applikationsniveau, hvilken type ændring ser du, når de begynder at indføre et værktøj til at udføre den slags rapportering og revision og kontroller, du kan tilbyde, som i modsætning til hvad de muligvis har gjort manuelt? Hvordan ser det ud, når de rent faktisk bruges?
Bullett Manale: Spørger du, hvad er forskellen med hensyn til håndtering af dette manuelt kontra brug af dette værktøj? Er det spørgsmålet?
Dez Blanchfield: Nå, specifikt virkningen af virksomheden. Så hvis vi for eksempel forsøger at levere overensstemmelse i en manuel proces, ved du, tager vi altid lang tid med en masse mennesker. Men jeg gætte, for at sætte en vis kontekst omkring spørgsmålet, som du ved, taler vi om en enkelt person, der kører dette værktøj, der erstatter potentielt 50 personer, og kan gøre det samme i realtid eller i timer kontra måneder? Er den slags, hvad viser det sig generelt at være?
Bullett Manale: Jeg mener, det kommer ned på et par ting. Den ene er at have evnen til at besvare disse spørgsmål. Nogle af disse ting bliver ikke gjort meget let. Så ja, den tid det tager at udføre tingene hjemmearbejdet, at skrive rapporterne på egen hånd, at opsætte sporene eller de udvidede begivenheder for at indsamle data manuelt, kan tage meget tid. Virkelig, jeg vil give dig nogle, jeg mener, dette har ikke rigtig forbindelse til databaser generelt, men ligesom lige efter at Enron skete og SOX blev udbredt, var jeg hos et af de større olieselskaber i Houston, og vi regnede med, Jeg tror, det var som om 25 procent af vores forretningsomkostninger var relateret til SOX-overholdelse.
Nu var det lige efter, og det var slags det første første skridt hos SOX, men tinget med, jeg vil sige, ved du, du får en masse fordel ved at bruge dette værktøj i den forstand, at det ikke kræver meget af mennesker til at gøre dette og en masse forskellige typer mennesker til at gøre det. Og som sagt, DBA er ikke typisk den fyr, der virkelig ser frem til at have disse samtaler med revisorerne. Så i mange tilfælde vil vi se, at DBA kan aflæse dette og være i stand til at give rapporten, der er sammenkoblet til revisoren, og de kan fjerne sig helt ud af ligningen snarere end at skulle være involveret. Så du ved, det er en enorm besparelse også med hensyn til ressource, når du kan gøre det.
Dez Blanchfield: Du taler om massive omkostningsreduktioner, ikke? Organisationerne fjerner ikke kun risikoen og omkostningen af den, men jeg mener, at du i bund og grund taler om en betydelig reduktion i omkostningerne, A) operationelt og også B) i det faktum, at du ved, om de rent faktisk kan levere reelle- rapportering om overholdelse af tid om, at der er væsentlig reduceret risiko for dataovertrædelse eller en eller anden juridisk bøde eller virkning for ikke at overholde dem, ikke?
Bullett Manale: Ja, absolut. Jeg mener, at for ikke at overholde, er der alle slags dårlige ting, der sker. De kan bruge dette værktøj, og det ville være dejligt, eller de gør det ikke, og de vil finde ud af, hvor dårligt det virkelig er. Så ja, det er ikke kun værktøjet åbenlyst, du kan udføre dine kontroller og alt uden et værktøj som dette. Som jeg sagde, det vil bare tage meget mere tid og omkostninger.
Dez Blanchfield: Det er fantastisk. Så Eric, jeg vil vende tilbage til dig, fordi jeg synes, at takeaway for mig er, at du ved, at slags marked er fantastisk. Men også, i det væsentlige, er det værd at være dens vægt i guld på grundlag af at det at være i stand til at undgå den kommercielle virkning af et problem, der finder sted, eller at kunne reducere den tid, det tager at rapportere og styre overholdelse, bare gør det, ved du værktøjet betaler for sig selv straks ved lyden af ting.
Eric Kavanagh: Det er nøjagtigt rigtigt. Nå, tak så meget for din tid i dag, Bullett. Tak til alle jer derude for jeres tid og opmærksomhed, og Robin og Dez. En anden god præsentation i dag. Tak til vores venner på IDERA for at lade os bringe dig dette indhold gratis. Vi arkiverer denne webcast til senere visning. Arkivet er normalt ope inden for cirka en dag. Og lad os vide, hvad du synes om vores nye websted, insideanalysis.com. Et helt nyt design, et helt nyt look and feel. Vi vil meget gerne høre din feedback, og med det vil jeg byde dig farvel, folkens. Du kan maile mig. Ellers får vi fat i dig i næste uge. Vi har syv webcasts i de næste fem uger eller noget lignende. Vi bliver travlt. Og vi er på Strata-konferencen og IBM Analyst-topmødet i New York senere i denne måned. Så hvis du er der omkring, skal du stoppe ved og sige hej. Pas på, folkens. Hej hej.
