Maak een dreigingsmodel voor AI-ontwikkeling

Kies een beperkt scenario

Begin met één workflow die mensen kunnen begrijpen. Bijvoorbeeld: een agent leest een issue, bewerkt een repository, voert tests uit en opent een pull request. Neem de systemen op die deze acties mogelijk maken.

Noteer de belangrijke assets: broncode, klantinformatie, toegangsgegevens, releaseartefacten en beschikbaarheid van de dienst. Identificeer hun verantwoordelijken. Identificeer vervolgens de mensen en systemen die elke asset kunnen lezen of wijzigen.

OWASP adviseert het systeem te modelleren, dreigingen te identificeren, reacties te kiezen en het resultaat te valideren. Gebruik de methode vroeg en werk het model bij als het systeem verandert. Advies voor dreigingsmodellering.

Teken de vertrouwensgrenzen

Teken voor de fictieve issue-naar-PR-workflow deze koppelingen:

Issue → agent → repository → testrunner → artefactopslag → deployment

Voeg de modelprovider en secretopslag toe. Markeer waar inhoud uit een minder vertrouwde bron komt. Markeer waar een identiteit een nieuwe capaciteit krijgt, zoals van een issue lezen naar repositorybestanden schrijven.

Het applicatiediagram alleen toont niet het volledige ontwikkelrisico. Een productiedatabase kan privé zijn terwijl een CI-job een toegangswaarde blootlegt. Neem tijdelijke omgevingen en supporttoegang mee als ze het scenario beïnvloeden.

Beschrijf een concreet foutpad

Vermijd vermeldingen als ‘AI kan onveilig zijn’. Beschrijf een actor, een actie, een getroffen asset en een gevolg. Neem de omstandigheden op die nodig zijn om het scenario te laten optreden.

Dit zijn voorbeelden, geen volledige dreigingslijst. Uw gegevens, tools en beheeromgeving bepalen de relevante scenario’s.

Kies een reactie met een verantwoordelijke

Prioriteer gevolgen en aannemelijke blootstelling. Presenteer een numerieke score niet als precisie die u niet hebt. Noteer de onzekerheid en het bewijs dat de prioriteit kan veranderen.

Een reactie kan de risicovolle mogelijkheid wegnemen, de scope beperken, een controle toevoegen of een bepaald restrisico accepteren. Acceptatie heeft een bevoegde verantwoordelijke en een reden nodig. Het mag geen ongecontroleerde conclusie van een agent zijn.

Zet de gekozen reactie om in werk met een waarneembare acceptatievoorwaarde. ‘Verbeter agentbeveiliging’ is moeilijk te verifiëren. ‘De testjob kan het productiesecret niet lezen’ definieert een controleerbare grens.

Herbeoordeel na belangrijke wijzigingen

Een nieuwe connector, modelroute, omgeving of recht kan het dreigingsmodel veranderen. Voeg deze wijzigingen toe als aanleidingen voor herbeoordeling. Gebruik ook incidenten en mislukte evaluaties om aannames bij te werken.

Probeer de risicoreviewoefening om gegevens, bevoegdheden, doelgroep en herstelvoorwaarden van een scenario te veranderen. Het resultaat stelt vragen voor. Het vervangt geen systeemspecifiek dreigingsmodel en geeft geen toestemming voor het werk.