Jelszócsere vagy jelszó reset?

Sok szervezetnél teszem fel az alábbi kérdést: “van password reset megoldásotok?”

A válasz szinte minden esetben egy magabiztos “Igen! Ott az OWA felületünk, vagy akár az ADFS-en”

Elsőre jónak hangzik, de nézzük meg közelebbről. Technikailag a jelszócsere és reset esetén is ugyanaz történik: megváltozik a jelszó. Az odavezető út azonban már árnyaltabb.

Jelszócsere megoldások:

Ahogy említettem, jelszócserére tökéletes az OWA vagy ADFS felület:

Ahogy látjuk, itt minden esetben szükéséges, hogy a felhasználó tudja a régi jelszavát is, annak megadásával tud új jelszót is beállítani.

Ez kockázatos is lehet, mert ha egy támadó megszerzi a jelszót, annak birtokában meg is tudja változtatni.

A fentiek viszont nem adnak megoldást, ha a felhasználó ténylegesen elfelejtette a jelszavát. Ebben az esetben marad a nehézkes megoldás, ahol az IT-helpdesk segítségét kell kérje. Ez is érdekes lehet, hogy miként történik meg, ha a céges ticketing rendszerbe nem tud belépni. Telefonon felhívja az IT-t, hogy kérek egy jelszóresetet? Nem biztonságos. Megkér egy kollégát, hogy nyisson egy ticketet a jelszóresetről? Nem biztonságos, plusz hogyan juttatjuk el neki az új jelszót? Egy külső emailcímre vagy egy megadott telefonszámra sms-ben? Megint csak nem biztonságos.

Fontos tehát, hogy legyen password reset megoldásunk, lehetőleg önkiszolgáló módon, tehát a felhasználó saját magának tudjon jelszót resetelni, az IT-bevonása nélkül. Így az IT-t sem terheli, és felhasználói oldalról sincs várakozás.

Az Azure AD P1 licenszekkel igénybevehető a Self-Service Password Reset eszköz, amivel biztonságos módon, többfaktoros hitelesítéssel lehet új jelszót beállítani.

A felhasználó elnavigál a https://portal.office.com oldalra és kiválasztja a “can’t access your account?”

Megadja a felhasználónevét:

A következő oldalon pedig kiválasztja, hogy milyen megoldással szeretné hitelesíteni magát. A lenti képen az AzureAD-ban regisztrált telefonra SMS-küldéssel vagy az Authenticator alkalmazásból való kóddal:

A kód megadása után már beállítható az új jelszó:

Mint látható, az Azure AD SSPR eszközzel egy nagyon könnyen és gyorsan beüzemelhető bizotonságos jelszóreset-rendszert kapunk.

ADFS monitorozás a felhőből

A nagy szervezeteknél gyakori az ADFS használata. Itt tenném hozzá, ha csak az Office365 felé hitelesítést szeretnénk kezelni, ahhoz van már sokkal rugalmasabb eszköz, Pass-Through Autentication Method (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)

Visszatérve, ilyen vagy olyan okok mentén kiépült a hibatűrő-magas rendelkezésre állású ADFS-farmunk. A hitelesítés működik, felhasználók részéről nincs panasz, minden rendben.

Mint minden fontos szolgáltatást, az ADFS-t is kell tudnunk monitorozni, látni a hibákat és rögtön beavatkozni, ha szükséges. A loggyűjtés megvalósítható egy SIEM rendszerrel, központi logolással, de abból visszamenőleg adatokat-riportokat kinyerni nehézkes feladat. Az Azure AD Connect Health with ADFS segítségével viszont könnyen, pár kattintással ellenőrizhetjük az ADFS-farmunkat.

Segítségével riasztásokat kaphatunk az ADFS teljesítményéről, konfigurációs hibáiról:

Illetve figyelemmel kísérhetjük az hitelesítési forgalmat, a relying party-k kihasználtságát:

Ezen kívül monitorozhatjuk a node-ok teljesítményét is:

Sőt, egy jelentést is kaphatunk, a top 50 hibás felhasználónév/jelszó párosról:

Ennek figyelése különösen fontos, mert lehet hogy csak egy konfigurációs hibáról van szó (scriptben bennemaradt egy régi jelszó), de lehet, hogy egy támadás jele is. Ez a riport 12 óránként frissül automatikusan.

Hogyan üzemeljük be az AD Connect Health with ADFS szolgáltatást?

Előfeltétel: Azure AD Premium P1 vagy P2 licensz

Engedélyezzük az ADFS Auditot:


