Förra månaden skrev jag en artikel om hur plattformar med låg kod/ingen kod erbjuder delning av autentiseringsuppgifter som en tjänst, varför de gör det och hur det ser ut från en angripares perspektiv. I den här artikeln kommer jag att fokusera på konsekvenserna av den kompromissen och hur den påverkar företag idag.
Här är anledningen till att det är dålig praxis att dela dina företagsuppgifter med någon annan. Säg att jag vill skicka mina referenser till en kollega för att söka efter produktionsloggar för en engångsanalys av användarbeteende. I ett typiskt företag kan det att ge någon behörighet att fråga efter en ny datakälla innebära en lång process för åtkomstgranskning, särskilt när det gäller produktion eller känslig data. Min kollega kan lätt bli frustrerad. "Allt jag ville var att göra den här lilla engångsfrågan, och jag har redan väntat i en månad!" kunde de säga. Jag kunde bara köra frågan för dem, men jag är översvämmad med mina egna dagliga uppgifter, och enstaka frågor tenderar att bli komplicerade.
Jag har en snabb lösning kvar: jag kan bara dela mitt användarnamn/lösenord med min kollega. Om de får en MFA-utmaning så godkänner jag gärna. Jag behöver inte spendera tid på att köra frågan, och min kollega blockeras. Alla vinner! Höger?
Tja, du skulle ha rätt i din analys, men du missar den större bilden. Även om det är viktigt för företaget att din kollega får sin användarbeteendeanalys gjord, är det lika, om inte mer, viktigt att ditt företag förblir kompatibelt med en mängd sekretess- och säkerhetsstandarder och upprätthåller kundernas förtroende genom att upprätthålla företagets engagemang för säkerhet .
Om företagsmål på hög nivå inte övertygar dig, överväg de centrala ledningsgrupperna inom IT eller säkerhet. Dessa team baserar sina verksamheter och säkerhetsstrategier på det faktum att varje användare har sin egen unika identitet. IT-team sätter upp nätverks- och åtkomstpolicyer som förutsätter att varje användare skulle vara inloggad från en företags-IP eller en bärbar dator på en gång; säkerhetsteam korrelerar händelser baserat på användar-ID; ekonomiteam kan samla kostnadsrapporter per användare och deras personliga molnmiljö. Att dela legitimation undergräver bland annat alla dessa antaganden. Det tar bort den grundläggande innebörden av en onlineidentitet.
Ett verkligt exempel
Låt oss vända oss till världen med låg kod/ingen kod och undersöka ett verkligt scenario. I ett stort företag insåg Jane, en inspirerad anställd från kundvårdsteamet, att när anställda i hela organisationen deltar i ett kundärende saknar de vanligtvis nyckelinformation om kunden, som deras supportärendehistorik och senaste köp. Detta försämrar kundens upplevelse, eftersom de måste förklara sitt problem gång på gång samtidigt som ärendet skickas till rätt medarbetare som kan ta itu med problemet.
För att förbättra detta skapade Jane en app som gör att företagets anställda kan se denna nyckelinformation om kunder när dessa anställda ingår i teamet som ansvarar för att ta itu med kundens supportärende. Låt oss först ta ett ögonblick för att erkänna kraften med låg kod/ingen kod, vilket gör att Jane kan identifiera ett behov och ta itu med det på egen hand, utan att be om en budget eller vänta på allokering av IT-resurser.
När Jane byggde applikationen var Jane tvungen att lösa flera problem, den största var behörigheter. Anställda i hela organisationen har inte direkt tillgång till att söka i kunddatabasen för att få den information de behöver. Om de gjorde det skulle Jane inte behöva bygga den här applikationen. För att lösa detta problem loggade Jane in i databasen och bäddade in sin autentiserade session direkt i applikationen. När applikationen tar emot en begäran från en användare kommer den att använda Janes identitet för att köra den frågan och sedan returnera resultaten till användaren. Denna funktion för inbäddning av autentiseringsuppgifter, som vi utforskade förra månaden, är en nyckelfunktion i plattformar med låg kod/ingen kod. Jane såg till att ställa in rollbaserad åtkomstkontroll (RBAC) i applikationen så att varje användare bara kan komma åt kundcase de är tilldelade.
Applikationen löste ett viktigt affärsproblem och fick därför snabbt användarantagande i hela företaget. Folk var glada över att de kunde ge bättre service till sina kunder genom att ha rätt sammanhang för samtalet. Kunderna var också nöjda. En månad efter att Jane skapade applikationen användes den redan av hundratals användare i hela organisationen, och kundnöjdheten steg.
Samtidigt på SOC utlöstes en varning med hög allvar som visade onormal aktivitet runt produktionskunddatabasen och tilldelades Amy, en erfaren säkerhetsanalytiker. Amys första undersökning visade att en intern användare försökte skrapa hela databasen och frågade efter information om flera kunder från flera IP-adresser över hela organisationen. Frågemönstret var mycket komplext; istället för ett enkelt uppräkningsmönster som du förväntar dig att se när en databas skrapas, efterfrågades samma kunds data flera gånger, ibland via olika IP-adresser och vid olika datum. Kan detta vara en angripare som försöker blanda ihop säkerhetsövervakningssystemen?
Efter en snabb undersökning avslöjade Amy en viktig bit av information: Alla dessa frågor över alla IP-adresser och datum använde en enda användaridentitet, någon som heter Jane från kundtjänstteamet.
Amy nådde ut till Jane för att fråga henne vad som händer. Först visste Jane inte. Blev hennes legitimation stulen? Klickade hon på fel länk eller litade hon på fel inkommande e-postmeddelande? Men när Jane berättade för Amy om applikationen hon nyligen byggde insåg de båda att det kunde finnas ett samband. Amy, SOC-analytikern, var inte bekant med låg-kod/ingen kod, så de kontaktade AppSec-teamet. Med Janes hjälp kom teamet på att Janes ansökan hade Janes referenser inbäddade i den. Ur databasens perspektiv fanns det ingen applikation – det var bara Jane som körde en hel massa frågor.
Jane, Amy och AppSec-teamet bestämde sig för att stänga av programmet tills en lösning hittats. Applikationsanvändare i hela organisationen var frustrerade eftersom de hade börjat lita på det, och kunderna kände det också.
Medan Amy stängde frågan och dokumenterade sina resultat, var VP of Customer Care inte nöjd med att se hur nöjda kunderna sjönk, så de bad Jane att leta efter en permanent lösning. Med hjälp av plattformens dokumentation och organisationens Center of Excellence-team tog Jane bort sin inbäddade identitet från applikationen, ändrade appen för att använda varje användares identitet för att fråga i databasen och säkerställde att användarna endast fick behörighet till kundcase de är associerade med . I sin nya och förbättrade version använde applikationen varje användares identitet för att söka i kunddatabasen. Jane och applikationsanvändarna var glada över att applikationen är online igen, Amy och AppSec-teamet var glada över att Janes identitet inte längre delas, och företaget såg att kundnöjdheten började stiga igen. Allt var väl.
Två veckor senare fick SOC ytterligare en varning om onormal åtkomst till produktionskunddatabasen. Det såg misstänkt ut likt den tidigare varningen på samma databas. Återigen använde IP-adresser från hela organisationen en enda användares identitet för att fråga databasen. Återigen, den användaren var Jane. Men den här gången visste säkerhetsteamet och Jane att appen använder sina användares identiteter. Vad pågår?
Undersökningen visade att den ursprungliga appen hade implicit delas Janes autentiserade databassession med appens användare. Genom att dela appen med en användare fick den användaren direkt tillgång till anslutning, ett omslag runt en autentiserad databassession som tillhandahålls av plattformen för låg kod/ingen kod. Med den anslutningen kunde användare utnyttja den autentiserade sessionen direkt – de behövde inte längre gå igenom appen. Det visar sig att flera användare hade tagit reda på detta och, som trodde att detta var det avsedda beteendet, använde Janes autentiserade databassession för att köra sina frågor. De älskade den här lösningen, eftersom användningen av anslutningen direkt gav dem full tillgång till databasen, inte bara för kundärenden som de är tilldelade.
Anslutningen raderades och händelsen var över. SOC-analytikern nådde ut till användare som hade använt Janes anslutning för att säkerställa att de kasserade all kunddata som de har lagrat.
Ta itu med säkerhetsutmaningen med låg kod/ingen kod
Historien ovan är ett verkligt scenario från ett multinationellt B2C-företag. Vissa detaljer har utelämnats eller justerats för att skydda integriteten. Vi har sett hur en välmenande anställd omedvetet kunde dela sin identitet med andra användare, vilket orsakar en hel rad problem inom IT, säkerhet och verksamheten. Som vi utforskade förra månaden är delning av autentiseringsuppgifter en nyckelfunktion för låg kod/ingen kod. Det är normen, inte undantaget.
As low-code/no-code fortsätter att blomma i företaget, medvetet eller inte, är det avgörande för säkerhets- och IT-team att delta i affärsutvecklingssamtalet. Lågkods-/no-kodappar kommer med en unika säkerhetsutmaningar, och deras produktiva natur innebär att dessa utmaningar blir akuta snabbare än någonsin tidigare.
