Email Security Hardening – Deo 3: Exchange Server i Exchange Online hardening

Prva dva dela serije pokrila su principe nezavisne od platforme — tehničku autentifikaciju i odbranu od BEC-a. Ovaj deo prelazi na konkretnu, najrasprostranjeniju poslovnu email platformu — Exchange Online (deo Microsoft 365) i, gde se razlikuje, on-premise Exchange Server. Većina organizacija danas koristi Exchange Online, pa je fokus ovog teksta pretežno tamo, sa napomenama gde on-premise okruženje zahteva drugačiji pristup.

Legacy authentication — "zadnja vrata" pored MFA-a

Ovo je koncept vredan detaljnog objašnjenja, jer predstavlja jedan od najčešćih, a najmanje očiglednih propusta u Microsoft 365 okruženjima. Legacy (starija, osnovna) autentifikacija — protokoli poput POP3, IMAP, starijeg SMTP AUTH-a, i Exchange ActiveSync-a sa osnovnom autentifikacijom — ne podržavaju moderne autentifikacione mehanizme, što konkretno znači da ne mogu da sprovedu MFA proveru čak i kad je MFA za taj nalog inače uključena. Napadač koji poseduje ukradenu lozinku (ali ne i drugi faktor) može se, ako legacy protokoli ostanu aktivni, jednostavno povezati kroz njih i potpuno zaobići MFA koja je, na prvi pogled, "uključena za sve".

Microsoft je zvanično ukinuo (deprecated) osnovnu autentifikaciju za Exchange Online u oktobru 2022. godine, ali protokoli i dalje mogu ostati tehnički dostupni kroz zaostale, neregistrovane konfiguracije, starije aplikacije koje se oslanjaju na njih (stariji Outlook klijenti, uređaji za štampanje-na-mejl, računovodstveni softver koji se povezuje preko IMAP-a), ili servisne naloge podešene godinama unazad i nikad revidirane.

Šta treba uraditi

• Proveriti stvarnu upotrebu legacy autentifikacije pre blokiranja — Entra ID sign-in logovi, filtrirani po tipu klijentske aplikacije, pokazuju sve nedavne prijave preko legacy protokola; Exchange Online PowerShell (Get-MailboxStatistics, Get-CasMailboxPlan) pomaže identifikovati mailbox-ove sa i dalje omogućenim legacy pristupom
• Očekivati da će provera otkriti legitimne, iako često zaboravljene slučajeve upotrebe — deljeni mailbox koji povremeno proverava alat za monitoring, uređaj koji šalje sken na email preko SMTP AUTH-a, starija aplikacija integrisana preko IMAP-a — i pripremiti put migracije (OAuth-bazirana alternativa ili konfiguracija SMTP relay-a) za svaki od njih pre blokiranja
• Kreirati Conditional Access politiku koja blokira pristup sa legacy autentifikacionih klijenata, primenjenu prvo u report-only modu kroz period od bar dve nedelje — isti princip audit-pre-enforce koji se provlači kroz svaku operativno osetljivu promenu opisanu kroz celu ovu seriju blogova
• Nakon perioda posmatranja i sanacije otkrivenih legitimnih slučajeva, preći na stvarno blokiranje kroz Conditional Access, ne samo kroz preporuku ili upozorenje

Napomena o riziku: direktno blokiranje legacy autentifikacije bez prethodnog audita najčešće prekida stariju štamparsku/skener opremu koja šalje mejlove preko SMTP AUTH-a, i starije desktop email klijente (Outlook 2013 i raniji) koji se i dalje mogu koristiti negde u organizaciji, a da IT tim toga nije ni svestan. Ovo je operativno osetljiva promena koja zaslužuje isti oprez kao i svaka slična, ranije opisana kroz ovu seriju blogova.

MFA i Conditional Access — obavezno, granularno, sa jasnim izuzecima

Isti princip phishing-otporne, obavezne MFA koji se provlači kroz svaku seriju o kritičnoj infrastrukturi na ovom blogu ima ovde direktnu, merljivu potvrdu — prema sopstvenoj telemetriji Microsoft-a, MFA blokira preko 99 procenata pokušaja kompromitacije naloga. Vredi razjasniti razliku između dva pristupa koje Microsoft 365 nudi: Security Defaults je jednostavan, "sve ili ništa" mehanizam koji uključuje osnovnu MFA zaštitu za ceo tenant bez mogućnosti finog podešavanja, dok Conditional Access nudi granularnu kontrolu — različite politike za različite grupe korisnika, uslove (lokacija, stanje uređaja, procenjen rizik prijave), i akcije.

