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.

NAC stands for what? Part 2

Before the 4h, I posted on the access control-side of NAC. I compared it with web access control and examined some similarities. This week, I want to look at the other side of NAC: admission control.

NAC as Network Admission Control
Treating NAC as admission control is more of a network/threat-centric approach. There are some basic characteristics of NAC as admissions control:

• Health and configuration validation and remediation
• Machine authentication to the network infrastructure
• Assignment of IP address

Health checking is a common NAC function. This is just good house keeping and it is something that every organization, big or small, needs to do. There are a variety of ways to check the health state of a connecting end-point and most are fairly simple to do. The challenge is managing the remediation of a sick end-point. This is where the real skill of NAC vendors (and a lot of time – their partners) comes into play. How do you quarantine? What configuration management and software distribution tools are used to remediate the problems? How do you orchestrate all of these pieces working together? This is non-trivial work and there are a lot of vendors out there doing really great stuff.

The next two items are not truly mandatory functions for admission control, but they are important nonetheless. Some form of machine authentication is lumped in here: RADIUS, 802.1x, EAP. This is one approach to ensure that only organization-owned laptops are on the network. What concerns me is the conflation of me for my laptop. In order to truly understand what is going on inside the network, user and machine identity have to be treated separately. I am not my laptop and my laptop is not I.

Last, getting an IP address is the last aspect of admission. Some NAC vendors integrate with DHCP services to orchestrate all the necessary steps for admission including address assignment. I’m not saying that DHCP services need to be embedded into the same product that does health analysis, but it is the last step to network admission and should be treated with importance.

Will the real NAC please stand up?
In conversations, blog entries, analyst papers, which NAC is being discussed? I feel that both are necessary to have a complete story, but each side has a different heritage and mindset. Using NAC as an abbreviation blurs the distinction between what is required for admission versus access control. We can do better. Anyone up for renaming this market Network Admission and Access Control – NAAC?