Följ upp ditt informationsskydd med ny AIP dashboard

Efter att ha infört en lösnings för informationsskydd är det viktigt att marknadsföra den internt inom verksamheten på ett lämpligt sätt. Dels för att stötta användarna med vilken typ av information som är skyddsvärd men framför allt också för att de skall veta om att det finns en lösning som de kan använda för att skydda det som de själva anser relevant.

Steget därpå handlar om att följa upp och se hur stor del av verksamheten som faktiskt använder lösningen samt hur den används. Dels för att avgöra om det behövs någon uppföljning inom information och kunskapsöverföring till slutanvändarna och dels för att se att den faktiskt används.

Azure Information Protection släpper nu en ny dashboard för dels det här ändamålet men även för att identifiera vilken kritisk information som inte är klassificerad/skyddad.

Den nya Usage report delen ger en översikt och analys under senaste månaden, kvartalet eller halvåret över hur många:

· filer är klassificerade
· filer är skyddade
· användare är det som klassificerat/skyddat filer
· många enheter har klassificerat/skyddat filer

Vi kan få en djupare analys över vilka informationsklassifikationer (Labels) som används och fördelningen mellan dessa. Även hur fördelningen ser ut mellan filtyper/applikationer listas för att tydliggöra statistiken över vilka filer som skyddas och kan innehålla känslig information.

2018-09-03 10_42_13-Window

Används exempelvis en standard-label eller någon annan label man vill exkludera från statistiken går det enkelt att exkludera den för att få en bättre insikt

image

Finns det behov av fler detaljer, har vi möjlighet att göra mer avancerade sökningar för att identifiera allt ifrån specifika informationstyper så som person/konto-nummer, användare till specifika dokument och filer.

Här kan vi dels söka, genom att markera de uppgifter vi önskar, och filtrera på de värden vi efterfrågar. Resultatet kan sedan exporteras för att exempelvis analyseras vidare med Power BI både i molnet eller via en lokal installation (Power BI desktop).¨

clip_image001

Identifiera risker med oskyddad känslig information.

Om AIP Scannern används för att söka igenom lokala filservrar och SharePoints redovisas även dess resultat under Data discovery.

Här får du en tydlig överblick och kan välja att till exempel filtrera på ett visst file share och se både vilka filer som är klassificerade/skyddade men också vilka filer som innehåller känslig information men saknar skydd.

2018-09-12 11_38_50-

Tack vare den nya dashboarden blir det enkelt att följa upp så fort nya filer innehållande känslig information sparas till ett lokalt file share och hur stor del av verksamhetens information som är både klassificerad och skyddad.

(Än så länge är den nya Dashboarden enbart i Preview och den bygger även på att klienterna (och AIP Scannern) använder den senaste preview versionen av AIP klienten från version 1.38 och framåt.)

Annonser
Publicerat i Azure Information protection, Informationssäkerhet, Microsoft Information Protection | Märkt | Lämna en kommentar

Bättre och säkrare lösenord i ditt AAD/AD

Även om Microsoft och många andra har kommit väldigt långt att med olika tekniker komma ifrån lösenordsinloggning kommer vi nog ha klassiska lösenord kvar ett antal år till.

Lösenord är dock något som de flesta användarna tycker är krångligt, tråkigt och mest av allt något onödigt ont som man bara måste ta sig igenom. Majoriteten av våra användare lägger nog ingen större vikt av att lösenordet Sommar2018! är ett svagt lösenord, bara de lyckas komma igenom alla svåra lösenordpolicys och sätta ett godkänt lösenord.

Som tur är har vi genom åren lärt oss mycket om lösenord och vilka krav som faktiskt höjer säkerheten på våra lösenord. Vi har även lärt oss vilka lösenordpolicys som faktiskt riskerar att sänka säkerheten på lösenord.

Klassiskt tänk som att vi bör byta vårat lösenord med jämna mellanrum har nu ersatts av att vi bör sätta ett lösenord vi kan och kommer ihåg utan några krav på att byta detta såvida det inte blivit läckt/knäckt.

