Vorige maand schreef ik een artikel over de manier waarop low-code/no-code platforms het delen van inloggegevens aanbieden als een service, waarom ze dit doen en hoe dit eruit ziet het perspectief van een aanvaller. In dit artikel zal ik me concentreren op de implicaties van dat compromis en hoe het ondernemingen van vandaag beïnvloedt.
Dit is de reden waarom het delen van uw bedrijfsgegevens met iemand anders een slechte gewoonte is. Stel dat ik mijn inloggegevens aan een collega wil doorgeven om productielogboeken op te vragen voor een eenmalige analyse van gebruikersgedrag. In een typische onderneming kan het verlenen van machtigingen om een nieuwe gegevensbron te doorzoeken een lang proces voor toegangsbeoordeling betekenen, vooral als het gaat om productie of gevoelige gegevens. Mijn collega kan gemakkelijk gefrustreerd raken. "Ik wilde alleen maar deze kleine eenmalige vraag doen, en ik wacht al een maand!" ze zouden kunnen zeggen. Ik zou gewoon de query voor ze kunnen uitvoeren, maar ik word overspoeld met mijn eigen dagelijkse taken en eenmalige query's worden vaak ingewikkeld.
Ik heb nog één snelle oplossing: ik kan gewoon mijn gebruikersnaam/wachtwoord delen met mijn collega. Als ze een MFA-uitdaging krijgen, keur ik dat graag goed. Ik hoef geen tijd te besteden aan het uitvoeren van de query en mijn collega wordt gedeblokkeerd. Iedereen wint! Rechts?
Nou, je zou gelijk hebben in je analyse, maar je mist het grotere plaatje. Hoewel het voor de onderneming belangrijk is dat uw collega de analyse van het gebruikersgedrag laat uitvoeren, is het net zo belangrijk, zo niet belangrijker, dat uw onderneming blijft voldoen aan een hele reeks privacy- en beveiligingsnormen en het vertrouwen van de klant behoudt door de toewijding van het bedrijf aan beveiliging te handhaven .
Als bedrijfsdoelstellingen op hoog niveau u niet overtuigen, overweeg dan de centrale managementteams in IT of beveiliging. Die teams baseren hun operaties en beveiligingsstrategieën op het feit dat elke gebruiker zijn eigen unieke identiteit heeft. IT-teams stellen netwerk- en toegangsbeleid op dat ervan uitgaat dat elke gebruiker tegelijk zou inloggen vanaf één bedrijfs-IP of bedrijfslaptop; beveiligingsteams correleren gebeurtenissen op basis van gebruikers-ID; financiële teams kunnen kostenrapporten per gebruiker en hun persoonlijke cloudomgeving samenvoegen. Het delen van inloggegevens ondermijnt onder andere al deze aannames. Het ontneemt de fundamentele betekenis van een online identiteit.
Een voorbeeld uit de echte wereld
Laten we ons wenden tot de wereld van low-code/no-code en een realistisch scenario onderzoeken. In een grote onderneming realiseerde Jane, een geïnspireerde medewerker van het klantenserviceteam, dat wanneer medewerkers in de hele organisatie deelnemen aan een klantcase, ze meestal belangrijke informatie over de klant missen, zoals hun supportcasegeschiedenis en laatste aankopen. Dit verslechtert de ervaring van de klant, omdat ze hun probleem steeds opnieuw moeten uitleggen terwijl de zaak wordt doorgestuurd naar de juiste medewerker die het probleem kan oplossen.
Om dit te verbeteren, heeft Jane een app gemaakt waarmee bedrijfsmedewerkers deze belangrijke informatie over klanten kunnen bekijken wanneer die medewerkers deel uitmaken van het team dat verantwoordelijk is voor het behandelen van de ondersteuningszaak van de klant. Laten we eerst even stilstaan bij de kracht van low-code/no-code, waarmee Jane een behoefte kan identificeren en zelf kan aanpakken, zonder een budget te vragen of te wachten op toewijzing van IT-middelen.
Tijdens het bouwen van de applicatie moest Jane meerdere problemen omzeilen, waarvan de grootste de machtigingen waren. Werknemers in de hele organisatie hebben geen directe toegang om de klantendatabase te doorzoeken om de informatie te krijgen die ze nodig hebben. Als dat zo was, zou Jane deze applicatie niet hoeven te bouwen. Om dit probleem op te lossen, logde Jane in op de database en sloot haar geverifieerde sessie rechtstreeks in de toepassing in. Wanneer de toepassing een verzoek van één gebruiker ontvangt, zal het de identiteit van Jane gebruiken om die vraag uit te voeren en vervolgens de resultaten naar de gebruiker terug te sturen. Deze functie voor het insluiten van referenties, zoals we vorige maand hebben verkend, is een belangrijk kenmerk van low-code/no-code platforms. Jane heeft ervoor gezorgd dat op rollen gebaseerde toegangscontrole (RBAC) in de applicatie is ingesteld, zodat elke gebruiker alleen toegang heeft tot klantcases waaraan ze zijn toegewezen.
De applicatie loste een belangrijk zakelijk probleem op, waardoor het snel werd geaccepteerd door de gebruikers in de hele onderneming. Mensen waren blij dat ze hun klanten beter van dienst konden zijn door de juiste context voor het gesprek te hebben. Ook de klanten waren blij. Een maand nadat Jane de applicatie had gemaakt, werd deze al door honderden gebruikers in de hele organisatie gebruikt, en de klanttevredenheid steeg.
Ondertussen werd bij het SOC een zeer ernstige waarschuwing geactiveerd die abnormale activiteit rond de productieklantendatabase aantoonde en toegewezen aan Amy, een ervaren beveiligingsanalist. Amy's eerste onderzoek toonde aan dat een interne gebruiker de hele database probeerde te doorzoeken en informatie opvroeg over meerdere klanten van meerdere IP-adressen in de hele organisatie. Het zoekpatroon was erg complex; in plaats van een eenvoudig opsommingspatroon dat je zou verwachten te zien wanneer een database wordt geschraapt, werden de gegevens van dezelfde klant meerdere keren opgevraagd, soms via verschillende IP-adressen en op verschillende datums. Zou dit een aanvaller kunnen zijn die probeert de beveiligingsmonitoringsystemen in de war te brengen?
Na een snel onderzoek ontdekte Amy een cruciaal stuk informatie: al die zoekopdrachten over alle IP-adressen en datums maakten gebruik van één enkele gebruikersidentiteit, iemand genaamd Jane van het klantenserviceteam.
Amy stak haar hand uit naar Jane om haar te vragen wat er aan de hand was. Jane wist het eerst niet. Zijn haar inloggegevens gestolen? Heeft ze op de verkeerde link geklikt of de verkeerde inkomende e-mail vertrouwd? Maar toen Jane Amy vertelde over de applicatie die ze onlangs had gebouwd, realiseerden ze zich allebei dat er een verband zou kunnen zijn. Amy, de SOC-analist, was niet bekend met low-code/no-code, dus namen ze contact op met het AppSec-team. Met de hulp van Jane kwam het team erachter dat Jane's aanmelding de inloggegevens van Jane bevatte. Vanuit het perspectief van de database was er geen applicatie - er was alleen Jane, die een heleboel query's uitvoerde.
Jane, Amy en het AppSec-team besloten de applicatie af te sluiten totdat er een oplossing was gevonden. Applicatiegebruikers in de hele organisatie waren gefrustreerd omdat ze erop waren gaan vertrouwen, en klanten voelden het ook.
Terwijl Amy het probleem afsloot en hun bevindingen documenteerde, was de VP van klantenservice niet blij met de daling van de klanttevredenheid, dus vroegen ze Jane om een permanente oplossing te zoeken. Met behulp van de documentatie van het platform en het Center of Excellence-team van de organisatie heeft Jane haar ingebedde identiteit uit de applicatie verwijderd, de app gewijzigd om de identiteit van elke gebruiker te gebruiken om de database te doorzoeken, en ervoor gezorgd dat gebruikers alleen toestemming krijgen voor klantcases waarmee ze zijn geassocieerd . In de nieuwe en verbeterde versie gebruikte de applicatie de identiteit van elke gebruiker om de klantendatabase te doorzoeken. Jane en de gebruikers van de applicatie waren blij dat de applicatie weer online is, Amy en het AppSec-team waren blij dat Jane's identiteit niet langer wordt gedeeld, en de onderneming zag de klanttevredenheid weer stijgen. Alles was goed.
Twee weken later ontving het SOC opnieuw een waarschuwing over abnormale toegang tot de productieklantendatabase. Het leek verdacht veel op de vorige waarschuwing in diezelfde database. Nogmaals, IP-adressen uit de hele organisatie gebruikten de identiteit van één gebruiker om de database te doorzoeken. Nogmaals, die gebruiker was Jane. Maar deze keer wisten het beveiligingsteam en Jane dat de app de identiteit van de gebruiker gebruikt. Wat gebeurd er?
Uit het onderzoek bleek dat de oorspronkelijke app had impliciet gedeeld Jane's geverifieerde databasesessie met de gebruikers van de app. Door de app te delen met een gebruiker, kreeg die gebruiker direct toegang tot de versterken, een wrapper rond een geverifieerde databasesessie die wordt geleverd door het low-code/no-code-platform. Met behulp van die verbinding konden gebruikers de geverifieerde sessie rechtstreeks gebruiken - ze hoefden niet langer via de app te gaan. Het bleek dat verschillende gebruikers dit ontdekt hadden en, in de veronderstelling dat dit het beoogde gedrag was, Jane's geauthenticeerde databasesessie gebruikten om hun zoekopdrachten uit te voeren. Ze waren dol op deze oplossing, omdat ze door rechtstreeks gebruik te maken van de verbinding volledige toegang hadden tot de database, niet alleen voor klantcases waaraan ze zijn toegewezen.
De verbinding is verwijderd en het incident is voorbij. De SOC-analist nam contact op met gebruikers die de verbinding van Jane hadden gebruikt om ervoor te zorgen dat ze alle opgeslagen klantgegevens weggooiden.
De low-code/no-code beveiligingsuitdaging aangaan
Het bovenstaande verhaal is een realistisch scenario van een multinationaal B2C-bedrijf. Sommige details zijn weggelaten of aangepast om de privacy te beschermen. We hebben gezien hoe een goedbedoelende werknemer ongewild zijn identiteit met andere gebruikers kon delen, wat een hele reeks problemen veroorzaakte in IT, beveiliging en het bedrijf. Zoals we vorige maand hebben onderzocht, is het delen van inloggegevens een belangrijk kenmerk van low-code/no-code. Het is de norm, niet de uitzondering.
As low-code/no-code blijft bloeien in de onderneming, bewust of onbewust, is het van cruciaal belang dat beveiligings- en IT-teams deelnemen aan het gesprek over bedrijfsontwikkeling. Low-code/no-code apps worden geleverd met een unieke reeks beveiligingsuitdagingen, en hun productieve karakter betekent dat die uitdagingen sneller acuut worden dan ooit tevoren.
