Insiderrisk: minska möjligheterna och förbättra hanteringen

Insiderrisk omfattar avsiktligt missbruk, misstag och aktivitet via ett komprometterat legitimt konto. Anställda, konsulter, leverantörer och tidigare medarbetare med kvarvarande åtkomst kan alla vara inblandade. Den användbara utgångspunkten är inte en lista över förment riskfyllda personer: det är den åtkomst och de handlingar som kan orsaka skada.

För en CTO är uppgiften att minska möjligheterna till missbruk utan att hindra legitimt arbete, och sedan göra misstänkt aktivitet möjlig att utreda. Det kräver identitetskontroller, regler för datahantering, användbar telemetri och en hanteringsprocess som skiljer ett misstag från ett komprometterat konto eller en avsiktlig handling. Möjliga konsekvenser är bedrägeri, förlust av immateriella tillgångar, exponering av personuppgifter och driftstörningar. Ingen av dem kräver att en angripare utnyttjar en sårbarhet i programvara om befintliga behörigheter redan möjliggör handlingen.

Identifiera vägar med stor påverkan

Börja med en viktig verksamhetsprocess och kartlägg hur någon skulle kunna orsaka väsentlig skada med legitim åtkomst. Ta med applikationer, administrativa gränssnitt, API:er, slutpunkter och externa leverantörer. En hotmodellering med fokus på åtkomst kan hjälpa till att identifiera vägar som går genom flera system.

Fråga vad en person kan läsa, ändra, exportera, radera eller godkänna, inte bara om hen har ett konto.

Dokumentera för varje väg tillgångsägaren, behöriga roller, förväntat syfte, förebyggande säkerhetsåtgärd, detektionskälla och den som hanterar händelser. Prioritera efter möjlig påverkan, hur lätt handlingen är att utföra och förmågan att återhämta sig. En känslig handling som en person kan utföra utan oberoende kontroller förtjänar särskild uppmärksamhet.

Resultatet är ett kort register över åtkomstvägar. Det bör ange exakt vilken handling som behöver uppdelning av arbetsuppgifter, ytterligare godkännande eller närmare övervakning.

Ta bort onödiga befogenheter innan ni lägger till övervakning

Minsta behörighet innebär att behörigheterna motsvarar det nuvarande arbetet. Börja med de faktiska behörigheterna, inklusive nästlade grupper, applikationsspecifika roller, delegerad åtkomst, tjänstekonton, API-token och delade inloggningsuppgifter. En prydlig lista över katalogroller kan dölja överdrivna behörigheter i enskilda applikationer.

Låt verksamhetsägarna bekräfta varför varje känslig behörighet behövs. Skilj där det är praktiskt möjligt vardagskonton från administrativa identiteter och ersätt stående administrativ åtkomst med godkänd, tidsbegränsad förhöjning. Använd flerfaktorsautentisering, helst nätfiskeresistenta metoder där de stöds, för att minska exponeringen för komprometterade inloggningsuppgifter. Autentisering hindrar inte en behörig person från att missbruka sina behörigheter.

Uppdelning av arbetsuppgifter måste finnas i systemet, inte bara i policyn. Den som ändrar en leverantörs betalningsuppgifter bör inte också godkänna den resulterande betalningen. Nödåsidosättanden behöver ett dokumenterat skäl, ett fastställt slutdatum och en granskning i efterhand av någon som är oberoende av handlingen.

Bygg in åtkomständringar i arbetsflödena för personal och leverantörer:

• Nyanställning: tilldela en definierad roll i stället för att kopiera en kollegas ackumulerade behörigheter.
• Rollbyte: ta bort inaktuell åtkomst och lägg inte bara till nya ansvarsområden.
• Avslut: samordna inaktivering av konton, avslutande av sessioner, återkallelse av token, hantering av enheter och borttagning av leverantörsåtkomst.
• Tillfälligt arbete: tilldela förhöjd eller projektspecifik åtkomst en ägare och ett slutdatum.

Granska tjänstekonton separat. Dokumentera deras syfte, beroenden, lagring av inloggningsuppgifter och ägare. Undvik interaktiv användning där den inte behövs. Om en delad inloggningsuppgift ännu inte kan tas bort, dokumentera undantaget och de kompenserande säkerhetsåtgärderna; anta inte att loggarna på ett tillförlitligt sätt kommer att identifiera den enskilda användaren.

Skydda data och vägen ut

Dataskydd börjar med att veta vilken information som är viktig och vart den tar vägen. Klassificera känsliga datamängder, identifiera godkända destinationer och definiera när exporter eller extern delning är legitima. Ge användarna en fungerande godkänd väg, annars kan säkerhetsåtgärderna driva aktiviteten till oförvaltade kanaler.

Verktyg för att förhindra dataläckage (DLP) kan varna, blockera eller kräva motivering för utvalda överföringar. Prova policyer mot representativa arbetsflöden innan de tillämpas brett. Testa delningslänkar i molnet, uppladdningar via webbläsaren, synkroniseringsklienter, flyttbara lagringsmedier och utskrifter där det är relevant för risken. Täckningen skiljer sig mellan plattformar och kanaler; ett lyckat test på en slutpunkt visar inte att ett applikations-API är skyddat.

