Elke AI-tool, workflowautomatisering en productiviteitsapp die uw werknemers dit jaar met Google of Microsoft hebben verbonden, heeft iets achtergelaten: een persistent OAuth-token zonder vervaldatum, zonder automatische opschoning, en in de meeste organisaties kijkt niemand ernaar. Jouw perimetercontroles zien het niet. Uw MFA houdt dit niet tegen. En als een aanvaller er een te pakken krijgt, heeft hij geen wachtwoord nodig.
OAuth-toekenningen verlopen niet wanneer werknemers vertrekken. Ze worden niet gereset als wachtwoorden veranderen. En in de meeste organisaties kijkt niemand naar hen.
Het model was logisch toen een handvol door IT goedgekeurde apps agendatoegang nodig hadden. Het houdt geen stand als elke medewerker zelfstandig AI-tools, workflowautomatiseringen en productiviteitsapps rechtstreeks in hun Google- of Microsoft-omgeving aansluit, waarbij elke medewerker een persistent, token ontvangt zonder automatische vervaldatum en zonder gecentraliseerde zichtbaarheid.
Dat is geen verkeerde configuratie. Dit is hoe OAuth is ontworpen om te werken. Het verschil is dat de meeste beveiligingsprogramma’s niet zijn gebouwd om er op grote schaal rekening mee te houden.
CISO’s weten dat het een probleem is. De meesten lossen het niet op.
Nieuw onderzoek van Material Security kwantificeert de kloof tussen bewustzijn en actie. 80% van de beveiligingsleiders beschouwt onbeheerde OAuth-subsidies als een kritiek of aanzienlijk risico. De meesten zeggen dat al jaren.
Maar bewustzijn vertaalt zich niet rechtstreeks in bekwaamheid. Een substantieel deel van de organisaties (45%) doet niets om OAuth-subsidies op grote schaal te monitoren. Een groot deel van de overige bedrijven (33%) voert handmatige processen uit: het bijhouden van subsidies in spreadsheets, het op ad-hocbasis beoordelen van machtigingen en het vertrouwen op werknemers om ongewoon app-gedrag te signaleren.
Spreadsheets zijn geen mogelijkheid om op bedreigingen te reageren. Ze zijn een registratie van hoeveel exposure een organisatie heeft, waarvan ze niet weet dat ze die heeft.
Het is geen theoretisch risico
Het argument voor OAuth-zichtbaarheid wordt vaak verwoord als werknemers gevoelige informatie doorsturen naar tools van derden zonder IT-zichtbaarheid. Dat is een reëel probleem, maar het is een kleiner probleem. Het urgentere probleem is dat OAuth-subsidies een actieve aanvalsvector zijn. Het Drift-incident maakt dat concreet.
Drift, een verkoopbetrokkenheidsplatform overgenomen door Salesloft, onderhield OAuth-integraties met Salesforce-instanties bij honderden klantorganisaties. Een bedreigingsacteur die door Palo Alto Unit 42 werd gevolgd toen UNC6395 geldige OAuth-vernieuwingstokens verkreeg – waarschijnlijk via eerdere phishing-campagnes – en deze gebruikte om toegang te krijgen tot Salesforce-omgevingen van meer dan 700 organisaties.
De structuur van de aanval is een waarschuwing: de tokens waren legitiem, de integratie was legitiem. Vanuit het perspectief van elke perimetercontrole was er niets aan de hand. MFA werd volledig omzeild omdat de aanvaller niet inlogde. Ze presenteerden een token waarvoor Drift al toestemming had gekregen om het te gebruiken. Eenmaal binnen exporteerde UNC6395 systematisch gegevens en doorzocht deze op zoek naar inloggegevens: AWS-toegangssleutels, Snowflake-tokens, wachtwoorden.
Cloudflare, PagerDuty en tientallen anderen werden getroffen. De volledige reikwijdte wordt nog beoordeeld.
Het Drift-incident was geen aanval van een verdachte, onbekende app. Het was een aanval door een vertrouwde. De les is niet dat organisaties OAuth-integraties moeten beperken; het is dat het vertrouwen van een app op het moment van installatie niet betekent dat deze betrouwbaar blijft, en dat OAuth-subsidies actieve, continue monitoring nodig hebben in plaats van passieve acceptatie.
Hoe monitoring er eigenlijk uit moet zien
De huidige generatie OAuth-beveiligingstools pakt het OAuth-risico aan op het moment van installatie. Zij controleren of een gevraagde toestemmingsscope excessief is. Ze kunnen apps van leveranciers met een slechte reputatie markeren. Dat is nuttig – maar het is niet voldoende. Voor het Drift-scenario, een legitieme app waarvan de inloggegevens later werden gestolen en bewapend, wordt niets onderschept.
Om te beginnen zijn de vertrouwensniveaus van leveranciers en de reikwijdte van apps belangrijk, maar dit vertelt slechts een deel van het verhaal. Het monitoren van het daadwerkelijke gedrag van de app – de API-aanroepen die de app doet, de acties die hij onderneemt – is van cruciaal belang om te begrijpen wat de app is Eigenlijk doet, niet alleen wat het zou kunnen doen. En zelfs dan, zonder diepgaand inzicht in de account(s) waaraan de app is gekoppeld, opereer je nog steeds halfblind. Een riskante app gekoppeld aan het account van een stagiair is één ding; dezelfde app die wordt gebruikt door een VIP met toegang tot talloze gevoelige e-mails, bestanden en systemen is iets heel anders.
Bij de Drift-aanval was er geen sprake van een verdachte app die tijdens de installatie om ongebruikelijke machtigingen vroeg. Het betrof een legitieme app waarvan de inloggegevens later werden gecompromitteerd en bewapend. Een tool die de subsidie alleen evalueert op het moment van creatie zou niets verkeerds hebben gezien. Het risico manifesteerde zich later – toen het token werd gestolen en volledig door een andere actor werd gebruikt.
Effectieve OAuth-beveiliging vereist:
- Continue gedragsmonitoring, geen beoordeling op een bepaald moment. Wat doet de app eigenlijk nadat er toegang aan is verleend? Het monitoren van de API-aanroepen die een met OAuth verbonden app in de loop van de tijd doet, brengt afwijkingen aan het licht die geen enkele statische toestemmingsbeoordeling kan onderkennen: plotselinge pieken in de gegevenstoegang, zoekopdrachten naar ongebruikelijke gegevenstypen en toegang op onverwachte uren.
- Beoordeling van de straalstraal. Een OAuth-toekenning die is gekoppeld aan een account met leestoegang tot duizenden gevoelige documenten en jarenlange e-mailgeschiedenis verschilt pertinent van dezelfde toekenning aan een nieuw ingericht account met beperkte blootstelling. Het bereik van het gebruikersaccount bepaalt de potentiële impact van een gecompromitteerde of kwaadaardige OAuth-verbinding. Risicoscores moeten dat weerspiegelen.
- Gegradueerde respons afgestemd op de risicotolerantie van de organisatie. Een duidelijk kwaadaardige app (onbekende leverancier, brede rechten, abnormaal API-gedrag vanaf de eerste dag) mag niet in de omgeving blijven staan terwijl een ticket door een wachtrij werkt. Het moet onmiddellijk worden ingetrokken. Een bedrijfskritische integratie van een grote leverancier die milde afwijkingen vertoont, vereist menselijke beoordeling voordat er actie wordt ondernomen. De responslaag moet intelligent genoeg zijn om het verschil te kunnen zien.
Materiaal’s OAuth Threat Remediation Agent
De OAuth Threat Remediation Agent van Material Security is gebouwd rond dit completere model van OAuth-risico. De agent draait continu in de Google Workspace-omgeving van een organisatie en controleert elke OAuth-gekoppelde applicatie, niet alleen de nieuwe op het moment van verlening.
Voor elke verbonden app evalueert de agent drie factoren samen:
- Leveranciersvertrouwen en reikwijdteanalyse – de standaardbasislijn waar de meeste tools bij stoppen
- Gedragsmonitoring van daadwerkelijke API-oproepen die in de loop van de tijd door de app zijn gemaakt, waardoor afwijkingen in het verwachte gedrag aan het licht komen
- Beoordeling van de straalstraal gebaseerd op de toegangsniveaus en gegevensblootstelling van de accounts waarmee de app is verbonden
Deze inputs vormen samen een risicosignaal dat zowel de waarschijnlijkheid van een probleem als de potentiële impact ervan weerspiegelt. Wanneer de agent een subsidie met een hoog risico identificeert, kan deze onmiddellijk actie ondernemen en het token intrekken voordat er schade wordt aangericht. Voor situaties met minder zekerheid waarbij bedrijfskritische applicaties betrokken zijn, wordt de bevinding met volledige context aan het beveiligingsteam getoond: wat de app is, wat deze heeft gedaan, waartoe deze toegang heeft en wat de risicoscore is.
Organisaties configureren hun eigen drempels: hoeveel risico leidt tot geautomatiseerd herstel, en waar ligt de grens voor het vereisen van menselijke goedkeuring. De agent is ontworpen om beveiligingsteams op de hoogte te houden van de beslissingen die er toe doen, en buiten de lijn van de beslissingen die er niet toe doen.
Het sluiten van de achterdeur
OAuth-subsidies zijn de standaardmanier waarop apps en AI-tools van derden verbinding maken met de bedrijfswerkruimte. Dat verandert niet. Het aantal subsidies zal in de meeste omgevingen blijven groeien naarmate de adoptie van AI versnelt. Werknemers vertellen dat ze geen AI-tools mogen gebruiken is voor de meeste organisaties geen haalbare beveiligingshouding – en het zou de dreiging van apps die bij de installatie legitiem zijn en later kwaadaardig zijn, niet aanpakken.
Het antwoord is niet minder OAuth-subsidies. Het gaat om een beter inzicht in de bestaande systemen, het voortdurend monitoren van hun gedrag en het operationele vermogen om snel genoeg te reageren als het er toe doet en slim genoeg om te voorkomen dat de integraties die het bedrijf draaiende houden, worden verstoord.
Voor beveiligingsteams die inzicht willen in wat er daadwerkelijk met hun omgeving is verbonden – en de mogelijkheid willen hebben om te reageren als er iets verandert, kunt u contact opnemen met Material Security voor een demo van de OAuth Threat Remediation Agent.