Det vi har lärt oss av detta är ett kontinuerligt krav på lösenordsbyte ofta resulterar i att man lägger till och ändrar några siffror och specialtecken i samma lösenord. Exempelvis ”Sommar2017” enbart byts mot ”Sommar2018” eller kanske ”Sommar2018!” Det här är något som även är känd av de som gör intrång och om vi tittar på attackerna de senaste åren har det skett en klar ökning av så kallade spray attacks. Dessa går ut på att man bygger upp en lista på de vanligaste förekommande lösenorden exempelvis ”Password” med alla dess varianter ”P@$$w0rd!” och så vidare. För att ta sig runt lock out policys och andra skydd testar med dessa lösenord mot alla identifierade användarkonton på ett företag.
Det räcker då att ett användarkonto eller värsta fall ett administrator-konto har ett lösenord som man tidigare trodde var starkt, ex. “P@$$w0rd!” eller  “$0mM@r!” blir knäckt, så riskerar man ett fulländat intrång.

Som tur är, är det inte bara the bad guys som blir duktigare och mer erfarna. Microsoft lägger enormt mycket resurser på att identifiera hur attacker går till för att lära sig att bygga allt bättre skydd mot de rådande attackerna.

Det senaste runt lösenordsskydd är Password Protection som är en funktion i Azure Active Directory som ökar skyddet både i Azure Active Directory och lokala Active Directoryt.

Tjänsten består av flera skydd för att öka lösenordssäkerheten och blockera intrång baserat på lösenordsförsök.

Det ingår dels en lista med de vanligaste lösenorden så kallade banned password list. Denna lista är i skrivande stund snart uppe i 1000 lösenord. Alla olika kombinationer av dessa lösenord blockeras också, vilket gör att flera miljoner lösenord kommer blockeras.

Då lösenord ofta innehåller namnet på företaget, den lokala orten med mera kan man även komplettera den här listan och ange lösenord som ofta förekommer i sin egen organisation och som kan vara lätt även för den som attackerar organisationen att identifiera. Även olika kombinationer av dessa lösenord kommer blockeras som i exemplet nedan för företaget MSSEC och Company

  • Mssec, mssec2018!, M$$3C…
  • Company, company2017?, c0mMp@ny

Eller varför inte “Sommar”, “Vinter” m.m. om det är något som kanske tidigare användes av Service Desk när de återställde lösenord

clip_image001[4]

För att även lösenord som sätts eller byts i det lokala Active Directory:t skall få samma skydd finns en proxy och agent som installeras lokalt och knyts med våra domänkontrollanter. Dessa hämtar och applicerar samma inställningar som vi konfigurerat i vårat Azure AD.

clip_image001[6]

Det här resulterar i att när en användare försöker sätta någon av dessa lösenordskombinationer kommer detta att blockeras.

Både om användaren försöker sätta ett lösenord från listan i det lokala ADt som i exemplet nedan

clip_image001[8] clip_image001[10]

Alternativt om användaren ändra det via självbetjäningsportalen i Azure AD

clip_image001[12] clip_image001[14]

Förutom att Password Protection motverkar att vanliga lösenord konfigurerats innehåller den även en funktion, så kallad Smart lockout för att blockera lösenordsintrång utan att låsa ut den faktiska användaren.

Om det pågår inloggningsförsök som enligt avancerade algoritmer tolkas som intrångsförsök kommer dessa inloggningar att stoppas med den riktiga användaren kan fortsätta jobba helt ostört.

Den här funktionen har funnits i Azure AD en längre tid oavsett licensform, men tack vare det nya gränssnittet med Custom smart lockout kan vi nu även anpassa skyddet och konfigurera känsligheten för sin egen organisation.

Detta gör att Password Protection både stöttar dina användare att sätta bättre och säkrare lösenord som inte är lika lätta att gissa sig fram till, samtidigt som den blockerar felaktiga inloggningsförsök utan att störa användaren.

