Traficom ohje: Suojautuminen Microsoft Office 365 tunnusten kalastelulta ja tietomurroilta

Traficom julkaisi kyseisen ohjeen 5.4.2019 jossa käydään kattavasti periaatteet miten voidaan ennaltaehkäistä Office 365 palveluun kohdistuvia tunnusten kalasteluilta sekä tietomurroilta. Ohje on tarkoitettu ylläpidosta ja tietoturvasta vastaaville henkilöille.Ohje

Luin itse kyseisen ohjeen viikonloppuna ja pidän ohjetta hyvänä perusohjeena jonka jokaisen ylläpitäjän/konsultin/arkkitehdin/CISO pitäisi lukea.

Ohjeessa on muutama virhe sekä vähän epäselvästi kirjoitettuja kohtia, eli vastuu lukijalla. Alla omat huomioni.

Kohta 2.2 Identiteetti: ADFS kuvaus: 

Käyttäjän kirjautuessa pilvipalveluun, hänet ohjataan on-premise ympäristön Active Directory Federation Service (AD FS) -palveluun. Tämä ratkaisu vaatii useimmiten vähintään neljän palvelimen (kaksi sisäverkkoon ja kaksi DMZ-vyöhykkeelle) käyttöönoton. Active Directoryn domain controller (valtuuttaja) -palvelimet tekevät todennuksen.

  • Huomioni: Vaatii 4 palvelinta jos halutaan tehdä HA ratkaisu, 2 ADFS palvelinta paikalliseen AD:n liitettynä sekä 2 Web Application Proxy palvelinta perimeter verkkoon, jotka voidaan liittää Active Directoryn jäseniksi, jos esim. Work folders ominaisuus halutaan käyttöön.

Kohta 2.5 Tietoturva-arkkitehtuuri:

2.5.png

Huomioni: Tiedon hakeminen sekä hallinnan rajoissa on virheellistä tietoa. Pitäisi olla seuraavaa

2.5_huomio.png

Kohta 3.11: Räätälöi sisäänkirjautumissivut organisaation graafisen ilmeen muikaseksi: 

Office 365 -palvelun sisäänkirjautumissivut voidaan räätälöidä organisaation graafisen ilmeen mukaisiksi. Samalla käyttäjät tottuvat niiden ulkonäköön ja näin kalastelun onnistuminen organisaation räätälöidystä kirjautumissivuista poikkeavalla ulkonäöllä vaikeutuu. Toisaalta käyttäjä ei voi ulkonäköön täysin luottaa, koska kalastelija on voinut tehdä väärennetystä sivusta täysin samannäköisen. Tällaisessakin tapauksessa väärennös saattaa paljastua osoiterivin ja varmenteen (sertifikaatin) tietojen perusteella.

  • Huomioni:  

    • Kirjautumissivujen kopiointi voidaan automatisoida eli vastapuolella voi olla ihan täysin samanlainen sivu kuin oikea kirjautumissivu, ja kuten tekstissä todetaan niin ei voida täysin luottaa graafiseen ilmeeseen.

    • Sertifikaatin lukon merkkiin ei voi ihan hirveästi luottaa enää koska jos koneen selaimen liikenne saadaan ohjattu esim. Modlishka reverse proxylle niin selain tarkistaa kyseisen proxyn sertifikaatin eikä kohteen. https://vimeo.com/328647131

    • Varmin Keino väärennöksen todentamiseen on katsomalla siihen osoiteriville ja tutkimalla sitä url osoitetta. Eli tämä pitäisi opettaa loppukäyttäjille.

Kohta 3.12: Suojaa salasanat: Jos käytössä on federoitu kirjautuminen, on syytä varmistaa, että käytössä on Extranet Lockout. Toiminto tuli saataville Windows Server 2012 R2 -versiossa ja on edelleen kehittynyt uudemmissa käyttöjärjestelmissä (Windows Server 2016 ja 2019)

  • Huomioni: Jos käytössä on federoitu kirjautuminen, on syytä varmistaa, että käytössä on Extranet Lockout. Toiminto tuli saataville Windows Server 2012 R2 -versiossa ja on edelleen kehittynyt uudemmissa käyttöjärjestelmissä Smart Lockout policy nimiseksi, mutta jos ADFS on otettu Extrane Lockout käyttöön niin tuo vanha politiikka joudutaan muuttamaan smart lockout politiikaksi.

Jarmo Haaranen