Ambitieuze werknemers prijzen nieuwe AI-tools aan en negeren ernstige SaaS-beveiligingsrisico’s
Net als de SaaS-schaduw-IT uit het verleden plaatst AI CISO’s en cyberbeveiligingsteams op een moeilijke maar vertrouwde plek.
Werknemers maken heimelijk gebruik van AI, zonder rekening te houden met gevestigde IT- en cybersecurity-beoordelingsprocedures. Gezien de snelle opkomst van ChatGPT tot 100 miljoen gebruikers binnen 60 dagen na de lancering, vooral met weinig verkoop- en marketingophef, zal de door werknemers gestuurde vraag naar AI-tools alleen maar escaleren.
Nu uit nieuwe onderzoeken blijkt dat sommige werknemers de productiviteit met 40% verhogen door gebruik te maken van generatieve AI, wordt de druk op CISO’s en hun teams om de adoptie van AI te versnellen – en een oogje dicht te knijpen voor het gebruik van niet-goedgekeurde AI-tools – steeds groter.
Maar het bezwijken voor deze druk kan leiden tot ernstige SaaS-datalekken en risico’s op inbreuken, vooral omdat werknemers massaal gebruik maken van AI-tools die zijn ontwikkeld door kleine bedrijven, solopreneurs en indie-ontwikkelaars.
Indie AI-startups missen doorgaans de strikte beveiliging van Enterprise AI
Indie AI-apps tellen nu tienduizenden, en ze lokken met succes werknemers met hun freemium-modellen en productgestuurde groeimarketingstrategie. Volgens een vooraanstaande offensieve beveiligingsingenieur en AI-onderzoeker Jozef ThackerIndie AI-app-ontwikkelaars hebben minder beveiligingspersoneel en beveiligingsfocus in dienst, minder juridisch toezicht en minder naleving.
Thacker verdeelt de risico’s van indie AI-tools in de volgende categorieën:
- Data lekkage: AI-tools, met name generatieve AI die gebruik maakt van grote taalmodellen (LLM’s), hebben brede toegang tot de aanwijzingen die werknemers invoeren. Zelfs de chatgeschiedenis van ChatGPT is gelekt en de meeste indie AI-tools werken niet met de beveiligingsstandaarden die OpenAI (het moederbedrijf van ChatGPT) hanteert. Bijna elke indie AI-tool bewaart aanwijzingen voor ‘trainingsgegevens of foutopsporingsdoeleinden’, waardoor die gegevens kwetsbaar zijn voor blootstelling.
- Problemen met de inhoudskwaliteit: LLM’s zijn verdacht van hallucinaties, wat IBM definieert als het fenomeen waarbij LLMS “patronen of objecten waarneemt die niet bestaan of niet waarneembaar zijn voor menselijke waarnemers, en resultaten creëert die onzinnig of totaal onnauwkeurig zijn.” Als uw organisatie hoopt te kunnen vertrouwen op een LLM voor het genereren of optimaliseren van inhoud zonder dat er menselijke beoordelingen en protocollen voor factchecking aanwezig zijn, is de kans groot dat er onnauwkeurige informatie wordt gepubliceerd. Naast de valkuilen bij het creëren van nauwkeurigheid bij het maken van inhoud, heeft een groeiend aantal groepen, zoals academici en redacteuren van wetenschappelijke tijdschriften, ethische zorgen geuit over het openbaar maken van AI-auteurschap.
- Productkwetsbaarheden: Over het algemeen geldt dat hoe kleiner de organisatie is die de AI-tool bouwt, hoe waarschijnlijker het is dat de ontwikkelaars er niet in zullen slagen algemene productkwetsbaarheden aan te pakken. Indie AI-tools kunnen bijvoorbeeld gevoeliger zijn voor snelle injectie, en traditionele kwetsbaarheden zoals SSRF, IDOR en XSS.
- Compliance risico: Het ontbreken van een volwassen privacybeleid en interne regelgeving door Indie AI kan leiden tot hoge boetes en straffen voor niet-nalevingsproblemen. Werkgevers in sectoren of regio’s met strengere SaaS-dataregelgeving zoals SOX, ISO 27001, NIST CSF, NIST 800-53 en APRA CPS 234 kunnen in overtreding raken wanneer werknemers tools gebruiken die niet aan deze normen voldoen. Bovendien zijn veel indie AI-leveranciers er niet in geslaagd om aan SOC 2 te voldoen.
Kortom, onafhankelijke AI-leveranciers houden zich over het algemeen niet aan de raamwerken en protocollen die cruciale SaaS-gegevens en -systemen veilig houden. Deze risico’s worden vergroot wanneer AI-tools worden verbonden met SaaS-systemen van ondernemingen.
Het verbinden van Indie AI met Enterprise SaaS-apps verhoogt de productiviteit – en de kans op backdoor-aanvallen
Werknemers bereiken (of zien) aanzienlijke procesverbeteringen en resultaten met AI-tools. Maar binnenkort willen ze hun productiviteitswinst een boost geven door AI te verbinden met de SaaS-systemen die ze dagelijks gebruiken, zoals Google Workspace, Salesforce of M365.
Omdat indie AI-tools meer afhankelijk zijn van groei via mond-tot-mondreclame dan traditionele marketing- en verkooptactieken, moedigen indie AI-leveranciers deze verbindingen binnen de producten aan en maken het proces relatief naadloos. Een Hacker News-artikel over generatieve AI-beveiligingsrisico’s illustreert dit punt met een voorbeeld van een werknemer die een AI-planningsassistent vindt om de tijd beter te beheren door het taakbeheer en de vergaderingen van de werknemer te monitoren en analyseren. Maar de AI-planningsassistent moet verbinding maken met tools als Slack, zakelijke Gmail en Google Drive om de gegevens te verkrijgen die hij moet analyseren.
Omdat AI-tools grotendeels afhankelijk zijn van OAuth-toegangstokens om een AI-naar-SaaS-verbinding tot stand te brengen, krijgt de AI-planningsassistent doorlopende API-gebaseerde communicatie met Slack, Gmail en Google Drive.
Werknemers maken elke dag zonder zorgen AI-naar-SaaS-verbindingen op deze manier. Ze zien de mogelijke voordelen, niet de inherente risico’s. Maar goedbedoelende medewerkers realiseren zich niet dat ze mogelijk een tweederangs AI-toepassing hebben gekoppeld aan de zeer gevoelige gegevens van uw organisatie.
AI-naar-SaaS-verbindingen zullen, net als alle SaaS-naar-SaaS-verbindingen, de toestemmingsinstellingen van de gebruiker overnemen. Dit vertaalt zich in een ernstig veiligheidsrisico, aangezien de meeste indie AI-tools lakse beveiligingsnormen volgen. Bedreigingsactoren richten zich op indie AI-tools als middel om toegang te krijgen tot de verbonden SaaS-systemen die de kroonjuwelen van het bedrijf bevatten.
Zodra de bedreigingsactoren misbruik hebben gemaakt van deze achterdeur naar het SaaS-domein van uw organisatie, kunnen ze toegang krijgen tot gegevens en deze exfiltreren totdat hun activiteit wordt opgemerkt. Helaas blijven dit soort verdachte activiteiten vaak weken of zelfs jaren onder de radar. Er zijn bijvoorbeeld ongeveer twee weken verstreken tussen de data-exfiltratie en de publieke kennisgeving van het CircleCI-datalek in januari 2023.
Zonder de juiste SaaS Security Posture Management (SSPM)-tools om te controleren op ongeautoriseerde AI-naar-SaaS-verbindingen en om bedreigingen zoals grote aantallen bestandsdownloads te detecteren, loopt uw organisatie een verhoogd risico op SaaS-datalekken. SSPM beperkt dit risico aanzienlijk en vormt een essentieel onderdeel van uw SaaS-beveiligingsprogramma. Maar het is niet bedoeld om beoordelingsprocedures en -protocollen te vervangen.
Hoe u de beveiligingsrisico’s van Indie AI Tool praktisch kunt verminderen
Na de risico’s van indie-AI te hebben onderzocht, raadt Thacker aan dat CISO’s en cyberbeveiligingsteams zich concentreren op de basisprincipes om hun organisatie voor te bereiden op AI-tools:
1. Negeer standaard due diligence niet
We beginnen niet voor niets bij de basis. Zorg ervoor dat iemand in uw team, of een lid van de juridische afdeling, de servicevoorwaarden leest voor alle AI-tools waar werknemers om vragen. Natuurlijk is dit niet noodzakelijkerwijs een bescherming tegen datalekken of datalekken, en indie-leveranciers kunnen de waarheid oprekken in de hoop zakelijke klanten tevreden te stellen. Maar een grondig begrip van de voorwaarden zal uw juridische strategie bepalen als AI-leveranciers de servicevoorwaarden schenden.
2. Overweeg de implementatie (of herziening) van het applicatie- en databeleid
Een applicatiebeleid zorgt voor duidelijke richtlijnen en transparantie voor uw organisatie. Een eenvoudige ‘toegestane lijst’ kan betrekking hebben op AI-tools die zijn gebouwd door zakelijke SaaS-providers, en alles wat daar niet op staat valt in het ‘niet-toegestane’ kamp. Als alternatief kunt u een databeleid opstellen dat bepaalt welke soorten gegevens werknemers in AI-tools kunnen invoeren. U kunt bijvoorbeeld verbieden dat elke vorm van intellectueel eigendom in AI-programma’s wordt ingevoerd, of dat gegevens worden gedeeld tussen uw SaaS-systemen en AI-apps.
3. Zorg voor regelmatige training en opleiding van medewerkers
Weinig werknemers zoeken naar indie-AI-tools met kwade bedoelingen. De overgrote meerderheid is zich simpelweg niet bewust van het gevaar waaraan ze uw bedrijf blootstellen als ze niet-goedgekeurde AI gebruiken.
Bied regelmatig training zodat ze de realiteit begrijpen van datalekken en inbreuken op AI-tools en wat AI-naar-SaaS-verbindingen met zich meebrengen. Trainingen dienen ook als geschikte momenten om uw beleid en softwarebeoordelingsproces uit te leggen en te versterken.
4. Stel de kritische vragen in uw leveranciersbeoordelingen
Terwijl uw team leveranciersbeoordelingen van indie AI-tools uitvoert, moet u vasthouden aan dezelfde nauwkeurigheid die u toepast op de ondernemingen die worden beoordeeld. Dit proces moet hun beveiligingshouding en naleving van de wetgeving inzake gegevensprivacy omvatten. Bespreek tussen het team dat de tool aanvraagt en de leverancier zelf vragen als:
- Wie heeft toegang tot de AI-tool? Is het beperkt tot bepaalde individuen of teams? Hebben aannemers, partners en/of klanten toegang?
- Welke personen en bedrijven hebben toegang tot aanwijzingen die bij de tool worden ingediend? Is de AI-functie afhankelijk van een derde partij, een modelaanbieder of een lokaal model?
- Verbruikt of maakt de AI-tool op enige wijze gebruik van externe input? Wat zou er gebeuren als er snelle injectieladingen in zouden worden geplaatst? Welke impact zou dat kunnen hebben?
- Kan de tool vervolgacties ondernemen, zoals wijzigingen aan bestanden, gebruikers of andere objecten?
- Heeft de AI-tool functies die mogelijk traditionele kwetsbaarheden kunnen veroorzaken (zoals de hierboven genoemde SSRF, IDOR en XSS)? Wordt de prompt of uitvoer bijvoorbeeld weergegeven waar XSS mogelijk zou kunnen zijn? Maakt de functionaliteit voor het ophalen van internet het mogelijk om interne hosts of het IP-adres van cloudmetadata te raken?
AppOmni, een SaaS-beveiligingsleverancier, heeft een reeks CISO Guides to AI Security gepubliceerd die gedetailleerdere beoordelingsvragen van leveranciers bieden, samen met inzichten in de kansen en bedreigingen die AI-tools bieden.
5. Bouw relaties op en maak uw team (en uw beleid) toegankelijk
CISO’s, beveiligingsteams en andere bewakers van AI- en SaaS-beveiliging moeten zichzelf presenteren als partners bij het navigeren door AI naar bedrijfsleiders en hun teams. De principes van hoe CISO’s van beveiliging een bedrijfsprioriteit maken, zijn terug te voeren op sterke relaties, communicatie en toegankelijke richtlijnen.
Door de impact van AI-gerelateerde datalekken en inbreuken in termen van verloren dollars en verloren kansen aan te tonen, zijn cyberrisico’s weerklank bij bedrijfsteams. Deze verbeterde communicatie is van cruciaal belang, maar het is slechts één stap. Mogelijk moet u ook de manier aanpassen waarop uw team met het bedrijf samenwerkt.
Of u nu kiest voor lijsten met toepassingen of gegevens die zijn toegestaan (of een combinatie van beide), zorg ervoor dat deze richtlijnen duidelijk zijn geschreven en direct beschikbaar zijn (en gepromoot). Wanneer werknemers weten welke gegevens in een LLM zijn toegestaan, of welke goedgekeurde leveranciers ze kunnen kiezen voor AI-tools, is de kans veel groter dat uw team wordt gezien als een stimulerende en niet als een belemmering voor de vooruitgang. Als leiders of werknemers om AI-tools vragen die buiten de grenzen vallen, begin dan het gesprek met wat ze proberen te bereiken en hun doelen. Als ze zien dat u geïnteresseerd bent in hun perspectief en behoeften, zijn ze eerder bereid om met u samen te werken aan de juiste AI-tool dan om met een indie AI-leverancier in zee te gaan.
De beste kansen om uw SaaS-stack op de lange termijn te beveiligen tegen AI-tools is het creëren van een omgeving waarin het bedrijf uw team als een hulpbron ziet en niet als een wegversperring.
