Een kwartaalrapport gepubliceerd door een geïntegreerd app- en beveiligingsplatform Muurarm geeft gedetailleerde aandacht aan een weinig besproken maar cruciaal beveiligingsprobleem voor fintechs: hun API’s. De rapporten zijn ontwikkeld op basis van openbaar beschikbare bronnen.
Mede-oprichter en CEO van Wallarm Ivan Novikov zei dat zijn doel voor de rapporten is om de omvang van de bedreigingen in te schatten en deze in verstandige secties te groeperen. Dit helpt CISO's en cybersecuritymanagers de gevaren te meten en op te bouwen risicomodellen. Elk kwartaal analyseert het Wallarm-team elk beschikbaar incident, combineert het met aanvullende informatie en verrijkt het.
Novikov zei dat focus realtime analyses oplevert met betere inzichten dan andere rapporten die minder vaak worden gepubliceerd. Het identificeert ook enkele nieuwe dreigingsgroepen die waarschijnlijk kunnen worden toegeschreven aan de proliferatie van API-gebruik.
Lekken uit API’s vormen een opkomende bedreiging
Injecties waren veruit het grootste probleem dit kwartaal. Hun 59 bekende voorvallen vertegenwoordigen 25% van de 239 getraceerde acties. Injecties vinden plaats wanneer iemand gevaarlijke API-opdrachten verzendt via een gebruikersinvoerveld. Authenticatiefouten staan op de tweede plaats met 37. Hierbij gaat het om mislukte identiteitsverificatie. Cross-site problemen staan op de derde plaats met 30.
API-lekken vormen meer dan 10% van de incidenten. Ze hebben Netflix, leveranciers van open source-software en zakelijke softwarebedrijven getroffen. Novikov zei dat API-lekken een recent ontdekt probleem zijn.
Er zijn twee soorten API’s, waarvan er één specifiek van invloed is op fintechs: open API’s voor het bankwezen. Novikov zei dat instellingen in twee dingen geïnteresseerd zijn. De eerste is het volgen waar hun financiële gegevens naartoe gaan. Dit omvat persoonlijk identificeerbare informatie en interne bankrekeninggegevens. Ze moeten weten of het ergens wordt overgeheveld waar het niet hoort.
“Als je merkt dat de interne bankrekeningnummers als routeringsnummer met elkaar verbonden zijn, kunnen criminelen veel dingen doen”, zei Novikov. “Ze kunnen een heel ander fraudeschema uitvoeren. Als je je de films met James Bond herinnert, zeggen ze: ‘Ik weet je rekeningnummer in Zwitserland’, het is precies hetzelfde.”
Deze gegevensstukken kunnen privétoegang zijn via uw API. Het kunnen certificaten zijn die u aan een partnerbank hebt uitgegeven en die zijn gecompromitteerd. Iedere partij met wie u een sleutel deelt, is daarvoor verantwoordelijk, maar u bent zelf verantwoordelijk voor de open data.
Hoewel banken vele mogelijkheden hebben om zichzelf te beschermen als wachtwoorden en inloggegevens in gevaar komen, zegt Novikov dat API's maar één sleutel hebben, en dat is alles. Een bank accepteert het en jij bent een partner.
“Daarom bouwen we oplossingen om dit probleem op te lossen, omdat het probleem enorm is.”
De verouderende infrastructuur verergert het probleem
De ouderdom van veel bank-API’s maakt de uitdaging nog groter. Bij oudere exemplaren is het moeilijker te achterhalen wie de sleutel heeft gedefinieerd. Het staat ergens in de code. Novikov heeft voorbeelden gezien in COBOL die teruggaan tot 1998.
"Het zit ergens in de code en je kunt het daar vandaan halen", zei Novikov. 'Het is een hardgecodeerde sleutel die iemand erin heeft gestopt. Maak verbinding met XML en u bent klaar om te gaan. En nu hebben we daar een mooie API-gateway bovenop gezet en deze open banking genoemd. Het is open, maar het is open vanuit een ander perspectief. Er zitten heel erg gaten in.”
Houd uw partners in de gaten
Gezien het aanzienlijke risico is het de taak van financiële instellingen om ervoor te zorgen dat zij hun partners kunnen vertrouwen. Novikov zei dat er meer comfort is voor banken, die normen kunnen definiëren waaraan hun dataproviders moeten voldoen.
Voor fintechs is het wat losser. Novikov moedigt hen aan om hun normen te bepalen. Deel een sleutel met een fintech-facilitator, en zij zijn ervoor verantwoordelijk.
“Als fintech zijn ze niet gereguleerd zoals een bank”, zei Novikov. “Dat moeten ze zelf doen. In dit geval vertrouwen ze op (banken) en moeten ze op zichzelf vertrouwen. Dat is een groot probleem, want als ik mijn Robinhood aan mijn bank wil koppelen, kan ik niet anders.”
Omdat er geen industriestandaard bestaat, kunnen fintechs beslissen hoeveel beveiliging ze willen inzetten. En als uw hele bedrijf draait om API's, kan die beveiliging maar beter goed zijn.
VP van Marketing Girish Bhat zei Wallarm bouwt een cloud-native platform dat ook op locatie kan worden gebruikt. Het kan aanvallen bijna in realtime detecteren. Het kan reparatie-aanbevelingen en herstelmogelijkheden bieden door samen te werken met de andere tools in een fintech-ecosysteem.
“Er vinden miljarden API-aanroepen plaats”, zei Bhat. “We kunnen dat in realtime analyseren en de proactieve mogelijkheden bieden om deze te beperken.”
Zwakke referenties en problemen met cryptografie zijn een verrassende nieuwkomer op de Top 10-lijst met problemen. Novikov zei dat veel bedrijven standaard- en standaardsleutels gebruiken.
"Het is voor iedereen duidelijk dat je geen standaard- of standaardsleutels moet gebruiken, maar het gebeurt nog steeds steeds vaker", zei hij. “Helaas kunnen we hier om de een of andere reden nog steeds niet vanaf komen.”
Hoe ChatGPT heeft geholpen bij de ontwikkeling van het AAA-systeem van Wallarm
Wallarm gebruikte ChatGPT om bedreigingen in een AAA-systeem te sorteren (authenticatie, autorisatie en toegangscontrole). Authenticatie is de eerste verdedigingslinie. Door het te isoleren kan Wallarm zich richten op kwetsbaarheden die specifiek misbruik maken van de mazen in de authenticatie.
Wanneer autorisatie wordt gescheiden van authenticatie, helpt dit bij het identificeren wanneer systemen onnodige machtigingen verlenen. Bij toegangscontrole wordt rekening gehouden met factoren als apparaat, IP-adres en tijdstip. Het helpt tekortkomingen in de handhavingsmechanismen op te sporen.
“We kunnen de bank-API’s of de bank-app richten om specifiek te controleren of een manager iets kan doen buiten de ontwerprechten”, zegt Novikov. “En we zien bij bedrijfsapps dat het moeilijk is om beveiligingscontroles, scanners en wat ze ook hebben te omzeilen.
“Het is echter relatief eenvoudig om fouten te maken bij toegangscontroles, omdat de toegangscontrole vaak alleen maar wordt beheerd; het is geen onderdeel van de code. Het stelt ons in staat om niet alleen op het selectievakje te klikken terwijl we bepaalde compliance-apps of API's uitvoeren en dit aan te vinken. Slechte toegangscontrole is iets anders: je moet het apart controleren.”
