Beveiliging van spraakbots: hoe kunnen bedrijven hun spraakassistenten tegen aanvallen beschermen?

Spraakbots beantwoorden tegenwoordig vragen van klanten, hebben toegang tot bedrijfsgegevens en voeren in sommige gevallen zelfs zelfstandig bedrijfsprocessen uit. Daardoor worden ze ook een steeds aantrekkelijker doelwit voor aanvallers. Elke organisatie die spraakassistenten inzet voor de klantenservice, moet zich daarom bewust zijn van de bijbehorende risico’s – en weten hoe deze kunnen worden beperkt.

Deze uitdaging wordt nog vergroot door een tweede ontwikkeling: veel medewerkers gebruiken in hun dagelijkse werk al hun eigen AI-tools, vaak zonder dat de IT-afdeling hiervan op de hoogte is of hiermee heeft ingestemd. Dit fenomeen staat bekend als ‘schaduw-AI’.

Tegelijkertijd stellen klanten en bedrijven steeds meer vertrouwen in door AI gegenereerde antwoorden, naarmate de kwaliteit van deze systemen blijft verbeteren. Ironisch genoeg maakt dat groeiende vertrouwen voicebots tot een nog aantrekkelijker doelwit voor cyberaanvallen.

Welke aanvallen op voicebots vormen echt een bedreiging?

Beveiligingsrisico’s die verband houden met AI kunnen tegenwoordig vrij snel worden ingedeeld. Een van de bekendste kaders wordt aangeboden door de OWASP-gemeenschap (Open Web Application Security Project). OWASP is een non-profitorganisatie die zich al vele jaren inzet voor het bevorderen van best practices op het gebied van cyberbeveiliging. De organisatie publiceert regelmatig haar bekende Top 10-lijsten met beveiligingsrisico’s, samen met praktische richtlijnen om deze aan te pakken. Onlangs heeft de organisatie ook het GenAI Security Project gelanceerd, dat zich specifiek richt op de risico’s die gepaard gaan met generatieve AI.

Een van de belangrijkste risico’s die door OWASP zijn geïdentificeerd, is prompt-injectie. Dit gebeurt wanneer een beller zorgvuldig opgestelde prompts gebruikt om de AI te manipuleren, zodat deze acties uitvoert waarvoor deze nooit bedoeld was, zoals het vrijgeven van vertrouwelijke informatie of het aanbieden van ongeoorloofde kortingen. Het is vergelijkbaar met een oplichtingstruc die via de telefoon wordt uitgevoerd, met dit verschil dat de aanvaller een AI-systeem manipuleert in plaats van een mens. Deze aanvallen worden steeds vaker automatisch uitgevoerd.

Prompt-injectie is slechts één van de vele aanvalsvectoren. AI-modellen kunnen ook worden overbelast met verzoeken, wat een vorm van denial-of-service-aanval veroorzaakt. Bij overmatige belasting kan een model onvoorspelbaar falen, beoogde beveiligingsmaatregelen negeren of reacties genereren die het normaal gesproken niet zou produceren. Taalmodellen kunnen ook interne informatie blootgeven, implementatiedetails onthullen of inhoud verwerken die ze volledig zouden moeten afwijzen. Bekijk onze video

Een ander belangrijk risico vloeit voort uit de integratie van AI met kennisbeheersystemen en Retrieval-Augmented Generation (RAG). Veel spraakbots maken gebruik van uitgebreide kennisdatabases van bedrijven om gespecialiseerde vragen van klanten te beantwoorden. Als deze integraties niet goed beveiligd zijn, kunnen aanvallers mogelijk de onderliggende gegevens manipuleren, de reacties van het model beïnvloeden of informatie opvragen die nooit toegankelijk zou mogen zijn.