Šta treba uraditi

• Za produkcione tenante sa stvarnim bezbednosnim zahtevima, koristiti Conditional Access umesto Security Defaults — granularnost omogućava prilagođavanje politike stvarnim potrebama različitih grupa korisnika, umesto univerzalnog, nefleksibilnog pristupa
• Kreirati baznu Conditional Access politiku koja zahteva MFA za sve korisnike, sve cloud aplikacije, sa eksplicitnim izuzimanjem break-glass naloga (opisanih dalje u tekstu) i servisnih naloga koji koriste autentifikaciju zasnovanu na sertifikatima ili managed identity umesto korisničkih kredencijala
• Primeniti svaku novu ili izmenjenu Conditional Access politiku prvo u report-only modu kroz period od bar dve nedelje, po istom principu opisanom za legacy autentifikaciju ranije u tekstu, pre stvarnog sprovođenja
• Koristiti sign-in risk detekciju (dostupnu kroz Entra ID Protection, licencni nivo P2) za dodatno, kontekstualno pooštravanje — zahtevati dodatnu proveru ili blokirati pristup kad sistem proceni prijavu kao rizičnu na osnovu obrazaca ponašanja, ne samo na osnovu ispravnosti lozinke i MFA koda
• Zahtevati phishing-otpornu MFA (FIDO2 ključevi, Windows Hello for Business) za administratorske naloge posebno, gde je izvodivo, iznad standardnog nivoa zahtevanog za obične korisnike

Administratorski pristup — minimalan broj, privremena dodela, break-glass rezerva

Isti princip least privilege i just-in-time pristupa detaljno obrađen kroz AD hardening seriju na ovom blogu ima ovde direktnu, konkretnu primenu kroz Microsoft Entra ID Privileged Identity Management (PIM). Trajno aktivan Global Administrator pristup (ekvivalent Domain Admin-a u lokalnom AD-u) za veći broj naloga predstavlja nepotrebno širok, stalno dostupan cilj za napadača.

Šta treba uraditi

• Svesti broj stalnih Global Administrator naloga na apsolutni minimum — dva do četiri je razuman, često citiran polazni cilj za većinu organizacija, sa preostalim administratorskim potrebama pokrivenim užim, specifičnijim rolama (Exchange Administrator, User Administrator) umesto rutinske dodele punog Global Admin pristupa
• Koristiti dedikovane administratorske naloge, potpuno odvojene od svakodnevnih korisničkih naloga istih osoba — administratorski nalog ne treba da ima pristup email-u niti da se koristi za rutinski rad, isti princip odvojenih kredencijala opisan kroz Backup Infrastructure i Proxmox serije na ovom blogu
• Uključiti Privileged Identity Management kako bi administratorski pristup postao privremen (aktiviran po potrebi, na ograničeno vreme) i auditiran, umesto trajno aktivan — isti princip just-in-time pristupa opisan u AD hardening seriji
• Kreirati bar jedan, dobro dokumentovan break-glass administratorski nalog — cloud-only (ne zavisan od lokalne AD federacije koja može otkazati), eksplicitno izuzet iz Conditional Access politika, i pod strogim, kontinuiranim nadzorom svake upotrebe — isti princip opisan za break-glass naloge kroz VMware i Proxmox hardening serije na ovom blogu

Defender for Office 365 — anti-phishing na nivou same platforme

Microsoft Defender for Office 365 pruža ugrađenu zaštitu (dostupnu kroz Plan 1 ili napredniji Plan 2, u zavisnosti od licence) koja direktno dopunjuje principe iz drugog dela serije o BEC-u i lookalike domenima — sada primenjene kroz konkretna, konfigurabilna podešavanja platforme.

Šta treba uraditi

