stomp Oorkom die topsekuriteitsuitdagings van KI-gedrewe lae-kode/geen kode-ontwikkeling - Unite.AI
Verbinding met ons

Gedagte Leiers

Oorkom die topsekuriteitsuitdagings van KI-gedrewe lae-kode/geen kode-ontwikkeling

mm

Gepubliseer

 on

Lae-kode ontwikkeling platforms het die manier verander waarop mense pasgemaakte besigheidsoplossings skep, insluitend toepassings, werkvloeie en medevlieëniers. Hierdie instrumente bemagtig burgerontwikkelaars en skep 'n meer ratse omgewing vir toepassingsontwikkeling. Die toevoeging van KI tot die mengsel het hierdie vermoë net verbeter. Die feit dat daar nie genoeg mense by 'n organisasie is wat die vaardighede (en tyd) het om die aantal toepassings, outomatisering en so meer te bou wat nodig is om innovasie vorentoe te dryf nie, het aanleiding gegee tot die lae-kode/geen-kode paradigma. Nou, sonder om formele tegniese opleiding te benodig, kan burgerontwikkelaars gebruikersvriendelike platforms en Generatiewe KI gebruik om KI-gedrewe oplossings te skep, te innoveer en te ontplooi.

Maar hoe veilig is hierdie praktyk? Die realiteit is dat dit 'n magdom nuwe risiko's bekendstel. Hier is die goeie nuus: jy hoef nie te kies tussen sekuriteit en die doeltreffendheid wat besigheidsgeleide innovasie bied nie.

'n Verskuiwing buite die tradisionele strekking

IT- en sekuriteitspanne is gewoond daaraan om hul pogings op te fokus skandeer en soek na kwesbaarhede wat in kode geskryf is. Hulle het daarop gefokus om seker te maak dat ontwikkelaars veilige sagteware bou, om te verseker dat die sagteware veilig is en dan – sodra dit in produksie is – dit te monitor vir afwykings of vir enigiets wat agterna verdag is.

Met die styging van lae kode en geen kode, meer mense as ooit bou toepassings en gebruik outomatisering om toepassings te skep – buite die tradisionele ontwikkelingsproses. Dit is dikwels werknemers met min of geen agtergrond vir sagteware-ontwikkeling nie, en hierdie toepassings word buite sekuriteit se bestek geskep.

Dit skep 'n situasie waar IT nie meer alles vir die organisasie bou nie, en die sekuriteitspan nie sigbaarheid het nie. In 'n groot organisasie kry jy dalk 'n paar honderd toepassings in 'n jaar gebou deur professionele ontwikkeling; met lae/geen kode, kan jy baie meer as dit kry. Dit is baie potensiële toepassings wat ongemerk of ongemonitor deur sekuriteitspanne kan bly.

'n Magdom nuwe risiko's

 Sommige van die potensiële sekuriteitskwessies wat verband hou met lae-kode/geen-kode-ontwikkeling sluit in:

  1. Nie in IT se bevoegdheid nie – soos net genoem, werk burgerontwikkelaars buite die lyne van IT-professionele persone, wat 'n gebrek aan sigbaarheid en skadu-toepassingsontwikkeling skep. Boonop stel hierdie instrumente 'n oneindige aantal mense in staat om apps en outomatisering vinnig te skep, met net 'n paar kliks. Dit beteken daar is 'n ongekende aantal toepassings wat teen 'n yslike pas geskep word deur 'n ongekende aantal mense, almal sonder dat IT die volle prentjie het.
  2. Geen sagteware-ontwikkeling lewensiklus (SDLC) – Om sagteware op hierdie manier te ontwikkel, beteken dat daar geen SDLC in plek is nie, wat kan lei tot inkonsekwentheid, verwarring en 'n gebrek aan aanspreeklikheid bykomend tot risiko.
  3. Beginner-ontwikkelaars – Hierdie toepassings word dikwels gebou deur mense met minder tegniese vaardighede en ondervinding, wat die deur oopmaak vir foute en sekuriteitsbedreigings. Hulle dink nie noodwendig aan die sekuriteit of ontwikkelingsgevolge op die manier wat 'n professionele ontwikkelaar of iemand met meer tegniese ervaring sou doen nie. En as 'n kwesbaarheid gevind word in 'n spesifieke komponent wat in 'n groot aantal toepassings ingebed is, het dit die potensiaal om oor verskeie gevalle uitgebuit te word
  4. Slegte identiteitspraktyke – Identiteitsbestuur kan ook 'n probleem wees. As u 'n besigheidsgebruiker wil bemagtig om 'n toepassing te bou, is die nommer een ding wat hulle kan stop 'n gebrek aan toestemmings. Dikwels kan dit omseil word, en wat gebeur is dat jy dalk 'n gebruiker het wat iemand anders se identiteit gebruik. In hierdie geval is daar geen manier om uit te vind of hulle iets verkeerd gedoen het nie. As jy toegang kry tot iets waartoe jy nie mag nie, of jy het iets kwaadwillig probeer doen, sal sekuriteit kom soek na die geleende gebruiker se identiteit, want daar is geen manier om tussen die twee te onderskei nie.
  5. Geen kode om te skandeer nie – Dit veroorsaak 'n gebrek aan deursigtigheid wat foutsporing, ontfouting en sekuriteitsanalise kan belemmer, sowel as moontlike voldoening en regulatoriese kommer.

