Een kwaadwillende gebruiker kan kwetsbaarheden vinden die de MySQL-database van een organisatie misbruiken. Het monitoren van database-activiteit zou dus een kernpraktijk van elk bedrijf moeten zijn. Hackers ontketenen aanvallen die zijn ontworpen om vertrouwelijke gegevens te stelen, en hun primaire doelwit zijn de MySQL-databaseservers van een organisatie. Databases staan bekend als een van de meest gecompromitteerde activa.
Waarom wordt de database zo vaak getarget? Eenvoudig: de database is het hart van elke organisatie die klantrecords en andere vertrouwelijke bedrijfsgegevens opslaat. Organisaties geven de minste prioriteit als het gaat om het beschermen van deze cruciale activa.
Zodra hackers en kwaadwillende insiders toegang krijgen tot gevoelige gegevens, is hun volgende stap om snel waarde te extraheren, schade op te leggen of de bedrijfsactiviteiten te beïnvloeden. Behalve financieel verlies of reputatieschade, leiden inbreuken ook tot overtredingen van de regelgeving, boetes en juridische kosten, enz.
Laten we eens kijken naar de onderstaande casestudy, waarin een klant miljoenen dollars heeft verloren door kwaadwillende activiteiten in hun database:
Casestudies
Bedrijfsnaam: Capital One
Link: https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
probleem:
Capital One bank lijdt een van de grootste verliezen van 150 miljoen als gevolg van een kwetsbaarheidsaanval.
Gevolg:
Een software-engineer en een voormalige medewerker van de Capital One-bank hebben de server van het bedrijf gehackt, waarbij ze klantgegevens vasthouden en persoonlijke gegevens van meer dan 100 miljoen mensen hebben gepocheerd. Amazon Web Services host de klantendatabase en overigens was de engineer eerder ook werkzaam bij Amazon.
Volgens de rechtbank en Capital One heeft de hacker 140,000 burgerservicenummers en 80,000 bankrekeningnummers gestolen. Naast de tientallen miljoenen creditcardaanvragen werden ook inbreuk gemaakt. De diefstal bracht een miljoen Canadese burgerservicenummers in gevaar, die gelijk zijn aan de burgerservicenummers voor de Amerikanen. Het bereik van gestolen gegevens was al in het jaar 2005 en de laatste in het jaar 2019.
De bank verstrekte de verklaring dat zij verwachtte dat de inbreuk haar tot $ 150 miljoen zou kosten, inclusief het betalen voor kredietbewaking voor getroffen klanten. De inbreuk was mogelijk omdat er een kwetsbaarheid open was in hun firewall en de hacker gemakkelijk toegang had tot de gehoste database in AWS.
Als voormalig werknemer bij AWS werd de kwetsbaarheid goed uitgebuit om de database te hacken en de klantgegevens te manipuleren. Mogelijke knowhow over hoe de kwetsbaarheid is gebruikt.
Zoals we weten, worden databases gebruikt om alle klant- en transactiegegevens op te slaan. De hacker heeft de database gemanipuleerd door het toevoegen / verwijderen of zelfs extraheren van gegevens uit de bankdatabase.
Als ze de juiste beveiliging hadden om deze database te bewaken, wat kan worden gedaan met Zmanda ZRM-product, had een dergelijke bedreiging kunnen worden gedetecteerd en proactief kunnen worden gestopt. De bank heeft de kwetsbaarheid verholpen en beschikt nu over strengere methoden om dergelijke fraude te bestrijden.
Schadelijk detecteren MySQL-database-activiteit met behulp van Zmanda
De organisaties dienen een meerlaagse strategie voor de beveiliging van databanken te hanteren. Met de toepassing van best practices kan het risico op gegevensblootstelling op een verstandige manier worden verminderd verschillende aanvallen vectoren. Zmanda kan bijvoorbeeld kwaadaardige activiteiten detecteren vanuit databaseback-ups
ZRM voor MySQL slaat binaire MySQL-logboeken op als onderdeel van de databaseback-ups. De binaire logboeken bieden een goed controlespoor van alle databaseactiviteit. ZRM for MySQL binary maakt gebruik van log-parsing-mogelijkheid voor een bepaald tijdstip in de tijdherstel, waarbij kwaadaardige database-activiteit wordt gedetecteerd met behulp van SQL-inspectie.
Met de ZRM voor MySQL-plug-in-interface kunnen DBA's (Database Administrator) log-parser-plug-inscripts schrijven om specifieke / alle database-activiteit bij te houden en te bewaken. De volgende code kan bijvoorbeeld het verwijderen van gegevens uit de PRODUCTS-tabel in de database detecteren. Dit script drukt alle exemplaren van verwijderde regelitems uit de PRODUCTS-tabel af.
@fields = split (/ \ | /, $ ARGV [0]);
mijn $ SQL_VERB = ”VERWIJDEREN”;
mijn $ TABLE_NAME = ”PRODUCTS”;
if (($ velden [3] == "Zoekopdracht") && \
($ velden [4] = ~ / $ SQL_VERB * FROM. * `$ TABLE_NAME` /)) {
print "$ velden [2] $ velden [4] \ n";
}
De opdracht mysql-zrm voert het aangepaste plug-in-script uit voor alle back-ups of een specifiek back-upimage. De volgende opdracht zoekt naar verwijdering uit de PRODUCTS-tabel op een back-upimage van 9 december 2019.
# mysql-zrm –actie parse-binlogs \
–Brondirectory / var / lib / mysql-zrm / pricebook / 20061205142103 \
–Parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl
De uitvoer van de opdracht bevat zowel geldige verwijderingen als kwaadwillende verwijderingen van databases.
Op dezelfde manier kunnen klanten hun eigen script opzetten en het laten uitvoeren en verifiëren voor en na de back-up, afhankelijk van de behoefte en is een opvallende functie voor ZRM voor MySQL.
De onderstaande schermafbeelding verwijst naar de pagina Back-up | Hoe in ZRM, waar u de naam, het pad en de uitvoering van de plug-in kunt configureren.
De parameter Pre en Post backup-plug-in moet de naam en het volledige pad naar de plug-in bevatten. De aanbevolen locatie voor plug-ins in de directory "/ usr / share / mysql-is database / plugins".
Inpakken!
Ondanks het hoge bewustzijn van verschillende kwetsbaarheidsdreigingen, is het aantal incidenten de afgelopen jaren toegenomen. Als gevolg van de kosten die door de slachtoffers van deze incidenten worden gemaakt, zijn de bedrijfskosten tot een zeer aanzienlijk niveau gestegen vanwege de toename van datalekken. Om de impact van deze gebeurtenissen te verminderen, moet een organisatie de juiste procedures toepassen om de totale kosten als gevolg van datalekken te minimaliseren en niet over een efficiënte monitoring- en detectietool beschikken.
Bekijk ook zeker de Punten om op te nemen in uw noodherstelplan