Hetzelfde geldt voor integraties met CRM- en ERP-systemen, evenals API’s en andere software-interfaces. Deze integraties vormen al lang een veelvoorkomende bron van kwetsbaarheden in traditionele softwareomgevingen, en AI-systemen vergroten het belang ervan alleen maar. Gevoelige informatie kan via slecht beveiligde interfaces uitlekken, terwijl gekoppelde tools waarmee AI-agenten met externe applicaties kunnen communiceren, in toenemende mate het doelwit van aanvallen zijn geworden. De afgelopen maanden hebben onderzoekers aanvallen gedemonstreerd waarbij ongeautoriseerde code werd uitgevoerd of inloggegevens werden ontfutseld via kwetsbare integraties.

Het scala aan mogelijke aanvallen is dan ook breed. Om AI-systemen te beveiligen zijn meerdere verdedigingslagen nodig, in plaats van één enkele beveiligingsmaatregel.

Een verstandig uitgangspunt is om de rol van de AI-agent vanaf het begin duidelijk te omschrijven en strikte grenzen vast te stellen. De agent mag bepaalde categorieën informatie niet verwerken, geen ongeoorloofde kortingen toekennen en geen juridisch bindende toezeggingen doen. Beslissingen van die aard moeten altijd onder menselijke controle blijven.

Even belangrijk is de betrouwbare verificatie van bellers, bijvoorbeeld via klantidentificatiegegevens, IBAN-verificatie of, bij voorkeur, meervoudige authenticatie (MFA), waarbij een extra authenticatiefactor – zoals een code die naar een geregistreerd mobiel apparaat wordt verzonden – vereist is. Dit vermindert de kans dat geautomatiseerde aanvallen slagen aanzienlijk.

Geen enkele beveiligingsmaatregel is op zichzelf voldoende. Effectieve bescherming ontstaat door meerdere beveiligingsmaatregelen te combineren tot een gelaagde verdediging – een aanpak die algemeen bekendstaat als ‘defence in depth’. In de volgende paragrafen worden de drie belangrijkste bouwstenen van een dergelijke beveiligingsstrategie beschreven.

Drie manieren om voicebots effectief te beveiligen

Om deze risico’s aan te pakken, hebben zich in de praktijk drie benaderingen doorgezet:

• Veiligheidsmaatregelen die rechtstreeks in het voicebot-platform zijn geïntegreerd,
• Adaptieve beveiligingsinstrumenten die als aanvullende maatregel kunnen worden ingezet,
• penetratietesten, waarmee gesimuleerde aanvallen kunnen worden uitgevoerd om kwetsbaarheden aan het licht te brengen voordat een echte aanvaller dat doet.

Geïntegreerde veiligheidsmaatregelen in voicebot-platforms

Ingebouwde beveiligingsmaatregelen zijn een verstandig uitgangspunt, omdat ze rechtstreeks zijn geïntegreerd in het voicebot-platform dat u al gebruikt, zonder dat er extra software of aparte licenties voor nodig zijn. De meeste toonaangevende platforms beschikken tegenwoordig standaard over eigen beveiligingsmaatregelen.

NiCE Cognigy

NiCE Cognigy biedt configureerbare veiligheidsinstellingen voor AI-agenten. Met deze instellingen kunnen organisaties verschillende categorieën veiligheidsmaatregelen definiëren. Hoewel in de documentatie het doel van elke categorie wordt uitgelegd, wordt niet altijd gedetailleerde informatie gegeven over hoe individuele instellingen in de praktijk werken. Voor implementaties in de productieomgeving is het daarom raadzaam om nauw samen te werken met de implementatiepartner of de leverancier om precies te begrijpen hoe elke maatregel werkt en hoe deze moet worden geconfigureerd.

Het belangrijkste voordeel van ingebouwde veiligheidsbarrières is dat ze rechtstreeks in het platform zijn geïntegreerd. Dit leidt doorgaans slechts tot minimale vertraging. Sommige veiligheidsmaatregelen zijn echter afhankelijk van extra vragen of systeeminstructies, wat het verbruik van tokens kan verhogen.

Parloa

