Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 35 reacties

Het internationale systeem voor bankverkeer Swift zal strenger worden beveiligd. Dat moet voorkomen dat hackers digitaal binnendringen en geld wegsluizen, iets dat in de afgelopen tijd steeds veelvuldiger gebeurt.

Op de jaarlijkse Sibos-bijeenkomst in Geneve liet Gottfried Leibbrandt, ceo bij Swift, weten dat er nieuwe beveiligingsmaatregelen worden ingevoerd en dat bestaande procedures onder de loep worden genomen. Dat bericht persbureau Reuters. De directe aanleiding is de toename in het aantal hacks bij banken, waarbij inbrekers soms tientallen miljoenen euro's buitmaken.

Omdat hackers volgens Leibbrandt steeds geraffineerder te werk gaan, ondermijnt dat het vertrouwen in transacties die via Swift worden gedaan. Dat blijkt ook uit een hack van de centrale bank in Bangladesh in februari, waarbij 81 miljoen dollar, omgerekend ongeveer 72 miljoen euro, werd weggesluisd. Uit een analyse bleek dat de hack mogelijk werd gemaakt door een kwetsbaarheid in de Swift-software. Ook waren er hacks in Oekraïne, Ecuador en Vietnam.

Banken nemen zelf ook extra beveiligingsmaatregelen. Zo bericht Reuters over de Franse bank Société Générale, waar werknemers verplicht zijn om bij Swift-transacties zichzelf te identificeren met een vingerafdrukscanner. Ook is bekend dat banken kijken naar alternatieve beveiligingstechnologieën, zoals de blockchain.

Swift waarschuwt al langer voor de gevaren van digitale bankroof. Eerder dit jaar werden er ook al nieuwe beveiligingsprocedures uitgerold, en werd het bedrijf Fox-IT ingeschakeld om de beveiliging op te schroeven.

Moderatie-faq Wijzig weergave

Reacties (35)

Swift is nalatig geweest want de zwakheden zijn al twintig jaar bekend. Nu er op grote schaal geplunderd wordt en mensen het vertrouwen verliezen in het internationale betalingsverkeer gaat men pas actie ondernemen.

Ze moeten een apart fysiek netwerk optuigen wat niet met het internet verbonden is. Het kan wel dezelfde protocollen als internet gebruiken.
Ze moeten een apart fysiek netwerk optuigen wat niet met het internet verbonden is. Het kan wel dezelfde protocollen als internet gebruiken.

Dat is reeds grotendeels zo en voor zover niet lost niets op. De hacks waren door het besmetten van de interne bedirjfscomputers van getroffen banken, en niet door inbraken op Swift zelf of inbraken vanuit het internet.
Het is niet een apart fysiek netwerk met aparte fysieke kabels. En de apparatuur is indirect gewoon aangesloten op het internet.

Dat maakt het extreem kwetsbaar. De gebruikte computers zijn ook gewoon standaard PC's. Vroeger waren het mainframes en minicomputers waar niet iedereen aan kon komen, laat staan een virus voor kon schrijven.

[Reactie gewijzigd door ArtGod op 29 september 2016 21:36]

Dus 'security through obscurity' door mainframes met aparte programmeertalen enz. te gebruiken is beter?...
Met een volledig eigen netwerk voor betaling naast het internet, hoe wil je dan ooit internetbankieren doen om maar het eerste slachtoffer van je plan te noemen ;)
Het is meer "security through scarcity"

Het maakt het wel een stuk moeilijker want je kan niet zomaar aan zo'n machine komen laat staan er software op ontwikkelen. Iedereen heeft tegenwoordig een PC waar je software op kan ontwikkelen voor dit soort hacks. Dat maakt de kans dat het gaat gebeuren ook veel groter.
want je kan niet zomaar aan zo'n machine komen laat staan er software op ontwikkelen

Dit soort hacks zijn semi-insider hacks. Bij de wereld van ATM machines wordt er ook voortdurend nieuwe skimmer-software ontwikkeld en vervolgens aangetroffen op machines, ondanks dat het vaak custom-made is voor merk X van terminal type Y. Dus het argument van non-standaard materiaal gebruiken geeft je geen beveiliging, maar wel de vele nadelen.

