This is good in a lot of ways. The security aspect has me wondering, though. Most of the big banks have mainframes, obscure software in obscure language, and little trip-wires throughout their stacks. The hackers neither know how to hack them nor want to lease a small mainframe to find out. It’s a big pile of obfuscation that works most of the time. The hacks that get through are mostly insiders. The culprits are usually detected due to auditing but sometimes not.
This infrastructure is built with modern stacks that hackers know how to attack. There’s whole, underground markets for hitting the underlying components at low cost or high reliability. The stack will probably be easier to reverse engineer in terms of UI, data formats, etc as well. I wonder if they’re setting themselves up for more attacks this way. It might be worth it to them to keep costs low & flexibility + development pace high. Yet, attacks on their finances might cost them a ton. Maybe literally if it were printed and weighed. Go language seems like a good choice for reducing amount of unsafe code in system. Can any Go users tell me if most of the standard lib, runtime, etc are written in Go with its safety? Or not with bypasses possible? And what’s the odds that they’re using third-party libraries written in C? Go ecosystem already provided about everything they’d need for key components?
If I wanted low cost and high flexibility, I’d go with a secure UNIX + memory-safe language w/ similar stdlib where possible (Ada/SPARK or Rust) + careful protocols + ability to get off it at any time just buying extra hardware for export and/or sync of data. Get something better with lower TCB later or greater flexibility later when I have the money and expertise on-board. Use proven components people can learn to use safely and quickly in the meantime.
I think you’re being a bit too romantic about banks and mainframes. Yes, they do have mainframe (especially for retail banking). But it’s deep and there are layers upon layers of enterprise Java above the mainframe, all of which a hacker knows how to attack.
I’ve seen this talk given for financial services for just about every language. Despite developers perhaps enjoying Go more than Java, I don’t see any reason to think that Go is particularly more secure than Java. And it’s not clear to me that microservices are more secure than a monolith. There might be organizational reasons to have microservices but given that transactional boundaries are difficult to express and enforce in a microservice architecture, I’m not sure security is a free-win.
They can try to hit the front-end. It gets converted into the mainframe stuff that then goes through the internal controls. Some things will be blocked with some things going through with logging to try to reverse them or punish the offender if possible. That’s what bankers told me, anyway.
I’d watch the front-end’s to see what traffic shows up on new transactions, large transactions, and especially combos of both. Spot any extra computers that seem to authorize stuff for multiple people signing off on a major change. Also look for if logging information is sent, if there’s traffic/commands to delete logs, and bad configuration of mainframe by reading IBM Red Books. Any of these might be exploited to set up a target for a transfer, initiate one, spoof secondary authorizations, and prevent/remove logs. I mean, someone will see it somehow eventually but just getting them out of the bank into an intermediary lets attacker move fast from there.
That’s what I would do anyway. I’ve seen both Java and C# in banks as you said. If enough security logic is in front ends, then hacking those might be pretty easy. :)
Do you know what percentage of bank attacks are actually hacking the bank and what percentage are just getting ignorant users to do something dumb?
I did have a report on that but can’t find it any more. For a recent one, I pulled Verizon’s survey on breaches, methods, etc. It’s a start:
The report indicates social engineering and attacks on personal devices are becoming the majority of attack patterns. However, a section showing the breakdown of attacks per sector showed finance to be 34% DOS attacks, 48% web app attacks, and less than 1% “stolen assets.” That seems to contradict the known losses until you consider most are coming from fraudulent use of cards via identity theft where losses hit consumers & are single-digit side for total that banks absorb. Krebs reports a significant amount of ACH loss due to stolen credentials which again either doesn’t impact the bank or barely does. So, most of the attacks seem to hit the customers.
I do recall some huge losses recently from both hackers and malware [which may be socially engineered]. These are highly-targeted attacks usually in countries with less money for defense and cheaper bribery of employees. I’m not sure how much it tells us about First World countries with high, cost of living if there were bribes or low-budget security involved. I mean, it says smaller or community banks might be at similar risk. Just hard to be sure what it is.
Use of C libraries is generally discouraged by the Go community, and not only most of the Go distribution – not only the compiler, but also the standard libraries – but also any packages you are likely to use are consequently written in Go. This has a bad side and a good side: new implementations of old protocols might need to go through the a long process of shaking out bugs, but reading uninitialized memory is not liable to be among them.
Go is probably not replacing C for most of these use cases though, but rather Java.
Thank you. Ok, then their memory safety should improve quite a bit over a Java or C# stack that’s common in banks.
Java banking apps tend to have a lot of C or C++?
Huh? The runtimes and support libraries on the bottom were written in C/C++ last time I looked at them. It might have changed since. One guy sent me a bunch of info on Oracle’s project for Java stack that’s totally Java. Microsoft has been writing system software, including an OS, in variant or restricted form of C#. Maybe one or the other got rid of all the C/C++ by now. Far as I knew, there was still plenty unsafe code in both that expose risk if it’s used by safe code processing malicious input with calls to that unsafe code.