Pazite na lažno predstavljanje uporabnika v aplikacijah z nizko kodo/brez kode

Prejšnji mesec sem pisal članek o tem, kako platforme z nizko kodo/brez kode ponujajo deljenje poverilnic kot storitev, zakaj to počnejo in kako to izgleda od perspektiva napadalca. V tem članku se bom osredotočil na posledice tega kompromisa in na to, kako vpliva na današnja podjetja.

Evo, zakaj je deljenje poverilnic vašega podjetja z nekom drugim slaba praksa. Recimo, da želim posredovati svoje poverilnice kolegu, da poizveduje po produkcijskih dnevnikih za neko enkratno analizo vedenja uporabnikov. V tipičnem podjetju lahko podelitev dovoljenj nekomu za poizvedovanje po novem viru podatkov pomeni dolg postopek pregleda dostopa, zlasti ko gre za produkcijske ali občutljive podatke. Moj kolega bi bil zlahka razočaran. "Vse, kar sem hotel, je, da naredim to drobno enkratno poizvedbo, in čakal sem že mesec dni!" bi lahko rekli. Lahko bi le zagnal poizvedbo namesto njih, vendar sem preplavljen s svojimi vsakodnevnimi opravili in enkratne poizvedbe se ponavadi zapletejo.

Preostane mi ena hitra rešitev: svoje uporabniško ime/geslo lahko delim s kolegom. Če dobijo izziv MFA, ga bom z veseljem odobril. Ni mi treba porabiti časa za izvajanje poizvedbe in moj kolega je deblokiran. Vsi zmagajo! Prav?

No, v svoji analizi bi imeli prav, vendar pogrešate širšo sliko. Medtem ko je za podjetje pomembno, da vaš sodelavec opravi analizo vedenja uporabnikov, je enako, če ne še bolj pomembno, da vaše podjetje ostane skladno s celo vrsto standardov zasebnosti in varnosti ter ohranja zaupanje strank z ohranjanjem zavezanosti podjetja varnosti .

Če vas visoki podjetniški cilji ne prepričajo, razmislite o centralnih vodstvenih ekipah v IT ali varnosti. Te skupine svoje delovanje in varnostne strategije temeljijo na dejstvu, da ima vsak uporabnik svojo edinstveno identiteto. Ekipe IT vzpostavljajo politike omrežja in dostopa, ki predpostavljajo, da bi bil vsak uporabnik prijavljen z enega naslova IP ali prenosnika podjetja hkrati; varnostne ekipe povezujejo dogodke na podlagi ID-ja uporabnika; finančne ekipe bi lahko združevale poročila o stroških na uporabnika in njihovo osebno okolje v oblaku. Skupna raba poverilnic med drugim spodkopava vse te predpostavke. Odpravlja osnovni pomen spletne identitete.

Primer iz resničnega sveta

Obrnimo se v svet nizke kode/brez kode in preučimo scenarij iz resničnega sveta. V velikem podjetju je Jane, navdihnjena uslužbenka iz skupine za pomoč strankam, ugotovila, da ko zaposleni v celotni organizaciji sodelujejo pri primeru stranke, običajno pogrešajo ključne informacije o stranki, kot so zgodovina primerov podpore in zadnji nakupi. To poslabša strankino izkušnjo, saj mora znova in znova pojasnjevati svojo težavo, medtem ko je primer preusmerjen k pravemu zaposlenemu, ki lahko reši težavo.

Da bi to izboljšala, je Jane ustvarila aplikacijo, ki zaposlenim v podjetju omogoča ogled teh ključnih informacij o strankah, ko so ti zaposleni del ekipe, ki je odgovorna za obravnavo primera podpore strank. Najprej si vzemimo trenutek in priznajmo moč nizke kode/brez kode, ki Jane omogoča, da prepozna potrebo in jo obravnava sama, ne da bi zahtevala proračun ali čakala na dodelitev virov IT.

Med gradnjo aplikacije je morala Jane rešiti več težav, največja pa so bila dovoljenja. Zaposleni v celotni organizaciji nimajo neposrednega dostopa do povpraševanja po bazi podatkov strank, da bi dobili informacije, ki jih potrebujejo. Če bi, potem Jane ne bi bilo treba izdelati te aplikacije. Da bi odpravila to težavo, se je Jane prijavila v zbirko podatkov in svojo overjeno sejo vdelala neposredno v aplikacijo. Ko aplikacija prejme zahtevo enega uporabnika, bo uporabila Janeino identiteto za izvedbo te poizvedbe in nato vrnila rezultate uporabniku. Ta funkcija vdelave poverilnic, kot smo raziskovali prejšnji mesec, je ključna značilnost platform z nizko kodo/brez kode. Jane je poskrbela, da je v aplikaciji nastavila nadzor dostopa na podlagi vlog (RBAC), tako da lahko vsak uporabnik dostopa samo do primerov strank, ki so mu dodeljeni.

Aplikacija je rešila pomemben poslovni problem, zato so jo uporabniki hitro sprejeli v celotnem podjetju. Ljudje so bili veseli, da so lahko svojim strankam zagotovili boljše storitve s pravim kontekstom za pogovor. Tudi stranke so bile zadovoljne. Mesec dni po tem, ko je Jane ustvarila aplikacijo, jo je že uporabljalo na stotine uporabnikov v celotni organizaciji, pri čemer je stopnja zadovoljstva strank naraščala.