Het PC zijn of niet is verder irrelevant, want het gaat veel meer om de interfaces met de betalingssystemen.

Tenslotte, systemen afsluiten van het intranet om het helemaal air-gapped te maken tov het internet klinkt leuk, maar met miljoenen transacties per minuut als het niet meer is, is dat niet haalbaar. Immers de afkomst van die transacties is wel van het "internet". O.a. ik die met mijn webbrowser via ING.nl inlogt en geld overboekt naar het buitenland. Wil je dat een bankmedewerker handmatig die data gaat overtypen of met USB stick overzetten?
Heb je al wel eens goed rondgekeken? De Personas ATM's van bv NCR zijn wereldwijd te vinden. Hier in de UK, in Belgie, in Litouwen, in Servie, in Spanje, om maar een paar plekken te noemen waar ik ze zelf ben tegengekomen.... En die dingen draaien ook gewoon op Windows XP/Windows 7 hoor... Met een Pentium 4 of Core (2) Duo.
De banken zelf schrijven en leveren inderdaad de software aan maar elke software bevat wel lekken. En als je bijvoorbeeld zoals KBC in Belgie een 3000-tal machines hebt staan, kan ik goed inkomen dat er daar een paar door de mazen van het net glippen.
Ook omdat die PC's door verschillende handen gaan eer ze in zo'n machine terecht komen : De mensen die ze diagnosen en repairen, de mensen die ze stagen, de mensen die ze vervoeren en de mensen die ze plaatsen. Om nog maar te zwijgen over laks omgaan met bedrijfsgeheimen, niet iedereen tilt even zwaar aan oplettendheid als het gaat om wat bijwerken op de trein of een USB stick (per ongeluk?) mee naar huis nemen en ondertussen verliezen.
Precies waar ik op doel. Het gebruik van non-standaard systemen geeft dus geen veiligheid. Immers die geheime systemen lekken uit, en de mensen die ermee werken zijn ook vatbaar voor verleidingen van de "dark side".

Dus exotische hardware gebruiken voor Swift geen enkel voordeel, maar wel de evidente nadelen.

Overigens zoals aangegeven bleek de onveiligeid van de bank systemen niet zozeer een Swift probleem te zijn, maar gebrekkige beveiliging van het intranet van de getroffen banken, en qua oorzaak malware die geschreven was voor de (toevallig non-standaard _/-\o_ ) custom-made bank-software die communcieerde met het Swift systeem.

Wat Swift nu gaat doen, is meer inherente veiligheden inbouwen die kunnen ingrijpen als de primaire security (die van de banken) faalt. Maar de primaire veiligheid ligt nog altijd daar. Met Swift kun je immers enkel makkelijk geld internationaal wegsluizen, maar het geld wordt uiteindelijk gestolen van een bank, alwaar een malafide opdracht tot overboeking gedaan wordt.
Ik vind jouw beredenering niet staven met der werkelijkheid. Toen er exotische hardware werd gebruikt waren er nooit hacks en nu alle banken standaard PC's en standaard Windows besturingssysteem software gebruiken wel.

[Reactie gewijzigd door ArtGod op 30 september 2016 09:48]

Vroeger waren er ook hacks, maar kwamen ze niet in het nieuws. Al 20+ jaar lang gebruikt men PC terminals. En toen zonder malware scanners en aanzienlijk minder controle.

Het verschil is vooral het exponentieel toegenomen aantal transacties en we bijbehorende wens tot automatisering. Vroeger moest je met een papieren formulier naar de bankbalie en typte en medewerker het handmatig over na controle van jouw ID. Nu type je het in op je webbrowser thuis.

Deze indirecte koppeling tussen internet en intranet maakt systemen vatbaar, maar is onvoorkomelijk ivm het enorme aantal transacties en gebruiksgemak dat wij eisen.
Juist... dus een zo basic mogelijk systeem gebruiken met beproefde en ondersteunde open-source software.
Alleen de pakketten die nodig zijn, en eigen software ook open-sourcen.
Peer-reviewed code.
Ik zie telkens reacties langs komen waarin men open source gelijk stelt aan veilig. Dat is echt klinkklare onzin. Open source maakt het hackers juist makkelijker.

