Server abuse is difficult, but not impossible and since getting a banking licence usually does not verify any security measures, I'm wondering what they already did (or didn't) do.
(I'm well aware of the state-of-the-art, and the usual less than so, security of banking apps).
We see Mondo as an opportunity to build a great security culture from the ground up. We're currently hiring a Head of Security role in London: https://getmondo.co.uk/careers
If you know anyone that
- is an excellent communicator
- likes to code and does so regularly
- can think like a black hat (CVEs and PoCs please!)
- doesn't mind writing the occasional policy document
please send them my way: jonas@getmondo.co.uk
BTW, at the moment we are not holding customer balances or approving transactions so we're not a particularly juicy target, yet. That said, we've already conducted pen tests and invited a number of security firms to come and break our software :)
Most of the pentesters/vuln researchers I know aren't huge fans of writing ISO2700x style policies documents (actually thinking about it there aren't many people who are fans of that kind of thing!)
if you're looking for non-traditional advertising routes for this you might want to post on /r/netsec's hiring thread https://www.reddit.com/r/netsec/comments/3zfj6v/rnetsecs_q1_...
I'd rather hire a CISO that understands security and teach them how to think like a regulator than vice versa! Heck, I have long hair myself and didn't have any contact with policy documents until just over a year ago. And both our CTO and CEO like to write code.
Basically, we're looking for our Alex Stamos. Any more ideas you have how we might find somebody like that and avoid the stigma of the "Bank CISO" job would be much appreciated.
>at the expense customer experience and true security
I always call this "lazy security"[1] and it's what you get when you hire some security professionals to "make it secure". It's a mistake to separate security from product design, the two should inform each other to come up with a compelling product that remains secure. Separating them misaligns interests, the security team will push for a change that improves security irrespective of any impact it may have on user experience.
I think Touch ID is a great example of how a novel solution can improve both security and usability.
At Mondo we are committed to investing time and energy into finding these solutions, security at the expense of user experience is a last resort.
[1]https://medium.com/@danielchatfield/lazy-security-32acc31fbd...
You can, however, identify the user with something like biometrics, and afterwards request an authorization of the transaction with something else (possession of key (good), +pin (better), or easiest a simple 'yes'(less than good)).
I've actually been disappointed to see the opposite (companies moving away from providing hardware 2FA) as other options are perceived as cheaper, despite potential weaknesses in the security model.
What Mondo is (from my reading) trying to do is very cool but quite ambitious. A new bank in 2016 will be a serious target for quite sophisticated attackers so they're going to have to do app/inf/ops security very well do avoid damage.
On the flip-side they have the once in a lifetime golden opportunity of a green-field deployment to actually get security baked into their systems before they're live without a load of legacy cruft holding them back.
They talk about the card revocation/freeze in the app in the talk posted earlier, which is a really nice idea (next to the metadata collection). The reason most 'normal' banks have limitations on their apps is that either they will not (or can not) guarantee the safety of their apps or want to place the responsibility at the users end. This means the limits in place (usually ~750/1000 euros max per day/week on mobile platforms) are there to make sure they won't loose too much money if people start saying "I didn't make that transfer". Banks pay out anyway (at least here in the Netherlands) because the customer dissatisfaction is of greater importance than actual tracing the problem of either a hack, an abusive spouse or simply mistyping the IBAN number. Since they collect a huge amount of metadata, this problem gets easier but won't be eliminated and can be managed by good app security and user informing the user. This limitation is the same for card revocation (not freezing, that has other issues; namely concurrency).
I do hope they get a group of 'non HN people' to test it out, as they are more likely to get into the 'I didn't make that transfer' problem.
The problem with freezing cards is that transfers are not direct: freezing the card on the banks end might work, but some ATMs or other systems might have a sufficient delay to allow (some) abuse while the card was 'frozen' by the user. The question will be who will pay for the delay.
I definitely will support these ideas as they stir up a broken market, but please make sure you have you proof-of-possession and concurrency issues well sorted out.
Where I was thinking that a lot of their security challenges will lie is things like internal money processing systems. An attacker with access to a bank's internal systems could make a right mess of things...
This is part of why their cards are online-only, every* transaction has to be verified with them before it can complete at the reader - so transactions are slower, but there is no grace period after the freeze.
* as I understand it, certain merchants are white-listed on-card for offline transactions - namely TfL.