Drie tips om uw geheimen te beschermen tegen AI-ongelukken

Vorig jaar publiceerde het Open Worldwide Application Security Project (OWASP) meerdere versies van de “OWASP Top 10 For Large Language Models”, waarbij in augustus een 1.0-document werd bereikt en in oktober een 1.1-document. Deze documenten tonen niet alleen de snel evoluerende aard van grote taalmodellen aan, maar ook de evoluerende manieren waarop ze kunnen worden aangevallen en verdedigd. We gaan het in dit artikel hebben over vier items in die top 10 die het meest kunnen bijdragen aan het per ongeluk openbaar maken van geheimen zoals wachtwoorden, API-sleutels en meer.

We zijn ons er al van bewust dat LLM’s geheimen kunnen onthullen omdat het is gebeurd. Begin 2023 meldde GitGuardian dat het meer dan 10 miljoen geheimen had gevonden in openbare Github-commits. De Copilot AI-coderingstool van Github werd getraind op openbare commits, en in september 2023 publiceerden onderzoekers van de Universiteit van Hong Kong een paper over hoe ze een algoritme creëerden dat 900 aanwijzingen genereerde om Copilot ertoe te brengen geheimen uit zijn trainingsgegevens te onthullen. Toen deze aanwijzingen werden gebruikt, onthulde Copilot meer dan 2.700 geldige geheimen.

De techniek die de onderzoekers gebruiken heet ‘prompt injection’. Het staat op nummer 1 in de OWASP Top 10 voor LLM’s en zij omschrijven het als volgt: [blockquote]

“Dit manipuleert een groot taalmodel (LLM) door middel van sluwe invoer, waardoor onbedoelde acties van de LLM worden veroorzaakt. Directe injecties overschrijven systeemprompts, terwijl indirecte injecties invoer van externe bronnen manipuleren.”

Je bent misschien meer bekend met snelle injectie door de bug die vorig jaar werd onthuld en die ervoor zorgde dat ChatGPT trainingsgegevens begon uit te spugen als je hem vroeg bepaalde woorden voor altijd te herhalen.

Tip 1: Roteer uw geheimen

Zelfs als je niet denkt dat je per ongeluk geheimen op GitHub hebt gepubliceerd, zijn een aantal van de geheimen daarin vastgelegd in een vroege commit en vernield in een nieuwere commit, dus ze zijn niet meteen zichtbaar zonder je hele commitgeschiedenis te bekijken, niet alleen de huidige status van uw openbare repository’s.

Met een tool van GitGuardian, genaamd Has My Secret Leaked, kun je een huidig ​​geheim hashen en vervolgens de eerste paar tekens van de hash indienen om te bepalen of er overeenkomsten in hun database zijn van wat ze vinden in hun scans van GitHub. Een positieve match is geen garantie dat uw geheim is gelekt, maar biedt wel een mogelijke waarschijnlijkheid dat dit wel het geval is, zodat u dit verder kunt onderzoeken.

Voorbehoud bij het wisselen van sleutels/wachtwoorden is dat u moet weten waar ze worden gebruikt, wat er kapot kan gaan als ze veranderen, en dat u een plan moet hebben om die breuk te beperken terwijl de nieuwe geheimen zich verspreiden naar de systemen die ze nodig hebben. Eenmaal gerouleerd, moet u ervoor zorgen dat de oudere geheimen zijn uitgeschakeld.

Aanvallers kunnen geen geheim gebruiken dat niet meer werkt, en als de geheimen van jou die zich mogelijk in een LLM bevinden, zijn gerouleerd, worden het niets anders dan nutteloze strings met een hoge entropie.

Tip 2: Schoon uw gegevens op

Item #6 in de OWASP Top 10 voor LLM’s is “Openbaarmaking van gevoelige informatie”:

LLM’s kunnen onbedoeld vertrouwelijke gegevens onthullen in hun antwoorden, wat leidt tot ongeoorloofde gegevenstoegang, privacyschendingen en inbreuken op de beveiliging. Het is van cruciaal belang om gegevensopschoning en een strikt gebruikersbeleid te implementeren om dit te beperken.

Hoewel opzettelijk ontworpen aanwijzingen ertoe kunnen leiden dat LLM’s gevoelige gegevens onthullen, kunnen ze dit ook per ongeluk doen. De beste manier om ervoor te zorgen dat de LLM geen gevoelige gegevens onthult, is ervoor te zorgen dat de LLM deze nooit te weten komt.