Parloa biedt meer gedetailleerde controle over de configuratie van de veiligheidsbarrière. Voor veel categorieën veiligheidsbarrières kunnen organisaties kiezen uit verschillende beschermingsniveaus, zoals Laag, Gemiddeld of Hoog. Het ondersteunt ook aangepaste filters, waarmee specifieke termen, onderwerpen of scenario’s kunnen worden gedefinieerd waarin de bot anders moet reageren of de interactie moet beëindigen.

Naarmate de mogelijkheden van veiligheidsmaatregelen zich verder ontwikkelen, gaan platforms steeds vaker verder dan geïsoleerde inhoudsfilters en richten ze zich op analyse op gespreksniveau, waarbij de context van een volledige interactie wordt beoordeeld in plaats van afzonderlijke prompts en reacties op zichzelf. Net als bij alle ingebouwde veiligheidsmaatregelen bieden deze controles een effectieve eerste beschermingslaag, hoewel ze ook het tokenverbruik kunnen verhogen omdat er naast het gesprek extra instructies worden verwerkt. Een prompt is de invoer die door een gebruiker, systeem of AI-agent wordt verstrekt en die een taalmodel opdracht geeft om een antwoord te genereren of een specifieke taak uit te voeren.

Adaptieve beveiligingstools: Cisco AI Defense

Dit soort tools zijn vooral van grote waarde wanneer ingebouwde beveiligingsmaatregelen alleen niet langer volstaan – bijvoorbeeld wanneer meerdere bots en platforms centraal moeten worden bewaakt, of wanneer beveiligingsteams behoefte hebben aan leveranciersonafhankelijk toezicht op verschillende AI-omgevingen.

Een voorbeeld hiervan is Cisco AI Defence. Cisco is al jarenlang een gevestigde naam op het gebied van netwerken en cyberbeveiliging en heeft zijn portfolio de afgelopen jaren uitgebreid om de groeiende beveiligingsuitdagingen in verband met AI het hoofd te bieden.

Een van de belangrijkste functies is semantische inspectie. Hiermee wordt een beveiligingslaag aangebracht tussen de AI-toepassing – bijvoorbeeld een spraakbot – en het grote taalmodel (LLM). Het systeem analyseert de informatiestroom en kan verdachte vragen, antwoorden of gedragspatronen herkennen voordat deze het model of de gebruiker bereiken.

Zoals bij elke tussenliggende beveiligingslaag moet rekening worden gehouden met latentie. Afhankelijk van de architectuur kan semantische inspectie extra verwerkingsvertragingen veroorzaken. Compatibiliteit is een andere belangrijke factor. Niet elke voicebot of elk Agentic AI-platform is voldoende open om een beveiligingsoplossing van een derde partij rechtstreeks tussen de applicatie en het LLM te plaatsen. In sommige gevallen is integratie alleen mogelijk via API’s, terwijl er in andere gevallen helemaal geen toegang is tot het model of de onderliggende tekststroom.

Een andere belangrijke beveiligingslaag is het toezicht op gekoppelde API’s. Hieronder vallen integraties met kennisbanken, CRM- en ERP-systemen, klantendatabases en andere applicaties waaruit de AI gegevens ophaalt of waarnaar hij gegevens schrijft.

Cisco’s Runtime Protection helpt deze integraties te beveiligen door API-activiteit te monitoren, verdachte toegangs pogingen te detecteren en waar nodig kwaadaardige acties te blokkeren. Het doel is om zowel de kans op als de mogelijke gevolgen van een gecompromitteerde AI-toepassing tot een minimum te beperken.

Extra functies – waaronder Secure Access, integraties met werkplekken, AI Assistant en AgenticOps – kunnen de beveiligingspositie van een organisatie verder versterken. Toch blijft het ‘human-in-the-loop’-principe van essentieel belang. Uiteindelijk moet een menselijke beheerder de verantwoordelijkheid behouden voor cruciale beslissingen, zoals het tijdelijk uitschakelen van een bot of het goedkeuren van een aanbevolen actie.

Damovo Managed Service: Penetratietesten voor spraakbots

