Sidste måned skrev jeg en artikel om måden lavkode/ingen kode platforme tilbyder deling af legitimationsoplysninger som en tjeneste, hvorfor de gør det, og hvordan det ser ud fra en angribers perspektiv. I denne artikel vil jeg fokusere på konsekvenserne af dette kompromis, og hvordan det påvirker virksomheder i dag.
Her er grunden til, at det er dårlig praksis at dele dine virksomhedsoplysninger med en anden. Lad os sige, at jeg vil videregive mine legitimationsoplysninger til en kollega for at forespørge på produktionslogfiler til en engangsanalyse af brugeradfærd. I en typisk virksomhed kan det at give nogen tilladelser til at forespørge efter en ny datakilde betyde en lang adgangsgennemgangsproces, især når det kommer til produktion eller følsomme data. Min kollega kunne nemt blive frustreret. "Alt, jeg ville, var at lave denne lille engangsforespørgsel, og jeg har allerede ventet i en måned!" kunne de sige. Jeg kunne bare køre forespørgslen for dem, men jeg er oversvømmet med mine egne daglige opgaver, og engangsforespørgsler har tendens til at blive komplicerede.
Jeg står tilbage med en hurtig løsning: Jeg kunne bare dele mit brugernavn/adgangskode med min kollega. Hvis de får en MFA-udfordring, godkender jeg gerne. Jeg skal ikke bruge tid på at køre forespørgslen, og min kollega bliver blokeret. Alle vinder! Ret?
Nå, du ville have ret i din analyse, men du mangler det større billede. Selvom det er vigtigt for virksomheden, at din kollega får lavet deres brugeradfærdsanalyse, er det lige så, hvis ikke mere, vigtigt, at din virksomhed forbliver i overensstemmelse med en lang række privatlivs- og sikkerhedsstandarder og bevarer kundernes tillid ved at opretholde virksomhedens forpligtelse til sikkerhed .
Hvis virksomhedsmål på højt niveau ikke overbeviser dig, så overvej de centrale ledelsesteams inden for IT eller sikkerhed. Disse teams baserer deres operationer og sikkerhedsstrategier på det faktum, at hver bruger har deres egen unikke identitet. IT-teams er ved at opsætte netværks- og adgangspolitikker, der antager, at hver bruger vil være logget ind fra en virksomheds IP eller en virksomheds bærbar computer på én gang; sikkerhedsteams korrelerer hændelser baseret på bruger-id; økonomiteams kunne samle omkostningsrapporter pr. bruger og deres personlige cloudmiljø. Deling af legitimationsoplysninger undergraver blandt andet alle disse antagelser. Det fjerner den grundlæggende betydning af en online identitet.
Et eksempel fra den virkelige verden
Lad os vende os til verden af lav-kode/ingen kode og undersøge et scenarie i den virkelige verden. I en stor virksomhed indså Jane, en inspireret medarbejder fra kundeserviceteamet, at når medarbejdere på tværs af organisationen deltager i en kundesag, mangler de normalt nøgleoplysninger om kunden, såsom deres supportsagshistorik og seneste køb. Dette forringer kundens oplevelse, da de skal forklare deres problem igen og igen, mens sagen bliver sendt til den rigtige medarbejder, der kan løse problemet.
For at forbedre dette har Jane skabt en app, der giver virksomhedens medarbejdere mulighed for at se disse nøgleoplysninger om kunder, når disse medarbejdere er en del af det team, der er ansvarligt for at behandle kundens supportsag. Lad os først tage et øjeblik på at anerkende kraften ved lav-kode/ingen kode, som gør det muligt for Jane at identificere et behov og løse det på egen hånd uden at bede om et budget eller vente på allokering af it-ressourcer.
Mens han byggede applikationen, måtte Jane omgå flere problemer, hvoraf det største var tilladelser. Medarbejdere på tværs af organisationen har ikke direkte adgang til at forespørge kundedatabasen for at få de oplysninger, de har brug for. Hvis de gjorde det, ville Jane ikke skulle bygge denne applikation. For at løse dette problem loggede Jane på databasen og indlejrede sin autentificerede session direkte i applikationen. Når applikationen modtager en anmodning fra én bruger, vil den bruge Janes identitet til at udføre denne forespørgsel og derefter returnere resultaterne til brugeren. Denne legitimationsindlejringsfunktion, som vi udforskede i sidste måned, er en nøglefunktion i lav-kode/no-code platforme. Jane sørgede for at opsætte rollebaseret adgangskontrol (RBAC) i applikationen, således at hver bruger kun kan få adgang til kundesager, de er tildelt.
Applikationen løste et vigtigt forretningsproblem, og derfor vandt det hurtigt brugeradoption på tværs af virksomheden. Folk var glade for, at de kunne yde bedre service til deres kunder ved at have den rette kontekst for samtalen. Kunderne var også glade. En måned efter at Jane oprettede applikationen, blev den allerede brugt af hundredvis af brugere på tværs af organisationen, og kundetilfredsheden steg.
I mellemtiden på SOC blev en alarm med høj alvorlighed, der viste unormal aktivitet omkring produktionskundedatabasen, udløst og tildelt Amy, en erfaren sikkerhedsanalytiker. Amys indledende undersøgelse viste, at en intern bruger forsøgte at skrabe hele databasen og forespurgte oplysninger om flere kunder fra flere IP-adresser på tværs af organisationen. Forespørgselsmønsteret var meget komplekst; i stedet for et simpelt opregningsmønster, du ville forvente at se, når en database bliver skrabet, blev den samme kundes data forespurgt flere gange, nogle gange gennem forskellige IP-adresser og på forskellige datoer. Kan dette være en angriber, der forsøger at forvirre sikkerhedsovervågningssystemerne?
Efter en hurtig undersøgelse afslørede Amy en vigtig information: Alle disse forespørgsler på tværs af alle IP-adresser og datoer brugte en enkelt brugeridentitet, en person ved navn Jane fra kundeserviceteamet.
Amy rakte ud til Jane for at spørge hende, hvad der sker. Først vidste Jane det ikke. Blev hendes legitimationsoplysninger stjålet? Har hun klikket på det forkerte link eller stolet på den forkerte indkommende e-mail? Men da Jane fortalte Amy om den applikation, hun for nylig byggede, indså de begge, at der måske var en forbindelse. Amy, SOC-analytikeren, var ikke bekendt med lav-kode/ingen kode, så de kontaktede AppSec-teamet. Med Janes hjælp fandt holdet ud af, at Janes ansøgning havde Janes legitimationsoplysninger indlejret i den. Fra databasens perspektiv var der ingen applikation - der var bare Jane, der udførte en hel masse forespørgsler.
Jane, Amy og AppSec-teamet besluttede at lukke applikationen ned, indtil en løsning blev fundet. Applikationsbrugere på tværs af organisationen var frustrerede, da de var kommet til at stole på det, og kunderne mærkede det også.
Mens Amy lukkede problemet og dokumenterede deres resultater, var vicedirektøren for kundepleje ikke glad for at se, at kundetilfredsheden faldt, så de bad Jane om at lede efter en permanent løsning. Ved hjælp af platformens dokumentation og organisationens Center of Excellence-team fjernede Jane sin indlejrede identitet fra applikationen, ændrede appen til at bruge hver brugers identitet til at forespørge databasen og sikrede, at brugere kun fik tilladelser til kundesager, de er tilknyttet. . I sin nye og forbedrede version brugte applikationen hver brugers identitet til at forespørge kundedatabasen. Jane og applikationsbrugerne var glade for, at applikationen igen er online, Amy og AppSec-teamet var glade for, at Janes identitet ikke længere deles, og virksomheden så kundetilfredsheden begynde at stige igen. Alt var godt.
To uger senere modtog SOC endnu en advarsel om unormal adgang til produktionskundedatabasen. Det lignede mistænkeligt den tidligere advarsel på den samme database. Igen brugte IP-adresser fra hele organisationen en enkelt brugers identitet til at forespørge databasen. Igen var den bruger Jane. Men denne gang vidste sikkerhedsteamet og Jane, at appen bruger sin brugers identitet. Hvad sker der?
Undersøgelsen viste, at den originale app havde implicit delt Janes autentificerede databasesession med appens brugere. Ved at dele appen med en bruger, fik denne bruger direkte adgang til tilslutning, en indpakning omkring en autentificeret databasesession leveret af lav-kode/ingen kodes platform. Ved at bruge denne forbindelse kunne brugerne udnytte den autentificerede session direkte - de behøvede ikke længere at gå gennem appen. Det viser sig, at flere brugere havde fundet ud af dette, og de troede, at dette var den tilsigtede adfærd, brugte Janes autentificerede databasesession til at køre deres forespørgsler. De elskede denne løsning, da direkte brug af forbindelsen gav dem fuld adgang til databasen, ikke kun til kundesager, som de er tildelt.
Forbindelsen blev slettet, og hændelsen var forbi. SOC-analytikeren kontaktede brugere, der havde brugt Janes forbindelse for at sikre, at de kasserede alle kundedata, de har gemt.
Løsning af lav-kode/no-kode sikkerhedsudfordringen
Historien ovenfor er et virkelighedsscenario fra en multinational B2C-virksomhed. Nogle detaljer blev udeladt eller justeret for at beskytte privatlivets fred. Vi har set, hvordan en velmenende medarbejder uforvarende kan dele deres identitet med andre brugere, hvilket forårsager en lang række problemer på tværs af IT, sikkerhed og forretning. Som vi udforskede i sidste måned, er deling af legitimationsoplysninger en nøglefunktion ved lav kode/ingen kode. Det er normen, ikke undtagelsen.
As lav-kode/ingen kode fortsætter med at blomstre i virksomheden, bevidst eller ej, er det afgørende for sikkerheds- og it-teams at deltage i forretningsudviklingssamtalen. Lav-kode/ingen kode apps leveres med en unikke sikkerhedsudfordringer, og deres produktive karakter betyder, at disse udfordringer bliver akutte hurtigere end nogensinde før.