Open Local Security Policy by opening Server Manager on the Start screen, or Server Manager in the taskbar on the desktop, then click Tools/Local Security Policy.
Navigate to the Security Settings\Local Policies\User Rights Assignment folder, and then double-click Generate security audits.
On the Local Security Setting tab, verify that the AD FS service account is listed. If it is not present, click Add User or Group and add the AD FS service account to the list, and then click OK.
To enable auditing, open a command prompt with elevated privileges and run the following command: auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable
Close Local Security Policy.
— The following steps are only required for primary AD FS servers. —
Open the AD FS Management snap-in (in Server Manager, click Tools, and then select AD FS Management).
In the Actions pane, click Edit Federation Service Properties.
In the Federation Service Properties dialog box, click the Events tab.
Select the Success audits and Failure audits check boxes and then click OK. This should be enabled by default.
Open a PowerShell window and run the following command: Set-AdfsProperties -AuditLevel Verbose.

Töltsük le a szükséges agentent az Azure Portalról:

https://portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/AadHealthMenuBlade/QuickStart

Telepítsük fel az agentet az összes ADFS és Web Application Proxy node-ra

A telepítés után kezdődhet a konfigurálás

Jelentkezzünk be Global Adminként

A bejelentkezést követően elindul egy Powershell és elvégzi a szükséges beállításokat. Az esetleges hibákat is jelzi:

A sikeres telepítést követően három service fog futni:

Azure AD Connect Health AD FS Diagnostics Service
Azure AD Connect Health AD FS Insights Service
Azure AD Connect Health AD FS Monitoring Service

A sikeres telepítést és regisztrálást követően a működés ellenőrizhető az Azure AD-ban:

https://portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/AadHealthMenuBlade/AdfsServicesList

Megnézhetjük az Overview-t

Ellenőrizzük az Active Alerts részt:

Rögtön két konfigurációs hiba, ami javításra szorul. A javítást követően a rendszer lezárja a riasztást. A riasztásokról egyébként a Global Adminok emailt is kapnak:

A Monitoring rész alatt megnézhetjük az alapvető értékeket pl token requests/sec

Illetve a lekérdezést testreszabhatjuk jobb klikkel:

Az Usage Analytics résznél megnézhetük a használt relying party-kat:

A Bad Passwords Attemps résznél tudjuk ellenőrizni a leggyakrabban előforduló felhasználónév/jelszó hibákat

A kiugró failure eredményeket itt is érdemes megnézni és remedálni (pl. scriptben maradt régi jelszó, stb).

A Risky IP Report résznél láthatjuk a következő eseményeket:

  • IP címek, amikről túllépték a failed password logint
  • Felhasználóneveket, amikkel a belépési kísérletek történtek

A fenti screenshot alapján látszik, hogy este 6 és 7 óra között az adott IP-címről 14 különböző felhasználónévvel kíséreltek meg belépést.

Összefoglalva: érdemes az ADFS monitorozást beállítani at Azure AD segítségével, sok hasznos információhoz juthatunk vele.

O365 és M365, mi különbség?

Sokszor felmerül ez a kérdés, hogy mi a különbség a két termék között?

Nagyon röviden:

  • Az O365 az productivityhez kapcsolódó termékeket tartalmaz, Office-Teams-Sharepoint stb
  • Az M365 a fentieket tartalmazza, plusz a Windows 10-et és az Enterprise Mobility + Security csomag részeit.

A lenti táblázat részletezi az egyes elérhető komponenseket

Tippek a helpdesk terhelésének csökkentésére

Az utóbbi fél évben bekövetkezett távoli munkavégzés az IT-helpdeskek terhelését jelentősen megnövelte. Nézzünk pár tippet, amivel a felhasználók produktivitása is megmarad, a helpdeskről is levesz terheket és a működési költséget is csökkenti.

  1. Elfelejett jelszavak problémája

Nagyon sok szervezetnél jelent kihívást, hogy kezeljék az elfelejettett felhasználói jelszavak resetelését. Ez mindenkinek rossz, hiszen a felhasználó addig nem tud dolgozni, az IT-helpdesknek pedig ismétlődő unalmas feladat. További kérdés, hogy a megváltoztatott jelszót hogyan juttatják el a felhasznónak (SMS, vagy magán emailcímre küldéssel? Ez vajon bizonságos?)

Azure AD Self-Service password reset szolgáltatással a felhasználó tud jelszót resetelni saját magának is, biztonságos módon (kétfaktoros hitelesítéssel)

A felhasználó pedig ezt látja:

Állítsuk be ezt szolgáltatást és oktassuk le a felhasználóknak. Megfelelő kommunikáció után akár 80%-kal is csökkenhet az “elfelejettem a jelszavam, resetet kérnék” esetek száma.

