Presentation from one of the remarkable IT Security events in the Baltic States organized by “Data Security Solutions” (www.dss.lv ) Event took place in Riga, on 7th of November, 2013 and was visited by more than 400 participants at event place and more than 300 via online live streaming.
Atrodiet un identificējiet savu DB (prod & test env kopijas + pieredze rāda, ka arī produkcijas dati nonāk IS izstrādātājiem uz personālajiem datoriem !)
Vai esam droši par to kurā no datu bāzēm tiek glabāti sensitīvi dati (jebkuri kompānijas noteikti) - piemēram p.k., adrese, norēķinu informācija? Dalos pieredzē par Valsts nozīmes IS DB (MSSQL un Oracle)? Vai ir IS pārzinis? Kā ar izmaiņām – vai tās tiek dokumentētas. Šis ir gadījums kur Guardium var (jums to nezinot) maskēt informāciju vai pilnībā bloķēt pieeju tiem, ja šīs darbīas netiek veiktas uzreiz.
Pēc iepriekš definētiem nosacījumiem sistēma atpazīst Jūsu noteiktos sensitīvos datus – šajā gadījumā CreditCard Num.
DB konfigurācijas drošības pārbaude pirms to nodod lietošanā – vai DB administrators var visu atcerēties? Pilnībā uzticamies saviem DB administratoriem – būtu labi palīdzēt administratoriem ar DB drošības pārbaudi un norādīt tās lietas, ko pēc būtībās ne vienmēr var atcerēties, jo vairāk, ja nav izstrādātas konfigurācijas paraugi un liste ar jautājumiem, kam jāiziet cauri.
Sistēma nodrošina plašu klāstu ar DB konfigurācijas sagatavēm un pārbaudēm.
UpToDate DB ievainojamības pārbaude – regulāri atjauninājumi no IBM. Plāšs klāsts ar predefinētām pārbaudēm – cieši sadarbojas ar CAS.
Ievainojamības pārbaude – jaunākā informācija regulāri tiek saņemta no IBM par konkrēto DB un to versiju ievainojamībām – līdz ar to nodrošinot iespēju veikt regulāru iestatītu skanēšanu.
Ne tikai kopsavilkums, bet arī konkrēti ieteikumi, kas jāizdara sistēmas administratoram.
Datu maskēšana atbilstoši pieejas tiesībām un lietotāju grupām – integrācija ar LDAP.
DB administrātoram parasti ir superadmin tiesības, kas nozīmē, ka tas var redzēt arī sensitīvu informāciju.
Control also non-TCP local connections
Dažādi maskēšanas paņēmieni – konfigurējama jebkādai informācijai, ar jebkādiem aizstājējsimboliem, kā arī RANDOM pieeja, lai izvadītie rezultāti būtu tuvu realitātei (formātam) bet ne produkcijas datiem.
Kas notiek ar DB konfigurācijas izmaiņu pārvaldību – vai varam redzēt izmaiņu vēsturi un vietu, kur, kas, kāpēc tika mainīts? (faili un to sagataves, OS and SQL scripts, registry and env variables). Vai izmaiņas ir veiktas saskaņā ar ServiceDesk pieteikuma ID NR ? (Guardium nodrošina – redzēt konkrētas izmainītās vērtības, script output, failu nosaukumam, pieejas tiesību maiņa (owner,group), Failu CheckSum – pieejami templates).
Log faili tiek glabāti nemainīgi Guardium no 3-6 mēnešiem pēc nepieciešamības to eksportējot arī uz arhīvu.
Pētot esošo auditācijas ierakstu aktivitātes – arī vēsturiski spēj sūtīt reālā laikā brīdinājumus, kā arī pieņemt predefinētus mērus.
Mēs varam būt laimīgi, ja mums ir drošības pārvaldnieks ar nepieciešamo tehnisko nodrošinājumu ar kuru palīdzību rūpējas par šiem jautājumiem un arī, ja tas tiek darīts, vai viņš spētu pietiekami ātri identificēt aizdomīgas situācijas pirms cietusi organizācijas reputācija (data leakage/ news or TV). Guardium nav atkarīgs no lokālajiem servera log failiem, bet gan tos caurskata pie sevis. Nodrošinot nepieciešamo to uzglabāšanas ilgumu un nosūtīšanu uz citu repositoriju.
Let’s talk about our solution!
Heterogeneous support for Databases and Applications
S-TAP Agents
lightweight cross platform support
NO changes to Databases or Applications
Also monitor direct access to databases by privileged users (such as SSH console access), which can’t be detected by solutions that only monitor at the switch level.
Collectors handle the heavy lifting (continuous analysis, reporting and storage of audit data)
reduces the impact on the database server
Our solution does not rely on log or native audit data
DBAs can (sometimes have to!) turn this off
Logging greatly impacts performance on the Database Server as you increase granularity!
Real-time alerting – not after the fact
Monitor ALL Access
Piemēram, vai DB atbilst PCI-DSS (payment card industry data security standard) standartam.
Bieži aplikācijas kā Oracle EBS, PeopleSoft, SAP izmanto unikālu DB pieslēgšanās Lietotāja ID, tāpēc nav nosakāms, kurš lietotājs ir veicis konkrēto darbību. (Guardium seko līdzi sesijai starp App un DB)
Scalable Multi-Tier Architecture – no vienkāršas ar vienu Collector līdz vairākiem Aggrigator un centrālo collectoru vadības pārvaldību.
Let’s talk about our solution!
Heterogeneous support for Databases and Applications
STAP Agents
lightweight cross platform support
NO changes to the Database or Applications
Collectors handle the heavy lifting
reduces the impact on the database server
No logging requirements
DBAs can (sometimes have to!) turn this off
Logging greatly impacts the Database Server as you increase granularity!
Real-time alerting
Monitor ALL Access
A Privileged User working on the server console won’t be detected by any solution that only monitors network traffic!