File Server Hardening – Deo 5: DLP osnove i otpornost na ransomware

Prethodna četiri dela serije pokrila su specifičnosti Windows i Linux fajl servera — dozvole, protokole, audit. Ovaj, poslednji deo serije bavi se temama koje važe nezavisno od toga koji je operativni sistem u pitanju: osnovnim principima zaštite od gubitka podataka (data loss prevention, DLP), i praktičnim, dodatnim merama specifično usmerenim na ranu detekciju i otpornost prema ransomware napadima na nivou samog fajl servera. Fokus ovog dela je namerno na pristupačnim, uglavnom besplatnim merama koje ne zahtevaju skup, specijalizovan alat — pristup koji odgovara realnosti manjeg IT tima sa ograničenim budžetom, ne enterprise DLP platformama sa licencama koje koštaju više nego sam fajl server.

DLP kao princip, ne kao proizvod

Vredi razjasniti ovo unapred, jer termin DLP često asocira na skupe, komercijalne platforme sa mašinskim učenjem, centralizovanim konzolama i licencama po korisniku. Suština DLP-a, međutim, nije u konkretnom alatu — to je princip: znati gde se osetljivi podaci nalaze, i imati kontrolu nad tim kako se ti podaci kreću i ko im pristupa. Veliki deo ovog principa se, na fajl serveru, već ostvaruje kroz mere opisane u prethodna četiri dela ove serije — dobro postavljene dozvole, audit pristupa, mrežna segmentacija. DLP dodaje jedan sloj koji ta prethodna četiri dela ne pokrivaju direktno: svesnost o tome šta se tačno nalazi u pojedinim folderima, i kontrolu nad tim šta se sa tim podacima dešava kad izlaze sa fajl servera.

Klasifikacija podataka — osnova bez koje ostatak nema smisla

Nemoguće je efikasno štititi "sve podjednako" — folder sa internim, javno objavljivim materijalima ne zaslužuje isti nivo pažnje kao folder sa ličnim podacima zaposlenih ili finansijskim izveštajima. Klasifikacija podataka, čak i u najjednostavnijem obliku, je preduslov za sve što sledi: bez znanja gde se šta nalazi, nemoguće je doneti informisanu odluku o tome koji folder zaslužuje strože dozvole, detaljniji audit, ili posebnu backup politiku.

Šta treba uraditi

  • Uvesti jednostavnu, praktičnu shemu klasifikacije (npr. tri nivoa — javno, interno, osetljivo/poverljivo) umesto pokušaja da se odmah gradi kompleksan, potpun sistem klasifikacije koji niko dosledno neće primenjivati
  • Označiti postojeću strukturu foldera prema toj shemi kroz jednostavan, dokumentovan popis (koji folder, koji nivo, ko je vlasnik/odgovoran) — ovo ne mora biti automatizovano niti tehnički sofisticirano da bi bilo korisno; jednostavna tabela koja se održava tačnom vredi više od skupog alata koji niko ne konfiguriše ispravno
  • Uskladiti nivo dozvola, audit obima i backup učestalosti sa tom klasifikacijom — osetljivi folderi zaslužuju stroži pristup (opisan kroz prva četiri dela serije), detaljniji audit, i češći, posebno čuvan backup, dok interni ili javni sadržaj ne zahteva isti nivo napora
  • Kad se kreira nov folder ili share, tretirati klasifikaciju kao deo standardnog procesa kreiranja, ne kao naknadnu misao koja se nikad ne sprovede — ovo sprečava akumulaciju neklasifikovanih, "sivih" delova strukture koji se vremenom nagomilaju bez ičije svesne odluke

Kontrola kretanja podataka — gde podaci mogu, a gde ne mogu da odu

Dobro postavljene dozvole na fajl serveru kontrolišu ko sme da čita ili menja podatke dok su tamo, ali ne kontrolišu šta se dešava kad korisnik legitimno pristupi podacima i zatim ih prenese negde drugde — na USB uređaj, u lični cloud nalog, ili prosto pošalje mejlom van organizacije. Ovo je oblast gde puna, komercijalna DLP rešenja daju najviše vrednosti, ali i oblast gde postoje jednostavne, besplatne mere koje pokrivaju veći deo praktičnog rizika bez potrebe za takvim ulaganjem.

Šta treba uraditi

  • Koristiti ugrađene mehanizme operativnog sistema za ograničavanje prenosivih uređaja (Group Policy za USB skladišta na Windows-u, odgovarajuća pravila za blokiranje montiranja spoljnih uređaja na Linux-u) na radnim stanicama koje pristupaju osetljivim folderima — ovo je besplatna, ugrađena mera koja pokriva čest, jednostavan put gubitka podataka
  • Ograničiti ili pratiti pristup ličnim cloud servisima (lični Google Drive, Dropbox i slično) sa mreže organizacije kroz firewall/proxy pravila opisana u ranijim serijama, posebno za radne stanice sa pristupom osetljivim folderima
  • Za organizacije koje već koriste Microsoft 365 ili sličnu platformu, istražiti ugrađene, često već plaćene kroz postojeću licencu DLP mogućnosti (npr. Microsoft Purview) pre kupovine odvojenog, specijalizovanog alata — mnoge organizacije plaćaju za funkcionalnost koju već poseduju, a nikad je ne uključe
  • Fokusirati napor na najosetljivije, najviše klasifikovane foldere prvo, umesto pokušaja da se odmah pokrije cela infrastruktura — isti princip postepenog uvođenja koji se provlači kroz svaku prethodnu seriju na ovom blogu

