Kwaadaardige AI-programma's dwingen ons ertoe: Zero Trust moet ook op de code worden toegepast.

Softwarebeveiliging is altijd gebaseerd geweest op menselijke ontwikkeling. Vroeger schreven, beoordeelden en publiceerden mensen code. Nu nemen machines deze taken over.

In een recent onderzoeksrapport meldde Anthropic dat meer dan 80% van de code in hun productiviteitsdatabase is geschreven door hun AI- model, Cloud.

Dezelfde mogelijkheden die de productiviteit van ontwikkelaars verhogen, veranderen ook de economie van cyberaanvallen.

Terwijl tegenstanders het doelwit nog aan het identificeren zijn, kunnen machines kwaadaardige payloads genereren, varianten testen, code aanpassen aan verschillende omgevingen en dit proces herhalen met een snelheid die beveiligingssoftware niet kan bijhouden.

Snelheid overschrijft de veiligheidsregeling.

De meeste workflows voor softwarebeveiliging binnen bedrijven gaan uit van een beoordelingsperiode. Code wordt geschreven, gecontroleerd, getest, goedgekeurd en geïmplementeerd. Als er later iets verdachts gebeurt, onderzoeken beveiligingsteams de zaak en nemen ze actie.

Dit model faalt wanneer het programma binnen enkele minuten van louter begeleiding overgaat naar uitvoering.

Door AI gegenereerde code kan vrijwel direct worden omgezet in scripts, afhankelijkheden, automatiseringstaken of infrastructuurwijzigingen. Tegelijkertijd kunnen ontwikkelagents bestanden aanpassen, pakketten oplossen en commando's uitvoeren.

Menselijke beoordelaars maken geen deel meer uit van het proces.

Aanvallers kunnen dezelfde mechanismen gebruiken om kwetsbaarheden te creëren, ontwijktechnieken te testen en het gedrag van kwaadaardige payloads aan te passen voor verschillende doelen. Dit zorgt voor meer veelzijdigheid met minder stabiele indicatoren die verdedigers kunnen identificeren.

Hoewel AI-gestuurde analyses de screening kunnen verbeteren, leveren ze vaak waarschijnlijkheden op in plaats van beleid. En op machinesnelheid is "waarschijnlijk verdacht" niet voldoende. Daarom wordt de behoefte aan regels en kaders voor AI-governance steeds urgenter.

Machines veranderen het aanvalsmodel.

Menselijke aanvallers zullen niet verdwijnen, maar een groter deel van de aanvalsketen wordt nu door machines uitgevoerd.

Kunstmatige intelligentie kan verkenning automatiseren, de ontdekking van kwetsbaarheden versnellen, exploitcode genereren, kwaadaardige payloads herschrijven en commandoreeksen aanpassen aan de doelomgeving. De meeste verdedigingsmaatregelen zijn echter gebaseerd op menselijke beperkingen: hergebruikte infrastructuur, snelkoppelingen en traceerbare patronen. Deze zijn niet van toepassing op aanvallen door machines.

De kwaadaardige payload die door de machine wordt gegenereerd, komt mogelijk niet overeen met een bekende signatuur of heeft geen gevestigde reputatie. Deze kan worden aangemaakt, kortstondig worden gebruikt en vervolgens worden verwijderd. Maar AI-gestuurde malware moet interactie hebben met de doelomgeving om zijn doel te bereiken. Het gedrag ervan mag zijn intentie niet verbergen; het moet toegang krijgen tot resources en de omgeving zodanig veranderen dat de aanval wordt bevorderd.

Wat kwaadaardige code kan doen, is het meest hardnekkige beveiligingssignaal creëren.

De beveiligingsafdeling moet een andere vraag stellen.

De beveiliging van de softwareleveringsketen is verbeterd, maar er wordt nog steeds vooral gecontroleerd op impactkenmerken vóór de uitvoering, in plaats van de uitvoering zelf te controleren.

