Insiderrisiko: begræns mulighederne, og forbedr reaktionen

Insiderrisiko omfatter bevidst misbrug, fejl og aktivitet via en kompromitteret legitim konto. Medarbejdere, underleverandører, leverandører og tidligere medarbejdere med resterende adgang kan alle være involveret. Det nyttige udgangspunkt er ikke en liste over angiveligt risikable personer, men den adgang og de handlinger, der kan forvolde skade.

For en CTO er opgaven at begrænse mulighederne for misbrug og samtidig bevare det legitime arbejde og derefter gøre mistænkelig aktivitet mulig at undersøge. Det kræver identitetskontroller, regler for datahåndtering, brugbar telemetri og en reaktionsproces, der skelner mellem et uheld og en kompromitteret konto eller bevidst handling. Mulige konsekvenser omfatter svig, tab af intellektuel ejendom, eksponering af personoplysninger og driftsforstyrrelser. Ingen af dem kræver, at en angriber udnytter en softwaresårbarhed, hvis eksisterende rettigheder allerede muliggør handlingen.

Identificer veje med stor konsekvens

Begynd med én vigtig forretningsproces, og kortlæg, hvordan nogen kan forvolde væsentlig skade ved hjælp af legitim adgang. Medtag applikationer, administrative grænseflader, API'er, endpoints og eksterne udbydere. En trusselsmodellering med fokus på adgang kan hjælpe med at identificere veje, der går på tværs af flere systemer.

Spørg, hvad en person kan læse, ændre, eksportere, slette eller godkende, ikke blot om vedkommende har en konto.

Registrer for hver vej aktivejeren, de autoriserede roller, det forventede formål, den forebyggende kontrol, detektionskilden og den, der reagerer. Prioriter efter mulig konsekvens, hvor let handlingen er at udføre, og evnen til at genoprette. En følsom handling, som én person kan udføre uden uafhængig kontrol, fortjener særlig opmærksomhed.

Leverancen er et kort register over adgangsveje. Det bør præcist angive, hvilken handling der kræver funktionsadskillelse, yderligere godkendelse eller tættere overvågning.

Fjern unødvendige beføjelser, før der tilføjes overvågning

Mindste privilegium betyder, at rettighederne svarer til det aktuelle arbejde. Begynd med de faktiske rettigheder, herunder indlejrede grupper, applikationsspecifikke roller, delegeret adgang, servicekonti, API-tokens og delte loginoplysninger. En pæn liste over roller i kataloget kan skjule overdrevne rettigheder inde i de enkelte applikationer.

Lad forretningsejerne validere, hvorfor hver følsom rettighed er nødvendig. Hvor det er praktisk muligt, bør almindelige konti adskilles fra administrative identiteter, og stående administrativ adgang erstattes med godkendt, tidsbegrænset forhøjelse. Brug multifaktorautentificering, helst phishing-resistente metoder, hvor de understøttes, for at reducere eksponeringen for kompromitterede loginoplysninger. Autentificering forhindrer ikke en autoriseret person i at misbruge sine rettigheder.

Funktionsadskillelse skal findes i systemet, ikke kun i politikken. Den, der ændrer en leverandørs betalingsoplysninger, bør ikke også godkende den efterfølgende betaling. Nødtilsidesættelser kræver en registreret begrundelse, et defineret udløb og en efterfølgende gennemgang foretaget af en person, der er uafhængig af handlingen.

Indbyg adgangsændringer i personale- og leverandørprocesserne:

• Ansættelse: Tildel en defineret rolle i stedet for at kopiere en kollegas ophobede rettigheder.
• Rolleskift: Fjern forældet adgang, og tilføj nye ansvarsområder.
• Fratrædelse: Koordiner deaktivering af konti, afslutning af sessioner, tilbagekaldelse af tokens, håndtering af enheder og fjernelse af leverandøradgang.
• Midlertidigt arbejde: Tildel en ejer og et udløb til forhøjet eller projektspecifik adgang.

Gennemgå servicekonti separat. Dokumenter deres formål, afhængigheder, opbevaring af loginoplysninger og ejer. Undgå interaktiv brug, hvor det ikke er nødvendigt. Hvis en delt loginoplysning endnu ikke kan fjernes, skal undtagelsen og de kompenserende kontroller registreres; antag ikke, at loggene pålideligt vil identificere den enkelte bruger.

Beskyt dataene og vejen ud

Databeskyttelse begynder med at vide, hvilke oplysninger der betyder noget, og hvor de bevæger sig hen. Klassificer følsomme datasæt, identificer godkendte destinationer, og definer, hvornår eksport eller ekstern deling er legitim. Giv brugerne en brugbar godkendt vej, ellers kan kontrollerne skubbe aktiviteten ud i ustyrede kanaler.

Data loss prevention (DLP) kan advare, blokere eller kræve en begrundelse for udvalgte overførsler. Afprøv politikkerne på repræsentative arbejdsgange, før de håndhæves bredt. Test delingslinks i skyen, uploads i browseren, synkroniseringsklienter, flytbare medier og udskrivning, hvor det er relevant for risikoen. Dækningen varierer efter platform og kanal; en vellykket test på et endpoint fastslår ikke beskyttelse af en applikations API.

