Av Techopedia Staff, 27 oktober 2016
Takeaway: Värd Eric Kavanagh diskuterar databassäkerhet med Robin Bloor, Dez Blanchfield och IDERAs Ignacio Rodriguez.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Hej och välkommen tillbaka, återigen till Hot Technologies. Jag heter Eric Kavanagh; Jag kommer att vara din värd för webbsändningen idag och det är ett hett ämne och det kommer aldrig att bli ett hett ämne. Detta är ett hett ämne nu på grund av, uppriktigt sagt, alla överträdelser som vi hör om och jag kan garantera att det aldrig kommer att försvinna. Så ämnet idag, den exakta titeln på showen jag skulle säga, är "The New Normal: Att hantera verkligheten i en osäker värld." Det är exakt vad vi har att göra med.
Vi har din värd, din verkligen, just där. För några år sedan, tänk på att jag borde förmodligen uppdatera mitt foto; det var 2010. Tiden flyger. Skicka ett e-postmeddelande med mig om du vill göra några förslag. Så detta är vår vanliga "heta" bild för Hot Technologies. Hela syftet med denna show är verkligen att definiera ett visst utrymme. Så idag pratar vi uppenbarligen om säkerhet. Vi tar en mycket intressant vinkel på det, faktiskt med våra vänner från IDERA.
Och jag vill påpeka att du som våra publikmedlemmar spelar en viktig roll i programmet. Var snäll inte blyg. Skicka oss en fråga när som helst så kommer vi i kö för frågor och svar om vi har tillräckligt med tid för det. Vi har tre människor online idag, Dr. Robin Bloor, Dez Blanchfield och Ignacio Rodriguez, som ringer in från en otäckt plats. Så först av allt, Robin, du är den första presentatören. Jag ger dig nycklarna. Ta bort det.
Dr. Robin Bloor: Okej, tack för det, Eric. Säkra databas - Jag antar att vi kan säga att sannolikheten för att de mest värdefulla data som något företag faktiskt ordnar över finns i en databas. Så det finns en hel serie säkerhetssaker vi kan prata om. Men vad jag trodde att jag skulle göra är att prata om att säkra databasen. Jag vill inte ta bort något från den presentation som Ignacio kommer att ge.
Så låt oss börja med, det är lätt att tänka på datasäkerhet som ett statiskt mål, men det är det inte. Det är ett rörligt mål. Och detta är ganska viktigt att förstå i den meningen att de flesta människors IT-miljöer, särskilt stora företagens IT-miljöer, förändras hela tiden. Och eftersom de förändras hela tiden, attackytan, områden där någon kan försöka på ett eller annat sätt, antingen från insidan eller utsidan, att kompromissa med datasäkerheten, förändras hela tiden. Och när du gör något liknande, uppgraderar du en databas, du har ingen aning om du bara har skapat någon sårbarhet för dig själv. Men du är inte medveten om och kanske aldrig får veta om förrän något usel händer.
Det finns en kort översikt av datasäkerhet. Först och främst är datastöld inget nytt och data som är värdefulla riktas in. Det är normalt lätt att uträtta för en organisation vad de data de behöver för att sätta mest skydd på är. Ett märkligt faktum är att den första, eller vad vi kan hävda vara den första datorn, byggdes av brittisk underrättelse under andra världskriget med ett syfte i åtanke, och det var att stjäla data från tysk kommunikation.
Så datastöld har varit en del av IT-branschen ganska mycket sedan det började. Det blev mycket mer allvarligt med internet. Jag tittade på en logg över antalet dataintrång som inträffade år efter år efter år. Och antalet hade raket över 100 år 2005 och från och med den tiden tenderade det att bli sämre och sämre för varje år.
Större mängder data blir stulen och ett större antal hacks äger rum. Och det är de hacks som rapporteras. Det finns ett mycket stort antal incidenter som inträffar där företaget aldrig säger något för det finns inget som tvingar det att säga någonting. Så det håller dataöverträdelsen tyst. Det finns många spelare i hackingbranschen: regeringar, företag, hackergrupper, individer.
En sak som jag bara tycker att det är intressant att nämna, när jag åkte till Moskva tror jag att det var någon gång för fyra år sedan, det var en mjukvarukonferens i Moskva, jag pratade med en journalist som specialiserat sig på datahackning. Och han hävdade - och jag är säker på att han har rätt, men jag vet inte det annat än att han är den enda personen som någonsin har nämnt det för mig, men - det finns ett ryskt företag som heter The Russian Business Network, det har förmodligen en ryska namn men jag tror att det är den engelska översättningen av den, som faktiskt hyrs in för att hacka.
Så om du är en stor organisation överallt i världen och vill göra något för att skada din konkurrens kan du anställa dessa människor. Och om du anställer dessa människor får du väldigt sannolik förnöjbarhet om vem som låg bakom hacken. För om det alls upptäcks vem som är bakom hacket, kommer det att indikera att det antagligen är någon i Ryssland som gjorde det. Och det ser inte ut som om du försökte skada en konkurrent. Och jag tror att det ryska affärsnätverket faktiskt har anlitats av regeringar för att göra saker som hacka i banker för att försöka ta reda på hur terrorist pengar rör sig. Och det görs med plausibel förnekelse av regeringar som aldrig kommer att erkänna att de faktiskt någonsin gjort det.
Tekniken för attack och försvar utvecklas. För länge sedan brukade jag gå till Chaos Club. Det var en webbplats i Tyskland där du kunde registrera dig och du bara kunde följa samtal från olika människor och se vad som var tillgängligt. Och jag gjorde det när jag tittade på säkerhetsteknologi, tror jag omkring 2005. Och jag gjorde det bara för att se vad som gick då och det som förvånade mig var antalet virus, där det i princip var ett open source-system Jag var på gång och människor som hade skrivit virus eller förbättrade virus bara fastade koden där uppe för någon att använda. Och det hände mig vid den tiden att hackare kan vara väldigt, väldigt smarta, men det finns väldigt många hackare som inte nödvändigtvis är smarta alls, men de använder smarta verktyg. Och några av dessa verktyg är anmärkningsvärt smarta.
Och den sista punkten här: företag har en omsorgsplikt över sina uppgifter, oavsett om de äger dem eller inte. Och jag tror att det blir mer och mer realiserat än det brukade vara. Och det blir mer och mer, låt oss säga, dyra för ett företag att faktiskt genomgå ett hack. Om hackarna kan de vara belägna var som helst, kanske svåra att komma till rätta även om de är korrekt identifierade. Många av dem är mycket skickliga. Betydande resurser, de har botnät överallt. Den senaste DDoS-attacken som inträffade tros ha kommit från över en miljard enheter. Jag vet inte om det är sant eller om det bara är en reporter som använder ett runt nummer, men säkert ett stort antal robotenheter användes för att göra en attack på DNS-nätverket. Vissa lönsamma företag, det finns regeringsgrupper, det finns ekonomisk krigföring, det finns cyberwarfare, allt händer där ute, och det är osannolikt, jag tror att vi sa i preshowet, det kommer troligtvis aldrig att ta slut.
Överensstämmelse och föreskrifter - det finns ett antal saker som faktiskt pågår. Det finns många efterlevnadsinitiativ som är sektorbaserade, du vet - läkemedelssektorn eller banksektorn eller hälsosektorn - kan ha specifika initiativ som människor kan följa, olika typer av bästa praxis. Men det finns också många officiella förordningar som, eftersom de är lag, de har påföljder för alla som bryter mot lagen. De amerikanska exemplen är HIPAA, SOX, FISMA, FERPA, GLBA. Det finns vissa standarder, PCI-DSS är en standard för kortföretag. ISO / IEC 17799 bygger på att försöka få en gemensam standard. Detta är ägandet av data. Nationella bestämmelser skiljer sig från land till land, även i Europa, eller man kanske borde säga, särskilt i Europa där det är väldigt förvirrande. Och det finns en GDPR, en global dataskyddsförordning som för närvarande förhandlas fram mellan Europa och USA för att försöka harmonisera i förordningar eftersom det finns så många, vanligtvis som de är, internationellt, och sedan finns det molntjänster som du kanske tror inte att dina uppgifter var internationella, men de gick internationella så fort du gick in i molnet, eftersom de flyttade ur ditt land. Så det är en uppsättning regler som förhandlas på ett eller annat sätt för att hantera dataskydd. Och det mesta har att göra med en individs data, som naturligtvis innehåller ganska mycket all identitetsdata.
Saker att tänka på: sårbarhet i databasen. Det finns en lista över sårbarheter som är kända och rapporterade av databasleverantörer när de upptäcks och lappas så snabbt som möjligt, så det finns allt detta. Det finns saker som hänför sig till det när det gäller att identifiera sårbara data. En av de stora och mest framgångsrika hackorna på betalningsdata gjordes till ett betalningsföretag. Det tog senare över eftersom det var tvunget att gå till likvidation om det inte gjorde det, men uppgifterna stal inte från någon av de operativa databaserna. Uppgifterna stulen från en testdatabas. Det hände precis så att utvecklarna just hade tagit en delmängd av data som var riktiga data och använt den, utan något som helst skydd, i en testdatabas. Testdatabasen hackades och en hel del människors personliga ekonomiska detaljer togs från den.
Säkerhetspolitiken, särskilt när det gäller åtkomstsäkerhet när det gäller databaser, vem som kan läsa, vem som kan skriva, vem som kan bevilja behörigheter, finns det något sätt att någon kan kringgå något av detta? Sedan finns det naturligtvis krypteringar från databaser som tillåter det. Det finns kostnaden för ett säkerhetsöverträdelse. Jag vet inte om det är standardpraxis inom organisationer, men jag vet att vissa liksom högsta säkerhetsansvariga försöker ge cheferna en idé om vad kostnaden för ett säkerhetsöverträdelse faktiskt är innan det händer snarare än efter. Och de, till exempel, behöver göra det för att se till att de får rätt budgetmängd för att kunna försvara organisationen.
Och sedan attackytan. Attackytan verkar växa hela tiden. Det är år efter år att attackytan bara verkar växa. Sammanfattningsvis är intervall en annan punkt, men datasäkerhet är vanligtvis en del av DBA: s roll. Men datasäkerhet är också en samarbetsaktivitet. Du måste ha, om du gör säkerhet, måste du ha en fullständig uppfattning om säkerhetsskydd för organisationen som helhet. Och det måste finnas företagspolitik för detta. Om det inte finns företagspolicyer slutar du bara med små lösningar. Du vet, gummiband och plast, typ av, försök att stoppa säkerheten.
Så med det sagt tror jag att jag överlämnar till Dez som förmodligen kommer att ge dig olika krigshistorier.
Eric Kavanagh: Take it away, Dez.
Dez Blanchfield: Tack, Robin. Det är alltid en tuff handling att följa. Jag kommer att komma till detta från motsatt ände av spektrumet bara för att, antar jag, ge oss en känsla av omfattningen av den utmaning du står inför och varför vi borde göra mer än bara sitta upp och uppmärksamma detta . Den utmaning vi ser nu med skalan och kvantiteten och volymen, hastigheten som dessa saker händer, är att det jag hör runt på plats nu med många CXO: er, inte bara CIO: er, utan säkert CIO: er är de som deltar där pengarna stannar, är att de anser att dataöverträdelser snabbt blir normen. Det är något de nästan förväntar sig att hända. Så de tittar på detta med tanke på: "Okej, när vi blir kränkta - inte om - när vi blir kränkta, vad behöver vi ha gjort åt det här?" Och sedan börjar konversationerna, vad gör de i traditionella kantmiljöer och routrar, switchar, servrar, intrångsdetektering, intrångsinspektion? Vad gör de i själva systemen? Vad gör de med uppgifterna? Och sedan kommer allt tillbaka till vad de gjorde med sina databaser.
Låt mig bara beröra några exempel på några av dessa saker som har fångat mycket människors fantasi och sedan borrat ner till, typ av, bryt dem upp lite. Så vi har hört i nyheterna att Yahoo - förmodligen det största antalet som människor har hört är ungefär en halv miljon, men det visar sig faktiskt att det är inofficiellt mer som en miljard - jag hörde ett landligt antal på tre miljarder, men det är nästan halva världsbefolkningen så jag tror att det är lite högt. Men jag har fått det verifierat från ett antal människor i relevanta utrymmen som tror att det finns drygt en miljard poster som har brutits ut från Yahoo. Och detta är bara ett förbluffande nummer. Nu ser och tänker en del spelare, det är bara webmail-konton, ingen stor sak, men då lägger du till det faktum att många av dessa webmail-konton och ett nyfiken högt antal, högre än jag hade förväntat mig, faktiskt är betalda konton. Det är där människor lägger in sina kreditkortsuppgifter och de betalar för att ta bort annonserna, eftersom de tröttnar på annonserna och så $ 4 eller $ 5 per månad är de villiga att köpa en webmail och molnlagringstjänst som inte har annonser, och jag är en av dem, och jag har det över tre olika leverantörer där jag ansluter mitt kreditkort.
Så då får utmaningen lite mer uppmärksamhet eftersom det inte bara är något som finns där ute som en kasta en rad med att säga, "Åh, Yahoo har förlorat, låt oss säga, mellan 500 miljoner och 1 000 miljoner konton, " 1 000 miljoner gör det låter väldigt stort och webbmailkonton, men kreditkortsuppgifter, förnamn, efternamn, e-postadress, födelsedatum, kreditkort, pin-nummer, vad du vill, lösenord, och sedan blir det ett mycket mer skrämmande koncept. Och igen säger folk till mig, "Ja, men det är bara webbtjänst, det är bara webmail, ingen stor sak." Och sedan säger jag, "Ja, ja, det kan också ha använts Yahoo-konton i Yahoo-pengarna för att köpa och sälja aktier. ”Då blir det mer intressant. Och när du börjar borras ner i det inser du att okej, det här är faktiskt mer än bara mammor och pappor hemma, och tonåringar, med meddelandekonton, detta är faktiskt något där människor har gjort affärer.
Så det är den ena änden av spektrumet. Den andra änden av spektrumet är att en mycket liten, allmän praxis, vårdleverantör i Australien hade cirka 1 000 poster stulna. Var ett internt jobb, någon lämnade, de var bara nyfikna, de gick ut genom dörren, i det här fallet var det en 3, 5 tums diskett. Det var för en liten stund sedan - men du kan berätta mediaens era - men de handlade om gammal teknologi. Men det visade sig att anledningen till att de tog informationen var att de bara var nyfiken på vem som var där. Eftersom de hade ganska många människor i denna lilla stad, som var vår nationella huvudstad, som var politiker. Och de var intresserade av vem som var där och var deras liv var och all den slags information. Så med ett mycket litet dataöverträdelse som gjordes internt var ett betydande stort antal politiker i den australiensiska regeringen förmodligen ute i allmänheten.
Vi har två olika ändar på spektrumet att tänka på. Nu är verkligheten att dessa saker är helt omväxlande och jag har en bild som vi kommer att hoppa till mycket väldigt snabbt här. Det finns ett par webbplatser som listar alla typer av data, men just den här kommer från en säkerhetsspecialist som hade webbplatsen där du kan gå och söka efter din e-postadress eller ditt namn, och det visar dig varje datahändelse överträdelse under de senaste 15 åren som han har lyckats få tag på och sedan ladda in i en databas och verifiera, och det kommer att säga om du har blivit pwned, som termen är. Men när du börjar titta på några av dessa nummer och den här skärmdumpen har inte uppdaterats med hans senaste version, som innehåller ett par, som Yahoo. Men tänk bara på typerna av tjänster här. Vi har Myspace, vi har LinkedIn, Adobe. Adobes intressanta eftersom människor ser och tänker, vad betyder Adobe? De flesta av oss som laddar ner Adobe Reader av någon form, många av oss har köpt Adobe-produkter med kreditkort, det är 152 miljoner människor.
Nu, till Robins punkt tidigare, är det här mycket stora siffror, det är lätt att bli överväldigad av dem. Vad händer när du har fått 359 miljoner konton som har brutits? Det finns ett par saker. Robin betonade det faktum att dessa data alltid finns i en databas av någon form. Det är det kritiska meddelandet här. Nästan ingen på den här planeten, som jag är medveten om, som driver ett system av någon form, lagrar inte det i en databas. Men det intressanta är att det finns tre olika typer av data i databasen. Det finns säkerhetsrelaterade saker som användarnamn och lösenord, som vanligtvis är krypterade, men alltid finns det många exempel där de inte är. Det finns den faktiska kundinformationen kring deras profil och data de har skapat om det är en hälsopost eller om det är ett e-postmeddelande eller ett direktmeddelande. Och sedan finns den faktiska inbäddade logiken, så det här kan lagras procedurer, det kan vara en hel massa regler, om + detta + då + det. Och alltid är det bara ASCII-text som sitter fast i databasen, väldigt få människor sitter där och tänker, ”Det här är affärsregler, det är så våra data rörde sig och kontrolleras, vi borde potentiellt kryptera det när det är i vila, och när det är i motion kanske dekrypterar vi det och förvarar det i minnet, ”men det borde helst vara så bra.
Men det kommer tillbaka till denna nyckelpunkt att alla dessa uppgifter finns i en databas av någon form och oftare är fokuset bara historiskt sett på routrar och switchar och servrar och till och med lagring, och inte alltid på databasen på baksidan. Eftersom vi tror att vi har täckt kanten av nätverket och det är, liksom, en typisk gammal, typ av, bor i ett slott och du lägger en vallgrav runt det och du hoppas att de onda inte kommer att kunna simma. Men sedan plötsligt räddade dåliga killarna hur man kunde göra utökade stegar och kasta dem över vallgraven och klättra över vallgraven och klättra uppför murarna. Och plötsligt är din vallgrad ganska mycket värdelös.
Så vi befinner oss nu i scenariot där organisationerna befinner sig i ett fångstläge i en sprint. De snubblar bokstavligen över alla system, enligt min åsikt, och säkert min erfarenhet av att det inte alltid är bara dessa enhörningar på webben, som vi ofta hänvisar till dem, oftare är det inte traditionella företagsorganisationer som bryts. Och du behöver inte ha mycket fantasi för att ta reda på vem de är. Det finns webbplatser som en som heter pastebin.net och om du går till pastebin.net och du bara skriver in e-postlista eller lösenordslista kommer du att hamna med hundratusentals poster om dagen som läggs till där människor listar exempeluppsättningar av upp till tusen poster med förnamn, efternamn, kreditkortsuppgifter, användarnamn, lösenord, dekrypterade lösenord förresten. Där människor kan ta tag i den listan, gå och verifiera tre eller fyra av dem och bestämma att, ja, jag vill köpa den listan och det finns vanligtvis någon form av mekanism som tillhandahåller någon form av anonym gateway till den som säljer uppgifterna.
Vad som är intressant är att när den anslutna företagaren inser att de kan göra det, krävs det inte så mycket fantasi för att inse att om du spenderar 1 000 USD för att köpa en av dessa listor, vad är det första du gör med det? Du går inte och försöker spåra kontona, du lägger tillbaka en kopia av det på pastbin.net och du säljer två exemplar för 1 000 dollar vardera och tjänar 1 000 dollar. Och det här är barn som gör det här. Det finns några extremt stora professionella organisationer runt om i världen som gör detta för att leva. Det finns till och med statliga nationer som attackerar andra stater. Du vet, det talas mycket om att Amerika attackerar Kina, Kina attackerar Amerika, det är inte så enkelt, men det finns definitivt statliga organisationer som bryter mot system som alltid drivs av databaser. Det är inte bara ett fall av små organisationer, det är också länder kontra länder. Det ger oss tillbaka till den frågan om, var lagras data? Det finns i en databas. Vilka kontroller och mekanismer finns där? Eller alltid är de inte krypterade, och om de är krypterade är det inte alltid all data, kanske det bara är lösenordet som saltas och krypteras.
Och runt detta har vi en rad utmaningar med vad som finns i dessa data och hur vi ger tillgång till data och SOX-efterlevnad. Så om du tänker på förmögenhetsförvaltning eller bank, har du organisationer som oroar sig för utmaningen. du har organisationer som oroar sig för efterlevnaden i företagsutrymmet; du har regeringens efterlevnad och myndighetskrav; du har scenarier nu där vi har lokala databaser; vi har databaser i tredje parts datacenter; Vi har databaser som sitter i molnmiljöer, så dess molnmiljöer är alltid inte alltid i landet. Och så detta blir en större och större utmaning, inte bara ur ren säkerhet låt-inte-bli-hackad synvinkel, men också, hur uppfyller vi alla olika nivåer av efterlevnad? Inte bara HIPAA- och ISO-standarderna, men det finns bokstavligen dussintals och dussintals sådana på statlig nivå, nationell nivå och global nivå som passerar gränserna. Om du gör affärer med Australien kan du inte flytta regeringsuppgifter. Alla australiska privata uppgifter kan inte lämna nationen. Om du är i Tyskland är det ännu strängare. Och jag vet att Amerika rör sig mycket snabbt av detta av flera skäl också.
Men det leder mig tillbaka till hela utmaningen om hur vet du vad som händer i din databas, hur övervakar du den, hur berättar du vem som gör vad i databasen, vem har visningar av olika tabeller och rader och kolumner och fält, när läser de den, hur ofta läser de den och vem spårar den? Och jag tror att det tar mig till min sista punkt innan jag överlämnar till vår gäst idag som kommer att hjälpa oss att prata om hur vi löser detta problem. Men jag vill lämna oss med den här tanken och det vill säga mycket fokus är på kostnaden för företaget och kostnaden för organisationen. Och vi kommer inte att täcka denna punkt i detalj idag, men jag vill bara lämna den i våra tankar för att fundera över och det är att det finns en uppskattning på ungefär mellan 135 och 585 US dollar per post för att rensa upp efter ett brott. Så investeringen du gör i din säkerhet kring routrar och switchar och servrar är allt bra och bra och brandväggar, men hur mycket har du investerat i din databassäkerhet?
Men det är en falsk ekonomi och när Yahoos överträdelse inträffade nyligen, och jag har det på god myndighet, är det ungefär en miljard konton, inte 500 miljoner. När Verizon köpte organisationen för något som 4, 3 miljarder, så snart brottet inträffade bad de om en miljard dollar tillbaka eller rabatt. Om du gör matematiken och säger att det finns ungefär en miljard poster som har brutits, en miljardrabatt, blir uppskattningen $ 135 till $ 535 för att rensa upp en post nu $ 1. Vilket, återigen, är farcical. Det kostar inte $ 1 för att rensa upp en miljard poster. På $ 1 per post för att rensa upp en miljard poster för ett brott av den storleken. Du kan inte ens lägga ut ett pressmeddelande för den typen av kostnad. Och så fokuserar vi alltid på de interna utmaningarna.
Men en av sakerna, tror jag, och det kräver att vi tar detta mycket på allvar på databasnivå, varför detta är ett mycket, mycket viktigt ämne för oss att prata om, och det är att vi aldrig pratar om människan vägtull. Vilken är den mänskliga vägtull som vi har på detta? Och jag ska ta ett exempel innan jag snabbt slår ihop. LinkedIn: 2012 hackades LinkedIn-systemet. Det fanns ett antal vektorer och jag kommer inte gå in på det. Och hundratals miljoner konton stulna. Folk säger ungefär 160 udda miljoner, men det är faktiskt ett mycket större antal, det kan vara så många som cirka 240 miljoner. Men det överträdelsen tillkännagavs inte förr tidigare i år. Det är fyra år som hundratals miljoner människors poster finns där ute. Nu var det vissa som betalade för tjänster med kreditkort och vissa personer med gratis konton. Men LinkedIn är intressant, för inte bara fick de tillgång till dina kontouppgifter om du har brutits, utan de fick också tillgång till all din profilinformation. Så vem du var kopplad till och alla kontakter du hade, och vilka typer av jobb de hade och vilka typer av färdigheter de hade och hur länge de hade jobbat på företag och all den typen av information och deras kontaktuppgifter.
Så tänk på den utmaning som vi har när det gäller att säkra uppgifterna i dessa databaser, och säkra och hantera själva databasesystemen, och på flödet för påverkan, den mänskliga tullen för den informationen som finns där ute i fyra år. Och sannolikheten för att någon kan dyka upp på en semester någonstans i Sydostasien och de har haft sina data där ute i fyra år. Och kanske någon har köpt en bil eller fått ett hemlån eller köpt tio telefoner under året på kreditkort, där de skapade ett falskt ID för den informationen som fanns där ute i fyra år - för till och med LinkedIn-uppgifterna gav dig tillräckligt med information för att skapa ett bankkonto och ett falskt ID - så går du på planet, du går på semester, du landar och du kastas i fängelse. Och varför kastas du i fängelse? Tja, för att du fick ditt ID stulit. Någon skapade ett falskt ID och agerade som du och hundratusentals dollar och de gjorde det här fyra år och du visste inte ens om det. Eftersom det är ute, hände det bara.
Så jag tror att det leder oss till denna grundutmaning om hur vet vi vad som händer på våra databaser, hur spårar vi det, hur övervakar vi det? Och jag ser fram emot att höra hur våra vänner på IDERA har kommit fram till en lösning för att hantera det. Och med det kommer jag att överlämna.
Eric Kavanagh: Okej, Ignacio, golvet är ditt.
Ignacio Rodriguez: Okej. Välkommen, välkomna alla. Jag heter Ignacio Rodriguez, bättre känd som Iggy. Jag är med IDERA och en produktchef för säkerhetsprodukter. Riktigt bra ämnen som vi just har behandlat, och vi måste verkligen oroa oss för dataöverträdelserna. Vi måste ha härdade säkerhetspolicyer, vi måste identifiera sårbarheter och utvärdera säkerhetsnivåerna, kontrollera användarrättigheter, kontrollera serversäkerheten och följa revisioner. Jag har gjort revisioner i min tidigare historia, mest på Oracle-sidan. Jag har gjort en del på SQL Server och gjorde dem med verktyg eller i grund och botten hemmagjorda skript, vilket var bra men du måste skapa ett förvar och se till att förvaret var säkert, hela tiden måste hålla skriptet med ändringar från revisorerna, vad har du.
Så i verktyg, om jag hade vetat att IDERA var ute och hade ett verktyg, skulle jag mer än troligt ha köpt det. Men hur som helst, vi kommer att prata om Secure. Det är en av våra produkter i vår säkerhetsproduktlinje och vad den i princip gör är att vi tittar på säkerhetspolicyn och kartlägger dessa till lagstiftningsriktlinjer. Du kan visa en fullständig historik över SQL Server-inställningar och du kan också i princip göra en baslinje av dessa inställningar och sedan jämföra mot framtida förändringar. Du kan skapa en ögonblicksbild, som är en baslinje för dina inställningar, och sedan kunna spåra om något av dessa saker har ändrats och också få varning om de ändras.
En av de saker som vi gör bra är att förebygga säkerhetsrisker och kränkningar. Säkerhetsrapportkortet ger dig en översikt över de bästa säkerhetsproblemen på servrarna och sedan klassificeras också varje säkerhetskontroll som hög, medellång eller låg risk. På dessa kategorier eller säkerhetskontroller kan alla dessa ändras. Låt oss säga om du har några kontroller och använder en av de mallar som vi har och du bestämmer, ja, våra kontroller indikerar eller vill att denna sårbarhet inte egentligen är en hög, utan ett medium, eller vice versa. Du kanske har några som är märkta som medium men i din organisation kan de kontroller du vill märka dem, eller betrakta dem som höga, alla inställningar konfigureras av användaren.
En annan kritisk fråga som vi måste titta på är att identifiera sårbarheterna. Förstå vem som har tillgång till vad och identifiera var och en av användarens effektiva rättigheter för alla SQL Server-objekt. Med verktyget kommer vi att kunna gå igenom och titta på rättigheterna för alla SQL Server-objekt och vi kommer att se en skärmdump av det här ganska snart. Vi rapporterar och analyserar också användar-, grupp- och rolltillstånd. En av de andra funktionerna är att vi levererar detaljerade säkerhetsriskrapporter. Vi har out-of-the-box rapporter och innehåller flexibla parametrar för dig för att skapa de typer av rapporter och visa information som revisorer, säkerhetsansvariga och chefer behöver.
Vi kan också jämföra säkerhets-, risk- och konfigurationsförändringar över tid, som jag nämnde. Och de är med ögonblicksbilderna. Och dessa ögonblicksbilder kan konfigureras så långt du vill göra dem - varje månad, kvartalsvis, årligen - som kan schemaläggas i verktyget. Och igen kan du göra jämförelser för att se vad som har förändrats och vad som är trevligt med det är att om du hade en överträdelse kan du skapa en ögonblicksbild efter att den hade korrigerats, göra en jämförelse och du skulle se att det fanns en hög nivå risk förknippad med föregående ögonblicksbild och sedan rapportera, ser du faktiskt i nästa ögonblicksbild när det korrigerats att det inte längre var ett problem. Det är ett bra granskningsverktyg som du kan ge till revisoren, en rapport som du kan ge revisorerna och säga: "Se, vi hade den här risken, vi mildrade den och nu är det inte längre någon risk." Och, igen, jag som nämns med ögonblicksbilderna som du kan varna när en konfiguration ändras, och om en konfiguration ändras och upptäcks, som innebär en ny risk, kommer du också att meddelas om detta.
Vi får några frågor om vår SQL Server-arkitektur med Secure, och jag vill göra en korrigering av bilden här där det står ”Collection Service.” Vi har inga tjänster, det borde ha varit “Management and Collection Server. ”Vi har vår konsol och sedan vår Management and Collection Server och vi har en agentlös fångst som går ut till databaserna som har registrerats och samlar in data genom jobb. Och vi har ett SQL Server Repository och vi arbetar tillsammans med SQL Server Reporting Services för att schemalägga rapporter och skapa anpassade rapporter också. Nu på ett säkerhetsrapportkort är detta den första skärmen som du kommer att se när SQL Secure startas. Du ser enkelt vilka kritiska objekt du har upptäckt. Och återigen har vi höjderna, medierna och lågen. Och sedan har vi också de policyer som spelas med de särskilda säkerhetskontrollerna. Vi har en HIPAA-mall; vi har IDERA-säkerhetsnivå 1, 2 och 3 mallar; Vi har PCI-riktlinjer. Dessa är alla mallar som du kan använda och återigen kan du skapa din egen mall, baserad på dina egna kontroller också. Och återigen är de modifierbara. Du kan skapa dina egna. Vilken som helst av de befintliga mallarna kan användas som en baslinje, då kan du ändra dem som du vill.
En av de trevliga sakerna att göra är att se vem som har behörigheter. Och med den här skärmen här kommer vi att kunna se vilka SQL Server-inloggningar som finns på företaget och du kommer att kunna se alla tilldelade och effektiva rättigheter och behörigheter på serverdatabasen på objektnivå. Vi gör det här. Du kommer att kunna välja igen databaserna eller servrarna och sedan kunna ta fram rapporten om SQL Server-behörigheter. Så kunna se vem som har vilken tillgång till vad. En annan trevlig funktion är att du kommer att kunna jämföra säkerhetsinställningar. Låt oss säga att du hade standardinställningar som behövde ställas in i ditt företag. Du kan sedan göra en jämförelse av alla dina servrar och se vilka inställningar som ställts in för de andra servrarna i ditt företag.
Återigen, policymallarna, det här är några av de mallar som vi har. Du använder i grund och botten en av dessa, skapa din egen. Du kan skapa din egen policy, som det ses här. Använd en av mallarna och du kan ändra dem efter behov. Vi kan också se SQL Server Effektiva rättigheter. Detta kommer att verifiera och bevisa att behörigheterna är korrekt inställda för användare och roller. Återigen kan du gå ut och titta och se och verifiera att behörigheten är korrekt inställd för användare och roller. Sedan med SQL Server Object Access Rights kan du sedan bläddra och analysera SQL Server-objektträdet ner från servernivå ner till objektnivåens roller och slutpunkter. Och du kan direkt se tilldelade och effektiva ärvda behörigheter och säkerhetsrelaterade egenskaper på objektnivå. Detta ger dig en bra bild av tillgångarna som du har på dina databasobjekt och vem som har tillgång till dessa.
Vi har återigen våra rapporter som vi har. Det är konserverade rapporter, vi har flera som du kan välja mellan för att göra din rapportering. Och många av dessa kan anpassas eller så kan du ha dina kundrapporter och använda det i samband med rapporteringstjänsterna och kunna skapa dina egna anpassade rapporter därifrån. Nu Snapshot-jämförelser, detta är en ganska cool funktion, tror jag, där du kan gå ut där och du kan göra en jämförelse av dina ögonblicksbilder som du har tagit och titta för att se om det var några skillnader i antalet. Finns det några objekt tillagda, var det behörigheter som har ändrats, allt vi kanske kunde se vilka förändringar som har gjorts mellan de olika ögonblicksbilderna. En del människor kommer att titta på dessa på en månatlig nivå - de kommer att göra en snapshot varje månad och sedan göra en jämförelse varje månad för att se om något har förändrats. Och om det inte fanns något som skulle ha ändrats, något som gick till förändringskontrollmöten, och du ser att vissa behörigheter har ändrats kan du gå tillbaka för att se vad som har hänt. Det här är en ganska trevlig funktion där du kan göra en jämförelse igen av allt som granskas inom ögonblicksbilden.
Sedan din bedömning jämförelse. Detta är en annan trevlig funktion som vi har där du kan gå ut och titta på bedömningarna och sedan göra en jämförelse av dem och märka att jämförelsen här hade ett SA-konto som inte har inaktiverats i den här senaste ögonblicksbilden som jag har gjort - det är nu korrigerad. Det här är en ganska trevlig sak där du kan visa att okej, vi hade vissa risker, de identifierades av verktyget, och nu har vi mildrat dessa risker. Och återigen är detta en bra rapport för att visa revisorerna att faktiskt dessa risker har minskats och tagits hand om.
Sammanfattningsvis är databassäkerhet kritiskt, och jag tror många gånger vi tittar på överträdelser som kommer från externa källor och ibland ägnar vi inte så mycket uppmärksamhet åt interna överträdelser och det är några av de saker som vi måste se upp för. Och Secure hjälper dig där för att se till att det inte finns några privilegier som inte behöver tilldelas, du vet, se till att alla dessa säkerheter är korrekt inställda på kontona. Se till att dina SA-konton har lösenord. Kontrollerar också så långt som, har dina krypteringsnycklar, har de exporterats? Bara flera olika saker som vi letar efter och vi kommer att varna dig om att det var ett problem och på vilken nivå av fråga det är. Vi behöver ett verktyg, många professionella behöver verktyg för att hantera och övervaka behörigheter för databasåtkomst, och vi tittar faktiskt på att ge en omfattande förmåga att kontrollera databasbehörigheter och spåra åtkomstaktiviteter och minska risken för överträdelser.
En annan del av våra säkerhetsprodukter är att det finns en WebEx som täcktes och en del av presentationen som vi talade om tidigare var data. Du vet vem som har åtkomst till vad, vad har du, och det är vårt SQL Compliance Manager-verktyg. Och det finns en inspelad WebEx på det verktyget och som faktiskt gör att du kan övervaka vem som har åtkomst till vilka tabeller, vilka kolumner, du kan identifiera tabeller som har känsliga kolumner, så långt som födelsedatum, patientinformation, vilka typer av tabeller och se faktiskt vem som har tillgång till den informationen och om den har åtkomst.
Eric Kavanagh: Okej, så låt oss dyka in i frågorna, antar jag, här. Kanske, Dez, jag ska kasta den till dig först, och Robin, chime in som du kan.
Dez Blanchfield: Ja, jag har klarat att ställa en fråga från andra och tredje bilden. Vad är det typiska användningsfallet du ser för det här verktyget? Vilka är de vanligaste användarnas typer som du ser som använder detta och sätter det i spel? Och på baksidan av den typiska, typ av, använda fallmodellen, hur går de åt det? Hur genomförs det?
Ignacio Rodriguez: Okej, det typiska användningsfallet som vi har är DBA som har tilldelats ansvaret för åtkomstkontroll för databasen, som ser till att alla behörigheter är inställda som de behöver och sedan hålla reda på, och deras standarder på plats. Du vet, dessa vissa användarkonton kan bara ha tillgång till dessa tabeller osv. Och vad de gör med det är att se till att dessa standarder har ställts in och att dessa standarder inte har förändrats genom tiden. Och det är en av de stora saker som människor använder det för är att spåra och identifiera om några förändringar görs som inte är kända om.
Dez Blanchfield: Eftersom de är de läskiga, eller hur? Är det att du kan ha ett, låt oss säga, ett strategidokument, har du en politik som ligger till grund för det, har du efterlevnad och styrning under det, och du följer policyerna, du följer styrningen och det får grönt ljus och sedan plötsligt en månad senare rullar någon ut en förändring och av någon anledning går det inte igenom samma förändringsgranskning eller förändringsprocess, eller vad det än skulle vara, eller så har projektet bara gått vidare och ingen vet.
Har du några exempel som du kan dela - och jag vet uppenbarligen att det inte alltid är något du delar eftersom kunder är lite bekymrade över det, så vi behöver inte nödvändigtvis namnge namn - men ge oss ett exempel på var du kanske har sett detta faktiskt, du vet, en organisation har infört detta på plats utan att inse det och de hittade bara något och insåg, "Wow, det var värt tio gånger, vi hittade bara något vi inte insåg." Har du fått något exempel där människor har implementerat detta och sedan upptäckt att de hade ett större problem eller ett verkligt problem som de inte insåg att de hade och då läggs du omedelbart till på julekortlistan?
Ignacio Rodriguez: Tja, jag tror att det största som vi har sett eller har rapporterat är vad jag just nämnde, vad gäller tillgången som någon hade haft. Det finns utvecklare och när de implementerade verktyget insåg de verkligen inte att X-mängd av dessa utvecklare hade så mycket åtkomst till databasen och hade tillgång till vissa objekt. Och en annan sak är skrivskyddskonton. Det fanns några skrivskyddskonton som de hade, kom för att ta reda på att dessa skrivskyddade konton faktiskt var, hade infoga data och radera privilegier också. Det är där vi har sett en viss fördel för användarna. Den stora saken, återigen, att vi har hört att människor gillar, kan återigen spåra förändringarna och se till att ingenting gör det möjligt för dem.
Dez Blanchfield: Precis som Robin framhävde, har du scenarier som människor inte ofta tänker igenom, eller hur? När vi ser fram emot så tänker vi, om du gör allt enligt reglerna, och jag finner, och jag är säker på att du ser det också - berätta om du inte håller med det - organisationer fokuserar så starkt på att utveckla strategi och policy och efterlevnad och styrning och KPI och rapportering, att de ofta blir så fixerade av att de inte tänker på utdelarna. Och Robin hade ett riktigt bra exempel som jag kommer att stjäla från honom - ledsen Robin - men exemplet är den andra gången där en live kopia av databasen, en stillbild och sätta den i utvecklingstest, eller hur? Vi gör dev, vi gör tester, vi gör UAT, vi gör systemintegration, allt det slags och sedan gör vi ett gäng test av efterlevnad nu. Ofta har dev-test, UAT, SIT faktiskt en efterlevnadskomponent på det där vi bara ser till att allt är friskt och säkert, men inte alla gör det. Detta exempel som Robin gav med en kopia av en live-kopia av databasen satt i ett test med utvecklingsmiljö för att se om det fortfarande fungerar med livedata. Mycket få företag luta sig bakom och tänker, "Händer det till och med eller är det möjligt?" De är alltid fixerade på produktionsmaterialet. Hur ser implementeringsresan ut? Pratar vi om dagar, veckor, månader? Hur ser en vanlig distribution ut för en medelstor organisation?
Ignacio Rodriguez: dagar. Det är inte ens dagar, jag menar, det är bara ett par dagar. Vi har precis lagt till en funktion där vi kan registrera många, många servrar. Istället för att behöva gå in där i verktyget och säga att du hade 150 servrar, var du tvungen att gå in där individuellt och registrera servrarna - nu behöver du inte göra det. Det finns en CSV-fil som du skapar och vi tar bort den automatiskt och vi håller den inte där på grund av säkerhetsproblem. Men det är en annan sak som vi måste tänka på, är att du kommer att ha en CSV-fil där ute med användarnamn / lösenord.
Vad vi gör är att vi automatiskt tar bort det igen, men det är ett alternativ du har. Om du vill gå in där individuellt och registrera dem och inte vill ta den risken, kan du göra det. Men om du vill använda en CSV-fil, placera den på en plats som är säker, peka applikationen på den platsen, den kör den CSV-filen och sedan är den automatiskt inställd att ta bort den filen när den är klar. Och det kommer att se till att kontrollera att filen är borttagen. Den längsta polen i sanden som vi hade så långt som implementeringen var registrering av själva servrarna.
Dez Blanchfield: Okej. Nu pratade du om rapporter. Kan du ge oss lite mer detaljerad och inblick i vad som kommer förbundna så långt som att rapportera bara, antar jag, upptäcktskomponenten att titta på vad som finns där och rapportera om det, nationens nuvarande tillstånd, vad som kommer före- byggda och förbakade så långt som rapporter kring det aktuella tillståndet för efterlevnad och säkerhet, och hur lätt är de utdragbara? Hur bygger vi på dem?
Ignacio Rodriguez: Okej. Några av de rapporter vi har, vi har rapporter som behandlar cross-server, inloggningskontroller, datainsamlingsfilter, aktivitetshistorik och sedan riskbedömningsrapporterna. Och alla misstänkta Windows-konton. Det finns många, många här. Se misstänkta SQL-inloggningar, serverinloggningar och användarkartläggning, användarrättigheter, alla användarrättigheter, serverroller, databasroller, viss mängd sårbarhet som vi har eller autentiseringsrapporter i blandat läge, gästaktiverade databaser, OS-sårbarhet via XPS, de utökade procedurerna, och sedan de sårbara fasta roller. Det är några av de rapporter vi har.
Dez Blanchfield: Och du nämnde att de är tillräckligt betydelsefulla och ett antal av dem, vilket är en logisk sak. Hur lätt är det för mig att skräddarsy det? Om jag kör en rapport och jag får den här fantastiska stora grafen, men jag vill ta ut några stycken som jag inte riktigt är så intresserad av och lägga till ett par andra funktioner, finns det en rapportförfattare, finns det något slags gränssnitt och verktyg för att konfigurera och skräddarsy eller till och med potentiellt bygga en annan rapport från början?
Ignacio Rodriguez: Vi skulle då be användarna att använda Microsoft SQL Report Services för att göra det och vi har många kunder som faktiskt kommer att ta några av rapporterna, anpassa och schemalägga dem när de vill. Några av dessa killar vill se dessa rapporter på månadsvis eller veckobasis och de kommer att ta den information som vi har, flytta den till Reporting Services och sedan göra det därifrån. Vi har inte en rapportförfattare integrerad med vårt verktyg, men vi utnyttjar Reporting Services.
Dez Blanchfield: Jag tror att det är en av de största utmaningarna med dessa verktyg. Du kan komma dit och hitta saker, men då måste du kunna dra ut det, rapportera det till människor som inte nödvändigtvis är DBA och systemingenjörer. Det finns en intressant roll som har uppstått i min erfarenhet och det är, du vet, riskombud har alltid varit i organisationer och att de övervägande har funnits och ett helt annat antal risker som vi har sett nyligen, medan nu med data överträdelser blir inte bara en sak utan en verklig tsunami, CRO har gått från att vara, du vet, HR och efterlevnad och arbetshälsa och säkerhetsfokus nu till cyberisk. Du vet, brott, hacking, säkerhet - mycket mer teknisk. Och det blir intressant eftersom det finns många CRO: er som kommer från en MBA-stamtavla och inte en teknisk stamtavla, så de måste ta sig runt huvudet, typ av vad det här betyder för övergången mellan cyberrisken att flytta till en CRO, och så vidare. Men det stora som de vill är bara synlighetsrapportering.
Kan du berätta för oss något kring positioneringen när det gäller efterlevnad? Uppenbarligen är en av de stora styrkorna med detta att du kan se vad som händer, du kan övervaka det, du kan lära dig, du kan rapportera om det, du kan reagera på det, du kan till och med föregripa vissa saker. Den övergripande utmaningen är efterlevnad av regeringar. Finns det viktiga delar av detta som medvetet länkar till befintliga efterlevnadskrav eller branschöverensstämmelse som PCI, eller något liknande för närvarande, eller är det något som kommer ner på färdplanen? Passar det, till exempel, inom ramen för sådana som COBIT-, ITIL- och ISO-standarder? Om vi använder detta verktyg, ger det oss en serie kontroller och balanser som passar in i dessa ramverk, eller hur bygger vi det in i dessa ramverk? Var är positionen med den typen av saker i åtanke?
Ignacio Rodriguez: Ja, det finns mallar som vi har som vi levererar med verktyget. Och vi kommer till punkten igen där vi omvärderar våra mallar och vi kommer att lägga till och det kommer att komma fler snart. FISMA, FINRA, några ytterligare mallar som vi har, och vi granskar vanligtvis mallarna och ser för att se vad som har förändrats, vad behöver vi lägga till? Och vi vill faktiskt komma till den punkt där, du vet, säkerhetskraven har förändrats ganska mycket, så vi tittar på ett sätt att göra detta expansibelt i farten. Det är något vi tittar på i framtiden.
Men just nu tittar vi på kanske skapa mallar och kunna hämta mallarna från en webbplats; du kan ladda ner dem. Och det är så vi hanterar det - vi hanterar dem genom mallar, och vi letar efter sätt i framtiden här för att göra det lätt expansivt och snabbt. För när jag brukade göra revisioner, vet du, saker och ting förändras. En revisor skulle komma en månad och nästa månad vill de se något annat. Då är det en av utmaningarna med verktygen, att kunna göra dessa förändringar och få det du behöver, och det är, typ av, där vi vill komma till.
Dez Blanchfield: Jag antar att en revisors utmaning förändras regelbundet mot bakgrund av att världen går snabbare. Och en gång i tiden skulle kravet från en revisionssynpunkt, enligt min erfarenhet, bara vara ren kommersiell efterlevnad, och sedan blev det teknisk efterlevnad och nu är det operativt efterlevnad. Och det finns alla dessa andra, du vet, varje dag som någon dyker upp och de mäter inte bara dig på något som ISO 9006 och 9002, de tittar på alla slags saker. Och jag ser nu att de 38 000 serierna blir en stor sak också i ISO. Jag föreställer mig att det bara kommer att bli mer och mer utmanande. Jag håller på att överlämna till Robin eftersom jag har tagit bandbredden.
Tack så mycket för det, och jag kommer definitivt att spendera mer tid på att lära känna det eftersom jag faktiskt inte insåg att det faktiskt var helt så ingående. Så tack, Ignacio, jag ska överlämna till Robin nu. En bra presentation, tack. Robin, över till dig.
Dr. Robin Bloor: Okej Iggy, jag kommer att kalla dig Iggy, om det är okej. Vad som förvirrar mig, och jag tror att med tanke på några av de saker som Dez sade i sin presentation, är det väldigt mycket som händer där ute som du måste säga att folk verkligen inte tar hand om uppgifterna. Du vet, särskilt när det gäller att du bara ser en del av isberget och det förmodligen är mycket som händer att ingen rapporterar. Jag är intresserad av ditt perspektiv på hur många av de kunder som du är medveten om, eller potentiella kunder som du är medveten om, har den skyddsnivå som du, typ av, erbjuder med inte bara detta, men också din datatillgångsteknik? Jag menar, vem där ute är ordentligt utrustade för att hantera hotet, är frågan?
Ignacio Rodriguez: Vem är ordentligt utrustad? Jag menar, många kunder som vi verkligen inte har behandlat någon typ av revision, du vet. De har haft några, men det stora är att försöka hålla jämna steg med det och försöka upprätthålla det och se till. Den stora frågan som vi har sett är - och till och med det när jag gjorde efterlevnaden, är - om du kör dina skript skulle du göra det en gång per kvartal när revisorerna skulle komma in och du har hittat ett problem. Gissa vad, det är redan för sent, revision är där, revisorerna är där, de vill ha sin rapport, de flaggar den. Och så får vi antingen ett märke eller så fick vi höra, hej, vi måste lösa dessa problem, och det är där detta skulle komma in. Det skulle vara mer av en proaktiv typ där du kan hitta din risk och mildra risken och det är vad våra kunder letar efter. Ett sätt att vara något proaktiv i motsats till att vara reaktiv när revisorer kommer in och finner att några av åtkomstarna inte är där de behöver vara, andra människor har administrativa privilegier och de borde inte ha dem, sådana saker. Och det är där vi har sett mycket feedback från, som människor gillar verktyget och använder det för.
Dr. Robin Bloor: Okej, en annan fråga som jag har som är, i en mening, en uppenbar fråga också, men jag är bara nyfiken. Hur många kommer faktiskt till dig i kölvattnet av en hack? Där, du vet, du får affärer, inte för att de tittade på deras miljö och tänkte att de måste säkras på ett mycket mer organiserat sätt, men faktiskt är du där helt enkelt för att de redan har drabbats av något av smärta.
Ignacio Rodriguez: I min tid här på IDERA har jag inte sett en. För att vara ärlig med dig, är det mesta av samspelet jag har haft med kunderna som jag har varit involverat mer i framtiden och försöker börja granska och började titta på privilegier osv. Som sagt, jag har själv, inte har upplevt under min tid här, att vi har haft någon som har kommit efter överträdelse som jag känner till.
Dr. Robin Bloor: Åh, det är intressant. Jag skulle ha trott att det hade varit åtminstone några. Jag tittar faktiskt på detta, men lägger också till det, alla komplexiteter som faktiskt gör data säkra över hela företaget på alla sätt och i alla aktiviteter du gör. Erbjuder du konsultverksamhet direkt för att hjälpa människor? Jag menar, det är tydligt att du kan köpa verktyg, men enligt min erfarenhet köper människor ofta sofistikerade verktyg och använder dem mycket dåligt. Erbjuder du specifikt konsultföretag - vad du ska göra, vem du ska träna och liknande?
Ignacio Rodriguez: Det finns vissa tjänster du kan, såväl som supporttjänster, som gör att en del av detta kan ske. Men när det gäller konsulttjänster tillhandahåller vi inga konsulttjänster utan utbildning, du vet, hur man använder verktygen och sådana saker, något av det skulle hanteras med supportnivån. Men i sig har vi ingen serviceavdelning som går ut och gör det.
Dr. Robin Bloor: Okej. När det gäller den databas du täcker, nämner presentationen här bara Microsoft SQL Server - gör du Oracle också?
Ignacio Rodriguez: Vi kommer att utvidgas till Oracle-området med Compliance Manager först. Vi kommer att starta ett projekt med det så vi kommer att titta på att utöka detta till Oracle.
Dr. Robin Bloor: Och kommer du sannolikt att åka någon annanstans?
Ignacio Rodriguez: Ja det är något som vi måste titta på i färdplanerna och se hur det är, men det är några av de saker som vi överväger, är vilka andra databasplattformar vi behöver också attackera.
Dr. Robin Bloor: Jag var också intresserad av splittringen, jag har inte fått någon förutfattad bild av detta, men när det gäller distributioner, hur mycket av detta som faktiskt distribueras i molnet, eller är det nästan allt på plats ?
Ignacio Rodriguez: Allt på plats. Vi tittar på att utvidga Secure också för att täcka Azure, ja.
Dr. Robin Bloor: Det var Azure-frågan, du är inte där ännu men du åker dit, det är mycket meningsfullt.
Ignacio Rodriguez: Ja, vi åker dit väldigt snart.
Dr. Robin Bloor: Ja, min förståelse från Microsoft är att det finns väldigt mycket action med Microsoft SQL Server i Azure. Det blir, om du vill, en viktig del av vad det är som de erbjuder. Den andra frågan som jag är intresserad av - den är inte teknisk, den är mer som en hur-gör-du-engagera frågan - vem är köparen för detta? Uppmanas ni av IT-avdelningen eller kontaktas ni av CSO: er, eller är det en annan variation av människor? När något sådant övervägs, är det en del av att titta på en hel serie saker för att säkra miljön? Vad är situationen där?
Ignacio Rodriguez: Det är en blandning. Vi har CSO: er, många gånger kommer säljteamet att nå ut och prata med DBA. Och sedan har DBA, återigen, chartrats med att få någon form av revisionsprocesser på plats. Och därifrån kommer de att utvärdera verktygen och rapportera upp kedjan och fatta ett beslut om vilken del de vill köpa. Men det är en blandad påse av vem som kommer att kontakta oss.
Dr. Robin Bloor: Okej. Jag tror att jag kommer att lämna tillbaka till Eric nu för att vi till exempel har gjort timmen, men det kan finnas några publikfrågor. Eric?
Eric Kavanagh: Ja, vi har bränt igenom mycket bra innehåll här. Här är en riktigt bra fråga som jag kommer att kasta till dig från en av de deltagande. Han pratar om blockchain och vad du pratar om, och han frågar, finns det ett möjligt sätt att migrera en skrivskyddad del av en SQL-databas till något liknande det blockchain erbjuder? Det är lite tufft.
Ignacio Rodriguez: Ja, jag ska vara ärlig med dig, jag har inget svar på det.
Eric Kavanagh: Jag kommer att slänga det till Robin. Jag vet inte om du hörde den frågan, Robin, men han frågar bara, finns det ett sätt att migrera den skrivskyddade delen av en SQL-databas till något liknande det blockchain erbjuder? Vad tycker du om det?
Dr. Robin Bloor: Det är som om du ska migrera databasen kommer du också att migrera databastrafiken. Det finns en hel uppsättning komplexitet involverad i att göra det. Men du skulle inte göra det av någon annan anledning än att göra data okränkbara. Eftersom en blockchain kommer att bli långsammare att komma åt, så, du vet, om hastighet är din sak - och det är nästan alltid saken - då skulle du inte göra det. Men om du ville tillhandahålla, typ av, nycklad krypterad tillgång till en del av den till vissa människor som gör den typen av saker, kan du göra det, men du måste ha en mycket god anledning. Du är mycket mer benägna att lämna den där den är och säkra den där den är.
Dez Blanchfield: Ja, det håller jag med om jag snabbt kan väga in. Jag tror att utmaningen med blockchain, till och med blockchain som är offentligt ute, den används på bitcoin - vi har svårt att skala det utöver, till och med fyra transaktioner per minut på ett fullständigt distribuerat sätt. Inte så mycket på grund av den beräknade utmaningen, även om den är där, har de hela noderna bara svårt att hålla jämna steg med databasvolymerna som rör sig bakåt och framåt och mängden data som kopieras eftersom det är spelningar nu, inte bara megs.
Men också, jag tror att den viktigaste utmaningen är att du behöver ändra applikationens arkitektur eftersom det i en databas främst handlar om att föra allt till en central plats och du har den klient-servertypmodellen. Blockchain är det omvända; det handlar om distribuerade kopior. Det är mer som BitTorrent på många sätt, och det är att det finns många kopior där med samma data. Och du vet, som Cassandra och databaser i minnet där du distribuerar det och många servrar kan ge dig kopior av samma data från ett distribuerat index. Jag tror att de två viktiga delarna, som du sa, Robin, är: en, om du vill säkra den och se till att den inte kan bli stulen eller hackad, det är bra, men det är inte nödvändigtvis en transaktionsplattform ännu, och vi Det har jag upplevt med bitcoin-projektet. Men i teorin har andra löst det. Men arkitektoniskt sett vet inte många applikationer där ute bara hur man frågar och läser från en blockchain.
Det finns mycket arbete att göra där. Men jag tror att nyckelpunkten med frågan där, bara om jag kan, är skälet till att flytta det till en blockchain, jag tror att den fråga som ställs är, kan du ta ut data ur en databas och lägga dem i någon form som är mer säker? Och svaret är att du kan lämna den i databasen och bara kryptera den. Det finns gott om teknik nu. Kryptera bara data i vila eller i rörelse. Det finns ingen anledning till att du inte kan ha krypterad data i minnet och i databasen på disken, vilket är en mycket enklare utmaning eftersom du inte har en enda arkitektonisk förändring. Ofta de flesta databasplattformar, det är faktiskt bara en funktion som aktiveras.
Eric Kavanagh: Ja, vi har en sista fråga jag ska kasta till dig, Iggy. Det är ganska bra. Ur ett SLA- och kapacitetsplaneringsperspektiv, vilken typ av skatt finns det genom att använda ditt system? Med andra ord, någon extra latens eller genomströmningskostnad om någon i ett produktionsdatabassystem vill involvera IDERAs teknik här?
Ignacio Rodriguez: Vi ser verkligen inte så mycket påverkan. Återigen är det en agentlös produkt och det beror på, som jag nämnde tidigare, ögonblicksbilderna. Säkert är baserat på ögonblicksbilder. Det kommer att gå ut där och faktiskt skapa ett jobb som kommer att gå ut där baserat på de intervaller du har valt. Antingen vill du göra det igen, varje vecka, dagligen, varje månad. Det kommer att gå ut där och utföra det jobbet och sedan samla in data från fallen. Vid den punkten kommer då lasten tillbaka till hanterings- och insamlingstjänsterna, när du börjar göra jämförelser och allt detta spelar inte belastningen på databasen någon roll i det. All den belastningen finns nu på hanterings- och insamlingsservern, så långt det går att göra jämförelser och allt rapportering och allt detta. Den enda gången du träffar databasen är alltid när den gör själva ögonblicksbilden. Och vi har inte haft några rapporter om att det verkligen skadar produktionsmiljöerna.
Eric Kavanagh: Ja, det är en riktigt bra poäng som du gör där. I princip kan du bara ställa in hur många stillbilder du tar, vad tidsintervallet är, och beroende på vad det kan hända, men det är väldigt intelligent arkitektur. Det är bra grejer. Tja, ni är ute i frontlinjen och försöker skydda oss från alla de hackare vi pratade om under de första 25 minuterna av showen. Och de är ute, folk, gör inga misstag.
Tja, lyssna, vi kommer att lägga en länk till denna webcast, arkiven, på vår webbplats insideanalysis.com. Du kan hitta saker på SlideShare, du kan hitta det på YouTube. Och folk, bra grejer. Tack för din tid, Iggy, jag älskar ditt smeknamn förresten. Med det säger vi dig farväl, folkens. Tack så mycket för din tid och uppmärksamhet. Vi kommer att komma ihåg dig nästa gång. Hejdå.