Publicerat i Azure Active Directory | Märkt , , | Lämna en kommentar

Identifiera ett Secure Email-phishing försök

Tyvärr fortsätter phishing mail att öka och de blir allt duktigare på att kopiera officiella mailtjänster och utskick i ett ständigt försök att få mottagaren att klicka på en bifogad länk, och i många fall även få mottagaren att ange sitt användarnamn och lösenord.

Det har nu kommit phishing mail som försöker efterlikna Microsoft Secure Email / Office 365 Message Encryption vilket i flera fall har varit så gott som identiska med standardgränssnittet.

Jag vill med den här artikeln påvisa hur man kan särskilja på ett phishing mail och ett äkta Secure Email.

Phishing mail

Ett exempel på ett phishing mail där det är två väsentliga fel:

  1. När du håller musen över ”Read the Message” -länken ser du att den inte pekar inte på ”outlook.office365.com”
  2. Avsändaradressen som även skall redovisas i meddelandet matchar inte avsändaradressen

clip_image001

Ett äkta Secure Email

  1. ”Read the message”-länken pekar på outlook.office365.com
  2. Avsändaradressen är både korrekt och matchar avsändaradress i meddelandet

clip_image002

Ett äkta anpassat Secure Email

De bilder och text i ett Secure Email som beskrivs i denna artikel kan bytas ut. Här är det viktigt att informera och utbilda interna användare om organisationens design, både för interna användares skull, men även för att de skall kunna stötta externa mottagare och ha vetskap om upplevelsen när de skyddar epost externt.

Oavsett anpassad design skall motsvarande länk och avsändaradresser matcha enligt exemplet nedan.

clip_image003

Tekniskt skydd mot Phishing mail

Det är väldigt viktigt att oavsett tekniska skyddslösningar även utbilda slutanvändare att vara vaksamma på denna typ av hot.

Ett bra skydd mot bland annat phishing är Office 365 Advanced Threat Protection (ATP). Dess ATP Safe Link Protection funktion genomsöker och ersätter alla inkluderade länkar (bland annat för att skydda mot DNS-ompekningar som används för att i efterhand styra användaren till en skadlig websida)

Även om den här typen av lösning oftast stoppar användaren att komma till en skadlig websida går det att utläsa om det är ett phishing mail som i exemplet nedan:

clip_image004

Läs mer om hur Secure Email fungerar och i vilka scenarion som ett skyddad mail redovisas enligt ovan

Publicerat i Azure Information protection | Märkt , | 3 kommentarer

Nyheter i Secure Email och dess funktionalitet

Microsoft har kommit långt i sin resa att skydda epost och Office dokument utan att ställa några motkrav på mottagaren. Lösningen gör det enklare för våra svenska företag och myndigheter att möta de nya GDPR lagarna.

Historiskt sett har det varit stora utmaningar att nyttja Rights Management Services (RMS) för att skydda epost-meddelanden och andra filer till externa användare utanför sin egen organisation.

I ett RMS-scenario krävs följande för att kunna läsa något som är skyddat av denna lösning:

  1. Ett konto som kan autentisera sig mot avsändarens Azure Active Directory (eller Active Directory i ett AD RMS scenario)
  2. En applikation som stödjer RMS i form av dekryptering och applicering av de begränsade rättigheterna som definieras vid kryptering (Ex begränsa utskrift, kopiering eller vidarebefordring av epost)

Secure Email är en lösning från Microsoft som automatiskt tillämpas om någon av de två övre kraven inte uppfylls. Lösningen gör det möjligt att skydda oavsett vem mottagaren är och tillåter även att innehållet visas via en webbläsare och ställer därmed inga krav på övriga applikationer. Secure Email bygger på klassiska RMS och det som tidigare kallades för Outlook Message Encryption (OME). Med OME får mottagaren tillgång till informationen genom en inloggning mot avsändarens Office 365 –webbgränssnitt. Det här scenariot resulterar i att ingen oskyddad information lämnar avsändarens organisation.