Softwarecomponentlijsten (SBOM's), signatures en broncode geven beveiligingsteams meer vertrouwen in de samenstelling, herkomst en bouwdatum van de code. Kennis van de broncode onthult echter niet wat het programma zal doen wanneer het wordt uitgevoerd.

Een programma kan al deze controles doorstaan ​​en toch risico's creëren. Zelfs de impact van een legitiem bouwproces kan tijdens de uitvoering in strijd zijn met het beleid, terwijl een door AI gegenereerd script zijn beoogde taak kan voltooien op een manier die gegevens of systemen in gevaar brengt. Een schone afhankelijkheidslijst is daarom geen bewijs van veilig gedrag, wat het belang benadrukt van het niet schenden van programmeerstandaarden, zelfs niet met AI-tools.

De openbaarmaking na de implementatie komt te laat.

Detectie en respons blijven noodzakelijk, maar ze grijpen pas in nadat de dreiging de omgeving al is binnengedrongen. Tegen de tijd dat verdacht gedrag zichtbaar wordt, kan de malware al toegang hebben gekregen tot vertrouwelijke informatie, systeemstatussen hebben gewijzigd, netwerkverbindingen hebben geopend of continuïteitspunten hebben gecreëerd.

Kunstmatige intelligentie verkort deze tijdspanne aanzienlijk. Code kan veel sneller worden gemaakt, aangepast en geïmplementeerd dan dat mensen deze kunnen controleren. Wachten op bewijsmateriaal na de uitvoering geeft aanvallers veel manoeuvreerruimte.

We moeten het besluitvormingsproces naar een eerder stadium verplaatsen. In plaats van te vragen: "Kunnen we deze software in bedwang houden als deze zich misdraagt?", zouden we ons moeten afvragen: "Moeten we dit gedrag überhaupt toestaan?"

Dit betekent niet dat de bestaande controles vervangen moeten worden, maar dat de locatie van de cruciale beveiligingspoort verplaatst moet worden.

Nul vertrouwen in programmeerinstructies

Het Zero Trust-principe heeft de beveiliging van organisaties getransformeerd door impliciet vertrouwen af ​​te wijzen. Gebruikers, apparaten, sessies en toegangsverzoeken worden niet zomaar vertrouwd omdat ze bekend lijken; ze moeten allemaal worden geverifieerd aan de hand van vastgestelde beleidsregels.

Software-implementatie vereist hetzelfde niveau van verificatie.

Code mag niet zomaar vertrouwd worden omdat het afkomstig is van een bekende repository, ondertekend is door een erkende uitgever, een build-pipeline heeft doorlopen of in het verleden geen kwaadaardig gedrag heeft vertoond. Dit zijn nuttige indicatoren, maar ze zijn niet doorslaggevend.

Het Zero Trust for Code-principe pakt dit probleem aan. Voordat een programma wordt uitgevoerd, moet het verwachte gedrag ervan worden geëvalueerd aan de hand van het beleid. Als het gedrag acceptabel is, kan de uitvoering doorgaan. Zo niet, dan moet het element worden geblokkeerd, beperkt, in quarantaine geplaatst of doorgestuurd voor beoordeling. Deze noodzaak benadrukt het belang van het vaststellen van duidelijke regels en kaders voor kunstmatige intelligentie die verder gaan dan louter beleid.

Organisaties kunnen beginnen met het definiëren van elk pad waarlangs code de omgeving binnenkomt of met aanzienlijke privileges wordt uitgevoerd. Dit omvat formele ontwikkelingskanalen zoals repositories, open-sourcepakketten, containers en continuous integration/continuous deployment (CI/CD)-pipelines, maar ook e-mailbijlagen, gedownloade bestanden, macro's, browserextensies, endpoint-installatieprogramma's, integraties met derden en scripts die worden geïnjecteerd via AI- of automatiseringstools.

Vervolgens is het cruciaal om te bepalen waar deze processen afhankelijk zijn van overgeërfd vertrouwen. Als uitvoering is toegestaan ​​omdat de software afkomstig is van een vertrouwde bron, is ondertekend, een bouwproces heeft doorlopen of geen kwaadaardige geschiedenis heeft, is deze controle onvolledig. Het gedrag moet nog steeds worden geëvalueerd voordat het element mag worden uitgevoerd. Dit benadrukt ook de kwetsbaarheid voor kwetsbaarheden die voortkomen uit de toenemende afhankelijkheid van AI-leveranciers.

Naarmate kunstmatige intelligentie steeds meer taken op zich neemt voor het creëren van zowel legitieme als kwaadaardige code, kunnen organisaties er niet langer vanuit gaan dat code die de huidige controles doorstaat, zomaar mag worden uitgevoerd. Implementatie moet een weloverwogen beveiligingsbeslissing worden.

We hebben de beste internetbeveiligingspakketten voor pc's, Macs en mobiele apparaten op een rijtje gezet.