Av Techopedia Staff, 10. mai 2017
Takeaway: Vert Eric Kavanagh diskuterer sikkerhet og tillatelser med Dr. Robin Bloor og IDERAs Vicky Harp.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: OK, mine damer og herrer, hei og velkommen tilbake igjen. Det er en onsdag, det er fire østlige og i verden av enterprise teknologi som betyr at det er på tide igjen for Hot Technologies! Ja absolutt. Presentert av Bloor Group selvfølgelig, drevet av våre venner på Techopedia. Temaet for i dag er veldig kult: "Bedre å spørre om tillatelse: beste praksis for personvern og sikkerhet." det blir virkelig mer alvorlig hver dag, helt ærlig. Det er en alvorlig sak på mange måter for mange organisasjoner. Vi skal snakke om det, og vi skal snakke om hva du kan gjøre for å beskytte organisasjonen din mot de skumle karakterene som ser ut til å være over alt i disse dager.
Så dagens programleder er Vicky Harp som ringer inn fra IDERA. IDERA-programvare kan du se på LinkedIn - jeg elsker den nye funksjonaliteten på LinkedIn. Selv om jeg kan fortelle at de trekker noen strenger på visse måter, ikke lar deg få tilgang til folk, prøver å få deg til å kjøpe premium medlemskap. Der går du, vi har vår helt egen Robin Bloor, og ringer inn - han er faktisk i San Diego-området i dag. Og din virkelig som din moderator / analytiker.
Så hva snakker vi om? Data brudd. Jeg tok nettopp denne informasjonen fra IdentityForce.com, den er allerede av stabelen. Vi er i mai selvfølgelig i år, og det er bare massevis av datainnbrudd, det er noen virkelig store, selvfølgelig, av Yahoo! var en stor en, og vi hørte selvfølgelig om den amerikanske regjeringen ble hacket. Vi hadde nettopp det franske valget hacket.
Dette skjer overalt, det fortsetter og det kommer ikke til å stoppe, så det er en realitet, det er den nye virkeligheten, som de sier. Vi trenger virkelig å tenke på måter å håndheve sikkerheten til våre systemer og våre data. Og det er en pågående prosess, så det er akkurat i tide å tenke på alle de forskjellige sakene som kommer inn. Dette er bare en delvis liste, men dette gir deg et perspektiv på hvor usikker situasjonen er i dag med bedriftssystemer. Og før dette showet snakket vi i løsmakten før show om ransomware som har truffet noen jeg kjenner, noe som er en veldig ubehagelig opplevelse, når noen tar over iPhonen din og krever penger for at du skal få tilgang til telefonen din. Men det skjer, det skjer med datamaskiner, det skjer med systemer, jeg så akkurat her om dagen, det skjer med milliardærer med yachten deres. Se for deg å dra til yachten din en dag, prøv å imponere alle vennene dine, og du kan ikke engang slå den på, for en tyv har stjålet tilgang til kontrollene, kontrollpanelet. Jeg sa nettopp forleden i et intervju til noen, har alltid den manuelle overstyringen. Jeg er ikke en stor fan av alle tilkoblede biler - til og med biler kan bli hacket. Alt som er koblet til internett, eller koblet til et nettverk som kan penetreres, kan bli hacket, hva som helst.
Så her er det bare noen få ting å ta i betraktning når det gjelder å innramme konteksten av hvor alvorlig situasjonen er. Nettbaserte systemer er overalt i disse dager, de fortsetter å spre seg. Hvor mange mennesker kjøper ting på nettet? Det er bare gjennom taket i disse dager, det er derfor Amazon er en så kraftig styrke i disse dager. Det er fordi så mange mennesker kjøper ting på nettet.
Så du husker den gangen, for 15 år siden, folk var ganske nervøse for å legge kredittkortet sitt i et nettskjema for å få informasjonen sin, og den gang var argumentet: “Vel, hvis du overlater kredittkortet ditt til en servitør på en restaurant, så er det den samme tingen. ”Så, svaret vårt er ja, det er det samme, det er alle disse kontrollpunktene, eller tilgangspunkter, samme ting, den andre siden av den samme mynten, der folk kan plasseres i fare, der noen kan ta pengene dine, eller noen kan stjele fra deg.
Da utvider IoT selvfølgelig trusselbildet - jeg elsker det ordet - med størrelsesordener. Jeg mener, tenk på det - med alle disse nye enhetene overalt, hvis noen kan hacke seg inn i et system som kontrollerer dem, kan de snu alle disse robotene mot deg og forårsake mange problemer, så det er et veldig alvorlig problem. Vi har en global økonomi i disse dager, som utvider trusselbildet enda mer, og dessuten har du mennesker i andre land som kan få tilgang til nettet på samme måte som du og jeg kan, og hvis du ikke vet hvordan du snakker russisk, eller et hvilket som helst antall andre språk, har du vanskelig for å forstå hva som skjer når de hacker seg inn i systemet ditt. Så vi har fremskritt innen nettverk og virtualisering, det er bra.
Men jeg har på høyre side av dette bildet her, et sverd og grunnen til at jeg har det der, er fordi hvert sverd kutter begge veier. Det er et tveegget sverd, som de sier, og det er en gammel klisjé, men det betyr at sverdet jeg har kan skade deg eller at det kan skade meg. Det kan komme tilbake på meg, enten ved å sprette tilbake, eller av at noen tar det. Det er faktisk en av Aesops fabler - vi gir ofte fiendene våre verktøy for vår egen ødeleggelse. Det er virkelig den overbevisende historien og har å gjøre med noen som brukte pil og bue og skjøt ned en fugl og fuglesagen, mens pilen kom opp, den fjæren fra den ene fuglens venner var på pilkanten, på baksiden av pilen for å lede den, og han tenkte for seg selv: “Å, her er det, mine egne fjær, min egen familie kommer til å bli brukt til å ta meg ned.” Det skjer hele tiden, hører du statistikk om at du har en pistol i huset, tyven kan ta pistolen. Vel, dette stemmer. Så jeg kaster dette ut som en analogi bare for å vurdere, alle disse forskjellige utviklingene har positive sider og negative sider.
Og snakk om containere for de av dere som virkelig følger banebrytende virksomhetsberegning, containere er den siste tingen, siste måte å levere funksjonalitet, det er virkelig ekteskapet med virtualisering i den serviceorienterte arkitekturen, i det minste for mikroservices og det er veldig interessante ting. Du kan absolutt gjemme bort sikkerhetsprotokollene dine, applikasjonsprotokollene dine og dataene dine og så videre, ved å bruke containere, og det gir deg et forskudd i en periode, men før eller senere vil skurkene finne ut av det, og så blir det enda vanskeligere å forhindre at de utnytter systemene dine. Så det er det, det er global arbeidsstyrke som kompliserer nettverket og sikkerheten, og hvor folk logger seg på fra.
Vi har nettleserkrigene som fortsetter raskt, og krever kontinuerlig arbeid for å oppdatere og holde oss oppdatert. Vi hører stadig om de gamle Microsoft Explorer-nettleserne, hvordan de ble hacket og tilgjengelige der inne. Så det er mer penger å tjene på hacking i disse dager, det er en hel bransje, dette er noe som partneren min, Dr. Bloor, lærte meg for åtte år siden - jeg lurte på hvorfor vi ser så mye av det, og han minnet om meg, det er en hel bransje som er involvert i hacking. Og i den forstand er fortellingen, som er et av mine minst favorittord om sikkerhet, virkelig veldig uærlig, fordi fortellingen viser deg i alle disse videoene og alle slags nyhetsdekninger noe hacking de viser noen fyr i hettegenser, sittende i kjelleren hans i et mørkt opplyst rom, er det slett ikke tilfelle. Det er overhode ikke representativt for virkeligheten. Det er ensomme hackere, det er veldig få ensomme hackere, de er der ute, de skaper problemer - de kommer ikke til å forårsake store problemer, men de kan tjene mye penger. Så det som skjer er at hackerne kommer inn, og trenger inn i systemet ditt og så selger den tilgangen til noen andre, som snur seg og selger den til noen andre, og så et sted nede på linjen, utnytter noen det hacket og drar nytte av deg. Og det er utallige måter å dra nytte av stjålne data på.
Jeg har til og med undret meg over hvordan vi har glamorisert dette konseptet. Du ser dette begrepet overalt, "veksthakk" som om det er bra. Veksthacking, vet du, hacking kan være en god ting, hvis du prøver å jobbe for de gode guttene for å si det og hacke inn i et system, som vi fortsetter å høre om med Nord-Korea og deres missiloppskytninger, og potensielt bli hacket - det er bra. Men hacking er ofte en dårlig ting. Så nå glamoriserer vi det, nesten som Robin Hood, da vi glamoriserte Robin Hood. Og så er det det kontantløse samfunnet, noe som helt ærlig angår dagslyset fra meg. Alt jeg tenker hver gang jeg hører det, er: “Nei, vær så snill, ikke gjør det! Vær så snill og ikke! ”Jeg vil ikke at alle pengene våre skal forsvinne. Så dette er bare noen problemer å vurdere, og igjen, det er et katt-og-mus-spill; det kommer aldri til å stoppe, det vil alltid være behov for sikkerhetsprotokoller og for å fremme sikkerhetsprotokoller. Og for å overvåke systemene dine for selv å vite og føle hvem som er der ute, med forståelsen av at det til og med kan være en innsidejobb. Så det er en pågående problem, det kommer til å være en pågående problem i ganske lang tid - gjør ingen feil om det.
Og med det skal jeg overlevere det til Dr. Bloor, som kan dele med oss noen tanker om sikring av databaser. Robin, ta den bort.
Robin Bloor: OK, et av de interessante hakkene, jeg tror det skjedde for omtrent fem år siden, men i utgangspunktet var det et kortbehandlingsfirma som ble hacket. Og et stort antall kortdetaljer ble stjålet. Men det interessante med det, for meg, var det faktum at det var testdatabasen som de faktisk kom inn i, og det var sannsynligvis slik at de hadde store problemer med å komme inn i den faktiske, virkelige databasen med behandlingskort. Men du vet hvordan det er med utviklere, de tar bare et kutt av en database, skyver den der inne. Det måtte ha vært langt mer årvåkenhet for å stoppe det. Men det er mange interessante hackinghistorier, det gjør i ett område, det gjør et veldig interessant emne.
Så jeg skal faktisk, på en eller annen måte, gjenta noen av tingene som Eric sa, men det er lett å tenke på datasikkerhet som et statisk mål; det er lettere bare fordi det er lettere å analysere statiske situasjoner og deretter tenke på å sette inn forsvar, forsvar der, men det er det ikke. Det bevegelige målet, og det er en av tingene som slags definerer hele sikkerhetsrommet. Det er bare slik all teknologi utvikler seg, teknologien til skurkene utvikler seg også. Så kort oversikt: Datatyveri er ikke noe nytt, faktisk er spionasje av data datatyveri, og det har pågått i tusenvis av år, tror jeg.
De største dataene i disse vilkårene var at britene brøt de tyske kodene og amerikanerne som brøt de japanske kodene, og i begge tilfeller forkortet de krigen veldig betydelig. Og de stjal bare nyttige og verdifulle data, det var selvfølgelig veldig smart, men du vet, det som skjer akkurat nå er veldig smart på mange måter. Cyber-tyveri ble født med internett og eksploderte rundt 2005. Jeg gikk og så på all statistikken, og da du begynte å bli virkelig alvorlig, og på en eller annen måte, bemerkelsesverdig høye tall som startet i ca 2005. Det har bare blitt verre siden deretter. Mange aktører, myndigheter er involvert, virksomheter er involvert, hackergrupper og enkeltpersoner.
Jeg dro til Moskva - det må ha gått omtrent fem år - og jeg tilbrakte faktisk mye tid med en fyr fra Storbritannia, som forsker på hele hackingsplassen. Og han sa det - og jeg aner ikke om dette stemmer, jeg har bare ordet for det, men det høres veldig sannsynlig ut - at i Russland er det noe som heter Business Network, som er en gruppe av hackere som alle er, du vet, de kom ut av ruinene til KGB. Og de selger seg selv, ikke bare, jeg mener, jeg er sikker på at den russiske regjeringen bruker dem, men de selger seg selv til hvem som helst, og det ble ryktet, eller han sa det var ryktet, at forskjellige utenlandske regjeringer brukte Business Network for plausibel denierbarhet. Disse karene hadde nettverk med millioner av kompromitterte PC-er som de kunne angripe fra. Og de hadde alle verktøyene du kan forestille deg.
Så teknologien for angrep og forsvar utviklet seg. Og bedrifter har en aktsomhetsplikt over dataene sine, enten de eier dem eller ikke. Og det begynner å bli mye tydeligere når det gjelder de forskjellige reguleringsdelene som allerede er i kraft, eller som trer i kraft. Og sannsynligvis vil det forbedre seg, noen er på en eller annen måte, noen må bære kostnadene for hacking på en slik måte at de er incentiv for å legge ned muligheten. Det er en av tingene som jeg antar er nødvendig. Så om hackerne, kan de være plassert hvor som helst. Spesielt i organisasjonen din - utrolig mange geniale hacks som jeg har hørt om involvert noen som åpner døren. Du vet, personen, det er som bankrøver-situasjonen, nesten alltid pleide de å si i gode bankraner at det er en innsider. Men innsiden trenger bare å gi ut informasjon, så det er vanskelig å få dem, å vite hvem det var, og så videre og så videre.
Og det kan være vanskelig å bringe dem for retten, for hvis du har blitt hacket av en gruppe mennesker i Moldova, selv om du vet at det var den gruppen, hvordan skal du få en slags juridisk begivenhet til å skje rundt dem? Det er slags, fra en jurisdiksjon til en annen, det er bare, det er ikke et veldig bra sett med internasjonale ordninger for å feste hackerne. De deler teknologi og informasjon; mye av det er åpen kildekode. Hvis du vil bygge ditt eget virus, er det mange viruspakker der ute - helt åpen kildekode. Og de har betydelige ressurser, det har vært et antall som har hatt botnett på mer enn en million kompromitterte enheter i datasentre og på PC-er og så videre. Noen er lønnsomme virksomheter som har pågått lenge, og så er det regjeringsgrupper, som jeg nevnte. Det er usannsynlig, som Eric sa, det er usannsynlig at dette fenomenet noen gang vil ta slutt.
Så dette er et interessant hack jeg bare trodde jeg skulle nevne det, fordi det var et ganske nylig hack; det skjedde i fjor. Det var en sårbarhet i DAO-kontrakten tilknyttet Etherium-kryptomynten. Og det ble diskutert på et forum, og i løpet av et døgn ble DAO-kontrakten hacket, og benyttet den sårbarheten nøyaktig. 50 millioner dollar i eter ble forsinket, noe som forårsaket en øyeblikkelig krise i DAO-prosjektet og lukket det. Og Etherium kjempet faktisk for å prøve å hindre hackeren fra tilgang til pengene, og de reduserte slags. Men det ble også antatt - ikke kjent med sikkerhet - at hackeren faktisk kortet prisen på eter før hans angrep, vel vitende om at prisen på eter ville kollapse, og dermed tjente på en annen måte.
Og det er en annen, hvis du vil, stratagem som hackerne kan bruke. Hvis de kan skade aksjekursen din, og de vet at de vil gjøre det, er det bare nødvendig for dem å kortslutte aksjekursen og gjøre hackingen, så det er liksom, disse karene er smarte, vet du. Og prisen er direkte tyveri av penger, forstyrrelse og løsepenger, inkludert investeringer, der du forstyrrer og korte ned aksjen, sabotasje, identitetstyveri, alle slags svindel, bare for reklamens skyld. Og det har en tendens til å være politisk, eller tydeligvis, spionering av informasjon, og det er til og med mennesker som tjener penger på bug-belønningene du kan få ved å prøve å hacke Google, Apple, Facebook - til og med Pentagon, faktisk gir feilbeløp. Og du bare hacker; hvis det er vellykket, bare gå og kreve premien din, og ingen skader er gjort, så det er en fin ting, vet du.
Jeg kan like godt nevne etterlevelse og regulering. Bortsett fra sektorinitiativer, er det mange offisielle forskrifter: HIPAA, SOX, FISMA, FERPA og GLBA er all lovgivning i USA. Det er standarder; PCI-DSS har blitt en ganske generell standard. Og så er det ISO 17799 om dataeierskap. Nasjonale forskrifter skiller land til land, også i Europa. Og for øyeblikket er GDPR - Global Data, hva står det for? Global Data Protection Regulation, tror jeg den står for - men den trer i kraft neste år, sa til. Og det interessante med det er at det gjelder over hele verden. Hvis du har 5000 eller flere kunder, som du har personlig informasjon om og de bor i Europa, vil Europa faktisk ta deg til oppgaven, uansett om selskapet ditt faktisk har hovedkontor, eller hvor det opererer. Og straffene, den maksimale straffen er fire prosent av de årlige inntektene, som bare er enorme, så det vil være en interessant vri på verden når det trer i kraft.
Ting å tenke på, vel, DBMS-sårbarheter, det meste av verdifulle data sitter faktisk i databaser. Det er verdifullt fordi vi har lagt ned veldig mye tid på å gjøre det tilgjengelig og organisere det godt, og det gjør det mer sårbart, hvis du ikke bruker riktige DBMS-verdipapirer. Selvfølgelig, hvis du planlegger for slike ting, må du identifisere hvilke sårbare data som er i hele organisasjonen, og husk at data kan være sårbare av forskjellige grunner. Det kan være kundedata, men det kan også være interne dokumenter som vil være verdifulle for spionasjeformål og så videre. Sikkerhetspolitikken, spesielt i forhold til aksessikkerhet - som i nyere tid har vært veldig svak i de nye open source-tingene - kommer kryptering mer i bruk fordi den er ganske bunnsolid.
Kostnaden for et sikkerhetsbrudd, de fleste visste ikke, men hvis du faktisk ser på hva som har skjedd med organisasjoner som har fått sikkerhetsbrudd, viser det seg at kostnadene ved et sikkerhetsbrudd ofte er mye høyere enn du tror det ville vært . Og så er den andre tingen å tenke på angrepsoverflaten, fordi ethvert programvare hvor som helst, som kjører med organisasjonene dine, presenterer en angrepsflate. Så gjør noen av enhetene, og dataene gjør det, uansett hvordan de er lagret. Det hele er, angrepflaten vokser med tingenes internett, angrepsoverflaten kommer nok til å dobles.
Så endelig DBA og datasikkerhet. Datasikkerhet er vanligvis en del av DBAs rolle. Men det er samarbeid, også. Og det må være underlagt selskapspolitikk, ellers blir det sannsynligvis ikke implementert godt. Når det er sagt, tror jeg at jeg kan passere ballen.
Eric Kavanagh: OK, la meg gi nøklene til Vicky. Og du kan dele skjermen eller flytte til disse lysbildene, det er opp til deg, ta den bort.
Vicky Harp: Nei, jeg begynner med disse lysbildene, tusen takk. Så ja, jeg ville bare ta et raskt øyeblikk og presentere meg. Jeg er Vicky Harp. Jeg er en manager, produktstyring for SQL-produkter hos IDERA-programvare, og for de av dere som kanskje ikke er kjent med oss, har IDERA en rekke produktlinjer, men jeg snakker her for SQL Server-siden. Og så gjør vi resultatovervåking, sikkerhetsoverholdelse, sikkerhetskopiering, administrasjonsverktøy - og det er bare en slags liste over dem. Og selvfølgelig, det jeg er her for å snakke om i dag, er sikkerhet og etterlevelse.
Hovedtyngden av det jeg ønsker å snakke om i dag er ikke nødvendigvis produktene våre, selv om jeg har tenkt å vise noen eksempler på det senere. Jeg ville snakke med deg mer om databasesikkerhet, noen av truslene i databasesikkerhetens verden akkurat nå, noen ting å tenke på, og noen av de innledende ideene til hva du trenger å se på for å sikre din SQL Serverdatabaser og også for å sikre at de er i samsvar med det regelverket som du kan være underlagt, som nevnt. Det er mange forskjellige forskrifter på plass; de går på forskjellige bransjer, forskjellige steder rundt om i verden, og dette er ting å tenke på.
Så jeg ønsker litt å ta et øyeblikk og snakke om tilstanden til datainnbrudd - og ikke å gjenta for mye av det som allerede er diskutert her - jeg så over denne Intel sikkerhetsforskningsstudien nylig, og på tvers av deres - tror jeg 1500 organisasjoner de snakket med - de hadde i gjennomsnitt seks sikkerhetsbrudd, når det gjelder brudd på tap av data, og 68 prosent av dem hadde krevd avsløring i en viss forstand, så de påvirket aksjekursen, eller de måtte gjøre noe æren overvåking for sine kunder eller deres ansatte osv.
Noe interessant annen statistikk er at interne aktører som sto for 43 prosent av disse. Så mange mennesker tenker mye på hackere og denne typen lyssky kvasi-regjeringsorganisasjoner eller organisert kriminalitet, etc., men interne aktører tar fortsatt direkte tiltak mot arbeidsgiverne sine, i en ganske høy andel av sakene. Og disse er noen ganger vanskeligere å beskytte mot, fordi folk kan ha legitime grunner til å ha tilgang til disse dataene. Omtrent halvparten av dette var 43 prosent tilfeldig tap i en viss forstand. Så for eksempel i tilfelle hvor noen tok data med seg hjem, og deretter mistet oversikten over disse dataene, noe som fører meg til dette tredje punktet, som er at ting til fysiske medier fortsatt var involvert i 40 prosent av bruddene. Så det er USB-nøkler, det er menneskers bærbare datamaskiner, det er faktiske medier som ble brent på fysiske plater og tatt ut av bygningen.
Hvis du tenker på, har du en utvikler som har en kopi av produksjonsdatabasen din på den bærbare datamaskinen? Så går de på et fly og de går av flyet, og de får den innsjekket bagasjen og den bærbare datamaskinen deres er stjålet. Du har nå hatt et datainnbrudd. Du trenger ikke nødvendigvis tro at det er grunnen til at den bærbare datamaskinen ble tatt, den vil kanskje aldri dukke opp i naturen. Men det er fremdeles noe som regner som et brudd, det kommer til å kreve avsløring, du kommer til å ha alle nedstrøms-effektene av å ha mistet disse dataene, bare på grunn av tapet av det fysiske mediet.
Og den andre interessante tingen er at mange mennesker tenker på kredittdata og kredittkortinformasjon som den mest verdifulle, men det er egentlig ikke tilfelle lenger. Disse dataene er verdifulle, kredittkortnumre er nyttige, men ærlig talt, disse tallene endres veldig raskt, mens folks personlige data ikke endres så raskt. Noe som den siste nyheten, relativt nylig, VTech, en leketøysprodusent, hadde disse lekene som var designet for barn. Og folk ville, de ville ha barna sine navn, de ville ha informasjon om hvor barna bor, de hadde foreldrene sine navn, de hadde bilder av barna. Ingenting av det ble kryptert, fordi det ikke ble ansett som viktig. Men passordene deres var kryptert. Vel, når bruddet uunngåelig skjedde, sier du: "OK, så jeg har en liste over barnenavn, foreldrenes navn, hvor de bor - all denne informasjonen er der ute, og du tenker at passordet var den mest verdifulle delen av det? ”Det var det ikke; folk kan ikke endre disse aspektene om deres personlige data, deres adresse osv. Og slik at informasjon faktisk er veldig verdifull og den må beskyttes.
Så ønsket å snakke om noen av tingene som skjer, for å bidra til måten datainnbrudd skjer akkurat nå. Et av de store hotspots, mellomrom akkurat nå er sosialteknikk. Så folk kaller det phishing, det er etterligning osv., Der folk får tilgang til data, ofte gjennom interne aktører, ved bare å overbevise dem om at de skal ha tilgang til det. Så her om dagen hadde vi denne Google Docs-ormen som gikk rundt. Og hva det ville skje - og jeg fikk faktisk en kopi av den, selv om jeg heldigvis ikke klikket på den - du fikk e-post fra en kollega og sa: “Her er en Google Doc-kobling; må du klikke på dette for å se hva jeg nettopp har delt med deg. ”Vel, i en organisasjon som bruker Google Dokumenter, det er veldig konvensjonelt, kommer du til å få dusinvis av disse forespørslene om dagen. Hvis du klikket på det, ville det be deg om tillatelse til å få tilgang til dette dokumentet, og kanskje du ville sagt: "Hei, det ser litt rart ut, men du vet, det ser legitim ut også, så jeg vil gå foran og klikk på den, ”og så snart du gjorde det, ga du denne tredjeparten tilgang til alle Google-dokumentene dine, og slik opprettet du denne lenken for at denne eksterne aktøren skal få tilgang til alle dokumentene dine på Google Drive. Dette ormer over alt. Det rammet hundretusener av mennesker i løpet av timer. Og dette var i grunnen et phishing-angrep som Google selv endte med å legge ned, fordi det var veldig bra utført. Folk falt for det.
Jeg nevner her SnapChat HR-bruddet. Dette var bare et enkelt spørsmål om at noen sendte en e-post, og forkynte at de var administrerende direktør, e-post til HR-avdelingen og sa: "Jeg trenger at du sender meg dette regnearket." kompensasjonsinformasjon, hjemmeadressene osv., sendte den til denne andre parten via e-post, det var faktisk ikke administrerende direktør. Nå var dataene ute, og alle de ansattes personlige, private opplysninger var der ute og tilgjengelige for utnyttelse. Så sosialteknikk er noe jeg nevner det i databasenes verden, fordi dette er noe du kan prøve å forsvare deg mot gjennom utdanning, men du må også bare huske at hvor som helst der du har en person som samhandler med teknologien din, og Hvis du er avhengig av deres gode skjønn for å forhindre et brudd, spør du mange av dem.
Folk gjør feil, folk klikker på ting de ikke burde ha, folk faller for smarte russen. Og du kan prøve veldig hardt for å beskytte dem mot det, men det er ikke sterkt nok, du må prøve å begrense muligheten for at folk ved et uhell gir ut denne informasjonen i databasesystemene dine. Den andre tingen jeg ønsket å nevne at åpenbart vi snakker om mye er ransomware, botnett, virus - alle disse forskjellige automatiserte måtene. Og det jeg synes er viktig å forstå om ransomware, er at det virkelig endrer gevinstmodellen for angripere. I tilfelle at du snakker om et brudd, må de på en eller annen måte hente ut data og ha det for seg selv og benytte seg av det. Og hvis dataene dine er obskure, hvis de er kryptert, hvis de er bransjespesifikke, har de kanskje ingen verdi for det.
Fram til dette tidspunktet, kan folk ha følt at det var en beskyttelse for dem, "Jeg trenger ikke å beskytte meg mot et datainnbrudd, fordi hvis de kommer inn i systemet mitt, alt det de kommer til å ha er, jeg er et fotograferingsstudio, jeg har en liste over hvem som kommer på hvilke dager for det neste året. Hvem bryr seg om det? ”Vel, det viser seg at svaret er at du bryr deg om det; du lagrer den informasjonen, det er din virksomhetskritiske informasjon. Så ved å bruke ransomware vil en angriper si: "Vel, ingen andre kommer til å gi meg penger for dette, men det vil du også." Så de utnytter det faktum at de ikke engang trenger å få ut dataene, de trenger ikke til og med å ha et brudd, de trenger bare å bruke sikkerhetsverktøy offensivt mot deg. De kommer inn i databasen din, de krypterer innholdet i den, og så sier de: “OK, vi har passordet, og du må betale oss 5000 dollar for å få det passordet, ellers har du bare ikke disse dataene lenger. ”
Og folk betaler seg; de finner seg selv nødt til å gjøre det. MongoDB hadde et slags stort problem for et par måneder siden, antar det var i januar, der ransomware traff, tror jeg, over en million MongoDB-databaser de har offentlig til internett, basert på noen standardinnstillinger. Og det som gjorde det enda verre er at folk betalte, og at andre organisasjoner ville komme inn og kryptere på nytt eller påstå at de hadde vært de som opprinnelig hadde kryptert det, så når du betalte pengene dine, og jeg tror i så fall de var På spørsmål om $ 500, ville folk si: “OK, jeg ville betale mer enn det for å betale en forsker for å komme hit for å hjelpe meg med å finne ut hva som gikk galt. Jeg betaler bare 500 dollar. ”Og de betalte ikke en gang til riktig skuespiller, så de ville bli stablet videre med ti forskjellige organisasjoner som sa til dem, “ Vi har passordet, ”eller“ Vi har fikk veien for deg å låse opp løsepengene dine. ”Og du må betale dem alle for å muligens få dem til å fungere.
Det har også vært tilfeller der ransomware-forfatterne hadde feil, jeg mener, vi snakker ikke om at det er en perfekt situasjon over bord, så selv når den har blitt angrepet, selv når du har betalt, er det ingen garanti for at du er Hvis du vil få alle dataene dine tilbake, blir noe av dette komplisert i tillegg med våpne InfoSec-verktøy. Så Shadow Brokers er en gruppe som har lekket ut verktøy som var fra NSA. De var verktøy designet av myndighetene for spionasje og faktisk jobbe mot andre myndigheter. Noen av disse har vært virkelig høyprofilerte angrep på null dager, som i utgangspunktet gjør at de kjente sikkerhetsprotokollene bare faller til side. Og slik var det en stor sårbarhet i SMB-protokollen, for eksempel i en av de siste Shadow Brokers 'dumps.
Og slik at disse verktøyene som kommer ut her, i løpet av et par timer, virkelig kan endre spillet på deg, med tanke på angrepsoverflaten din. Så når jeg tenker på dette, er det noe som, på organisatorisk nivå, at InfoSec er sin egen funksjon, det må tas på alvor. Når vi snakker om databaser, kan jeg ta det litt ned, du trenger ikke nødvendigvis å ha som databaseadministrator full forståelse av hva som skjer med Shadow Brokers denne uken, men du må være klar over at alle av disse skifter, det er ting som skjer, og så i hvilken grad du holder ditt eget domene tett og sikkert, vil det virkelig hjelpe deg i tilfelle at ting slags blir dratt ut under deg.
Så jeg ville ta et øyeblikk her, før jeg gikk videre til å snakke om SQL Server spesifikt, for å faktisk ha litt av en åpen diskusjon med våre paneldeltakere om noen av hensynene til databasesikkerhet. Så, jeg har kommet til dette punktet, noen av tingene vi ikke har nevnt, ville jeg snakke om SQL-injeksjon som en vektor. Så dette er SQL-injeksjon, selvfølgelig er det måten folk setter inn kommandoer i et databasesystem, ved å formopprette inngangene.
Eric Kavanagh: Ja, jeg møtte faktisk en fyr - jeg tror det var på Andrews Air Force base - for omtrent fem år siden, en konsulent som jeg snakket med ham på gangen og vi bare delte krigsfortellinger - ingen ordspill ment - og han nevnte at han hadde blitt hentet inn av noen for å rådføre seg med et ganske høyt rangert medlem av militæret, og fyren spurte ham: "Vel, hvordan vet vi at du er flink til det du gjør?" Og dette og det . Og mens han snakket med dem han brukte på datamaskinen sin, hadde han kommet seg inn i nettverket, han brukte SQL-injeksjon for å komme inn i e-postregistret for den basen og for disse menneskene. Og han fant personens e-postadresse som han snakket med, og han bare viste ham e-posten sin på maskinen sin! Og fyren var som: "Hvordan gjorde du det?" Han sa, "Vel, jeg brukte SQL-injeksjon."
Så det var bare fem år siden, og det var på en flyvåpenbase, ikke sant? Så, jeg mener, når det gjelder kontekst, er denne tingen fortsatt veldig ekte, og den kan brukes med virkelig skremmende effekter. Jeg mener, jeg vil være nysgjerrig på å vite om krigsfortellinger som Robin har om emnet, men alle disse teknikkene er fremdeles gyldige. De er fremdeles brukt i mange tilfeller, og det er et spørsmål om å utdanne deg, ikke sant?
Robin Bloor: Vel, ja. Ja, det er mulig å forsvare seg mot SQL-injeksjon ved å gjøre jobben. Det er lett å forstå hvorfor når ideen ble oppfunnet og først spredte seg, er det lett å forstå hvorfor den var så forbanna vellykket, fordi du bare kunne feste den i et inputfelt på en webside og få den til å returnere data for deg, eller få det for å slette data i databasen, eller hva som helst - du kan bare injisere SQL-kode for å gjøre det. Men det er det som interesserte meg, er at det er du vet, du må gjøre litt analysering av hvert stykke data som ble lagt inn, men det er ganske mulig å se at noen prøver å gjøre det. Og det er virkelig, jeg tror det virkelig er, fordi folk fremdeles slipper unna med det, jeg mener det bare er rart at det ikke har vært en enkel måte å bekjempe det på. Du vet, at alle lett kunne bruke, jeg mener, så vidt jeg vet, har det ikke vært, Vicky, der?
Vicky Harp: Vel, faktisk, noen av gisselløsningene, som SQL Azure, tror jeg har noen ganske gode deteksjonsmetoder som er basert på maskinlæring. Det er sannsynligvis det vi kommer til å se fremover, noe som den prøver å komme opp med den ene størrelsen passer alle. Jeg tror at svaret har vært at det ikke er en størrelse som passer alle, men vi har maskiner som kan lære hva størrelsen din er og sørge for at du passer på det, ikke sant? Og slik at hvis du har en falsk positiv, skyldes det at du faktisk gjør noe uvanlig, det ikke fordi du har måttet gjennomgå og omhyggelig identifisere alt applikasjonen din noen gang kan gjøre.
Jeg tror en av grunnene til at det fortsatt er så produktivt, er at folk fortsatt er avhengige av tredjepartsapplikasjoner, og applikasjoner fra ISV-er og de blir smurt ut over tid. Så, du snakker om en organisasjon som har kjøpt et ingeniørprogram som ble skrevet i 2001. Og de har ikke oppdatert det, fordi det ikke har skjedd noen store funksjonsendringer siden den gang, og den opprinnelige forfatteren av den var slags, de var ikke ingeniører, de var ikke databasesikkerhetsekspert, de gjorde ikke ting på riktig måte i applikasjonen og de ender opp med å være en vektor. Min forståelse er at - jeg tror det var brudd på Target data, den virkelig store - angrepsvektoren hadde vært via en av deres leverandører av air condition, ikke sant? Så problemet med disse tredjepartene, kan du, hvis du eier din egen utviklingsbutikk, kan du ha noen av disse reglene på plass og gjøre det generisk når som helst. Som organisasjon kan du ha hundrevis eller tusenvis av applikasjoner som kjører, med alle de forskjellige profilene. Jeg tror det er her maskinlæring kommer til å begynne å hjelpe oss mye.
Krigshistorien min var lærerik. Jeg fikk se et SQL-injeksjonsangrep, og noe som aldri hadde skjedd for meg er å bruke vanlig lesbar SQL. Jeg gjør disse tingene som kalles tilslørt P SQL-feriekort; Jeg liker å gjøre, du får denne SQL til å se så forvirrende ut som mulig. Det er skjult C ++ -kodekonkurranse som har pågått i flere tiår nå, og det er lik den samme ideen. Så, hva du faktisk fikk, var SQL-injeksjonen som var i et åpent strengfelt, det lukket strengen, det satte i semikolonet, og så satte det inn exec-kommando som da hadde en serie med tall, og så brukte den i utgangspunktet casting-kommando for å caste disse tallene i binær og deretter casting disse, i sin tur, til tegnverdier og deretter utføre det. Så det er ikke som du fikk se noe som sa: "Slett oppstart fra produksjonstabellen, " det var faktisk fylt inn i numeriske felt som gjorde det mye vanskeligere å se. Og selv når du så det, for å identifisere hva som skjedde, tok det noen virkelige SQL-skudd, for å kunne finne ut hva som skjedde, på hvilket tidspunkt selvfølgelig arbeidet allerede var gjort.
Robin Bloor: Og en av tingene som bare er et fenomen i hele hackingverdenen er at hvis noen finner en svakhet og det tilfeldigvis er i et programvare som generelt er solgt, vet du, et av de tidlige problemene er databasepassordet du fikk da en database ble installert, faktisk var mange databaser bare en standard. Og mange DBA-er endret det ganske enkelt aldri, og derfor kunne du klare å komme deg inn i nettverket da; du kan bare prøve det passordet, og hvis det fungerte, vel, du bare vant lotteriet. Og det interessante er at all denne informasjonen sirkuleres veldig effektivt og effektivt blant hackingsamfunnene på darknet-nettsteder. Og det vet de. Så de kan ganske mye gjøre en fei av det som er der ute, finne noen få tilfeller og bare automatisk kaste litt hacking utnytte det, og de er i. Og det er, tror jeg, at mange mennesker som minst er på periferien til alt dette, forstår faktisk ikke hvor raskt hackingsnettverket reagerer på sårbarhet.
Vicky Harp: Ja, det bringer faktisk opp en annen ting jeg ønsket å nevne før jeg fortsetter, som er denne forestillingen om legitimasjonsstopping, som er noe som har dukket opp mye, som er at når legitimasjonsbeskrivelsen din først har blitt stjålet for noen hvor som helst, på ethvert sted, vil disse legitimasjonene bli forsøkt brukt på nytt over hele linjen. Så hvis du bruker dupliserte passord, og si at hvis brukerne dine er, til og med, la oss si det på den måten, kan noen være i stand til å få tilgang via det som ser ut til å være et fullstendig gyldig sett med legitimasjon. Så la oss si at jeg har brukt det samme passordet mitt hos Amazon og i banken min, og også på et forum og at forumprogramvaren ble hacket, de har brukernavnet mitt og passordet mitt. Og de kan da bruke det samme brukernavnet hos Amazon, eller så bruker de det i banken. Og for banken var det en fullstendig gyldig innlogging. Nå kan du ta ubehagelige handlinger via den fullstendig autoriserte tilgangen.
Så den slags går tilbake til det jeg sa om de interne bruddene og de interne bruksområdene. Hvis du har folk i organisasjonen din som bruker det samme passordet for intern tilgang som de gjør for ekstern tilgang, har du muligheten for at noen kommer inn og etterligner deg via et brudd på et annet nettsted du ikke gir vet ikke engang. Og disse dataene formidles veldig raskt. Det er lister over, jeg tror at den siste belastningen til "har jeg blitt pwned" av Troy Hunt, sa han at han hadde et halvt milliard sett med legitimasjon, som er - hvis du vurderer antall mennesker på planeten - det er en virkelig stort antall legitimasjonsbeskrivelser som er blitt gjort tilgjengelig for legitimasjon.
Så jeg kommer til å gå litt dypere og snakke om SQL Server-sikkerhet. Nå vil jeg si at jeg ikke skal prøve å gi deg alt du trenger å vite for å sikre din SQL Server i løpet av de neste 20 minuttene; det virker litt av en høy rekkefølge. Så, til og med å starte, vil jeg si at det er grupper online og ressurser på nettet som du absolutt kan Google, det er bøker, det er best-praksis-dokumenter på Microsoft, det er et virtuelt sikkerhetskapittel for profesjonelle medarbeidere på SQL Server, de er på security.pass.org og de har, tror jeg, månedlige webcast og innspillinger av webcast som slags går over den virkelige, dyptgående hvordan du gjør SQL Server-sikkerhet. Men dette er noen av tingene som jeg snakker til deg som datapersonell, som IT-fagpersoner, som DBA-er, jeg vil at du skal vite at du trenger å vite om med SQL Server-sikkerhet.
Så den første er fysisk sikkerhet. Så som jeg sa tidligere, er det fremdeles ekstremt vanlig å stjele fysiske medier. Og så scenariet som jeg ga med dev-maskinen, med en kopi av databasen din på dev-maskinen som blir stjålet - det er en ekstremt vanlig vektor, det er en vektor du må være klar over og prøve å iverksette tiltak mot. Det gjelder også for sikkerhetskopiering, så når du tar sikkerhetskopi av dataene dine, må du sikkerhetskopiere den kryptert, må du ta sikkerhetskopi til et sikkert sted. Mange ganger disse dataene som virkelig ble beskyttet i databasen, så snart de begynner å komme ut på periferilokaliteter, på dev-maskiner, på testmaskiner, blir vi litt mindre forsiktige med lappen, vi blir litt mindre nøye med menneskene som har tilgang til det. Den neste tingen du vet, har du krypterte sikkerhetskopier av databaser lagret på en offentlig andel i organisasjonen din tilgjengelig for utnyttelse fra mange forskjellige mennesker. Så tenk på fysisk sikkerhet, og kan det være så enkelt som noen gå opp og bare sette en USB-nøkkel på serveren din? Du skal ikke tillate det.
Neste vare jeg vil at du skal tenke på er plattformsikkerhet, så oppdatert operativsystem, oppdaterte oppdateringer. Det er veldig slitsomt å høre folk snakke om å bo på eldre versjoner av Windows, eldre versjoner av SQL Server, og tenke at den eneste kostnaden i spillet er kostnadene ved lisensoppgraderingen, noe som ikke er tilfelle. Vi er med sikkerhet, det er en strøm som fortsetter å gå ned bakken og etter hvert som tiden går, blir flere utnyttelser funnet. Microsoft i dette tilfellet, og andre grupper etter hvert som de vil være, vil de oppdatere eldre systemer til et punkt, og til slutt vil de falle utenfor støtten, og de vil ikke oppdatere dem lenger, fordi det bare er en uendelig prosess med vedlikehold.
Og så, du må være på et støttet operativsystem, og du må være oppdatert om oppdateringene dine, og vi har nylig funnet som hos Shadow Brokers, i noen tilfeller kan Microsoft ha innsikt i kommende store sikkerhetsbrudd, før de blir offentliggjort før avsløringen, så ikke la deg vri deg i orden. Jeg vil helst ikke ta driftsstansen, jeg vil heller vente og lese hver enkelt av dem og bestemme. Det er ikke sikkert du vet hva verdien er før noen uker etter at du har funnet ut hvorfor denne oppdateringen oppstod. Så hold deg på toppen av det.
Du bør ha brannmuren konfigurert. Det var sjokkerende i SNB-bruddet hvor mange som kjørte eldre versjoner av SQL Server med brannmuren helt åpen for internett, slik at noen kunne komme inn og gjøre hva de ville med serverne sine. Du bør bruke en brannmur. Det at du tidvis må konfigurere reglene eller gjøre spesifikke unntak for måten du gjør din virksomhet på, er en OK pris å betale. Du må kontrollere overflaten i databasesystemene dine - installerer du tjenester eller webservere som IIS på samme maskin? Deler du den samme diskplassen, deler den samme minneplassen som databasene dine og dine private data? Prøv å ikke gjøre det, prøv å isolere det, hold overflaten mindre, slik at du ikke trenger å bekymre deg så mye for å sørge for at alt dette er sikkert på toppen av databasen. Du kan liksom fysisk skille dem, plattformen, skille dem, gi deg selv litt pusterom.
Du skal ikke ha superadministratorer som løper rundt overalt og kan få tilgang til alle dataene dine. Det er ikke nødvendigvis at OS-administrasjonskontoer trenger å ha tilgang til databasen din, eller til de underliggende dataene i databasen via kryptering, som vi snakker om om et øyeblikk. Og tilgangen til databasefilene, må du også begrense det. Det er litt dumt hvis du skulle si, vel, noen har ikke tilgang til disse databasene via databasen; SQL Server i seg selv vil ikke tillate dem å få tilgang til den, men hvis de da kan gå rundt, ta en kopi av den faktiske MDF-filen, flytte den over ganske enkelt, fest den til sin egen SQL Server, du har ikke virkelig oppnådd veldig mye.
Kryptering, så kryptering er det berømte toveis sverdet. Det er mange forskjellige nivåer av kryptering som du kan gjøre på OS-nivå, og den moderne måten å gjøre ting for SQL og Windows på er med BitLocker, og på databasenivå kalles det TDE eller gjennomsiktig datakryptering. Så dette er begge måter å holde dataene kryptert i ro. Hvis du vil holde dataene dine kryptert mer omfattende, kan du kryptere - beklager, jeg har litt gått foran. Du kan opprette krypterte tilkoblinger slik at den fremdeles er kryptert, når den er i transitt, slik at hvis noen lytter på eller har en mann midt i et angrep, har du en viss beskyttelse av disse dataene over ledningen. Sikkerhetskopiene dine må være kryptert, som sagt, de kan være tilgjengelige for andre, og hvis du vil at den skal være kryptert i minnet og under bruk, har vi kolonnekryptering, og da har SQL 2016 denne forestillingen om "alltid kryptert ”der den faktisk er kryptert på disk, i minnet, på ledningen, helt til applikasjonen som faktisk benytter seg av dataene.
Nå er ikke all denne krypteringen gratis: Det er CPU-overhead, det er noen ganger for kolonnekryptering og alltid kryptert tilfelle. Det har konsekvenser for ytelsen når det gjelder din evne til å søke på disse dataene. Imidlertid er denne krypteringen, hvis den er ordentlig satt sammen, betyr det at hvis noen skulle få tilgang til dataene dine, blir skadene kraftig redusert, fordi de klarte å få det, og da kan de ikke gjøre noe med det. Imidlertid er dette også måten ransomware fungerer på, at noen går inn og slår på disse varene, med sitt eget sertifikat eller sitt eget passord, og du har ikke tilgang til det. Så det er derfor det er viktig å sørge for at du gjør dette, og at du har tilgang til det, men du gir ikke det, åpent for at andre og angripere kan gjøre det.
Og så, sikkerhetsprinsipper - jeg skal ikke utdype dette poenget, men sørge for at du ikke har alle brukere som kjører i SQL Server som superadministrator. Utviklerne dine vil kanskje ha det, forskjellige brukere vil kanskje ha det - de er frustrerte over å måtte be om tilgang til enkeltelementer - men du må være flittig med det, og selv om det kan være mer komplisert, gi tilgang til objektene og databasene og skjemaene som er gyldige for pågående arbeid, og det er en spesiell sak, kanskje det betyr en spesiell innlogging, det betyr ikke nødvendigvis en forhøyning av rettighetene for den gjennomsnittlige saksbrukeren.
Og så er det hensyn til forskriftsoverholdelse som samsvarer med dette, og noen tilfeller kan faktisk slags gå av på sin egen måte - så det er HIPAA, SOX, PCI - det er alle disse forskjellige hensynene. Og når du gjennomgår en revisjon, forventes det at du viser at du tar tiltak for å forbli i samsvar med dette. Og så, dette er mye å holde oversikt over, jeg vil si som en DBA-oppgaveliste, du prøver å sikre sikkerhetens fysiske krypteringskonfigurasjon, du prøver å sikre at tilgangen til disse dataene blir revidert for overholdelsesformål, og sørg for at de sensitive kolonnene dine, at du vet hva de er, hvor de er, hvilke du bør kryptere og se tilgang til. Og sørge for at konfigurasjoner er i samsvar med forskriftsretningslinjene du er underlagt. Og du må holde dette oppdatert når ting endrer seg.
Så det er mye å gjøre, og hvis jeg skulle la det være der, vil jeg si at du gjør det. Men det er mange forskjellige verktøy for det, og så, hvis jeg kanskje i løpet av de siste minuttene, ville jeg vise deg noen av verktøyene vi har på IDERA for det. Og de to jeg ønsket å snakke om i dag er SQL Secure og SQL Compliance Manager. SQL Secure er vårt verktøy for å identifisere type konfigurasjonssårbarheter. Dine sikkerhetspolicyer, brukerrettighetene dine, konfigurasjonene av overflaten. Og den har maler som hjelper deg å overholde forskjellige regelverk. Det i seg selv, den siste linjen, kan være grunnen til at folk vurderer det. For å lese gjennom disse forskjellige forskriftene og identifisere hva de betyr, PCI og så ta det helt ned til SQL Serveren i butikken min, det er mye arbeid. Det er noe du kan betale mye konsulentpenger for å gjøre; vi har gått og gjort det som konsulent, vi har jobbet med de forskjellige revisjonsselskapene osv. for å finne ut hva disse malene er - noe som sannsynligvis vil bestå en revisjon hvis disse er på plass. Og så kan du bruke malene og se dem i miljøet ditt.
Vi har også et annet, søsterverktøy i form av SQL Compliance Manager, og det er her SQL Secure handler om konfigurasjonsinnstillinger. SQL Compliance Manager handler om å se hva som ble gjort av hvem, når. Så det er revisjon, så det lar deg overvåke aktiviteten mens den oppstår og lar deg oppdage og spore hvem som får tilgang til ting. Var det noen, det prototypiske eksemplet som en kjendis som ble sjekket inn på sykehuset ditt, var det noen som gikk og lette opp informasjonen deres, bare av nysgjerrighet? Hadde de en grunn til det? Du kan se på revisjonshistorikken og se hva som skjedde, hvem som fikk tilgang til disse postene. Og du kan identifisere at dette har verktøy som hjelper deg med å identifisere sensitive kolonner, slik at du ikke nødvendigvis trenger å lese gjennom og gjøre det selv.
Så hvis jeg kan, vil jeg gå foran og vise deg noen av disse verktøyene her i løpet av de siste minuttene - og vær så snill, ikke ansett det som en dyptgående demo. Jeg er en produktansvarlig, ikke en salgsingeniør, så jeg skal vise deg noen av de tingene jeg synes er relevante for denne diskusjonen. Så dette er vårt SQL Secure-produkt. Og som du kan se her, så har jeg et slags rapportkort på høyt nivå. Jeg kjørte dette, tror jeg, i går. Og det viser meg noen av de tingene som ikke er satt opp riktig, og noen av de tingene som er satt opp riktig. Så du kan se at det er ganske mange over 100 forskjellige kontroller som vi har gjort her. Og jeg kan se at min sikkerhetskryptering på sikkerhetskopiene jeg har gjort, ikke har brukt sikkerhetskryptering. SA-kontoen min, eksplisitt kalt “SA-konto”, er ikke deaktivert eller gitt nytt navn. Den offentlige serverrollen har tillatelse, så dette er alle ting jeg kanskje vil se på å endre.
Jeg har fått policyen satt opp her, så hvis jeg ønsket å sette opp en ny policy for å gjelde serverne mine, har vi alle disse innebygde policyene. Så jeg vil bruke en eksisterende policy-mal, og du kan se at jeg har CIS, HIPAA, PCI, SR og skjer, og vi er faktisk i ferd med å legge til ytterligere retningslinjer, basert på hva folk trenger ute i feltet . Og du kan også lage en ny policy, så hvis du vet hva revisoren din leter etter, kan du opprette den selv. Og når du gjør det, kan du velge mellom alle disse forskjellige innstillingene, hva du trenger å ha angitt, i noen tilfeller har du noen - la meg gå tilbake og finne en av de forhåndsbygde. Dette er praktisk, jeg kan velge, si, HIPAA - Jeg har allerede fått HIPAA, min dårlige - PCI, og når jeg klikker rundt her, kan jeg faktisk se den eksterne krysshenvisningen til delen av regulering som dette er relatert til. Så det vil hjelpe deg senere, når du prøver å finne ut hvorfor jeg setter dette inn? Hvorfor prøver jeg å se på dette? Hvilken seksjon er dette relatert til?
Dette har også et fint verktøy ved at det lar deg gå inn og bla gjennom brukerne dine, så en av de vanskelige tingene med å utforske brukerrollene dine, er at jeg faktisk vil ta en titt her. Så hvis jeg viser tillatelser for mitt, la oss se, la oss velge en bruker her. Vis tillatelser. Jeg kan se de tildelte tillatelsene for denne serveren, men så kan jeg klikke her nede og beregne de effektive tillatelsene, og den vil gi meg hele listen basert på, så i dette tilfellet er dette admin, så det er ikke så spennende, men Jeg kunne gå gjennom og plukke de forskjellige brukerne og se hva deres effektive tillatelser er, basert på alle de forskjellige gruppene de kan tilhøre. Hvis du noen gang prøver å gjøre dette på egen hånd, kan det faktisk være litt bryderi, for å finne ut, OK, denne brukeren er medlem av disse gruppene og har derfor tilgang til disse tingene via grupper osv.
Slik at dette produktet fungerer, er det å ta stillbilder, så det er virkelig ikke en veldig vanskelig prosess å ta et øyeblikksbilde av serveren med jevne mellomrom, og så holder det øyeblikksbildene over tid slik at du kan sammenligne for endringer. Så dette er ikke en kontinuerlig overvåking i tradisjonell forstand som et ytelsesovervåkningsverktøy; dette er noe du kanskje har satt opp for å kjøre en gang per natt, en gang per uke - uansett hvor ofte du tror er gyldig - slik at du, når du gjør analysen og gjør litt mer, faktisk bare jobber innenfor verktøyet vårt. Du kobler ikke tilbake til serveren din så mye, så dette er et ganske fint lite verktøy å jobbe med, for å overholde de slags statiske innstillinger.
Det andre verktøyet jeg vil vise deg er vårt Compliance Manager-verktøy. Compliance Manager kommer til å overvåke på en mer kontinuerlig måte. Og det kommer til å se hvem som gjør hva på serveren din, og la deg se på den. Så hva jeg har gjort her, de siste par timene, har jeg faktisk prøvd å skape noen små problemer. Så her har jeg fått vite om det er et problem eller ikke, jeg vet kanskje om det, noen har faktisk opprettet en pålogging og lagt den til en serverrolle. Så hvis jeg går inn og ser på det, kan jeg se - jeg antar at jeg ikke kan høyreklikke der, jeg kan se hva som skjer. Så dette er dashbordet mitt, og jeg kan se at jeg hadde en rekke mislykkede innlogginger litt tidligere i dag. Jeg hadde en haug med sikkerhetsaktivitet, DBL-aktivitet.
Så la meg gå over til revisjonshendelsene mine og se på. Her har jeg fått revisjonshendelsene mine gruppert etter kategori og målobjekt, så hvis jeg tar en titt på den sikkerheten fra tidligere, kan jeg se DemoNewUser, skjedde dette opprette serverpålogging. Og jeg kan se at påloggings-SA opprettet denne DemoNewUser-kontoen, her, klokka 14.42. Og så kan jeg se at på sin side legger du til innlogging på serveren, denne DemoNewUser ble lagt til serveradministratorgruppen, de ble lagt til sette opp admin-gruppen, ble de lagt til sysadmin-gruppen. Så det er noe som jeg ønsker å vite at hadde skjedd. Jeg har også fått den satt opp slik at de sensitive kolonnene i tabellene mine blir sporet, slik at jeg kan se hvem som har fått tilgang til den.
Så her har jeg et par utvalgte som har skjedd på personbordet mitt, fra Adventure Works. Og jeg kan se og se at brukeren SA på tabellen Adventure Works gjorde en valgt topp ti-stjerne fra person dot person. Så kanskje i organisasjonen min vil jeg ikke at folk skal velge stjerner fra personprikkperson, eller jeg forventer at bare visse brukere vil gjøre det, og derfor vil jeg se dette her. Så det du trenger i forhold til revisjonen din, kan vi sette det opp basert på rammeverket, og dette er litt mer et intensivt verktøy. Den bruker SQL Trace eller SQLX hendelser, avhengig av versjon. Og det er noe du må ha noen takhøyde på serveren din for å få plass, men det er en av de tingene, slags forsikring, som er fint hvis vi ikke måtte ha bilforsikring - det ville være en koster at vi ikke trenger å ta - men hvis du har en server der du trenger å følge med på hvem som gjør hva, kan det hende du må ha litt ekstra takhøyde og et verktøy som dette for å gjøre dette. Enten du bruker verktøyet vårt eller rullerer det selv, er du til syvende og sist ansvarlig for å ha denne informasjonen for forskrifter.
Så som sagt, ikke en grundig demo, bare et raskt, lite sammendrag. Jeg ville også vise deg et raskt, lite gratis verktøy i form av dette SQL Column Search, som er noe du kan bruke for å identifisere hvilke kolonner i miljøet som ser ut til å være sensitive opplysninger. Så vi har en rekke søkekonfigurasjoner der den leter etter de forskjellige navnene på kolonner som ofte inneholder sensitive data, og så har jeg fått hele listen over dem som er identifisert. Jeg har 120 av dem, og så eksporterte jeg dem hit, slik at jeg kan bruke dem til å si, la oss se på og sørge for at jeg sporer tilgangen til mellomnavnet, en person som er prikkperson eller moms rate osv.
Jeg vet at vi kommer rett på slutten av vår tid her. Og det er alt jeg faktisk måtte vise deg, så noen spørsmål til meg?
Eric Kavanagh: Jeg har et par gode for deg. La meg bla dette opp her. En av de fremmøtte stilte et virkelig godt spørsmål. En av dem spør om resultatskatten, så jeg vet at den varierer fra løsning til løsning, men har du noen generell ide om hva resultatskatten er for å bruke IDERA sikkerhetsverktøy?
Vicky Harp: Så på SQL Secure er det som sagt veldig lavt på SQL Secure, det vil bare ta noen øyeblikksbilder. Og selv om du har kjørt ganske ofte, får den statisk informasjon om innstillinger, og derfor er den veldig lav, nesten ubetydelig. Når det gjelder Compliance Manager, er det-
Eric Kavanagh: Som en prosent?
Vicky Harp: Hvis jeg måtte gi et prosenttall, ja, ville det være en prosent eller lavere. Det er grunnleggende informasjon om rekkefølgen av å bruke SSMS og gå inn i sikkerhetsfanen og utvide ting. På Compliance-siden er det mye høyere - det er derfor jeg sa at det trenger litt takhøyde - det er liksom det er langt utover det du har når det gjelder ytelsesovervåking. Nå vil jeg ikke skremme folk fra det, trikset med overvåking av overholdelse, og hvis det er revisjon er å sørge for at du bare reviderer det du skal iverksette tiltak. Så når du har filtrert ned for å si: "Hei, jeg vil vite når folk får tilgang til disse tabellene, og jeg vil vite når folk får tilgang til dette, ta disse spesielle handlingene, " vil det være basert på hvor ofte disse tingene er skjer og hvor mye data du genererer. Hvis du sier: "Jeg vil ha den fullstendige SQL-teksten til alle valg som noen gang skjer på noen av disse tabellene, " det vil bare være gigabyte og gigabyte med data som må analyseres av SQL Server lagret, flyttet til vårt produkt, etc.
Hvis du holder det nede til et - vil det også være mer informasjon enn du sannsynligvis kan takle. Hvis du kan ta det ned til et mindre sett, slik at du får et par hundre arrangementer per dag, så er det tydeligvis mye lavere. Så, på noen måter, er himmelen grensen. Hvis du slår på alle innstillinger på all overvåking for alt, ja, det kommer til å bli et resultat på 50 prosent ytelse. Men hvis du skal gjøre det om til et mer moderat, ansett nivå, ville jeg kanskje øyeeplet 10 prosent? Det er virkelig en av de tingene at den kommer til å være veldig avhengig av arbeidsmengden din.
Eric Kavanagh: Ja, ikke sant. Det er et annet spørsmål om maskinvare. Og så er det maskinvareleverandører som kommer inn i spillet og virkelig samarbeider med programvareleverandører, og jeg svarte gjennom spørsmål og svar-vinduet. Jeg kjenner til ett bestemt tilfelle, av Cloudera som jobbet med Intel der Intel gjorde den enorme investeringen i dem, og en del av beregningen var at Cloudera ville få tidlig tilgang til chipdesign, og dermed kunne bake sikkerhet inn i chipnivået til arkitektur, som er ganske imponerende. Men det er ikke desto mindre, det er noe som kommer til å komme der ute, og som fremdeles kan utnyttes av begge sider. Vet du om trender eller tendenser hos maskinvareleverandører til å samarbeide med programvareleverandører om sikkerhetsprotokoll?
Vicky Harp: Ja, faktisk, jeg tror at Microsoft har samarbeidet for å ha noe av, for eksempel, minneplassen for noe av krypteringsarbeidet skjer faktisk på separate brikker på hovedkort som er atskilt fra hovedminnet, slik at noen av de tingene er fysisk atskilt. Og jeg tror at det faktisk var noe som kom fra Microsoft når det gjelder å gå ut til leverandørene for å si: “Kan vi komme på en måte å gjøre dette på, i utgangspunktet er det et lite adresserbart minne, jeg kan ikke gjennom et bufferoverløp komme til dette minnet, fordi det ikke en gang er der, på en måte, så jeg vet at noe av det skjer. ”
Eric Kavanagh: Ja.
Vicky Harp: Det vil tydeligvis være de virkelig store leverandørene.
Eric Kavanagh: Ja. Jeg er nysgjerrig på å se etter det, og kanskje Robin, hvis du har et raskt sekund, vil jeg være nysgjerrig på å kjenne til opplevelsen din gjennom årene, for igjen, når det gjelder maskinvare, når det gjelder den faktiske materialvitenskapen som går i hva du setter sammen fra leverandørsiden, at informasjonen kan gå til begge sider, og teoretisk går vi til begge sider ganske raskt, så er det noen måte å bruke maskinvaren mer nøye, fra et designperspektiv til å styrke sikkerheten? Hva tror du? Robin, er du på stum?
Robin Bloor: Ja, ja. Beklager, jeg er her; Jeg grubler bare på spørsmålet. For å være ærlig har jeg ikke en mening, det er et område som jeg ikke har sett på i betydelig dybde, så jeg er liksom, du vet, jeg kan oppfinne en mening, men jeg vet ikke helt. Jeg foretrekker at ting er trygge i programvare, det er akkurat slik jeg spiller, i utgangspunktet.
Eric Kavanagh: Ja. Vel, folkens, vi har brent gjennom en time og forandret oss her. Stor takk til Vicky Harp for hennes tid og oppmerksomhet - for all din tid og oppmerksomhet; vi setter pris på at du dukker opp for disse tingene. Det er en stor avtale; det kommer ikke til å forsvinne når som helst snart. Det er et katt-og-mus-spill som kommer til å fortsette og gå og gå. Og derfor er vi takknemlige for at noen selskaper er der ute, fokusert på å muliggjøre sikkerhet, men som Vicky til og med hisset på og snakket litt om i presentasjonen sin, på slutten av dagen, er det folk i organisasjoner som trenger å tenke veldig nøye om disse phishing-angrepene, den slags sosialteknikk, og hold på bærbare datamaskiner - ikke la det være på kaffebaren! Endre passordet, gjør det grunnleggende, og du kommer til å få 80 prosent av veien dit.
Så med det folkens, vi kommer til å ta farvel, takk igjen for din tid og oppmerksomhet. Vi henter deg neste gang, ta vare. Ha det.
Vicky Harp: Hei, takk.
