Door Techopedia Staff, 27 oktober 2016
Takeaway: gastheer Eric Kavanagh bespreekt databasebeveiliging met Robin Bloor, Dez Blanchfield en IDERA's Ignacio Rodriguez.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Hallo en welkom, nogmaals, bij Hot Technologies. Mijn naam is Eric Kavanagh; Ik zal vandaag je gastheer zijn voor de webcast en het is een hot topic en het zal nooit een hot topic worden. Dit is nu een hot topic vanwege, eerlijk gezegd, alle inbreuken waar we over horen en ik kan je garanderen dat het nooit weg zal gaan. Dus het onderwerp van vandaag, de exacte titel van de show die ik zou moeten zeggen, is: "Het nieuwe normaal: omgaan met de realiteit van een onzekere wereld." Dat is precies waar we mee te maken hebben.
We hebben je gastheer, echt die van jou, daar. Van een paar jaar geleden, let wel, ik zou waarschijnlijk mijn foto moeten bijwerken; dat was 2010. De tijd vliegt. Stuur me een e-mail met als u enkele suggesties wilt doen. Dit is dus onze standaard 'hot'-dia voor Hot Technologies. Het hele doel van deze show is echt om een bepaalde ruimte te definiëren. Dus vandaag hebben we het uiteraard over beveiliging. We nemen er een zeer interessante invalshoek op in feite met onze vrienden van IDERA.
En ik zal erop wijzen dat u, als onze publieksleden, een belangrijke rol speelt in het programma. Wees alsjeblieft niet verlegen. Stuur ons een vraag wanneer we maar in de rij staan voor de Q&A als we er genoeg tijd voor hebben. We hebben vandaag drie mensen online, Dr. Robin Bloor, Dez Blanchfield en Ignacio Rodriguez, die belt vanuit een niet vrijgegeven locatie. Dus allereerst, Robin, jij bent de eerste presentator. Ik zal je de sleutels overhandigen. Haal het weg.
Dr. Robin Bloor: Oké, bedankt daarvoor, Eric. Database beveiligen - Ik veronderstel dat we zouden kunnen zeggen dat de kans dat de meest waardevolle gegevens die een bedrijf feitelijk presideert zich in een database bevindt. Er is dus een hele reeks beveiligingszaken waar we over kunnen praten. Maar wat ik dacht dat ik zou doen is praten over het onderwerp van het beveiligen van de database. Ik wil niets wegnemen van de presentatie die Ignacio gaat geven.
Laten we beginnen, het is gemakkelijk om gegevensbeveiliging als een statisch doel te beschouwen, maar dat is het niet. Het is een bewegend doelwit. En dit is nogal belangrijk om te begrijpen in die zin dat de IT-omgevingen van de meeste mensen, met name de IT-omgevingen van grote bedrijven, voortdurend veranderen. En omdat ze voortdurend veranderen, verandert het aanvalsoppervlak, de gebieden waar iemand op een of andere manier kan proberen, van binnenuit of van buitenaf, om gegevensbeveiliging in gevaar te brengen, voortdurend. En als je zoiets doet, upgrade je een database, je hebt geen idee of je daarmee gewoon een soort kwetsbaarheid voor jezelf hebt gecreëerd. Maar je bent je niet bewust van en komt er misschien nooit achter totdat er iets rots gebeurt.
Er is een kort overzicht van gegevensbeveiliging. Allereerst is datadiefstal niets nieuws en wordt waardevolle data getarget. Het is normaal gesproken eenvoudig om voor een organisatie te achterhalen wat de gegevens zijn die ze nodig hebben om de meeste bescherming te bieden. Een merkwaardig feit is dat de eerste, of wat we zouden kunnen beweren de eerste computer te zijn, tijdens de Tweede Wereldoorlog door de Britse inlichtingendienst is gebouwd met één doel in gedachten, en dat was het stelen van gegevens uit Duitse communicatie.
Datadiefstal is dus al sinds het begin een onderdeel van de IT-industrie. Het werd veel ernstiger met de geboorte van internet. Ik keek naar een logboek van het aantal datalekken dat jaar na jaar na jaar plaatsvond. En het aantal was in 2005 boven de 100 gestegen en vanaf dat moment werd het elk jaar erger en erger.
Er worden grotere hoeveelheden gegevens gestolen en er vindt een groter aantal hacks plaats. En dat zijn de hacks die worden gemeld. Er zijn zeer veel incidenten waarbij het bedrijf nooit iets zegt omdat er niets is dat het dwingt iets te zeggen. Dus het houdt de datalek stil. Er zijn veel spelers in de hacksector: overheden, bedrijven, hackergroepen, individuen.
Eén ding vind ik gewoon interessant om te vermelden, toen ik naar Moskou ging, denk ik dat het ongeveer vier jaar geleden was, het was een softwareconferentie in Moskou, ik sprak met een journalist die gespecialiseerd was op het gebied van gegevenshacken. En hij beweerde - en ik weet zeker dat hij gelijk heeft, maar ik weet het niet anders dan dat hij de enige persoon is die het ooit over mij heeft gezegd, maar - er is een Russisch bedrijf genaamd The Russian Business Network, het heeft waarschijnlijk een Russisch bedrijf naam, maar ik denk dat dat de Engelse vertaling ervan is, die eigenlijk is ingehuurd om te hacken.
Dus als u overal ter wereld een grote organisatie bent en iets wilt doen om uw concurrentie te schaden, kunt u deze mensen inhuren. En als je deze mensen inhuurt, krijg je een zeer plausibele ontkenning over wie er achter de hack zat. Want als het helemaal wordt ontdekt wie er achter de hack zit, geeft dit aan dat het waarschijnlijk iemand in Rusland is die het heeft gedaan. En het lijkt er niet op dat u een concurrent probeerde te beschadigen. En ik geloof dat het Russian Business Network door overheden is ingehuurd om dingen te doen zoals het hacken van banken om te proberen te achterhalen hoe terroristisch geld beweegt. En dat gebeurt met plausibele ontkenning door regeringen die nooit zullen toegeven dat ze dat ooit hebben gedaan.
De technologie van aanval en verdediging evolueert. Lang geleden ging ik naar de Chaos Club. Het was een site in Duitsland waar je je kon registreren en je kon gewoon de gesprekken van verschillende mensen volgen en zien wat er beschikbaar was. En ik deed dat toen ik naar beveiligingstechnologie keek, denk ik rond 2005. En ik deed het gewoon om te zien wat er toen aan de hand was en het ding dat me verbaasde was het aantal virussen, waar het eigenlijk een open-source systeem was Ik was aan de gang en mensen die virussen of verbeterde virussen hadden geschreven, stopten gewoon de code daar voor iedereen. En het viel me op dat moment dat hackers heel, heel slim kunnen zijn, maar er zijn ontzettend veel hackers die helemaal niet noodzakelijk slim zijn, maar ze gebruiken slimme tools. En sommige van die tools zijn opmerkelijk slim.
En het laatste punt hier: bedrijven hebben een zorgplicht voor hun gegevens, of ze die nu bezitten of niet. En ik denk dat dat steeds meer wordt gerealiseerd dan vroeger. En het wordt steeds duurder, laten we zeggen, duur voor een bedrijf om daadwerkelijk een hack te ondergaan. Over de hackers kunnen ze zich overal bevinden, misschien moeilijk te berechten, zelfs als ze goed zijn geïdentificeerd. Velen van hen zijn zeer bekwaam. Aanzienlijke bronnen, ze hebben overal botnets. Aangenomen werd dat de recente DDoS-aanval van meer dan een miljard apparaten afkomstig was. Ik weet niet of dat waar is of dat het gewoon een verslaggever is die een rond nummer gebruikt, maar er is zeker een groot aantal robotapparaten gebruikt om een aanval op het DNS-netwerk uit te voeren. Sommige winstgevende bedrijven, er zijn regeringsgroepen, er is economische oorlogvoering, er is cyberoorlogvoering, alles gebeurt daarbuiten, en het is onwaarschijnlijk, ik denk dat we in de voorwoord zeiden, het is onwaarschijnlijk dat het ooit zal eindigen.
Naleving en regelgeving - er zijn een aantal dingen die daadwerkelijk gebeuren. Er zijn veel nalevingsinitiatieven die sectorgebaseerd zijn, weet u - de farmaceutische sector of de banksector of de gezondheidssector - kunnen specifieke initiatieven hebben die mensen kunnen volgen, verschillende soorten beste praktijken. Maar er zijn ook veel officiële voorschriften die, omdat ze wet zijn, boetes hebben voor iedereen die de wet overtreedt. De voorbeelden in de VS zijn HIPAA, SOX, FISMA, FERPA, GLBA. Er zijn enkele standaarden, PCI-DSS is een standaard voor kaartbedrijven. ISO / IEC 17799 is gebaseerd op het proberen een gemeenschappelijke standaard te krijgen. Dit is het eigendom van gegevens. Nationale voorschriften verschillen van land tot land, zelfs in Europa, of misschien moet men zeggen, vooral in Europa, waar het erg verwarrend is. En er is een GDPR, een wereldwijde gegevensbeschermingsregelgeving waarover momenteel wordt onderhandeld tussen Europa en de Verenigde Staten om te proberen de voorschriften te harmoniseren, omdat er zoveel zijn, meestal als ze in feite internationaal zijn, en dan zijn er cloudservices die je misschien niet dat je gegevens internationaal waren, maar het ging internationaal zodra je de cloud inging, omdat het je land verliet. Dat zijn dus een aantal verordeningen waarover op een of andere manier wordt onderhandeld om met gegevensbescherming om te gaan. En het meeste heeft te maken met de gegevens van een persoon, die natuurlijk vrijwel alle identiteitsgegevens omvat.
Dingen om over na te denken: database kwetsbaarheden. Er is een lijst met kwetsbaarheden die bekend en gerapporteerd worden door databaseleveranciers wanneer ze zo snel mogelijk worden ontdekt en gepatcht, dus dat is er allemaal. Er zijn dingen die verband houden met het identificeren van kwetsbare gegevens. Een van de grootste en meest succesvolle hacks op betalingsgegevens werd gedaan door een betalingsverwerkingsbedrijf. Dat werd vervolgens overgenomen omdat het moest worden geliquideerd als dat niet het geval was, maar de gegevens werden niet gestolen uit een van de operationele databases. De gegevens zijn gestolen uit een testdatabase. Het gebeurde gewoon zo dat de ontwikkelaars net een subset van de gegevens hadden genomen die echte gegevens waren en deze, zonder enige bescherming, in een testdatabase hadden gebruikt. De testdatabase is gehackt en er zijn ontzettend veel persoonlijke gegevens van mensen uit gehaald.
Is het beveiligingsbeleid, met name met betrekking tot toegangsbeveiliging met betrekking tot databases, wie kan lezen, wie kan schrijven, wie kan machtigingen verlenen, bestaat er een manier waarop iemand dit kan omzeilen? Dan zijn er natuurlijk coderingen van databases die dat toestaan. Er zijn de kosten van een inbreuk op de beveiliging. Ik weet niet of het de standaardpraktijk is binnen organisaties, maar ik weet wel dat sommige, zoals hoofdbeveiligingsfunctionarissen, de leidinggevenden proberen een idee te geven van wat de kosten van een inbreuk op de beveiliging zijn voordat het gebeurt en niet daarna. En dat moeten ze eigenlijk doen om ervoor te zorgen dat ze het juiste budget krijgen om de organisatie te verdedigen.
En dan het aanvalsoppervlak. Het aanvalsoppervlak lijkt voortdurend te groeien. Jaar na jaar lijkt het aanvalsoppervlak alleen maar te groeien. Kortom, bereik is een ander punt, maar gegevensbeveiliging is meestal onderdeel van de rol van de DBA. Maar gegevensbeveiliging is ook een samenwerkingsactiviteit. Als u beveiliging uitvoert, moet u een volledig beeld hebben van de beveiligingsmaatregelen voor de organisatie als geheel. En daar moet een bedrijfsbeleid voor zijn. Als er geen bedrijfsbeleid is, krijg je slechts afzonderlijke oplossingen. Je weet wel, rubberen band en plastic, soort van, probeert te stoppen met beveiliging gebeurt.
Dat gezegd hebbende, denk ik dat ik het overdraag aan Dez, die je waarschijnlijk verschillende oorlogsverhalen gaat vertellen.
Eric Kavanagh: Take it away, Dez.
Dez Blanchfield: Bedankt, Robin. Het is altijd een moeilijke daad om te volgen. Ik kom hier aan de andere kant van het spectrum om, denk ik, ons een idee te geven van de omvang van de uitdaging waar je voor staat en waarom we meer moeten doen dan alleen rechtop zitten en hier aandacht aan besteden . De uitdaging die we nu zien met de schaal en de hoeveelheid en het volume, de snelheid waarmee deze dingen gebeuren, is dat wat ik nu overal hoor met veel CXO's, niet alleen CIO's, maar zeker CIO's zijn degenen die aanwezig zijn waar de dollar stopt, is dat ze datalekken beschouwen als snel de norm worden. Het is iets dat ze bijna verwachten te gebeuren. Dus ze bekijken dit vanuit het oogpunt van: "Oké, als we worden geschonden - niet als - als we worden geschonden, wat moeten we hier dan aan gedaan hebben?" En dan beginnen de gesprekken, wat doen ze in de traditionele edge-omgevingen en routers, switches, servers, inbraakdetectie, inbraakinspectie? Wat doen ze in de systemen zelf? Wat doen ze met de gegevens? En dan komt het allemaal terug op wat ze met hun databases deden.
Laat me even een paar voorbeelden noemen van enkele van deze dingen die veel mensen tot de verbeelding hebben getrokken en dan een beetje verder gaan om ze een beetje uit elkaar te halen. Dus we hebben in het nieuws gehoord dat Yahoo - waarschijnlijk het grootste aantal dat mensen hebben gehoord, ongeveer een half miljoen is, maar het blijkt dat het officieus meer op een miljard lijkt - ik hoorde een vreemd aantal van drie miljard, maar dat is bijna de helft van de wereldbevolking, dus ik denk dat dat een beetje hoog is. Maar ik heb het laten verifiëren door een aantal mensen in relevante ruimtes die geloven dat er iets meer dan een miljard records zijn verbroken door Yahoo. En dit is gewoon een verbijsterend nummer. Nu kijken en denken sommige spelers, nou ja, het zijn gewoon webmailaccounts, geen big deal, maar dan voeg je eraan toe dat veel van die webmailaccounts, en een opmerkelijk hoog aantal, hoger dan ik had verwacht, eigenlijk betaalde accounts zijn. Dat is waar mensen hun creditcardgegevens invoeren en ze betalen om de advertenties te verwijderen, omdat ze de advertenties beu zijn en dus $ 4 of $ 5 per maand zijn ze bereid om een webmail- en cloudopslagservice te kopen die geen advertenties heeft, en ik ben een van die, en ik heb dat bij drie verschillende providers waar ik mijn creditcard aansluit.
Dus de uitdaging krijgt iets meer aandacht, omdat het niet alleen maar iets is dat als een wegwerpregel een regel is: "Ach, Yahoo heeft, laten we zeggen, tussen 500 miljoen en 1.000 miljoen accounts verloren", 1.000 miljoen maakt het klinkt erg groot en webmailaccounts, maar creditcardgegevens, voornaam, achternaam, e-mailadres, geboortedatum, creditcard, pincode, wat je maar wilt, wachtwoorden, en dan wordt het een veel angstaanjagender concept. En weer zeggen mensen tegen mij: "Ja, maar het is gewoon webservice, het is gewoon webmail, geen big deal." En dan zeg ik: "Ja, nou, dat Yahoo-account mogelijk ook is gebruikt in de Yahoo-gelddiensten om te kopen en aandelen verkopen. 'Dan wordt het interessanter. En als je er op begint in te gaan, realiseer je je dat, oké, dit eigenlijk meer is dan alleen mama's en papa's thuis en tieners, met berichtenaccounts, dit is eigenlijk iets waar mensen zakelijke transacties hebben gedaan.
Dus dat is een kant van het spectrum. Het andere uiteinde van het spectrum is dat een heel kleine huisartsenpraktijk in Australië ongeveer 1.000 records heeft gestolen. Was een interne taak, iemand ging weg, ze waren gewoon nieuwsgierig, ze liepen de deur uit, in dit geval was het een 3, 5-inch diskette. Het was een tijdje geleden - maar je kunt het tijdperk van de media vertellen - maar ze waren op oude technologie. Maar het bleek dat de reden dat ze de gegevens namen was dat ze gewoon nieuwsgierig waren naar wie daar binnen was. Omdat ze heel veel mensen hadden in dit kleine stadje, dat onze nationale hoofdstad was, die politici waren. En ze waren geïnteresseerd in wie daar was en waar hun leven was en al dat soort informatie. Dus met een zeer kleine datalek die intern werd gedaan, was een aanzienlijk groot aantal politici in de gegevens van de Australische regering zogenaamd openbaar.
We hebben twee verschillende uiteinden van het spectrum om te overwegen. De realiteit is dat de omvang van deze dingen gewoon behoorlijk onthutsend is en ik heb een dia waar we hier heel, heel snel naartoe gaan. Er zijn een aantal websites die allerlei soorten gegevens bevatten, maar deze is van een beveiligingsspecialist die de website had waar u naar uw e-mailadres of uw naam kunt zoeken, en het zal u elk incident van gegevens laten zien schending in de afgelopen 15 jaar dat hij in staat is geweest om hem in handen te krijgen, en vervolgens in een database te laden en te verifiëren, en het zal u vertellen of u bent gepwnd, zoals de term is. Maar als je naar sommige van deze cijfers gaat kijken en deze screenshot niet is bijgewerkt met zijn nieuwste versie, die een paar bevat, zoals Yahoo. Maar denk eens aan de soorten services hier. We hebben Myspace, we hebben LinkedIn, Adobe. Adobe is interessant omdat mensen kijken en denken, nou, wat betekent Adobe? De meesten van ons die Adobe Reader van een of andere vorm downloaden, velen van ons hebben Adobe-producten gekocht met een creditcard, dat zijn 152 miljoen mensen.
Nu, tot het punt van Robin eerder, dit zijn zeer grote aantallen, het is gemakkelijk om overweldigd te worden door hen. Wat gebeurt er als je 359 miljoen accounts hebt die zijn overtreden? Nou, er zijn een paar dingen. Robin benadrukte het feit dat die gegevens steevast in een database van een of andere vorm voorkomen. Dat is de kritische boodschap hier. Bijna niemand op deze planeet, waarvan ik weet dat die een systeem van welke vorm dan ook draait, slaat het niet op in een database. Maar wat interessant is, is dat er drie verschillende soorten gegevens in die database zijn. Er zijn beveiligingsgerelateerde dingen zoals gebruikersnamen en wachtwoorden, die meestal worden gecodeerd, maar er zijn steevast veel voorbeelden waar ze dat niet zijn. Er is de daadwerkelijke klantinformatie rond hun profiel en gegevens die ze hebben gemaakt, of het nu een gezondheidsdossier is of een e-mail of een expresbericht. En dan is er de eigenlijke ingebedde logica, dus dit kunnen opgeslagen procedures zijn, het kan een hele reeks regels zijn, als + dit + dan + dat. En steevast is dat gewoon ASCII-tekst die in de database zit, er zijn maar weinig mensen die denken: "Nou, dit zijn bedrijfsregels, dit is hoe onze gegevens worden verplaatst en beheerd, we moeten dit mogelijk coderen wanneer het in rust is en wanneer het binnen is beweging misschien ontcijferen we het en bewaren het in het geheugen, 'maar idealiter zou het waarschijnlijk ook zo moeten zijn.
Maar het komt terug op dit belangrijke punt dat al deze gegevens zich in een database van een bepaalde vorm bevinden en vaker wel dan niet de nadruk ligt, historisch gezien, op routers en switches en servers en zelfs opslag, en niet altijd op de database op de achterkant. Omdat we denken dat we de rand van het netwerk bedekt hebben en het is een soort van oud, soort, leven in een kasteel en je legt er een slotgracht omheen en je hoopt dat de slechteriken niet gaan kunnen zwemmen. Maar toen kwamen de slechteriken er plotseling achter hoe ze verlengde ladders konden maken en over de gracht konden gooien en over de gracht konden klimmen en tegen de muren konden klimmen. En opeens is je gracht vrijwel nutteloos.
We zitten nu in het scenario waarin organisaties in een sprint inhaalmodus zijn. Naar mijn mening sprinten ze letterlijk over alle systemen, en zeker mijn ervaring, dat het niet altijd alleen deze web-eenhoorns zijn, zoals we er vaak naar verwijzen, vaker wel dan niet de traditionele bedrijfsorganisaties die worden overtreden. En je hoeft niet veel fantasie te hebben om erachter te komen wie ze zijn. Er zijn websites zoals die met de naam pastebin.net en als je naar pastebin.net gaat en je typt gewoon een e-maillijst of wachtwoordlijst, krijg je honderdduizenden vermeldingen per dag die worden toegevoegd waar mensen voorbeeldgegevenssets vermelden tot duizend records van voornaam, achternaam, creditcardgegevens, gebruikersnaam, wachtwoord, gedecodeerde wachtwoorden trouwens. Waar mensen die lijst kunnen pakken, er drie of vier van gaan controleren en besluiten dat, ja, ik wil die lijst kopen en er is meestal een vorm van mechanisme dat een soort anonieme gateway biedt aan de persoon die de gegevens verkoopt.
Wat nu interessant is, is dat als de aangesloten ondernemer zich realiseert dat hij dit kan, er niet veel fantasie voor nodig is om te beseffen dat als je US $ 1.000 uitgeeft om een van deze lijsten te kopen, wat het eerste is dat je ermee doet? Je gaat niet proberen de accounts te volgen, je zet er een kopie van terug op pastbin.net en je verkoopt twee exemplaren voor $ 1.000 elk en maakt $ 1.000 winst. En dit zijn kinderen die dit doen. Er zijn een aantal extreem grote professionele organisaties over de hele wereld die dit voor de kost doen. Er zijn zelfs staten die andere staten aanvallen. Weet je, er wordt veel gesproken over Amerika dat China aanvalt, China aanvalt Amerika, het is niet zo eenvoudig, maar er zijn zeker overheidsorganisaties die systemen overtreden die steevast worden aangedreven door databases. Het is niet alleen een zaak van kleine organisaties, het zijn ook landen versus landen. Het brengt ons terug bij dat nummer, waar worden de gegevens opgeslagen? Het staat in een database. Welke bedieningselementen en mechanismen zitten daar? Of steevast zijn ze niet gecodeerd, en als ze gecodeerd zijn, zijn het niet altijd alle gegevens, misschien is het alleen het wachtwoord dat is gezouten en gecodeerd.
En daaromheen hebben we een reeks uitdagingen met wat er in die data zit en hoe we toegang tot data en SOX-compliance bieden. Dus als u denkt aan vermogensbeheer of bankieren, hebt u organisaties die zich zorgen maken over de uitdaging van de geloofwaardigheid; u hebt organisaties die zich zorgen maken over compliance in de bedrijfsruimte; u hebt overheidsvoorschriften en wettelijke vereisten; je hebt nu scenario's waarin we databases op locatie hebben; we hebben databases in datacenters van derden; we hebben databases in cloudomgevingen, dus zijn cloudomgevingen niet altijd in het land. En dus wordt dit een steeds grotere uitdaging, niet alleen vanuit het oogpunt van pure beveiliging, laten we niet gehackt worden, maar ook, hoe kunnen we aan alle verschillende nalevingsniveaus voldoen? Niet alleen de HIPAA- en ISO-normen, maar er zijn letterlijk tientallen en tientallen en tientallen hiervan op staatsniveau, nationaal niveau en mondiale niveaus die grenzen overschrijden. Als u zaken doet met Australië, kunt u overheidsgegevens niet verplaatsen. Australische privégegevens kunnen de natie niet verlaten. Als je in Duitsland bent, is het nog strenger. En ik weet dat Amerika hier ook om verschillende redenen heel snel op vooruit gaat.
Maar het brengt me weer terug bij die hele uitdaging van hoe weet je wat er gebeurt in je database, hoe monitor je het, hoe vertel je wie wat doet in de database, wie weergaven heeft van verschillende tabellen en rijen en kolommen en velden, wanneer lezen ze het, hoe vaak lezen ze het en wie volgt het op? En ik denk dat dit me bij mijn laatste punt brengt voordat ik vandaag overhandig aan onze gast die ons gaat helpen praten over hoe we dit probleem oplossen. Maar ik wil ons laten met deze ene gedachte en dat is, veel van de focus ligt op de kosten voor het bedrijf en de kosten voor de organisatie. En we zullen dit punt vandaag niet in detail bespreken, maar ik wil het gewoon in onze gedachten laten om erover na te denken en dat is dat er een schatting is van ongeveer tussen US $ 135 en US $ 585 per record om op te ruimen na een inbreuk. Dus de investering die u doet in uw beveiliging rond routers en switches en servers is allemaal goed en goed en firewalls, maar hoeveel heeft u geïnvesteerd in uw databasebeveiliging?
Maar het is een valse economie en toen de inbreuk van Yahoo onlangs gebeurde, en ik heb het op goed gezag, zijn het ongeveer een miljard rekeningen, geen 500 miljoen. Toen Verizon de organisatie kocht voor zoiets als 4, 3 miljard, vroegen ze zodra de inbreuk plaatsvond een miljard dollar terug, of een korting. Als je nu wiskunde doet en zegt dat er ongeveer een miljard records zijn overtreden, een korting van een miljard dollar, wordt de schatting van $ 135 tot $ 535 voor het opschonen van een record nu $ 1. Dat is wederom farcical. Het kost $ 1 om een miljard records op te schonen. Voor $ 1 per record om een miljard records op te ruimen voor een inbreuk van die omvang. Je kunt niet eens een persbericht uitbrengen voor dat soort kosten. En dus richten we ons altijd op de interne uitdagingen.
Maar een van de dingen, denk ik, en het past ons om dit heel erg serieus te nemen op databaseniveau, daarom is dit een heel, heel belangrijk onderwerp voor ons om over te praten, en dat is dat we nooit over de mens praten tol. Wat is de menselijke tol die we hiervoor oplopen? En ik zal een voorbeeld nemen voordat ik snel inpakken. LinkedIn: in 2012 werd het LinkedIn-systeem gehackt. Er waren een aantal vectoren en daar zal ik niet op ingaan. En honderden miljoenen accounts werden gestolen. Mensen zeggen ongeveer 160-oneven miljoen, maar het is eigenlijk een veel groter aantal, het kan zo veel zijn als ongeveer 240 miljoen. Maar die breuk werd pas eerder dit jaar aangekondigd. Dat is vier jaar dat de gegevens van honderden miljoenen mensen daar zijn. Nu waren er mensen die betaalden voor diensten met creditcards en sommige mensen met gratis accounts. Maar LinkedIn is interessant, want niet alleen kregen ze toegang tot je accountgegevens als je werd overtreden, maar ze kregen ook toegang tot al je profielinformatie. Dus, met wie je verbonden was en alle connecties die je had, en de soorten banen die ze hadden en de soorten vaardigheden die ze hadden en hoe lang ze bij bedrijven hadden gewerkt en al dat soort informatie, en hun contactgegevens.
Dus denk aan de uitdaging die we hebben bij het beveiligen van de gegevens in deze databases, en het beveiligen en beheren van de databasesystemen zelf, en de stroom bij impact, de menselijke tol van die gegevens die er vier jaar zijn. En de kans dat iemand ergens opduikt voor een vakantie ergens in Zuidoost-Azië en ze hebben hun gegevens daar al vier jaar. En iemand heeft misschien een auto gekocht of een woningkrediet gekregen of het hele jaar door tien telefoons gekocht op creditcards, waar ze een nep-ID hebben gemaakt voor die gegevens die er al vier jaar was - omdat zelfs de LinkedIn-gegevens je voldoende informatie gaven om maak een bankrekening en een nep-ID - en je stapt in het vliegtuig, je gaat op vakantie, je landt en je wordt in de gevangenis gegooid. En waarom word je in de gevangenis gegooid? Omdat je je ID hebt gestolen. Iemand creëerde een nep-ID en handelde zoals jij en honderdduizenden dollars en ze deden dit vier jaar lang en je wist er niets van. Omdat het daar is, gebeurde het gewoon.
Dus ik denk dat het ons tot deze kernuitdaging brengt: hoe weten we wat er gebeurt in onze databases, hoe volgen we het, hoe monitoren we het? En ik kijk ernaar uit om te horen hoe onze vrienden bij IDERA een oplossing hebben bedacht om dat aan te pakken. En daarmee zal ik het overhandigen.
Eric Kavanagh: Oké, Ignacio, de vloer is van jou.
Ignacio Rodriguez: Oké. Nou, iedereen welkom. Mijn naam is Ignacio Rodriguez, beter bekend als Iggy. Ik ben bij IDERA en een productmanager voor beveiligingsproducten. Echt goede onderwerpen die we net hebben behandeld, en we moeten ons echt zorgen maken over de datalekken. We moeten een gehard beveiligingsbeleid hebben, we moeten kwetsbaarheden identificeren en de beveiligingsniveaus beoordelen, gebruikersmachtigingen beheren, serverbeveiliging beheren en audits naleven. Ik heb audits gedaan in mijn verleden, vooral aan de kant van Oracle. Ik heb wat gedaan op SQL Server en deed ze met tools of, in feite, eigen scripts, wat geweldig was, maar je moet een repository maken en ervoor zorgen dat de repository veilig was en constant de scripts moest onderhouden met wijzigingen van de auditors, wat heb je.
Dus als ik in tools had geweten dat IDERA daar was en een tool had, zou ik het waarschijnlijk hebben gekocht. Hoe dan ook, we gaan het hebben over Secure. Het is een van onze producten in onze beveiligingsproductlijn en wat het in feite doet, is dat we kijken naar het beveiligingsbeleid en dit in overeenstemming brengen met wettelijke richtlijnen. U kunt een volledige geschiedenis van SQL Server-instellingen bekijken en u kunt ook een baseline van die instellingen maken en vervolgens vergelijken met toekomstige wijzigingen. U kunt een momentopname maken, wat een basislijn van uw instellingen is, en vervolgens kunnen volgen of een van deze dingen zijn gewijzigd en ook een melding krijgen als ze zijn gewijzigd.
Een van de dingen die we goed doen, is het voorkomen van beveiligingsrisico's en schendingen. Het beveiligingsrapport geeft u een overzicht van de belangrijkste beveiligingsproblemen op de servers en vervolgens wordt elke beveiligingscontrole gecategoriseerd als hoog, gemiddeld of laag risico. Nu kunnen deze categorieën of beveiligingscontroles allemaal worden gewijzigd. Laten we zeggen dat als u enkele besturingselementen hebt en een van de sjablonen gebruikt die we hebben, en u besluit, nou ja, onze besturingselementen geven echt aan of willen dat dit beveiligingslek niet echt een high is maar een medium, of vice versa. Misschien hebt u er een die als medium is gelabeld, maar in uw organisatie de bedieningselementen die u wilt labelen of als hoog beschouwt, kunnen al die instellingen door de gebruiker worden geconfigureerd.
Een ander kritisch probleem dat we moeten bekijken, is het identificeren van de kwetsbaarheden. Begrijpen wie toegang heeft tot wat en elk van de effectieve rechten van de gebruiker identificeren voor alle SQL Server-objecten. Met de tool kunnen we de rechten voor alle SQL Server-objecten doornemen en bekijken en we zullen hier binnenkort een screenshot van zien. We rapporteren en analyseren ook machtigingen van gebruikers, groepen en rollen. Een van de andere functies is dat we gedetailleerde beveiligingsrisicorapporten leveren. We hebben kant-en-klare rapporten en bevatten flexibele parameters waarmee u de soorten rapporten kunt maken en de gegevens kunt weergeven die auditors, beveiligingsfunctionarissen en managers nodig hebben.
We kunnen ook beveiligings-, risico- en configuratiewijzigingen in de loop van de tijd vergelijken, zoals ik al zei. En die zijn bij de snapshots. En die snapshots kunnen worden geconfigureerd voor zover u ze wilt doen - maandelijks, driemaandelijks, jaarlijks - die kunnen worden gepland in de tool. En nogmaals, je kunt vergelijkingen maken om te zien wat er is veranderd en wat er leuk aan is, als je een overtreding had, kon je een snapshot maken nadat het was gecorrigeerd, een vergelijking maken en je zou zien dat er een hoog niveau was risico verbonden aan de vorige momentopname en vervolgens rapporteren, ziet u in de volgende momentopname nadat het was gecorrigeerd dat het geen probleem meer was. Het is een goed controle-instrument dat u aan de auditor kunt geven, een rapport dat u de auditor zou kunnen geven en zeggen: "Kijk, we hadden dit risico, we hebben het beperkt, en nu is het geen risico meer." En nogmaals, ik vermeld bij de snapshots die u kunt waarschuwen wanneer een configuratie verandert, en als een configuratie wordt gewijzigd en worden gedetecteerd, die een nieuw risico vormen, wordt u daar ook van op de hoogte gebracht.
We krijgen wel enkele vragen over onze SQL Server-architectuur met Secure, en ik wil een correctie aanbrengen op de dia hier met de naam 'Collectieservice'. We hebben geen services, het had 'Beheer- en incassoserver' moeten zijn. “We hebben onze console en vervolgens onze Management- en Collection Server en we hebben een agentloze opname die naar de geregistreerde databases gaat en de gegevens via banen verzamelt. En we hebben een SQL Server Repository en we werken samen met SQL Server Reporting Services om rapporten te plannen en ook aangepaste rapporten te maken. Nu op een beveiligingsrapport is dit het eerste scherm dat u ziet wanneer SQL Secure wordt gestart. U zult eenvoudig zien welke kritieke items u heeft die het heeft gedetecteerd. En nogmaals, we hebben de hoogtepunten, de media en de dieptepunten. En dan hebben we ook het beleid dat speelt bij de specifieke beveiligingscontroles. We hebben een HIPAA-sjabloon; we hebben IDERA beveiligingsniveau 1, 2 en 3 sjablonen; we hebben PCI-richtlijnen. Dit zijn allemaal sjablonen die u kunt gebruiken en nogmaals, u kunt uw eigen sjabloon maken, ook op basis van uw eigen besturingselementen. En nogmaals, ze kunnen worden gewijzigd. U kunt uw eigen maken. Elk van de bestaande sjablonen kan als basislijn worden gebruikt en u kunt deze naar wens aanpassen.
Een van de leuke dingen om te doen is kijken wie machtigingen heeft. En met dit scherm hier kunnen we zien welke SQL Server-aanmeldingen in de onderneming zijn en kunt u alle toegewezen en effectieve rechten en machtigingen op de serverdatabase op objectniveau bekijken. Dat doen we hier. U kunt opnieuw de databases of de servers selecteren en vervolgens het rapport van de SQL Server-machtigingen ophalen. Dus in staat om te zien wie welke toegang heeft tot wat. Een andere leuke functie is dat je beveiligingsinstellingen kunt vergelijken. Stel dat u standaardinstellingen had die binnen uw onderneming moesten worden ingesteld. U kunt dan een vergelijking maken van al uw servers en zien welke instellingen zijn ingesteld voor de andere servers in uw onderneming.
Nogmaals, de beleidssjablonen, dit zijn enkele van de sjablonen die we hebben. Je gebruikt er in feite weer een van, maak er zelf een. U kunt uw eigen beleid maken, zoals hier te zien. Gebruik een van de sjablonen en u kunt ze indien nodig wijzigen. We kunnen ook de effectieve rechten van SQL Server bekijken. Dit zal verifiëren en bewijzen dat machtigingen correct zijn ingesteld voor de gebruikers en rollen. Nogmaals, u kunt naar buiten gaan en kijken en zien en verifiëren dat de rechten correct zijn ingesteld voor gebruikers en de rollen. Vervolgens kunt u met de SQL Server-objecttoegangsrechten vervolgens door de SQL Server-objectstructuur bladeren en deze analyseren van serverniveau tot rollen en eindpunten op objectniveau. En u kunt direct de toegewezen en effectieve overgenomen machtigingen en beveiligingsgerelateerde eigenschappen op objectniveau bekijken. Dit geeft u een goed beeld van de toegangen die u hebt tot uw databaseobjecten en wie daar toegang toe heeft.
We hebben weer onze rapporten die we hebben. Het zijn ingeblikte rapporten, we hebben verschillende waaruit u kunt kiezen om uw rapportage te doen. En veel van deze kunnen worden aangepast of u kunt uw klantrapporten hebben en die gebruiken in combinatie met de rapportageservices en van daaruit uw eigen aangepaste rapporten kunnen maken. Nu de Snapshot-vergelijkingen, dit is een behoorlijk coole functie, denk ik, waar je naar buiten kunt gaan en je een vergelijking kunt maken van je gemaakte snapshots en kijken of er verschillen in het aantal waren. Zijn er objecten toegevoegd, waren er machtigingen die zijn gewijzigd, alles wat we kunnen zien welke wijzigingen zijn aangebracht tussen de verschillende snapshots. Sommige mensen zullen deze maandelijks bekijken - ze zullen een maandelijkse momentopname maken en vervolgens elke maand een vergelijking maken om te zien of er iets is veranderd. En als er niets was dat verondersteld was te zijn veranderd, iets dat naar de veranderingsvergaderingen ging en u ziet dat sommige toestemmingen zijn gewijzigd, kunt u teruggaan om te kijken wat er is gebeurd. Dit is een behoorlijk leuke functie hier waar je opnieuw de vergelijking kunt maken van alles wat wordt gecontroleerd in de snapshot.
Dan is uw beoordelingsvergelijking. Dit is een andere leuke functie die we hebben, waar je naar buiten kunt gaan en de beoordelingen kunt bekijken en ze vervolgens kunt vergelijken en opmerken dat de vergelijking hier een SA-account had die niet was uitgeschakeld in deze recente momentopname die ik heb gedaan - het is nu gecorrigeerd. Dit is een heel mooi ding waar je kunt laten zien dat, oké, we enig risico hadden, ze werden geïdentificeerd door de tool, en nu hebben we die risico's beperkt. En nogmaals, dit is een goed rapport om de auditors te laten zien dat die risico's in feite zijn beperkt en worden weggenomen.
Samenvattend, databasebeveiliging, het is van cruciaal belang, en ik denk dat we vaak kijken naar inbreuken die afkomstig zijn van externe bronnen en soms besteden we niet echt veel aandacht aan interne inbreuken en dat zijn enkele dingen die we moet uitkijken voor. En Secure helpt u daar om ervoor te zorgen dat er geen privileges zijn die niet hoeven te worden toegewezen, weet u, zorg ervoor dat al deze beveiliging correct is ingesteld op de accounts. Zorg ervoor dat uw SA-accounts wachtwoorden hebben. Controleert ook voor zover zijn uw coderingssleutels geëxporteerd? Gewoon meerdere verschillende dingen die we controleren en we zullen u erop wijzen dat er een probleem was en op welk probleemniveau het is. We hebben een tool nodig, veel professionals hebben tools nodig om databasetoegangsmachtigingen te beheren en te controleren, en we kijken eigenlijk naar het bieden van een uitgebreide mogelijkheid om databasemachtigingen te beheren en toegangsactiviteiten te volgen en inbreukrisico's te beperken.
Nu is een ander deel van onze beveiligingsproducten dat er een WebEx is die werd behandeld en dat een deel van de presentatie waar we het eerder over hadden, gegevens was. U weet wie toegang heeft tot wat, wat heeft u, en dat is onze SQL Compliance Manager-tool. En er is een opgenomen WebEx op die tool en waarmee u daadwerkelijk kunt controleren wie toegang heeft tot welke tabellen, welke kolommen, kunt u tabellen identificeren die gevoelige kolommen hebben, voor zover geboortedatum, patiëntinformatie, dat soort tabellen, en daadwerkelijk zien wie toegang heeft tot die informatie en of deze wordt gebruikt.
Eric Kavanagh: Oké, dus laten we hier even op de vragen ingaan, denk ik. Misschien, Dez, zal ik het je eerst geven, en Robin, bel je mee als je kunt.
Dez Blanchfield: Ja, ik stond te popelen om een vraag te stellen van de 2de en 3de dia. Wat is de typische use case die u voor deze tool ziet? Wie zijn de meest voorkomende typen gebruikers die je ziet die dit overnemen en in het spel brengen? En daarachter, het typische, soort use case-model, hoe gaan ze daar over? Hoe wordt het geïmplementeerd?
Ignacio Rodriguez: Oké, de typische use case die we hebben zijn DBA's die de verantwoordelijkheid hebben gekregen voor toegangscontrole voor de database, die ervoor zorgt dat alle toestemmingen worden ingesteld zoals ze moeten zijn en vervolgens bijhouden en hun normen in situ. Weet je, deze bepaalde gebruikersaccounts hebben alleen toegang tot deze specifieke tabellen, enzovoort. En wat ze ermee doen, is ervoor zorgen dat die normen zijn vastgesteld en die normen niet zijn veranderd door de tijd heen. En dat is een van de grote dingen waarvoor mensen het gebruiken, is het volgen en identificeren van eventuele wijzigingen die niet bekend zijn.
Dez Blanchfield: Omdat zij enge zijn, nietwaar? Is dat je misschien een, laten we zeggen, een strategiedocument hebt, je hebt beleid dat dat ondersteunt, je hebt compliance en governance daaronder, en je volgt het beleid, je houdt je aan het bestuur en het krijgt een groen licht en plotseling rolt iemand een maand later een verandering uit en om de een of andere reden doorloopt het niet hetzelfde wijzigingsbeoordelingsbord of veranderingsproces, of wat het ook is, of het project is gewoon verder gegaan en niemand weet het.
Heb je voorbeelden die je kunt delen - en ik weet natuurlijk dat het niet altijd iets is dat je deelt omdat klanten er een beetje bezorgd over zijn, dus we hoeven niet noodzakelijk namen te noemen - maar geef ons een voorbeeld van waar je heeft dit misschien wel eens gezien, weet je, een organisatie heeft dit op zijn plaats gezet zonder het te beseffen en ze hebben net iets ontdekt en beseften: "Wauw, het was tien keer waard, we hebben net iets gevonden dat we ons niet realiseerden." een voorbeeld waar mensen dit hebben geïmplementeerd en vervolgens ontdekten dat ze een groter probleem hadden of een echt probleem waarvan ze niet wisten dat ze het hadden en dan word je meteen toegevoegd aan de kerstkaartlijst?
Ignacio Rodriguez: Nou, ik denk dat het grootste dat we hebben gezien of gemeld is wat ik zojuist heb genoemd, wat betreft de toegang die iemand had gehad. Er zijn ontwikkelaars en toen ze de tool implementeerden, realiseerden ze zich echt niet dat X-hoeveelheid van deze ontwikkelaars zoveel toegang had tot de database en toegang had tot bepaalde objecten. En nog iets is alleen-lezenaccounts. Er waren enkele read-only accounts die ze hadden, kwamen erachter dat deze read-only accounts eigenlijk zijn, hadden ook invoeggegevens en verwijderrechten. Dat is waar we wat voordeel voor de gebruikers hebben gezien. Het grote ding, opnieuw, dat we hebben gehoord dat mensen leuk vinden, is in staat zijn om, opnieuw, de veranderingen te volgen en ervoor te zorgen dat niets ze verblindt.
Dez Blanchfield: Nou, zoals Robin benadrukte, heb je scenario's waar mensen niet vaak over nadenken, toch? Als we vooruit kijken, denken we een beetje, weet je, als we alles volgens de regels doen, en ik vind, en ik weet zeker dat je het ook ziet - vertel me als je het er niet mee eens bent - organisaties focussen dus zwaar op het ontwikkelen van strategie en beleid en compliance en governance en KPI's en rapportage, dat ze daar vaak zo gefixeerd op zijn, dat ze niet aan de uitbijters denken. En Robin had een echt geweldig voorbeeld dat ik van hem ga stelen - sorry Robin - maar het voorbeeld is de andere keer dat een live kopie van de database, een momentopname en het in ontwikkelingstest plaatste, toch? We doen dev, we doen tests, we doen UAT, we doen systeemintegratie, al dat soort dingen en dan doen we nu een aantal compliance-tests. Vaak ontwikkeltest, UAT, SIT heeft eigenlijk een compliancecomponent waarin we er gewoon voor zorgen dat het allemaal gezond en veilig is, maar niet iedereen doet dat. Dit voorbeeld dat Robin gaf met een kopie van een live kopie van de database, getest in een ontwikkelomgeving om te zien of deze nog steeds met de live data werkt. Zeer weinig bedrijven leunen achterover en denken: "Gebeurt dat zelfs of is het mogelijk?" Ze zijn altijd gefixeerd op de productie. Hoe ziet de implementatiereis eruit? Hebben we het over dagen, weken, maanden? Hoe ziet een reguliere implementatie eruit voor een middelgrote organisatie?
Ignacio Rodriguez: Dagen. Het zijn niet eens dagen, ik bedoel, het zijn maar een paar dagen. We hebben zojuist een functie toegevoegd waarmee we heel veel servers kunnen registreren. In plaats van daar naar binnen te gaan in de tool en te zeggen dat je 150 servers had, moest je daar individueel naar binnen gaan en de servers registreren - nu hoef je dat niet te doen. Er is een CSV-bestand dat u maakt en we verwijderen het automatisch en we houden het daar niet vanwege beveiligingsproblemen. Maar dat is een ander ding waar we rekening mee moeten houden, is dat je een CSV-bestand met gebruikersnaam / wachtwoord hebt.
Wat we doen, doen we automatisch, is dat we het opnieuw verwijderen, maar dat is een optie die u hebt. Als u daar individueel naar binnen wilt gaan en ze wilt registreren en dat risico niet wilt nemen, dan kunt u dat doen. Maar als u een CSV-bestand wilt gebruiken, het op een veilige locatie wilt plaatsen, de toepassing naar die locatie wilt wijzen, wordt dat CSV-bestand uitgevoerd en wordt het automatisch ingesteld om dat bestand te verwijderen zodra het klaar is. En het zal gaan en ervoor zorgen en controleren of het bestand is verwijderd. De langste paal in het zand die we tot dusverre hadden was de registratie van de eigenlijke servers.
Dez Blanchfield: Oké. Nu had je het over rapporten. Kun je ons een beetje meer detail en inzicht geven in wat vooraf is gebundeld, alleen als het gaat om rapporteren, denk ik, de ontdekkingscomponent van kijken naar wat er in staat en daarover rapporteren, de huidige staat van de natie, wat er vooraf komt gebouwd en voorgebakken tot rapporten over de huidige staat van naleving en beveiliging, en hoe gemakkelijk zijn ze uitbreidbaar? Hoe bouwen we daarop voort?
Ignacio Rodriguez: Oké. Sommige van de rapporten die we hebben, hebben rapporten over cross-server, inlogcontroles, filters voor gegevensverzameling, activiteitengeschiedenis en vervolgens de risicobeoordelingsrapporten. En ook alle verdachte Windows-accounts. Er zijn er heel veel. Zie verdachte SQL-aanmeldingen, serveraanmeldingen en gebruikerstoewijzing, gebruikersrechten, alle gebruikersrechten, serverrollen, databaserollen, enige kwetsbaarheid die we hebben of authenticatiemeldingen in gemengde modi, databases met gastvrijgave, OS-kwetsbaarheid via XPS's, de uitgebreide procedures, en dan de kwetsbare vaste rollen. Dat zijn enkele van de rapporten die we hebben.
Dez Blanchfield: En je zei dat ze significant genoeg zijn en een aantal van hen, wat een logische zaak is. Hoe gemakkelijk is het voor mij om het aan te passen? Als ik een rapport uitvoer en ik krijg deze geweldige grote grafiek, maar ik wil enkele stukken verwijderen waar ik niet echt in geïnteresseerd ben en een paar andere functies toevoegen, is er een schrijver van het rapport, is er een soort interface en een hulpmiddel om een nieuw rapport te configureren en aan te passen of mogelijk zelfs helemaal opnieuw te bouwen?
Ignacio Rodriguez: We zouden de gebruikers dan de opdracht geven om Microsoft SQL Report Services te gebruiken om dat te doen en we hebben veel klanten die sommige van de rapporten daadwerkelijk nemen, aanpassen en plannen wanneer ze maar willen. Sommige van deze jongens willen deze rapporten maandelijks of wekelijks zien en zij zullen de informatie die we hebben, naar de Reporting Services verplaatsen en dat vanaf daar doen. We hebben geen rapportschrijver geïntegreerd in onze tool, maar we profiteren wel van de Reporting Services.
Dez Blanchfield: Ik denk dat dat een van de grootste uitdagingen is met deze tools. Je kunt er naar binnen gaan en dingen vinden, maar dan moet je het eruit kunnen halen, het melden aan mensen die niet noodzakelijkerwijs DBA's en systeemingenieurs zijn. Er is een interessante rol die in mijn ervaring tot stand is gekomen en dat is, weet je, risicofunctionarissen zijn altijd in organisaties geweest en dat ze voornamelijk aanwezig zijn geweest en een heel ander scala aan risico's dat we recent hebben gezien, nu met gegevens inbreuken worden niet alleen maar een ding, maar een echte tsunami, de CRO is van u, weet u, HR en compliance en aandacht voor gezondheid en veiligheid op het werk nu veranderd in cyberrisico's. Je weet wel, inbreuk, hacking, beveiliging - veel technischer. En het wordt interessant omdat er veel CRO's zijn die afkomstig zijn uit een MBA-stamboom en niet uit een technische stamboom, dus ze moeten hun hoofd erbij houden, soort, wat dit betekent voor de overgang tussen het cyberrisico naar een CRO, enzovoort. Maar het grote ding dat ze willen is alleen zichtbaarheidsrapportage.
Kun je ons iets vertellen over de positionering met betrekking tot compliance? Het is duidelijk dat een van de sterke punten hiervan is dat je kunt zien wat er aan de hand is, je kunt het volgen, je kunt leren, je kunt erover rapporteren, je kunt erop reageren, je kunt zelfs een aantal dingen voorschieten. De overkoepelende uitdaging is governance compliance. Zijn er belangrijke onderdelen hiervan die opzettelijk verband houden met bestaande compliancevereisten of industriële compliance zoals PCI, of zoiets op dit moment, of is het iets dat op de kaart komt? Past het min of meer in het raamwerk van bijvoorbeeld COBIT, ITIL en ISO-normen? Als we deze tool hebben geïmplementeerd, geeft het ons dan een reeks checks and balances die in die frameworks passen, of hoe bouwen we het in die frameworks in? Waar is de positie met dat soort dingen in gedachten?
Ignacio Rodriguez: Ja, we hebben sjablonen die we met de tool leveren. En we komen weer op het punt waar we onze sjablonen opnieuw evalueren en we gaan toevoegen en er zullen er binnenkort meer volgen. FISMA, FINRA, enkele aanvullende sjablonen die we hebben, en we bekijken de sjablonen meestal en kijken wat er is veranderd, wat moeten we toevoegen? En we willen eigenlijk het punt bereiken waarop, weet u, beveiligingsvereisten nogal zijn veranderd, dus we kijken naar een manier om dit snel uitbreidbaar te maken. Dat is iets waar we in de toekomst naar kijken.
Maar op dit moment bekijken we misschien het maken van sjablonen en het kunnen krijgen van de sjablonen van een website; je kunt ze downloaden. En zo gaan we daarmee om - we behandelen ze via sjablonen en we zoeken naar manieren om dit in de toekomst gemakkelijk uitbreidbaar en snel te maken. Want toen ik auditing deed, weet je, dingen veranderen. Een auditor zou de ene maand komen en de volgende maand willen ze iets anders zien. Dan is dat een van de uitdagingen met de tools, het kunnen maken van die veranderingen en krijgen wat je nodig hebt, en dat is een soort van waar we naartoe willen.
Dez Blanchfield: Ik denk dat de uitdaging van een auditor regelmatig verandert in het licht van het feit dat de wereld sneller beweegt. En ooit was de vereiste vanuit auditoogpunt, naar mijn ervaring, gewoon pure commerciële compliance, en toen werd het technische compliance en nu is het operationele compliance. En er zijn al die andere, weet je, elke dag verschijnt er iemand en ze meten je niet alleen met iets zoals ISO 9006 en 9002, ze kijken naar allerlei dingen. En ik zie nu dat de 38.000-serie ook een grote zaak wordt in ISO. Ik stel me voor dat dat alleen maar meer en meer uitdagend gaat worden. Ik sta op het punt om aan Robin over te dragen omdat ik de bandbreedte heb vergroot.
Heel erg bedankt, zie dat, en ik ga absoluut meer tijd besteden om het te leren kennen omdat ik me niet echt realiseerde dat het eigenlijk zo diepgaand was. Dus, bedankt, Ignacio, ik ga het nu aan Robin overhandigen. Een geweldige presentatie, bedankt. Robin, tegenover jou.
Dr. Robin Bloor: Oké Iggy, ik ga je Iggy noemen, als dat oké is. Wat me verbijstert, en ik denk dat in het licht van enkele van de dingen die Dez in zijn presentatie zei, er heel veel gaande is dat je moet zeggen dat mensen echt niet op de gegevens letten. Weet je, vooral als het erop aankomt dat je maar een deel van de ijsberg ziet en er is waarschijnlijk veel gaande dat niemand rapporteert. Ik ben geïnteresseerd in jouw perspectief met betrekking tot hoeveel van de klanten die je kent, of potentiële klanten die je kent, het beschermingsniveau hebben dat je, eigenlijk, biedt met niet alleen dit, maar ook uw data access-technologie? Ik bedoel, wie is daar goed uitgerust om met de dreiging om te gaan, is de vraag?
Ignacio Rodriguez: Wie is naar behoren uitgerust? Ik bedoel, veel klanten die we echt niet hebben aangepakt, weten we. Ze hebben er een paar gehad, maar het grote ding is proberen het bij te houden en proberen het te behouden en ervoor te zorgen. Het grote probleem dat we hebben gezien is - en zelfs ik heb toen ik de compliance deed, is - als je je scripts zou uitvoeren, zou je het elk kwartaal doen wanneer de auditors zouden binnenkomen en je een probleem hebt gevonden. Wel, raad eens, dat is al te laat, audits zijn er, de auditors zijn er, ze willen hun rapport, ze markeren het. En dan krijgen we ofwel een merkteken of ons werd verteld, hey, we moeten deze problemen oplossen, en dat is waar dit zou komen. Het zou meer een proactief type zijn waar u uw risico kunt vinden en het risico kunt verminderen en dat is wat onze klanten zoeken. Een manier om enigszins proactief te zijn in plaats van reactief te zijn wanneer auditors binnenkomen en vinden dat sommige toegangen niet zijn waar ze moeten zijn, andere mensen hebben administratieve privileges en ze zouden ze niet moeten hebben, dat soort dingen. En dat is waar we veel feedback van hebben gezien, waar mensen van de tool houden en het voor gebruiken.
Dr. Robin Bloor: Oké, ik heb nog een vraag die in zekere zin ook een voor de hand liggende vraag is, maar ik ben gewoon nieuwsgierig. Hoeveel mensen komen naar je toe na een hack? Waar, weet je, je het bedrijf krijgt, niet omdat ze naar hun omgeving keken en dachten dat ze op een veel meer georganiseerde manier moesten worden beveiligd, maar eigenlijk ben je er gewoon omdat ze al een deel van de pijn.
Ignacio Rodriguez: In mijn tijd hier bij IDERA heb ik er nog geen gezien. Om eerlijk te zijn, is het grootste deel van de interactie die ik heb gehad met de klanten waar ik bij betrokken ben, meer een vooruitziende blik en proberen te beginnen met auditing en begonnen te kijken naar privileges, enzovoort. Zoals ik al zei, ik heb mezelf, heb in mijn tijd hier niet ervaren dat we iemand hebben gehad die na de breuk is gekomen die ik ken.
Dr. Robin Bloor: Oh, dat is interessant. Ik had gedacht dat er minstens een paar zouden zijn geweest. Ik kijk hier eigenlijk naar, maar voeg er ook alle complexiteiten aan toe die gegevens in de hele onderneming op elke manier en in elke activiteit die je doet beveiligen. Biedt u rechtstreeks advies om mensen te helpen? Ik bedoel, het is duidelijk dat je gereedschap kunt kopen, maar in mijn ervaring kopen mensen vaak geavanceerde gereedschap en gebruiken ze heel slecht. Biedt u specifiek advies - wat te doen, wie te trainen en dat soort dingen?
Ignacio Rodriguez: Er zijn een aantal diensten die u zou kunnen bieden, wat ondersteunende diensten mogelijk maakt, waardoor een deel daarvan kan plaatsvinden. But as far as consultancy, we don't provide any consultancy services but training, you know, how to use the tools and stuff like that, some of that would be addressed with the support level. But per se we don't have a services department that goes out and does that.
Dr. Robin Bloor: Okay. In terms of the database you cover, the presentation here just mentions Microsoft SQL Server – do you do Oracle as well?
Ignacio Rodriguez: We are going to be expanding into the Oracle realm with Compliance Manager first. We're going to start a project with that so we are going to be looking at expanding this into Oracle.
Dr. Robin Bloor: And are you likely to go elsewhere?
Ignacio Rodriguez: Yeah that's something that we have to look at on the roadmaps and see how things are, but that is some of the things that we are considering, is what other database platforms do we need to attack as well.
Dr. Robin Bloor: I was also interested in the split, I haven't got any preconceived picture of this, but in terms of deployments, how much of this is actually being deployed in the cloud, or is it nearly all on-premise?
Ignacio Rodriguez: All on-premise. We are looking at extending Secure as well to cover Azure, yeah.
Dr. Robin Bloor: That was the Azure question, you're not there yet but you're going there, it makes a lot of sense.
Ignacio Rodriguez: Yeah, we're going there very soon.
Dr. Robin Bloor: Yeah, well, my understanding from Microsoft is that there's an awful lot of action with Microsoft SQL Server in Azure. It's becoming, if you like, a key part of what it is that they offer. The other question that I'm kind of interested in – it's not technical, it's more like a how-do-you-engage question – who is the buyer for this? Are you being approached by the IT department or are you being approached by CSOs, or is it a different variety of people? When something like this is being considered, is it part of looking at a whole series of things for securing the environment? What's the situation there?
Ignacio Rodriguez: It's a mixture. We do have CSOs, a lot of times the sales team will reach out and talk to DBAs. And then the DBAs, again, have been chartered with getting some kind of auditing process policies in place. And then from there they will evaluate the tools and report up the chain and make a decision on which part that they want to buy. But it's a mixed bag of who will contact us.
Dr. Robin Bloor: Okay. I think I'll hand back to Eric now because we've, kind of, done the hour, but there may be some audience questions. Eric?
Eric Kavanagh: Yeah sure, we've burned through a lot of good content here. Here's one really good question I'll throw over to you from one of the attendees. He's talking about the blockchain and what you're talking about, and he's asking, is there a possible way to migrate a read-only part of a SQL database to something similar to what blockchain offers? It's kind of a tough one.
Ignacio Rodriguez: Yeah, I'll be honest with you, I don't have an answer to that one.
Eric Kavanagh: I'll throw it over to Robin. I don't know if you heard that question, Robin, but he's just asking, is there a way to migrate the read-only part of a SQL database to something similar to what blockchain offers? What do you think about that?
Dr. Robin Bloor: It's like, if you're going to migrate the database you're also going to migrate the database traffic. There's a whole set of complexity involved in doing that. But you wouldn't do it for any reason other than to make the data inviolable. Because a blockchain is going to be slower to access, so, you know, if speed is your thing – and it nearly always is the thing – then you wouldn't be doing it. But if you wanted to provide, kind of, keyed encrypted access to part of it to some people doing that kind of thing, you could do it, but you'd have to have a very good reason. You're much more likely to leave it where it is and secure it where it is.
Dez Blanchfield: Yeah, I agree on that, if I can weigh in quickly. I think the challenge of blockchain, even the blockchain that's publicly out there, it's used on bitcoin – we're finding it hard to scale it beyond, sort of, four transactions a minute in a full distributed fashion. Not so much because of the compute challenge, although it is there, the full nodes are just finding it tough to keep up with the database volumes moving backwards and forwards and the amount of data being copied because it's gigs now, not just megs.
But also, I think the key challenge is you need to change the architecture of the application because in a database it's predominantly about bringing everything to a central location and you've got that client-server type model. Blockchain is the inverse; it's about distributed copies. It's more like BitTorrent in many ways, and that is that lots of copies are out there of the same data. And, you know, like Cassandra and in-memory databases where you distribute it and lots of servers can give you copies of the same data out of a distributed index. I think the two key parts, as you said, Robin, is: one, if you want to secure it and make sure that it can't be stolen or hacked, that's great, but it's not necessarily a transactional platform yet, and we've experienced that with the bitcoin project. But in theory others have solved it. But also, architecturally a lot of the applications out there just don't know how to query and read from a blockchain.
There's a lot of work to be done there. But I think the key point with the question there, just if I can, is the rationale of moving it to a blockchain, I think the question that's being asked is, can you take data out of a database and put it into some form that's more secure? And the answer is, you can leave it in the database and just encrypt it. There are plenty of technologies now. Just encrypt the data at rest or in motion. There's no reason why you can't have encrypted data in memory and in the database on disk, which is a far simpler challenge because you don't have a single architectural change. Invariably most database platforms, it's actually just a feature that gets enabled.
Eric Kavanagh: Yeah, we do have one last question I'll throw over to you, Iggy. It's a pretty good one. From an SLA and capacity planning perspective, what kind of tax is there by using your system? In other words, any additional latency or throughput overhead if, in a production database system, someone wants to involve IDERA's technology here?
Ignacio Rodriguez: We really don't see much of an impact. Again, it's an agentless product and it all depends on, as I mentioned before, the snapshots. Secure is based on snapshots. It'll go out there and actually create a job that will go out there based on the intervals that you have selected. Either you want to do it, again, weekly, daily, monthly. It'll go out there and execute that job and then collect the data from the instances. At that point then the load then comes back to the management and collection services, once you start doing the comparisons and all that, the load on the database doesn't play a part in that. All that load is now on the management and collection server, as far as doing the comparisons and all of the reporting and all that. The only time you hit the database is always when it's doing the actual snapshotting. And we have not had really any reports of it really being detrimental to the production environments.
Eric Kavanagh: Yeah, that's a really good point that you make there. Basically you can just set how many ever snapshots you take, what that interval of time is, and depending on what that may happen to be, but that's very intelligent architecture. That's good stuff, man. Well you guys are out on the frontlines trying to protect us from all of those hackers we talked about in the first 25 minutes of the show. And they are out there, folks, make no mistake.
Well, listen, we will post a link to this webcast, the archives, at our site insideanalysis.com. You can find stuff on SlideShare, you can find it on YouTube. And folks, good stuff. Thanks for your time, Iggy, I love your nickname, by the way. With that we'll bid you farewell, folks. Heel erg bedankt voor je tijd en aandacht. We'll catch up to you next time. Bye bye.
