Hantering av mobila enheter: konfiguration och bevis

Enhetshantering stöder säkerheten endast för de enheter och inställningar den faktiskt omfattar. En MDM-panel som visar regelefterlevande enheter behöver en andra fråga: vilka enheter saknas? Därefter följer en tredje fråga: beskriver ”efterlevande” en effektiv konfiguration, eller bara en policy som har tilldelats en ändpunkt?

För en CTO handlar uppgiften om att göra svaren reproducerbara. Hantering av mobila enheter (MDM) bör koppla ihop enhetsägarskap, konfiguration, applikationsåtkomst, incidenthantering och underlag. Målet är inte en grön instrumentpanel. Det är en försvarbar redogörelse för vilka ändpunkter som kan komma åt verksamhetens information, hur de skyddas och vad som händer när skyddet fallerar.

Vad MDM kontrollerar och vad det inte kontrollerar

Hantering av mobila enheter innebär att ändpunkter administreras via en central tjänst och de hanteringsmekanismer som plattformen stöder. Beroende på produkt, operativsystem och registreringsläge kan MDM driftsätta konfigurationsprofiler, distribuera applikationer, rapportera enhetens tillstånd, begränsa utvalda funktioner och skicka fjärrkommandon. Bredare produkter för ändpunktshantering kan omfatta bärbara och stationära datorer vid sidan av telefoner och surfplattor.

Funktionerna är inte enhetliga. En fullt hanterad företagstelefon och en privatägd telefon med en hanterad arbetsprofil exponerar olika kontroller och telemetri. Vissa plattformar använder inbyggda hanteringstjänster; andra kräver ytterligare agenter. Varken ständig anslutning eller omedelbart utförande bör tas för givet.

MDM ersätter inte heller identitetshantering, ändpunktsdetektering, sårbarhetshantering eller informationsklassificering. MDM kan konfigurera dessa kontroller eller förse dem med signaler, men deras funktion behöver verifieras separat. En hanterad enhet kan ändå ha för omfattande applikationsbehörigheter, en session som inte återkallats eller en sårbar applikation.

Definiera kontrollpåståendet innan ni väljer inställningar. Till exempel: ”Företagets bärbara datorer som har åtkomst till administrationsmiljön för produktion måste vara registrerade, krypterade, ha ett operativsystem som stöds och ha bedömts nyligen.” Påståendet identifierar en population, en resurs och observerbara villkor. ”Alla enheter är säkra” gör det inte.

Koppla ändpunktshanteringen till ISMS

ISO/IEC 27001 avser ett avgränsat ledningssystem för informationssäkerhet, inte inköpet av ett visst verktyg för ändpunkter. Avsnitt 4–10 fastställer kraven på ledningssystemet. Bilaga A innehåller en referensuppsättning med 93 kontroller vars tillämplighet prövas genom riskbedömning och riskbehandling; den är ingen universell checklista för MDM-konfiguration.

Uttalandet om tillämplighet (Statement of Applicability) dokumenterar nödvändiga kontroller, motivering för att ta med dem, genomförandestatus och motivering för att utesluta kontroller i bilaga A. En MDM-driftsättning utgör en del av genomförandet och underlagen för relevanta kontroller, snarare än att bevisa hela ISMS:et.

Användbara kopplingar är bland annat:

Kopplingarna beskriver bidrag, inte likvärdighet. Att till exempel driftsätta en inloggningskonfiguration visar inte att privilegierad åtkomst har godkänts på lämpligt sätt. Använd vår guide till bilaga A för att koppla åtgärder för ändpunkter till det bredare ISMS:et i stället för att behandla enheters efterlevnad som ett isolerat värde.

Definiera populationen innan ni mäter efterlevnad

Börja med enheter som lagrar, bearbetar eller har åtkomst till information inom ISMS:ets omfattning. Ta med företagsägd och privatägd utrustning, konsulters ändpunkter, delade enheter och tillfälliga låneenheter där det är relevant. Kom överens om vilka operativsystem som stöds, registreringsregler och gränser för integriteten.

