Tankeledere

Overvindelse af de største sikkerhedsudfordringer for AI-drevet lavkode/ingenkode-udvikling

mm
Føj Unite.AI til dine foretrukne kilder på Google

Lavkode-udviklingsplatforme har ændret måden, hvorpå mennesker skaber brugerdefinerede forretningsløsninger, herunder apps, arbejdsgange og copiloter. Disse værktøjer giver magt til medborgerudviklere og skaber en mere agil udviklingsmiljø for app-udvikling. Tilføjelse af AI til blandingen har kun forbedret denne funktion. Det faktum, at der ikke er nok mennesker i en organisation, der har de nødvendige færdigheder (og tid) til at bygge det antal apps, automatiseringer og så videre, der er nødvendigt for at drive innovationen fremad, har ført til lavkode/ingenkode-paradigmet. Nu kan medborgerudviklere uden formel teknisk uddannelse udnytte brugervenlige platforme og generativ AI til at skabe, innovere og udvikle AI-drevne løsninger.

Men hvor sikker er denne praksis? Realiteten er, at det introducerer en række nye risici. Her er det gode nyheder: du behøver ikke at vælge mellem sikkerhed og den effektivitet, som forretningsledet innovation giver.

En skift uden for den traditionelle kompetence

IT- og sikkerhedsteams er vant til at fokusere deres indsats på at scannen og lede efter sårbarheder i kode. De har centreret sig på at sikre, at udviklere bygger sikker software, assurerer, at softwaren er sikker, og derefter – når den er i produktion – overvåger den for afvigelser eller noget mistænkeligt efterfølgende.

Med opkomsten af lavkode og ingenkode bygger flere mennesker end nogensinde før applikationer og bruger automatisering til at skabe applikationer – uden for den traditionelle udviklingsproces. Disse er ofte medarbejdere med lidt eller ingen softwareudviklingsbaggrund, og disse apps bliver skabt uden for sikkerhedens kompetence.

Dette skaber en situation, hvor IT ikke længere bygger alt for organisationen, og sikkerhedsteamet mangler indsigt. I en stor organisation kan du få et par hundrede apps bygget om året gennem professionel udvikling; med lav/ingenkode kan du få langt mere end det. Det er mange potentielle apps, der kan gå ubemærket eller uovervåget af sikkerhedsteams.

En rigdom af nye risici

 Nogle af de potentielle sikkerhedsproblemer, der er forbundet med lavkode/ingenkode-udvikling, omfatter:

  1. Ikke i IT’s kompetence – som nævnt, arbejder medborgerudviklere uden for IT-professionelle, hvilket skaber en mangel på indsigt og skyggeapp-udvikling. Derudover giver disse værktøjer mulighed for en ubegrænset mængde mennesker at skabe apps og automatiseringer hurtigt, med kun få klik. Det betyder, at der er en utalt mængde apps, der bliver skabt i hurtig tempo af en utalt mængde mennesker, alle uden IT’s fulde oversigt.
  2. Ingen softwareudviklingslivscyklus (SDLC) – Udvikling af software på denne måde betyder, at der ikke er nogen SDLC på plads, hvilket kan føre til inkonsistens, forvirring og mangel på ansvarlighed samt risiko.
  3. Uerfarne udviklere – Disse apps bliver ofte bygget af mennesker med mindre teknisk færdighed og erfaring, hvilket åbner døren for fejl og sikkerhedsTrusler. De tænker ikke nødvendigvis over sikkerheden eller udviklingskonsekvenserne på samme måde, som en professionel udvikler eller nogen med mere teknisk erfaring ville. Og hvis en sårbarhed findes i en bestemt komponent, der er indbygget i en stor mængde apps, har det potentialet til at blive udnyttet på tværs af multiple instanser
  4. Dårlige identitetspraksis – Identitetsstyring kan også være et problem. Hvis du vil give en forretningsbruger mulighed for at bygge en applikation, er det vigtigste, der kan stoppe dem, en mangel på tilladelser. Ofte kan dette omgås, og hvad der sker, er, at en bruger bruger en anden persons identitet. I dette tilfælde er der ingen måde at afgøre, om de har gjort noget forkert. Hvis du får adgang til noget, du ikke er tilladt til, eller du prøver at gøre noget ondt, vil sikkerheden komme efter den lånte brugers identitet, fordi der ikke er nogen måde at skelne mellem de to.
  5. Ingen kode at scannen – Dette forårsager en mangel på gennemsigtighed, der kan hindre fejlfinding, fejlretning og sikkerhedsanalyse, samt mulige overholdelses- og lovgivningsproblemer.

