Beveiligingsprofessionals maken zich steeds meer zorgen over identiteitsgebaseerde bedreigingen voor SaaS-applicaties. Toch beschikken maar weinigen over de capaciteiten om deze te detecteren en erop te reageren.
Volgens de Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) begint 90% van alle cyberaanvallen met phishing, een identiteitsgebaseerde bedreiging. Voeg daar aanvallen aan toe die gebruikmaken van gestolen inloggegevens, overgeprovisioneerde accounts en insider-bedreigingen, en het wordt duidelijk dat identiteit een primaire aanvalsvector is.
Om het nog erger te maken, zijn het niet alleen menselijke accounts die het doelwit zijn. Dreigingsactoren kapen ook niet-menselijke identiteiten, waaronder serviceaccounts en OAuth-autorisaties, en slepen deze diep in SaaS-applicaties.
Wanneer dreigingsactoren de eerste verdedigingslinies doorbreken, kan een robuust Identity Threat Detection and Response (ITDR)-systeem als integraal onderdeel van Identity Security enorme inbreuken voorkomen. De Snowflake-inbreuk van vorige maand is een perfect voorbeeld. Dreigingsactoren maakten gebruik van enkelvoudige authenticatie om toegang te krijgen tot het account. Eenmaal binnen had het bedrijf geen enkele zinvolle dreigingsdetectiemogelijkheid, waardoor de dreigingsactoren meer dan 560 miljoen klantrecords konden exfiltreren.
Hoe ITDR werkt
ITDR combineert verschillende elementen om SaaS-bedreigingen te detecteren. Het bewaakt gebeurtenissen van de hele SaaS-stack en gebruikt inloggegevens, apparaatgegevens en gebruikersgedrag om gedragsafwijkingen te identificeren die duiden op een bedreiging. Elke afwijking wordt beschouwd als een indicator of compromise (IOC) en wanneer die IOC’s een vooraf gedefinieerde drempel bereiken, activeert de ITDR een waarschuwing.
Als een admin bijvoorbeeld een ongebruikelijke hoeveelheid data downloadt, beschouwt ITDR dat als een IOC. Als het downloaden echter midden in de nacht plaatsvindt of op een ongebruikelijke computer, kan de combinatie van die IOC’s als een bedreiging worden beschouwd.
Op dezelfde manier, als een gebruiker inlogt vanaf een verdacht ASN na brute-force loginpogingen, classificeert de ITDR de login als een bedreiging, wat een incidentrespons triggert. Door een rijke dataset van meerdere applicaties te gebruiken, kan de ITDR bedreigingen detecteren op basis van gegevens van verschillende applicaties. Als een gebruiker tegelijkertijd is ingelogd op één applicatie vanuit New York en een tweede applicatie vanuit Parijs, kan het lijken alsof het normaal gedrag is als de ITDR beperkt is tot het beoordelen van gebeurtenislogboeken voor één enkele app. De kracht van SaaS ITDR komt voort uit het monitoren van gegevens van de hele SaaS-stack.
Bij een recente inbreuk die door Adaptive Shield werd gedetecteerd, infiltreerden dreigingsactoren een HR-salarissysteem en veranderden de rekeningnummers van de bankrekeningen van verschillende werknemers. Gelukkig detecteerden de ITDR-engines de afwijkende acties en werden de rekeninggegevens gecorrigeerd voordat er geld werd overgemaakt naar de dreigingsactoren.
Het verminderen van identiteitsgebaseerde risico’s
Organisaties kunnen een aantal stappen ondernemen om het risico op identiteitsgerelateerde bedreigingen te verkleinen en hun identiteit te versterken.
Multi-factor authenticatie (MFA) en single sign-on (SSO) zijn cruciaal in deze inspanningen. Permission trimming, het naleven van het principe van least privilege (PoLP) en role-based access control (RBAC) beperken ook de toegang van gebruikers en verkleinen het aanvalsoppervlak.
Helaas worden veel identiteitsbeheertools onvoldoende benut. Organisaties schakelen MFA uit en de meeste SaaS-applicaties vereisen dat beheerders lokale inlogmogelijkheden hebben voor het geval de SSO uitvalt.
Hier volgen enkele proactieve maatregelen voor identiteitsbeheer om het risico van identiteitsgebaseerde inbreuken te beperken:
Classificeer uw rekeningen
Accounts met een hoog risico vallen over het algemeen in verschillende categorieën. Om sterk identiteitsbeheer en -beheer te creëren, moeten beveiligingsteams beginnen met het classificeren van de verschillende gebruikerstypen. Dit kunnen accounts van voormalige werknemers, accounts met hoge privileges, inactieve accounts, niet-menselijke accounts of externe accounts zijn.
1. Deprovisioneren van voormalige werknemers en deactiveren van inactieve gebruikersaccounts
Actieve accounts van voormalige werknemers kunnen leiden tot een aanzienlijk risico voor organisaties. Veel SaaS-beheerders gaan ervan uit dat zodra een werknemer wordt verwijderd van de Identity Provider (IdP), hun toegang tot SaaS-applicaties van het bedrijf automatisch wordt verwijderd.
Hoewel dat waar kan zijn voor SaaS-applicaties die verbonden zijn met de IdP, zijn veel SaaS-apps niet verbonden. In die omstandigheden moeten beheerders en beveiligingsteams samenwerken om voormalige gebruikers met lokale referenties te deprovisioneren.
Slapende accounts moeten worden geïdentificeerd en gedeactiveerd wanneer dat mogelijk is. Vaak gebruikten beheerders deze accounts om tests uit te voeren of de applicatie in te stellen. Ze hebben hoge privileges en worden gedeeld door meerdere gebruikers met een gemakkelijk te onthouden wachtwoord. Deze gebruikersaccounts vormen een aanzienlijk risico voor de applicatie en de gegevens ervan.
2. Externe gebruikers controleren
Externe accounts moeten ook worden gemonitord. Vaak worden deze accounts aan agentschappen, partners of freelancers gegeven, de organisatie heeft geen echte controle over wie toegang heeft tot hun gegevens. Wanneer projecten eindigen, blijven deze accounts vaak actief en kunnen ze door iedereen met inloggegevens worden gebruikt om de applicatie te compromitteren. In veel gevallen zijn deze accounts ook geprivilegieerd.
3. Gebruikersrechten inkorten
Zoals eerder vermeld, vergroten buitensporige rechten het aanvalsoppervlak. Door het principe van de minste privileges (POLP) toe te passen, heeft elke gebruiker alleen toegang tot de gebieden en gegevens binnen de app die ze nodig hebben om hun werk te doen. Door het aantal accounts met hoge privileges te verminderen, wordt de blootstelling van een bedrijf aan een grote inbreuk aanzienlijk verminderd.
4. Maak cheques voor bevoorrechte accounts
Beheerdersaccounts zijn risicovol. Als ze gecompromitteerd worden, stellen ze organisaties bloot aan aanzienlijke datalekken.
Maak beveiligingscontroles die waarschuwingen sturen wanneer gebruikers zich verdacht gedragen. Enkele voorbeelden van verdacht gedrag zijn ongebruikelijke late-night logins, verbinding maken met een werkstation vanuit het buitenland of grote hoeveelheden data downloaden. Beheerders die gebruikersaccounts met hoge privileges maken, maar deze niet toewijzen aan een beheerd e-mailadres, kunnen verdacht zijn.
Door beveiligingscontroles te definiëren die op dit soort gedrag letten, kan uw beveiligingsteam een voorsprong krijgen bij het identificeren van aanvallen in een vroeg stadium.
Maak het detecteren van identiteitsbedreigingen een prioriteit
Naarmate meer gevoelige bedrijfsinformatie achter een identiteitsgebaseerde perimeter wordt geplaatst, wordt het steeds belangrijker voor organisaties om prioriteit te geven aan hun identiteitsstructuur. Elke beveiligingslaag die rond identiteit wordt geplaatst, maakt het voor dreigingsactoren alleen maar moeilijker om toegang te krijgen.
Voor degenen die de eerste verdedigingen wel doorstaan, is het essentieel om een robuust ITDR-systeem te hebben als integraal onderdeel van de identiteitsstructuur om de beveiliging te behouden en gevoelige gegevens te beschermen tegen blootstelling. Het identificeert actieve bedreigingen en waarschuwt beveiligingsteams of onderneemt geautomatiseerde stappen om te voorkomen dat bedreigingsactoren schade veroorzaken.
Meer informatie over het detecteren van bedreigingen in uw SaaS-stack