Bygg förteckningen kring stabila identifierare i stället för enbart visningsnamn. Användbara fält är tillgångsidentifierare, hanteringsidentifierare, tilldelad användare, ägarskap, plattform, registreringsläge, affärsändamål, registreringsdatum, senaste kontakt och status för avveckling. Dokumentera uttryckligen vem som ansvarar för delade enheter.

Stäm av MDM-förteckningen mot oberoende källor. Inköpsunderlag för tillgångar avslöjar utrustning som aldrig registrerats. Inloggningsloggar från identitetstjänsten och loggar över applikationsåtkomst kan avslöja ändpunkter som saknas i hanteringen. Uppgifter från ändpunktsskyddet kan visa dubbla agenter eller enheter som hanteras någon annanstans. Kontrollera vilka identifierare varje källa faktiskt tillhandahåller innan ni försöker koppla ihop dem.

Klassificera avvikelser i stället för att tyst utesluta dem:

• Inom omfattningen och registrerad: bedöm konfiguration och aktualitet.
• Inom omfattningen men ohanterad: registrera, begränsa åtkomsten eller godkänn ett avgränsat undantag.
• Avvecklad men fortfarande aktiv: utred och återkalla kvarvarande åtkomst.
• Dubblett eller ominstallerad: stäm av posterna utan att förlora historiska underlag.
• Utanför omfattningen: dokumentera skälet och den gräns som förhindrar relevant åtkomst.

Nämnaren spelar roll. ”98 % efterlevnad” bland registrerade enheter kan dölja en betydande ohanterad population. Rapportera täckning separat från konfigurationsefterlevnad och spara datumet för avstämningen och olösta poster.

Bygg en baslinje som går att testa

En baslinje för ändpunkter bör översätta riskbeslut till inställningar och verifieringskriterier. Den bör skilja mellan plattformar och ägarmodeller i stället för att låtsas att varje inställning fungerar överallt.

Följande är en praktisk utgångspunkt, inte en universell checklista som föreskrivs i lag eller av ISO:

Definiera vad ”okänt” betyder. En ändpunkt som inte har rapporterat sin krypteringsstatus är inte bevisat krypterad. Behandla saknad eller inaktuell telemetri som ett separat tillstånd med en tydlig åtgärd, i stället för att omvandla det till godkänt.

Uppdateringsfönster bör spegla sårbarhetens allvarlighetsgrad, exponering, tillgängliga riskreducerande åtgärder och operativa begränsningar. Dokumentera hanteringen i akuta fall för sårbarheter som aktivt utnyttjas och en process för uppdateringar som förstör nödvändiga applikationer. MDM-rapporter om driftsättning hjälper till att fastställa installationsstatus; de förklarar inte i sig om en olöst sårbarhetsrisk är godtagbar.

För applikationer, skilj mellan distribution och kontroll. Att installera en godkänd applikation hindrar inte användare från att installera alternativ, såvida inte plattformen och konfigurationen stöder en sådan begränsning. Definiera vem som får godkänna programvara, vad som kräver bedömning och hur föråldrade eller förbjudna applikationer tas bort.

Varje undantag från baslinjen behöver en ägare, berörda enheter, ett affärsskäl, en riskbedömning, kompenserande åtgärder, ett godkännande och ett slutdatum. Ett operativsystem som inte stöds och som har obegränsad åtkomst till känsliga uppgifter bör inte stå kvar på obestämd tid under en allmän anteckning om ”verksamhetskrav”.

Rulla ut konfigurationen utan att förväxla tilldelning med framgång

Använd en pilotgrupp som representerar varje viktig plattform, ägarmodell och användning i verksamheten. Testa normalt arbete, resor, beteende utan uppkoppling och återställning, inte bara lyckad registrering på en administratörs skrivbord.

