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

Annonser
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 GDRP 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

Microsoft Information Protection User Group

Intresset och framförallt behovet av lösningar för att detektera, klassificera och skydda känslig information är större än någonsin. Ju fler som nyttjar samma teknik underlättar också när information delas mellan organisationer. Här har det varit en rejäl ”ketchupeffekt” de senaste 2-3 åren om man jämför med de RMS införanden som jag själv utförde för 5-6 år sedan där det var förhållandevis få som nyttjade denna teknik för att skydda både dokument och e-post.

Det viktigaste vid ett införande av all typ av kryptering är också att man har ordentliga operation/förvaltnings -rutiner på plats och här är kompetens en nyckelfaktor.

För att öka kunskapen och dela erfarenheter har vi även startat upp en user group (användargrupp) i detta syfte. Plattformen för gruppen landade på Facebook och här är det fritt fram att gå med för de intresserade. Här kan du ställa frågor, dela dina erfarenheter och diskutera Microsofts olika tekniker för informationsskydd.

MIPUGLogga

https://www.facebook.com/groups/MicrosoftInformationProtection/

Publicerat i Azure Information protection, Informationssäkerhet, Microsoft Event, RMS | Lämna en kommentar

Modern hantering av Windows 10 med lokalt AD och hybrid Azure AD join

Azure Active Directory (AD) ger en helt annan intelligens och ger många fördelar för våra moderna Windows-enheter. Om Windows-enheten går med i ett Azure AD istället för ett traditionellt lokalt AD får vi med automatik efterfrågade funktioner exempelvis Windows Hello med en förenklad inloggning som skyddar våra autentiseringar och lösenordsåterställning direkt vid Windows-inloggningen.
clip_image002

En enhet kan idag inte gå med i både ett Azure AD och ett lokalt AD vilket gör att de flesta verksamheter inte kan nyttja alla Azure AD funktioner eftersom det oftast finns ett beroende till det lokala ADt.

Automatisk Hybrid Azure AD joined

Från Windows 10 version 1709 kom en lösning på det här med ett nytt koncept som kallas Hybrid Azure AD joined. Det hela bygger på att enheten går med i det lokala traditionella ADt och med automatik går även enheten med i Azure AD i det som kallas Hybrid Azure AD joined.

image

För att det här skall fungera behöver vi

  • Synkronisera även våra datorobjekt från vårat lokala AD till Azure AD med hjälp av Azure AD Connect
  • konfigurera det lokala Active Directoryt och peka ut vårat Azure AD med en så kallad Service Connection Point 
  • anpassa ADFS om detta används då det kräver ett antal nya claim rules

En guide som går igenom detta finns på docs

Efter att ovanstående konfiguration är korrekt utförd kommer Windows-enheter från version 1709 och framåt att bli hybrid joinade vid omstart eller inloggning.

Automatisk MDM registrering i Intune

Vi kan sedan fortsätta med automatiseringen där enheten också blir hanterad av Intune med automatik. Detta ger oss möjlighet att dels fortsätta använda klassiska Group Policies (GPO)s kombinerat med kraftfulla MDM policies som är ett krav för att kunna konfigurera viss funktionalitet i Windows 10, Exempelvis Windows Information Protection.

  • Automatisk registrering i Intune konfigureras via en GPO och här krävs det att dess ADMXer är uppdaterade för att få stöd för Windows 10 version 1709-inställningar. Uppdaterade ADMXer laddas ner här image
  • För att klienterna skall hitta fram till Intune behöver även följande CNAMES läggas in i för klienternas DNS
    EnterpriseEnrollment.<domain.com> EnterpriseEnrollment-s.manage.microsoft.com
    EnterpriseRegistration. <domain.com> EnterpriseRegistration.windows.net

När detta är konfigurerat kommer klienten nu även att registreras i Intune

image

Vi kan sedan börja hantera även dessa enheter och konfigurera allt ifrån skydd av organisationens information med Windows Information Protection till kraftfulla skydd mot Ransomware med Defender Exploit Guard

clip_image010

Publicerat i Windows 10 | Märkt , , | Lämna en kommentar

Anpassa Secure Email för din organisation

Secure Email är namnet på det nya sättet att dela skyddade email. Secure Email är i grunden en kombination av Rights Management Services (RMS) och OME (Office 365 Message Encryption). Den här tekniken löser tidigare problem med publika eposttjänster eller att mottagaren använder sig av en email-applikation som inte stödjer/förstår RMS.

Avsändaren (eller organisationens Exchange) skyddar ett email på samma sätt som tidigare och behöver inte bry sig om vem mottagaren är eller vilken applikation den använder.

Om mottagaren använder sig av en mailapplikation som förstår RMS, exempelvis Outlook eller dess webbgränssnitt visas mailet precis som övriga mail.

Om mottagaren där emot använder sig av en annan mailapplikation eller mailtjänst ligger det krypterade mailet som en bifogad (rpmsg) fil och istället visas följande information i mailet, med en länk till själva meddelandet.

image

Länken pekar egentligen till avsändarens Office 365 och den skyddade informationen redovisas för användaren utan att lämna Exchange.

Användaren kan välja att autentisera sig med sitt emailkonto (av typen Azure/Microsoft account, Google eller Yahoo) och skulle den möjligheten saknas finns även en möjlighet att logga in med en engångskod (OTP). Denna OTP levereras som ett ytterligare mail med automatik.

Om verksamheten vill förtydliga vem som skickat det skyddade meddelandet, tydligt visa mottagaren vem den autentiserar sig emot och vilken autentisering som tillåts finns även möjlighet att anpassa detta.

Mottagaren får istället ett mail som exempelvis ser ut enligt nedan:

image

I nästa steg får mottagaren välja om den vill autentisera sig med sitt Google-konto

image

Efter lyckad inloggning redovisas meddelandet

image

Anpassning

För att anpassa Secure Email används (som vanligt) PowerShell.

Kommandot ser ut enligt följande

Set-OMEConfiguration -Identity ”Ome Configuration” -EmailText ”<text>“ -BackgroundColor ”#00000” -PortalText ”<text>” -DisclaimerText ”<text>” -OTPEnabled $true -SocialIdSignIn $true -Image (Get-Content ”<image location>” –Encoding byte)

Parametrarna nedan redovisas för att förtydliga vad som är förändringsbart och vilken parameter som styr vad

· EmailText
· BackgroundColor
· PortalText
· DisclaimerText
· OTPEnabled
· SocialIdSignIn
· Image

image

image

Publicerat i Azure Information protection | Märkt , , | 1 kommentar