En skadlig användare kan hitta sårbarheter som kommer att utnyttja en organisations MySQL-databas. Således bör övervakning av databasaktivitet vara en kärnpraxis för varje företag. Hackare släpper ut attacker som är utformade för att stjäla konfidentiell data, och deras primära mål är en organisations MySQL-databasservrar. Databaser är kända för att vara en av de mest komprometterade tillgångarna.
Varför riktas databasen så ofta? Enkelt — databas är hjärtat i alla organisationer som lagrar kundregister och annan konfidentiell affärsdata. Organisationer prioriterar minst när det gäller att skydda dessa viktiga tillgångar.
När hackare och skadliga insiders får tillgång till känslig data är deras nästa steg att snabbt extrahera värde, införa skada eller påverka affärsverksamheten. Bortsett från ekonomisk förlust eller skada på rykte, leder överträdelser också till regelöverträdelser, böter och juridiska avgifter etc.
Låt oss ta en titt på fallstudien nedan, där en kund förlorade miljontals dollar på grund av skadlig aktivitet i sin databas:
Fallstudie
Företagsnamn: Capital One
Länk: https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
Problem:
Capital One-banken drabbas av en av de mest betydande förlusterna på 150 miljoner på grund av en sårbarhetsattack.
Följd:
En programvarutekniker och en tidigare anställd från Capital One-banken hackade in på företagsservern, med kunddata och pocherade personuppgifter om över 100 miljoner människor. Amazon Web Services är värd för kunddatabasen, och för övrigt var ingenjören också tidigare anställd hos Amazon.
Enligt domstolen och Capital One stal hackaren 140,000 80,000 personnummer och 2005 2019 bankkontonummer. Förutom de tiotals miljoner kreditkortsansökningarna bröts också. Stölden komprometterade en miljon kanadensiska socialförsäkringsnummer, vilket motsvarar amerikanska socialförsäkringsnummer. Det data som stulits var redan XNUMX och det senaste året XNUMX.
Banken lämnade uttalandet att den förväntade sig att överträdelsen skulle kosta det upp till 150 miljoner dollar, inklusive att betala för kreditövervakning för berörda kunder. Överträdelsen var möjlig eftersom det var sårbarhet öppen i deras brandvägg och hackaren lätt kunde komma åt den värdbaserade databasen i AWS.
Att vara en tidigare anställd på AWS utnyttjades sårbarheten väl för att hacka in i databasen och manipulera kunddata. Möjlig kunskap om hur sårbarheten kan ha använts.
Som vi känner till används databaser för att lagra all kund- och transaktionsinformation. Hackaren manipulerade DB antingen genom att lägga till / ta bort eller till och med extrahera data från bankdatabasen.
Om de hade rätt säkerhet för att övervaka denna databas, vilket kan göras med Zmanda ZRM-produkt, ett sådant hot kunde ha upptäckts och stoppat proaktivt från att hända. Banken har fixat sårbarheten och har nu strängare metoder för att kontrollera sådana bedrägerier.
Upptäcker skadlig MySQL-databasaktivitet med Zmanda
Organisationerna bör anta en strategi för säkerhetsförsvar i flera lager. Med antagandet av bästa praxis kan på ett förnuftigt sätt minska risken för exponering av data orsakad av olika attacker vektorer. Till exempel kan Zmanda upptäcka skadliga aktiviteter från säkerhetskopior av databaser
ZRM för MySQL lagrar binära MySQL-loggar som en del av säkerhetskopior av databasen. De binära loggarna ger ett korrekt granskningsspår av all databasaktivitet. ZRM för MySQL-binär använder logg-analyseringsfunktion för en viss tidpunkt för återställning och upptäcker skadlig databasaktivitet med hjälp av SQL-inspektion.
ZRM för MySQL-plugin-gränssnittet tillåter DBA: er (databasadministratör) att skriva loggparser-plugin-skript för att spåra och övervaka specifik / all databasaktivitet. Följande kod kan till exempel upptäcka borttagning av data från tabellen PRODUKTER i databasen. Detta skript skriver ut alla instanser av raderade rader från tabellen PRODUKTER.
@fields = split (/ \ | /, $ ARGV [0]);
min $ SQL_VERB = ”RADERA”;
min $ TABLE_NAME = ”PRODUKTER”;
om (($ fält [3] == “Fråga”) && \
($ fält [4] = ~ / $ SQL_VERB * FRÅN. * `$ TABLE_NAME` /)) {
skriva ut "$ fält [2] $ fält [4] \ n";
}
Kommandot mysql-zrm kör det anpassade plugin-skriptet för alla säkerhetskopior eller en specifik säkerhetskopia. Följande kommando letar efter borttagning från PRODUCTS-tabellen i en säkerhetskopia av 9 december 2019.
# mysql-zrm – parse-binlogs för handling \
–Källkatalog / var / lib / mysql-zrm / prisbok / 20061205142103 \
–Parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl
Utdata från kommandot kommer att innehålla giltiga borttagningar såväl som skadliga databasraderingar.
På samma sätt kan kunder skapa sitt eget skript och få det att köras och verifieras före och efter säkerhetskopieringen enligt behov och är en utmärkande funktion för ZRM för MySQL.
Nedanstående skärmdump hänvisar till Backup | How-sidan i ZRM, där du kan konfigurera plugin-namnet, sökvägen och körningen.
Parametern Backup and Plug-in före och efter post ska innehålla namnet och hela sökvägen till plugin-programmet. Den rekommenderade platsen för plugins i katalogen “/ usr / share / mysql-is database / plugins”.
Sammanfatta!
Trots den höga medvetenheten om olika sårbarhetshot har antalet incidenter ökat de senaste åren. Som ett resultat av de kostnader som drabbats av offren för dessa incidenter har driftskostnaderna ökat till en mycket betydande nivå på grund av ökade dataintrång. För att minska effekterna av dessa händelser måste en organisation vidta lämpliga procedurer för att minimera de totala kostnaderna på grund av dataintrång och inte ha ett effektivt övervaknings- och detekteringsverktyg.
Se också till att kolla in Poäng att inkludera i din katastrofåterställningsplan