I följande exemplet går jag igenom de senaste nyheterna inom Secure Email och mottagarens upplevelse om de uppfyller kraven eller inte:

Skydda och skicka Epost-meddelande

– Användaren kan skydda ett epostmeddelande och välja om mottagaren skall ha fulla rättigheter (Encrypt) eller om mottagaren skall vara begränsad att vidarebefordra, kopiera, skriva ut eller på annat sätt sprida innehållet (Do Not Forward).
(I nuläget finns bara alternativet ”Encrypt” via webbgränssnittet till Exchange (OWA). Funktionen kommer via AIP klienten framöver även till lokalt installerade Outlook som idag bara har ”Do not Forward”-alternativet)
Är ett Office dokument bifogat kommer även detta krypteras med motsvarande rättigheter

clip_image001

Alternativ 1: Mottagare som uppfyller kraven

– Mottagare som har exempelvis Office 365 och därmed både konto i Azure AD och Applikationer som förstår RMS.

Alla supporterade Office-versioner har idag inbyggt stöd för RMS.
Där emot är alternativet Encrypt en helt ny standard där stödet nyligen släpptes till Office Version 1804 (Build 9226.xxxx).

clip_image002

Äldre Office versioner kommer inte få stöd utan supporterar enbart Do Not Forward som funnits i snart 15 år.
Om en äldre Office/Outlook version används kommer ett epostmeddelande skyddat med Encrypt att visas på samma sätt som exemplet nedan då applikationen inte kan tolka den här RMS-rättigheten.

Alternativ 2: Mottagare som inte uppfyller kraven

Mottagare som varken har konto hos Microsoft eller applikationer som förstår RMS, i detta fall ett gmail-konto.

image

För att logga in mot Office 365 har en gmail-användare möjlighet att autentisera sig direkt med sitt Googlekonto då Microsoft federerar med Google och flera andra leverantörer.

Saknas den här möjligheten finns det alltid ett alternativ att istället logga in med en engångskod (OTP)

clip_image007

En OTP kod skickas då till samma mottagare

clip_image009 clip_image011

Efter lyckad autentisering kommer Office IRM dekryptera och visa både mailet och den bifogade Officefilen via webbläsaren

clip_image013

I båda alternativen är det fortfarande RMS som nyttjas för kryptering/dekryptering och i alternativ 2 tillsammans med det som kallas för Office IRM. I alternativ 1 när det är en lokalt installerad programvara som dekrypterar innehållet används det som kallas för Client-Side-decryption där RMS dekrypteringen sker lokalt. Office IRM i Alternativ 2 gör att tjänster så som Exchange, SharePoint och Office Online krypterar/dekrypterar innehållet åt användaren, så kallad Server-Side-Encryption/decryption.

Varje RMS-krypterad fil har även en okrypterad text som redovisas om applikationen inte förstår RMS. I Secure Email är detta texten som länkar till Office 365 där vi även ser att det krypterade mailet ligger bifogad. Den här texten kan även anpassas vilket jag tidigare beskrivit här https://itsakerhetsguiden.se/2017/11/17/anpassa-secure-email-fr-din-organisation/

Publicerat i Azure Information protection | Märkt , | Lämna en kommentar

Identifiera och förhindra att känslig information sprids via molntjänster med CAS

Microsoft Cloud App Security (CAS) har flera syften. Den har dels en viktig del för att få en bild över vilka molntjänster som verksamhetens användare nyttjar. Den har även en integration med Azure Information Protection för att detektera känslig information och applicera skydd.

Jag kommer med den här artikeln påvisa ett konkret exempel på hur CAS kan stötta verksamheten genom att både identifiera och förhindra känslig information som sparas och delas via molntjänster.

Känslig information delas via molntjänst

Förutom att skydda känslig information är det viktigt att ha en informationsklassifikation som inte stoppar verksamheten.