2. Windows upgrade-ek zavartalansága

A Windows 10-hez évente kétszer érkezik nagyobb frissítőcsomag, melyek telepítése minden esetben nagyon ajánlott. Érdemes up-to-date tartani az operációs rendszereket, mind a biztonsági, mind az egyéb funkcionális frissítések miatt.

Amennyiben viszont nem-Microsoft végpontvédelmi megoldás van használatban, az okozhat gondot a frissítési folyamatnál, ezáltal megint csak jelentős mennyiségű helpdesk-ticketet generálva.

Elkerülhető ez a probléma és a hosszas előzetes kompatibilitási tesztelések, ha végpontvédelmi megoldásnak a Microsoft Defender ATP-t használjuk. Az MDATP-vel nem csak a klasszikus vírusvédelmi megoldást lehet bevezetni, hanem a különböző fejlett támadási formákat is képes detektálni és megállítani.

3. Bátorítsuk a BYOD-ot!

Megint csak egy jellemző problémakör tud lenni az eszközök menedzselése. Új felhasználó érkezik a céghez, laptopra van szüksége, beállításokra, jogosultságokra stb. A gép átvételéhez személyesen kell megjelennie az irodában, várnia, ez mind-mind időveszteség.

Ezek csökkentésére egy megoldás lehet a BYOD-eszközök használata. Amennyiben van mód rá, érdemes bátorítani a felhasználókat hogy használják a meglévő eszközeiket (számítógép, mobil stb), ezáltal “önjáró” módon beálltani a munkakörnyezetét.

A Microsoft Endpoint Managerrel (régi nevén Intune), egy robosztus, biztonságos keretrendszer alakítható ki az ilyen eszközöknek (és természetesen a vállalati eszközöknek is). A MEM-mel biztosítható az eszközök felügyelet alá vonása (enrollment), különböző alap-alkalmazásokat lehet automatikusan telepíteni, VPN-beállítások leküldeni, különféle biztonsági beállításokat előírni.

A fenti környezetek kialakítása nem egyszerű, egylépéses feladat, viszont megéri a befektetést.

Dokumentumok megosztása külsős partnerekkel, biztonságosan

Előző cikkemben bemutattam, hogyan lehet egy alap információvédelmi megoldást implementálni, amit a felhasználók egymás között tudnak használni:

https://istvanffyzoltan.com/2020/07/14/informaciovedelem-m365-alapon/

Ezek után merül fel a jogos igény, hogy lehet ezt kiterjeszteni külsős parterekre is, azaz biztosítani számukra a dokumentumok megosztását és közös Teams-munkát, miközben a hozzáférés/tartalomvédelem is megmarad.

A most következő cikkben leírok egy lehetséges megoldást, amit kiindulási alapnak lehet használni.

A külsős accountok kezelése mindig is fejtörést okozott a szervezeteknek. Létrehozhatók a földi vagy felhős AD-ben, mint standard userek, de akkor nekünk kell a biztonságról/jelszókezelésről/licenszekről gondoskodnunk.

A javasolt megoldás inkább, hogy a kezeljük őket az Azure AD-ban, guestként. Erre az AAD lehetőséget ad, ingyenesen. Az általános szabály, hogy egy licenszelt userre 5 guest juthat. Tehát egy 100 fős cégnél 500 guest accountot lehet létrehozni díjmentesen.

Az Azure AD B2B (business-to-business) lehetőségét kihasználva nagyon egyszerűen megoldható, hogy egy vállalati accounttal rendelkező külsőst meghívjunk (invite) guestként. Így lehetősége van a saját accountja használatára, nincs szükség külön regisztrációra, név/jelszó karbantartására.

Azure AD Guest meghívása

Ehhez küldenünk kell számára egy meghívót az Azure AD-ból. Navigájunk el ide adminként ide: https://portal.azure.com/#blade/Microsoft_AAD_IAM/UsersManagementMenuBlade/AllUsers és válasszuk a New Guest opciót.

Töltsük ki a név és emailcím mezőket, ide fog kimenni a meghívó.

A meghívó elküldése meg is tudjuk nézni az így létrejött accountot:

Látható, hogy még nem fogadta el a meghívást, azaz nem csinálta végig a regisztrációs processt.

A címzett egy emailt kap, melyben lévő linkre kattintva el tudja kezdeni a regisztrációt:

Figyelmeztetés: mindig legyünk óvatosak a invitáló mailekkel! Csak akkor kattintsunk a linkre és végezzük el a belépést, ha előtte megbizonyosodtunk a meghívó szervezet érvényességéről. Ha ismeretlentől érkezik a felkérés, töröljük a meghívó levelet.