Disse risici kan alle bidrage til potentiel datalekkage. Uanset, hvordan en applikation bliver bygget – enten det bliver bygget med drag-and-drop, en tekstbaseret prompt eller med kode – har den en identitet, den har adgang til data, den kan udføre operationer, og den skal kommunikere med brugere. Data bliver flyttet, ofte mellem forskellige steder i organisationen; dette kan let bryde datagrænser eller -barrierer.

Dataintegritet og overholdelse er også på spil. Følsomme data findes inden for disse applikationer, men de bliver behandlet af forretningsbrugere, der ikke ved, hvordan (eller endda tænker på at) korrekt gemme dem. Dette kan føre til en række yderligere problemer, herunder overholdelseskrænkelser.

Genopnåelse af indsigt

Som nævnt er en af de store udfordringer med lav/ingenkode, at det ikke er under IT/sikkerhedens kompetence, hvilket betyder, at data bevæger sig gennem apps. Der er ikke altid en klar forståelse af, hvem der virkelig skaber disse apps, og der er en generel mangel på indsigt i, hvad der virkelig sker. Og ikke alle organisationer er endda fuldt ud bevidste om, hvad der sker. Eller de tror, at medborgerudvikling ikke sker i deres organisation, men det sker næsten helt sikkert.

Så, hvordan kan sikkerhedsledere opnå kontrol og mindske risiko? Det første skridt er at se på medborgerudviklingsinitiativerne inden for din organisation, finde ud af, hvem (hvis nogen) der leder disse bestræbelser, og forbinde dig med dem. Du vil ikke have, at disse teams føler sig straffet eller hæmmet; som sikkerhedsleder skal dit mål være at støtte deres bestræbelser, men give dem uddannelse og vejledning i, hvordan processen kan gøres sikrere.

Sikkerhed skal starte med indsigt. Nøgle til dette er at oprette en oversigt over applikationer og udvikle en forståelse af, hvem der bygger hvad. At have denne information vil hjælpe med at sikre, at hvis en slags brud indtræffer, vil du være i stand til at spore skridtene og afgøre, hvad der skete.

Etabler en ramme for, hvad sikker udvikling ligner. Dette inkluderer de nødvendige politikker og tekniske kontroller, der vil sikre, at brugere træffer de rigtige valg. Selv professionelle udviklere begår fejl, når det kommer til følsomme data; det er endnu sværere at kontrollere dette med forretningsbrugere. Men med de rigtige kontroller på plads kan du gøre det svært at begå en fejl.

Mod en mere sikker lavkode/ingenkode

Den traditionelle proces for manuel kodning har hæmmet innovation, især i konkurrencedygtige tid-til-marked-scenarier. Med i dagens lavkode- og ingenkode-platforme kan selv mennesker uden udviklingserfaring skabe AI-drevne løsninger. Mens dette har strømlinet app-udvikling, kan det også sætte organisationers sikkerhed og sikkerhed i fare. Det behøver ikke at være et valg mellem medborgerudvikling og sikkerhed; sikkerhedsledere kan samarbejde med forretningsbrugere for at finde en balance for begge.

Michael er medstifter og teknisk direktør i Zenity. Han er en brancheekspert i cybersikkerhed med interesse for cloud, SaaS og AppSec. Før Zenity var Michael seniorarkitekt i Microsoft Cloud Security CTO Office, hvor han grundlagde og ledede sikkerhedsproduktindsatsen for IoT, APIs, IaC og confidential computing. Michael leder OWASP-fællesskabets indsats på området low-code/no-code-sikkerhed.