Banks: Data breaches, info security, and risk – oh my!

Our marketing team recently completed a survey of IT types at banks and credit unions, asking about data breaches, identity theft, information security costs and risks. The survey uncovered some interesting results, especially regarding how they regard insider threats (very seriously) and the estimated organizational costs of a major data breach (more than you’d think).

With most of the security discussion focused on consumer banking (phishing, stronger auth of retail online banking), we were also intrigued by feedback about business banking customers. The majority of respondents agree that business customers demand greater security for Web and electronic banking services. They also agreed that business customers would be willing to limit access to certain services for specific users connecting from specific computers.

This is a departure from thinking on the consumer side — banks just can’t force individual users to log in from only one machine. (Even if logging in from another machine requires you to take and extra step, like answering a secret question.) Getting consumers to work with anything other than username and password is going to be challenging; this is one reason why I have so much hope for CardSpace. (I am tempted to refer to consumers as lazy but a) that’s not really accurate and b) they have been trained into their malaise.)

It may not fit for consumers, computer-based access control makes perfect sense for a lot of business banking services. As a business owner, I would probably only want authorized users from my accounting team to have access to payroll or wire transfer services, and only from known computers in the office. Or I would only want known POS systems connecting with my bank’s remote deposit capture servers.

We will be sharing the complete results of the survey on a Webcast October 10 and 1 p.m. EST, sharing the virtual dais with Tripp Johnson of Cornerstone Advisors (the guys behind the very amusing More details and registration information here:

Out: NAC, In: N-IdM?

In prepping for the panel he is leading (and I am speaking on), Eric Norlin has been reading through the mire that is NAC literature. I’ve talked about how Network Access Control (NAC) is a thorny term that is misunderstood, misused, and a bit misleading: here and here. Eric recently called for TNT, among others, to rebrand/rename the entire market space to something more clear than NAC. He suggested Network Identity Management or N-IdM. He suggested that N-IdM would be distinguished from Application Identity Management (A-IdM) – what we think of as traditional identity management. Let’s look at the typical services that A-IdM and N-IdM offer. Under the A-IdM umbrella:

  • Directory Services (including meta and virtual)
  • User Provisioning
  • Web Access Control
  • Federated Identity Management (really Federated Access Control and someday, maybe, Federated User Provisioning)
  • Centralized and Stronger Authentication
  • Role Management (both top-down and bottom-up)
  • Reduced / Single Sign-on
  • Compliance analysis and attestation
  • Report and alerting

In the N-IdM bag of tricks we have:

  • End-point services (Identification, Authentication, and Health)
  • Network admission control (Are you allowed on the network?)
  • Network access control (Where are you allowed to go and what can you see?)
  • Policy-driven Connectivity
  • Connection protection (Tunneling and encryption)
  • Identity-centric activity analysis, reporting, auditing, and alerting

I’m sure I’ve missed some services in both camps, but those lists are a decent start. To be meaningful to the business, these services must help describe the interaction between people and business goals and needs. Consider Bill. Bill is a traveling sales rep. He needs constant, secure access back to the order entry system, email, and the sales portal. He should only have the appropriate permissions in those systems based on who he is and what he does. The business needs to be able to report on Bill activities in those systems as well as on the corporate network in general. The business needs to protect itself from viruses and malware which Bill, inadvertently, has on his computer. Twice a year Bill needs to verify that he is using all of his accounts and the business needs to verify that Bill is in the appropriate roles with the appropriate permissions. I don’t think Bill’s case is too far fetched. But tell me, where in that example does network-provided identity services stop and application-provided identity services begin? Sure connectivity is a network service, but the policy that governs it is related to roles and user provisioning. Auditing and attesting to activity is not exclusively an application-level affair. So, is there really a clear demarcation between network and application identity management from a business perspective? The title of our panel at Digital ID world is: How Network Access Control is Integrating with Identity Management. Come by next Wednesday and bring your questions. Its going to take all kinds of stakeholders in this industry (vendors, customers, pundits, analysts) to get us from NAC to N-IdM and from there to truly unified identity management.