[chc]

I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.

[tptacek]

The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build badly. Can you guess how much it costs to revise password storage and UX for tens or hundreds of applications?

[cosgroveb]

Anecdote in support of your point: I was a developer who sinned in the creation of a terrible password storage system on an internal web-app that had about 50 users (why didn't I just use LDAP???). It was at a Fortune 500 financial. I was fresh out of college. The company had a large security organization in-house and very clearly documented software best-practices but I was cowboy coding on an Infrastructure team. I was the stereotypically bad programmer at a large company who makes grievous security errors. I'm not even very comfortable making this confession but I believe I've learned a lot since then.

[khafra]

Interesting. If financial institutions routinely succeed at operational security but catastrophically fail at having a secure development life-cycle, is that a startup opportunity?

[m0nastic]

I don't know about "startup opportunity" specifically, but it's pretty much the raison d'être for most application security consultancies.

Usually when first engaged, you deal with operational issues (making sure all the applications they know about are assessed), but as you build on that, you try and instill secure development practices (so that every new application they build doesn't have the same issues as the ones you've just spent months uncovering).

The number of large clients I work with who don't have any SDLC process is staggering (I'd say it's the overwhelming majority of them). For the most part, the small group of security people are tasked with trying to secure the multitudes of applications which in many cases are 20-30 year old codebases. Their developer groups may be completely separate (usually from the result of all the mergers of financial institutions) and it's basically all fiefdoms.

As you start to work up the pyramid of enterprise security "hierarcy of needs" you get to things like a secure development life-cycle, but not all organizations are "ready" yet for that type of work. Some are just trying to figuratively stop the percieved bleeding.

[bhousel]

The teams (or more likely outside vendors) that set up the bank's external-facing servers and load balancers are not going to poke around the application code.

A bank will have architecture and security teams that evaluate the applications, but their main job is to run each application through a "best practices" checklist or audit to identify potential trouble spots. An application will need to meet some kind of sane minimum requirement for password security, but many of these apps are legacy or mainframe, and not easy to change. Big banks move very slowly.