Door Techopedia Staff, 10 mei 2017
Takeaway: gastheer Eric Kavanagh bespreekt beveiliging en machtigingen met Dr. Robin Bloor en IDERA's Vicky Harp.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: OK, dames en heren, hallo en welkom weer terug. Het is een woensdag, het is vier Eastern en in de wereld van enterprise-technologie betekent dit dat het weer tijd is voor Hot Technologies! Ja inderdaad. Uiteraard gepresenteerd door de Bloor Group, mogelijk gemaakt door onze vrienden bij Techopedia. Het onderwerp van vandaag is heel cool: "Beter om toestemming te vragen: Best Practices voor privacy en beveiliging." Dat klopt, het is een nogal moeilijk onderwerp, veel mensen praten erover, maar het is een behoorlijk serieus onderwerp, en het wordt echt elke dag serieuzer, eerlijk gezegd. Het is op veel manieren een groot probleem voor veel organisaties. We gaan het erover hebben en we gaan het hebben over wat je kunt doen om je organisatie te beschermen tegen de snode karakters die tegenwoordig overal voorkomen.
Dus de presentator van vandaag is Vicky Harp die vanuit IDERA belt. U kunt IDERA Software zien op LinkedIn - ik ben dol op de nieuwe functionaliteit op LinkedIn. Hoewel ik kan zien dat ze op bepaalde manieren aan een touwtje trekken, je geen toegang tot mensen geven, proberen je ertoe te brengen die premium lidmaatschappen te kopen. Daar gaan we, we hebben onze eigen Robin Bloor, die inbelt - hij is eigenlijk vandaag in de omgeving van San Diego. En de uwe echt als uw moderator / analist.
Dus waar hebben we het over? Datalekken. Ik heb deze informatie net overgenomen van IdentityForce.com, het is al onderweg naar de races. We zijn natuurlijk in mei van dit jaar, en er zijn maar een paar datalekken, er zijn natuurlijk heel grote, door Yahoo! was een grote, en we hoorden natuurlijk dat de Amerikaanse overheid werd gehackt. We hebben net de Franse verkiezingen gehackt.
Dit gebeurt overal, het gaat door en het zal niet stoppen, dus het is een realiteit, het is de nieuwe realiteit, zoals ze zeggen. We moeten echt nadenken over manieren om de veiligheid van onze systemen en van onze gegevens af te dwingen. En het is een continu proces, dus het is net op tijd om na te denken over alle verschillende problemen die een rol spelen. Dit is slechts een gedeeltelijke lijst, maar dit geeft u enig inzicht in hoe precair de situatie tegenwoordig is met bedrijfssystemen. En vóór deze show, in onze pre-show scherts hadden we het over ransomware die iemand heeft getroffen die ik ken, wat een zeer onaangename ervaring is, wanneer iemand je iPhone overneemt en geld voor je eist om weer toegang tot je telefoon te krijgen. Maar het gebeurt, het gebeurt met computers, het gebeurt met systemen, ik zag de andere dag, het gebeurt met miljardairs met hun jachten. Stel je voor dat je op een dag naar je jacht gaat en probeert indruk te maken op al je vrienden en je kunt het zelfs niet inschakelen, omdat een dief de toegang tot de bedieningselementen heeft gestolen, het bedieningspaneel. Ik zei net onlangs in een interview tegen iemand, altijd de handmatige override hebben. Ik ben bijvoorbeeld geen grote fan van alle verbonden auto's - zelfs auto's kunnen worden gehackt. Alles dat is verbonden met internet of is verbonden met een netwerk dat kan worden doordrongen, kan worden gehackt, alles.
Dus, hier zijn slechts een paar punten om in overweging te nemen in termen van de context van hoe ernstig de situatie is. Web-gebaseerde systemen zijn tegenwoordig overal, ze blijven groeien. Hoeveel mensen kopen dingen online? Het is tegenwoordig alleen maar door het dak, daarom is Amazon tegenwoordig zo'n krachtige kracht. Dat komt omdat zoveel mensen online dingen kopen.
Dus, je herinnert je toen, 15 jaar geleden, mensen behoorlijk nerveus waren over het plaatsen van hun creditcard in een webformulier om hun informatie te krijgen, en toen was het argument: "Wel, als je je creditcard overhandigt aan een ober bij een restaurant, dan is dat hetzelfde. ”Dus ons antwoord is ja, het is hetzelfde, er zijn al deze controlepunten, of toegangspunten, hetzelfde, verschillende kant van dezelfde medaille, waar mensen kunnen worden geplaatst in gevaar, waar iemand uw geld kan nemen, of iemand van u kan stelen.
Dan breidt IoT het bedreigingslandschap - ik hou van dat woord - natuurlijk uit met orden van grootte. Ik bedoel, denk er eens over na - met al deze nieuwe apparaten overal, als iemand een systeem kan hacken dat ze bestuurt, kunnen ze al die bots tegen je keren en heel veel problemen veroorzaken, dus dat is een zeer ernstig probleem. We hebben tegenwoordig een wereldeconomie, die het bedreigingslandschap nog meer uitbreidt, en bovendien, je hebt mensen in andere landen die op dezelfde manier toegang hebben tot internet, en als je niet weet hoe je Russisch moet spreken, of een willekeurig aantal andere talen, zult u het moeilijk vinden om te begrijpen wat er aan de hand is wanneer ze uw systeem hacken. We hebben dus vooruitgang in netwerken en virtualisatie, nou dat is goed.
Maar ik heb aan de rechterkant van deze foto hier een zwaard en de reden dat ik het heb is omdat elk zwaard beide kanten op snijdt. Het is een tweesnijdend zwaard, zoals ze zeggen, en het is een oud cliché, maar het betekent dat het zwaard dat ik heb je kan schaden of het kan me schaden. Het kan op me terugkomen, hetzij door terug te stuiteren, of door iemand die het neemt. Het is eigenlijk een van de fabels van Aesop - we geven onze vijanden vaak het gereedschap van onze eigen vernietiging. Het is echt een boeiende verhaallijn en heeft te maken met iemand die een pijl en boog gebruikte en een vogel neerschoot en de vogel zag, terwijl de pijl omhoog kwam, die veer van een van zijn vogelvrienden op de rand van de pijl was, op de achterkant van de pijl om het te leiden, en hij dacht bij zichzelf: "Oh man, hier zijn het, mijn eigen veren, mijn eigen familie zal worden gebruikt om mij neer te halen." Dat gebeurt de hele tijd, hoor je statistieken over je hebt een pistool in huis, de dief kan het pistool pakken. Nou, dit is allemaal waar. Dus, ik gooi dit weg als een analogie om te overwegen, al deze verschillende ontwikkelingen hebben positieve en negatieve kanten.
En gesproken over, containers voor diegenen onder u die echt de voorhoede van enterprise computing volgen, containers zijn het nieuwste, de nieuwste manier om functionaliteit te leveren, het is echt het huwelijk van virtualisatie in de servicegeoriënteerde architectuur, althans voor microservices en het is zeer interessante dingen. Je kunt zeker je beveiligingsprotocollen en je applicatieprotocollen en je gegevens enzovoort verdoezelen door containers te gebruiken, en dat geeft je een voorschot voor een periode van tijd, maar vroeg of laat gaan de slechteriken dat uitzoeken, en dan wordt het nog moeilijker om te voorkomen dat ze profiteren van uw systemen. Er is dus een wereldwijd personeelsbestand dat het netwerk en de beveiliging bemoeilijkt en waar mensen vanaf inloggen.
We hebben de browseroorlogen die snel doorgaan en constant werk vereisen om bij te werken en op de hoogte te blijven. We blijven horen over de oude Microsoft Explorer-browsers, hoe deze zijn gehackt en daar beschikbaar zijn. Dus er is tegenwoordig meer geld te verdienen bij het hacken, er is een hele industrie, dit is iets dat mijn partner, Dr. Bloor, me acht jaar geleden leerde - ik vroeg me af waarom we er zoveel van zien en hij herinnerde eraan ik, het is een hele industrie die bezig is met hacken. En in die zin is het verhaal, dat een van mijn minst favoriete woorden over beveiliging is, echt heel oneerlijk, omdat het verhaal je in al deze video's en elke vorm van nieuwsverslaggeving laat zien dat sommige hackers een kerel in een hoodie laten zien, zittend in zijn kelder in een donker verlichte kamer, dat is helemaal niet het geval. Dat is helemaal niet representatief voor de realiteit. Het zijn alleenstaande hackers, er zijn maar weinig alleenstaande hackers, ze zijn daar, ze veroorzaken wat problemen - ze zullen niet de grote problemen veroorzaken, maar ze kunnen heel veel geld verdienen. Dus wat er gebeurt, is dat de hackers binnenkomen en je systeem binnendringen en die toegang dan verkopen aan iemand anders, die zich omdraait en het aan iemand anders verkoopt, en dan ergens langs de lijn, exploiteert iemand die hack en profiteert van jou. En er zijn talloze manieren om te profiteren van gestolen gegevens.
Ik heb me zelfs verwonderd over hoe we dit concept hebben betoverd. Je ziet deze term overal, "growth hacking" alsof het een goede zaak is. Groei hacken, weet je, hacken kan een goede zaak zijn, als je probeert om voor de goede jongens te werken en een systeem te hacken, zoals we horen over Noord-Korea en hun raketlanceringen, mogelijk gehackt - dat is goed. Maar hacken is vaak een slechte zaak. Dus nu glamouren we het, net als Robin Hood, toen we Robin Hood glamourden. En dan is er de geldloze samenleving, iets dat eerlijk gezegd de daglicht uit mij betreft. Alles wat ik denk, is elke keer dat ik dat hoor: "Nee, doe het alsjeblieft niet! Alsjeblieft niet! 'Ik wil niet dat al ons geld verdwijnt. Dus dit zijn slechts enkele aandachtspunten en nogmaals, het is een kat-en-muisspel; het zal nooit stoppen, er zal altijd behoefte zijn aan beveiligingsprotocollen en aan het ontwikkelen van beveiligingsprotocollen. En voor het bewaken van uw systemen om zelfs te weten en te voelen wie daar is, met het begrip dat het zelfs een interne taak kan zijn. Het is dus een continu probleem, het gaat nog een hele tijd aan de orde - vergis je niet.
En daarmee ga ik het overhandigen aan Dr. Bloor, die wat gedachten over het beveiligen van databases met ons kan delen. Robin, haal het weg.
Robin Bloor: OK, een van de interessante hacks, ik denk dat het ongeveer vijf jaar geleden plaatsvond, maar in feite was het een kaartverwerkingsbedrijf dat werd gehackt. En een groot aantal kaartgegevens werden gestolen. Maar het interessante eraan was voor mij het feit dat het de testdatabase was waar ze daadwerkelijk in terecht kwamen, en het was waarschijnlijk het geval dat ze veel moeite hadden om in de werkelijke, echte database met verwerkingskaarten te komen. Maar je weet hoe het is met ontwikkelaars, ze nemen gewoon een deel van een database en stoppen die erin. Er zou veel meer waakzaamheid moeten zijn geweest om dat te stoppen. Maar er zijn veel interessante verhalen over hacken, het maakt op één gebied een heel interessant onderwerp.
Dus ik ga eigenlijk op een of andere manier een aantal dingen herhalen die Eric zei, maar het is gemakkelijk om gegevensbeveiliging als een statisch doel te beschouwen; het is gemakkelijker alleen omdat het gemakkelijker is om statische situaties te analyseren en vervolgens te denken aan het aanbrengen van verdedigingen, verdedigingen daar, maar dat is het niet. Het is een bewegend doel en dat is een van de dingen die de gehele beveiligingsruimte definieert. Het is gewoon zoals alle technologie evolueert, de technologie van de slechteriken evolueert ook. Dus, kort overzicht: datadiefstal is niets nieuws, in feite is dataspionage datadiefstal en dat is volgens mij al duizenden jaren aan de gang.
De grootste gegevensoverval in die termen waren de Britten die de Duitse codes overtreden en de Amerikanen die de Japanse codes overtreden, en in beide gevallen hebben ze de oorlog vrijwel aanzienlijk ingekort. En ze waren gewoon nuttige en waardevolle gegevens aan het stelen, het was natuurlijk heel slim, maar weet je, wat er nu aan de hand is, is op veel manieren heel slim. Cyberdiefstal werd geboren met internet en explodeerde rond 2005. Ik ging naar alle statistieken kijken en toen je echt serieus begon te worden en, op de een of andere manier, opmerkelijk hoge cijfers vanaf ongeveer 2005. Het is alleen maar erger geworden sinds vervolgens. Veel spelers, overheden zijn betrokken, bedrijven zijn betrokken, hackergroepen en individuen.
Ik ging naar Moskou - dat moet ongeveer vijf jaar zijn geweest - en ik heb eigenlijk veel tijd doorgebracht met een man uit het VK, die de hele hackruimte onderzoekt. En hij zei dat - en ik heb geen idee of dit waar is, ik heb er alleen zijn woord voor, maar het klinkt heel waarschijnlijk - dat er in Rusland iets is dat het Business Network wordt genoemd, een groep hackers die allemaal, weet je, ze kwamen uit de ruïnes van de KGB. En ze verkopen zichzelf, niet alleen, ik bedoel, ik weet zeker dat de Russische overheid ze gebruikt, maar ze verkopen zichzelf aan iedereen, en er werd gerucht, of hij zei dat het gerucht ging, dat verschillende buitenlandse regeringen het Bedrijfsnetwerk gebruikten voor plausibele ontkenning. Deze jongens hadden netwerken van miljoenen gecompromitteerde pc's die ze konden aanvallen. En ze hadden alle tools die je je kunt voorstellen.
Dus de technologie van aanval en verdediging evolueerde. En bedrijven hebben een zorgplicht voor hun gegevens, of ze die nu bezitten of niet. En dat begint veel duidelijker te worden in termen van de verschillende stukjes regelgeving die eigenlijk al van kracht zijn of in werking treden. En waarschijnlijk zal het verbeteren, iemand is op de een of andere manier, moet iemand de kosten van het hacken dragen op een manier dat hij wordt gestimuleerd de mogelijkheid te sluiten. Dat is een van de dingen die volgens mij nodig is. Dus over de hackers kunnen ze zich overal bevinden. Met name binnen uw organisatie - bij heel wat ingenieuze hacks waarvan ik heb gehoord dat iemand de deur opendeed. Weet je, de persoon, het is net als de situatie van bankrovers, bijna altijd zeiden ze bij goede bankovervallen dat er een insider was. Maar de insider hoeft alleen informatie te geven, dus het is moeilijk om ze te krijgen, om te weten wie het was, enzovoort, enzovoort.
En het kan moeilijk zijn om ze voor het gerecht te brengen, want als je gehackt wordt door een groep mensen in Moldavië, zelfs als je weet dat het die groep was, hoe ga je een soort juridische gebeurtenis om hen heen gebeuren? Het is een beetje, van het ene rechtsgebied naar het andere, het is gewoon, er is geen heel goede set internationale regelingen om de hackers vast te pinnen. Ze delen technologie en informatie; veel ervan is open source. Als je je eigen virus wilt bouwen, zijn er tal van virussets beschikbaar - volledig open source. En ze hebben aanzienlijke bronnen, er is een aantal geweest dat botnets had in meer dan een miljoen gecompromitteerde apparaten in datacenters en op pc's enzovoort. Sommige zijn winstgevende bedrijven die al heel lang gaan, en dan zijn er regeringsgroepen, zoals ik al zei. Het is onwaarschijnlijk, zoals Eric zei, het is onwaarschijnlijk dat dit fenomeen ooit zal eindigen.
Dus dit is een interessante hack waarvan ik dacht dat ik het zou noemen, omdat het een vrij recente hack was; het gebeurde vorig jaar. Er was een kwetsbaarheid in het DAO-contract dat verband hield met de Etherium-cryptomunt. En het werd besproken op een forum, en binnen een dag werd het DAO-contract gehackt, precies met behulp van die kwetsbaarheid. $ 50 miljoen aan ether werd overgeheveld, waardoor het DAO-project onmiddellijk in een crisis terechtkwam en werd afgesloten. En de Etherium vocht echt om te proberen de hacker geen toegang tot het geld te geven, en ze verminderden zijn manier van werken. Maar men geloofde ook - niet zeker - dat de hacker voorafgaand aan zijn aanval de prijs van ether had ingekort, wetende dat de prijs van ether zou instorten en dus op een andere manier winst zou maken.
En dat is een andere, als je wilt, strategie die de hackers kunnen gebruiken. Als ze je aandelenprijs kunnen beschadigen, en ze weten dat ze dat zullen doen, dan is het alleen nodig voor hen om de aandelenprijs te korten en de hack te doen, dus het is een beetje, deze jongens zijn slim, weet je. En de prijs is regelrechte diefstal van geld, verstoring en losgeld, inclusief investeringen, waarbij u de voorraad, sabotage, identiteitsdiefstal, allerlei zwendel verstoort en onderbreekt, alleen voor reclame. En het is vaak politiek, of duidelijk, informatie spionage en er zijn zelfs mensen die de kost verdienen met de beloningen die je kunt krijgen door te proberen Google, Apple, Facebook te hacken - zelfs het Pentagon geeft eigenlijk beloningen. En je hackt gewoon; als het succesvol is, ga je gewoon je prijs opeisen en wordt er geen schade aangericht, dus dat is een leuke zaak, weet je.
Ik kan net zo goed melding maken van compliance en regelgeving. Afgezien van sectorinitiatieven zijn er tal van officiële voorschriften: HIPAA, SOX, FISMA, FERPA en GLBA zijn allemaal Amerikaanse wetgeving. Er zijn normen; PCI-DSS is een vrij algemene standaard geworden. En dan is er ISO 17799 over data-eigendom. Nationale voorschriften verschillen van land tot land, zelfs in Europa. En momenteel de GDPR - de wereldwijde gegevens, waar staat het voor? Global Data Protection Regulation, ik denk dat het voor staat - maar dat treedt volgend jaar in werking, zei. En het interessante eraan is dat het overal ter wereld van toepassing is. Als u 5.000 of meer klanten hebt, over wie u persoonlijke informatie hebt en die in Europa wonen, dan zal Europa u daadwerkelijk aan het werk zetten, ongeacht of uw bedrijf daadwerkelijk zijn hoofdkantoor heeft of waar het actief is. En de straffen, de maximale boete is vier procent van de jaarlijkse omzet, wat gewoon enorm is, dus dat zal een interessante wending zijn in de wereld, wanneer dat van kracht wordt.
Dingen om over na te denken, nou ja, DBMS-kwetsbaarheden, de meeste waardevolle gegevens zitten eigenlijk in databases. Het is waardevol omdat we heel veel tijd hebben gestoken in het beschikbaar stellen en goed organiseren ervan en dat maakt het kwetsbaarder, als u niet echt de juiste DBMS-effecten toepast. Als u van plan bent om dit soort dingen te plannen, moet u natuurlijk vaststellen wat kwetsbare gegevens in de hele organisatie zijn, rekening houdend met het feit dat gegevens om verschillende redenen kwetsbaar kunnen zijn. Het kunnen klantgegevens zijn, maar het kunnen ook interne documenten zijn die waardevol zijn voor spionagedoeleinden, enzovoort. Het beveiligingsbeleid, met name met betrekking tot toegangsbeveiliging - die naar mijn mening de afgelopen tijd erg zwak is geweest in de nieuwe open source-dingen - codering wordt meer in gebruik omdat het behoorlijk solide is.
De kosten van een inbreuk op de beveiliging wisten de meeste mensen niet, maar als je kijkt naar wat er is gebeurd met organisaties die te maken hebben gehad met inbreuken op de beveiliging, blijkt dat de kosten van een inbreuk op de beveiliging vaak veel hoger zijn dan je denkt . En dan is het andere ding om over na te denken het aanvalsoppervlak, omdat elk stukje software dat overal met uw organisaties draait, een aanvalsoppervlak heeft. Dat geldt ook voor alle apparaten, de gegevens ook, ongeacht hoe deze zijn opgeslagen. Het is allemaal, het aanvalsoppervlak groeit met het internet der dingen, het aanvalsoppervlak zal waarschijnlijk verdubbelen.
Dus, eindelijk, DBA en gegevensbeveiliging. Gegevensbeveiliging is meestal een onderdeel van de rol van de DBA. Maar het werkt ook samen. En het moet onderworpen zijn aan het bedrijfsbeleid, anders wordt het waarschijnlijk niet goed geïmplementeerd. Dat gezegd hebbende, denk ik dat ik de bal kan passeren.
Eric Kavanagh: Oké, ik zal de sleutels aan Vicky geven. En u kunt uw scherm delen of naar deze dia's gaan, het is aan u, neem het mee.
Vicky Harp: Nee, ik begin met deze dia's, heel erg bedankt. Dus, ja, ik wilde gewoon even een moment nemen en mezelf voorstellen. Ik ben Vicky Harp. Ik ben een manager, productbeheer voor SQL-producten bij IDERA-software, en voor diegenen die ons misschien niet kennen, IDERA heeft een aantal productlijnen, maar ik spreek hier voor de SQL Server-kant van dingen. En dus doen we prestatiebewaking, beveiligingsnaleving, back-up, beheertools - en het is gewoon een soort lijst van hen. En natuurlijk, waar ik het vandaag over heb, is beveiliging en compliance.
Het grootste deel van waar ik het vandaag over wil hebben, is niet noodzakelijkerwijs onze producten, hoewel ik van plan ben daar later enkele voorbeelden van te geven. Ik wilde met u meer praten over databasebeveiliging, enkele van de bedreigingen in de wereld van databasebeveiliging op dit moment, een aantal dingen om over na te denken, en enkele inleidende ideeën over waar u naar moet kijken om uw SQL te beveiligen Serverdatabases en ook om ervoor te zorgen dat ze voldoen aan het regelgevingskader waaraan u mogelijk onderworpen bent, zoals vermeld. Er zijn veel verschillende voorschriften van kracht; ze gaan op verschillende industrieën, verschillende plaatsen over de hele wereld, en dit zijn dingen om over na te denken.
Dus ik wil een beetje de tijd nemen om te praten over de staat van datalekken - en niet te veel herhalen van wat hier al is besproken - ik heb deze Intel-beveiligingsstudie onlangs bekeken en over hun - denk ik Ongeveer 1500 organisaties waarmee ze spraken - ze hadden gemiddeld zes inbreuken op de beveiliging, in termen van inbreuken op gegevensverlies, en 68 procent daarvan had op een of andere manier openbaarmaking nodig, dus beïnvloedden ze de aandelenkoers, of ze moesten krediet doen monitoring voor hun klanten of hun werknemers, etc.
Enkele interessante andere statistieken zijn dat interne actoren verantwoordelijk waren voor 43 procent daarvan. Dus veel mensen denken veel aan hackers en dit soort louche quasi-gouvernementele organisaties of georganiseerde misdaad, enz., Maar interne actoren ondernemen nog steeds rechtstreeks actie tegen hun werkgevers, in een behoorlijk groot deel van de gevallen. En deze zijn soms moeilijker te beschermen, omdat mensen legitieme redenen kunnen hebben om toegang tot die gegevens te hebben. Ongeveer de helft daarvan, 43 procent was op een of andere manier verlies. Dus bijvoorbeeld in het geval dat iemand gegevens mee naar huis heeft genomen en die gegevens vervolgens uit het oog heeft verloren, wat me naar dit derde punt leidt, namelijk dat er nog 40 procent van de inbreuken op fysieke media te maken hadden. Dat zijn dus USB-sleutels, dat zijn laptops van mensen, dat zijn echte media die op fysieke schijven werden gebrand en uit het gebouw werden gehaald.
Als je erover nadenkt, heb je een ontwikkelaar die een dev-kopie van je productiedatabase op hun laptop heeft? Dan gaan ze in het vliegtuig en stappen ze uit het vliegtuig, en krijgen de ingecheckte bagage en hun laptop is gestolen. U heeft nu een gegevenslek. Je denkt misschien niet noodzakelijkerwijs dat dat de reden is waarom die laptop is genomen, hij komt misschien nooit in het wild opdagen. Maar dat is nog steeds iets dat als een inbreuk geldt, het zal openbaarmaking vereisen, je zult alle downstream-effecten hebben van het verlies van die gegevens, alleen vanwege het verlies van die fysieke media.
En het andere interessante is dat veel mensen denken dat creditcardgegevens en creditcardinformatie de meest waardevolle zijn, maar dat is niet echt het geval meer. Die gegevens zijn waardevol, creditcardnummers zijn nuttig, maar eerlijk gezegd worden die nummers zeer snel gewijzigd, terwijl de persoonlijke gegevens van mensen niet erg snel worden gewijzigd. Iets dat recent nieuws, relatief recent, VTech, een speelgoedmaker, dit speelgoed had dat voor kinderen was ontworpen. En mensen zouden, ze zouden de namen van hun kinderen hebben, ze zouden informatie hebben over waar de kinderen wonen, ze hadden de namen van hun ouders, ze hadden foto's van de kinderen. Niets daarvan was gecodeerd, omdat het niet belangrijk werd geacht. Maar hun wachtwoorden waren gecodeerd. Nou, toen de inbreuk onvermijdelijk gebeurde, zeg je: "OK, dus ik heb een lijst met kindernamen, de namen van hun ouders, waar ze wonen - al deze informatie is beschikbaar en je denkt dat het wachtwoord was daar het meest waardevolle deel van? ' mensen kunnen die aspecten van hun persoonlijke gegevens, hun adres, enz. niet veranderen. En dus is informatie eigenlijk heel waardevol en moet het worden beschermd.
Dus, wilde het hebben over enkele van de dingen die gaande zijn, om bij te dragen aan de manier waarop datalekken zich nu voordoen. Een van de grote hotspots, ruimtes op dit moment is social engineering. Dus mensen noemen het phishing, er is nabootsing, enz., Waar mensen toegang krijgen tot gegevens, vaak via interne actoren, door ze gewoon te overtuigen dat ze verondersteld worden er toegang toe te hebben. Dus onlangs hadden we deze Google Documenten-worm die rondging. En wat het zou gebeuren - en ik ontving er zelfs een kopie van, hoewel ik er gelukkig niet op klikte - je kreeg een e-mail van een collega die zei: "Hier is een Google Doc-link; je moet hierop klikken om te zien wat ik zojuist met je heb gedeeld. 'Nou, dat in een organisatie die Google Documenten gebruikt, dat is heel conventioneel, je zult tientallen van die verzoeken per dag krijgen. Als je erop zou klikken, zou het je om toestemming vragen voor toegang tot dit document, en misschien zou je zeggen: "Hé, dat ziet er een beetje vreemd uit, maar weet je, het ziet er ook legitiem uit, dus ik ga door en klik erop ', en zodra je dat deed, gaf je deze derde partij toegang tot al je Google-documenten en dus creëerde je deze link voor deze externe actor om toegang te krijgen tot al je documenten op Google Drive. Dit kwam overal op gang. Het trof honderdduizenden mensen in enkele uren. En dit was fundamenteel een phishing-aanval die Google zelf uiteindelijk moest afsluiten, omdat het zeer goed werd uitgevoerd. Mensen vielen ervoor.
Ik noem hier de SnapChat HR-inbreuk. Dit was gewoon een kwestie van e-mailen, zich voordoen als de CEO, e-mailen naar de HR-afdeling en zeggen: "Ik wil dat je me deze spreadsheet stuurt." En ze geloofden hen en ze plaatsten een spreadsheet met 700 verschillende werknemers 'compensatie-informatie, hun thuisadressen, enz., e-mailden deze naar deze andere partij, het was eigenlijk niet de CEO. Nu waren de gegevens bekend en was alle persoonlijke, privéinformatie van hun werknemers beschikbaar en beschikbaar voor exploitatie. Dus, social engineering is iets dat ik het in de wereld van databases noem, omdat dit iets is dat je kunt proberen te verdedigen door middel van onderwijs, maar je moet ook gewoon onthouden dat overal waar je een persoon hebt die interactie heeft met je technologie, en als u vertrouwt op hun gezond verstand om een storing te voorkomen, vraagt u veel van hen.
Mensen maken fouten, mensen klikken op dingen die ze niet zouden moeten hebben, mensen vallen voor slimme list. En u kunt heel hard proberen om ze daartegen te beschermen, maar het is niet sterk genoeg, u moet proberen het vermogen van mensen om deze informatie per ongeluk in uw databasesystemen te verspreiden, te beperken. Het andere dat ik wilde vermelden, is dat we het natuurlijk over ransomware, botnets, virussen hebben - al deze verschillende geautomatiseerde manieren. En dus wat ik belangrijk vind om te begrijpen over ransomware, is dat het het winstmodel voor aanvallers echt verandert. In het geval dat je het over een inbreuk hebt, moeten ze in zekere zin gegevens extraheren en voor zichzelf hebben en er gebruik van maken. En als uw gegevens onduidelijk zijn, als ze gecodeerd zijn, als het branchespecifiek is, hebben ze er misschien geen waarde voor.
Tot nu toe hadden mensen misschien het gevoel dat dat een bescherming voor hen was: "Ik hoef mezelf niet te beschermen tegen een datalek, want als ze in mijn systeem komen, hebben ze is, ik ben een fotostudio, ik heb een lijst met wie er op welke dagen het komende jaar komt. Wie geeft daarom? 'Nou, het antwoord is dat jij daar om geeft; u slaat die informatie op, het is uw bedrijfskritische informatie. Dus met behulp van ransomware zal een aanvaller zeggen: "Nou, niemand anders zal me hier geld voor geven, maar jij wel." Dus maken ze gebruik van het feit dat ze de gegevens niet eens hoeven te verspreiden, ze doen het niet ' ze moeten zelfs een inbreuk hebben, ze moeten alleen beveiligingshulpmiddelen aanstootgevend tegen u gebruiken. Ze komen in uw database, ze coderen de inhoud ervan en dan zeggen ze: "OK, we hebben het wachtwoord, en u zult ons $ 5000 moeten betalen om dat wachtwoord te krijgen, anders hebt u gewoon niet deze gegevens niet meer. '
En mensen betalen wel; ze merken dat ze dat moeten doen. MongoDB had een paar maanden geleden een soort groot probleem, ik denk dat het in januari was, waar ransomware volgens mij meer dan een miljoen MongoDB-databases trof die ze openbaar op internet hebben, op basis van enkele standaardinstellingen. En wat het nog erger maakte, is dat mensen betaalden en dus andere organisaties zouden binnenkomen en opnieuw coderen of beweren degenen te zijn die het oorspronkelijk hadden gecodeerd, dus toen je je geld betaalde, en ik denk dat in dat geval terwijl ze vroegen om $ 500, zouden mensen zeggen: “OK, ik zou meer betalen om een onderzoeker te betalen om hier binnen te komen om me te helpen erachter te komen wat er mis is gegaan. Ik betaal gewoon de $ 500. 'En ze betaalden het niet eens aan de juiste acteur, dus ze stapelden zich op bij tien verschillende organisaties en zeiden:' We hebben het wachtwoord 'of' We hebben kreeg de manier om je losgekochte gegevens te ontgrendelen. ”En je zou ze allemaal moeten betalen om het mogelijk te maken.
Er zijn ook gevallen geweest waarin de auteurs van de ransomware bugs hadden, ik bedoel, we hebben het niet over een perfect bovenboord situatie, dus zelfs als het eenmaal is aangevallen, zelfs als je eenmaal hebt betaald, is er geen garantie dat je om al uw gegevens terug te krijgen, wordt een deel hiervan ook gecompliceerd door bewapende InfoSec-tools. Dus de Shadow Brokers is een groep die tools heeft gelekt die van de NSA waren. Het waren hulpmiddelen die door een overheidsinstantie zijn ontworpen voor spionagedoeleinden en die in feite tegen andere overheidsinstanties werken. Sommige van deze zijn echt high profile zero-day-aanvallen, waardoor de bekende beveiligingsprotocollen gewoon opzij vallen. En dus was er een grote kwetsbaarheid in het SMB-protocol, bijvoorbeeld in een van de recente dumps van Shadow Brokers.
En dus kunnen deze tools die hier verschijnen, binnen een paar uur het spel op jou echt veranderen, in termen van je aanvalsoppervlak. Dus wanneer ik hier aan denk, is het iets dat op organisatorisch niveau beveiliging InfoSec zijn eigen functie is, het moet serieus worden genomen. Wanneer we het over databases hebben, kan ik het een beetje verwijderen, je hoeft als databasebeheerder niet per se volledig te begrijpen wat er deze week aan de hand is met de Shadow Brokers, maar je moet weten dat alle van deze zijn aan het veranderen, er zijn dingen aan de hand, en dus de mate waarin je je eigen domein strak en veilig houdt, het zal je echt helpen in het geval dat dingen soort van onder je worden gerukt.
Dus ik wilde hier even de tijd nemen voordat ik specifiek over SQL Server ging praten, om een beetje een open discussie te hebben met onze panelleden over enkele overwegingen met betrekking tot databasebeveiliging. Dus ik ben tot dit punt gekomen, sommige dingen die we niet hebben genoemd, ik wilde het hebben over SQL-injectie als een vector. Dus dit is SQL-injectie, het is duidelijk de manier waarop mensen commando's in een database-systeem invoegen, door de ingangen een beetje te misvormen.
Eric Kavanagh: Ja, ik ontmoette eigenlijk een man - ik denk dat het op de luchtmachtbasis van Andrews was - ongeveer vijf jaar geleden, een consultant die ik met hem in de gang sprak en we waren gewoon een soort oorlogsverhalen aan het delen - geen woordspeling bedoeld - en hij zei dat hij was binnengebracht door iemand om een redelijk hooggeplaatst lid van het leger te raadplegen en de man vroeg hem: "Wel, hoe weten we dat je goed bent in wat je doet?" En dit en dat . En terwijl hij met hen sprak die hij op zijn computer gebruikte, was hij in het netwerk gekomen, gebruikte hij SQL-injectie om in het e-mailregister voor die basis en voor die mensen te komen. En hij vond de e-mail van de persoon waarmee hij praatte en hij liet hem gewoon zijn e-mail op zijn machine zien! En de man zei: "Hoe heb je dat gedaan?" Hij zei: "Wel, ik heb SQL-injectie gebruikt."
Dus dat is slechts vijf jaar geleden en het was op een luchtmachtbasis, toch? Dus, ik bedoel, in termen van context is dit ding nog steeds erg reëel en kan het worden gebruikt met echt angstaanjagende effecten. Ik bedoel, ik zou nieuwsgierig zijn naar eventuele oorlogsverhalen die Robin over dit onderwerp heeft, maar al deze technieken zijn nog steeds geldig. Ze worden nog steeds in veel gevallen gebruikt en het is een kwestie van jezelf opleiden, toch?
Robin Bloor: Nou ja. Ja, het is mogelijk om je te verdedigen tegen SQL-injectie door het werk te doen. Het is gemakkelijk te begrijpen waarom, toen het idee werd uitgevonden en voor het eerst verspreid werd, het gemakkelijk te begrijpen is waarom het zo verdomd succesvol was, omdat je het gewoon in een invoerveld op een webpagina kon stoppen en ervoor kon zorgen dat het gegevens voor je retourneerde, of om gegevens in de database of iets anders te verwijderen - u kunt hiervoor gewoon SQL-code injecteren. Maar het is het ding dat me interesseerde, is dat je weet dat je een beetje parsing zou moeten doen, van elk stukje gegevens dat werd ingevoerd, maar het is heel goed mogelijk om te zien dat iemand dat probeert te doen. En het is echt, ik denk dat het echt zo is, omdat mensen er nog steeds mee wegkomen, ik bedoel, het is gewoon heel vreemd dat er geen gemakkelijke manier is geweest om dat te bestrijden. Weet je, dat iedereen gemakkelijk zou kunnen gebruiken, ik bedoel, voor zover ik weet, is er niet geweest, Vicky, is het wel?
Vicky Harp: Nou, eigenlijk denk ik dat sommige van de gegijzelde oplossingen, zoals SQL Azure, een aantal behoorlijk goede detectiemethoden hebben die gebaseerd zijn op machine learning. Dat is waarschijnlijk wat we in de toekomst zullen zien, is iets dat het probeert te vinden met de one size fits all. Ik denk dat het antwoord is dat er niet één maat past, maar we hebben wel machines die kunnen leren wat jouw maat is en ervoor zorgen dat je erbij past, toch? En dus als je een vals positief hebt, is het omdat je eigenlijk iets ongewoons doet, niet omdat je alles hebt moeten doornemen en nauwkeurig moet identificeren wat je applicatie ooit zou kunnen doen.
Ik denk dat een van de redenen dat het echt nog steeds zo productief is, is dat mensen nog steeds vertrouwen op applicaties van derden, en applicaties van ISV's en die worden in de loop van de tijd uitgesmeerd. Dus je hebt het over een organisatie die een engineering-applicatie heeft gekocht die in 2001 is geschreven. En ze hebben deze niet bijgewerkt, omdat er sindsdien geen grote functionele veranderingen zijn geweest en de oorspronkelijke auteur ervan een soort was, ze waren geen ingenieur, ze waren geen databasebeveiligingsexpert, ze deden de dingen niet op de juiste manier in de toepassing en ze blijken een vector te zijn. Ik begrijp dat - ik denk dat het de Datalek was, de echt grote - de aanvalsvector was geweest via een van hun leveranciers van airconditioning, toch? Dus het probleem met die derde partij, je kunt, als je een eigen ontwikkelingswinkel hebt, misschien een aantal van deze regels hebben en het generiek doen wanneer je maar wilt. Als organisatie kunt u honderden of zelfs duizenden applicaties draaien, met alle verschillende profielen. Ik denk dat dat is waar machine learning zal komen en ons gaat helpen.
Mijn oorlogsverhaal was educatief leven. Ik kreeg een SQL-injectieaanval te zien en iets dat me nooit was opgevallen, is dat ik gewoon leesbare SQL gebruik. Ik doe deze dingen die onduidelijke P SQL-vakantiekaarten worden genoemd; Ik vind het leuk om te doen, je maakt deze SQL zo verwarrend mogelijk. Er is een onduidelijke C ++ codewedstrijd die al decennia aan de gang is, en het is ongeveer hetzelfde idee. Dus wat je eigenlijk kreeg was de SQL-injectie die in een open stringveld stond, het sloot de string, zette het in de puntkomma, en vervolgens voerde het een exec-commando in dat vervolgens een reeks getallen had en toen gebruikte het eigenlijk de commando om die getallen in binair te gieten en vervolgens die op zijn beurt in karakterwaarden te gieten en die vervolgens uit te voeren. Het is dus niet zo dat je iets te zien kreeg dat zei: "Startup verwijderen uit productietabel", het was eigenlijk in numerieke velden gestopt waardoor het veel moeilijker te zien was. En zelfs als je het eenmaal zag, om te identificeren wat er aan de hand was, waren er enkele echte SQL-opnamen nodig om erachter te komen wat er aan de hand was, tegen welke tijd het werk natuurlijk al was gedaan.
Robin Bloor: En een van de dingen die gewoon een fenomeen is in de hele hackwereld is dat als iemand een zwakte vindt en het zich in een stuk software bevindt dat over het algemeen wordt verkocht, weet je, een van de eerste problemen is het databasewachtwoord dat u kreeg toen een database werd geïnstalleerd, waren in feite veel databases gewoon een standaard. En veel DBA's hebben het simpelweg nooit veranderd, en daarom zou je erin kunnen slagen om in het netwerk te komen; je zou dat wachtwoord gewoon kunnen proberen en als het werkte, heb je gewoon de loterij gewonnen. En het interessante is dat al die informatie zeer efficiënt en effectief wordt verspreid onder de hackgemeenschappen op darknet-websites. En ze weten het. Dus ze kunnen vrijwel alles vegen wat er is, een paar instanties vinden en er gewoon automatisch een hack-aanval op gooien, en ze zijn binnen. En dat is, denk ik, dat veel mensen die op zijn minst de periferie van dit alles, begrijp eigenlijk niet hoe snel het hacking-netwerk reageert op kwetsbaarheid.
Vicky Harp: Ja, dat brengt eigenlijk nog een ding naar voren dat ik wilde noemen voordat ik verder ging, dit is het idee van het vullen van referenties, wat iets is dat veel opduikt, dat is dat zodra je referenties ergens voor iemand zijn gestolen, op elke site, zullen die referenties worden geprobeerd over de hele linie te worden hergebruikt. Als u dus dubbele wachtwoorden gebruikt, laten we zeggen, als uw gebruikers het zelfs zo stellen, kan iemand mogelijk toegang krijgen via wat een volledig geldige set referenties lijkt te zijn. Laten we zeggen dat ik hetzelfde wachtwoord heb gebruikt bij Amazon en bij mijn bank, en ook op een forum en dat forum-software is gehackt, nou ja, ze hebben mijn gebruikersnaam en mijn wachtwoord. En ze kunnen diezelfde gebruikersnaam vervolgens gebruiken bij Amazon, of ze gebruiken het bij de bank. En wat de bank betreft, het was een volledig geldige login. Nu kunt u via de volledig geautoriseerde toegang snode acties ondernemen.
Dus dat gaat weer terug naar wat ik zei over de interne inbreuken en het interne gebruik. Als er mensen in uw organisatie zijn die hetzelfde wachtwoord gebruiken voor interne toegang als voor externe toegang, hebt u de mogelijkheid dat iemand binnenkomt en u imiteert via een inbreuk op een andere site die u niet weet het niet eens. En deze gegevens worden zeer snel verspreid. Er zijn lijsten van, ik denk dat de meest recente lading om "ben ik gepwnd" door Troy Hunt, hij zei dat hij een half miljard referenties had, dat wil zeggen - als je kijkt naar het aantal mensen op de planeet - dat is een echt een groot aantal referenties die beschikbaar zijn gesteld voor het invullen van referenties.
Dus ik ga een beetje dieper stappen en praten over SQL Server-beveiliging. Nu wil ik zeggen dat ik niet ga proberen u alles te geven wat u moet weten om uw SQL Server in de komende 20 minuten te beveiligen; dat lijkt een beetje een grote opgave. Dus om te beginnen wil ik zeggen dat er online groepen zijn en bronnen die je zeker kunt googlen, er zijn boeken, er zijn best practices-documenten op Microsoft, er is een virtueel beveiligingshoofdstuk voor de professionele medewerkers bij SQL Server, ze staan op security.pass.org en ze hebben, geloof ik, maandelijkse webcasts en opnames van webcasts om de echte, diepgaande manier van beveiliging met SQL Server te bespreken. Maar dit zijn enkele dingen die ik u, als dataprofessionals, als IT-professionals, als DBA's, wil laten weten dat u moet weten wat betreft SQL Server-beveiliging.
Dus de eerste is fysieke beveiliging. Zoals ik al eerder zei, is het stelen van fysieke media nog steeds heel gewoon. En dus het scenario dat ik gaf met de dev-machine, met een kopie van je database op de dev-machine die wordt gestolen - dat is een extreem veel voorkomende vector, dat is een vector waar je op moet letten en waar je acties tegen wilt ondernemen. Dit geldt ook voor back-upbeveiliging, dus wanneer u een back-up van uw gegevens maakt, moet u er een back-up van maken, gecodeerd, moet u een back-up maken naar een veilige locatie. Vaak worden deze gegevens die echt beschermd waren in de database, zodra het begint te verschijnen in perifere locaties, op dev-machines, op testmachines, we worden een beetje minder voorzichtig met het patchen, we krijgen een beetje minder wees voorzichtig met de mensen die er toegang toe hebben. Het volgende dat u weet, is dat niet-versleutelde databaseback-ups zijn opgeslagen op een openbare share in uw organisatie en beschikbaar zijn voor gebruik door veel verschillende mensen. Dus, denk aan fysieke beveiliging en is net zo eenvoudig als: kan iemand naar boven lopen en gewoon een USB-sleutel in uw server steken? Dat zou je niet moeten toestaan.
Het volgende punt waar ik aan moet denken is platformbeveiliging, dus up-to-date besturingssysteem, up-to-date patches. Het is erg vervelend om mensen te horen praten over het blijven werken met oudere versies van Windows, oudere versies van SQL Server, omdat ze denken dat de enige kosten zijn de kosten van de licentie-upgrade, wat niet het geval is. We zijn met beveiliging, het is een stroom die de heuvel afdaalt en naarmate de tijd vordert, worden meer exploits gevonden. Microsoft in dit geval, en andere groepen, in voorkomend geval, zullen oudere systemen tot op zekere hoogte updaten, en uiteindelijk zullen ze uit de ondersteuning vallen en zullen ze deze niet meer bijwerken, omdat het gewoon een eindeloos proces is van onderhoud.
En dus moet je een ondersteund besturingssysteem hebben en op de hoogte zijn van je patches, en we hebben recent gevonden, net als bij Shadow Brokers, in sommige gevallen kan Microsoft inzicht hebben in aanstaande grote inbreuken op de beveiliging openbaar wordt gemaakt, voorafgaand aan openbaarmaking, dus laat jezelf niet allemaal in de war raken. Ik neem liever geen downtime, ik wacht liever en lees ze allemaal door. U weet misschien pas wat de waarde ervan is tot enkele weken nadat u hebt ontdekt waarom deze patch is opgetreden. Dus blijf daar bovenop.
U moet uw firewall hebben geconfigureerd. Het was schokkend in de SNB-inbreuk hoeveel mensen oudere versies van SQL Server hadden met de firewall volledig open voor internet, zodat iedereen binnen kon komen en kon doen wat ze wilden met hun servers. U zou een firewall moeten gebruiken. Het feit dat u af en toe de regels moet configureren of specifieke uitzonderingen moet maken voor de manier waarop u zaken doet, is een goede prijs. U moet de oppervlakte in uw databasesystemen beheren - installeert u services of webservers zoals IIS mee op dezelfde machine? Dezelfde schijfruimte delen, dezelfde geheugenruimte delen als uw databases en uw privégegevens? Probeer dat niet te doen, probeer het te isoleren, het oppervlak kleiner te houden, zodat u zich niet zoveel zorgen hoeft te maken dat alles veilig bovenop de database staat. Je kunt ze fysiek scheiden, platformen, scheiden, jezelf een beetje ademruimte geven.
Je zou geen superbeheerders moeten hebben die overal rondrennen en toegang hebben tot al je gegevens. De OS-beheerdersaccounts hoeven niet noodzakelijkerwijs toegang te hebben tot uw database of tot de onderliggende gegevens in de database via codering, waarover we het zo hebben. En de toegang tot de databasebestanden moet u ook beperken. Het is een beetje dom als je zou zeggen: nou, iemand kan via de database geen toegang krijgen tot deze databases; SQL Server zelf geeft hen geen toegang, maar als ze dan rond kunnen gaan, een kopie van het feitelijke MDF-bestand kunnen nemen, het eenvoudig kunnen verplaatsen, koppelen aan hun eigen SQL Server, heb je niet echt heel veel bereikt veel.
Codering, dus codering is dat beroemde tweeweg zwaard. Er zijn veel verschillende niveaus van codering die u kunt doen op OS-niveau en de hedendaagse manier om dingen te doen voor SQL en Windows is met BitLocker en op databaseniveau wordt dit TDE of transparante gegevenscodering genoemd. Dit zijn dus beide manieren om uw gegevens in rust te versleutelen. Als u uw gegevens uitgebreider wilt houden, kunt u versleuteld doen - sorry, ik ben een beetje vooruit gegaan. U kunt gecodeerde verbindingen maken, zodat deze tijdens het transport nog steeds gecodeerd zijn, zodat als iemand luistert of een man midden in een aanval zit, u die gegevens via de draad kunt beschermen. Je back-ups moeten worden gecodeerd, zoals ik al zei, ze kunnen toegankelijk zijn voor anderen en dan, als je wilt dat het in het geheugen wordt gecodeerd en tijdens gebruik, hebben we kolomcodering en dan heeft SQL 2016 het idee van "altijd gecodeerd 'waar het feitelijk wordt gecodeerd op schijf, in het geheugen, op de draad, helemaal tot aan de toepassing die feitelijk gebruik maakt van de gegevens.
Nu, al deze codering is niet gratis: er is CPU-overhead, er is soms voor de kolomcodering en het altijd gecodeerde geval, er zijn gevolgen voor de prestaties in termen van uw vermogen om te zoeken naar die gegevens. Deze versleuteling betekent echter, als deze correct is samengesteld, dat als iemand toegang tot uw gegevens zou krijgen, de schade aanzienlijk wordt verminderd, omdat ze deze konden krijgen en er dan niets mee kunnen doen. Dit is echter ook de manier waarop ransomware werkt, is dat iemand naar binnen gaat en deze items aanzet, met hun eigen certificaat of hun eigen wachtwoord en je hebt er geen toegang toe. Daarom is het belangrijk om ervoor te zorgen dat je dit doet en dat je er toegang toe hebt, maar je geeft het niet open voor anderen en aanvallers om te doen.
En dan, beveiligingsprincipes - ik ga dit punt niet verder uitwerken, maar zorg ervoor dat niet elke gebruiker in SQL Server als superbeheerder draait. Je ontwikkelaars willen het misschien, verschillende gebruikers willen het - ze zijn gefrustreerd omdat ze om toegang voor individuele items moeten vragen - maar je moet daar zorgvuldig mee omgaan, en hoewel het misschien gecompliceerder is, toegang geven tot de objecten en de databases en de schema's die geldig zijn voor doorlopend werk, en er is een speciaal geval, misschien betekent dat een speciale login, het betekent niet noodzakelijkerwijs een verhoging van rechten, voor de gemiddelde gebruiker.
En dan zijn er overwegingen met betrekking tot de naleving van de regelgeving die hierop aansluiten en sommige gevallen kunnen eigenlijk op hun eigen manier afgaan - dus er is HIPAA, SOX, PCI - er zijn al deze verschillende overwegingen. En wanneer u een audit doorloopt, wordt van u verwacht dat u aantoont dat u acties onderneemt om hieraan te blijven voldoen. En dus, dit is veel om bij te houden, ik zou zeggen als een DBA-takenlijst, je probeert de beveiliging van de fysieke coderingsconfiguratie te garanderen, je probeert ervoor te zorgen dat de toegang tot die gegevens wordt gecontroleerd voor uw nalevingsdoeleinden, ervoor te zorgen dat uw gevoelige kolommen, dat u weet wat ze zijn, waar ze zijn, welke u moet coderen en de toegang bekijken. En ervoor zorgen dat configuraties in overeenstemming zijn met de wettelijke richtlijnen waaraan u onderworpen bent. En je moet dit allemaal up-to-date houden omdat de dingen veranderen.
Dus het is veel te doen, en als ik het daar zou laten, zou ik zeggen, ga dat doen. Maar daar zijn veel verschillende tools voor, en daarom wilde ik u in de laatste paar minuten enkele van de tools laten zien die we daarvoor bij IDERA hebben. En de twee waar ik het vandaag over wilde hebben zijn SQL Secure en SQL Compliance Manager. SQL Secure is onze tool om de kwetsbaarheid van de configuratie te helpen identificeren. Uw beveiligingsbeleid, uw gebruikersrechten, uw oppervlakteconfiguraties. En het heeft sjablonen om u te helpen aan verschillende regelgevingskaders te voldoen. Dat op zichzelf, die laatste regel, zou de reden kunnen zijn voor mensen om het te overwegen. Omdat het doorlezen van deze verschillende voorschriften en het identificeren van wat dat betekent, PCI en dat vervolgens helemaal naar mijn SQL Server in mijn winkel brengen, dat is een hoop werk. Dat is iets waarvoor je veel adviesgeld zou kunnen betalen; we zijn gegaan en hebben dat advies gedaan, we hebben samengewerkt met de verschillende auditbedrijven, etc., om te bedenken wat die sjablonen zijn - iets dat waarschijnlijk een audit zal doorstaan als deze aanwezig zijn. En dan kunt u die sjablonen gebruiken en ze in uw omgeving bekijken.
We hebben ook een ander, soort zustertool in de vorm van SQL Compliance Manager, en dit is waar SQL Secure over configuratie-instellingen gaat. SQL Compliance Manager gaat over wat is gedaan door wie, wanneer. Het is dus auditing, zodat u de activiteit kunt volgen terwijl deze plaatsvindt en u kunt detecteren en bijhouden wie toegang heeft tot dingen. Was er iemand, het voorbeeld dat een beroemdheid is, ingecheckt in je ziekenhuis, ging iemand zijn informatie opzoeken, gewoon uit nieuwsgierigheid? Hadden ze daar een reden voor? U kunt een kijkje nemen in de auditgeschiedenis en zien wat er aan de hand was, wie toegang had tot die gegevens. En u kunt identificeren dat dit tools heeft om u te helpen gevoelige kolommen te identificeren, dus u hoeft niet per se door te lezen en dat allemaal zelf te doen.
Dus als ik mag, ga ik je in de laatste paar minuten hier enkele van die tools laten zien - en beschouw het alsjeblieft niet als een diepgaande demo. Ik ben een productmanager, geen verkoopingenieur, dus ik ga je enkele dingen laten zien die volgens mij relevant zijn voor deze discussie. Dit is dus ons SQL Secure-product. En zoals je hier kunt zien, heb ik zo'n soort rapport op hoog niveau. Ik heb dit gisteren gedaan, denk ik. En het toont me enkele dingen die niet correct zijn ingesteld en sommige dingen die correct zijn ingesteld. Je ziet dus dat er een behoorlijk aantal meer dan 100 verschillende controles zijn die we hier hebben uitgevoerd. En ik zie dat mijn back-upversleuteling op de back-ups die ik heb gemaakt, geen back-upversleuteling heb gebruikt. Mijn SA-account, expliciet "SA-account" genoemd, is niet uitgeschakeld of hernoemd. De openbare serverrol heeft toestemming, dus dit zijn allemaal dingen die ik zou willen bekijken om te veranderen.
Ik heb het beleid hier ingesteld, dus als ik een nieuw beleid wilde instellen om op mijn servers toe te passen, hebben we al deze ingebouwde beleidsregels. Dus ik zal een bestaande beleidssjabloon gebruiken en je kunt zien dat ik CIS, HIPAA, PCI, SR heb, en we zijn bezig met het continu toevoegen van extra beleid, gebaseerd op de dingen die mensen in het veld nodig hebben . En u kunt ook een nieuw beleid maken, dus als u weet waar uw auditor naar op zoek is, kunt u het zelf maken. En dan, wanneer u dit doet, kunt u kiezen uit al deze verschillende instellingen, welke u moet instellen, in sommige gevallen hebt u er enkele - laat me teruggaan en een van de vooraf gebouwde vinden. Dit is handig, ik kan bijvoorbeeld HIPAA kiezen - ik heb al HIPAA, mijn slechte - PCI, en dan, terwijl ik hier rondklik, zie ik de externe kruisverwijzing naar het gedeelte van de regelgeving waaraan dit gerelateerd is. Dus dat zal je later helpen, wanneer je probeert uit te vinden waarom stel ik dit in? Waarom probeer ik hiernaar te kijken? Aan welke sectie houdt dit verband?
Dit heeft ook een leuke tool omdat het je toelaat om door je gebruikers te bladeren, dus een van de lastige dingen over het verkennen van je gebruikersrollen, is dat ik hier eigenlijk een kijkje ga nemen. Dus, als ik machtigingen voor mijn laat zien, laten we eens kijken, laten we hier een gebruiker kiezen. Machtigingen weergeven. Ik zie de toegewezen machtigingen voor deze server, maar dan kan ik hier klikken en de effectieve machtigingen berekenen, en het geeft me de volledige lijst op basis, dus in dit geval is dit admin, dus het is niet zo opwindend, maar Ik zou kunnen doorlopen en de verschillende gebruikers kiezen en zien wat hun effectieve machtigingen zijn, gebaseerd op alle verschillende groepen waartoe ze kunnen behoren. Als je dit ooit alleen probeert te doen, kan het eigenlijk een beetje gedoe zijn om erachter te komen, OK deze gebruiker is lid van deze groepen en heeft daarom toegang tot deze dingen via groepen, enz.
Dus, de manier waarop dit product werkt, is dat het snapshots maakt, dus het is echt geen heel moeilijk proces om regelmatig een snapshot van de server te maken en dan worden die snapshots in de tijd bewaard zodat je ze kunt vergelijken voor veranderingen. Dit is dus geen continue monitoring in de traditionele zin van als een prestatiebewakingsinstrument; dit is iets dat je misschien hebt ingesteld om eenmaal per nacht, eenmaal per week te worden uitgevoerd - hoe vaak je ook denkt dat het geldig is - zodat je, wanneer je de analyse doet en een beetje meer doet, eigenlijk gewoon werken binnen onze tool. Je maakt niet zo vaak verbinding met je server, dus dit is een aardig hulpmiddel om mee te werken, om aan dat soort statische instellingen te voldoen.
De andere tool die ik je wil laten zien is onze Compliance Manager-tool. Compliance Manager gaat op een meer continue manier monitoren. En het gaat zien wie wat op uw server doet en u toelaten er naar te kijken. Dus wat ik hier de afgelopen paar uur heb gedaan, heb ik eigenlijk geprobeerd een paar kleine problemen te creëren. Dus hier heb ik of het een probleem is of niet, ik weet het misschien, iemand heeft eigenlijk een login gemaakt en aan een serverrol toegevoegd. Dus als ik naar binnen ga en daarnaar kijk, zie ik - ik denk dat ik daar niet met de rechtermuisknop kan klikken, ik kan zien wat er aan de hand is. Dus dit is mijn dashboard en ik zie dat ik vandaag eerder een aantal mislukte aanmeldingen had. Ik had een heleboel beveiligingsactiviteit, DBL-activiteit.
Dus laat me naar mijn auditevenementen gaan en een kijkje nemen. Hier heb ik mijn auditgebeurtenissen gegroepeerd per categorie en doelobject, dus als ik naar die beveiliging van eerder kijk, zie ik DemoNewUser, dit creëerde server login. En ik kan zien dat de login SA dit DemoNewUser-account heeft gemaakt, hier om 14:42 uur. En dan zie ik dat op zijn beurt login toevoegen aan de server, deze DemoNewUser is toegevoegd aan de serverbeheerdersgroep, ze zijn toegevoegd aan de setup admin groep, ze zijn toegevoegd aan de sysadmin groep. Dus dat is iets waarvan ik zou willen weten dat het was gebeurd. Ik heb het ook zo ingesteld dat de gevoelige kolommen in mijn tabellen worden bijgehouden, zodat ik kan zien wie er toegang toe heeft gehad.
Dus, hier heb ik een paar geselecteerde die zijn opgetreden op mijn persoonstafel, van Adventure Works. En ik kan een kijkje nemen en zien dat gebruiker SA op de Adventure Works-tafel een selecte top tien-ster van person dot person heeft gemaakt. Dus misschien wil ik in mijn organisatie niet dat mensen sterren selecteren van persoon punt persoon, of ik verwacht dat alleen bepaalde gebruikers dit doen, en dus ga ik dit hier zien. Dus, de - wat u nodig hebt met betrekking tot uw auditing, kunnen we dat instellen op basis van het raamwerk en dit is een beetje een intensievere tool. Het gebruikt SQL Trace of SQLX-gebeurtenissen, afhankelijk van de versie. En het is iets dat je wat headroom op je server moet hebben om te huisvesten, maar het is een van die dingen, een soort van verzekering, wat leuk is als we geen autoverzekering nodig hadden - het zou een kosten die we niet zouden moeten nemen - maar als je een server hebt waar je moet bijhouden wie wat doet, moet je misschien een beetje extra hoofdruimte en een hulpmiddel als dit hebben om dit te doen. Of u onze tool nu gebruikt of zelf gebruikt, u bent uiteindelijk verantwoordelijk voor het hebben van deze informatie voor compliance-doeleinden.
Dus zoals ik al zei, geen diepgaande demo, maar een korte, korte samenvatting. Ik wilde je ook een snelle, kleine gratis tool laten zien in de vorm van deze SQL Column Search, wat je kunt gebruiken om te identificeren welke kolommen in je omgeving gevoelige informatie lijken te zijn. We hebben dus een aantal zoekconfiguraties waarbij wordt gezocht naar de verschillende namen van kolommen die gewoonlijk gevoelige gegevens bevatten, en dan heb ik deze hele lijst met geïdentificeerde. Ik heb er 120 en vervolgens heb ik ze hier geëxporteerd, zodat ik ze kan gebruiken om te zeggen, laten we gaan kijken en ervoor zorgen dat ik de toegang volg tot de middelste naam, één persoon dot persoon of omzetbelasting tarief, etc.
Ik weet dat we aan het einde van onze tijd hier gelijk krijgen. En dat is alles wat ik je eigenlijk moest laten zien, dus vragen voor mij?
Eric Kavanagh: Ik heb een paar goede voor je. Laat me hier naar boven scrollen. Een van de aanwezigen stelde een hele goede vraag. Een daarvan is vragen over de prestatiebelasting, dus ik weet dat deze verschilt van oplossing tot oplossing, maar heb je een algemeen idee van wat de prestatiebelasting is voor het gebruik van IDERA beveiligingshulpmiddelen?
Vicky Harp: Dus, op SQL Secure, zoals ik al zei, het is erg laag, het gaat gewoon af en toe een paar snapshots maken. En zelfs als je vrij vaak hebt gelopen, krijgt het statische informatie over instellingen, en dus is het erg laag, bijna te verwaarlozen. In termen van Compliance Manager is het -
Eric Kavanagh: Zoals één procent?
Vicky Harp: Als ik een percentagegetal moest geven, zou het één procent of lager zijn. Het is basisinformatie over de volgorde van het gebruik van SSMS en naar het tabblad Beveiliging gaan en dingen uitbreiden. Aan de kant van de compliance is het veel hoger - daarom heb ik gezegd dat het een beetje stahoogte nodig heeft - het is een beetje alsof het veel verder gaat dan wat je hebt op het gebied van prestatiebewaking. Nu wil ik mensen er niet van wegjagen, de truc met nalevingsmonitoring, en als het auditing is, moet je ervoor zorgen dat je alleen controleert waar je actie op gaat ondernemen. Dus als je eenmaal naar beneden filtert om te zeggen: "Hé, ik wil weten wanneer mensen toegang hebben tot deze specifieke tabellen, en ik wil weten wanneer mensen toegang hebben tot deze specifieke acties, " dan zal het gebaseerd zijn op hoe vaak deze dingen zijn gebeurt en hoeveel gegevens genereert u. Als u zegt: "Ik wil de volledige SQL-tekst van elke selectie die ooit in een van deze tabellen voorkomt", dan worden mogelijk gigabytes en gigabytes aan gegevens die moeten worden ontleed door SQL Server, verplaatst naar ons product, enz.
Als je het tot een beperkt houdt, zal het ook meer informatie zijn dan je waarschijnlijk zou kunnen behandelen. Als je het zou kunnen terugbrengen tot een kleinere set, zodat je een paar honderd evenementen per dag krijgt, dan is dat duidelijk veel lager. Dus echt, in sommige opzichten is de hemel de limiet. Als je alle instellingen op alle monitoring voor alles inschakelt, ja, dan wordt het een prestatiepercentage van 50 procent. Maar als je het op een wat gematigder niveau gaat zetten, zou ik misschien 10 procent oog hebben? Het is echt, het is een van die dingen waarvan het erg afhankelijk zal zijn van je werklast.
Eric Kavanagh: Ja, toch. Er is nog een vraag over hardware. En dan komen er hardwareleveranciers die meedoen aan de game en echt samenwerken met softwareleveranciers en ik antwoordde via het Q & A-venster. Ik ken een specifiek geval, van Cloudera die met Intel werkte, waarin Intel die enorme investering in hen deed, en een deel van de calculus was dat Cloudera vroeg toegang zou krijgen tot het chipontwerp, en dus in staat zou zijn om beveiliging te integreren in het chipniveau van de architectuur, die behoorlijk indrukwekkend is. Maar het is toch iets dat er uit gaat komen en nog steeds door beide partijen kan worden uitgebuit. Kent u trends of tendensen van hardwareleveranciers om samen te werken met softwareleveranciers aan het beveiligingsprotocol?
Vicky Harp: Ja, eigenlijk geloof ik dat Microsoft heeft samengewerkt om een deel van, zoals, de geheugenruimte voor een deel van het coderingswerk te hebben, feitelijk gebeurt op afzonderlijke chips op moederborden die los staan van je hoofdgeheugen, zodat sommige van dat spul is fysiek gescheiden. En ik geloof dat dit eigenlijk iets was dat van Microsoft kwam in termen van uitgaan naar de leveranciers om te zeggen: "Kunnen we een manier bedenken om dit te maken, eigenlijk is het een niet-adresseerbaar geheugen, ik kan niet door een bufferoverloop deze herinnering, omdat het er in zekere zin zelfs niet is, dus ik weet wel dat er iets gebeurt. "
Eric Kavanagh: Ja.
Vicky Harp: Dat zullen waarschijnlijk de echt grote leveranciers zijn, hoogstwaarschijnlijk.
Eric Kavanagh: Ja. Ik ben daar nieuwsgierig naar, en misschien is Robin, als je even tijd hebt, nieuwsgierig naar je ervaring door de jaren heen, want nogmaals, in termen van hardware, in termen van de feitelijke materiaalkunde die gaat in wat u van de leverancierskant samenstelt, kan die informatie naar beide kanten gaan, en theoretisch gaan we redelijk snel naar beide kanten, dus is er een manier om de hardware zorgvuldiger te gebruiken, vanuit een ontwerpperspectief om de veiligheid te versterken? Wat denk je? Robin, sta je stil?
Robin Bloor: Ja, ja. Het spijt me, ik ben hier; Ik denk alleen maar aan de vraag. Om eerlijk te zijn, ik heb geen mening, het is een gebied dat ik niet diepgaand heb bekeken, dus ik ben een beetje, weet je, ik kan een mening verzinnen, maar ik weet het niet echt. Ik heb liever dat dingen veilig zijn in software, het is gewoon de manier waarop ik speel, eigenlijk.
Eric Kavanagh: Ja. Welnu, mensen, we hebben een uur doorgebrand en veranderen hier. Grote dank aan Vicky Harp voor haar tijd en aandacht - voor al je tijd en aandacht; we waarderen het dat je voor deze dingen komt opdagen. Het is een groot probleem; het zal niet snel verdwijnen. Het is een kat-en-muisspel dat zal blijven gaan en gaan en gaan. En dus zijn we dankbaar dat sommige bedrijven daar zijn, gericht op het inschakelen van beveiliging, maar zoals Vicky zelfs in haar presentatie aan het woord kwam en erover sprak, uiteindelijk zijn het mensen in organisaties die heel goed moeten nadenken over deze phishing-aanvallen, dat soort social engineering en houd uw laptops vast - laat het niet achter in de koffieshop! Verander je wachtwoord, doe de basis en je krijgt 80 procent van de weg daarheen.
Dus daarmee, mensen, we gaan je vaarwel zeggen, nogmaals bedankt voor je tijd en aandacht. We zullen je de volgende keer inhalen, wees voorzichtig. Tot ziens.
Vicky Harp: Dag, bedankt.
