Av Techopedia Staff, 14 september 2016
Takeaway: Host Eric Kavanagh diskuterar databasrevision och efterlevnad med analytiker Robin Bloor och Dez Blanchfield samt Bullett Manale från IDERA i detta avsnitt av Hot Technologies.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej och välkomna, återigen, till Hot Technologies! Ja, 2016. Vi är i år tre av den här showen, det är väldigt spännande grejer. Vi har gungat och rullat i år. Det här är Eric Kavanagh, din värd. Ämnet för idag - det här är ett bra ämne, det har många applikationer i ett antal branscher, helt uppriktigt - "Vem, vad, var och hur: varför du vill veta." Ja, vi kommer att prata om allt det roliga. Det finns en bild om din verkligen, slå mig upp på Twitter @eric_kavanagh. Jag försöker att tweeta alla omnämnanden och tweeta om allt som någon skickar till mig. Annars, så var det.
Det är varmt, ja! Hela showen här är utformad för att hjälpa organisationer och individer att förstå särskild teknik. Vi designade hela programmet här, Hot Technologies, som ett sätt att definiera en viss typ av programvara, eller en viss trend, eller en viss typ av teknik. Anledningen är för att ärligt talat, i programvaruvärlden, får du ofta dessa marknadsföringsvillkor som blir bandade om och ibland kan de uppriktigt bastardisera de koncept som de var avsedda att beskriva.
I den här showen försöker vi verkligen hjälpa dig att förstå vad en viss typ av teknik är, hur den fungerar, när du kan använda den, när du kanske inte ska använda den och ge dig så mycket detaljer som vi möjligen kan. Vi kommer att ha tre presentatörer idag: vår egen Robin Bloor, chefanalytiker här på Bloor Group; vår datavetare som ringer in från Sydney, Australien på andra sidan planeten, Dez Blanchfield, och en av våra favoritgäster Bullett Manale, chef för försäljningsteknik på IDERA.
Jag ska bara säga ett par saker här, förstå vem som gör vad med vilken data, ja det är sånt som styrning, eller hur? Om du tänker på alla förordningar kring branscher, som sjukvård och finansiella tjänster, på dessa domäner, är det där otroligt viktigt. Du måste veta vem som rörde informationen, vem som har ändrat något, vem som öppnade den, vem laddade upp den till exempel. Vad är avstamningen, vad är förutsättningen för dessa uppgifter? Du kan vara säker på att alla dessa frågor kommer att förbli framträdande under de kommande åren av alla slags skäl. Inte bara för efterlevnad, även om HIPAA, och Sarbanes-Oxley, och Dodd-Frank, och alla dessa regler är mycket betydelsefulla, men också bara så att du förstår i din verksamhet vem som gör vad, var, när, varför och hur. Det här är bra saker, vi kommer att vara uppmärksamma.
Gå vidare, ta bort den, Robin Bloor.
Robin Bloor: Okej, tack för den introduktionen, Eric. Detta område med styrning är, menar jag, styrning inom IT var inte ett ord som du hörde förrän lite efter år 2000, tror jag. Det handlade främst om att jag tror ändå att det främst berodde på att det finns lagstiftning om efterlevnad som pågår. Särskilt HIPAA och Sarbanes-Oxley. Det finns faktiskt mycket av det. Därför insåg organisationer att de måste ha en uppsättning regler och en uppsättning förfaranden eftersom det var nödvändigt enligt lagen att göra det. Långt innan detta, särskilt inom banksektorn, fanns det olika initiativ som du var tvungen att följa beroende på vilken typ av bank du var, och särskilt de internationella bankirerna. Hela Basel-kompatibla startade vägen, långt före den specifika uppsättningen av initiativ efter år 2000. Allt kommer verkligen till att styra styrningen. Jag trodde att jag skulle prata om ämnet styrning som en introduktion till fokus för att hålla ett öga på vem som får uppgifterna.
Datastyrning, jag brukade se mig omkring Jag tänker för fem eller sex år sedan, letade efter definitioner och det var inte bra definierat alls. Det blir tydligare och tydligare vad det faktiskt betyder. Verkligheten i situationen var att inom vissa gränser faktiskt styrdes all information tidigare, men det fanns inga formella regler för det. Det fanns speciella regler som gjordes särskilt inom bankbranschen för att göra saker som det, men återigen handlade det mer om efterlevnad. På ett eller annat sätt att bevisa att du faktiskt var en - det är typ av associerad med risk, så att bevisa att du var en livskraftig bank var affären.
Om du ser på utmaningarna för styrning nu börjar det med ett faktum av stordatarörelsen. Vi har ett ökande antal datakällor. Datavolym är naturligtvis ett problem med det. Framför allt började vi göra mycket, mycket mer med ostrukturerade data. Det började bli något som är en del av hela analysspelet. Och på grund av analyser är datainriktning och linjer viktiga. Verkligen med tanke på att använda dataanalys på något sätt som är relaterat till någon form av efterlevnad, måste du verkligen ha kunskap om var informationen kommer från och hur det ska bli vad det är.
Datakryptering började bli ett problem, bli ett större problem så snart vi åkte till Hadoop eftersom idén om en datasjö där vi lagrar mycket data, plötsligt betyder att du har ett enormt sårbarhetsområde för människor som kan få på det. Kryptering av data blev mycket mer framträdande. Autentisering var alltid ett problem. I den äldre miljön, strikt mainframe-miljö, hade de ett sådant underbart säkerhetsskydd; autentisering var aldrig riktigt mycket problem. Senare blev det en större fråga och det är mycket mer en fråga nu eftersom vi har så enormt fördelade miljöer. Datatillträdesövervakning, det blev ett problem. Jag verkar komma ihåg olika verktyg som kom till för tio år sedan. Jag tror att de flesta av dessa drivs av efterlevnadsinitiativ. Därför har vi också alla efterlevnadsregler, efterlevnadsrapportering.
Det som har kommit i minnet är att även tillbaka på 1990-talet, när du utförde kliniska prövningar inom läkemedelsindustrin, var du inte bara tvungen att kunna bevisa var data kom från - uppenbarligen är det mycket viktigt, om du försöker ut läkemedel i olika sammanhang, för att veta vem som försöks och vilka sammanhangsdata som finns kring det - du var tvungen att kunna göra en granskning av programvaran som faktiskt skapade uppgifterna. Det är den allvarligaste överensstämmelse som jag någonsin har sett någonstans, när det gäller att bevisa att du inte faktiskt röra upp saker medvetet eller av misstag. På senare tid har framför allt datalivscykelhantering blivit ett problem. Alla dessa är på ett sätt utmaningar eftersom många av dessa inte har gjorts bra. Under många omständigheter är det nödvändigt att göra dem.
Det här är vad jag kallar datapyramiden. Jag har pratat om det här tidigare. Jag tycker att det är ett mycket intressant sätt att titta på saker. Du kan tänka på data som att ha lager. Rå data, om du vill, är egentligen bara signaler eller mätningar, inspelningar, händelser, mestadels enstaka poster. Eventuellt skapar transaktioner, beräkningar och aggregeringar naturligtvis nya data. Man kan tänka på dem på datainivå. När du faktiskt ansluter data, blir det information. Det blir mer användbart, men naturligtvis blir det mer sårbart för människor som hackar det eller missbrukar det. Jag definierar det som att jag skapat, verkligen genom struktureringen av data, att kunna visualisera data med ordlistor, scheman, ontologier på informationen. Dessa två nedre lager är vad vi bearbetar på ett eller annat sätt. Ovanför det kallar jag lagen av kunskap som består av regler, policyer, riktlinjer, förfarande. Vissa av dem kan faktiskt skapas av insikter som upptäckts i analys. Många av dem är faktiskt politik som du måste följa. Detta är lagret, om du vill, av styrning. Det är här, på ett eller annat sätt, om detta lager inte är ordentligt befolkat, hanteras inte de två lagren nedan. Den sista punkten med detta är att förståelse i något som bara finns i människor. Datorer har inte lyckats göra det ännu, tack och lov. Annars skulle jag ha jobbat.
Styrningsimperiet - jag sammansatte det här, jag tror att det måste ha varit ungefär nio månader sedan, kanske mycket tidigare än så. I grund och botten förbättrade jag det, men så snart vi började bli oroliga för styrning, så fanns det, när det gäller företagets datahub, inte bara datareservoar, resurser för datasjön, men också allmänna servrar av olika slag, specialiserade dataservrar. Allt som behövde styras. När du faktiskt tittade på den olika dimensionen också - datasäkerhet, rensning av data, upptäckt av metadata och hantering av metadata, skapa en affärsordlista, datakartläggning, datalinje, hantering av livscykler för data - då, hantering av prestationsövervakning, hantering av servicenivå, systemhantering, som du kanske inte förknippar med styrning, men en viss - nu när vi går till en snabbare och snabbare värld med fler och fler dataflöden, är faktiskt att kunna göra något med en viss prestanda faktiskt en nödvändighet och börjar bli en arbetsregel snarare än något annat.
Sammanfattande när det gäller tillväxten av efterlevnad såg jag på detta hända under många, många år men det allmänna dataskyddet kom faktiskt på 1990-talet i Europa. Det blev bara mer och mer sofistikerat sedan dess. Sedan började alla dessa saker introduceras eller bli mer sofistikerade. GRC, det är styrningsrisk och efterlevnad har pågått sedan bankerna gjorde Basel. ISO har skapat standarder för olika sorters verksamhet. Jag vet hela tiden att jag har varit inom IT - det har varit länge - USA: s regering har varit särskilt aktiv när det gäller att skapa olika lagstiftningar: SOX, det finns Gramm-Leach-Bliley, HIPAA, FISMA, FERPA. Du har också den underbara NIST-organisationen som skapar många standarder, särskilt säkerhetsstandarder, mycket användbara. Lagarna om dataskydd i Europa har lokala avvikelser. Vad du kan göra med personuppgifter i till exempel Tyskland är annorlunda än vad du kan göra i Slovakiska republiken eller Slovenien, eller var som helst. De introducerade nyligen - och jag trodde att jag skulle nämna detta eftersom jag tycker det är underhållande - Europa introducerar idén om rätten att glömmas. Det vill säga, det borde finnas en stadga om begränsningar för uppgifter som har varit offentliga som faktiskt är personuppgifter. Jag tycker att det är lustigt. Ur IT-synvinkel kommer det att bli mycket, mycket svårt om det börjar bli effektiv lagstiftning. Sammanfattningsvis skulle jag säga följande: Eftersom IT-data och -hantering utvecklas snabbt måste styrning också utvecklas snabbt och det gäller alla förvaltningsområden.
Med det sagt kommer jag att skicka bollen till Dez.
Eric Kavanagh: Ja, ja, Dez Blanchfield, ta bort det. Robin, jag är med dig, jag dör för att se hur denna rätt att glömma spelar ut. Jag tror att det inte kommer att bli bara utmanande men i princip omöjligt. Det är bara en kränkning av att vänta på att utövas av myndigheter. Dez, ta bort det.
Dez Blanchfield: Det är verkligen och det är ett ämne för en annan diskussion. Vi har en mycket liknande utmaning här i Asien-Stillahavsområdet, och särskilt i Australien där transportörer och internetleverantörer krävs för att logga allt som är relaterat till internet och kunna spela in och regurgitera det om någon av intressen gör något fel. Det är en lag och du måste följa den. Utmaningen, precis som någon i Google i USA kan få höra att ta bort min sökhistorik eller vad som helst, det kan vara att följa europeisk lagstiftning, särskilt tysk sekretesslagstiftning. Om en byrå vill undersöka dig i Australien måste en transportör kunna lämna detaljer om samtal och sökhistorik, vilket är utmanande, men det är världen vi lever i. Det finns många orsaker till det. Låt mig bara hoppa in i min.
Jag gjorde medvetet min titel sida svår att läsa. Du måste verkligen titta hårt på den texten. Överensstämmelse, i enlighet med en uppsättning regler, specifikationer, kontroller, policyer, standarder eller lagar, med en dum, rörig bakgrund. Det beror på att du verkligen måste titta på det svårt att få detaljerna och ta fram information från vad den är överlagrad, som är en serie tabeller och rader och kolumner, antingen en databas, ett schema eller en mock-up i Visio. Det är så att efterlevnadsform känns som dag till dag. Det är ganska svårt att dyka ned i detaljerna och dra ut de relevanta informationsbitar du behöver för att kunna bekräfta att du uppfyller kraven. Rapportera om det, övervaka det och testa det.
Faktum är att jag tänkte ett riktigt bra sätt att visualisera detta när vi ställer oss frågan "Är du kompatibel?" "Är du säker?" "Tja, bevisa det!" Det finns en riktigt rolig sak som kanske är lite mer anglo-keltisk men jag är säker på att den har gjort vägen runt i världen till USA, så det är: "Where's Wally?" Wally är en liten karaktär som kommer in i dessa tecknade ritningar i form av böcker. Vanligtvis väldigt stora bilder på A3 eller större. Så, tabellstorleksteckningar. Han är en liten karaktär som bär en mössa och en rödvit randig skjorta. Idén med spelet är att du tittar på den här bilden och du tittar runt i cirklar för att försöka hitta Wally. Han är på den bilden där någonstans. När du funderar på hur du kan upptäcka och beskriva och rapportera om efterlevnad är det på många sätt att spela "Where's Wally." Om du tittar på den bilden är det nästan omöjligt att hitta karaktären. Barn lägger timmar på det och jag hade mycket kul att göra det själv igår. När vi tittar på det, hittar vi en hel massa människor i dessa tecknade film, medvetet placerade där med liknande bitar av Wally-outfit av en randig mössa och en tröja eller ulltopp. Men de blir falska positiva.
Detta är en liknande utmaning som vi har när det gäller efterlevnad. När vi tittar på saker, ibland är något vi tror att så är fallet inte alls. Någon kan ha tillgång till en databas och de ska ha tillgång till en databas men sättet de använder den på är något annorlunda än vad vi förväntar oss. Vi kanske beslutar att det är något vi behöver titta på. När vi tittar på det finner vi, faktiskt, det är en mycket giltig användare. De gör bara något udda. Kanske är det en PC-forskare eller vem vet det. I andra fall kan det vara motsatt. Verkligheten, när jag går framåt igen, finns det Wally. Om du såg riktigt hårt ut i denna högupplösta finns det en karaktär som faktiskt bär rätt klädsel. Alla de andra är bara lookalikes och feel-alikes. Efterlevnad känns väldigt så. De flesta jag känner arbetar med kontroller och efterlevnad och policyområden för företag. Inom hela spektrum av områden, oavsett om det är teknik, oavsett om det är ekonomi, drift eller risker. Ofta är det väldigt svårt att se Wally på bilden, du ser träden eller träet.
Frågan som vi ställer oss, när vi tänker på saker som efterlevnad, är "Big deal, vad kan eventuellt gå fel om vi inte riktigt uppfyller efterlevnaden?" I samband med dagens diskussion, speciellt kring databas och kontroll av tillgång till data, kommer jag att ge dig några väldigt riktiga exempel på väckningssamtal om vad som kan gå fel i mycket kort kortfattad form. Om vi tänker på dataöverträdelser, och vi är alla bekanta med dataintrång, hör vi dem i media, och vi slags stopp och skratt, eftersom människor tror att det är marknader. Det är personliga saker. Det är Ashley Madison och människor som letar efter datum utanför sina relationer och äktenskap. Det är kasta konton. Det är alla dessa konstiga saker eller någon slumpmässig europeisk eller rysk ISP eller värdföretag hackas. När det gäller saker som MySpace och dessa topp tio, när du tittar på dessa siffror, vad jag vill att du ska inse är detta: 1, 1 miljarder människors detaljer i dessa topp tio överträdelser. Och ja, det finns överlappningar, det finns förmodligen människor som har ett MySpace-konto, ett Dropbox-konto och ett Tumblr-konto, men låt oss bara runda upp det till en miljard människor.
Dessa topp tio överträdelser under det senaste decenniet eller så - inte ens ett decennium, i de flesta fall - sammanfattar ungefär en sjunde av världens befolkning av människor, men mer realistiskt är cirka 50 procent av antalet människor anslutna till internet, över en miljard individer. Dessa beror på att överensstämmelse inte har uppfyllts i vissa fall. I de flesta fall var det kontroller av åtkomst till databas, kontroll av åtkomst till vissa datauppsättningar och system och nätverk. Detta är en läskig verklighetskontroll. Om det inte skrämmer dig, när du tittar på de tio bästa och du kan se att det här är en - eller kan se att detta är en miljard individer, riktiga människor precis som oss, på detta samtal just nu. Om du har ett LinkedIn-konto, om du hade ett Dropbox-konto eller ett Tumblr-konto eller om du köpte från Adobes produkter eller till och med registrerade ladda ner gratis Adobe-visare. Det är helt troligt, inte möjligt, det är helt troligt att dina uppgifter, ditt förnamn, ditt efternamn, din e-postadress, eventuellt även ditt arbetsföretags adress, eller din hemadress eller ditt kreditkort, faktiskt finns ute på grund av ett överträdelse som ägde rum på grund av kontrollerna, som inte nödvändigtvis hanterades bra i form av datahantering, datastyring.
Låt oss titta på det när vi tittar på det i verklig detalj. Det finns en skärm av dem, det finns cirka 50-något där. Det finns ytterligare 15. Det handlar om ytterligare 25. Dessa är dataöverträdelser som listas på en webbplats som heter haveibeenpwned.com. Det här kan möjligen gå fel om något enkelt som att kontrollera vem som har haft tillgång till data i databaser i olika fält och rader och kolumner och olika applikationer i ditt företag inte hanteras korrekt. Dessa organisationer är nu datadrivna. De flesta data lever i en databas i någon form. När du tänker på det, den listan över överträdelser som vi just tittade på, och förhoppningsvis har den gett dig lite kall dusch på ett sätt, i det att du tänkte "Hmm, det är väldigt riktigt", och det har potentiellt påverkat dig. År 2012, till exempel det brott mot LinkedIn, har de flesta yrkesverksamma ett LinkedIn-konto i dag och det är troligt att dina uppgifter går förlorade. De har varit ute på internet sedan 2012. Vi har bara fått höra om det 2016. Vad hände med din information under de fyra åren? Det är väl intressant och vi kan prata om det separat.
Databas- och systemhantering - Jag pratar ofta om vad jag anser vara de fem bästa utmaningarna för att hantera dessa saker. Högst upp, och jag rankar dessa i önskad ordning från mig själv, men också påverkan, nummer ett är säkerhet och efterlevnad. Kontrollerna och mekanismerna och policyerna för att kontrollera vem som har vilken tillgång till vilket system, av vilket skäl och syfte. Rapportera om det och övervaka det, titta in i systemen, titta i databaserna och se vem som faktiskt kan få åtkomst till poster, enskilda fält och poster.
Tänk på detta i en mycket enkel form. Låt oss prata om bank- och förmögenhetsförvaltning som ett exempel. När du registrerar dig för ett bankkonto, låt oss bara säga ett normalt kontokonto för ett EFTPOS-kort, eller ett kontantkonto eller ett checkkonto. Du fyller i ett formulär och det finns massor av mycket privat information i det papperet som du fyller i eller så gör du det online och som går in i ett datorsystem. Om någon i marknadsföringen vill kontakta dig och skicka en broschyr, bör de få se ditt förnamn och efternamn och din personliga adress, till exempel och eventuellt ditt telefonnummer om de vill kalla dig och säljer dig något. De borde förmodligen inte se det totala beloppet du har i banken av många orsaker. Om någon tittar på dig ur ett riskperspektiv eller försöker hjälpa dig att göra något som att få bättre ränta på ditt konto, vill den specifika personen förmodligen se hur mycket pengar du har i banken, så de kan erbjuda dig rätt nivåer av ränta på dina pengar. Dessa två individer har mycket olika roller och mycket olika skäl för dessa roller och syften för dessa roller. Som ett resultat måste du se olika information i din post, men inte hela posten.
Dessa kontroller kring olika rapporter om vanliga skärmar eller form som de har i applikationerna som används för att hantera ditt konto. Utvecklingen för dem, upprätthållandet av dem, förvaltningen av dem, rapporteringen kring dem och styrningen och efterlevnaden som är lindad kring de som bubbelbrytningar, alla är en mycket, mycket stor utmaning. Det är bara den största utmaningen när det gäller att hantera data och system. När vi går djupare ner i den stacken i prestanda och övervakning, och upptäckt av incidenter och svar, hantering och administration av systemet och efterlevnad kring dem, design och utveckling av systemen från överensstämmelse, blir det mycket svårare.
Hantera hela frågan om att minska risker och förbättra säkerheten. Mina fem största utmaningar i detta utrymme - och jag gillar bilderna som följer med ett tullskrivbord när du kommer in i ett land - de presenterar ditt pass, och de checkar ut dig, och de tittar på deras datorsystem för att se om du borde passera eller inte. Om du inte borde sätta de dig på nästa plan hemma. Annars släpper de dig tillbaka och de ställer frågor som "Kommer du på semester? Är du här turist? Är du här för arbete? Vilken typ av arbete ska du se? Var ska du stanna "Hur länge kommer du efter? Har du tillräckligt med pengar för att täcka dina utgifter och kostnader? Eller kommer du att bli en risk för landet du befinner dig i och de kanske måste ta hand om dig och mata dig?"
Det finns några problem kring detta utrymme med data, hantering av dataskydd. Till exempel i databasutrymmet måste vi tänka på att mildra databasomgångar. Om data finns i databasen, i en normal miljö och det finns kontroller och mekanismer runt det i systemet. Vad händer om en dumpning av data görs i mer SQL och säkerhetskopieras till band? Databaserna dumpas i rå form och säkerhetskopieras ibland. Ibland görs det av tekniska skäl, utvecklingsskäl. Låt oss bara säga att en DB-dumpning togs och säkerhetskopieras till band. Vad händer om jag råkar få tag på det bandet och återställa det? Och jag har en rå kopia av databasen i SQL. Det är en MP-fil, det är text, jag kan läsa den. Alla lösenord som lagras i dumpningen har ingen kontroll över mig eftersom jag nu får åtkomst till databasens faktiska innehåll utan att databasmotorn skyddar den. Så jag kan tekniskt kringgå säkerheten för databasplattformen som byggs i motorn med överensstämmelse och riskhantering för att hindra mig att titta på data. Eftersom potentiellt utvecklaren, systemadministratören, har jag tagit hand om en fullständig dumpning av databasen som ska användas för säkerhetskopior.
Missbruk av data - potentiellt få någon att logga in som sitt upphöjda konto och låta mig sitta vid skärmen, leta efter information eller liknande saker. Egen revision, åtkomst till och användning av uppgifterna och visning av uppgifterna eller ändringar av uppgifterna. Sedan rapporteringen kring den kontrollen och efterlevnaden krävs. Övervaka trafik och åtkomst osv., Blockera hot som kommer från externa platser och servrar. Om data till exempel presenteras via ett formulär på en webbsida på internet, har deras SQL-injektioner skyddats genom brandväggar och konceptkontroller? Det finns en lång detaljerad berättelse som ligger bakom detta. Här kan du se att bara några av dessa absolut grundläggande saker som vi tänker på för att mildra och hantera risk kring data i databaser. Det är faktiskt relativt enkelt att komma runt några av dessa om du befinner dig på olika nivåer av tekniker. Utmaningen blir svårare och hårdare när du får mer och mer data och fler databaser. Mer och mer utmanande med människor som måste hantera systemen och övervaka användningen av dem, spåra relevanta detaljer som specifikt hänför sig till saker som Robin talade om, kring saker som personlig efterlevnad. Individer har kontroller och mekanismer runt sig som följer - om du gör något fel kan du bli avskedad. Om jag loggar in som mitt konto låter dig se det, borde det vara ett brännbart brott. Nu har jag gett dig tillgång till data som du inte borde ha sett normalt.
Det finns personlig efterlevnad, det finns företagens efterlevnad, företag har policyer och regler och kontroller som de har ställt på sig själva så att företaget fungerar bra och ger en avkastning på vinsten och en god avkastning till investerare och aktieägare. Sedan finns det ofta stads- eller statligt eller nationellt, federalt som du sa USA: s kontroller och lagar. Sedan finns det globala. Några av de större incidenterna i världen, där sådana som Sarbanes-Oxley, två individer som uppmanas att hitta sätt att skydda data och system. Det finns Basel i Europa och det finns alla kontroller i Australien, speciellt kring börser och plattformar, och sedan integritet på individ- eller företagsnivå. När var och en av dessa staplas som du såg på en av de platser som Robin hade, blir de nästan ett omöjligt berg att klättra. Kostnaderna blir höga och vi är vid den punkt där det ursprungliga traditionella tillvägagångssättet som du känner, som människor som mäter kontroll, inte längre är ett lämpligt tillvägagångssätt eftersom skalan är för stor.
Vi har ett scenario där överensstämmelse är det jag kallar nu en alltid pågående fråga. Och det är att vi brukade ha en tidpunkt, antingen månatlig eller kvartalsvis eller årligen, där vi skulle granska vårt land och hjälpa till att följa och kontrollera. Se till att vissa personer hade viss åtkomst och inte hade viss åtkomst beroende på vad deras behörigheter var. Nu är det ett fall med hastigheten på saker som saker rör sig, tempo i vilken saker förändras, i vilken skala vi arbetar. Efterlevnad är en alltid pågående fråga och den globala finanskrisen var bara ett exempel där de relevanta kontrollerna, och säkerhets- och efterlevnadsåtgärder potentiellt kunde ha undvikit ett scenario där vi hade ett kört godståg med visst beteende. Bara skapa en situation med hela världen effektivt veta att det skulle gå brist och konkurs. För att göra det behöver vi rätt verktyg. Att kasta människor på tåget och kasta kroppar är inte längre ett giltigt tillvägagångssätt eftersom skalan är för stor och saker rör sig för snabbt. Diskussionen idag, tror jag att vi kommer att ha, handlar om vilka typer av verktyg som kan tillämpas på detta. I synnerhet de verktyg som IDERA kan ge oss som borde göra det. Och med det i åtanke kommer jag att överlämna det till Bullett att gå igenom hans material och visa oss deras tillvägagångssätt och de verktyg som de har för att lösa detta problem som vi har lagt fram nu för dig.
Med det, Bullett, ska jag lämna till dig.
Bullett Manale: Det låter bra, tack. Jag vill prata om några bilder och jag vill också visa er en produkt som vi använder för SQL Server-databaser specifikt för att hjälpa till med efterlevnadssituationer. Verkligen utmaningen i många fall - jag kommer att hoppa över några av dessa - det här är bara vår produktportfölj, jag kommer att gå igenom det ganska snabbt. När det gäller hur den här produkten kommer att adresseras och hur den hänför sig till efterlevnaden, drar jag alltid upp den här som den första bilden eftersom den är typ av en generisk, "Hej, vad ansvarar en DBA?" En av sakerna kontrollerar och övervakar användaråtkomst och kan också generera rapporter. Det kommer att binda i när du pratar med din revisor, hur svår processen kan vara kommer att variera beroende på om du ska göra det på egen hand eller om du kommer att använda en tredje part verktyg för att hjälpa.
Generellt sett, när jag pratar med databasadministratörer, många gånger har de aldrig varit inblandade i en revision. Du måste slags utbilda dem till verkligen vad det är som du verkligen måste göra. Relaterat till vilken typ av efterlevnad som måste uppfyllas och att kunna bevisa att du faktiskt följer reglerna eftersom det gäller den nivån för efterlevnad. Många människor förstår det inte först. De tänker, "Åh, jag kan bara köpa ett verktyg som kommer att göra mig kompatibel." Verkligheten är att det inte är fallet. Jag önskar att jag kunde säga att vår produkt på magiskt sätt, genom att veta, trycka på den enkla knappen, gav dig möjligheten att se till att du uppfyller kraven. Verkligheten är att du måste ha din miljö inställd i fråga om kontrollerna, när det gäller hur människor får åtkomst till uppgifterna, att allt måste utarbetas med den applikation som du har. Där det är känsligt för informationen lagras, vilken typ av lagkrav är det. Då måste du också arbeta med vanligtvis en intern efterlevnadsansvarig för att kunna se till att du följer alla regler.
Det låter riktigt komplicerat. Om du tittar på alla lagstadgade krav skulle du tro att det skulle vara fallet, men verkligheten är att det finns en gemensam nämnare här. I vårt fall med det verktyg som jag ska visa dig idag, Compliance Manager-produkten, skulle processen i vår situation vara att vi först och främst måste se till att vi samlar in revisionsspårets data, relaterade till var informationen finns i databasen som är känslig. Du kan samla allt, eller hur? Jag kunde gå ut och säga att jag vill samla in alla transaktioner som händer i den här databasen. Verkligheten är att du antagligen bara har en liten bråkdel eller en liten andel transaktioner som faktiskt är relaterade till känsliga uppgifter. Om det är PCI-överensstämmelse kommer det att vara kring kreditkortsinformationen, kreditinnehavarnas ägare, deras personliga information. Det kan finnas massor av andra transaktioner när det gäller din ansökan, som egentligen inte har någon betydelse för PCI: s lagkrav.
Ur det synvinkeln är det första när jag pratar med DBA att jag säger: ”Utmaningen som nummer ett försöker inte få ett verktyg för att göra dessa saker för dig. Det är bara att veta var är den känsliga informationen och hur låser vi in den informationen? Om du har det, om du kan svara på den frågan, är du halvvägs hemma i termer av att du kan visa att du följer, förutsatt att du följer rätt kontroller. Låt oss säga för en sekund att du följer de rätta kontrollerna och att du sa till revisorerna att så är fallet. Nästa del av processen är uppenbarligen att kunna tillhandahålla en revisionsspår som visar och validerar de kontrollerna som faktiskt fungerar. Därefter följer du upp med att se till att du sparar data. Vanligtvis med saker som PCI och HIPAA-överensstämmelse, och dessa typer av saker, pratar du sju års värdeförvaring. Du pratar om en hel del transaktioner och mycket data.
Om du håller på med att samla in varje transaktion även om bara fem procent av transaktionerna är relaterade till känslig information, pratar du om en ganska stor kostnad för att behöva lagra den informationen i sju år. Det är en av de största utmaningarna, tror jag, är att få människors huvud att säga, det är helt klart en onödig kostnad. Det är också mycket lättare om vi bara kan fokusera granulärt på de känsliga områdena i databasen. Förutom att du också vill ha kontroller kring en del av känslig information också. Inte bara för att visa i termer av en revisionsspår, utan också kunna binda saker tillbaka till handlingar som händer och kunna bli meddelade i realtid, så att du kan bli medveten om det.
Exemplet använder jag alltid, och det kanske inte nödvändigtvis är relaterat till någon typ av myndighetskrav utan bara kunna spåra, till exempel skulle någon släppa tabellen som är kopplad till lönelistan. Om det händer, är det så att du får reda på det, om du inte spårar det, blir ingen betald. Det är för sent. Du vill veta när det bordet tappas, precis när det tappas, för att undvika alla dåliga saker som händer till följd av att någon missnöjd anställd går och tar bort tabellen som är direkt knuten till lönelistan.
Med det sagt är tricket att hitta den gemensamma nämnaren eller använda den gemensamma nämnaren för att kartlägga vad nivån för efterlevnad är. Det är typ av vad vi försöker göra med det här verktyget. Vi tar i princip tillvägagångssättet, vi ska inte visa dig en rapport som är specifik för PCI, specifik för aktier; den gemensamma nämnaren är att du har ett program som använder SQL Server för att lagra känslig information i databasen. När du väl har kommit över så säger du: "Ja det är verkligen det viktigaste vi behöver fokusera på - var är den känsliga informationen, och hur får man åt dem?" När du väl har det finns det massor av rapporter som vi erbjuder som kan ge bevis på att du är inom överensstämmelse.
När jag går tillbaka till de frågor som ställs av en revisor kommer den första frågan att vara: Vem har tillgång till uppgifterna och hur får de tillgången? Kan du bevisa att rätt personer har tillgång till uppgifterna och att fel personer inte är det? Kan du också bevisa att själva revisionsspåret är något som jag kan lita på som en oändlig informationskälla? Om jag ger dig en revisionsspår som är tillverkad, gör det mig inte så bra som revisor att plåga din revision om informationen är tillverkad. Vi behöver bevis på det, vanligtvis ur ett revisionsperspektiv.
Gå igenom dessa frågor, lite mer detaljerad. Utmaningen med den första frågan är, du måste veta, som jag sa, var den känsliga informationen är för att rapportera om vem som har åtkomst till den. Det är vanligtvis någon typ av upptäckt och verkligen har du tusentals olika applikationer som finns där ute, du har massor av olika lagkrav. I de flesta fall vill du arbeta med din efterlevnadsansvarig om du har en eller åtminstone någon som skulle ha ytterligare insikt i termer av var mina känsliga uppgifter finns i applikationen. Vi har ett verktyg som vi har, det är ett gratis verktyg, det kallas en SQL Column Search. Vi berättar för våra potentiella kunder och användare som är intresserade av den frågan, de kan ladda ner den. Vad det kommer att göra är att det i princip letar efter informationen i databasen som troligen kommer att vara känslig till sin natur.
Och sedan när du gör det måste du också förstå hur människor får åtkomst till dessa uppgifter. Och det kommer att bli, än en gång, vilka konton inom vilka Active Directory-grupper, vilka databasanvändare är involverade, det finns en rollmedlemskap associerade till detta. Och tänker naturligtvis på att alla dessa saker som vi pratar om måste godkännas av revisoren, så om du säger: "Så här låser vi in uppgifterna", så kan revisorerna komma tillbaka och säga, "Tja, du gör det fel." Men låt oss säga att de säger, "Ja, det ser bra ut. Du låser upp data tillräckligt. "
Gå vidare till nästa fråga, som kommer att bli, kan du bevisa att rätt personer har tillgång till den informationen? Med andra ord kan du berätta för dem att dina kontroller är, det här är kontrollerna du följer, men tyvärr är revisorerna inte riktigt litar på individer. De vill ha bevis på det och de vill kunna se det inom revisionsspåret. Och detta går tillbaka till hela den gemensamma nämnaren. Oavsett om det är PCI, SOX, HIPAA, GLBA, Basel II, hur som helst, verkligheten är, är att samma typ av frågor kommer vanligtvis att ställas. Objektet med den känsliga informationen, vem har kommit åt det objektet under den senaste månaden? Det borde kartlägga mina kontroller och jag borde kunna godkänna min revision så småningom genom att visa de typerna av rapporter.
Och vad vi har gjort är att vi har sammanställt cirka 25 olika rapporter som följer på samma typ av områden som den gemensamma nämnaren. Så vi har inte en rapport för PCI eller för HIPAA eller för SOX, vi har rapporter om att de än en gång går emot den gemensamma nämnaren. Och så spelar det ingen roll vilket lagkrav du försöker uppfylla, i de flesta fall kommer du att kunna svara på vilken fråga som revisorn ställer dig. Och de kommer att berätta vem, vad, när och var för varje transaktion. Du vet, användaren, när transaktionen inträffade, själva SQL-uttalandet, applikationen som det kom från, allt det där bra, och sedan också kunna automatisera leveransen av denna information till rapporter.
Och sedan, ännu en gång, när du har kommit förbi det och du har tillhandahållit det till revisoren, då kommer nästa fråga att bli, bevisa det. Och när jag säger bevisa det, menar jag bevisa att själva revisionsspåret är något vi kan lita på. Och hur vi gör det i vårt verktyg är att vi har hashvärden och CRC-värden som binder direkt tillbaka till händelserna i revisionsspåret. Och så är tanken att om någon går ut och tar bort en post eller om någon går ut och tar bort eller lägger till något i revisionsspåret eller ändrar något i själva revisionsspåret, kan vi bevisa att dessa data, integriteten hos uppgifterna i sig kränkades. Och så 99, 9 procent av tiden om du har låst vår granskningsdatabas låst, kommer du inte att stöta på det problemet eftersom när vi kör den integritetskontrollen bevisar vi i huvudsak för revisoren att själva uppgifterna inte har varit har ändrats och raderats eller lagts till sedan originalskrivningen från själva managementtjänsten.
Så det är en generell översikt över de typiska frågorna du skulle ställa. Nu, verktyget som vi måste ta itu med mycket av detta kallas SQL Compliance Manager och det gör alla dessa saker när det gäller att spåra transaktionerna, vem, vad, när och var av transaktionerna, att kunna göra det i en antal olika områden också. Inloggningar, misslyckade inloggningar, ändringar av scheman, uppenbarligen datatillgång, välj aktivitet, alla de saker som händer i databasmotorn. Och vi kan också varna användarna om specifika, mycket korniga förhållanden, om det behövs. Till exempel, någon går ut och tittar faktiskt på tabellen som innehåller alla mina kreditkortsnummer. De ändrar inte uppgifterna, de tittar bara på dem. I den situationen kan jag varna och jag kan låta folk veta att det händer, inte sex timmar senare när vi skrapar loggar utan i realtid. Det är i princip så länge det tar för oss att behandla transaktionen genom en hanteringstjänst.
Som jag nämnde tidigare har vi sett detta användas i en mängd olika lagkrav och det gör det inte riktigt - du vet, något lagkrav, än en gång, så länge som gemensamma nämnare, har du känslig data i en SQL Server databas, detta är ett verktyg som skulle hjälpa till i den typen av situationer. För de 25 rapporterna som är inbyggda är verkligheten nu att vi kan göra det här verktyget bra för revisoren och besvara varje fråga som de ställer, men DBA är de som måste få det att fungera. Så det finns också att tänka på, du vet väl, från ett underhållsperspektiv måste vi se till att SQL fungerar som vi vill. Vi måste också kunna gå in och titta på saker som kommer att kunna gå ut och titta på andra uppgifter, du vet såväl som arkiveringen av data, automatiseringen av det och omkostnaderna produkten själv. Det är saker som vi uppenbarligen tar hänsyn till.
Vilket tar upp själva arkitekturen. Så på den högra sidan av skärmen har vi förekomsten av SQL som vi hanterar, allt från 2000 hela vägen fram till 2014, redo att släppa en version för 2016. Den största takeawayen på den här skärmen är att ledningen servern själv gör alla tunga lyft. Vi samlar bara in data med hjälp av spårnings-API, inbyggt med SQL Server. Den informationen lurar upp till vår hanteringsserver. Den hanteringsservern själv identifierar och om det finns några händelser knutna till några typer av transaktioner som vi inte vill ha, skickar ut varningar och sådana saker och sedan fyller data i ett arkiv. Därifrån kan vi köra rapporter, vi skulle kunna gå ut och faktiskt se den informationen i rapporterna eller till och med inom programmets konsol.
Så vad jag ska gå vidare och göra är att jag ska ta oss igenom, verkligen snabbt, och jag vill bara påpeka en snabb sak innan vi hoppar in i produkten, det finns en länk på webbplatsen just nu, eller på presentationen kommer det att ta dig till det gratis verktyg som jag nämnde tidigare. Det gratis verktyget är, som sagt, det kommer att gå ut och titta på en databas och försöka hitta områden som ser ut som känslig data, personnummer, kreditkortsnummer, baserat på namnen på kolumnerna eller tabellerna, eller baserat på hur dataformatet ser ut, och du kan anpassa det också, så bara för att påpeka det.
Nu, i vårt fall, låt mig gå vidare och dela ut min skärm, ge mig en sekund här. Okej, och så, vad jag ville ta dig först är att jag vill ta dig till själva Compliance Manager-applikationen och jag kommer att gå igenom det ganska snabbt. Men det här är applikationen och du kan se att jag har ett par databaser här och jag ska bara visa dig hur lätt det är att gå in och berätta vad du vill granska. Från synpunkten på schemaändringar, säkerhetsförändringar, administrativa aktiviteter, DML, Välj, har vi alla dessa alternativ tillgängliga för oss, vi kan också filtrera ner det. Detta går tillbaka till bästa praxis för att kunna säga, ”Jag behöver egentligen bara den här tabellen eftersom den innehåller mina kreditkortsnummer. Jag behöver inte de andra tabellerna som har produktinformation, alla de andra saker som inte är i förhållande till nivån för efterlevnad jag försöker uppfylla. ”
Vi har också förmågan att fånga data och visa dem i termer av värdena på fälten som förändras. I många verktyg har du något som ger dig möjligheten att fånga SQL-uttalandet, visa användaren, visa applikationen, tid och datum, allt så bra grejer. Men i vissa fall kommer inte SQL-uttalandet att ge dig tillräckligt med information för att kunna berätta vad värdet på fältet var innan ändringen inträffade samt fältets värde efter att ändringen inträffade. Och i vissa situationer behöver du det. Jag kanske vill spåra till exempel en läkares dosinformation för receptbelagda läkemedel. Det gick från 50 mg till 80 mg till 120 mg, jag skulle kunna spåra det med före och efter.
Känsliga kolumner är en annan sak som vi stöter på mycket till exempel med PCI-efterlevnad. I situationen här har du data som är så känsliga till sin natur att bara genom att titta på den informationen behöver jag inte ändra den, ta bort den eller lägga till den kan jag orsaka oåterkallelig skada. Kreditkortsnummer, personnummer, alla sådana bra saker vi kan identifiera känsliga kolumner och binda varningar till det. Om någon går ut och tittar på den informationen skulle vi självklart kunna varna och skicka ett e-postmeddelande eller generera en SNMP-fälla och sådana saker.
I vissa fall kommer du nu att stöta på en situation där du kan ha ett undantag. Och vad jag menar med det, du har en situation där du har en användare som har ett användarkonto som kan vara bundet till någon typ av ETL-jobb som körs mitt på natten. Det är en dokumenterad process och jag behöver helt enkelt inte ta med den transaktionsinformationen för det användarkontot. I så fall skulle vi ha en betrodd användare. Och i andra situationer skulle vi använda funktionen i Privileged User Auditing, som i huvudsak är, om jag har, låt oss säga till exempel en applikation, och den applikationen som redan gör revision, för de användare som går igenom applikationen, det är bra, jag har redan något att hänvisa till när det gäller min revision. Men för de saker som är knutna till, till exempel, mina privilegierade användare, killarna som kan gå in i SQL Server managementstudio för att titta på informationen i databasen, kommer det inte att skära ner det. Och det är här vi kan definiera vem våra privilegierade användare är, antingen genom rollmedlemskap eller genom deras Active Directory-konton, grupper, deras SQL-autentiserade konton, där vi kan välja alla dessa olika typer av alternativ och sedan därifrån se till att för de privilegierade användare kan vi ange vilka typer av transaktioner vi är intresserade av att granska.
Dessa är alla typer av olika alternativ som du har och jag kommer inte att gå igenom alla de olika typerna av saker baserat på tidsbegränsningarna här för denna presentation. Men jag vill visa dig hur vi kan visa data och jag tror att du kommer att gilla hur det fungerar eftersom det finns två sätt vi kan göra det. Jag kan göra det interaktivt och så när vi pratar med människor som är intresserade av detta verktyg för kanske sina egna interna kontroller, vill de bara veta vad som händer i många fall. De behöver inte nödvändigtvis revisorer på plats. De vill bara veta, "Hej, jag vill gå efter det här bordet och se vem som har rört det under den senaste veckan eller förra månaden eller vad som än kan vara." I det här fallet kan du se hur snabbt vi kan göra det.
När det gäller vårddatabasen har jag en tabell som heter Patientjournaler. Och den tabellen, om jag bara skulle gruppera efter objekt, kan det mycket snabbt börja minska där vi letar efter. Kanske vill jag gruppera efter kategori och sedan kanske efter evenemang. Och när jag gör det kan du se hur snabbt det dyker upp, och det finns min tabell för patientjournaler där. Och när jag borrar in kan vi nu se DML-aktiviteten, vi kan se att vi har haft tusen inlägg av DML, och när vi öppnar upp en av dessa transaktioner kan vi se relevant information. Vem, vad, när, transaktionens var, SQL-uttalandet, uppenbarligen, den faktiska applikationen som används för att utföra transaktionen, kontot, tiden och datumet.
Om du nu tittar på nästa flik här, fliken Detaljer, går det tillbaka till den tredje frågan vi pratar om, vilket bevisar att integriteten hos uppgifterna inte har bryts. Så i princip varje händelse, vi har en hemlig beräkning för vårt hashvärde, och detta kommer sedan att binda tillbaka till när vi gör vår integritetskontroll. Om jag till exempel skulle gå ut till verktyget, gå till granskningsmenyn och jag skulle gå ut och säga, låt oss kontrollera förvarets integritet, jag kunde peka på databasen där revisionsspåret är, det kommer att köras genom en integritetskontroll som matchar dessa hashvärden och CRC-värden till de faktiska händelserna och det kommer att berätta för oss att det inte har hittats några problem. Med andra ord, uppgifterna i revisionsspåret har inte manipulerats sedan de ursprungligen skrevs av ledningstjänsten. Det är uppenbarligen ett sätt att interagera med data. Det andra sättet skulle vara genom själva rapporterna. Och så ska jag bara ge dig ett snabbt exempel på en rapport.
Och än en gång är dessa rapporter, hur vi kom fram till dem, inte specifika för någon typ av standard som PCI, HIPAA, SOX eller något liknande. Återigen är det gemensamma nämnaren för vad vi gör, och i det här fallet, om vi går tillbaka till det exempel på patientjournaler, skulle vi kunna gå ut och säga, i vårt fall här, ser vi i vårddatabasen och i vårt fall vill vi fokusera specifikt på den tabell som vi vet innehåller privat information, i vårt fall, relaterad till våra patienter. Och så, låt mig se om jag kan skriva det här, och vi ska gå vidare och driva den rapporten. Och vi kommer naturligtvis att se därifrån all relevant information som är kopplad till det objektet. Och i vårt fall visar det oss under en månad. Men vi kan gå tillbaka sex månader, ett år, hur länge vi har hållit data för.
Det är sådana sätt du faktiskt skulle kunna bevisa, om du vill, för revisoren att du följer dina kontroller. När du väl har identifierat det, så är det uppenbarligen bra när det gäller att godkänna din revision och kunna visa att du följer kontrollerna och allt fungerar.
Det sista att prata om det jag ville demonstrera är i administrationsavsnittet. Det finns också kontroller från det att det här verktyget själva kan ställa in kontroller för att kunna se till att om någon gör något som de inte ska göra så kan jag bli medveten om det. Och jag ska ge dig ett par exempel där. Jag har ett inloggningskonto som är bundet till en tjänst och som tjänsten behöver förhöjda behörigheter för att göra vad den gör. Det jag inte vill ha är att någon går in och använder det kontot i Management Studio och sedan, du vet, använder det för saker som det inte var avsett för. Vi skulle ha två kriterier här som vi kan tillämpa. Jag skulle kunna säga, "Se, vi är verkligen intresserade av att detta fungerar, säg med vår PeopleSoft-applikation, " som ett exempel, okej?
Nu när jag har gjort det, vad jag säger här är, är jag nyfiken på att veta alla inloggningar som är knutna till kontot jag redo att ange, om applikationen som används för att logga in med det här kontot är inte PeopleSoft, då kommer det att bli en höjning för larmet. Och självklart måste vi ange själva kontonamnet, så i vårt fall ska vi bara kalla detta Priv-konto för det faktum att det är privilegierat. När vi väl har gjort det här, när vi gör det här, skulle vi nu kunna specificera vad vi skulle vilja hända när det inträffar och för varje typ av händelse eller, jag skulle säga, varning, kan du ha en separat anmälan till den person som är ansvarig för den aktuella uppgiften.
Om det till exempel är löninformation kan det gå till min chef för HR. I det här fallet, som hanterar PeopleSoft-applikationen, kommer det att vara administratören för den applikationen. Oavsett fall. Jag skulle kunna sätta in min e-postadress, anpassa det faktiska varningsmeddelandet och allt det där bra. Återigen går detta tillbaka till att kunna se till att du kan visa att du följer dina kontroller och att dessa kontroller fungerar som de är avsedda. Från det sista perspektivet här, bara när det gäller underhåll, har vi förmågan att ta dessa data och lägga dem offline. Jag kan arkivera uppgifterna och jag kan schemalägga dem och vi skulle kunna göra dessa saker mycket enkelt i den meningen att du faktiskt skulle kunna, som en DBA, som använder det här verktyget, ställa in det och typ av gå bort från det. Det finns inte mycket handhållning som kommer att äga rum när du har ställt in det som det ska vara. Som jag sa, den svåraste delen av något av detta, tror jag, är inte att ställa in vad du vill granska, det är att veta vad du vill ställa in för att granska.
Och som jag sa, djurets natur med revision, du måste hålla informationen i sju år, så det är meningsfullt att fokusera på de områden som är känsliga i naturen. Men om du vill gå tillvägagångssättet för att samla in allt kan du absolut, det anses bara inte vara den bästa praxis. Så ur den synvinkeln vill jag bara påminna folk om att om detta är något som är av intresse kan du gå in på webbplatsen på IDERA.com och ladda ner en testversion av detta och leka med det själv. När det gäller det kostnadsfria verktyget som vi talade om tidigare, det är, det är gratis, du kan ladda ner det och använda det för alltid, oavsett om du använder produkten för Compliance Manager. Och det coola med kolumnsökverktyget är att våra resultat som du kommer fram till, och jag kan faktiskt visa att jag tror är att du kommer att kunna exportera den informationen och sedan kunna importera den till Compliance Manager också. Jag ser det inte, jag vet att det är här, där är det. Detta är bara ett exempel på det. Det är här man hittar relaterade känsliga data.
Nu har det här fallet gått ut och jag har verkligen tittat på allt, men du har bara massor av saker som vi kan leta efter. Kreditkortsnummer, adresser, namn, alla sådana saker. Och vi identifierar var den finns i databasen och sedan kan du fatta beslut om du verkligen vill granska den informationen eller inte. Men det är definitivt ett sätt att göra det mycket lättare för dig att definiera din omfattning av revision när du tittar på ett sådant verktyg.
Jag kommer bara att gå vidare och stänga med det, och jag kommer att gå vidare och skicka tillbaka det till Eric.
Eric Kavanagh: Det är en fantastisk presentation. Jag älskar hur du verkligen kommer in i de skitiga detaljerna där och visar oss vad som händer. För i slutet av dagen finns det ett system som kommer att få åtkomst till vissa poster, som kommer att ge dig en rapport, som kommer att få dig att berätta din historia, vare sig det är till en tillsynsmyndighet eller en revisor eller någon i ditt team, så det är bra att du vet att du är beredd om och när, eller som och när, den personen kommer och bankar, och det är naturligtvis den obehagliga situationen som du försöker undvika. Men om det händer, och det förmodligen kommer att hända i dessa dagar, vill du vara säker på att du har dina I: s prickade och dina T: er korsade.
Det finns en bra fråga från en publikmedlem som jag vill kasta ut till dig kanske först, Bullett, och sedan om en presentatör kanske vill kommentera det, känn dig fri. Och sedan kanske Dez ställer en fråga och Robin. Så frågan är, är det rättvist att säga att för att göra alla de saker du har nämnt måste du starta en ansträngning med dataklassificering på en grundnivå? Du måste känna till dina uppgifter när de framstår som en värdefull potentiell tillgång och göra något åt det. Jag tror att du skulle hålla med, Bullett, eller hur?
Bullett Manale: Ja, absolut. Jag menar, du måste lära känna dina uppgifter. Och jag inser att jag inser att det finns många applikationer som finns ute och att det finns många olika saker som har rörliga delar i din organisation. Kolumnsökverktyget är till stor hjälp när det gäller att gå ett steg i riktningen för att förstå dessa data bättre. Men ja, det är mycket viktigt. Jag menar, du har möjlighet att gå in i brandslangarna och granska allt, men det är bara mycket mer utmanande på det sättet logistiskt när du pratar om att behöva lagra dessa data och rapportera mot dessa data. Och då behöver du fortfarande veta var den informationen är för när du kör dina rapporter kommer du att behöva visa dina revisorer den informationen också. Så jag tror att, som sagt, den största utmaningen när jag pratar med databasadministratörer är att veta, ja.
Eric Kavanagh: Ja, men kanske Robin så tar vi dig in riktigt snabbt. Det verkar för mig att 80/20-regeln gäller här, eller hur? Du kommer antagligen inte hitta alla system med skivor som spelar någon roll om du är i någon medelstor eller stor organisation, men om du fokuserar på - som Bullett föreslog här - till exempel PeopleSoft eller andra system med skivor som är dominerande i företaget, det är där du fokuserar 80 procent av din ansträngning och sedan är 20 procent på de andra systemen som kan finnas där någonstans, eller hur?
Robin Bloor: Jag är säker, ja. Jag menar, du vet, jag tror att problemet med den här tekniken, och jag tror att det förmodligen är värt att kommentera den, men problemet med den här tekniken är, hur implementerar du den? Jag menar, det finns definitivt en brist på kunskap, låt oss säga, i de flesta organisationer vad gäller även antalet databaser som finns där ute. Du vet, det finns väldigt mycket brist på lager, låt oss säga. Du vet, frågan är, låt oss föreställa oss att vi börjar i en situation där det inte finns en särskilt välskött överensstämmelse, hur tar du denna teknik och injicerar den i miljön, inte bara i, du vet, teknik villkor, ställa upp saker, men som vem hanterar det, vem bestämmer vad? Hur börjar du skonföra detta till en äkta typ av att göra sitt jobb?
Bullett Manale: Jag menar, det är en bra fråga. Utmaningen i många fall är att jag menar att du måste börja ställa frågorna redan från början. Jag har stött på många företag där de, du vet, kanske de är ett privat företag och de har förvärvat, det finns en initial, typ av, först, typ av, vägbump, om du vill kalla det så. Till exempel, om jag just nu har blivit ett börsnoterat företag på grund av förvärvet, måste jag gå tillbaka och förmodligen räkna ut några saker.
Och i vissa fall pratar vi med organisationer som, du vet, även om de är privata, de följer reglerna om SOX-efterlevnad, helt enkelt för att i händelse av att de vill bli förvärvade vet de att de måste uppfylla kraven. Du vill definitivt inte ta tillvägagångssättet av bara, "Jag behöver inte oroa mig för det här nu." Varje typ av regelverk som PCI eller SOX eller vad som helst, du vill investera i att göra forskningen eller förståelse för var den känsliga informationen är, annars kan du hitta dig själv att hantera några betydande, rejäl böter. Och det är mycket bättre bara att investera den tiden, du vet, hitta den informationen och kunna rapportera mot dem och visa att kontrollerna fungerar.
Ja, när det gäller att sätta upp det, som sagt, det första jag skulle rekommendera till personer som gör sig redo att möta en granskning, är att bara gå ut och göra en kortvarig granskning av databasen, och ta reda på, du vet, i sitt bästa försök, att försöka ta reda på var den känsliga informationen är. Och det andra tillvägagångssättet skulle vara att börja med kanske ett större nät i termer av omfattningen av revision, och sedan sakta bromsa dig ner när du, typ, räknar ut var de områden inom systemet är relaterade till känslig information. Men jag önskar att jag kunde säga att det finns ett enkelt svar på den frågan. Det kommer förmodligen att variera ganska mycket från en organisation till den andra och typen av efterlevnad och verkligen hur, du vet, hur mycket struktur de har inom sina applikationer och hur många har, olika applikationer de har, vissa kan vara specialskrivna applikationer, så det kommer verkligen att bero på situationen i många fall.
Eric Kavanagh: Gå vidare, Dez, jag är säker på att du har en fråga eller två.
Dez Blanchfield: Jag är angelägen om att bara få lite inblick i dina iakttagelser kring effekterna för organisationerna ur ett folkmässigt perspektiv. Jag tror att ett av de områden där jag ser det största värdet för denna specifika lösning är att när människor vaknar på morgonen och går på arbete på olika nivåer i organisationen, vaknar de upp med en serie eller en kedja av ansvar som de måste ta itu med. Och jag är angelägen om att få lite inblick i vad du ser där ute med och utan vilka typer av verktyg du pratar om. Och det sammanhang jag pratar om här är från styrelsens ordförande till VD och CIO och C-sviten. Och nu har vi chefer för högre risker, som tänker mer på de typer av saker vi pratar om här i efterlevnad och styrning, och sedan har vi fått nya chefer för rollspel, chef för datatjänsteman, vem, du vet, ännu mer bekymrad över det.
Och på sidan av var och en av dem, runt CIO, har vi IT-chefer på en sida med, typ av du vet, tekniska leads och sedan databasledningar. Och i det operativa utrymmet har vi utvecklingschefer och utvecklingsledningar och sedan enskilda utvecklingar, och de går också tillbaka till databasadministrationsskiktet. Vad ser du kring reaktionen från var och en av dessa olika delar av verksamheten på utmaningen med efterlevnad och lagstiftningsrapportering och deras inställning till det? Ser du att folk kommer med detta med en glädje och kan se fördelarna med det, eller ser du att de motvilligt drar sina fötter till den här saken och bara, du vet, gör det för en fästing i rutan? Och vilka typer av svar ser du när de ser din programvara?
Bullett Manale: Ja, det är en bra fråga. Jag skulle säga att den här produkten, försäljningen av den här produkten, främst drivs av någon som sitter i heta sätet, om det är meningsfullt. I de flesta fall är det DBA, och ur vårt perspektiv, med andra ord, de vet att det kommer en revision och de kommer att vara ansvariga, eftersom de är DBA: erna, för att kunna tillhandahålla den information som revisor kommer att fråga. De kan göra det genom att skriva sina egna rapporter och skapa sina egna anpassade spår och alla sådana saker. Verkligheten är att de inte vill göra det. I de flesta fall ser DBA inte riktigt fram emot att ha de konversationerna med revisoren till att börja med. Du vet, jag skulle hellre säga att vi kan gå till ett företag och säga, "Hej, det här är ett bra verktyg och du kommer att älska det, " och visa dem alla funktioner och de kommer att köpa det.
Verkligheten är att de vanligtvis inte kommer att titta på det här verktyget om de faktiskt inte kommer att möta en revision eller den andra sidan av det myntet är att de har gjort en granskning och misslyckats med det och nu är de får höra att få lite hjälp eller så kommer de att bli böter. Jag skulle säga att när du visar den här produkten för folk, de vet definitivt värdet på det eftersom det sparar massor av tid i termer av att de måste ta reda på vad de vill rapportera om, den typen av saker. Alla dessa rapporter är redan inbyggda, larmmekanismerna är på plats, och sedan med den tredje frågan kan det också i många fall vara en utmaning. Eftersom jag kan visa er rapporter hela dagen men om du inte kan bevisa för mig är de rapporterna faktiskt giltiga då, du vet, det är mycket tuffare förslag för mig som DBA att kunna visa det. Men vi har utarbetat tekniken och hasningstekniken och alla dessa typer av saker för att kunna hjälpa till att se till att uppgifterna i granskningsspårens integritet bevaras.
Och så det är de saker som, det är mina observationer när det gäller de flesta människor vi pratar med. Du vet, det finns definitivt, i olika organisationer, du vet som, du kommer att höra om, du vet som, Target, till exempel, hade ett dataöverträdelse, och du vet, jag menar, när andra organisationer hör om böter och dessa slags saker folk börjar, det höjer ett ögonbryn, så förhoppningsvis svarar det på frågan.
Dez Blanchfield: Ja, definitivt. Jag kan föreställa mig några DBA när de äntligen ser vad som kan göras med verktyget bara inser att de har fått sina sena nätter och helger också. Tids- och kostnadsminskningar och andra saker som jag ser när lämpliga verktyg används för hela detta problem, och det är det, tre veckor satt jag med en bank här i Australien. De är en global bank, en topp tre bank, de är massiva. Och de hade ett projekt där de var tvungna att rapportera om överensstämmelse med förmögenhetsförvaltningen och särskilt risken, och de tittade på 60 veckors arbete för ett par hundra människor. Och när de visades hur ett verktyg som dig själv bara kunde automatisera processen, den här känslan, utseendet på deras ansikten när de insåg att de inte behövde spendera X antal veckor med hundratals människor som gjorde en manuell process var som de hittade Gud. Men det utmanande då var hur man faktiskt lägger den i plan, som Dr. Robin Bloor antydde, du vet, detta är något som blir en blandning av beteendemässigt, kulturellt skifte. På de nivåer du har att göra med, som hanterar detta direkt på applikationsnivå, vilken typ av förändring ser du när de börjar använda ett verktyg för att göra den typ av rapportering och revision och kontroller som du kan erbjuda, som i motsats till vad de kan ha gjort manuellt? Hur ser det ut när de faktiskt genomförs?
Bullett Manale: Frågar du, vad är skillnaden i att hantera detta manuellt mot att använda det här verktyget? Är det frågan?
Dez Blanchfield: Tja, specifikt effekten av verksamheten. Så till exempel, om vi försöker leverera efterlevnad i en manuell process, vet du, tar vi alltid lång tid med många människor. Men jag antar att för att sätta lite sammanhang kring frågan, som du vet, talar vi om en enda person som kör det här verktyget som ersätter potentiellt 50 personer och kan göra samma sak i realtid eller i timmar kontra månader? Är det sådant, vad visar det sig generellt vara?
Bullett Manale: Jag menar, det handlar om ett par saker. Den ena har förmågan att svara på dessa frågor. En del av dessa saker kommer inte att göras så lätt. Så ja, den tid det tar att göra saker hemodlade, att skriva rapporterna på egen hand, att ställa in spåren eller de utökade händelserna för att samla in data manuellt, kan ta mycket tid. Egentligen ska jag ge dig några, jag menar, det här gäller inte riktigt databaser i allmänhet men precis som efter att Enron hände och SOX blev utbredd, var jag hos ett av de större oljebolagen i Houston, och vi räknade för Jag tror att det var som om 25 procent av våra affärskostnader var relaterade till SOX-efterlevnad.
Nu var det rätt efter och det var typ av det första första steget på SOX men saken med, jag skulle säga, du vet, du får mycket fördel genom att använda det här verktyget i den meningen att det inte kräver mycket människor att göra detta och många olika typer av människor att göra det. Och som sagt, DBA är inte vanligtvis killen som verkligen ser fram emot att ha de konversationerna med revisorerna. Så i många fall ser vi att DBA kan ladda ner detta och kunna ge rapporten gränssnitt till revisoren och de kan ta bort sig helt ur ekvationen snarare än att behöva vara involverade. Så, du vet, det är en enorm besparing också när det gäller resursen när du kan göra det.
Dez Blanchfield: Du pratar om massiva kostnadsminskningar, eller hur? Organisationerna tar inte bara bort risken och omkostnaderna för det, men jag menar att du i princip talar om en betydande kostnadsminskning, A) operativt och även B) i det faktum att du vet om de faktiskt kan ge verkliga- rapportering om tidsöverensstämmelse om att det finns avsevärt minskad risk för ett dataöverträdelse eller någon juridisk böter eller påverkan för att den inte uppfyller kraven, eller hur?
Bullett Manale: Ja, absolut. Jag menar, för att inte uppfylla det finns det alla typer av dåliga saker som händer. De kan använda det här verktyget och det skulle vara bra eller inte, och de kommer att få reda på hur dåligt det egentligen är. Så ja, det är inte bara verktyget självklart, du kan göra dina kontroller och allt utan ett sådant verktyg. Som jag sa, det kommer bara att ta mycket mer tid och kostnad.
Dez Blanchfield: Det är bra. Så Eric, jag kommer att gå tillbaka till dig eftersom jag tror att takeaway för mig är att, du vet, marknaden är fantastisk. Men också, väsentligen, är det värt sin vikt i guld på grund av att det att kunna undvika den kommersiella effekten av en fråga som äger rum eller att kunna minska tiden det tar att rapportera och hantera efterlevnad bara gör det, du vet, verktyget betalar för sig själv omedelbart av ljudet av saker.
Eric Kavanagh: Det är exakt rätt. Tack så mycket för din tid idag, Bullett. Tack till er alla ute för er tid och uppmärksamhet, och Robin och Dez. En annan bra presentation idag. Tack till våra vänner på IDERA för att vi låter oss ge dig detta innehåll gratis. Vi kommer att arkivera denna webcast för senare visning. Arkivet är vanligtvis uppe inom ungefär en dag. Och låt oss veta vad du tycker om vår nya webbplats, insideanalysis.com. En helt ny design, en helt ny look and feel. Vi skulle gärna höra din feedback och med det ska jag ge dig farväl, folkens. Du kan maila mig. Annars kommer vi att komma ihåg dig nästa vecka. Vi har sju webbsändningar under de kommande fem veckorna eller något liknande. Vi kommer att vara upptagna. Och vi kommer att vara på Strata-konferensen och IBM Analyst-toppmötet i New York senare denna månad. Så om du är där, stanna förbi och säga hej. Var försiktig, folkens. Hejdå.