A linkre kattintva az O365 bejelentkező képernyő fogad, az authentikáció miatt:

A bejelentkezés után kapunk egy beleegyezés-kérő ablakot, ami felsorolja, hogy milyen információkat kérne rólunk a meghívó szervezet (név, emailcím, esetleg fotó)

A beléptetés után a meghívó szervezet oldalára jutunk:

Ha újra megnézzük az Azure AD-ban a meghívott user adatlapját, már látható, hogy a regisztrációt megcsinálta, és példánkban egy külső Azure AD-tenantból érkezett.

Evvel a felhasználó accountja létrejött az Azure AD-ban, használatra kész.

Természetesen a fenti folyamat scriptelhető, sőt Power Automate segítségével egy olyan workflow is összeállítható, ahol a meghívást indító felhasználó csak beírja a kívánt meghívott nevét és emailcímét, a rendszer pedig a háttérben intézi a folyamatot.

Következő lépésben engedélyezni kell a külsősökkel való együttműködést a Sharepoint Online / Teams rendszerekben.

Teams Guest access engedélyezése:

Az Office Admin Portalon, az Org Settings / Microsoft Teams részen kapcsolhatjuk be a guest accesst:

https://portal.office.com/AdminPortal/Home#/Settings/Services/:/Settings/L1/SkypeTeams

A Sharepoint Online-ban is érdemes beállítani a megosztási lehetőségeket, szabályozva, hogy csak olyan külsősökkel lehet fileokat megosztani, akik már guestként szerepelnek az Azure AD-címtárunkban:

A Sharepoint Admin Centerben állítsuk be az External Sharing opciónól, hogy Existing guests only:

Ezután a guest usert meghívhatjuk a Teamsbe:

Illetve fileokat is megoszthatunk vele az OneDriveból:

Ezeken túl van mód az információvédelmi megoldást is kiterjeszteni a külsősökre. A sensitivity labelek között kell egy olyan labelt definiálni, ahol a jogosultságot vagy “any authenticated users”-re állítjuk be (ilyenkor bárki, akinek van Azure AD, vagy Microsoft-accountja, hozzá tud férni az információhoz a megfelelő jogosultsággal (pl. Viewer, vagy egyedi beállításokkal, hogy ne tudjon a dokumentumból copyzni, printelni)

Természetsen beállíthatunk guestekre vonatkozó labeleket is:

A fenti labelt alkalmazva az Office-dokumentumokra, majd elküldve pl. emailben a külsős partnernek, meglesz a megfelelő adat- és tartalomvédelem.

Evvel az Azure AD guest + sensitivity label párossal megfelelő biztonság mellett tudjuk biztosítani a Teams és filemegosztási együttműködést.

Információvédelem M365 alapon

A megbízható üzleti működéshez manapság elengedhetetlen feltétel az információvédelem megléte. Külső partnerekkel történő együttműködés igénye, és a jogszabályi megfelelőség mind-mind arra ösztönzi a szervezeteket, hogy legyen megoldásuk a kihívásra.

A M365-ben lévő információvédelmi megoldással a szervezet digitális információvagyona kezelhető és megvédhető a felhőben, on-premise környezetben, felhasználói eszközökön egyaránt.

Sok esetben kevesen tudják, de az M365 E3 (és O365 E3 + EMS E3, ez utóbbi népszerű licenszkonstrukció a hazai vállalaltoknál) beépítetten tartalmaz sok képességet, amivel lefektethető egy információvédelmi rendszer alapja. A megoldás neve a Microsoft Information Protection, röviden MIP.

A védelem életciklusa a következőképpen épül fel:

  • discover: az érzékeny adatok felderítése
  • classify: adat megfelelő kategóriába helyezése (pl. céges adat, szenzitív információ)
  • protect: az adat védelemmel történő ellátása manuálisan vagy automatikusan (label)
  • monitor: a védett adat felhasználásának követése.

Nézzünk egy fikítv példát, hogyan működik a fenti folyamat, GDPR-megfelelősséggel:

Andrea foglalkozik a HR-folyamatokkal, dolgozói belépésekkel. Emiatt sok személyes adattal dolgozik Word- és Excel fileokban.

Discover: a rendszergazda beállította a MIP-et, hogy felismerje a szenzitív információkat (pl. személyi igazolvány számokat), és policyket rendeljen hozzá.

Classify: a MIP alkalmazza a megfelelő címkét, a policy előírásoknak megfelelően.

Protect: MIP automatikusan ellátja a megfelelő védelemmel a filet, amivel megakadályozható, hogy illetéktelenek férjenek hozzá a tartalomhoz. A védelem maga a file részévé válik. Ebben az esetben, ha a file ki is kerül a szervezetből (véletlen vagy szándékos adatszivárgás során), az információ védett marad.

Monitor: a felhasználó vagy a rendszergazda nyomon tudja követni, ki nyitotta meg a file-t (sikeresen vagy sikertelenül, jogosultság hiányában). Amennyiben úgy tűnik, hogy sok a sikertelen hozzáférés – ez lehet biztonsági probléma is- , a hozzáférés könnyen visszavonható.

A következő leírásban bemutatom, hogyan lehet egy nagyon alap megoldást létrehozni, amivel a céges dokumentumokat lehet védeni, hogy közben a felhasználók zavartalanul dolgozhassanak.

Elvárás a megoldással szemben:

  • minden, céges accounttal rendelkező dolgozó teljeskörűen hozzáférhessen a dokumentumokhoz, szerkeszthesse-nyomtathassa stb, fennakadás nélkül.
  • ha a dokumentum kikerül a szervezetből (emailen elküldve, usb-re kimásolva, stb), a védelem maradjon rajta és illetéktelenek ne tudjanak hozzáférni a tartalmához.

Lépések:

Sensitvity Label létrehozása az O365 Security&Compliance Centerben (https://protection.office.com/sensitivity?viewid=sensitivitylabels)

A labelt nevezzük el, pl Internal Use Onlynak:

Az Encryption részen lehet beállítani, hogy védelmi címke alkalmazódjon. Az “Assign permission now” részben tudjuk a jogosultságokat megszabni, kiknek legyen jogosultsága.

A “Choose permission” résznél pedig definiálható, hogy milyen jogosultság legyen hozzárendelve (save, print, copy stb)

A content marking (itt lehetne vízjelet, headert-footert tenni a dokumentumokba), site and group settings, auto-labeling opciókat ebben a példában nem használjuk, csak el kell menteni a labelt.

Az elkészült label megjelenik a felületen:

A label létrehozása után meghatározhatjuk, hogy kinek legyen elérhető. Ezt a label policy beállításban lehet megtenni. Válasszuk a “Publish labels” opciót:

Válasszuk a “Choose sensitivity labels to publish” részt:

A Publish users and groups résznél kiválaszthatjuk, milyen felhasználóknak vagy csoportoknak szeretnénk elérhetőve tenni:

A Policy settings résznél hagyjuk meg az alapbeállításokat:

Nevezzük el a policyt, majd mentsük el:

Az így létrejött policyt láthatjuk a label publishing policynél:

Következő lépésként a felhasználók gépére telepíteni az Azure Information Protection klienst, ami letölthető a Microsoft oldaláról: https://www.microsoft.com/en-us/download/details.aspx?id=53018

A telepítést követően az Office-alkalmazásokban megjelenik egy új menüsor, benne a publikált labellel:

Felhasználói élmény:

A felhasználó innentől kezdve tudja használni az információvédelmi megoldást, a dokumentumra rátéve a labelt, mentés után a következő információt látja:

Megjegyzendő, hogy a “tartalomfogyasztás” maga az ingyenes, tehát a védett dokumentumok megnyitáshoz nincs szükség az Azure Information Protection kliens telepítésére és AIP P1 licensz hozzárendelésére.

Az alapszintű információvédelemi megoldásunk tehát elkészült, a felhasználók tudnak dolgozni vele. Nézzük meg, hogy mi történik, ha egy ilyen “Internal Use Only” védett dokumentum kikerül a szervezeten kívülre.

A példában egy ilyen védett dokumentumot egy melléütés miatt rossz emailcímre küldtek ki. A fogadó megpróbálja megnyitni a file-t a Wordjében, de az bejelentkezési ablakot dob fel.

Mivel nincsen céges accountja, ezért a dokumentum tartalmához sem tud hozzáférni:

Levelezés esetében is hasonlóképp működik a védelem, ha emailt küldünk és rátesszük az Internal Use Only labelt, csak a cégen belüli felhasználók tudják megnyitni:

A fenti leírás alapján látható, hogy nagyon könnyű egy alapszintű védelmi rendszert beállítani, amit természetesen lehet tovább finomítani (további labelek, külsősökkel történő adatcsere esetére pl), illetve adott esetben automatizmusokkal ellátni.

Bemutató – Microsoft CloudApp Security

Mi a Cloud App Security?

Ezt a terméket viszonylag kevesen ismerik, pedig nagyon jó szolgáltatot tud tenni egy IT-szervezetben, a felelős szakemberek (CISO, security osztály stb) válláról hatalmas terhet levesz. Az alábbi cikkben szeretném röviden, technikai mélységek nélkül ezt bemutatni.

A Microsoftos világon kívül is rengeteg olyan felhős szolgáltatás van, ami a szervezet működéséhez szükséges, pl Salesforce. A mai IT-trendeket tekintve, nem realis a teljes “bezárkózás”, hanem gondolni kell az MS-ökoszisztémán kívül eső szolgáltatásokra, ezek felügyeletére is.

Mire használató a CloudApp Security?

Egyfelől megoldást ad a Shadow IT problémára, másfelől integrációt tud biztosítani más felhős szolgáltatásokkal, így az IT-által kontrollált módon történhet a céges adatok mozgása/felhasználása.

 Pár szó a Shadow IT jelenségről:

Shadow IT-nak hívjuk azt, mikor a felhasználók valamilyen szolgáltatást nem kapnak meg a céges IT-tól (szándékosan vagy még nincs megoldás az igényre), és ilyenkor maguk kezdenek megoldást keresni/kiépíteni. A klasszikus példa: “szeretném a fileokat máshonnan is elérni, de erre nem volt mód. Ezért beállítottam egy Google Drive-ot és most működik a fileok szinkronizálása“

Ez egy nagyon veszélyes jelenség, mivel könnyen látható, hogy céges adatok kontroll nélkül kerülnek más felhős szolgáltatásokba, menedzseletlen gépekre (pl. otthoni közös gép). A nemzetközi statiszkák alapján pedig a dolgozók 80%-a használ olyan alkalmazásokat/felhős szolgáltatásokat, amiket az IT nem hagyott jóvá!

Az üzleti igényre, hogy miként lehet monitorozni/kontrollálni a céges adatok mozgását más szolgáltatások felé, a CloudApp Security tud választ adni, a következő elven:

A fenti ábra egyszerűsített magyarázata:

–       azonosítsuk a felhős alkalmazásokat

–       vizsgáljuk meg azokat céges szabályzat szerinti megfelelőségnek

–       beszéljünk a felhasználóinkkal, hogy miért hasznáják ezeket, mi az igény és erre az igényre milyen választ/alternatívát tudna adni az IT

–       engedélyezzük vagy tiltsuk ezeket az alkalmazásokat

–       monitorozzuk a további felhasználást

Hogyan monitorozható a felhős alkalmazások használata?

Az egyik lehetőség, mikor csak egy pillanatképet szeretnék kapni, hogy általában milyen alkalmazásokat használnak a felhasználók. Ilyenkor a céges proxy szerver logjait(pl. elmúlt 2-3 hét) be lehet tölteni a CloudApp Securityba (Snapshot report néven található a beállítás) és az kiad egy átlátható dashboardot:

Itt könnyen áttekinthető a felhős alkalmazások használata, felhasználókra, adatforgalomra stb részletezve. 

Van mód folyamatos logolásra is (Continuous report), mikor a céges proxy szerver folyamatosan adja át a logokat a CloudApp Securitynek, így majdnem valós időben is monitorozható a forgalom.

 Mi a helyzet azokkal a gépekkel, amik nincsenek a céges tűfal/proxy mögött? Elég gyakori jelenség már, hiszen a mobilitás ugrásszerűen megnőtt, egyre több felhasználó dolgozik otthonról vagy különféle hálózatokból. Nos, a Windows 10 1809 verzióval bejött az a képesség, hogy a beépített Windows Defender kliensen keresztül közvetlenül tud reportálni a CloudApp Securitybe.

 A riportok elemzése után következő lépésként megvizsgálható, hogy ezek a használt termékek milyen nemzetközi szabványoknak felelnek meg. Például, ha céges előírás, hogy csak olyan Saas alkalmazás használható, ami teljesíti a SOC2 követelményt, ez könnyen ellenőrzihető.

A CloudApp Security több mint 16 ezer alkalmazást kategorizált (ez folyamatosan bővül), és villámgyorsan lekérdezhető a Cloud App Catalogon keresztül, egy-egy alkalmazás megfelelősége:

 A lenti példán a Google Drive compliance reportja:

Ez a Catalog szolgáltatás mérhetetlen mennyiségű munkát levesz a felelős szakember válláról, hiszen nem kell egyenként keresgélnie egy adott felhős alkalmazással kapcsolatban, hanem ezeket a reveláns információkat készen kapja.

 (megjegyzés: a Microsoft 10-es skálán sorolja az alkalmazásokat, a megfelelőségeket tekintve. Mivel itt több mint 70 nemzetközi standardot vesz alapul, így nem “hajlik a keze maga felé” 😊 A Skype sem kapta meg a 10-es pontszámot, mivel security és compliance szempontok alapján nem teljesíti mindet. Így ez a besorolás teljesen objektív)

 Ezek után érdemes párbeszédet kezdeni a felhasználókkal, ha kiugróan nagy használatot látunk. A példához visszatérve, ha azt látjuk a logokból, hogy napi 2-3 gigabájt adatot töltenek fel a Google Drive-ba, akkor érdemes megkérdeni, hogy mi az igény és az IT mit tud erre nyújtani (lehet a megoldás az OneDrive beállítása, ahol már megoldható az adatok feletti kontroll)

Természetesen a szigorúan szabályozott szervezeteknél ez nem feltétlenül járható, de a párbeszéddel és konstruktív megoldási tervvel mindenki jól jár.

 Amennyiben a felhős alkalmazás elfogadható a céges normák szerint, akkor beemelhető a szoftverkatalógusba.

 A CloudApp Security további képességei, csak címszavakban:

–       magas szintű logolás: felhasználók, fileok, aktivitások részletes logolása-elemzése

–       integráció a Windows Defender ATP és Azure Information Protection termékekkel

–       alkalmazások publikálása: Conditional Access segítségével meghatározható, hogy pl. csak domain tag gépről lehet mellékleteket letölteni a gépre, más esetben letiltja

–       előre definiált alert policyk: pl. nagyszámú fileletöltés adott időn belül, emailek kifelé forwardolása, nagymennyiségű adatforgalom nem jóváhagyott felhős alkalmazás felé

–       anomáliák, riasztások észlelése és kezelése

Ez a termék nagyon ajánlott minden szervezet számára, hiszen a céges adatok kontrollálása megkerülhetetlen felelősség manapság.

Kipróbálható a 30 napos verzió: https://www.microsoft.com/en-us/cloud-platform/cloud-app-security-trial illetve része az Enterprise + Mobility E5 csomagnak

Miért ne féljünk a password hash szinkronizálástól?

A Microsoft Detection and Response Team (DART) csapat tollából született egy remek cikk, https://www.microsoft.com/security/blog/2019/05/30/demystifying-password-hash-sync/

Ennek kapcsán szeretnék én is pár gondolatot megírni.

Ügyfelekkel történő konzultációk során, mikor szóbakerül a jelszóhash-szinkronizálás, sok esetben a teljes megdöbbenés és elutasítás a reakció:

“nem szeretném, hogy a Microsoft hozzáférjen az összes földi AD-jelszavamhoz”

“szigorúan tilos, hogy jelszóinformációk elhagyják a belső hálózatot”

“küzdjön csak meg az NSA a jelszavaimért, nem adom neki az MS-en kereszül tálcán” (ez remélem, irónia volt, nem mertem visszakérdezni…)

Először is, nézzük, hogyan a fenti aggodalmak miért nem valósak, és hogyan történik ez a hash-kezelés:

  • Az AzureAD Connect kliens a domain controllertől kapott jelszóhash-t átalakítja egy 32 bájtos hexadecimális karakterré
  • utána egy binárissá alakítja UTF-16 kódolással
  • a kapott értéket megsózza (salt) további 10 bájttal
  • az így kapott eredményt pedig 1000 alkalommal újrahash-eli HMAC-SHA256 kódolással
  • a végeredményt pedig a tenanthoz dedikált Service Bus juttatja el az AzureAD-ba (TLS kapcsolaton keresztül)

Ez a folyamat valószínűleg már mindenkinek megnyugató 🙂

Továbbmenve, paradox módon hangozhat, de nagyobb biztonságot tudok elérni a felhő felé nyitással (azaz a password hash szinkronizálással), mintha teljesen bezárkóznék mindenféle földi védelmi rendszere mögé! Szembemegy a gondolat a régi beidegződésekkel,igaz? 🙂

Mire gondolok itt?

Ha engedélyezzük a password hash szinkronizálást, igénybevehetünk robosztus felhő alapú, gép intelligenicára támaszkodó szolgáltatásokat, mint például az Azure AD Identity Protection. Dióhéjban, evvel a szolgáltatással nagyon erősen védhető az userek identitása, kaphatok riasztásokat, ha gyanús bejelentkezések történnek az accountokkal, ha kompromittálódott a felhasználói fiók (azaz az usernév/jelszó páros kiszivárgott, pl feltört adatbázisokba) és ezekhez az anolimáliákhoz automatikus akciókat is lehet rendelni (pl. gyanús felhasználói bejelentkezés esetén legyen kötelező a multifaktoros hitelesítés). Elérhetővé válik a Smart Lockout szolgáltatás, ami a jelszótörő brute-force támadásokat megállítja. Az IP lockout service, ami észleli az ún. password spray-attack támadásokat és blokkolja azokat, miközben a valódi felhasználó továbbra is gond nélkül be tud jelentkezni a hálózatba.

Mondanom sem kell, ilyenhez hasonló földi védelmi rendszer ára (hardverek, licenszköltségek, speciális szoftverek) a csillagos égig érhet.

Összefoglalva: használjuk bátran a password hash szinkronizálás szolgáltatást, a kockázatot nem növeljük vele, és elérhető lesz sok magas szintű felhős védelmi megoldás.

Pajzsok fel!

A jó védekezés egyik alapvetése, hogy a támadási felületet csökkentjük. Ugyanez igaz az IT-ra is, érdemes minél kisebb teret hagyni a sebezhető pontoknak (másik megközelítés, hogy addig növelni a támadó ROI-ját, hogy inkább más célpontot keressen)

A klasszikus védelmi megoldásokat ismerjük, antivírus szoftver, tűzfal, nem látogatunk kétes oldalakat, stb. Sajnos ezek kevesek lehetnek, ha alkalmazásokon keresztül érkezik a fenyegetés.

Az alkalmazások tartalmazhatnak régi, elavult megoldásokat, amiket kártevők kihasználhatnak. Jellemző példa a makrók, amik nagyszerű eszközök, de rosszindulatú módon is bevethetők. Vagy mint lentebb láthatjuk, egy rosszindulatú-preparált Adobe PDF károkozása “megúszható”

A Microsoft Attack Surface Reduction (ASR) megoldásával az alkalmazásokat kihasználó támadások sikeresen megakadályozhatók.

Gyorsan elő a feketelevessel: csak Windows 10 Enterprise kiadással működik. Cserébe Intune-ból és SCCM-mel is kezelhető… 🙂

Az ASR segítségével letiltható, hogy Office és Adobe programok futtatható állományokat hozzanak létre vagy pl. WMI-n keresztül processeket indítsanak. Könnyen látható, hogy pár legitim eset kivételével ezek bizony kártékony viselkedésre utalhatnak, tehát blokkolandó. Emellett a scriptek (JavaScript, VBScript) működése is felügyelhető.

További szabályozható beállítások, csak felsorolás jelleggel:

  • Block executable content from email client and webmail: régi, de hasznos, levelezőklienssel ne lehessen futtatható állományokat megnyitni.
  • Block Office Communication Applications from Creating Child Processes: megakadályozza, hogy az Office-alkalmazások újabb processeket hozzanak létre. Ha szükség van rá, kivételként engedélyezhető, az alap a blokkolás.
  • Block Adobe Reader from Creating Child Processes: ó, a PDF-fileok, támadók kedvence. Sok sebezhetőséget tartalmaz, sok esetben lassan foltozzák a szoftvert a cégek, ráadásul a “PDF az PDF”, miért ne nyitnám meg? Itt jó szolgáltatot tehet a szabály, hogy egy PDF csak ne akarjon processeket indítgatni….
  • Use advanced protection against ransomware: egy plusz védelmi vonal, ha egy futtatható állomány kártevőre hajaz, letiltja futását, még akkor is, ha alapból engedélyezve van.
  • Block process creations originating from PSExec and WMI commands: psexec és wmi nem hozhat létre processeket. Ha SCCM-et használunk, ez NE állítsuk be, mert csúnyán belekavarhat az SCCM kliens működésébe.
  • Block untrusted and unsigned processes that run from USB: bár az usb használata csökkenőben, azért nem baj, ha egy pendriveon lévő, digitális aláíráson lévő állomány nem indulhat el közvetlenül.
  • Block credential stealing from the Windows local security authority subsystem: nem engedi, hogy külső alkalmazások jelszavakat vagy hash-eket szedjenek ki a memóriából.

A teljes szabálylista itt érhető el: https://docs.microsoft.com/hu-hu/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction

Az ASR bevezetésekor érdemes monitorozással kezdeni, hogy a későbbi blokkolás mit érintene (pl. pénzügy esetén makrók generálása stb). Az Audit mode-dal ezt alaposan meg tudjuk vizsgálni, kivételeket képezni. Ezután jöhet a Block mode, ami a fenti szabályok alapján már tiltást végez.

Windows 10 E5 vagy M365 E5 licensz birtokában megkapjuk a Microsoft Defender ATP szoftver is, amivel az ASR teljesen kompatibilis, az evvel kapcsolatos riasztások és policyk központilag kezelhetők. Az alábbi képen látható, hogy átlagos hétfői napon több mint 1800 ASR-block történt…

A fentiek fényében tehát nagyon ajánlott az ASR bevezetése, evvel is csökkentve a támadási felületet.

Pajzsok fel!