Fastställ förutsättningarna för hanteringen före en bred driftsättning: administratörsroller, behörigheter för registrering, nödvändiga certifikat eller tjänsteinloggningar samt ägarskap för förnyelse. En hanteringstjänst kan förlora sin effekt när ett certifikat löper ut även om policydokumenten är oförändrade.

Följ konfigurationen genom åtskilda tillstånd: riktad, levererad, tillämpad, bedömd och effektiv. Där plattformen exponerar färre steg ska begränsningen dokumenteras och en säker verifieringsmetod läggas till. Granska motstridiga profiler, inaktuella agenter, inställningar som inte stöds och användaråtgärder som förhindrar att konfigurationen slutförs.

Använd stegvis driftsättning med en godkänd väg för återgång eller återställning. Dokumentera baslinjeversionen, de målgrupper som valts, pilotresultat, godkännande och fel vid utrullningen. En skärmbild av en policyredigerare visar avsedda inställningar; enhetsrapporter och tester fastställer om inställningarna fungerade.

Skydda själva hanteringsplanet. Använd namngivna administratörskonton, lämplig stark autentisering, roller med minsta behörighet och loggning. Begränsa behörigheter för massradering och konfigurationsändringar. Granska administratörer och tjänsteinloggningar eftersom en kompromettering av hanteringstjänsten kan påverka många ändpunkter samtidigt.

Verifiera kryptering och återställning separat

För bärbara datorer, kontrollera det faktiskt genomförda lagringsskyddet, inte bara en policy för att ”aktivera kryptering”. För telefoner och surfplattor, förstå operativsystemets krypteringsmodell, beteendet i låst läge och hanteringens insyn. Kryptering i vila och krypterad nätverkstrafik är separata påståenden.

Bestäm vilken lokal lagring som omfattas, om flyttbara medier är tillåtna och hur verksamhetsinformation kan lämna hanterade applikationer. En skyddad systemdisk skyddar inte automatiskt en exporterad fil på en okrypterad extern enhet.

Arrangemangen för återställning behöver en egen kontrollutformning. Fastställ var återställningsmaterialet förvaras, vem som kan hämta det, hur hämtningen godkänns och loggas och när rotation eller ersättning krävs. Lägg inte återställningshemligheter i allmänna revisionsunderlag eller supportärenden.

Testa återställning på en utsedd testenhet med en godkänd rutin. Bevara godkännandet och utfallet, inte hemligheten. Ett fält i konsolen som visar att en nyckel finns bevisar inte att behörig personal kan återställa enheten när det behövs.

Nätverksskyddet beror också på konfigurationen av applikationer och tjänster. MDM kan distribuera certifikat eller nätverksinställningar, men kan inte fastställa att varje applikation använder lämpligt konfigurerade krypterade anslutningar. För den bredare livscykeln, se kryptering och nyckelhantering.

Koppla enhetens status till åtkomstbeslut

En efterlevnadssignal har begränsat värde om icke-efterlevande ändpunkter behåller obegränsad åtkomst. Där det stöds, koppla information om enhetens tillförlitlighet eller efterlevnad till åtkomstkontrollerna för identiteter och applikationer. Fastställ exakt vilka resurser som tillämpar villkoret och vilka åtkomstvägar som kringgår det.

Testa webbläsaråtkomst, inbyggda applikationer, fjärradministration, äldre autentisering och befintliga sessioner där det är tillämpligt. En ohanterad webbläsare kan vara blockerad medan en tidigare godkänd klient fortsätter att fungera. Hur sessioner återkallas och hur färska signalerna är kräver uttryckliga tester.

Använd riskbaserade begränsningar. Känsliga administrativa system kan kräva strängare villkor för ändpunkter än samarbetsresurser med låg risk. Definiera rutiner för nödåtkomst och återställning så att en fallerande efterlevnadstjänst inte leder till odokumenterade permanenta genvägar.