Kryptering i hvile og under overførsel beskytter bestemte eksponeringsveje, men en autoriseret bruger kan stadig hente klartekst. Kombiner kryptering med adgangsgrænser, eksportbegrænsninger og kontrolleret deling. Beskyt også backups og administrationen af genopretning: Destruktivt misbrug bliver sværere at genoprette fra, når den samme identitet kan ændre produktionen og slette dens backups.

Gør detektion forholdsmæssig og forklarlig

Indsaml signaler, der er knyttet til vejene med stor konsekvens, i stedet for alt, hvad en person gør. Nyttige hændelser kan omfatte usædvanligt store eksporter, ny ekstern deling, ændringer af rettigheder, deaktiveret logning, gentagne afviste adgangsforsøg eller adgang til følsomme repositories uden for etablerede arbejdsmønstre.

Brug applikationers auditlogge sammen med hændelser fra identitet, endpoints og cloud. Et SIEM-system (security information and event management) kan korrelere disse kilder; adfærdsanalyse af brugere og enheder (UEBA) kan hjælpe med at identificere afvigelser fra en baseline. Ingen af dem fastslår hensigt. En migrering, en godkendt hændelsesreaktion eller en ændret jobrolle kan forklare usædvanlig aktivitet.

Angiv for hver detektionsregel:

• Den risikable handling og de dækkede systemer.
• De krævede logfelter, såsom aktør, tidsstempel, objekt, handling, udfald og destination.
• Forventede legitime undtagelser, og hvordan de, der reagerer, kontrollerer dem.
• Ejeren af reaktionen, eskaleringsvejen og betingelserne for hastende inddæmning.
• Hvordan teamet vil teste reglen og måle dens nytte.

Beskyt logge mod uautoriseret ændring, synkroniser tidsstempler, og kontroller, at fejl i indlæsningen er synlige. Test alarmer med godkendt aktivitet i et sikkert miljø. Følg manglende telemetri og falske positiver som tekniske fejl, ikke blot som analytikernes arbejdsbyrde.

Etabler sikkerhedsforanstaltninger for overvågningen først

Før der indsamles oplysninger om medarbejdernes aktivitet, skal retsgrundlaget, formålet, databeskyttelsesgarantierne, adgangskontrollerne og opbevaringen fastlægges. Inddrag relevante repræsentanter fra databeskyttelse, jura, HR og medarbejdersiden; forpligtelser til høring afhænger af jurisdiktion og kontekst.

Hvor GDPR finder anvendelse, omhandler artikel 5, 6, 13–14 og 32 principper, lovlig behandling, gennemsigtighed og sikkerhed. Artikel 35 kræver en konsekvensanalyse vedrørende databeskyttelse, hvor behandlingen sandsynligvis vil indebære en høj risiko. Sikkerhedsmål fjerner ikke disse krav.

Som praktisk anbefaling bør snævert afgrænsede hændelsesmetadata foretrækkes frem for indgribende indsamling af indhold, når de besvarer undersøgelsens spørgsmål. Begræns adgangen til sager, dokumenter beslutninger om opbevaring, og behandl ikke personlige forhold eller uenighed på arbejdspladsen som bevis for forseelser. Automatiske scorer kræver menneskelig validering.

Hjælp folk med at indberette fejl tidligt

Giv en tydelig indberetningsvej for utilsigtet deling, mistede enheder, mistænkelige anmodninger og uventet kontoaktivitet. Forklar, hvad der skal indberettes: systemet, det omtrentlige tidspunkt, de involverede oplysninger, modtagere og allerede foretagne handlinger. Medarbejderne bør ikke skulle klassificere hændelsen, før de beder om hjælp.

Gør uddannelsen specifik for arbejdet. Økonomiteams har brug for scenarier om verifikation af betalingsændringer; udviklere har brug for eksempler på håndtering af repositories og hemmeligheder; supportmedarbejdere har brug for vejledning om kundeeksporter og forsøg på at udgive sig for andre. Medtag underleverandører og privilegerede administratorer.

Reager konstruktivt på hurtige indberetninger. Fortæl den, der indberetter, om vedkommende skal stoppe med at bruge en enhed, bevare en besked eller undlade at kontakte en modtager, indtil beredskabsteamet giver besked. Klare instruktioner forhindrer, at velmenende oprydning ødelægger beviser eller udvider eksponeringen.

Reager på fakta, ikke på etiketter

En alarm er et spor til undersøgelse, ikke bevis for en forseelse. Fastslå konteksten, og beskyt fortroligheden for alle involverede. En tilsyneladende gyldig kontohandling kan skyldes en fejl, automatisering, en stjålet session eller bevidst misbrug; behovene for inddæmning kan overlappe, mens de ansættelsesmæssige konsekvenser er forskellige.

En brugbar reaktionsplan (playbook) bør dække fem beslutninger:

1. Triage: Bekræft hændelsen, de berørte aktiver, følsomheden, autorisationen, og om skaden fortsætter. Kontroller godkendte ændringer, og kontakt procesejeren via en betroet kanal.
2. Bevaring: Bevar relevante logge, identitetshændelser, delingsregistreringer og originale filer, hvor det er relevant. Registrer indsamlingstidspunkt, kilde, efterforsker og håndtering. Begræns adgangen til sagsmaterialet.
3. Inddæmning: Vælg forholdsmæssige foranstaltninger som at tilbagekalde sessioner, begrænse eksporter, deaktivere deling eller fjerne forhøjede rettigheder. Tag højde for afhængigheder i tjenesterne, før en konto deaktiveres, uden at forsinke hastende beskyttelse.
4. Koordinering: Inddrag sikkerhed, systemejeren, databeskyttelse, jura og HR efter de faktiske forhold. Ansættelsesmæssige skridt og anmeldelser til politiet kræver passende beføjelse, ikke en automatisk alarmtærskel.
5. Genopretning: Genetabler godkendt adgang og godkendte konfigurationer, skift berørte loginoplysninger, valider dataintegriteten, og overvåg for gentagelse.

Definer, hvem der kan godkende hastende inddæmning, og en alternativ kontakt, hvis en privilegeret administrator eller den sædvanlige beslutningstager er involveret.

Vurder underretningspligter separat. Efter GDPR artikel 33 og 34 vurderer dataansvarlige anmeldelse til tilsynsmyndigheden uden unødig forsinkelse og om muligt inden for 72 timer efter at være blevet bekendt med bruddet, medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Databehandlere underretter de dataansvarlige uden unødig forsinkelse. En høj risiko kan kræve underretning af de berørte personer med forbehold for undtagelserne i artikel 34. Registrer begrundelsen for ikke at anmelde, og kontroller andre gældende kontraktlige eller lovbestemte pligter.

Gennemgået eksempel: en usædvanlig kundeeksport

Illustrative antagelser: En supportapplikation indeholder kunders kontaktoplysninger; supervisorer må eksportere et begrænset antal registreringer i godkendte sager; en separat integrationsidentitet udfører planlagt rapportering.

En alarm melder, at en supervisor eksporterer væsentligt flere registreringer end vedkommendes normale arbejdsmængde. Analytikeren kontrollerer eksportens omfang, destinationen, identitetshændelserne og den godkendte sagsreference. En ny loginkontekst øger bekymringen, men fastslår ikke, hvem der handlede.

Beredskabsteamet bevarer applikations- og identitetslogge, tilbagekalder den mistænkelige session og fjerner midlertidigt brugerens eksportrettighed. Det kontrollerer, at den planlagte integration ikke påvirkes, før bredere adgang ændres. Via en betroet kontakt bekræfter supervisoren, at vedkommende ikke har bestilt eksporten.

Arbejdshypotesen bliver en kompromitteret konto. Efterforskerne undersøger eksponeringen af loginoplysninger og sessioner, identificerer så vidt muligt modtagere eller destinationer og vurderer pligterne til anmeldelse af brud. Genopretningen omfatter sikring af kontoen og validering af rettighederne.

Kontrolgennemgangen viser, at det rutinemæssige supportarbejde ikke krævede brede eksportrettigheder. Den korrigerende handling er en snævrere rolle, godkendelse af større eksporter og en testet alarm. Dokumentationen omfatter konfigurationsregistreringer, en kontrolleret test og bedømmerens godkendelse, ikke en påstand om, at alle fremtidige eksporter vil blive forhindret.

Bevar dokumentation, der viser, at kontrollerne virker

Efter en sag eller en øvelse skal fakta, reaktion, konsekvenser og forbedringer registreres. Undersøg, om overdrevne rettigheder, manglende godkendelser, uklare instruktioner eller ufuldstændig telemetri har bidraget. Tildel hver korrigerende handling en ejer, en frist og en verifikationsmetode.

Nyttig dokumentation omfatter gennemgange af rettigheder med registreringer af fjernelse, historik over forhøjede rettigheder, test af fratrædelsesprocessen, test af detektionsregler, kontrol af logdækning og øvelser, der demonstrerer eskaleringsvejen. Mål kontrolresultater som fjernet udløbet adgang og alarmer med tilstrækkelig kontekst i stedet for kun at tælle gennemført uddannelse.

Secani forbinder risici, implementering af kontroller og dokumentation i en styret kontekst. For én adgangsvej kan teams modellere de relevante systemer, vedhæfte eksporter fra gennemgange og testregistreringer, tildele opgaver til lukning af mangler og bevare menneskelige beslutninger fra gennemgangen. Dokumentationen om rettigheder og API-adgang beskriver OSCAL API-rollen, der kun kan validere, et konkret eksempel på at give loginoplysninger en kapabilitet, der er afgrænset til deres tilsigtede opgave. Bring eksporter fra adgangsgennemgange, overvågningsfund og godkendte beslutninger om reaktion ind i denne forbundne kontrolregistrering.

Begynd med at teste én adgangsvej med stor konsekvens og eskaleringsvejen, hvis den misbruges. Bekræft, at unødvendige beføjelser er fjernet, at en meningsfuld hændelse er synlig, og at en autoriseret person kan reagere med tilstrækkelig dokumentation og kontekst.