TL; DR:
- Gezien de gevoeligheid voor compliance moeten de beste leveranciers voor financiële instellingen beschikken over SOC2 Type 2-certificeringen, PCI DSS SAQ-D en meer.
- Financiële instellingen zijn nationale doelwitten voor slechte actoren. Daarom worden de beste beveiligingsleveranciers voor hen geïnvesteerd om op het scherpst van de snede te zijn op technisch gebied. Goed genoeg is niet goed genoeg. Een indicator voor de juiste houding ten opzichte van het allernieuwste is de bijdrage aan standaardorganisaties als het W3C, IETF en TC39.
- Beveiliging is gelaagdheid: een leverancier die een meerlaags beveiligingsmodel aanbiedt, helpt bedrijven veilig te blijven wanneer kwaadwillenden proberen omzeilingen voor beveiligingslagen te bouwen.
- Conclusie: de beste oplossing voor financiële instellingen is de meerlaagse aanpak van cside.
Wat is beveiliging aan de clientzijde?
Beveiliging aan de clientzijde is de praktijk van het beschermen van de JavaScript-afhankelijkheden, gebruikersgegevens en gedragingen die in de browser van de bezoeker worden uitgevoerd.
Dit omvat:
- First-party scripts: JavaScript-bestanden geladen vanuit uw eigen domein
- Scripts van derden: van analysetools, advertenties, chatbots, tagmanagers en A/B-testtools
- Inline-scripts, ingesloten inhoud zoals widgets en SDK's
- Gegevens verwerkt of opgehaald door de browser
Alles wat er gebeurt na de initiële HTML-reactie van de webserver is een actie aan de clientzijde. Aanvallers gebruiken de browser steeds vaker om kwaadaardige acties uit te voeren in een poging waardevolle gevoelige informatie te verkrijgen. Wanneer gegevens worden opgehaald uit het domein van een derde partij, dienen scripts vaak anders op basis van IP, verzoekheaders, tijdstip van de dag, locatie enz.
Bijvoorbeeld: een marketingtool verzamelt in Europa verschillende gegevens uit de VS om te voldoen aan de gegevensprivacy.
Vooral voor waardevolle doelen is het gebruik van een client-side fetch om een kwaadaardige payload te injecteren een veel voorkomende actie, omdat het veel moeilijker te detecteren is en de slechte actor lange tijd onder de radar kan blijven, tenzij er een runtime-beveiligingsoplossing aan de clientzijde wordt gebruikt.
Waarom worden financiële instellingen geclassificeerd als een natiestaatdoel?
Sommige slechte acteurs willen niet alleen snel geld verdienen. Ze kunnen door de staat worden gesponsord en gestimuleerd om grote schade aan te richten. Destabiliseer essentiële diensten die nodig zijn om economieën te laten draaien.
Financiële instellingen zijn een belangrijk doelwit en met hun omvang en blootstelling brengen extra risico's en dus kansen voor de slechte actoren met zich mee. Als de banken failliet gaan, gaat de economie ook failliet.
Financiële instellingen bevinden zich in hetzelfde domein als IT-omgevingen van de overheid, grootschalige zorgaanbieders en kritieke infrastructuur zoals openbaar vervoer en energieleveranciers.
Om geloofwaardigheid in de financiële sector op te bouwen, moeten merken een aanzienlijk meerjarig proces doorlopen om het vertrouwen van verschillende soorten klanten te winnen. Dat brengt aanzienlijke technische schulden met zich mee via oudere applicaties.
Een uitgebreide en verouderde infrastructuur vergroot het aanvalsoppervlak
Het is geen branchegeheim dat veel van de grote financiële instellingen nog steeds op COBOL draaien. EEN onderzoekspapier van een lid van de technische staf van PayPal stelt het probleem heel duidelijk: “De traditionele bankinfrastructuur is vaak verouderd en heeft moeite om te voldoen aan de toenemende vraag naar naadloze, realtime digitale diensten.”
Dit betekent dat oudere webapplicaties vaak gelaagd zijn met modernere technologieën die het aanvalsoppervlak vergroten om nieuwe gebruikerservaringen te creëren. Door gebruik te maken van kwetsbare back-ends om scripts aan de clientzijde te injecteren of zich te richten op verouderde afhankelijkheden om de toeleveringsketen te infiltreren, kunnen slechte actoren ernstige schade toebrengen aan de wereldeconomie.
Aanvallen aan de clientzijde zijn gericht op specifieke activa
Aanvallen aan de cliëntzijde tegen financiële instellingen zijn doorgaans gericht op:
- Gebruikersgegevens en sessietokens om toegang te krijgen tot accounts
- Betaalkaartgegevens
- Bankafschriften en gevoelige identiteitsgegevens
Strenge regelgevings- en nalevingsvereisten
Financiële instellingen zijn onderworpen aan een aanzienlijke lijst van compliance-kaders om te kunnen opereren; hun bankvergunning is afhankelijk van compliance. Dit varieert van het voldoen aan PCI DSS, DORA, lokale privacywetten zoals CCPA of GDPR en als een teken van vertrouwen, maar vaak een vereiste voor zakelijke klanten: SOC2 Type 2, ISO 27001…
Welke aanpak is het beste voor financiële instellingen?
Gezien de ernst van het doelwit is er weinig ruimte voor fouten. Een goede oplossing moet dus als gegoten zitten bij de toepassing.
Daarom is een lagenbenadering ideaal. Zeker als de oplossing in kwestie aanpasbaar is en transparantie en controle creëert waar voorheen geen controle bestond.
Daarom hebben we cside gebouwd als een platform dat gebruik maakt van alle verschillende lagen die tot nu toe beschikbaar zijn.
cside biedt twee complementaire implementatiemethoden, gecombineerd met meerdere detectiemotoren, waaronder open source Large Language Models voor analyse.
- Script Methode (eenvoudigst): we controleren scriptgedrag in de browser en halen de scripts aan onze kant op, en verifiëren vervolgens of het hetzelfde script is. We plaatsen onszelf niet in het pad van een script tenzij je daar expliciet om vraagt. Eenvoudig te implementeren, geen prestatie-impact, en je kunt nog steeds scriptacties stoppen of blokkeren op URL, hash of domein.
- Scan Methode (snelst): als je geen script aan je site kunt toevoegen, scant cside het met behulp van threat intelligence van duizenden andere websites met miljarden gezamenlijke bezoekers. Snel op te zetten en nuttig wanneer scriptinstallatie niet mogelijk is.
We bieden ook een Content Security Policy-endpoint zodat klanten browser-native handhaving naast cside's op JavaScript gebaseerde detectie kunnen leggen.
Beveiliging vereist een meerlaags model
De meeste beveiligingstools zijn afhankelijk van slechts één van de bovengenoemde lagen, hetzij runtime, hetzij extern bij het scannen. Maar het probleem is dat geen van deze lagen op zichzelf volledig kogelvrij is en daarom geen alomvattende dekking biedt. Door motoren te combineren kom je steeds dichter bij volledige dekking.
Veel oplossingen op de markt zijn nevenfuncties van grotere webbeveiligingsbedrijven. In plaats van een platform te bouwen voor beveiliging aan de clientzijde, bouwden ze een kleine nevenfunctie. Deze oplossingen worden beperkt door de focus van het bedrijf. Vaak is de clientzijde een gebied waarin ze niet bereid zijn substantiële middelen te investeren en daarom uitsluitend vertrouwen op het injecteren van Content Security Policies in de website via hun WAF.
Sommige oplossingen zijn in feite slechts scanners. Slechte acteurs zien de scanners en bedienen de kwaadaardige scripts niet tot hun punt in de tijd. Gezien de waarde van het doel is deze aanpak niet effectief.
Voor compliancedoeleinden is het handig dat de oplossing dashboards biedt die specifiek op elk raamwerk zijn gericht. Frameworks worden geleverd met een reeks unieke bedieningselementen en het handmatig verzamelen van die gegevens is een pijnlijk continu karwei.
Sommige benaderingen, zoals op scanners gebaseerde oplossingen, blijken vaak te worden omzeild door slechte actoren. Ze detecteren de scanner en serveren schone inhoud aan de scanner om onder de radar te vliegen. Onderzoekers bij ISACA, Universiteit van Brighton, Google en Orakel hebben aangetoond dat dynamische client-side scripts de statische analyse door scanners effectief omzeilen.
cside is altijd op zoek naar mogelijkheden om zijn mogelijkheden uit te breiden en is actief bezig met het pushen van een aantal nieuwe standaarden die een sterkere beveiliging aan de clientzijde mogelijk maken met behulp van native browserfunctionaliteit.
Het cside-team levert actieve bijdragen aan standaardorganisaties zoals het W3C, IETF en TC39.
Klaar om cside uit te proberen? Begin gratis of boek een demo om een praatje te maken met ons team.