De derde aanpak is een door Damovo ontwikkelde dienst voor penetratietesten. Hoewel er al enige tijd penetratietesten voor chatbots beschikbaar zijn, zijn vergelijkbare tests voor voicebots tot nu toe relatief beperkt gebleven.

De reden hiervoor is duidelijk. Hoewel een voicebot handmatig kan worden getest, maakt het enorme aantal mogelijke aanvalsvectoren – naar schatting zo’n 500 – het uitvoeren van uitgebreide tests zowel tijdrovend als arbeidsintensief. Bovendien moeten de aanvalsscenario’s worden afgestemd op de specifieke sector, of het nu gaat om het bankwezen, de verzekeringssector, de gezondheidszorg of een andere sector.

Damovo hanteert daarom een gestructureerde aanpak. Het proces begint met het opstellen van testvragen die zijn afgestemd op de branche van de klant. Deze vragen worden vervolgens gekoppeld aan de relevante OWASP GenAI-risicocategorieën.

Vervolgens belt een geautomatiseerde testbot de betreffende voicebot. Na de openingsgroet en, indien van toepassing, het authenticatieproces, worden de vooraf gedefinieerde testdialogen uitgevoerd. Beide kanten van het gesprek worden afzonderlijk opgenomen, waardoor de vragen en de antwoorden van de voicebot onafhankelijk van elkaar kunnen worden geanalyseerd.

Elk testgesprek wordt getranscribeerd en aangevuld met metagegevens, waardoor een volledig en controleerbaar bewijstraject ontstaat. Vervolgens wordt aan de hand van een AI-gestuurde analyse vastgesteld of de gesimuleerde aanval succesvol was, of de voicebot het verzoek correct heeft geblokkeerd, of dat er informatie is vrijgegeven die vertrouwelijk had moeten blijven.

De klant ontvangt een gedetailleerd rapport waarin de bevindingen worden gekoppeld aan de relevante OWASP GenAI-risicocategorieën en waarin het ondersteunende bewijsmateriaal voor elke geïdentificeerde kwetsbaarheid is opgenomen.

Wat het allemaal kost en hoeveel werk erbij komt kijken

Kosten

Voor voicebots die momenteel in gebruik zijn, brengen ingebouwde veiligheidsmaatregelen doorgaans geen directe extra kosten met zich mee. Ze kunnen echter wel leiden tot indirecte kosten door een hoger tokenverbruik. Op dit moment is het moeilijk om het extra verbruik nauwkeurig te kwantificeren, aangezien er weinig gepubliceerde gegevens over dit onderwerp beschikbaar zijn. Naarmate de mogelijkheden van beveiligingsmaatregelen zich verder ontwikkelen, is het echter waarschijnlijk dat voor geavanceerdere functies aanvullende licenties nodig zullen zijn – bijvoorbeeld wanneer een afzonderlijk groot taalmodel (LLM) op de achtergrond de context van een volledig gesprek analyseert.

Adaptieve beveiligingstools zijn oplossingen op bedrijfsniveau en brengen doorgaans implementatie-, onderhouds- en licentiekosten met zich mee. Afhankelijk van de leverancier en de omvang van de implementatie kunnen deze kosten aanzienlijk hoger uitvallen dan die van ingebouwde platformfuncties.

De dienst voor beheerde penetratietests is in de eerste plaats bedoeld voor eenmalige beoordelingen en is over het algemeen veel kosteneffectiever dan het permanent implementeren van bedrijfsbeveiligingssoftware. Het ontwikkelen van realistische testscenario’s vereist echter dat deze zowel op de betreffende sector als op de specifieke gebruikssituaties van de organisatie worden afgestemd, wat de initiële projectkosten verhoogt.

Of dergelijke tests eenmalig worden uitgevoerd, na de invoering van een nieuwe functie, of op regelmatige basis, hangt af van de beveiligingsvereisten en het risicoprofiel van de organisatie.

Onderhoudsinspanning