Kryptering av data i vila och under överföring skyddar vissa exponeringsvägar, men en behörig användare kan ändå hämta klartext. Kombinera kryptering med åtkomstgränser, exportbegränsningar och kontrollerad delning. Skydda även säkerhetskopior och administrationen av återställning: destruktivt missbruk blir svårare att återhämta sig från när samma identitet kan ändra produktionen och radera dess säkerhetskopior.

Gör detektionen proportionerlig och förklarbar

Samla in signaler som är kopplade till vägarna med stor påverkan, i stället för allt en person gör. Användbara händelser kan vara ovanligt stora exporter, ny extern delning, ändrade behörigheter, inaktiverad loggning, upprepade nekade åtkomstförsök eller åtkomst till känsliga kodförråd utanför etablerade arbetsmönster.

Använd applikationernas granskningsloggar tillsammans med händelser från identitet, slutpunkter och moln. Ett system för säkerhetsinformation och händelsehantering (SIEM) kan korrelera dessa källor; beteendeanalys av användare och entiteter (UEBA) kan hjälpa till att identifiera avvikelser från en baslinje. Ingen av dem fastställer avsikt. En migrering, en godkänd incidenthantering eller en ändrad arbetsroll kan förklara ovanlig aktivitet.

Ange för varje detektionsregel:

• Den riskfyllda handlingen och de system som omfattas.
• De loggfält som krävs, till exempel aktör, tidsstämpel, objekt, handling, utfall och destination.
• Förväntade legitima undantag och hur de som hanterar larm kontrollerar dem.
• Ägaren av hanteringen, eskaleringsvägen och villkoren för brådskande begränsning.
• Hur teamet ska testa regeln och mäta dess nytta.

Skydda loggar mot obehörig ändring, synkronisera tidsstämplar och kontrollera att misslyckad inläsning syns. Testa larm med godkänd aktivitet i en säker miljö. Följ saknad telemetri och falska positiva larm som tekniska fel, inte bara som arbetsbelastning för analytiker.

Inför skyddsåtgärder för övervakningen först

Innan ni samlar in uppgifter om anställdas aktivitet, fastställ rättslig grund, syfte, integritetsskydd, åtkomstkontroller och lagring. Involvera lämpliga företrädare för dataskydd, juridik, HR och arbetstagare; skyldigheter att förhandla eller samråda beror på jurisdiktion och sammanhang.

Där GDPR gäller behandlar artiklarna 5, 6, 13–14 och 32 principer, laglig behandling, öppenhet och säkerhet. Artikel 35 kräver en konsekvensbedömning avseende dataskydd när behandlingen sannolikt leder till en hög risk. Säkerhetsmål tar inte bort dessa krav.

Som en praktisk rekommendation, föredra snävt avgränsad händelsemetadata framför ingripande insamling av innehåll när den besvarar utredningsfrågan. Begränsa åtkomsten till ärenden, dokumentera beslut om lagring och behandla inte personliga omständigheter eller meningsskiljaktigheter på arbetsplatsen som belägg för misskötsel. Automatiska poängvärden kräver mänsklig validering.

Hjälp människor att rapportera misstag tidigt

Erbjud en tydlig rapporteringsväg för oavsiktlig delning, förlorade enheter, misstänkta förfrågningar och oväntad kontoaktivitet. Förklara vad som ska rapporteras: systemet, ungefärlig tidpunkt, berörd information, mottagare och åtgärder som redan vidtagits. Personalen ska inte behöva klassificera incidenten innan de ber om hjälp.

Gör utbildningen specifik för arbetet. Ekonomiteam behöver scenarier om verifiering av ändrade betalningsuppgifter; utvecklare behöver exempel om kodförråd och hantering av hemligheter; supportpersonal behöver vägledning om kundexporter och försök att utge sig för att vara någon annan. Ta med konsulter och privilegierade administratörer.

Bemöt snabba rapporter konstruktivt. Tala om för den som rapporterar om hen ska sluta använda en enhet, bevara ett meddelande eller avstå från att kontakta en mottagare tills incidentteamet ger besked. Tydliga instruktioner förhindrar att välmenande uppstädning förstör bevis eller vidgar exponeringen.

Agera på fakta, inte på etiketter

Ett larm är en ingång till en utredning, inte bevis på misskötsel. Fastställ sammanhanget och skydda konfidentialiteten för alla inblandade. En till synes giltig kontohandling kan bero på ett misstag, automatisering, en stulen session eller avsiktligt missbruk; behoven av begränsning kan överlappa medan de arbetsrättsliga följderna skiljer sig.

En användbar handbok för hantering bör omfatta fem beslut:

1. Sortering: bekräfta händelsen, berörda tillgångar, känslighet, behörighet och om skadan pågår. Kontrollera godkända ändringar och kontakta processägaren via en betrodd kanal.
2. Bevarande: spara relevanta loggar, identitetshändelser, uppgifter om delning och originalfiler där det är lämpligt. Dokumentera insamlingstid, källa, utredare och hantering. Begränsa åtkomsten till ärendematerialet.
3. Begränsning: välj proportionerliga åtgärder som att återkalla sessioner, begränsa exporter, inaktivera delning eller ta bort förhöjd behörighet. Beakta tjänsteberoenden innan ett konto inaktiveras, utan att fördröja brådskande skydd.
4. Samordning: involvera säkerhet, systemägaren, dataskydd, juridik och HR utifrån omständigheterna. Arbetsrättsliga åtgärder och polisanmälningar kräver lämplig befogenhet, inte en automatisk larmtröskel.
5. Återställning: återställ godkänd åtkomst och konfiguration, byt berörda inloggningsuppgifter, validera dataintegriteten och övervaka om händelsen upprepas.

Definiera vem som kan godkänna brådskande begränsning och en alternativ kontakt om en privilegierad administratör eller den vanliga beslutsfattaren är inblandad.

Bedöm anmälningsskyldigheter separat. Enligt artiklarna 33 och 34 i GDPR bedömer personuppgiftsansvariga anmälan till tillsynsmyndigheten utan onödigt dröjsmål och, om möjligt, inom 72 timmar efter att de fått kännedom om incidenten, såvida det inte är osannolikt att incidenten medför en risk för enskildas rättigheter och friheter. Personuppgiftsbiträden underrättar personuppgiftsansvariga utan onödigt dröjsmål. En hög risk kan kräva information till de berörda enskilda, med förbehåll för undantagen i artikel 34. Dokumentera resonemanget när ingen anmälan görs och kontrollera andra tillämpliga avtalsenliga eller lagstadgade skyldigheter.

Exempel: en ovanlig kundexport

Illustrativa antaganden: en supportapplikation innehåller kunders kontaktuppgifter; arbetsledare får exportera ett begränsat antal poster för godkända ärenden; en separat integrationsidentitet utför schemalagd rapportering.

Ett larm visar att en arbetsledare exporterar betydligt fler poster än vad den normala arbetsbelastningen motiverar. Analytikern kontrollerar exportens omfattning, destination, identitetshändelser och referens till ett godkänt ärende. Ett nytt inloggningssammanhang ökar oron men fastställer inte vem som agerade.

Incidentteamet bevarar applikations- och identitetsloggar, återkallar den misstänkta sessionen och tar tillfälligt bort användarens exportbehörighet. Det kontrollerar att den schemalagda integrationen inte påverkas innan bredare åtkomst ändras. Via en betrodd kontakt bekräftar arbetsledaren att hen inte begärde exporten.

Arbetshypotesen blir ett komprometterat konto. Utredarna undersöker exponeringen av inloggningsuppgifter och sessioner, identifierar mottagare eller destinationer där det är möjligt och bedömer skyldigheter att anmäla personuppgiftsincidenten. Återställningen omfattar att säkra kontot och validera behörigheterna.

Granskningen av säkerhetsåtgärderna visar att det rutinmässiga supportarbetet inte krävde breda exporträttigheter. Den korrigerande åtgärden är en snävare roll, godkännande av större exporter och ett testat larm. Underlaget omfattar konfigurationsunderlag, ett kontrollerat test och granskarens godkännande, inte ett påstående om att varje framtida export kommer att förhindras.

Spara underlag som visar att säkerhetsåtgärderna fungerar

Efter ett ärende eller en övning, dokumentera fakta, hantering, påverkan och förbättringar. Undersök om överdrivna behörigheter, saknade godkännanden, otydliga instruktioner eller ofullständig telemetri bidrog. Ge varje korrigerande åtgärd en ägare, ett slutdatum och en verifieringsmetod.

Användbara underlag för säkerhet är behörighetsgranskningar med uppgifter om borttagningar, historik över förhöjningar, tester av avslutsprocessen, tester av detektionsregler, kontroller av loggtäckning och övningar som visar eskaleringsvägen. Mät resultaten av säkerhetsåtgärderna, till exempel borttagen utgången åtkomst och larm med tillräckligt sammanhang, i stället för att bara räkna genomförda utbildningar.

Secani kopplar ihop risker, införande av säkerhetsåtgärder och underlag i ett styrt sammanhang. För en åtkomstväg kan teamen modellera de relevanta systemen, bifoga exporter från granskningar och testunderlag, tilldela uppgifter för att åtgärda brister och bevara mänskliga granskningsbeslut. Dokumentationen om behörigheter och API-åtkomst beskriver OSCAL-API-rollen som endast tillåter validering, ett konkret exempel på hur inloggningsuppgifter kan ges en förmåga som är begränsad till deras avsedda uppgift. Ta in exporter från behörighetsgranskningar, iakttagelser från övervakning och godkända beslut om hantering i detta sammankopplade underlag för säkerhetsåtgärderna.

Börja med att testa en åtkomstväg med stor påverkan och eskaleringsvägen om den missbrukas. Bekräfta att onödiga befogenheter tas bort, att en meningsfull händelse syns och att en behörig person kan agera med tillräckligt underlag och sammanhang.