Medtem se je v SOC sprožilo opozorilo visoke resnosti, ki je pokazalo nenormalno dejavnost v produkcijski bazi podatkov strank in dodeljeno Amy, izkušeni varnostni analitiki. Amyjina začetna preiskava je pokazala, da je interni uporabnik poskušal pobrskati po celotni zbirki podatkov in povpraševal po informacijah o več strankah z več naslovov IP v celotni organizaciji. Vzorec poizvedbe je bil zelo zapleten; namesto preprostega oštevilčenega vzorca, ki bi ga pričakovali, da boste videli, ko je zbirka podatkov strgana, so bili podatki iste stranke poizvedovani večkrat, včasih prek različnih naslovov IP in na različne datume. Je to lahko napadalec, ki poskuša zamenjati sisteme za varnostni nadzor?

Po hitri preiskavi je Amy odkrila ključno informacijo: vse te poizvedbe po vseh naslovih IP in datumih so uporabljale eno samo uporabniško identiteto, nekoga z imenom Jane iz ekipe za pomoč uporabnikom.

Amy je prišla do Jane in jo vprašala, kaj se dogaja. Sprva Jane ni vedela. So ji ukradli poverilnice? Ali je kliknila napačno povezavo ali zaupala napačni dohodni e-pošti? Toda ko je Jane povedala Amy za aplikacijo, ki jo je pred kratkim zgradila, sta obe spoznali, da bi lahko obstajala povezava. Amy, analitik SOC, ni poznala nizke kode/brez kode, zato se je obrnila na ekipo AppSec. Z Janeino pomočjo je ekipa ugotovila, da ima Janeina aplikacija vgrajene Janeine poverilnice. Z vidika baze podatkov ni bilo nobene aplikacije - bila je samo Jane, ki je izvajala veliko poizvedb.

Jane, Amy in ekipa AppSec so se odločile, da zaprejo aplikacijo, dokler ne najdejo rešitve. Uporabniki aplikacije v celotni organizaciji so bili razočarani, ker so se začeli zanašati nanjo, in tudi stranke so to občutile.

Medtem ko je Amy zaključila zadevo in dokumentirala njihove ugotovitve, podpredsednica službe za pomoč uporabnikom ni bila zadovoljna, ker je stopnja zadovoljstva strank padla, zato so Jane prosili, naj poišče trajno rešitev. S pomočjo dokumentacije platforme in ekipe Centra odličnosti organizacije je Jane odstranila svojo vdelano identiteto iz aplikacije, spremenila aplikacijo tako, da uporablja identiteto vsakega uporabnika za poizvedovanje v bazi podatkov, in zagotovila, da uporabniki pridobijo dovoljenja samo za primere strank, s katerimi so povezani. . V svoji novi in ​​izboljšani različici je aplikacija uporabila identiteto vsakega uporabnika za poizvedovanje v bazi podatkov strank. Jane in uporabniki aplikacije so bili veseli, da je aplikacija spet na spletu, Amy in ekipa AppSec so bili veseli, da Janeina identiteta ni več razkrita, in podjetje je opazilo, da se je stopnja zadovoljstva strank spet začela povečevati. Vse je bilo dobro.

Dva tedna kasneje je SOC prejel še eno opozorilo o neobičajnem dostopu do podatkovne baze proizvodnih strank. Videti je bilo sumljivo podobno prejšnjemu opozorilu v isti bazi podatkov. Spet so naslovi IP iz celotne organizacije uporabljali identiteto enega samega uporabnika za poizvedovanje v bazi podatkov. Spet je bila ta uporabnica Jane. Toda tokrat sta varnostna ekipa in Jane vedeli, da aplikacija uporablja identitete svojih uporabnikov. Kaj se dogaja?

Preiskava je pokazala, da je prvotna aplikacija imela implicitno v skupni rabi Janeina overjena seja zbirke podatkov z uporabniki aplikacije. Z deljenjem aplikacije z uporabnikom je ta dobil neposreden dostop do povezava, ovoj okoli overjene seje baze podatkov, ki jo zagotavlja platforma z nizko kodo/brez kode. Z uporabo te povezave so lahko uporabniki neposredno izkoristili overjeno sejo – ni jim bilo več treba iti skozi aplikacijo. Izkazalo se je, da je to ugotovilo več uporabnikov in so mislili, da je to načrtovano vedenje, za izvajanje svojih poizvedb uporabljali sejo podatkovne baze z overjeno pristnostjo Jane. Ta rešitev jim je bila všeč, saj jim je uporaba neposredne povezave omogočila popoln dostop do baze podatkov, ne le za primere strank, ki so jim dodeljeni.

Povezava je bila izbrisana in incident je bil končan. Analitik SOC se je obrnil na uporabnike, ki so uporabljali Janeino povezavo, da bi zagotovil, da so zavrgli vse podatke o strankah, ki so jih shranili.

Reševanje varnostnega izziva z nizko kodo/brez kode

Zgornja zgodba je scenarij iz resničnega življenja multinacionalnega podjetja B2C. Nekatere podrobnosti so bile izpuščene ali prilagojene zaradi zaščite zasebnosti. Videli smo, kako lahko dobronamerni zaposleni nehote deli svojo identiteto z drugimi uporabniki, kar povzroči celo vrsto težav v IT, varnosti in podjetju. Kot smo raziskovali prejšnji mesec, je deljenje poverilnic ključna značilnost nizke kode/brez kode. To je pravilo, ne izjema.

As nizka koda/brez kode še naprej cveti v podjetju, zavestno ali ne, je ključnega pomena, da se ekipe za varnost in IT pridružijo pogovoru o poslovnem razvoju. Aplikacije z nizko kodo/brez kode so opremljene z a edinstven niz varnostnih izzivov, in njihova plodna narava pomeni, da ti izzivi postanejo akutni hitreje kot kdaj koli prej.