• Konfigurisati politike zaštite od impersonacije korisnika i domena — ove politike specifično prepoznaju pokušaje oponašanja izvršnog osoblja ili poznatih, poverljivih domena, direktno adresirajući BEC scenario opisan u drugom delu serije
• Uključiti Safe Links (koji proverava i po potrebi blokira zlonamerne linkove u trenutku klika, ne samo u trenutku prijema mejla) i Safe Attachments (koji izvršava priloge u izolovanom sandbox okruženju pre isporuke) gde licenca to dozvoljava
• Podesiti pragove za spam/phishing detekciju iznad podrazumevanih vrednosti gde je to opravdano stvarnim obrascem pretnji organizacije, umesto oslanjanja isključivo na generičke, podrazumevane vrednosti
• Koristiti unapred pripremljene Standard ili Strict Protection profile kao polaznu tačku i referencu, umesto građenja politike potpuno od nule — ovi profili predstavljaju Microsoft-ovu kurirranu, redovno ažuriranu preporuku, dobru osnovu za dalje prilagođavanje

Blokiranje eksternog auto-forwarding-a — direktna odbrana od BEC persistencije

Ovo je mera direktno povezana sa tehnikom opisanom u drugom delu serije — napadač koji kompromituje mailbox često kreira pravilo za automatsko prosleđivanje kopije svake ulazne poruke na spoljnu adresu, obezbeđujući tako trajan uvid u komunikaciju čak i nakon što žrtva promeni lozinku (jer pravilo ostaje aktivno sve dok ga neko eksplicitno ne ukloni). Podrazumevano, Exchange Online dozvoljava korisnicima da sami kreiraju ovakva pravila, što ovu tehniku čini iznenađujuće lakom za sprovođenje nakon uspešne kompromitacije.

Šta treba uraditi

• Onemogućiti automatsko prosleđivanje ka eksternim (van organizacije) adresama na nivou cele organizacije, osim za eksplicitno, pojedinačno odobrene, dokumentovane slučajeve
• Redovno pregledati postojeća pravila prosleđivanja i transport pravila na svim mailbox-ovima, sa posebnim fokusom na naloge visokog rizika (izvršno osoblje, finansijski tim) — isti princip periodične revizije koji se provlači kroz svaku seriju na ovom blogu
• Konfigurisati alert politiku koja obaveštava bezbednosni tim odmah po kreiranju novog pravila za prosleđivanje — rano obaveštenje omogućava brzu reakciju pre nego što napadač stigne da iskoristi taj pristup, po istom principu brzine reagovanja naglašenom u drugom delu serije
• Zabraniti i transport pravila koja masovno prosleđuju poštu ka eksternim domenima ili koja zaobilaze standardnu anti-spam/anti-phishing proveru — oba predstavljaju čest, dodatan put za curenje podataka ili zaobilaženje zaštite

Audit logovanje — preduslov za istragu bilo kog BEC incidenta

Isti princip centralizovanog, sveobuhvatnog logovanja koji se provlači kroz svaku seriju na ovom blogu ima ovde direktnu, praktičnu posledicu: bez uključenog mailbox audit logovanja, istraga BEC incidenta (ko je i kada kreirao sumnjivo pravilo za prosleđivanje, sa koje IP adrese se napadač prijavljivao, koje mejlove je pročitao) postaje znatno teža ili potpuno nemoguća.

Šta treba uraditi

• Potvrditi da je Unified Audit Logging uključen kroz Microsoft Purview compliance portal — podrazumevano uključeno za nove tenante od 2019. godine, ali vredi eksplicitno proveriti, posebno na starijim, migriranim tenantima
• Potvrditi da je Mailbox Auditing uključeno za sve mailbox-ove pojedinačno, ne samo na nivou tenanta — podrazumevano uključeno od 2019. godine, ali može biti pojedinačno isključeno za specifične naloge kroz stariju konfiguraciju ili grešku, pa zaslužuje eksplicitnu proveru, ne pretpostavku
• Postaviti retenciju audit logova u skladu sa stvarnim potrebama istrage i regulatornim zahtevima — podrazumevana retencija možda nije dovoljna za istragu incidenta otkrivenog nekoliko meseci nakon što se stvarno desio
• Konfigurisati alert politike za bezbednosno relevantne događaje — masovno brisanje mejlova, neuobičajena prijava, eskalacija privilegija — kako bi ovi događaji generisali aktivno obaveštenje, ne samo pasivan zapis koji čeka da neko ručno pretraži log nakon što sumnja već postoji

Ovim se zaokružuje pregled Exchange Online hardeninga. Poslednji deo serije prelazi na Google Workspace kao cloud alternativu, pokazujući kako se principi opisani kroz celu ovu seriju blogova (autentifikacija, anti-phishing, administrativni pristup, audit) primenjuju kroz Google-ovu, drugačije strukturiranu platformu i terminologiju.