Overvinning av de største sikkerhetsutfordringene med AI-drevet lavkode/ingenkode-utvikling

Lavkode-utviklingsplattformer har endret måten mennesker lager tilpassede forretningsløsninger, inkludert apper, arbeidsflyter og copiloter. Disse verktøyene gir makt til borgerutviklere og skaper en mer smidig miljø for app-utvikling. Å legge til AI i blandingen har bare forbedret denne evnen. Det faktum at det ikke er nok mennesker i en organisasjon som har ferdighetene (og tiden) til å bygge antall apper, automatiseringer og så videre som trengs for å drive innovasjon fremover, har ført til lavkode/ingenkode-paradigmet. Nå kan borgerutviklere, uten å trenge formell teknisk utdanning, utnytte brukervennlige plattformer og generativ AI for å lage, innovere og distribuere AI-drevne løsninger.

Men hvor sikker er denne praksisen? Virkeligheten er at det introduserer en mengde nye risikoer. Her er det gode nyheten: du trenger ikke å velge mellom sikkerhet og effektiviteten som forretningsledet innovasjon gir.

En skift utenfor den tradisjonelle virksomheten

IT- og sikkerhetsteam er vant til å fokusere sine innsats på skanning og å lete etter sårbarheter skrevet inn i kode. De har konsentrert seg om å sikre at utviklere bygger sikker programvare, sikre at programvaren er sikker og deretter – en gang den er i produksjon – overvåke den for avvik eller noe mistenkelig etterpå.

Med oppblomstringen av lavkode og ingenkode, bygger flere mennesker enn noen gang tidligere applikasjoner og bruker automatisering for å lage applikasjoner – utenfor den tradisjonelle utviklingsprosessen. Disse er ofte ansatte med liten eller ingen programvareutviklingsbakgrunn, og disse appene blir laget utenfor sikkerhetens virksomhet.

Dette skaper en situasjon der IT ikke lenger bygger alt for organisasjonen, og sikkerhetsteamet mangler oversikt. I en stor organisasjon kan du få noen hundre apper bygget i løpet av et år gjennom profesjonell utvikling; med lav/ingenkode kan du få langt flere enn det. Det er en mengde potensielle apper som kan gå ubemerket eller uovervåket av sikkerhetsteam.

En mengde nye risikoer

 Noen av de potensielle sikkerhetsproblemer forbundet med lavkode/ingenkode-utvikling inkluderer:

1. Ikke i ITs virksomhet – som allerede nevnt, borgerutviklere arbeider utenfor IT-profesjonelles linjer, og skaper en mangel på oversikt og skyggeapp-utvikling. I tillegg gjør disse verktøyene det mulig for en ubegrenset mengde mennesker å lage apper og automatiseringer raskt, med bare noen få klikk. Det betyr at det finnes en uendelig mengde apper som blir laget i en rasende takt av en uendelig mengde mennesker, alle uten at IT har det fullstendige bildet.
2. Ingen programvareutviklingslivssyklus (SDLC) – Å utvikle programvare på denne måten betyr at det ikke finnes noen SDLC på plass, hvilket kan føre til inkonsistens, forvirring og mangel på ansvar, i tillegg til risiko.
3. Uerfarne utviklere – Disse appene blir ofte bygget av mennesker med mindre teknisk ferdighet og erfaring, og åpner døren for feil og sikkerhetstrusler. De tenker ikke nødvendigvis på sikkerhets- eller utviklingskonsekvenser på samme måte som en profesjonell utvikler eller noen med mer teknisk erfaring ville. Og hvis en sårbarhet blir funnet i en bestemt komponent som er innbygget i en stor mengde apper, har det potensialet til å bli utnyttet over flere instanser
4. Dårlige identitetspraksiser – Identitetshåndtering kan også være et problem. Hvis du vil gi makt til en forretningsbruker til å bygge en applikasjon, er det viktigste som kan stoppe dem mangelen på tillatelser. Ofte kan dette omgås, og det som skjer er at du kan ha en bruker som bruker noen andres identitet. I dette tilfelle er det ingen måte å finne ut om de har gjort noe galt. Hvis du aksesserer noe du ikke har tillatelse til eller du prøver å gjøre noe skadelig, vil sikkerhet komme etter den lånte brukerens identitet fordi det ikke finnes noen måte å skille mellom de to.
5. Ingen kode å skanne – Dette forårsaker en mangel på transparens som kan hindre feilsøking, feilretting og sikkerhetsanalyse, samt mulige overholdelses- og reguleringsspørsmål.

