Category Archives: M365 Security

Microsoft Intune Suite és add-on képességei

Posted on by
Reply

A Microsoft Intune MDM megoldása már régóta a piacon van, lefedve a Windows, Android, macOS, Linux és iOS platformok menedzselését. A Microsoft azóta több szolgáltatást is fejlesztett és ezeket különböző csomagokba építette, igényekre reflektálva (Távoli segítség, firmware frissítést stb.)

Az alábbi táblázat mutatja az Intune Suite funkcióit, a licenszelésre később kitérünk:

Nézzük meg egyenként a funkciókat, röviden áttekintve:

  • Endpoint Privilege Management: Az EPM segítségével a standard jogosultságú felhasználók végrehajthatnak különböző feladatatokat, amik admin jogosultságot igényelnek (pl. alkalmazástelepítés, driver install, stb). Az IT-adminok különböző policykat küldhetnek a gépekre, ahol a felhasználó használhatja a “Run with elevated access” opciót és indoklás megadávásal elvégezheti a feladatot.
  • Enterprise App Management: egy előregyártott Win32 alkalmazásgyűjtemény, ami tartalmaz Microsoft és 3rd party alkalmazásokat (pl. Foxit PDF Reader, Dell Command Update stb). Az alkalmazásokat előre paraméterezték (detection rule, install-uninstall script) igy azonnal használatba vehetőek. Az itt található alkalmazások automatikus frissitik magukat, a kliensgépen is.

  • Advanced Analyitcs: az AA segítségével proaktívan felderíthetők és megoldhatók a kliensgépeken található problémák (alkalmazás összeomlások, legfagyások, váratlan gépújraindulások stb) vagy akár a laptopok akkumulátor-problémái is azonosíthatók.
  • Remote Help: biztonságos helpdesk kapcsolat Windows/Android/macOS eszközök felé. Ennek segítségével a helpdesk tud kapcsolódni az adott eszközre és láthatja a képernyőjét, átveheti az irányítást is. A biztonságot a role-based access adja, szigorúan meghatározott szerepkörökkel. Ez különösen hasznos funkció, ha külső hálózatban lévő gépet kell távolról supportálni.
  • Microsoft Tunnel for Mobile Application Management: amennyiben használunk Microsoft Tunnel VPN Gateway-t, a Tunnel for MAM szolgáltatással ki tudjuk terjeszteni az elérést a nem-enrollolt, nem menedzselt eszközökre is. A felhasználó a nem menedzselt eszközével is el tud érni belső hálózaton található erőforrásokat, SSO-val, modern hitelesítéssel, Conditional Access szabályokkal. Ez Android és iOS platformokra vehető igénybe.
  • Firmware-over-the-air-update: bizonyos támogattott eszközök automatikus firmware frissítését teszi lehetővé, pl. Zebra vagy Samsung Knox eszközök.
  • Specialized device management: AR/VR headsetek (RealWear, HTC eszközök), Microsoft Teams Rooms, Microsoft HoloLens eszközök menedzselését teszi lehetővé.

Licenszelés:

Alapvetően szükséges a Microsoft Intune licensz megléte. Ez lehet Business Premium vagy E3/E5 licensz, esetleg standalone Intune előfizetés. Erre lehet fűzni az Intune Plan 2-t ( Tunnel for MAM és specialty device management képességek) vagy az Intune Suite-ot, ami minden funkciót tartalmaz. Fontos azonban hangsúlyozni: az Intune Suite-hoz szükség van az alap Intune licenszre!

Leggyakoribb igény esetleg a Remote Help lehet, ezt add-on formájában meg lehet vásárolni az alap Intune licenszhez, 3,5 USD/hó/felhasználó áron.

A többi elérhető szolgáltatást igénybevételét is lehet mérlegelni, igénybe venni.

Intune Certificate Connector – Azure AD Sign in probléma

Posted on by
Reply

Microsoft Intune Certificate Connector telepítése közben szükséges belépni az Azure AD-ba. Ilyenkor viszont belefuthatunk egy hibaüzenetbe:

“Something went wrong An unanticipated error occurred. Your IT department may be able to help.”

A sikeres konfigurációhoz az alábbi feltételek szükségesek:

  • Global Administrator vagy Intune Service Administrator szerepkör ÉS Intune license hozzárendelve (ez elég ideiglenesen, a konfiguráció időtartamára) az accounthoz.
  • Az accountnak szinkronizálva kell lennie az Azure AD-val.

Ezek után már működik a bejelentkezés

Defender for Identity és VPN integráció NPS-sel

Posted on by
Reply

A Microsoft Defender for Identitiy (MDI) integrálható egy meglévő VPN szolgáltatással, azaz a VPN el tudja küldeni a RADIUS accounting logokat az MDI szenzornak (IP cím, ország stb). Ezzel információkat tudunk gyűjteni, honnan próbálják a VPN kapcsolatot felépíteni, van-e anomália. Gyanús esemény lehet ha hirtelen más országokból próbálnak VPN-en csatlakozni.

Jelen pillanatban az alábbi gyártók VPN megoldásai támogatottak a standad RADIUS accountinggal:

  • Microsoft
  • F5
  • Check Point
  • Cisco ASA

Nézzük meg, hogy a Microsoft RRAS esetén mik a beállítási lépések:

Nyissuk meg az RRAS konzolt, a Security fülön tudjuk konfigurálni a RADIUS accountingot

Itt megadhatjuk az egyik MDI szenzor nevét/IP-jét.

Utána pedig az MDI portálon beállítjuk a Shared Secretet

Eddig rendben; de mi van olyakor, ha Network Policy Servert használunk, ugyanazon a VPN szerveren? Ebben az esetben nincs ott a RADIUS accounting az RRAS konzolban.

Hogy tudjuk igy eljuttatni a RADIUS accounting logokat az MDI szenzorhoz?

Az NPS konzolban definiáljunk új Remote RADIUS Server Groupot, megadva az MDI szenzorok nevét/IP-jét:

Állítsuk be a Shared Secret értékeket:

Végül pedig a VPN connnection request policyben definiáljuk, hogy a RADIUS accounting melyik távoli szerveren történjen meg (ez esetben az MDI szenzorok)

Utána természetesen ne felejtsük el az MDI portálon is megtenni a szükséges beállításokat.

Azure Information Protection (Microsoft Purview) scanner licenszelési kérdés

Posted on by
Reply

Mikor ügyfelekkel beszélgetek információvédelem, Azure Information Protection (új nevén Microsoft Purview) témakörről, szinte mindig előjön a földi fileshare-ek kérdése: lehet-e az onprem rendszereken tárolt adatokat kategorizálni és esetleg automatikusan labellel ellátni?

A jó hír, hogy lehet. A rosszabbik, hogy minden felhasználónak E5-ös licensz kell hozzá (ez igy nem teljesen igaz, nemsoká kifejtem), ez sokszor az ügyfelek kedvét szegi, tehát érdemes tisztázni ennek a technikai és licenszelési hátterét.

Tehát, mi kell hozzá hogy egy földi fileshare-en tárolt dokumentumokat automatikusan kategorizálni és labelezni lehessen?

  • Microsoft Purview scanner bekonfigurálva
  • Megfelelő licensz

Amikor a scanner labelez egy dokumentumot, a file tulajdonosának rendelkeznie kell Azure Information Protection P2 licensszel. Ha valaki a fileshareben létrehoz egy új dokumentumot, amire alkalmazódik a label, akkor is kell az AIP P2 licensz. Mivel gyakorlatilag mindenki hozhat létre dokumentumokat, amiket ilyen vagy olyan okokból automatikusal labelezni kell, nagyjából mondhatjuk hogy szinte az összes felhasználót licenszelni kell AIP P2-re.

Ezt persze lehet szofisztikálni, előzetes felméréssel, hány owner lehet a meglévő fileokon illetve hogy kik használják a fileshare-t és rájuk szűkíteni a licenszelést.

