Säkerhet för röstbotar: Hur kan företag skydda sina röstassistenter mot attacker?

Röstbotar besvarar numera kundförfrågningar, har tillgång till företagsdata och kan i vissa fall till och med genomföra affärsprocesser på egen hand. Det gör dem också till ett allt mer attraktivt mål för angripare. Alla organisationer som använder röstassistenter inom kundtjänsten bör därför ha kunskap om de risker som är förknippade med detta – och hur man kan minska dem.

Utmaningen förvärras av en ytterligare utveckling: många medarbetare använder redan sina egna AI-verktyg i det dagliga arbetet, ofta utan IT-avdelningens vetskap eller godkännande. Detta fenomen har kommit att kallas ”skugg-AI”.

Samtidigt har kunder och företag allt större förtroende för AI-genererade svar i takt med att kvaliteten på dessa system fortsätter att förbättras. Ironiskt nog gör detta växande förtroende röstbotar till ett ännu mer attraktivt mål för cyberattacker.

Vilka attacker mot röstbotar utgör egentligen ett hot?

Säkerhetsrisker kopplade till AI kan numera kategoriseras ganska snabbt. Ett av de mest kända ramverken tillhandahålls av OWASP-gemenskapen (Open Web Application Security Project). OWASP är en ideell organisation som i många år har främjat bästa praxis inom cybersäkerhet. Organisationen publicerar regelbundet sina välkända ”Top 10”-listor över säkerhetsrisker tillsammans med praktiska råd om hur man hanterar dem. På senare tid har organisationen även lanserat GenAI Security Project, som specifikt fokuserar på riskerna kopplade till generativ AI.

En av de allvarligaste riskerna som OWASP har identifierat är ”prompt injection”. Detta inträffar när en anropare använder noggrant utformade uppmaningar för att manipulera AI-systemet till att utföra åtgärder som det aldrig var avsett att utföra, till exempel att avslöja konfidentiell information eller erbjuda obehöriga rabatter. Det liknar ett bedrägeri som utförs via telefon, med den skillnaden att angriparen manipulerar ett AI-system istället för en människa. Dessa attacker utförs i allt högre grad automatiskt.

Promptinjektion är bara en av flera attackvägar. AI-modeller kan också överbelastas med förfrågningar, vilket skapar en form av överbelastningsattack. Vid överdriven belastning kan en modell uppvisa oförutsägbara fel, bortse från avsedda säkerhetsåtgärder eller generera svar som den normalt inte skulle producera. Språkmodeller kan också avslöja intern information, avslöja implementeringsdetaljer eller bearbeta innehåll som de egentligen borde avvisa helt och hållet. Se vår video

En annan viktig risk uppstår genom integrationen av AI med kunskapshanteringssystem och Retrieval-Augmented Generation (RAG). Många röstbotar förlitar sig på omfattande företagsdatabaser för att besvara specialiserade kundförfrågningar. Om dessa integrationer inte är ordentligt säkrade kan angripare eventuellt manipulera de underliggande uppgifterna, påverka modellens svar eller hämta information som aldrig borde vara tillgänglig.

Detsamma gäller integrationer med CRM- och ERP-system, liksom API:er och andra programvarugränssnitt. Dessa integrationer har länge varit en vanlig källa till sårbarheter i traditionella programvarumiljöer, och AI-systemen gör dem bara ännu viktigare. Känslig information kan läcka ut via bristfälligt säkrade gränssnitt, samtidigt som anslutna verktyg som gör det möjligt för AI-agenter att interagera med externa applikationer i allt högre grad har blivit mål för attacker. Under de senaste månaderna har forskare visat på attacker där obehörig kod har körts eller inloggningsuppgifter har extraherats via sårbara integrationer.

Utbudet av möjliga attacker är därför brett. För att skydda AI-system krävs flera försvarslager snarare än en enda säkerhetsåtgärd.

En klok utgångspunkt är att redan från början tydligt definiera AI-agentens roll och fastställa strikta gränser. Den bör inte bearbeta vissa typer av information, bevilja obehöriga rabatter eller ingå rättsligt bindande åtaganden. Beslut av det slaget bör alltid ligga under mänsklig kontroll.