De drie benaderingen verschillen ook wat betreft de inspanningen die nodig zijn voor het lopende onderhoud. Geïntegreerde beveiligingsmaatregelen vergen zeer weinig onderhoud, omdat ze al in het platform zijn ingebouwd. Adaptieve beveiligingsinstrumenten vergen een gemiddelde tot hoge mate van inspanning, met name tijdens de eerste implementatiefase. Penetratietesten vergen een matige mate van inspanning, voornamelijk vanwege de noodzaak tot branchespecifieke aanpassingen.

Vertraging

De drie benaderingen verschillen ook wat betreft de latentie. Geïntegreerde beveiligingsmaatregelen zijn doorgaans in het platform zelf ingebouwd en veroorzaken daarom slechts minimale vertragingen. Adaptieve beveiligingstools kunnen extra latentie veroorzaken, afhankelijk van de onderliggende architectuur en de integratiemethode. Penetratietests moeten over het algemeen buiten de normale kantooruren worden uitgevoerd om verstoring van de dagelijkse werkzaamheden van gebruikers te voorkomen.

Waarom dit onderwerp op dit moment aan belang wint

Een belangrijke drijfveer achter deze ontwikkeling is de groeiende vraag naar traceerbaarheid. Vereisten zoals NIS2 en DORA zijn inmiddels vaste aandachtspunten geworden, en daar komt nu de noodzaak bij om AI-beheersystemen te beoordelen volgens de ISO 42001-norm. Als gevolg daarvan moeten steeds meer organisaties aantonen dat hun chatbots en voicebots regelmatig worden onderworpen aan beveiligingsbeoordelingen en -audits.

Hier komen de verschillen tussen de drie benaderingen bijzonder duidelijk naar voren. Geïntegreerde beveiligingsmaatregelen zijn op dit gebied relatief beperkt, aangezien ze vaak slechts beperkte documentatie bieden en weinig inzicht geven in hoe beslissingen tot stand komen. Adaptieve tools bieden aanzienlijk meer rapportagemogelijkheden en inzicht, hoewel hun mogelijkheden afhankelijk blijven van de specifieke functies en beperkingen van de gebruikte oplossing. De beheerde penetratietestdienst kan daarentegen veel flexibeler worden afgestemd – bijvoorbeeld of een klant 10, 100 of 500 aanvalsvectoren wil testen – en biedt daardoor het meest uitgebreide en transparante bewijsmateriaal.

De drie benaderingen verschillen ook wat betreft het restrisico. Afhankelijk van hun configuratie gaan geïntegreerde beveiligingsmaatregelen op zichzelf doorgaans gepaard met een gemiddeld tot hoog restrisico. Adaptieve tools kunnen dit risico aanzienlijk verminderen door op de achtergrond beproefde beveiligingsmaatregelen op bedrijfsniveau toe te passen. Beheerde penetratietests bieden de meest realistische beoordeling, omdat de tests worden uitgevoerd op live systemen met behulp van realistische aanvalsscenario’s en interacties, wat resulteert in het laagste restrisico.

Conclusie: een meerlaagse beveiliging in plaats van één enkele oplossing

Uiteindelijk komt men tot de conclusie dat dit geen keuze is tussen het een of het ander. Voicebots moeten via meerdere lagen worden beveiligd: beveiligingsmaatregelen vormen de eerste verdedigingslinie, adaptieve tools bieden extra bescherming en penetratietests in realtime toetsen hoe veerkrachtig deze beveiligingsmaatregelen daadwerkelijk zijn.

Deze gelaagde aanpak zorgt ervoor dat, mocht één beveiligingsmaatregel falen, de aanval wordt tegengehouden of de mogelijke gevolgen aanzienlijk worden beperkt.

Organisaties die het restrisico zo veel mogelijk willen beperken, moeten daarom alle drie de lagen in hun geheel in ogenschouw nemen, in plaats van afzonderlijke maatregelen los van elkaar te implementeren. Bedrijven die willen weten hoe veilig hun eigen voicebot werkelijk is, kunnen dit laten beoordelen via een door Damovo verzorgde beheerde penetratietest.