Licenszelési oldalról sokszor elhangzik a fent emlitett “E5 kell hozzá”. Szerencsére nem feltétlenül. Az automatikus labelezéshez szükséges AIP P2-t az alábbi módokon is beszerezhetjük:

  • Azure Information Protection P2 mint standalone előfiezetés, kb 5 euró/hó/fő
  • M365 E5 Information Protection & Governance addonként (meglévő E3-as liceszek mellé vehető) kb. 7 euró/hó/fő
  • Enterprise Mobility + Security E5 előfizetés, kb 15 euró/hó/fő
  • illetve a “nagy” M365 E5 csomagban is megtalálható

A fenti számok csak tájákoztató jellegűek, illetve a többi licensztípussal más szolgáltatásokat is használhatunk.

Always-on VPN IPSec policy Intune-ból

Posted on by
Reply

Aki már konfigurált AOVPN-t, az tudja, hogy illik az IPsec beállításokat az alapértelmezettnél erősebbé tenni.

Az alapértelmezett IPSec értékek a következők:

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

A javasolt beállítások:

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

A VPN szerver oldalon ezt powershell paranccsal tudjuk módosítani:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Utána szükséges a Remote Access service-t újraindítani:

Restart-Service RemoteAccess -PassThru

Ezzel a szerveroldali beállítások elkészültek. Szükséges viszont hogy a kliens oldalon is megegyezzenek az IPSec konfigurációk, itt is segítségül hívhatjuk a powershellt:

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Hogy néz ki mindez, ha Intune-ból akarjuk kiküldeni az IPSec policyt? Nos, elsőre nem feltétlenül egyértelmű, hogy a fenti parancsban definiált értékek hol vannak az Intune policyban:

Hogy ne kelljen sokat keresgélni, tesztelgetni, itt egy működő beállítás:

IKE Security Association Parameters

  • Encryption algorithm: AES-128
  • Integrity check algorithm: SHA2-256
  • Diffie-Hellman group: 14

Child Security Association Parameters

  • Cipher transform algorithm: CBC-AES-128
  • Authentication transform alorithm: HMAC-SHA256-128
  • Perfect forward secrecy (PFS) group: Use parent Diffie-Hellman group

Elavult böngészők szűrése

Posted on by
Reply

Az IT-securityben nagy hangsúlyt fektetünk rá, hogy az operációs rendszerek/alkalmazások naprakészek legyenek. Ugyanez vonatkozik a böngészőkre is, elemi érdek, hogy mindig a biztonsági frissítésekkel ellátott verziót használjuk, a céges erőforrások eléréséhez (OWA, Sharepoint Online stb).

Lásd CIS Control 9.1 “Ensure only fully supported browsers and email clients are allowed to execute in the enterprise, only using the latest version of browsers and email clients provided through the vendor.”

Eddig az elmélet, de a gyakorlatban hogyan tudjuk kikényszeríteni, hogy valóban csak “friss” böngészővel lehessen az erőforrásokat elérni?

Ebben segit az Azure AD Conditional Acces és Defender for Cloud Apps szolgáltatás. Lássuk, hogyan lehet letiltani az “outdated” browser használatát.

Megjegyzés: outdated browsernek számít az aktuális főverzió -2. Tehát ha pl. az Edge a 109-es verziónál jár, akkor támogatott a 109, 108 és 107 főverzió.

Először is, szükség lesz a kívánt erőforrás (OWA, Sharepoint stb) továbbirányítására a Defender for Cloud Apps-ba.

Conditonal Access

Készítsünk egy Conditional Access policy-t, az alábbi beállításokkal:

Defender for Cloud Apps Access Policy

A Cloud Apps-ban hozzunk létre egy Access Policyt:

Az User agent tag értéke legyen egyenlő az Outdated browser kategóriával illetve az Action legyen Block értéken. Természeseten más filtereket is hozzáadhatunk (user group stb.)

Tesztelés

Tesztelésként telepítettem egy Firefox 98-at és megpróbálkoztam egy böngészős Teams bejelentkezéssel. A Defender for Cloud Apps blokkolta is az elérést, ahogy vártuk:

A fenti tiltást nemcsak böngészőre, de akár operációs rendszerre is alkalmazható:

Összefoglalás

Ahogy a fentiekből látható, könnyen biztosíthatjuk, hogy naprakész böngészőkből legyen elérhető az erőforrás (ne feledjük, hogy nemcsak beépített MS szolgáltatásokat tudunk így védeni, az Azure AD Application Proxy segítségével akár 3rd party vagy on-prem alkalmazásokat is).

Break-glass account monitorozása

Posted on by
Reply

Fontos szerepe van a break-glass accountoknak, hogy legyen “visszaállási” lehetőségünk hibás konfiguráció (pl. kizártuk magunkat a tenantból Conditional Access policyval) vagy szolgáltatás kiesés esetén. Személyes élmény 2018-ból, mikor nagyjából napig nem működött az Azure MFA, így bejelentkezni sem tudtam az admin accounttal 🙂

Erre a veszélyre reflektálva sok szervezet használ már break-glass accountot. Mielőtt rátérnénk a security vonatkozásokra, nézzük át gyorsan az ajánlásokat az accounttal kapcsolatban:

  • a break-glass account az Azure AD-ban létrehozott entitás legyen; ne használjuk syncelt vagy federált accountot.
  • ne legyen személyhez kapcsolva
  • Ha használunk a breakglasshoz MFA-t, ne legyen valaki személy telefonja, emailcíme stb; a legjobb egy dedikált FIDO2 security key, biztos helyre elzárva
  • az accountra ne vonatkozzon semmilyen Conditional Access policy, illetve egyéb más security policy
  • Azure AD Identity Protectionban állítsuk permanent Global Administratorra, ne csak Eligible-re

Monitorozás

Security szempontból elengedhetetlen, hogy monitorozzuk ennek az accountnak a használatát. Hiszen nincs személyhez kötve, nincs MFA sem hozzá, így kritikus hogy lássuk az aktivitását. Ebben tud segiteni a Microsoft Sentinel.

A monitorozáshoz szükséges előfeltételek:

  • Microsoft Sentinel és Log Analytics Workspace
  • Azure AD P1 vagy P2 licensz a sign-in logok exportálásához
  • Break-glass account
  • Break-glass account Object ID

Feltételezzük, hogy a Sentinel már be van állítva, rátérhetünk a konnektor konfigurálásra.

Sentinel konnektor konfigurálása

Navigáljunk el a Sentinel portálra, majd a Data Connectors közül válasszuk ki az Azure Active Directory konnektort:

Az Audit és Sign-in logokat válasszuk ki:

A konnektor státuszát és a loggyűjtést tudjuk ellenőrzni a tulajdonságlapon:

Analytic rule elkészítése

Készítünk egy rule-t, ami incidenst generál ha a break-glass accounttal aktivitás történne.

Navigáljunk el a Sentinel portálon az Analytics részre és válasszuk a Create scheduled query rule opciót.

Adjunk nevet és leírást a szabálynak, a Tactics résznél válasszuk ki az Initial Access és Credential Access lehetőségeket, a Severity legyen High értéken.

A Set rule logic résznél egy Kusto lekérdézést kell definiálnunk:

SigninLogs
| project UserId,UserPrincipalName, Location, SourceSystem, TimeGenerated, IPAddress
| where UserId == 'object-id'
| extend AccountCustomEntity = UserPrincipalName
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

Az UserID-hoz tartoztó object-id-t megtaláljuk az Azure Active Directoryban a break-glass account tulajdonságlapján.

A lekérdést állítsuk be 5 percenkéntire.

Az Incident setting résznél állitsuk be hogy generálódjon incidens

Ellenőrzés

A beállítások után érdemes leellenőrizni, hogy valóban működik-e az incidensgenerálás. Ehhez jelentkezzünk be a break-glass accounttal és nézzük, megjelenik-e a Sentinel alert.

Összefoglalás

Az break-glass account megléte nagyon fontos, de ugyanúgy kiemelt szerepet kap a monitorozása is. A fentiek alapján ez könnyen beállítható.

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

Posted on by
Reply

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

Posted on by
Reply

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.