[raesene4]

FWIW, I saw that ad. Looks very interesting, but I think you may have a challenge getting someone who is a Vuln researcher/pen tester type (who most commonly have CVEs, PoCs to their name) who also has a decent knowledge of banking security, policies etc and also is looking to graduate out of technical work into team management...

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_...

[jhuckestein]

Thanks a lot for the link :)

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.

[consp]

[rant mode] From personal experience I can say that true crypto knowledge is not needed as a Bank CISO. Just keep repeating 'hardware token only, hardware token only' and everyone will trust you opinion at the expense customer experience and true security. The reason that most banks use the identifier+card method is because they don't want to change. (or don't see the benefit of an improved customer journey without actual loss of security and improved/lowered cost) [/rant mode]

[abritishguy]

[I work at Mondo]

>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...

[consp]

I have to comment on touch ID: Biometrics are in no way an authoritative option for the simple fact that they cannot be replaced. You can identify the user with it, sure. But you should never use them to authorize anything because if stolen or compromised, the user cannot change it. While you might say the scanner + data storage is secure, this is just temporal and can change over time. As revocation of the biometrics is identical to revoking the user, this is to be avoided for authorizing transactions.

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)).

[raesene4]

well whilst hardware tokens are not always the right answer, there are good reasons to resist their replacement with things like "SMS 2FA" which isn't really 2FA at all ,as you have no control over the receiving device, leading to it becoming 1+1FA in a lot of circumstances (e.g. apple continuity, skype account etc)

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.