Hierdie risiko's kan almal bydra tot potensiële datalekkasie. Maak nie saak hoe 'n toepassing gebou word nie - of dit gebou word met sleep-en-los, 'n teksgebaseerde aansporing of met kode - dit het 'n identiteit, dit het toegang tot data, dit kan bewerkings uitvoer, en dit moet kommunikeer met gebruikers. Data word verskuif, dikwels tussen verskillende plekke in die organisasie; dit kan maklik datagrense of hindernisse verbreek.

Dataprivaatheid en -nakoming is ook op die spel. Sensitiewe data leef binne hierdie toepassings, maar dit word hanteer deur besigheidsgebruikers wat nie weet hoe (ook nie eers daaraan dink nie) om dit behoorlik te stoor. Dit kan lei tot 'n magdom bykomende kwessies, insluitend voldoeningsoortredings.

Herwin sigbaarheid

Soos genoem, een van die groot uitdagings met lae/geen kode is dat dit nie onder die bevoegdheid van IT/sekuriteit val nie, wat beteken dat data programme deurkruis. Daar is nie altyd 'n duidelike begrip van wie werklik hierdie toepassings skep nie, en daar is 'n algehele gebrek aan sigbaarheid van wat werklik gebeur. En nie elke organisasie is eers ten volle bewus van wat aan die gebeur is nie. Of hulle dink burgerontwikkeling vind nie in hul organisasie plaas nie, maar dit is byna seker.

So, hoe kan sekuriteitsleiers beheer kry en risiko verminder? Die eerste stap is om na die burgerontwikkelaar-inisiatiewe binne jou organisasie te kyk, uit te vind wie (indien iemand) hierdie pogings lei en met hulle kontak te maak. Jy wil nie hê hierdie spanne moet gepenaliseer of verhinder voel nie; as 'n sekuriteitsleier moet jou doel wees om hul pogings te ondersteun, maar om opvoeding en leiding te verskaf om die proses veiliger te maak.

Sekuriteit moet by sigbaarheid begin. Die sleutel hiervoor is die skep van 'n inventaris van toepassings en die ontwikkeling van 'n begrip van wie wat bou. Om hierdie inligting te hê, sal help om te verseker dat as 'n soort oortreding wel plaasvind, jy die stappe sal kan opspoor en uitvind wat gebeur het.

Vestig 'n raamwerk vir hoe veilige ontwikkeling lyk. Dit sluit die nodige beleide en tegniese kontroles in wat sal verseker dat gebruikers die regte keuses maak. Selfs professionele ontwikkelaars maak foute wanneer dit by sensitiewe data kom; dit is selfs moeiliker om dit met besigheidsgebruikers te beheer. Maar met die regte kontroles in plek, kan jy dit moeilik maak om 'n fout te maak.

Na meer veilige lae-kode/geen-kode

Die tradisionele proses van handkodering het innovasie belemmer, veral in mededingende tyd-tot-mark-scenario's. Met vandag se lae-kode en geen kode-platforms, kan selfs mense sonder ontwikkelingservaring KI-gedrewe oplossings skep. Alhoewel dit app-ontwikkeling vaartbelyn het, kan dit ook die veiligheid en sekuriteit van organisasies in gevaar stel. Dit hoef egter nie 'n keuse tussen burgerontwikkeling en veiligheid te wees nie; sekuriteitsleiers kan met besigheidsgebruikers saamwerk om 'n balans vir beide te vind.

Michael is die medestigter en CTO van Zeniteit. Hy is 'n bedryfskenner in kuberveiligheid wat belangstel in wolk, SaaS en AppSec. Voor Zenity was Michael 'n senior argitek by Microsoft Cloud Security CTO Office, waar hy sekuriteitsprodukpogings vir IoT, API's, IaC en vertroulike rekenaars gestig en gelei het. Michael lei die OWASP-gemeenskapspoging oor lae-kode/geen-kode sekuriteit.