Disse risikoene kan alle bidra til potensiell datalekkasje. Uansett hvordan en applikasjon blir bygget – enten den blir bygget med dra-og-slip, en tekstbasert prompt eller med kode – har den en identitet, den har tilgang til data, den kan utføre operasjoner, og den må kommunisere med brukere. Data blir flyttet, ofte mellom ulike steder i organisasjonen; dette kan lett bryte data-grenser eller -barrierer.

Dataintegritet og overholdelse er også på spill. Følsomme data bor i disse applikasjonene, men de håndteres av forretningsbrukere som ikke vet hvordan (eller tenker på å) lagre dem ordentlig. Dette kan føre til en mengde ekstra problemer, inkludert overholdelsesbrudd.

Tilbake til oversikt

Som nevnt er en av de store utfordringene med lav/ingenkode at det ikke lenger er under IT/sikkerhetens virksomhet, hvilket betyr at data krysser apper. Det finnes ikke alltid en klar forståelse av hvem som virkelig lager disse appene, og det finnes en generell mangel på oversikt over hva som virkelig skjer. Og ikke alle organisasjoner er helt klar over hva som skjer. Eller de tror at borgerutvikling ikke skjer i deres organisasjon, men det skjer nesten helt sikkert.

Så, hvordan kan sikkerhetsledere få kontroll og minimere risiko? Det første steget er å se på borgerutviklingsinitiativene i din organisasjon, finne ut hvem (hvis noen) som leder disse anstrengene og koble seg til dem. Du ønsker ikke at disse teamene skal føle seg straffet eller hindret; som sikkerhetsleder er ditt mål å støtte deres anstrengelser, men gi veiledning og utdanning på å gjøre prosessen tryggere.

Sikkerhet må starte med oversikt. Nøkkel til dette er å lage en oversikt over applikasjoner og utvikle en forståelse av hvem som bygger hva. Å ha denne informasjonen vil hjelpe med å sikre at hvis en type brudd skjer, vil du være i stand til å spore skrittene og finne ut hva som skjedde.

Etablere en ramme for hva trygg utvikling ser ut til. Dette inkluderer de nødvendige politikker og tekniske kontroller som vil sikre at brukerne tar de riktige valg. Selv profesjonelle utviklere gjør feil når det gjelder følsomme data; det er enda vanskeligere å kontrollere dette med forretningsbrukere. Men med de riktige kontrollene på plass kan du gjøre det vanskelig å gjøre en feil.

Mot mer sikker lavkode/ingenkode

Den tradisjonelle prosessen med manuell kode har hindret innovasjon, spesielt i konkurranseutsatte tid-til-marked-scenarier. Med dagens lavkode- og ingenkodeplattformer kan selv mennesker uten utviklingserfaring lage AI-drevne løsninger. Mens dette har strømlinjeformet app-utvikling, kan det også sette organisasjoners sikkerhet og trygghet i fare. Det trenger ikke å være et valg mellom borgerutvikling og sikkerhet; sikkerhetsledere kan samarbeide med forretningsbrukere for å finne en balanse for begge. Utviklingserfaring kan skape AI-drevne løsninger. Mens dette har strømlinjeformet app-utvikling, kan det også sette organisasjoners sikkerhet og trygghet i fare. Det trenger ikke å være et valg mellom borgerutvikling og sikkerhet; sikkerhetsledere kan samarbeide med forretningsbrukere for å finne en balanse for begge.