Canary/honeypot fajlovi — besplatna, iznenađujuće efikasna mera rane detekcije

Ovo je konkretna, praktična tehnika koja zaslužuje detaljnije objašnjenje jer je i besplatna i lako sprovodiva, a daje realnu vrednost. Ideja je jednostavna: postaviti mali broj naizgled legitimnih, ali u stvarnosti veštačkih fajlova (canary ili honeypot fajlova) na osetljivim ili strateški postavljenim lokacijama — na primer, fajl nazvan tako da alfabetski bude prvi u folderu (ransomware alati često enkriptuju fajlove redom kojim ih pronalaze na disku, pa je fajl koji je prvi po abecedi statistički često i prvi pogođen), ili fajl privlačnog naziva poput "lozinke.docx" u folderu gde legitimni korisnici nemaju razloga da ga otvore.

Prednost ovog pristupa je da alarm koji canary fajl generiše nosi veoma visoku pouzdanost — legitimni korisnik nema razlog da otvori, izmeni ili obriše fajl koji ne postoji u njegovom svakodnevnom radnom obrascu, dok ransomware koji sistematski prolazi kroz sve fajlove u folderu neizbežno dodirne i canary fajl usput. Za razliku od mnogih drugih bezbednosnih alarma koji zahtevaju analizu i procenu, "neko je dirnuo fajl koji niko nikad ne dira" je gotovo uvek jednoznačan signal da se nešto neuobičajeno dešava.

Šta treba uraditi

  • Postaviti nekoliko canary fajlova (npr. Word ili Excel dokumenti sa uverljivim, ali izmišljenim sadržajem) u ključne, osetljive foldere — po jedan ili dva po folderu je dovoljno, nema potrebe za velikim brojem
  • Uključiti audit praćenje (opisano u drugom delu serije za Windows i trećem/četvrtom delu za Linux) specifično na te canary fajlove, sa alarmom koji odmah, u realnom vremenu, obaveštava administratora o bilo kakvom pristupu, izmeni ili brisanju
  • Za jednostavnu, besplatnu implementaciju bez potrebe za pisanjem sopstvenog sistema za alarme, razmotriti javno dostupne servise poput Canarytokens.org, koji generišu fajl sa ugrađenim mehanizmom koji šalje email obaveštenje čim se fajl otvori ili izmeni, bez potrebe za dodatnom infrastrukturom na samom fajl serveru
  • Postaviti canary fajlove pažljivo, van uobičajenih, legitimnih obrazaca korišćenja, kako bi se izbegli lažni alarmi izazvani rutinskim radom (npr. IT tim koji pravi popis svih fajlova u folderu bi trebalo da zna da izostavi canary fajlove iz takve operacije)
  • Povezati alarm sa canary fajla sa konkretnim, unapred definisanim planom odgovora — ako je canary fajl dirnut, sledeći korak treba da bude jasan (npr. hitna provera obrasca aktivnosti tog naloga, potencijalno privremeno onemogućavanje tog naloga do potvrde), ne samo pasivna beleška u logu koju niko odmah ne pregleda

Otpornost fajl servera specifično na ransomware — sabiranje svega iz serije

Vredi na kraju eksplicitno povezati mere iz cele ove serije u kontekst ransomware otpornosti, jer nijedna pojedinačna mera nije dovoljna sama po sebi — kombinacija je ono što stvarno menja ishod napada.

Šta treba uraditi

  • Least privilege dozvole (prvi i treći deo serije) ograničavaju koliko fajlova jedan kompromitovan nalog uopšte može da dosegne i enkriptuje — kompromitovan nalog sa pristupom samo sopstvenom folderu nanosi neuporedivo manju štetu od naloga sa širokim pristupom celoj strukturi
  • FSRM file screening (drugi deo) i canary fajlovi (ovaj deo) daju ranu detekciju dok je napad još u toku, umesto otkrivanja tek nakon što je šteta već potpuna
  • Shadow Copies (drugi deo) omogućavaju brz oporavak manjeg obima, uz jasno razumevanje da napredniji napadi te kopije eksplicitno brišu, pa se na njih ne sme računati kao na jedinu liniju odbrane
  • Odvojen, enkriptovan backup van dometa istog kompromitovanog pristupa (princip ponovljen kroz MSSQL, Hyper-V, i implicitno kroz ovu seriju) ostaje poslednja, najpouzdanija linija stvarnog oporavka kad sve ostalo zakaže
  • Mrežna segmentacija i protokol hardening (prvi, treći i četvrti deo) usporavaju i ograničavaju lateralno kretanje ransomware-a između različitih share-ova i servera, umesto da mu dozvole slobodno kretanje kroz celu infrastrukturu odjednom

Ovim se zaokružuje serija o hardeningu fajl servera — Windows i Linux strana, protokoli, dozvole, audit, i zaključno, principi koji povezuju sve to u praktičnu otpornost na najčešći, najskuplji scenario kojem je fajl server danas izložen. Isti obrazac koji se provlači kroz svaku seriju na ovom blogu ponovljen je i ovde: nijedna pojedinačna mera nije nepробojna, ali njihova promišljena kombinacija čini razliku između incidenta koji se brzo otkrije i ograniči, i onog koji ostane neprimećen dok šteta ne postane nepovratna.

Comments

Popular posts from this blog

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)