Dit is meer gericht op het trainen van een LLM voor gebruik door mensen die misschien niet altijd het beste met u voor hebben of mensen die simpelweg geen toegang zouden moeten hebben tot bepaalde informatie. Of het nu uw geheimen of geheime saus zijn, alleen degenen die er toegang toe moeten hebben, mogen het hebben… en uw LLM is waarschijnlijk niet een van die mensen.

Als u open-sourcetools of betaalde services gebruikt om uw trainingsgegevens op geheimen te scannen VOORDAT u de gegevens aan uw LLM invoert, kunt u de geheimen verwijderen. Wat uw LLM niet weet, kan hij niet vertellen.

Tip 3: Regelmatig patchen en rechten beperken

Onlangs hebben we een stuk gezien over het gebruik van .env-bestanden en omgevingsvariabelen als een manier om geheimen beschikbaar te houden voor uw code, maar buiten uw code. Maar wat als uw LLM gevraagd zou kunnen worden omgevingsvariabelen te onthullen… of iets ergers te doen?

Dit combineert zowel item #2 (“onveilige verwerking van uitvoer”) als item #8 (“buitensporige keuzevrijheid”).

  • Onveilige uitvoerverwerking: Dit beveiligingslek treedt op wanneer een LLM-uitvoer zonder controle wordt geaccepteerd, waardoor back-endsystemen bloot komen te liggen. Misbruik kan leiden tot ernstige gevolgen, zoals XSS, CSRF, SSRF, escalatie van bevoegdheden of uitvoering van code op afstand.
  • Overmatige keuzevrijheid: Op LLM gebaseerde systemen kunnen acties ondernemen die tot onbedoelde gevolgen leiden. Het probleem komt voort uit overmatige functionaliteit, machtigingen of autonomie die wordt verleend aan de op LLM gebaseerde systemen.

Het is moeilijk om ze van elkaar los te maken, omdat ze elkaar erger kunnen maken. Als een LLM ertoe kan worden verleid iets te doen en de operationele context onnodige privileges heeft, wordt het potentieel van het uitvoeren van willekeurige code om grote schade aan te richten, groter.

Elke ontwikkelaar heeft de tekenfilm ‘Exploits of a Mom’ gezien waarin een jongen genaamd ‘Robert’); DROP TABLE Students; ‘` de leerlingendatabase van een school leegruimt. Hoewel een LLM slim lijkt, is hij in werkelijkheid niet slimmer dan een SQL-database. En net zoals je ‘komiek’-broer je peuterneefje ertoe aanzet slechte woorden tegen oma te herhalen, kunnen slechte input slechte resultaten veroorzaken. Beide moeten worden gezuiverd en als onbetrouwbaar worden beschouwd.

Bovendien moet u vangrails opzetten rond wat de LLM of app kan doen, rekening houdend met het principe van de minste privileges. In wezen mogen de apps die de LLM en de LLM-infrastructuur gebruiken of inschakelen geen toegang hebben tot gegevens of functionaliteit die ze niet absoluut nodig hebben, zodat ze deze niet per ongeluk in dienst van een hacker kunnen stellen.

AI kan nog steeds worden beschouwd als iets dat nog in de kinderschoenen staat, en net als bij elke baby mag het niet de vrijheid krijgen om rond te dwalen in een kamer die niet babyproof is gemaakt. LLM’s kunnen het verkeerd begrijpen, hallucineren en opzettelijk op een dwaalspoor worden gebracht. Wanneer dat gebeurt, moeten goede sloten, goede muren en goede filters helpen voorkomen dat ze toegang krijgen tot geheimen of deze onthullen.

Samengevat

Grote taalmodellen zijn een geweldig hulpmiddel. Ze zullen een revolutie teweegbrengen in een aantal beroepen, processen en industrieën. Maar zij zijn ver van een volwassen technologie, en velen adopteren deze roekeloos uit angst om achterop te raken.

Zoals je zou doen met elke baby die voldoende mobiliteit heeft ontwikkeld om in de problemen te komen, moet je hem in de gaten houden en alle kasten op slot doen waar hij niet in mag komen. Ga door met grote taalmodellen, maar wees voorzichtig.

Thijs Van der Does