Om vi t.ex. automatiskt klassificerar eller ger användarna möjlighet att klassificera något som ”Confidential Unprotected” för att klassificera informationen utan att begränsa dess behörighet kan det komma tillfällen vi ändå vill ta åtgärd på filen.

Exemplet här rör när en användare delar filen externt utanför bolaget via en molntjänst i det här fallet OneDrive for Business. Här har vi nu möjlighet att både identifiera och ta åtgärd just på detta.

image

Identifiera och larma

Cloud App Security (CAS) kan integrerar med bland annat Office 365 inom samma tenant.

Med hjälp av CAS kan vi skapa en policy som t.ex. larmar om en fil klassificerad som Confidential men oskyddad delas med någon utanför bolaget

image

Det här resulterar i att administratörerna dels kan få ett larm av denna händelse och redogörelse i CAS över vem/vilka filen delas med

image

Via CAS får administratören mer information och får även möjlighet att vidta en åtgärd på detta larm

image

Manuell åtgärd

Exempelvis kan vi applicera ett skydd på filen genom att byta till en AIP Label som även krypterar filen (till fördefinierade användare) och på så sätt styra exakt vem/vilka som har behörighet till filen

image

image

Automatiserat skydd

Om administratören inser att det är idé att automatisera ovanstående åtgärd vid denna händelse kan vi också välja att skapa åtgärdspolicy baserat på detta larm som utför samma åtgärd

image

Åtgärden ser till att CAS automatiskt kommer skydda filen när den delas externt och vi kan avgöra var och när det här skall ske

image

Resultat

Det här kommer resultera i att oavsett vem som filen delats med kommer enbart de som är definierade i vår Information Protection Policy att nå filen

Samma skydd på övriga molntjänster

Idag fungerar ovanstående scenario för SharePoint Online, OneDrive for Business, Box och G Suite

Fler tjänster kommer få samma möjlighet och framöver kommer vi kunna använda Conditional Acess för att inspektera sessioner via publicerade molntjänster via Azure Application Proxy.

image

Publicerat i Azure Information protection | Märkt | Lämna en kommentar

Azure Advanced Threat Protection

Microsoft har från den 1:a mars lanserat sin Advanced Threat Analytics (ATA)-lösning som en molntjänst, kallad Azure Advanced Threat Protection. Vad innebär då detta?

ATAn har till syfte att detektera och larma om intrång i vårat lokala AD. Verktyget bygger på att ATA samlar in och analyserar på portnivå allt som når våra domänkontrollantera för att på så sätt identifiera intrång. Detta kräver rejält med prestanda av den lokala lösningen.

Vi har även Defender Advanced Threat Protection (ATP) som har till syfte att identifiera och även blockera intrång på våra klientdatorer med hjälp av bl.a. analys av allt som händer på enheten. Defender ATP nyttjar Microsofts Threat intelligence tjänst i molnet med bl.a. reputation-kontroll av allt ifrån filhashar till IP-adresser och URLer som klienter kommunicerar med.

Vad ger då Azure Advanced Threat Protection?
Dels tar den över ATAns roll och monitorerar våra DCs med hjälp av små enkla sensorer som då inte kräver att vi behöver investera i ny hårdvara.
Den integrerar också med Defender ATP för att på så sätt kunna samköra systemen och då detektera intrång både i vår lokala miljö men också i våra klienter oavsett var Windowsenheten är ansluten.

image

Med tanke på att Defender ATP numera är extremt kraftfullt och kan ta åtgärder som att sätta klienten i karantän vid säkerhetsincidenter. Nu kan vi även få in information från Azure ATP för att identifiera fler risker. På samma sätt kan vi identifiera risker på klienter för att motverka att attackerna fortsätter när klienten väl ansluter sig till det lokala AD:t.

image

image

ATA som produkt kommer finnas kvar för de som vill köra detta lokalt. Dessvärre kommer inte integrationen med Defender ATP och Office ATP till den lokala ATA-lösningen.