Autentisering för att låsa upp en enhet är inte detsamma som autentisering mot en applikation. Skärmlås skyddar en obevakad ändpunkt; flerfaktorsautentisering och behörighetskontroll skyddar åtkomsten till resurser. MDM kan stödja konfigurationen, men underlag från identitetsleverantören och applikationerna måste styrka dessa separata påståenden.

Hantera privata enheter, förluster och avslut medvetet

För privatägda enheter, bestäm om hanteringen ska omfatta hela enheten, en arbetsprofil, enbart applikationer eller inte vara möjlig. Förklara vad administratörer kan se, vad de kan ändra, vilken verksamhetsinformation som samlas in och vad som kan tas bort. Anta inte att platsspårning eller insyn i privata applikationer är nödvändig eller tillgänglig.

Där telemetri från anställdas enheter innefattar personuppgifter ska tillämpliga dataskyddsskyldigheter bedömas. Dataskyddsförordningen (GDPR) kräver en rättslig grund och att relevanta principer för behandling följs; artikel 32 har ett riskbaserat förhållningssätt till säkerhet i stället för att införa ett generellt krav på kryptering i alla situationer. Det bör inte antas att anställdas samtycke räcker. Låt rutiner för övervakning och borttagning granskas ur dataskydds- och arbetsrättsligt perspektiv.

Skilj selektiv borttagning av verksamhetsdata från fullständig radering av enheten. Bekräfta det beteende som stöds för varje registreringsläge och kommunicera det före registreringen. Borttagning av en arbetsprofil kan lämna personliga uppgifter orörda, medan en fullständig radering har väsentligt andra konsekvenser.

Vid en förlorad enhet bör hanteringen identifiera ändpunkten och användaren, bedöma exponeringen, begränsa åtkomsten, återkalla relevanta sessioner eller inloggningsuppgifter, skicka de lås- eller raderingskommandon som stöds och dokumentera resultaten. Fjärradering beror på anslutning och plattformens funktioner. ”Kommandot ligger i kö” är inte detsamma som ”uppgifterna är borttagna”.

Rutiner vid avslut bör omfatta både återlämnande av enheten och åtkomst till information. Återkalla åtkomsten oberoende av om en enhet återfås. Ta bort arbetsprofiler när det är lämpligt, bevara information som omfattas av lagringskrav och avveckla poster i förteckningen först efter de kontroller som krävs. Testa processerna inom en säker omfattning med testkonton och testenheter.

Bevara underlag som stöder ett avgränsat påstående

Ett paket med underlag bör låta en granskare rekonstruera vad som skyddades under en angiven period. Bevara daterade exporter, populationssiffror, beslut om undantag och åtgärdsdokumentation. Ta med tillräckligt sammanhang för att skilja en bedömning vid en viss tidpunkt från underlag om löpande drift.

Användbara resultat är bland annat:

• Omfattning och avstämning av förteckningen, inklusive olösta ohanterade enheter.
• Godkända baslinjeversioner och plattformsspecifika inställningar.
• Exporter av enhetstillstånd som visar identifierare, registrering, senaste kontakt och faktisk konfiguration.
• Godkännanden av undantag med slutdatum och kompenserande åtgärder.
• Fel vid driftsättning, åtgärdsärenden och verifiering av avslut.
• Testprotokoll för återställning, nekad åtkomst, förlorade enheter och avslut.
• Beslut från periodiska granskningar och tilldelade uppföljningsåtgärder.

Dokumentera exportfilter, tidpunkt för insamling och tolkningen av statusfält. Skydda exporterna på lämpligt sätt eftersom de kan innehålla personidentifierare eller känsliga uppgifter om infrastrukturen. Skärmbilder kan förklara konfigurationen, men sökbara exporter är oftast mer användbara för analys av populationen.

Gör stickprov över olika risker och felsätt, inte bara på friska enheter. Ta med olika plattformar, nyligen registrerade enheter, privilegierade användare, inaktuella ändpunkter och godkända undantag. En aktuell rapport kan inte rekonstruera en tidigare granskningsperiod om inte historiska uppgifter har sparats.

