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

Annonser
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

Identifiera och skydda befintlig information

Vid införande av en lösning för att skydda känslig information är det vanligt att man fokuserar på att skydda ny information vid skapande. Men vad gäller då med all lokal befintlig information och hur detekterar man vilken befintlig information som faktiskt är skyddsvärd?

När det kommer till klassiska RMS/IRM har vi i över 10 års tid kunna applicera skydd på:

Filservrar
Med hjälp av Windows Server rollen File Classification Infrastructure (FCI) som då baserat på mappnivå eller innehåll kan applicera skydd av befintliga filer. Till en början rörde det sig enbart om Officedokument men sedan en tid tillbaka har vi möjlighet att skydda oavsett filtyp.

SharePoint
Information Rights Management (IRM) i SharePoint nyttjar RMS för att applicera skydd på Office-dokument/pdf som öppnas eller delas från SharePoint. IRM appliceras per bibliotek och kan på så sätt bli en utmaning att i efterhand kunna avgöra vilka bibliotek som innehåller skyddsvärda dokument i en större SharePoint-farm.

Vi saknar idag möjlighet att klassificera filer med ovanstående lokala lösningar och det krävs att filservern kör Windows Server.

Azure Information Protection Scanner

Azure Information Protection (AIP) Scanner är en lösning för lokalt sparade filer. Om vi tänker oss att vi nyttjar Office 365 DLP system, för att utföra åtgärder på den metadata den kan identifiera och utföra åtgärder på. Exempelvis person och id-nummer i ett GDPR scenario på information som vi lagrar och hanterar via Office 365.  Oavsett om vi använder Office 365 eller inte finns oftast motsvarande behov även lokalt.
AIP Scannern identifierar, klassificerar och skyddar filer som är sparade lokalt. AIP Scannern nyttjar de labels och regler som vi redan definierats i Azure Information Protection.

AIP Scannern kan söka igenom både lokala SharePoint/OneDrive servrar och CIFS filytor (både Windows File shares och NAS) för att antingen enbart identifiera eller även applicera klassificering/skydd av dokument.

Komponenterna som krävs följer med vid installation av AIP klienten (aka.ms/aipclient) och både installeras och konfigureras via PowerShell.

För att ge en tydlig bild av dess syfte och funktion följer här ett exempel.

Exempel av AIP Scanner

I mitt exempel använder vi följande AIP regler:

  • en standard informationsklassning kallad ”Business” för alla dokument och mail som skapas. Informationen klassificeras utan att applicera något skydd. image
  • en regel som identifierar filer med svenskt personnummer och då klassificerar som ”Secret” och applicerar ett skydd så enbart interna användare når dessa filer och begränsar rättigheter till spridning i form av kopiering eller utskrift.image

Vi söker igenom både en lokal filserver och en lokal SharePoint/OneDrive.

Vi kan välja att ignorera redan klassificerade filer eller som i mitt exempel bortse från tidigare klassificering med målsättning att applicera ett korrekt skydd även om en användare klassificerat en fil felaktigt. Detta förutsätter också att AIP Scannern körs med ett konto som “Super User” för att på så sätt kunna dekryptera och inventera även befintligt skyddade filer.

clip_image002

Filytorna ser innan scanning ut enligt följande med både Office dokument och andra filtyper:

SharePoint:clip_image003

File share:clip_image004

AIP Scannern kan köras i två olika lägen:

  • enbart inventera och få en översikt över bland annat hur många filer som är klassificerade/skyddade samt innehåller känsliga uppgifter så som personnummer
  • påtvinga klassificering och skydd baserat på dess innehåll

Vi kan också välja att schemalägga scannern eller som i nedanstående fall göra en manuell engångsskörning

clip_image005

Efter AIP Scannern är konfigurerad kan tjänsten startas med ovanstående kommando och när tjänsten har gått färdigt finns en rapport över körningen.

Rapporterna skapas som en kommaseparerad fil (csv) och kan exempelvis importeras till Excel som i mitt fall nedan. Det framgår tydligt vilka filer som förändrats, vad de hade för informationsklassificering (label) sedan innan, samt hur filerna har förändrats och baserat på vad.

clip_image006

Filytorna ser nu ut enligt följande där den uppmärksamme även kan se på filernas något ökade storlek att de krypterats. Både Officefiler och övriga filtyper har klassificerats och krypterats både på filservern och SharePoint vilket inte varit möjligt i SharePoint tidigare.

SharePoint och exempel på en skyddad txt-fil och dokument som innehåller ett personnummer:clip_image008

File share med exempel på två PowerPointfiler med olika klassificeringar och skydd baserat på dess innehåll:clip_image007

En rekommendation är att enbart inventera och att även genomföra några tester med förändring mot en icke produktionsyta till en början. När resultatet är enligt förväntan genomför en engångskörning och vid behov schemalägg sedan denna mot skarpa lagringsytor.

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

Onevinns AIP File viewer

En utmaning kan vara att få en översikt över vilka filer som är skyddade av AIP/RMS. Via filutforskaren i Windows kan vi baserat på filformat identifiera detta baserat på filändelse sålänge det inte är en Office-fil eller PDF skyddad via SharePoint/OneDrive IRM. I det fallet som Office eller IRM applicerat skyddet förändras nämligen inte filformatet. Detta gör det svårt då det oftast är just Office dokument och PDFer som innehåller känslig information. Enda sättet att få informationen är att öppna respektive fil.

Vi har därför satt oss ner med våra utvecklare på Onevinn med Vanja Ferhatovic i spetsen och utformat en applikation i detta syfte.

Applikationen kan idag:

  • Inventera valfri NTFS sökväg, både lokalt och anslutna nätverksdelningar
  • Realtidsvy över vilka filer som är RMS-krypterade och vilken Informationsklass de har
  • Översikt över vilka rättigheter den specifika användaren har på filen
  • Översikt över vilka filer som INTE är krypterade
  • Möjlighet att skydda oavsett filtyp direkt från applikationen
  • Direktlänk till respektive track/revoke -portal för att övervaka och dra tillbaka tillgång för delade filer

För de användare som ofta är på resande fot eller på annat sätt behöver kunna jobba utan tillgång till Internet finns det ett behov att kunna se om det finns en sparad licens för den aktuella filen och hur länge denna licens är giltig. I RMS/AIP världen kallas detta för ”use license” och baseras på om och hur lång cache som filen skyddats med.

Kommande funktioner:

  • verifiera om det finns en giltig licens för respektive fil som gör det möjligt att öppna filen offline och hur länge aktuell cache/licens är giltig
  • Förnya licensen (baserat på om applicerad policy tillåter detta) på den aktuella enheten

Är du intresserad av den här applikationen och/eller har fler idéer på funktioner är det välkommet att höra av sig?

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