Det viktigste vi kan gjøre før vi skriver en eneste kodelinje er å blie enige om ansvarsfordelingen mellom oss og kunden, samt klassifiseringen av løsning og data: Hvilke krav stiller kunden og hvilke krav kommer fra lovverk eller andre parter? Kompetanse innenfor applikasjonssikkerhet (AppSec) bør være på banen allerede i denne fasen for å sikre at en ivaretar krav og forventninger til sikkerhet.
Vi må også vite hva vi gjør ~~dersom~~når det oppstår en sikkerhetshendelse - hvilke krav står vi ovenfor, hva må til for at disaster recovery, backup og liknende skal lykkes, og hva vil konsekvensene av nedetid være for kunden?
1 - Ansvarsfordeling
Manglende klarhet i hvem som er ansvarlig for hva kan få store konsekvenser. Dette gjelder alle prosjekter, men er spesielt viktig dersom andre selskaper enn oss og kunden er involvert. Å ha en tydelig ansvarsfordeling med tilhørende varslingsrutiner og roller er avgjørende.
Bouvet gjennomfører utviklingsprosjekter på mange ulike måter, der vi tar mer eller mindre ansvar for prosjektledelse, planlegging, utviklingsfasen, kvalitetssikring og ikke minst drift og forvaltning av løsningen. Vi har også ulike innslag av eget, kundens og tredjepartsutstyr, både under utvikling og forvaltning av løsningen.
Uavhengig av hvordan prosjektet gjennomføres er det viktig at vi har kontroll på ansvarsfordelingen. Denne skal være regulert i avtalen med kunden, og vi må sikre at vi
Har kontroll på ansvar og rollefordeling
At vi har kontaktpunkt hos alle involverte parter
Kan følge opp avvik raskt slik at vi unngår misforståelser eller problemer senere i prosjektløpet
Viktig
Rollen leveranseansvarlig har ansvar for sikkerheten i leveransen, og er ansvarlig for at dette følges opp.
Utvikling, Drift og forvaltning av løsning
Bouvet
Prosjektet kan også komme inn under våre ISO-sertifiseringer. Dette gjelder spesielt dersom vi benytter vårt utstyr eller infrastruktur til utvikling, drift eller forvaltning på vegne av kunden. Dersom dette er tilfelle medfører det at vi har et større helhetlig ansvar for sikkerheten rundt løsningen, og det er viktig at leveranseteamet er klar over dette.
Alle ressurser driftet av leveranseteamet må håndteres på linje med all annen infrastruktur, så teamet må ha rutiner for patching og vedlikehold eller sikre at dette blir håndtert. Vær obs på at kunderessurser og data håndteres med egne backuprutiner, slik at vi ikke blander på tvers av kunder eller med våre egne interne data.
Sjekk gjerne med Intern-IT & Sikkerhet for å se hva de kan levere og bistå med for å forenkle leveranse og forvaltning.
Bouvets Statement of Applicability/Anvendelseserklæring (SOA) for henholdsvis ISO 27001 og ISO 42001 tar for seg ulike kontroller relatert til informasjonssikkerheten og hvordan vi skal forholde oss til disse. Dersom vi tar på oss denne rollen vil din regionale kvalitetsleder kunne bistå med råd og veiledning for å sikre at vårt ansvar er ivaretatt.
Kunde eller tredjepart
Dersom vi kun har ansvar for utvikling av løsningen, er det viktig at vi har gått opp grensesnittet mellom oss og organisasjonen som overtar og drifter løsningen videre:
Hvordan skal handover skje
Hvordan håndterer vi at nødvendig hardware og kapasitet er satt opp
Hvordan sikrer vi at behov for deployments, driftshendelser, feilrettinger og liknende kommuniseres til begge parter?
Tips
Dokumenter ansvarsfordeling og annen relevant informasjon i kildekodesystemet sammen med resten av det som produseres i prosjektet. Det øker synligheten og alle vet til enhver tid hvor informasjonen finnes.
Bruk av KI
Dersom KI inngår i leveransen, må dere også gå opp hvordan dette reguleres i avtalen. KI åpner for mange muligheter, men introduserer også ny risiko i tillegg til å forsterke eksisterende risiko, spesielt knytttet til personvern. KI-loven er per nå ikke innført i Norge, men antagelsen er at denne kommer i nær fremtid, og prosjekter som bygger løsninger som omfattes av denne bør sikre at de er i samsvar med den foreslåtte KI-loven i Norge.
KI som verktøy
Dersom dere skal bruke KI-verktøy, må dere være sikre på at dette er avklart med kunden og at avtalen tar høyde for det. KI kan være et fantastisk verktøy, men det åpner også for noen scenarier der vi eller kunden kan bli skadelidende om ikke ansvar og bruk er avklart. Dersom vårt utstyr eller infrastruktur skal benyttes mot nye verktøy må dette klareres med IIT&S før prosjektet starter opp slik at lisenser og nødvendige risikovurderinger kan gjennomføres.
De fleste organisasjoner opererer med ulike klassifikasjonsnivå på både data og systemer. Klassifiseringen gjøres ofte med bakgrunn i hvordan data brukes, hvor det lagres og hvem som kan aksessere disse. Dette er nøkkelkrav for ethvert utviklingsprosjekt og må avklares i forkant.
Klassifisering
De aller fleste organisasjoner har rutiner og prosesser for klassifisering av data, for eksempel i følgende nivå:
Åpent
Internt
Konfidensielt
Begrenset
Avhengig av denne klassifiseringen kan det foreligge ulike krav til sikring av data. Åpne data har typisk ingen begrensninger, mens data klassifisert som “begrenset” kan ha begrensninger som at en
har strenge krav til innsyn
kun kan behandle informasjonen i egne systemer
krever flerfaktor autentisering før aksess
har restriksjoner i forhold til bruk av skytjenester eller hvor data lagres
Dette avklares med kunde i oppstarten av prosjektet slik at en kan sikre nødvendig etterlevelse. Dersom kunden ikke har et forhold til dataklassifisering, bør en likevel kartlegge sensitiviteten til dataene som skal behandles for å sikre at vi innfører nødvendige tiltak.
Personvern
Dersom leveranseteamet skal behandle personsensitive opplysninger, er det viktig at teamet setter seg inn i kravene rundt dette. Datatilsynet har publisert en egen veileder for “Programvareutvikling med innebygd personvern” som gir nyttig innblikk i problemstillingen.
Viktig
Norge er underlagt kravene i GDPR gjennom Personopplysningsloven, og det er viktig at leveransene har et forhold til en del krav og definisjoner i denne. Husk også at vi kan være underlagt databehandleravtaler som kan stille strengere krav enn lovverket!
Hensikten med GDPR er å sikre enkeltpersoners rettigheter ved å stille krav til hva personopplysninger kan brukes til samt hvilke, og hvordan disse kan brukes. Lovverket definerer personopplysninger som
“enhver opplysning om en identifisert eller identifiserbar fysisk person («den registrerte»); en identifiserbar fysisk person er en person som direkte eller indirekte kan identifiseres, særlig ved hjelp av en identifikator, f.eks. et navn, et identifikasjonsnummer, lokaliseringsopplysninger, en nettidentifikator eller ett eller flere elementer som er spesifikke for nevnte fysiske persons fysiske, fysiologiske, genetiske, psykiske, økonomiske, kulturelle eller sosiale identitet”
Personvern kan virke komplekst og vanskelig, men i korte trekk så
Er en personopplysning et informasjonsfragment som kan kobles til en bestemt person
Skal du ha behandlingsgrunnlag - hvorfor skal du behandle en personopplysning
Skal personen det gjelder gi sitt samtykke til at du kan behandle informasjonen
Du skal minimere mengden informasjon du henter inn - du skal kun samle inn det du trenger
Informasjonen skal ha en levetid - du skal ikke lagre data lenger enn nødvendig
Brukeren har retten til å bli glemt - også dersom du må restore fra en tidligere backup
Dersom vi behandler denne type informasjon på vegne av kunder skal de normalt kreve at vi signerer en databehandleravtale. Dersom dette ikke er på plass må det følges opp mot leveranse- og kundeansvarlig.
Data til bruk under utvikling og testing
Dersom en bruker data i forbindelse med utvikling og testing, er det viktig å ha et forhold til klassifisering og sensitivitet. Dev-miljøer har ofte et annet sikringsnivå enn produksjonsmiljøet, og dette gjør i praksis at vi ikke alltid kan bruke relle data til utvikling.
Teamet må sjekke behovet for anonymisering av dataene før disse brukes utenfor produksjonsmiljøet, slik at en ivaretar behovet for mengden data, fyllingsgrad og kvalitet samtidig som at en ikke risikerer at kundens data kommer på avveie. Kvalitet og metadata knyttet til informasjonen som brukes som utgangspunkt bør dokumenteres, slik at eventuelle avvik kan gås opp i etterkant og datagrunnlaget forbedres.
Dette er spesielt viktig dersom utvikling skjer i Bouvets infrastruktur, men det er også relevant dersom produksjonsmiljø er plassert hos kunden. I slike tilfeller er det viktig at Bouvet har dokumenterte rutiner som regulerer hvor og hvordan data oppbevares og brukes, og hvordan og når disse skal slettes. Dette må gås opp i samråd med kunde slik at det ikke er noe tvil rundt ansvar, plikter og risiko slik det er regulert i avtalen.
Kunstig intelligens og data
Dersom en bygger løsninger med, eller ved hjelp av kunstig intelligens stiller den foreslåtte KI-loven krav til datakvalitet, spesielt for høyrisikosystemer. Dette er spesifikt nevnt for disse da de kan brukes i situasjoner som kan få alvorlige konsekvenser for enkeltpersoner utover rene personvernhensyn beskrevet i personopplysningsloven. KI-systemer som ikke regnes som høyrisiko må også forholde seg til krav om merking av informasjon produsert av KI.
Et annet viktig moement er læring i KI-modellen: De færreste selskap vil godta at KI-modellene lærer av deres data, da det har vært flere eksempler på at læringsdata kan rekonstrueres i etterkant. Bruk av enterpriseavtaler begrenser ofte KI-modellens evne til å lære av kundedata - dette er et punkt som må verifiseres av oss når vi bygger løsninger.
Vær obs på at personopplysningsloven også gjelder for KI-systemer. Under vurdering av leverandører har vi sett flere tilfeller der KI-leverandører leverer tjenester utenfor EU, der det er nødvendig med ekstra grundige vurderinger og gjennomganger for å sikre at vi etterlever kravene som stilles gjennom lovverket.
Dersom du har spørsmål knyttet til bruk av KI kan du lage en sak gjennom BSD eller på #ai (Slack)
Dersom en katastrofal hendelse oppstår må vi vite hvem som skal kontaktes, og hvilke krav løsningen og leveranseteamet må forholde seg til. Dette går ikke bare på typiske krav relatert til tilgjengelighet men også hvor lang tid en kan bruke på gjenoppretting, hvordan dette skal gjøres og hva som er akseptabelt tap av data.
Business Continuity Planning er ikke utelukkende et IT-teknisk anliggende, men det er vårt ansvar som leverandører av et IT-system å minne kunden på at systemet kan bli utilgjengelig.
Svaret fra denne planleggingen vil være med å beskrive hvilke krav som stilles til løsningens robusthet og sikkerhetsnivå, og er avgjørende for å finne riktig balanse på kostnad og ytelse hos systemet.
Her er det viktig å ha et forhold til
Kritikaliteten av løsningen
Eventuelle workarounds dersom løsningen er utilgjengelig
Konsekvenser eller merarbeid som følge av utilgjengelighet eller når løsningen igjen blir tilgjengelig.
Kundens forventninger
Har vi definert en Service Level Agreement (SLA) med kunden som legger føringer på oppetid, tilgjengelighet og liknende, eller har kunden implisitte forventninger til dette?
Dette må avklares slik at en kjenner konsekvensene nedetid vil få. I mange prosjekter benyttes det skykomponenter der en ikke har kontroll over alle variabler selv. Derfor er det viktig å tidlig i prosjektet avklare de faktiske behovene med kunden. Vi kan sikre redundans på alle fronter dersom kunden ønsker det, men det koster da deretter.
Dersom en går opp dette i forkant er det lettere å henvise til dokumentasjon og avtaler når løsningen blir utilgjengelig for å unngå dårlig stemning.
Håndtering av hendelser
Alle kunder i Bouvet skal ha et definert kontaktpunkt for hendelser i Kunder (CRM). Dersom det er andre kontaktpunkter fra teamet inn mot kunde som sikkerhetssenter (SOC) eller liknende er det lurt å dokumentere dette også slik at en kan løse oppståtte hendelser så raskt som mulig.
Dersom en hendelse oppstår og kunde eller andre har behov for kontakt med teamet, er det vanlige at leveranseleder er det formelle kontaktpunktet i Bouvet-teamet.
Backup
Backup er viktig i alle prosjekter. Selv om vi i mange prosjekter ikke har noe ansvar for drift av infrastruktur, kildekodesystemer eller andre verktøy, bør vi gjøre oss kjent med rutiner og begrensninger på området.
Dersom vi har ansvar for drift har vi også ansvar for at backup gjennomføres. Vanlige begrep her er
Recovery Time Objective (RTO) - akseptabel tid for å oppnå normaltilstand etter svikt
Recovery Point Objective (RPO) - hva er akseptabelt datatap etter svikt (målt i tid)
Løsning for backup og recovery må designes ut ifra disse kravene, og vi må sikre at dette ivaretas. En må sammen med kunden ta stilling til
Hvor mye?
Hvilken data og systemer skal være underlagt backupregimet. Kan det differensieres?
Hvor ofte?
Skal vi ta backup 1 gang i uken, hver natt, eller hver time?
Hvor langt tilbake?
Hvor lenge skal vi lagre backupene?
En vanlig tilnærming til backup er å kjøre
Daglige backups - disse lagres i 30 dager
Ukentlige backups - disse lagres i 6 måneder
Månedtlige backups - disse lagres i 2 år
Det er også viktig å ha et forhold til hvor backupene lagres, slik at en kan være best mulig rigget mot katastrofale hendelser. Dette kan løses ved å ha offline og offsite backups, altså backups lagret på eksempelvis tape og oppbevart på en annen fysisk lokasjon enn øvrige backups.
Test!
Backup som ikke testes har ingen verdi - innfør rutiner for å teste at du kan restore fra backup!
Disaster recovery
Disaster Recovery i planleggingsfasen handler om å utvikle et planverk for hva som skal gjøres for å raskest mulig komme tilbake til normaltilstand. Det kan være nyttig å tenkte på dette som “actions on”, altså; “Hvis X inntreffer, så gjør vi Y”.
Gjenoppretting
Det vil ikke være nødvendig å gjenskape tjenestene i alle disaster hendelser. Ofte kan man slippe unna med mindre omfattende og manuell feilretting. Uavhengig av dette bør man uansett ha en plan for fullstendig gjennoppretting. Har man det kan man redde seg fra de fleste situasjoner.
Kan infrastruktur gjenskapes korrekt og raskt nok?
Dokumenter ressurser, avhengigheter, og operasjonelle prosedyrer
Her vil bruk av Infrastructure as Code (IaC) være et viktig bidrag
Data og databaser
Total / bulkgjennopretting: Hvordan gjenoppretter du store mengder data / hele volumer?
Enkeltfiler: Hvordan gjenoppretter du en enkelt fil?
Støttesystemer
Husk at støttesystemer kan spille en viktig rolle i det totale systmet. Disse må også kunne erstattes eller gjennopprettes ved hendelser
Eksempelvis: Git, CI-pipeline, logging og monitorering
Scenarier som kan diskuteres
Slettet tjeneste: Hvordan gjenoppretter du en tjeneste som har blitt slettet?
Korrupt tjeneste: Reparerer eller gjenoppretter man en VM eller andre tjenester med problemer?
Utilgjengelig tjeneste: Hva skjer om tjenestene blir utilgjengelige? Her trenger du definisjonen av hva som er midlertidig / kortvarig nedetid. Skal du deploye ny tjeneste, har du allerede en som kjører som hot-swap eller går det greit uten en periode?
Kompromittert sikkerhet: Hvordan håndterer du det når et passord har blitt lekket på noe vis?
Utgått passord: hvordan gjenopptar du driften hvis et passord eller sertifikat har utløpt? (Hint: prøv å unngå dette)
Kompromittert identitet / tjenestebruker: Hva gjør du hvis en managed identitet eller en tjenestebruker har blitt kompromittert?
Utilgjengelige passord: Hva gjør du hvis key vaulttjenesten i regionen du bruker går ned? Har du backup og failover i en annen region?
Malware: Hvordan gjenoppretter du systemet etter et cryptolockerangrep? Trenger du en delvis eller total gjenoppbygging av alle tjenester?
Konfidensialitetsbrudd: Hvordan håndterer du at noen har kommet seg inn i tjenesten(e) du drifter?
Kompromittert admin: Trenger du å planlegge for hva som skjer om eieren av subscription sletter hele Azure-subscriptionen din?
Kritisk sårbarhet: Hva skjer når noen oppdager en kritisk sårbarhet i din applikasjon? Det kan være lurt å ha protokoller klare for når du skal ta et valg om du stenger tjenesten ned.
Bruken av kunstig intelligens (KI) har eksplodert de siste årene, og teknologien har kommet så langt at den kan være et nyttig verktøy for å brainstorme løsninger, skrive,feilsøke eller vurdere kode. Men hva betyr dette for sikkerheten?
Denne siden handler om bruk av KI i utviklingsløpet, ikke generell bruk av KI-løsninger. Målet er å bruke KI som et produktivitetsverktøy uten å miste kontroll på sikkerhet, kvalitet og etterprøvbarhet.
Bruk av KI-verktøy
Husk at Bouvet og de fleste kunder har retningslinjer for bruk av KI som skal følges. Det er ikke lov å ta KI-verktøy i bruk uten eksplisitt godkjenning fra Bouvet eller kunde.
Hva har vi lov til å bruke
På Bouvet-utstyr kan vi kun bruke KI-verktøy som er eksplisitt tillatt i Bouvets KI-policy. På kundens utstyr kan vi kun bruke verktøy kunden har godkjent.
Bakgrunnen er enkel: KI-verktøy behandler ofte sensitiv informasjon og kan utføre handlinger som påvirker kodebase, bygg og leveranser.
Selv om vi kan bruke et verktøy teknisk, betyr det ikke at vi skal bruke det. Hvis et nytt verktøy kan gi nytte i prosjektet, opprett en BSD-sak for vurdering.
Praktiske råd for trygg KI-bruk i utvikling
For å få verdi av KI i utvikling uten å øke risiko unødig, bør teamet ha noen enkle, felles arbeidsregler. Disse bør brukes i daglig arbeid, ikke bare som policy på papir. Hvert enkelt team bør utarbeide egne regler og rutiner som passer til konteksten teamet jobber i, slik at våre og kundens krav til sikkerhet kan ivaretas.
Dette bør vi gjøre
bruk KI på avgrensede oppgaver med tydelig mål og ferdig definert rammeverk
behandle KI-bidrag som kode fra tredjepart: Du skal forstå og være i stand til å forklare koden før den merges eller kjøres.
dokumenter KI-bruk der det er relevant for sporbarhet og revisjon
bruk minst mulig data i prompt (dataminimering), og del kun det som trengs for oppgaven
begrens tilganger for KI-verktøy til minste nødvendige nivå
Dette bør vi unngå
lim inn hemmeligheter, persondata eller kundeinformasjon i prompt
la KI ta arkitektur- eller sikkerhetsbeslutninger uten menneskelig vurdering
slå av review- eller testkrav fordi koden ser riktig ut ved første øyekast
gi verktøy bred repo-, cloud- eller prod-tilgang uten tydelig behov og godkjenning
la KI merge, deploye eller rotere hemmeligheter uten eksplisitt menneskelig godkjenning
Målet er ikke å bremse utviklingen, men å bruke KI på en måte som er trygg, forutsigbar og etterprøvbar.
Kjøring av KI-generert kode
Kode og script foreslått av KI skal alltid gjennomgås før kjøring på utviklingsmaskin. Vær spesielt oppmerksom på kommandoer som laster ned innhold, endrer filrettigheter, starter bakgrunnsprosesser eller skriver til systemområder. Om man kjører KI-verktøyet i en avgrenset sandbox, reduserer man risikoen og kan i større grad la KI-verktøyet jobbe autonomt.
Prompting i praksis
Gode prompt-rutiner reduserer risiko og øker kvaliteten. Et nyttig prinsipp er at prompten skal være konkret nok til å gi et godt svar, men begrenset nok til at du beholder kontroll på data og resultat.
Dette bør vi be om
beskriv krav og rammer først (språk, rammeverk, sikkerhetskrav)
be om små, vurderbare endringer fremfor store omskrivninger
be om eksplisitte antagelser, avgrensninger og usikkerhet
be om testforslag sammen med kodeforslag
be KI forklare sikkerhetskonsekvenser av foreslått løsning
be om alternativer med fordeler og ulemper når løsningen påvirker sikkerhet eller drift
Dette bør vi styre unna
prompt som inneholder hemmeligheter, tokens eller kundedata
prompt som ber KI om å omgå policy, logging eller sikkerhetskontroller
prompt som gir KI åpne fullmakter til å “fikse alt” i hele kodebasen
prompt som ber KI gjøre endringer direkte i produksjonsnære miljø uten review
prompt som blander flere urelaterte oppgaver slik at resultatet blir vanskelig å kvalitetssikre
Med mindre det er eksplisitt godkjent, skal KI-verktøy ikke få tilgang til data utover det som trengs for oppgaven.
Sjekk at repoet ikke inneholder datafiler, hemmeligheter eller annen sensitiv informasjon. Bruk .gitignore , git pre-commit hook med hemmelighetsdeteksjon samt nøkkelhvelv for å redusere risiko for lekkasje.
KI-spesifikke trusler i utviklingsløpet
Når KI brukes i utvikling, oppstår trusler som ikke alltid dekkes av tradisjonelle kontroller:
prompt injection i kode, dokumentasjon eller issues som påvirker agentens oppførsel
dataeksfiltrering via prompt, logger, plugins eller integrasjoner
hallusinasjoner som introduserer falske API-er eller usikre mønstre
forgiftet kontekst fra kompromitterte avhengigheter eller ondsinnede kodeeksempler
overdreven tillit til autonom kjøring uten menneskelig kontroll
Disse truslene må håndteres med tekniske barrierer, tydelige prosesser og aktiv oppfølging.
Agentisk utvikling, instruksjonsfiler og guardrails
Agentiske verktøy kan analysere kodebase, foreslå endringer, opprette pull requests og i noen tilfeller utføre handlinger automatisk. Dette krever strengere styring enn vanlig kodeassistanse.
Lekkasje av sensitive data
Noen KI-verktøy kan commite og pushe kode automatisk. Sikre at sensitiv informasjon som passord, sertifikater og data ikke kommer på avveie.
For team som vil komme raskt i gang med tryggere agentisk utvikling, finnes det et internt Bouvet-repo med eksempler og mønstre: bouvet-ai-harness. Repoet tilbyr et sett med repoartefakter og arbeidsformer som gjør KI-assistert utvikling mer konsistent, effektiv og målbart, og kan brukes som et praktisk utgangspunkt for instruksjonsfiler, arbeidsflyt og målbare kvalitetskriterier.
Anbefalte guardrails:
bruk instruksjonsfiler som avgrenser hva agenten kan gjøre og ikke gjøre
hold instruksjoner konkrete, testbare og prosjektspesifikke
begrens tillatelser (least privilege) for repo, CI/CD og skytilganger
krev menneskelig review før merge og deploy
blokker automatiske endringer i sikkerhetskritiske filer uten eksplisitt godkjenning
logg agentens handlinger slik at bidrag er sporbare og etterprøvbare
bruk hooks i fra git og KI-verktøy for å etablere ekstra guardrails
For team som bruker instruksjonsfiler aktivt, bør disse behandles som en sikkerhetskontroll på linje med policy i CI/CD.
Kvalitetssikring før merge
KI-bidrag skal ikke til produksjon uten full kvalitetssikring. Minimum bør være på plass:
kodegjennomgang av utvikler som forstår endringen
relevante tester, inkludert sikkerhetstester der det er aktuelt
kontroll av avhengigheter og lisenskrav
kontroll av at hemmeligheter ikke er introdusert
vurdering av om endringen påvirker trusselmodell eller sikkerhetskrav
Et sikkerhetskontrollpunkt er et kontrollpunkt underveis i et prosjekt der en setter krav som må oppfylles før en går videre.
Avhengig av sikkerhetsnivået en leveranse ønsker å legge seg på, kan det være nødvendig å definere mekanismer for å vurdere sikkerheten på faste punkter i utviklingsløpet, såkalte sikkerhetskontrollpunkt.
Disse kan defineres mellom logiske faser i prosjektet, eksempelvis mellom design og utviklingsfasene, eller når en går fra utvikling til første release i produksjon. Andre og flere kontrollpunkter kan også defineres, helt avhengig av kravene leveranseteamet må forholde seg til.
IBM har i en studie fastslått at generelle svakheter i applikasjoner utviklet for det amerikanske forsvaret kostet langt mindre å utbedre jo tidligere de ble oppdaget.
Ved å ta i bruk sikkerhetskontrollpunkt er det ikke bare lettere å sikre etterlevelse av sikkerhet- og kvalitetskrav, men også lettere å sikre at en fanger opp svakheter tidlig. En vanlig praksis der slike kontrollpunkt benyttes er at det eksempelvis
skal foreligge et design av prosjektet før utviklingsløpet starter
at implementasjonen skal følge designet
og at en har verifisert at design og implementasjon faktisk matcher før en kan gå i produksjon
AI-spesifikke sikkerhetskontrollpunkt
For løsninger som bruker KI, bør det etableres egne kontrollpunkt før produksjonssetting. Målet er å sikre at data, modellatferd og driftsgrunnlag er vurdert og dokumentert før løsningen eksponeres i produksjon.
Et praktisk minimum er å innføre følgende gates:
1. Data review-gate
Før modelltrening, finjustering eller større endringer i datagrunnlaget bør teamet dokumentere:
hvilke datakilder som brukes, eierskap og tillatt bruksformål
grunnleggende kvalitetsvurdering av data (representativitet, mangler, støy, duplikater)
identifiserte personvern- og sikkerhetsrisikoer i datagrunnlaget
beslutning om eventuelle avgrensninger, filtrering eller avviste datasett
2. Evaluerings- og V&V-gate
Før produksjon bør modellen verifiseres og valideres mot definerte akseptansekriterier:
dokumentert evalueringsoppsett med relevante testsett og scenarier
vurdering av sikkerhets- og misbruksscenarier (for eksempel prompt injection og uønsket verktøybruk)
tydelige grenser for når modellen ikke skal brukes uten menneskelig kontroll
beslutning om go/no-go med begrunnelse
3. Logging- og monitoreringsgate
Før produksjon bør driftsteamet verifisere at nødvendig observabilitet er på plass:
hvilke hendelser som skal logges (modellkall, tilgangsendringer, feil, avvik)
hvordan logger beskyttes mot manipulering og uautorisert innsyn
hvilke alarmer og terskler som skal utløse oppfølging
hvem som har ansvar for løpende overvåking og hendelseshåndtering