Periodiska granskningar av täckningen bör omfatta nyligen introducerade enheter och förändrade åtkomstmönster. Användbara operativa mått är registreringstäckning, efterlevnad av den bedömda baslinjen, inaktuell rapportering, utgångna undantag och åtgärdernas ålder. Definiera varje nämnare och tröskel. Kontinuerlig övervakning av kontroller ger ytterligare sammanhang för att skilja signaler från granskade slutsatser.

Exempel: granskning av en blandad enhetsflotta

Följande siffror och tröskelvärden är illustrativa antaganden, inte branschriktmärken.

Ett företag identifierar 120 bärbara företagsdatorer och 30 privata telefoner som är godkända för arbetsmejl. Baslinjen för bärbara datorer kräver registrering, kryptering, ett operativsystem som stöds, skärmlås och en lyckad bedömning inom sju dagar. Privata telefoner kräver en hanterad arbetsprofil och programvara som stöds; hantering av hela enheten ligger utanför den godkända integritetsgränsen.

MDM-konsolen innehåller 116 bärbara datorer. Av dessa uppfyller 108 baslinjen, fyra rapporterar försenade uppdateringar, två har inaktuella bedömningar och två visar krypteringsfel. De återstående fyra bärbara datorerna saknas i hanteringen.

Om bara konsolens resultat rapporteras blir det 108 av 116, ungefär 93 % efterlevnad av baslinjen. Mot den fastställda populationen av bärbara datorer är det 108 av 120, alltså 90 %, som bevisligen uppfyller baslinjen. Registreringstäckningen är ungefär 97 %. Det är olika mått, och inget av dem bevisar kontrollerna för de privata telefonerna.

Identitetsloggar visar att två ohanterade bärbara datorer har haft åtkomst till en känslig applikation. Teamet begränsar den åtkomsten, utreder ägarskapet och registrerar enheterna. De andra två bekräftas vara avvecklade; underlag om återkallelse och kassering stöder att de tas bort ur den aktiva populationen.

För telefonerna har tre användare åtkomst till mejl utan den arbetsprofil som krävs. Deras åtkomst begränsas tills registrering eller ett godkänt alternativ är genomfört. En testtelefon bekräftar att selektiv borttagning raderar arbetsprofilen utan att radera personligt innehåll.

Granskningsdokumentationen behåller den ursprungliga populationen, ändringarna vid avstämningen, felen, åtkomstbegränsningarna och verifierade åtgärder. Den ersätter inte den första misslyckade bedömningen med en senare felfri skärmbild.

Gör nästa granskning enklare

De vanliga misstagen är operativa: att bara räkna registrerade ändpunkter, att lita på policytilldelning, att acceptera inaktuell telemetri, att lämna undantag öppna och att behandla fjärrkommandon som utförda åtgärder. Vart och ett kan hanteras genom en definierad population, uttrycklig hantering av tillstånd och daterad verifiering.

Secani kan organisera arbetet kring relevanta system, krav, ägare och underlag. Ladda upp baslinjedokument, daterade MDM-exporter och testprotokoll; koppla dem till de kontroller eller beslut de stöder; och omvandla saknade underlag eller olösta fel till tilldelade uppgifter. Bevara mänsklig granskning, godkännande och källsammanhang för väsentliga slutsatser. MDM förblir det operativa verktyget för ändpunktshantering; arbetsytan för efterlevnad bevarar sammanhanget kring genomförandet och granskningsbesluten.

Ett praktiskt nästa steg är att välja en känslig applikation och stämma av varje ändpunkt som har åtkomst till den mot hanteringens uppgifter. Testa en frisk ändpunkt, en ohanterad ändpunkt och en inaktuell ändpunkt. Dokumentera utfallen för åtkomsten och underlagen om konfigurationen, och tilldela sedan varje oförklarad avvikelse en ägare. Den lilla övningen testar täckning, tillämpning och bevis på samma gång.