Namnskillnaden där den lokala ATA-lösningen är mer “Analytics” för att detektera och larma om intrång medan ATP-som molntjänst även har “Protection” för att att ta åtgärd på dess larm.

Läs mer om Azure ATP:
Microsofts EM+S Blog
Microsoft Docs

Publicerat i Advanced Threat Analytics, Endpoint Protection | Märkt | Lämna en kommentar

Skydda alla filtyper till ALLA mottagare

Microsoft har sedan de började leverera sin RMS-lösning som en tjänst i Azure haft som vision att bland annat kunna skydda alla filtyper (jämfört med enbart Office filer som var begränsningen tidigare) till alla typer av mottagare. Alla filtyper var något som blev löst ganska omgående men där emot har det varit en del begränsningar när det kommer till att skydda oavsett mottagare.

Tack vare Azure AD/Office 365 fick man direkt en lösning att skydda mellan organisationer och tack vare konceptet ”RMS for individuals” kan användare som inte tillhör en organisation som använder sig av Azure AD/Office 365 registrera sig kostnadsfritt för denna tjänst.

Begränsningen har varit när det kommer till publika domäner och epostleverantörer så som gmail, hotmail, telia, med mera. I det här fallet har vi tusentals domäner som varit begränsade att kunna nyttja denna lösning. Jag kan personligen argumentera för att denna begränsningen även har kunnat rättfärdigas av att ID-kontrollen av att skapa ett organisationskonto generellt är bra mycket högre än ett att skapa ett publikt epostkonto som oftast kan genomföras av vem som helst mer eller mindre anonymt.

Begränsningen har dock varit ett problem för många verksamheter då behovet ändå har funnits att skydda även till vissa konton som nyttjar dessa publika mailtjänster.

Tack vare den tjänst som idag heter Secure Email och går även under namnet Office 365 Message Encryption version 2 (OMEv2) har vi sedan en tid tillbaka kunnat skydda både mail och även bifogade Officefiler även till publika mailtjänster. Lösningen bygger på att mottagaren i själva verket loggar in mot avsändarens Office 365 -miljö för att både läsa mailet via Outlook online och bifogade filer via Office online. Idag kan vi dock inte skydda en fil exempelvis via Office eller AIP klienten till en publik adress och mottagaren kan inte ladda ner en bifogad fil och konsumera utanför webbgränssnittet.

Nuvarande AIP client blockerar idag möjligheten att skydda till en publik mailadress:image

Konceptet med RMS for individuals är dock på väg att ändras för att lösa detta och det kommer fungera enligt följande:

  1. Om mottagaren har en organisationsadress som saknas i Azure AD kommer dess domän att skapas i Azure och användarkontot kommer registreras.
  2. I det scenarion som inte ovanstående fungerar exempelvis om mottagaren har en publik mailtjänst kommer det inom kort generera ett Microsoft Account (MSA) account med samma namn som den publika mailadressen.

På det här sättet kommer Microsoft i mål med sin vision. Lösningen kommer att kunna skydda till alla typer av mottagare. Precis som tidigare kommer det inte vara någon kostnad kopplad till att registrera sig för den här tjänsten, som då tillåter oavsett mottagare att kunna konsumera skyddad information oavsett filtyp.

Om vi tittar i Preview versionen av kommande AIP client kan vi redan nu skydda en fil till ett publikt konto.

2018-03-06 10_07_38-Sheldon on ONEVINNANDERSX1 - Virtual Machine Connection

2018-03-06 10_08_30-Sheldon on ONEVINNANDERSX1 - Virtual Machine Connection

Mer information om RMS for individuals från Microsoft TechX 2015 https://youtu.be/6uAa9eRcDtQ?t=718 

Mer om Secure Email:

https://itsakerhetsguiden.se/2017/10/27/skydda-gdrp-information-aven-till-publika-mailtjanster/

https://itsakerhetsguiden.se/2017/11/17/anpassa-secure-email-fr-din-organisation/

Publicerat i Azure Information protection | Lämna en kommentar