Lika viktigt är en tillförlitlig verifiering av de som ringer, till exempel genom kund-ID, IBAN-verifiering eller, helst, multifaktorautentisering (MFA), där en ytterligare autentiseringsfaktor – såsom en kod som skickas till en registrerad mobilenhet – krävs. Detta minskar avsevärt risken för att automatiserade attacker lyckas.

Ingen enskild säkerhetsåtgärd är tillräcklig i sig. Ett effektivt skydd uppnås genom att kombinera flera säkerhetsåtgärder till ett flerskiktat försvar – en strategi som allmänt kallas ”försvar i djupet”. I följande avsnitt beskrivs de tre viktigaste byggstenarna i en sådan säkerhetsstrategi.

Tre sätt att skydda röstbotar på ett effektivt sätt

För att hantera dessa risker har tre tillvägagångssätt etablerats i praktiken:

• Säkerhetsfunktioner som är direkt integrerade i röstbotplattformen,
• Anpassningsbara skyddsverktyg som kan användas som en kompletterande åtgärd,
• penetrationstestning, vilket gör det möjligt att genomföra simulerade attacker för att upptäcka sårbarheter innan en verklig angripare hinner göra det.

Inbyggda säkerhetsfunktioner i röstbotplattformar

Inbyggda skyddsfunktioner är en klok utgångspunkt eftersom de är direkt integrerade i den röstbotplattform som du redan använder, utan att det krävs någon ytterligare programvara eller separata licenser. De flesta ledande plattformar har numera egna säkerhetsfunktioner som standard.

NiCE Cognigy

NiCE Cognigy erbjuder konfigurerbara säkerhetsinställningar för AI-agenter. Dessa inställningar gör det möjligt för organisationer att definiera olika kategorier av säkerhetskontroller. Dokumentationen förklarar visserligen syftet med varje kategori, men ger inte alltid detaljerad information om hur de enskilda inställningarna fungerar i praktiken. Vid driftsättning i produktionsmiljö är det därför tillrådligt att samarbeta nära med implementeringspartnern eller leverantören för att få en exakt förståelse för hur varje kontroll fungerar och hur den bör konfigureras.

Den största fördelen med inbyggda skyddsräcken är att de är integrerade direkt i plattformen. Detta medför vanligtvis endast minimal fördröjning. Vissa säkerhetsåtgärder bygger dock på ytterligare uppmaningar eller systeminstruktioner, vilket kan öka tokenförbrukningen.

Parloa

Parloa erbjuder mer detaljerad kontroll över konfigurationen av skyddsräcken. För många kategorier av skyddsräcken kan organisationer välja mellan olika skyddsnivåer, till exempel Låg, Medel eller Hög. Systemet stöder även anpassade filter, vilket gör det möjligt att definiera specifika termer, ämnen eller scenarier där boten antingen ska svara på ett annat sätt eller avsluta interaktionen.

I takt med att säkerhetsfunktionerna fortsätter att utvecklas går plattformarna alltmer bort från isolerade innehållsfilter och övergår till analys på konversationsnivå, där sammanhanget i en hel interaktion utvärderas istället för enskilda inmatningar och svar var för sig. Precis som med alla inbyggda säkerhetsfunktioner utgör dessa kontroller ett effektivt första skyddslager, även om de också kan öka tokenförbrukningen eftersom ytterligare instruktioner bearbetas parallellt med konversationen. En prompt är den indata som tillhandahålls av en användare, ett system eller en AI-agent och som instruerar en språkmodell att generera ett svar eller utföra en specifik uppgift.

Verktyg för adaptivt skydd: Cisco AI Defense

Denna typ av verktyg blir särskilt värdefulla när de inbyggda säkerhetsmekanismerna inte längre räcker till – till exempel när flera botar och plattformar behöver övervakas centralt, eller när säkerhetsteamen behöver en leverantörsoberoende överblick över olika AI-miljöer.

Ett exempel är Cisco AI Defence. Cisco har länge varit etablerat inom nätverksteknik och cybersäkerhet och har under de senaste åren utökat sitt utbud för att möta de växande säkerhetsutmaningarna i samband med AI.

En av dess viktigaste funktioner är semantisk granskning. Detta skapar ett säkerhetslager mellan AI-applikationen – till exempel en röstbot – och den stora språkmodellen (LLM). Systemet analyserar informationsflödet och kan identifiera misstänkta inmatningar, svar eller beteendemönster innan de når modellen eller användaren.