Als je denkt dat reviews van open source code (als dit Łberhaupt al gebeurt) door andere ontwikkelaars, of zelfs security experts ervoor gaat zorgen dat alle exploitable bugs uit code verdwijnen, heb je het mis. Het geeft hackers juist de mogelijkheid om te doen waar ze erg goed in zijn, namelijk die bugs vinden. Dit is met broncode vele malen makkelijker dan met gedecompileerde code.
Open source maakt het hackers juist makkelijker.
Dat is net zulke grote onzin als de omgekeerde stelling waar je op reageert. Het lijkt mij de taak van de belanghebbenden, dus in dit geval Swift en de banken, om er voor te zorgen dat de software die ze gebruiken goede audits heeft ondergaan op gebied van betrouwbaarheid en veiligheid. Met open source software kan je dat doen op het niveau van de broncode, met gesloten software zal je dat op andere manieren moeten doen. Beide methoden hebben voor- en nadelen.

Feit blijft dat dit geld en mankracht kost en dat de financiŽle wereld wat mij betreft voorlopig erg weinig van beiden heeft gebruikt om dergelijke audits uit te voeren. Dit zou je gemakkelijk kunnen zien als nalatigheid, zoals de originele poster dan ook terecht beweert.
Ik weet niet hoe waar het is, maar ik zie het nog best wel eens gebeurd zijn...
De bron van wie ik dit hoorde is werkzaam bij een bedrijf wat financiŽle (boekhoud) software maakt:

Dergelijke systemen zouden met een virtueel toetsenbord bestuurd worden, waarbij het virtuele toetsenbord weer aangestuurd werd door een internet-facing API. Hierdoor kan je legacy systemen toch nog besturen via REST API's en dergelijke.
Ik hoor al direct dat jij precies weet hoe je een internationaal netwerk moet bouwen ....

Ik denk het iets gecompliceerder ligt.
Heb je enig idee wie er allemaal met swift verbinding maakt en welke data er allemaal verwerkt wordt? Hoe wil je daar ooit een fysiek gescheiden netwerk voor aanleggen? Heb je toevallig enkele tientallen miljarden euro in reserve liggen om dat plan ten uitvoer te brengen?
Ik vraag me dan af waarom dit dan niet meteen gebeurd, als bank moet je toch meteen al het veiligst mogelijke gebruiken/doen?
Hoewel de meningen daar over verschillen, lijken alternatieven als distributed ledgers/blockchain voor banken zeker interessant. Toch zal het zeker bij banken nog wel flink getest worden voordat deze gebruikt zullen worden in productie. Zie bijvoorbeeld http://www.coindesk.com/r...-tool-isnt-just-database/?
Een blockchain-techniek maakt het vooral moeilijker een digitale bankroof terug te draaien.
Als een aanvaller in de plaats van een medewerker een transactie kan doen kan deze namelijk nog steeds geld wegsluizen.
Klopt :) Maar als je het permissioned maakt weet je precies de medewerker te vinden die de key heeft gelekt (bewust of onbewust) en gepaste maatregelen nemen.
Dan ben je toch geen stap verder? Ze kunnen nu met alle logs ook wel achterhalen welke medewerker het was/gehacked is; dat maakt dan toch geen verschil? :)
Maakt het gebruikelijke log (textfile, key-value store, ...) integraal onderdeel uit van de infrastructuur en wordt daarbij de integriteit en chronologische volgorde gewaarborgd met cryptografie?

En kun je met de gebruikelijke logs garanderen dat elke kopie van het log op elke node aanwezig is, en continu gesynchroniseerd is met het hele netwerk?

Elke transactie op een blockchain is direct de regel die je normaal gesproken in een vaak losgekoppeld log-file zou zetten. Omdat de transactie digitaal ondertekend is, bestaat de handeling niet zonder het betreffende log-entry wat naar mijn mening wel degelijk verschil maakt :)
Dat kan je niet garanderen als de servers van de bank gehacked worden en de info gemanipuleerd is, nee; maar als je er zover in komt: dan heb je niet meer zo snel iemand nodig om je nog een sleutel oid te geven denk ik. Al ligt dat natuurlijk aan implementaties.

