Forrige måned skrev jeg en artikkel om måten lavkode/ingen kode-plattformer tilbyr legitimasjonsdeling som en tjeneste, hvorfor de gjør det, og hvordan dette ser ut fra en angripers perspektiv. I denne artikkelen vil jeg fokusere på implikasjonene av det kompromisset og hvordan det påvirker bedrifter i dag.
Her er grunnen til at det er dårlig praksis å dele bedriftslegitimasjonen din med noen andre. Si at jeg ønsker å gi legitimasjonen min til en kollega for å spørre etter produksjonslogger for en engangsanalyse av brukeratferd. I en typisk bedrift kan det å gi noen tillatelser til å spørre etter en ny datakilde bety en lang tilgangsgjennomgangsprosess, spesielt når det gjelder produksjon eller sensitive data. Min kollega kunne lett bli frustrert. "Alt jeg ville var å gjøre denne lille engangsforespørselen, og jeg har allerede ventet i en måned!" kunne de si. Jeg kunne bare kjøre spørringen for dem, men jeg er oversvømmet med mine egne daglige oppgaver, og engangsforespørsler har en tendens til å bli kompliserte.
Jeg sitter igjen med en rask løsning: Jeg kunne bare dele brukernavnet/passordet mitt med kollegaen min. Hvis de får en MFA-utfordring, godkjenner jeg gjerne. Jeg trenger ikke bruke tiden på å kjøre spørringen, og kollegaen min blir blokkert. Alle vinner! Ikke sant?
Vel, du ville ha rett i analysen din, men du mangler det større bildet. Selv om det er viktig for bedriften at kollegaen din får utført sin brukeratferdsanalyse, er det like, om ikke mer, viktig at bedriften din forblir kompatibel med en rekke personvern- og sikkerhetsstandarder og opprettholder kundenes tillit ved å opprettholde selskapets forpliktelse til sikkerhet .
Hvis bedriftsmål på høyt nivå ikke overbeviser deg, bør du vurdere de sentrale ledergruppene innen IT eller sikkerhet. Disse teamene baserer sine operasjoner og sikkerhetsstrategier på det faktum at hver bruker har sin egen unike identitet. IT-team setter opp nettverks- og tilgangspolicyer som forutsetter at hver bruker vil være logget på fra én bedrifts-IP eller en bærbar datamaskin samtidig; sikkerhetsteam korrelerer hendelser basert på bruker-ID; finansteam kan samle kostnadsrapporter per bruker og deres personlige skymiljø. Deling av legitimasjon undergraver blant annet alle disse forutsetningene. Det fjerner den grunnleggende betydningen av en online identitet.
Et eksempel fra den virkelige verden
La oss vende oss til verden av lav-kode/ingen kode og undersøke et virkelighetsscenario. I en stor bedrift innså Jane, en inspirert ansatt fra kundeserviceteamet, at når ansatte på tvers av organisasjonen deltar i en kundesak, mangler de vanligvis nøkkelinformasjon om kunden, for eksempel kundestøttehistorikken og siste kjøp. Dette forringer kundens opplevelse, siden de må forklare problemet sitt igjen og igjen mens saken sendes til rett medarbeider som kan ta opp problemet.
For å forbedre dette opprettet Jane en app som lar selskapets ansatte se denne nøkkelinformasjonen om kunder når disse ansatte er en del av teamet som er ansvarlig for å ta opp kundens supportsak. Først, la oss ta et øyeblikk til å erkjenne kraften til lav-kode/ingen kode, som lar Jane identifisere et behov og løse det på egen hånd, uten å be om et budsjett eller vente på tildeling av IT-ressurser.
Mens han bygde applikasjonen, måtte Jane omgå flere problemer, den største var tillatelser. Ansatte på tvers av organisasjonen har ikke direkte tilgang til å søke i kundedatabasen for å få informasjonen de trenger. Hvis de gjorde det, ville ikke Jane måtte bygge denne applikasjonen. For å løse dette problemet, logget Jane på databasen og bygde inn sin autentiserte økt direkte i applikasjonen. Når applikasjonen mottar en forespørsel fra én bruker, vil den bruke Janes identitet til å utføre den spørringen og deretter returnere resultatene til brukeren. Denne funksjonen for innbygging av legitimasjon, som vi utforsket forrige måned, er en nøkkelfunksjon på plattformer med lav kode/ingen kode. Jane sørget for å sette opp rollebasert tilgangskontroll (RBAC) i applikasjonen slik at hver bruker bare kan få tilgang til kundesaker de er tildelt.
Applikasjonen løste et viktig forretningsproblem, og fikk derfor raskt brukeradopsjon i hele bedriften. Folk var glade for at de kunne yte bedre service til kundene sine ved å ha den rette konteksten for samtalen. Kundene var også fornøyde. En måned etter at Jane opprettet applikasjonen, ble den allerede brukt av hundrevis av brukere over hele organisasjonen, og kundetilfredsheten steg.
I mellomtiden på SOC ble et varsel med høy alvorlighetsgrad som viser unormal aktivitet rundt produksjonskundedatabasen utløst og tildelt Amy, en erfaren sikkerhetsanalytiker. Amys innledende undersøkelse viste at en intern bruker prøvde å skrape hele databasen, og spurte etter informasjon om flere kunder fra flere IP-adresser på tvers av organisasjonen. Spørringsmønsteret var veldig komplekst; i stedet for et enkelt oppregningsmønster du forventer å se når en database blir skrapet, ble den samme kundens data forespurt flere ganger, noen ganger gjennom forskjellige IP-adresser og på forskjellige datoer. Kan dette være en angriper som prøver å forvirre sikkerhetsovervåkingssystemene?
Etter en rask undersøkelse avdekket Amy en viktig del av informasjonen: Alle disse forespørslene på tvers av alle IP-adresser og datoer brukte en enkelt brukeridentitet, en som het Jane fra kundeserviceteamet.
Amy tok kontakt med Jane for å spørre henne hva som skjer. Til å begynne med visste ikke Jane. Ble legitimasjonen hennes stjålet? Klikket hun på feil lenke eller stolte hun på feil innkommende e-post? Men da Jane fortalte Amy om applikasjonen hun nylig bygde, skjønte de begge at det kunne være en sammenheng. Amy, SOC-analytikeren, var ikke kjent med lav kode/ingen kode, så de tok kontakt med AppSec-teamet. Med Janes hjelp fant teamet ut at Janes søknad hadde Janes legitimasjon innebygd i den. Fra databasens perspektiv var det ingen applikasjon - det var bare Jane, som utførte en hel masse spørringer.
Jane, Amy og AppSec-teamet bestemte seg for å stenge programmet til en løsning ble funnet. Applikasjonsbrukere over hele organisasjonen var frustrerte siden de hadde kommet til å stole på det, og kundene følte det også.
Mens Amy avsluttet problemet og dokumenterte funnene deres, var VP for kundebehandling ikke fornøyd med å se at kundetilfredsheten falt, så de ba Jane om å se etter en permanent løsning. Ved hjelp av plattformens dokumentasjon og organisasjonens Center of Excellence-team, fjernet Jane sin innebygde identitet fra applikasjonen, endret appen til å bruke hver brukers identitet til å spørre databasen, og sørget for at brukere kun får tillatelser til kundesaker de er knyttet til. . I sin nye og forbedrede versjon brukte applikasjonen hver brukers identitet for å søke i kundedatabasen. Jane og applikasjonsbrukerne var glade for at applikasjonen er tilbake på nettet, Amy og AppSec-teamet var glade for at Janes identitet ikke lenger deles, og bedriften så at kundetilfredsheten begynte å stige igjen. Alt var bra.
To uker senere mottok SOC et nytt varsel om unormal tilgang til produksjonskundedatabasen. Det så mistenkelig ut som det forrige varselet på den samme databasen. Igjen brukte IP-adresser fra hele organisasjonen én enkelt brukers identitet for å spørre databasen. Igjen, den brukeren var Jane. Men denne gangen visste sikkerhetsteamet og Jane at appen bruker brukerens identiteter. Hva skjer?
Etterforskningen avdekket at den originale appen hadde implisitt delt Janes autentiserte databaseøkt med appens brukere. Ved å dele appen med en bruker, fikk denne brukeren direkte tilgang til tilkobling, en innpakning rundt en autentisert databaseøkt levert av lavkode/ingen kodes plattform. Ved å bruke den tilkoblingen kunne brukere utnytte den autentiserte økten direkte - de trengte ikke lenger å gå gjennom appen. Det viser seg at flere brukere hadde funnet ut av dette, og trodde at dette var den tiltenkte oppførselen, brukte Janes autentiserte databaseøkt for å kjøre søkene sine. De elsket denne løsningen, siden direkte bruk av tilkoblingen ga dem full tilgang til databasen, ikke bare for kundesaker de er tildelt.
Forbindelsen ble slettet, og hendelsen var over. SOC-analytikeren tok kontakt med brukere som hadde brukt Janes forbindelse for å sikre at de forkastet kundedata de har lagret.
Ta tak i sikkerhetsutfordringen med lav kode/ingen kode
Historien ovenfor er et virkelighetsscenario fra et multinasjonalt B2C-selskap. Noen detaljer ble utelatt eller justert for å beskytte personvernet. Vi har sett hvordan en velmenende medarbeider uforvarende kan dele identiteten sin med andre brukere, og forårsake en hel rekke problemer på tvers av IT, sikkerhet og virksomheten. Som vi utforsket forrige måned, er deling av legitimasjon en nøkkelfunksjon ved lav kode/ingen kode. Det er normen, ikke unntaket.
As lav-kode/ingen kode fortsetter å blomstre i bedriften, bevisst eller ikke, er det avgjørende for sikkerhets- og IT-team å delta i forretningsutviklingssamtalen. Apper med lav kode/no-kode leveres med en unikt sett med sikkerhetsutfordringer, og deres produktive natur betyr at disse utfordringene blir akutte raskere enn noen gang før.