Precis som med alla mellanliggande säkerhetslager måste man ta hänsyn till latensen. Beroende på arkitekturen kan semantisk granskning medföra ytterligare bearbetningsfördröjningar. Kompatibilitet är en annan viktig faktor. Det är inte alla röstbotar eller Agentic AI-plattformar som är tillräckligt öppna för att en säkerhetslösning från tredje part ska kunna placeras direkt mellan applikationen och LLM:en. I vissa fall är integration endast möjlig via API:er, medan det i andra fall inte finns någon tillgång alls till modellen eller den underliggande textströmmen.

Ett annat viktigt skyddslager är övervakningen av anslutna API:er. Detta omfattar integrationer med kunskapsbaser, CRM- och ERP-system, kunddatabaser och andra applikationer från vilka AI:n läser data eller till vilka den skriver data.

Ciscos Runtime Protection bidrar till att säkra dessa integrationer genom att övervaka API-aktiviteten, upptäcka misstänkta åtkomstförsök och vid behov blockera skadliga åtgärder. Målet är att minimera både sannolikheten för och de potentiella konsekvenserna av att en AI-applikation utsätts för intrång.

Ytterligare funktioner – däribland Secure Access, arbetsplatsintegrationer, AI-assistenten och AgenticOps – kan ytterligare stärka en organisations säkerhetsläge. Trots detta förblir principen om ”human-in-the-loop” avgörande. I slutändan bör en mänsklig administratör behålla ansvaret för kritiska beslut, såsom att tillfälligt inaktivera en bot eller godkänna en rekommenderad åtgärd.

Damovo Managed Service: Penetrationstestning av röstbotar

Den tredje metoden är en tjänst för penetrationstestning som utvecklats av Damovo. Även om penetrationstestning för chattbotar har funnits ett tag, har motsvarande testning för röstbotar hittills varit relativt begränsad.

Anledningen är enkel. Även om en röstbot kan testas manuellt gör det enorma antalet potentiella attackvägar – som uppskattas till omkring 500 – att en omfattande testning blir både tidskrävande och resurskrävande. Dessutom måste attackkommandona anpassas efter den specifika branschen, oavsett om det gäller bank-, försäkrings- eller hälso- och sjukvårdssektorn eller någon annan bransch.

Damovo följer därför en strukturerad metodik. Processen inleds med att man tar fram testfrågor som är anpassade efter kundens bransch. Dessa frågor kopplas sedan till de relevanta riskkategorierna i OWASP GenAI.

En automatiserad testbot ringer sedan upp mål-voiceboten. Efter den inledande hälsningen och, i förekommande fall, autentiseringsprocessen, genomförs de fördefinierade testdialogerna. Båda sidorna i samtalet spelas in separat, vilket gör det möjligt att analysera frågorna och voicebotens svar var för sig.

Varje testdialog transkriberas och kompletteras med metadata, vilket skapar en fullständig och spårbar dokumentation. En AI-stödd analys avgör sedan om den simulerade attacken lyckades, om röstboten korrekt blockerade förfrågan eller om den avslöjade information som borde ha förblivit skyddad.

Kunden får en detaljerad rapport som kopplar resultaten till de relevanta OWASP GenAI-riskkategorierna och innehåller underlag för varje identifierad sårbarhet.

Vad det kostar och hur mycket arbete det innebär

Kostnader

För röstbotar som redan är i bruk medför inbyggda säkerhetsmekanismer vanligtvis inga direkta merkostnader. De kan dock leda till indirekta kostnader genom ökad tokenförbrukning. För närvarande är det svårt att exakt kvantifiera den extra förbrukningen, eftersom det finns få publicerade uppgifter om ämnet. I takt med att säkerhetsfunktionerna fortsätter att utvecklas är det dock troligt att mer avancerade funktioner kommer att kräva ytterligare licenser – till exempel när en separat stor språkmodell (LLM) analyserar sammanhanget i en hel konversation i bakgrunden.

Verktyg för adaptivt skydd är lösningar av företagsklass och medför vanligtvis kostnader för implementering, underhåll och licensiering. Beroende på leverantör och omfattningen av implementeringen kan dessa kostnader bli betydligt högre än kostnaderna för inbyggda plattformsfunktioner.