Maar the point being; als je dus enkel de autorisatiesleutel weet te jatten, door bijv. dom gedrag als een USB stick oppakken en blind in je PC proppen, dan maakt het achterliggende systeem om de transactie vast te leggen toch geen verschil? :) Of dat nou iets is van nu of dat het een blockchain technologie is.

Dat de transactie an sich beter traceerbeer, te verifiŽren en te playbacken valt: dat spreek ik niet tegen, ik vraag me enkel af waarom het verschil maakt bij het jatten van de sleutels van een medewerker. Daar beschermt het niet extra tegen, toch?

[Reactie gewijzigd door WhatsappHack op 30 september 2016 00:13]

Dat klopt, met het jatten van de sleutel/achterhalen van wachtwoord kan je daarna alle transacties uitvoeren die met de bijbehorende autorisatie mogelijk zijn.

Wat niet meer kan is je sporen uitwissen, wat ook nog weleens van toepassing kan komen als de betreffende interne medewerker toch niet zo betrouwbaar is dan hij/zij zou moeten zijn.

Wat ook nog mogelijk is bij de gebruikte multichain oplossing, is om de betreffende transacties uitgevoerd met het betreffende sleutelpaar, vanaf een specifiek tijdstip "terug te draaien". Hierbij betekent terug draaien in dezelfde transactie omgekeerd uitvoeren om de schade teniet te doen, gezien verwijderen echt niet mogelijk is.

Wat ik ook erg interessant vind aan multichain, is dat de toegangsrechten ook via blockchaintransacties geregeld worden, dus als een corrupte administrator een half uurtje toegang gaf aan een onbetrouwbare partij, dan is ook dat terug te zien.
Nee, de regel is dat het eerst fout moet gaan voordat iedereen overtuigd is dat verbeteringen nodig zijn.
Nee de regel is dat het eerst fout moet gaan voor men er van overtuigd is dat er geld uitgegeven moet worden om het te verbeteren :P
Kosten / baten.
Zolang de schade niet hoger is als de te verwachten investering gebeurd er simpelweg niets.

Maar nu blijkbaar de Swiftsoftware een soort gatenkaas begint te worden en er zeer lukratieve bedragen te halen zijn veranderd die balans.
Kalf. Put. Verdronken.
Men heft het glas en doet een plas, en alles bleef zoals het was
zo zo... dat duurde wel even...
"Banken die hebben het goed voor elkaar......"

Blijkt net zo'n zooitje te zijn als overal....... Welcome to the real world.
Het blijft natuurlijk grotendeels mensenwerk...en daar zit denk ik ook gelijk het probleem...
Een groot deel van de beveiligingsproblemen waar bedrijven mee kampen, komt toch echt voort uit het personeel...
Zaken die de beveiliging beter maken, door bepaald gedrag af te dwingen, zijn vaak niet populair (maar eigenlijk wel nodig).

Bijvoorbeeld: hoe moeilijk is het voor een vreemde om bij jou in het bedrijf binnen te lopen? (eenmaal binnen is het aftappen van een verbinding of het vinden van een pc die niet gelockt is simpel).
Hoe moeilijk is het voor een corrupte collega om rechten te krijgen die hij/zij eigenlijk niet zou mogen hebben? Hoe vaak groeit het niet zo dat iemand rechten krijgt voor een bepaald project die later niet meer afgepakt worden?
Dwingt het systeem af dat bepaalde beslissingen (acties) door meerdere mensen gefiatteerd moeten worden?
Hoeveel bedrijven zijn er wel niet waarbij je gewoon een USB stick in een computer kunt steken en op die manier hele databases leeg kunt halen? Of een simpel spionage stickie (zijn bijna niet zichtbaar zo klein) die alles logt en doorstuurt wat een gebruiker intypt?

Er zijn vaak veel grotere interne gevaren te benoemen dan 'het standaard hacken' door een externe partij. Over het laatste valt iedereen, want dan is de ICT beveiliging niet op orde, maar bij de meeste bedrijven is het personeel toch echt het gevaarlijkst. Afdwingen van juist gedrag (b.v. door dichtzetten USB poorten) stuit vaak op zoveel weerstand intern dat het niet of te weinig gebeurd.

En dan zet je de deuren dus in feite open voor fraude, corruptie en ja, zelfs voor hackers..

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True