Defender External Attack Surface Management – a külső nézet

Amikor az IT-securityben gondolkodunk, nem szabad elfelejteni a külső támadási felületet (external attack surface), ahonnan a szervezet támadható. A támadási felületbe tartozhat egy internetre publikált weboldal, egy nem támogatott és esetleg sérülékenységet tartalmazó PHP-kód.

A külső támadási felület felmérését általában erre szakosodott cégekkel szokták megvizsgáltatni a vállalatok. Ez egyrész drága is lehet, illetve sokszor csak egy pillanatképet kapunk az aktuális problémákról.

Defender EASM

Az EASM folyamatosan felfedezi és feltérképezi digitális támadási felületet, hogy külső nézőpontot adjon az online infrastruktúráról. Ez a vizibilitás segithet az IT szakembereknek hogy azonositsák és elháritsák a kockázatokat.

A Defender EASM a Microsoft-infrastruktúra feltérképezési technológiai részét használja az online infrastruktúrához kapcsolódó eszközök felfedezésére, a technológia aktívan szkennel, hogy további betekintést nyerjen és felderítse a gyenge pontokat.

Az alábbi erőforrásokat képes felhasználni a felderitéshez:

  • Domains
  • Hostnames
  • Web Pages
  • IP Blocks
  • IP Addresses
  • ASNs
  • SSL Certificates
  • WHOIS Contacts

Licenszelés: az első 30 napig ingyenes, utána 0,011 USD/asset/nap. Assesnek számit a domain/host/IP cimek stb

EASM beállitása

A használatához szükségünk lesz egy Azure előfizetésre és egy resouce group-ra. Fontos tudni, hogy jelenleg EASM-instancet csak az alábbi régiókban tudunk létrehozni:

  • southcentralus
  • westus3
  • eastus
  • eastasia
  • swedencentral
  • australiaeast
  • japaneast

Navigáljunk el a https://portal.azure.com/#view/HubsExtension/BrowseResource/resourceType/Microsoft.Easm%2Fworkspaces portálra és válasszuk a Create opciót és hozzuk létre az instace-t.

A deployment végeztével az Overview fülön kezdhetjük el a beállitást. Rákereshetünk egy létező vállalatra vagy a “Create custom attack surface” gombbal definiálhatunk egyedi beállitásokat. A példa kedvéért mi egy custom konfigurációt készitünk.

Itt meg kell adnunk a Seed-eket, azaz információkat, amikre a discovery process lefuthat. Ezek lehetnek domainek, IP-tartományok, email kontaktok (pl. office@cegnev.hu) stb. Válasszuk a domaint és irjuk be a kivánt értéket.

Végül mentsük el a konfigot. A leltározási folyamat 24-48 órát vehet igénybe

A discover folyamat igy néz ki:

EASM használata

A leltár felépülte után az Overview oldalon egy áttekintést kapunk

Az Attack Surface Priorities szekció összefoglalja a különböző megfigyelt problémákat. A képen látható 2 medium és 5 low severity találat.

Az egyes találatokra kattintva láthatjuk az érintett IP-ket/hostokat. Jelen esetben egy Django projectnél azonositott egy SQL-injection sebezhetőséget, a hozzátartozó CVE advisory-val és a remediation lépésekkel (Django frissités ajánlott)

Inventory

Az inventoryban láthatjuk a felderitett elemeket. Az asseteket törölhetjük, módosithatjuk

Security Posture dashboard

A security posture mutat különböző értékeket, pl CVE exposure, domainek adminiszrációjával (hol vannak a domainek regisztrálva), az internet felől elérhető nyitott portokat

GDPR Compliance dashboard

A felderitett asseteket megvizsgálja GDPR megfelelőség szempontjából. A dashboard részei a következők:

  • Website by status
  • SSL Certificate Posture
  • SSL Certificate Expiration
  • Sites with SHA 1 / SHA256
  • P11 Posture
  • Login posture
  • Cookie posture

OWASP Top 10 dashboard

Ezen a dashboardon láthatjuk az OWASP által definiált legkritikusabb security ajánlásokat.

  • Broken access control
  • Cryptographic failure
  • Injection
  • Insecure design
  • Security misconfiguration
  • Vulnerable and outdated components
  • Identification and authentication failures
  • Software and data integrity failures
  • Security logging and monitoring
  • Server-side request forgery

Összefoglalás

A Defender EASM egy nagyon hasznos eszköz arra, hogy security szemszögből “kintről”, az internetről is felfedezzük a security hiányosságokat, problémákat. Az assetek számára érdemes odafigyelni, mert bár darabonként nem drága, de többezer tételnél már növelheti az Azure költséget.

Legacy authentication protokollok

Egyre közeleg a dátum, mikor a Microsoft végleg kivezeti a basic authenticationt az Exchange Online elérésében (2023.március 31.)

Az M365 adminok ezt többé-kevésbé tudják, és meg is teszik a szükséges lépéseket. Viszont sokszor jön a kérdés, mik is ezek a legacy protokollok és mi használja őket?

Az Azure Active Directoryban sign-in logban leszűrve ezeket látjuk, mint legacy protocols:

Legacy protocols:

  • Authenticated SMTP – POP és IMAP kliensek használják levélküldésre
  • Autodiscover – Outlook és Exhange Active Sync kliensek használják a mailboxok megkeresésére az Exchange Online-ban, pl Windows Mail és egyéb mobilalkalmazások
  • Exchange ActiveSync (EAS) – Postafiók elérés Exchane Online-ban
  • Exchange Online PowerShell – Exchange Online elérése Powershellből
  • Exchange Web Services (EWS) – úgynevezett programming interface amit az Outlook, Outlook for Mac, és 3rd party alkalmazások használnak
  • IMAP4 – IMAP4 email kliensek használják, pl Thunderbird vagy Apple Mail
  • MAPI over HTTP (MAPI/HTTP) – Outlook 2010/2013 kliensek használják.
  • Offline Address Book (OAB) – Outlook használja az address list letöltésére
  • Outlook Anywhere (RPC over HTTP) – Outlook 2016 használja
  • Outlook Service – Windows 10-ben lévő Mail and Calendar app használja
  • POP3 – POP3 kliensek használják
  • Other clients – minden más protokoll ami legacy módon működik

A POP/IMAP/Remote Powershell már kapott Oauth 2.0 támogatást, ezek továbbra is használhatók.

Microsoft Sentinel – ingyenes konnektorok

Ügyfelekkel való konzultáció során szinte mindig elhangzik a kérdés: melyek az ingyenes Sentinel-konnektorok? Tudjuk őket definiálni, de vannak olyan ingyenes konnektorok, amik tartalmaznak fizetős elemeket is.

Ingyenes adatforrások:

  • Azure AD Identity Protection
  • Azure Activity Logs
  • Office 365
  • Microsoft Defender for Cloud
  • Microsoft Defender for IoT
  • Microsoft 365 Defender
  • Microsoft Defender for Endpoint
  • Microsoft Defender for Identity
  • Microsoft Defender for Cloud Apps

Fontos tisztázni: a data connector bekötése mindig ingyenes. A logfileok esetén csak az Azure Acive Directory és O365 audit logok ingyenesek. A többi logforrásnál csak az alert és incidens generálás és néhány aktivitás ingyenes.

Nézzük egyenként a data connectorokat:

Azure AD Identity Protection:

Előfeltétel: Azure AD Premium 2 licensz

Ingyenes adattipus: Security Alert (IPC)

Azure Activity:

Ingyenes adattipus: minden tipus

Office 365

Ingyenes adattipus: Sharepoint, Exchange és Teams activity

Defender for Cloud:

Ingyenes adattipusok: Security Alert

Defender for IoT:

Ingyenes adattipus: Security Alert

Microsoft M365 Defender:

Ingyenes adattipus: Security Alert és Security Incident

Figyelem: a többi adatbetöltés már számolódik a Sentinel költségbe!

Defender for Endpoint:

Ingyenes adattipus: Security Alert (MDATP)

Defender for Identity:

Ingyenes adattipus: Security Alert (AATP)

Defender for Cloud Apps:

Ingyenes adattipus: Security Alert (Defender for Cloud App)

A Cloud Discovery logok bekapcsolása szintén számolódik a Sentinelben

Összefoglalva:

Mint látjuk, a Microsoft Sentinelt költséghatékony módon tudjuk használni arra hogy az O365 és Azure Activity logokat gyűjtsük és a különböző Microsoft termékekből érkező alerteket is fogadjuk.

Azure AD Certificate-based Authentication

2022 novemberében a Microsoft az Ignite konferencián bejelentette az Azure AD CBA szolgáltatás végleges (General Available) állapotba kerülését. Lássuk, mi ez és hogyan tudjuk beállitani.

Mi az Azure AD CBA?

A CBA lehetővé teszi, hogy különböző Microsoft alkalmazásokba és webes felületekre tanúsitvánnyal jelentkezzünk be. A tanúsitványt a saját PKI (public key infrastructure) környezetünkből kapjuk és az Azure AD ezt használja fel a hitelesitéshez. Ezzel egy úgynevezett phishing-resistent megoldást kapunk.

Hogyan működik a CBA?

A következő ábra bemutatja a bejelentkezési folyamatot:

Lássuk az egyes lépéseket:

  1. A felhasználó megnyitja a https://myapps.microsoft.com portált
  2. Ha nem volt eddig bejelentkezve, akkor a felhasználót elirányitja a https://login.microsoftonline.com oldalra
  3. A felhasználó megadja a nevét
  4. Az Azure AD ellenőrzni, hogy a tenantban be van-e állitva a CBA authentication. Ha igen, akkor megjelenik egy link “Use a certificate or smartcard” néven
  • 7. Az Azure AD ellenőrzni a tanúsitvány visszavonási listát (CRL), hogy nincs-e visszavonva
  • 8. Ha van Conditional Access policy, ami megköveteli az MFA-t, és ha az úgynevezett certificate authentication binding rule megfelel, akkor a belépés megtörténik.
  • 9. Az Azure AD elküldi a primary refresh tokent és a belépési process lezárul

Hogyan állitsuk be a CBA-t?

Előfeltételek:

  • Működő PKI rendszer (legalább egy root CA plusz egy intermediate CA)
  • Kiadott tanúsitvány a felhasználóknak (client authentication SKU)
  • A CA-nak legyen elérhető a CRL listája az internet felől (ennek hiányában az Azure AD nem fogja leellenőrizni a tanúsitvány érvényességét és nem blokkolja a belépést)

CA konfiguráció az Azure portálon

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/CertificateAuthorities portálra és töltsük fel a Root (és esetleg az intermediate CA) tanúsitványunk publikus kulcsát. Töltsük ki a CRL endpoint URL-jét is.

Engedélyezzük a CBA-at a tenantban

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods portálra és engedélyezzük a Certificate-based authenticationt.

Beállithatjuk az user csoportokat vagy minden usert is, a configure részben pedig maradhatunk az alapbeállitásoknál.

A többi opciót (single vs multi-factor authentication, rules) a következő posztban fogom részletezni.

Összefoglaló:

Áttekintettük, hogy mi az Azure CBA, hogyan működik és hogyan lehet alapszinten bekonfigurálni.