Den hanterade tjänsten för penetrationstest är främst avsedd för engångsbedömningar och är i allmänhet betydligt mer kostnadseffektiv än att permanent installera säkerhetsprogramvara för företag. Att ta fram realistiska testscenarier kräver dock att de skräddarsys både efter den aktuella branschen och organisationens specifika användningsfall, vilket ökar projektets initiala kostnad.

Huruvida sådana tester genomförs som en engångsåtgärd, efter införandet av en ny funktion eller regelbundet beror på organisationens säkerhetskrav och riskprofil.

Underhållsinsats

De tre metoderna skiljer sig också åt när det gäller den löpande underhållsinsatsen. Integrerade skyddsräcken kräver mycket lite underhåll eftersom de redan är inbyggda i plattformen. Adaptiva skyddsverktyg medför en medelstor till stor insats, särskilt under den inledande implementeringsfasen. Penetrationstestning kräver en måttlig insats, främst på grund av behovet av branschspecifik anpassning.

Fördröjning

De tre metoderna skiljer sig också åt när det gäller latens. Integrerade skyddsmekanismer är vanligtvis inbyggda i själva plattformen och medför därför endast minimala fördröjningar. Adaptiva skyddsverktyg kan medföra ytterligare latens, beroende på den underliggande arkitekturen och integrationsmetoden. Penetrationstester bör i allmänhet genomföras utanför normal arbetstid för att undvika att störa användarnas dagliga verksamhet.

Varför just detta ämne blir allt viktigare just nu

En viktig drivkraft bakom denna utveckling är den växande efterfrågan på spårbarhet. Krav som NIS2 och DORA har redan blivit etablerade fokusområden, och till dessa kommer nu behovet av att utvärdera AI-hanteringssystem i enlighet med standarden ISO 42001. Följaktligen måste allt fler organisationer kunna visa att deras chattbotar och röstbotar genomgår regelbundna säkerhetsutvärderingar och revisioner.

Det är här skillnaderna mellan de tre metoderna blir särskilt tydliga. Integrerade säkerhetsmekanismer är relativt begränsade på detta område, eftersom de ofta endast erbjuder begränsad dokumentation och begränsad insyn i hur beslut fattas. Adaptiva verktyg erbjuder betydligt mer rapportering och insikt, även om deras kapacitet fortfarande är beroende av de specifika funktionerna och begränsningarna hos den lösning som används. Den hanterade penetrationstestningstjänsten kan däremot skräddarsys mycket mer flexibelt – till exempel beroende på om en kund vill testa 10, 100 eller 500 attackvektorer – och ger därför den mest omfattande och transparenta dokumentationen.

De tre metoderna skiljer sig också åt när det gäller kvarstående risk. Beroende på hur de är konfigurerade är integrerade skyddsmekanismer i sig vanligtvis förknippade med en medelhög till hög nivå av kvarstående risk. Adaptiva verktyg kan minska denna risk avsevärt genom att i bakgrunden tillämpa etablerade säkerhetskontroller av företagsklass. Hanterade penetrationstester ger den mest realistiska bedömningen, eftersom testerna utförs mot aktiva system med hjälp av realistiska attackscenarier och interaktioner, vilket resulterar i den lägsta kvarstående risken.

Slutsats: Flera försvarslager istället för en enda lösning

Slutsatsen är i slutändan att detta inte är ett antingen-eller-beslut. Röstbotar bör skyddas genom flera skyddslager: skyddsräcken utgör den första försvarslinjen, anpassningsbara verktyg ger ytterligare skydd och penetrationstester i realtid utvärderar hur motståndskraftiga dessa säkerhetsåtgärder faktiskt är.

Denna flernivåstrategi säkerställer att om en säkerhetsåtgärd inte fungerar, så förhindras antingen att attacken fortskrider eller så minskas de potentiella konsekvenserna avsevärt.

Organisationer som vill minimera den kvarvarande risken så mycket som möjligt bör därför beakta alla tre nivåerna tillsammans, snarare än att genomföra enskilda åtgärder var för sig. Företag som vill förstå hur säker deras egen röstbot egentligen är kan utvärdera detta genom ett administrerat penetrationstest som tillhandahålls av Damovo.