Burton Group Identity Blog

Chasing the magical GRC animal

2008-07-22T20:43:25-07:00

Blogger: Ian Glazer

I'm sure you've been following the Terry Childs case. Mr. Childs was a sysadmin in San Francisco who decided to change a few passwords and thus locked the city out of their new wide area network. Though it is still not clear why Mr. Childs did this, he had been recently written up for poor job performance.

Among others, Matt Pollicove wrote about this and the need for trust. Matt asserts that trust is a must and I completely agree. That being said, the last two points in his post are mistaken.

First he says:
"This means, making sure there's no orphan or rogue accounts in the systems."

While this is a generally accepted good practice, it would not have necessarily helped San Francisco keep from losing their network. Privileged account management would have been far more useful. Discipline and control around how sysadmins gain access to and use root-like accounts, the bread and butter of privileged account management, would have helped avert some of San Francisco's problems.

Second Matt says:
"GRC tools will be a must in this verification."

This first thing that springs to my mind is a question: what aspect of governance, risk management, and compliance would have helped the city of San Francisco in this case? A good governance and risk identification and management process would have helped a great deal. But we have to keep in mind there is no such thing as a GRC tool; there is no such animal. In fact, GRC is starting to sound like the wonderful magical bacon animal that Homer Simpson dreams of. If pork chops, ham and bacon all come from the magical animal in the Simpsons, then privileged account management, orphan account management and provisioning all come from the magical GRC animal. Where does it end? The reality is that the industry has confused the benefits of good governance processes and risk management capabilities with automation tools that aid, but never replaces, those processes and capabilities.

Privileged account management is not and should not be considered part of the marketing fog of GRC. Does the controlled management of root-like accounts constitute good operating procedure and help reduce risk? Absolutely. But that doesn't make privileged account management a GRC technology. Is orphan account removal a critical process from a security and risk mitigation perspective? Of course. However, that doesn't mean the technologies to do that are GRC technologies.

Specificity of language is crucial. Telling the city of San Francisco that the solution to their problems lay within "GRC" would have done little except lengthen the time to finding what their real problems were. Our industry cannot take the easy route and lump every possible technology and procedure under the sun onto the GRC heap or else we'll find ourselves chasing Homer's magical bacon animal.

Physician, heal thyself…

2008-07-07T13:07:23-07:00

Blogger: Kevin Kampman

In my blog entry about Google and Microsoft’s plans to publish the personal medical records of US citizens on the Internet, I questioned these firms ability to properly protect the privacy of these records. It was only a matter of time before the inadequacies of data protection came to light; it recently happened that Google fell prey to the exposure of employee records (by one of its subcontractors). While no customer information was exposed, this does underscore the need to institute due care for all sensitive identity information. Individuals, legislators, and the medical community should ask very serious questions about the efficacy of these programs before a more damaging breach involving a huge segment of the population comes to pass.

The Elephant Parade: Relationships, Role Management, Provisioning, and Identity Services

2008-07-01T13:52:00-07:00

Blogger: Kevin Kampman

Catalyst 2008 went by so quickly, but that’s always the case when you are having a good time. It started off well, particularly when Bob Blakley couldn’t tell me (Kevin Kampman) apart from Mark Diodati on stage during the Market Overview. It helped that we had “Anonymizer 2008” bags over our heads, but Bob’s confusion is a good sign that lifestyle changes are at hand.

Conference attendees indicated their appreciation for the new presentation format; however, the changes are more than cosmetic. Several perspectives were presented that offer the potential to change the identity industry for the better. In particular, Bob introduced “relationships” as an overarching theme for the establishment and continuity of interactions.

Tim Weil, Vice Chair of the INCITS CS 1.1 Role-Based Access Control (RBAC) Working Group discussed their effort. His group is developing a standard for the implementation and interoperability of RBAC components described in INCITS 359-2004. Widespread adoption of the standard has been impeded by a lack of practical guidance; this effort is an attempt to resolve these issues. A military perspective was provided by Russell Reopell of MITRE, who discussed ABAC, or Attribute-Based Access Control. This approach requires qualitative attributes, such as roles and other characteristics, that can be evaluated singly or in combination by policies to make access decisions in real-time. It is particularly relevant in situations where pre-registration of users is not possible.

A practical need for role interoperability has been expressed by Darran Rolls of Sailpoint, who recently established the Open Role Exchange Forum. This forum was discussed during the Role Management and Provisioning vendor panel (including Rolls, Aveksa’s Jim Ducharme, Sun’s Nick Crowne, Oracle’s Jeff Shukis, and Eurekify’s Ron Rymon). The exchange represents an opportunity for more seamless enterprise role implementations by addressing how to normalize role definitions across multiple platforms. The panel concluded that role management and provisioning represent parallel complementary initiatives that will benefit both the business and administrative communities, respectively.

Ken Anderson, of Burton Group’s Executive Advisory Program, helped me to address a topic of significant interest to the business community: representing the value of role management. In a role play that featured Riley the Cat (a loose metaphor about conversations with executives), Ken and Kevin moved from a technical discussion of administrative trivia to a strategic overview of Return on Organization. The bottom line is that role management is a discipline, one that provides a relationship-driven perspective about the social dynamics of organizations. The point of the role play was how to speak to executives about business transparency and effectiveness, rather than administrative efficiency and compliance. The former is beneficial to the business, the latter to administration.

From a customer-centric perspective, it was standing room only for the Friday presentation and customer panel on identity services. The panel included Gavin Illingworth from Bank of Montreal, Susan Staples-Holt, MassMutual, Chris Harvison, ScotiaBank and Andrew Cameron, representing General Motors. Burton Group facilitated this year’s effort to establish the rationale and requirements for interoperable identity services. The multinational membership has grown to include contributors from financial services, manufacturing, telecommunications, and government agencies; additional interest has also been expressed by health services, pharmaceutical and educational institutions.

The current vendor efforts towards identity services are more project- than community-driven. Customers are challenged to deal with the development and integration of identity services, particularly for cross-platform and legacy purposes. While there is a general perspective about what the services should accomplish, there is no agreement on their demarcation or specifications for how they should do this. In order to develop this guidance, and to prioritize development activities, the participants have agreed to invite vendors and standards community representatives to contribute to the effort.

The area where there has been significant traction has been federation, but it has been challenged by supporting capabilities and agreement on information at the endpoints. Given the breadth of opportunities, one area for investigation includes authentication, authorization, and attribute services. Another is session and context management. Each of these represents an elephant-sized task; by working together we hope to line them up trunk to tail in short order.

Interested parties should contact me at kkampman@burtongroup.com for information on how to become involved. Our goal will be to develop shared requirements, a development plan, and an interoperability schedule to present during a joint customer-vendor panel at Catalyst 2008 in Prague.

Identity Management in Retrograde Motion: Thoughts from Burton Group Catalyst North America 2008

2008-06-30T22:26:12-07:00

Blogger: Ian Glazer

I’ve been to many Catalysts but this was my first as a Burton Group analyst. Besides seeing how the sausage gets made, so to speak, this Catalyst was different in that I got to speak to a lot of enterprises on their struggles and successes with identity management. It was in these conversations that I heard a disturbing theme: "I’m not ready to do roles, so I won’t attempt user provisioning." This is truly a disturbing theme for both enterprises and vendors alike.

Before delving into why this theme scares me, let’s look back at the history of the market. Role management products got their start five plus years ago. At that time, user-provisioning tools had poor permission policy (entitlement) management capabilities. Although user provisioning tools did provide some means to aggregating account permissions for given systems and a semi-automated way to dole those groups of permissions out, they were a bit cumbersome and difficult to report on. Because these permission policies were difficult to deal with early adopters struggled getting automated provisioning projects off the ground. Role management (and here I am speaking of IT or technical roles) tools filled a vital gap allowing enterprises to speed up their user provisioning deployments by accelerating and strengthening the entitlement management process. At that time in history, there was something to the argument that role management tools were needed to deploy user provisioning. That argument is no longer valid. User provisioning tools have greatly improved their permission policy management capabilities and provide the enterprise adequate tooling.

Implicit in the idea that an enterprise cannot attempt user-provisioning because it is not ready for role management is the notion that user provisioning has no value to the enterprise without role management. This is an outdated argument that is simply not true. By delaying a user-provisioning program (and I say program here and not project), the enterprise cannot reap the benefits of more automated deprovisioning, password management, self-service account requests, and basic user provisioning itself. Most importantly, by putting off user provisioning and waiting for role maturity to spontaneous happen, the enterprise risks putting off the most important part of any identity management program (role management or user provisioning alike) and that is establishment of governance. Establishment of governance is the most critical success factor to identity management programs and if it is not established up front, future programs and projects have a nearly 100% chance of failure.

As I said earlier, the wrongheaded notion that user provisioning requires mature roles contains danger for vendors as well. Vendors who have role management tools will find their bigger deals delayed as the enterprise waits for a sign that they are mature enough to begin their user-provisioning program. Further, vendors will end up with more shelfware deals as there are significantly more implementation teams familiar with user provisioning tools than they are with role management tools. Lastly, this disturbing theme constrains identity management to being viewed as a series of projects and not holistic programs and thus a lack of governance.

I have hopes that this theme is, in fact, observed retrograde motion of identity management. I hope that the market and its thinking is not reversing gains, but instead exhibiting a transformative behavior that we have yet to see. To close, keep in mind that both role management and user-provisioning efforts can be done in parallel and each will find benefit in the other as they mature. Provisioning requires an understanding of process and procedure, role management an understanding of relationships and responsibilities. To be successful with either, clear scoping and small iterative projects as part of an overall well governed program are advised to ensure current success and future growth.

Entitlement management and Concordia

2008-06-10T12:26:26-07:00

Blogger: Gerry Gebel

Project Concordia is pitching in again at Catalyst this year to host a session on entitlement and policy management. It promises to be a very informative and constructive event as representatives of Boeing, Cisco, Micron, and The US Army share their insights, experiences, and requirements for standards based policy and entitlement management. Within the audience will be a panel of experts representing standards committees and product purveyors listening intently to the enterprise presentations. Imagine that, vendors and standards developers hearing real world usage scenarios – what a concept!

Of course the rest of us in the audience will learn from entitlement management aficionados talk about standards issues, challenges with performance, application integration efforts, commercial application support and the like. We’ll also get a standards update on the state of Extensible Access Control Markup Language (XACML), as noted in the agenda.

Concordia serves a vital purpose to the industry in providing a forum for customers, vendors, and standards developers to gather and share information that can inject a heavy dose of reality based requirements into the software production process. Please join us, entry is free and you only need register at this link. Hopefully you’ll stay for the whole Catalyst conference!

The Push and Pull of Consumer Authentication

2008-05-12T10:08:03-07:00

Blogger: Mark Diodati

I was speaking with a colleague at a large financial institution. The topic: can organizations “push” information (e.g., bank statements) to consumers via email and still be compliant with the FFIEC guidelines (on the insufficiency of single factor authentication)? After thinking about it, I believe the question is broader: Is security adequate when pushing sensitive information via email?

Some financial institutions email their customers to let them know that their statement is available online. Is this a “push” or a “pull” authentication? I believe it is a pull authentication, because the user must authenticate to the financial institution’s website to retrieve the information. Some financial institutions place a URL link in the email body. It’s better from an anti-phishing perspective to have the user type in the URL into the browser.

Ignoring the security question, there are many convenience benefits associated with sending statements via email. Many customers don’t want paper statements. Some customers use financial management software like Quicken or Money, and <ALT-TAB> between the software and the bank statement to reconcile.

When thinking about use cases and potential fraud, I believe that pushing statements via email is not secure enough. Some concerns:

Most people store their passwords in their email program (for example, Outlook Express). Anyone can walk up to the computer, click on the e-mail desktop icon, and get access to the consumer’s bank statements.

Most users access their email via POP3. POP3 passes user credentials in cleartext. Anyone with a network sniffer along the path can grab the consumer’s credentials and re-use them to access the consumer’s emails.

Man-in-the-browser attacks are becoming more prevalent. These attacks utilize workstation malware to capture user credentials. If a consumer checked their email from a web browser at an infected kiosk, the email credentials could be captured for later use. Maybe consumers shouldn’t use a kiosk machine to access their bank accounts, regardless of whether a statement is delivered via email. Also, there is a risk that the consumer’s bank statement could be recovered on the kiosk machine.

Some might argue that similar risks exist with paper statement delivery. The differentiator is that the fraudster must have physical access to the consumer’s mailbox, which raises the attack bar.

What damage can be done once the fraudster gets the statement? The bank statement has the consumer’s account number, postal address, and a list of transactions (including payee information). This information is a treasure trove for initiating an identity theft attack.

I have other residual concerns about emailing bank statements. How is the integrity of the bank statement maintained through electronic delivery? How would the consumer know if the bank statement has changed? I can envision a scenario where a fraudster takes money out of the consumer’s bank account, and modifies the bank statement to hide it. I suppose this could be fixed with a customer support call if it is detected.

I am aware of another large financial institution which is evaluating plans to implement a push mechanism to distribute bank statements. They’re considering using a consumer authentication-style PKI product, which would provide both the necessary authentication and message integrity to make the process relatively secure. Also, Adobe Acrobat documents can be password-protected, which can mitigate some of the risks associated with pushing bank statements via email.

What are your thoughts?

Swiss Army Knife – The Personal Portable Security Device

2008-05-02T16:27:01-07:00

Blogger: Mark Diodati

I’ve been working with smart cards for a most of a decade, and there is a relatively new spin on the technology that merits discussion – the personal portable security device (PPSD). It combines the USB smart card form factor and USB flash memory on a single platform. Unlike older USB devices that had both components but functioned in a standalone manner, the smart card controls access to the flash memory. The combination is of interest to enterprises, and the payment and mobile communication industries. Vendors that offer PPSDs include Gemalto (Secure Enterprise Guardian) and MXI Security (Stealth MXP). I tested Gemalto’s Secure Enterprise Guardian product.

The combination overcomes the major problems of each technology. For smart cards, it’s limited storage. Smart cards on their own can store a maximum of 256kb of data. USB flash drives can hold up to 8 GB (though the Secure Enterprise Guardian’s current storage capability is considerably smaller at 2GB). The issue with flash memory is security, which is lacking relative to the smart card. The smart card will lock itself after a specific number of invalid PIN attempts. No diagnostic utility can bypass the PIN mechanism, and the smart card chip is physically tamper-resistant, more so than any other authenticator. It’s a great way to provide device-level file encryption, because card component generates and stores the symmetric encryption key. The encryption key never leaves the device. No PIN, no symmetric key, no access to the encrypted files. The PPSD typically has a public area which functions like a traditional USB drive, so you can share files with other people without authenticating.

The PPSD also supports traditional smart card/certificate functionality, so it supports Windows workstation logon, WiFi authentication, mutually authenticated SSL, S/MIME, and digital signatures. The Gemalto PPSD also has a PKCS #11 interface that provides certificate functions for non-Microsoft applications (Firefox and some VPNs), as well as other operating systems (Linux and Mac OS). Both the Gemalto and MXI Security PPSDs work with USB port control products, like Lumension’s Sanctuary Device Control. One inherent limitation exists with PPSDs. They don’t support physical-logical convergence initiatives, which almost always require the ISO 7816 (credit card sized) form factor.

The Gemalto and MXI Security PPSDs also support one-time password (OTP) generation (the PPSD does not have a LCD, so the workstation is required to view the OTP). Gemalto’s OTP generation is OATH-based and the MXI Security's OTP generation is RSA SecurID compatible (which provides broader platform support). The combination of OTP and certificate capability provides the broadest application support for a stronger authenticator. The MXP Stealth product also provides biometric authentication.

The Secure Enterprise Guardian was immediately recognized by my Windows XP machine. The device supports the CCID USB smart card specification, so the installation of the CCID driver was automatic via Windows Update. Gemalto has worked with Microsoft since the release of Windows 2000 to embed its Cryptographic Service Providers (CSP), so they are present in the operating system. A couple of mouse clicks and I was up and running. Net result: this is the closest to a zero software deployment model for smart cards I’ve experienced. When installing the Secure Enterprise Guardian, I was running with administrative privilege when doing the installation, and installation results on a typical enterprise workstation may vary. Windows Vista deployments are simpler as the CCID driver is already present.

The device becomes a mobile, secure storage container for both applications and sensitive data. There’s some intriguing functionality that I have not tested yet. I’m interested to see how PPSDs work with workstation virtualization products (e.g., VMWare ACE or MojoPac).
Some use cases include:

“Secure” browser (e.g., limited functionality and trusted root list) with mutually authenticated SSL. This combination is already productized by MXI for consumer authentication usage. It should be noted that hardware-based authentication is not currently acceptable to U.S. financial institutions and their retail banking consumers.

Storage of confidential data, along with the application necessary to access it.

Microsoft PowerPoint presentations, along with the PowerPoint software.

S/MIME with Outlook Express or Mozilla Thunderbird and the certificates stored on the smart card.

Enterprise SSO application and associated SSO credentials

I’m not glossing over the complexity of smart card and file encryption across the enterprise. The authenticator is part of a larger orchestration of smart card management systems, PKI, and key management. Additionally, organizations should consider USB data port security white lists to limit the devices that can be installed on workstations. But so much of stronger authentication is about user acceptance. The PPSD provides the USB mobile storage form factor that users need, so its authentication and data protection capabilities make it a useful Swiss Army Knife.

Third time a charm, revisited

2008-04-21T16:14:08-07:00

Blogger: Kevin Kampman

In my March 10, 2008 blog entry “Short and to the point, if not so sweet” regarding the electronic capture and publication of medical records, I discussed how we frequently mask or defer basic issues by focusing our attention on something else. As Dr. Molly Coye stated in USA Today regarding the potential misuse of medical records: “But those are human actions. They have nothing to do with the technology.” This perspective underscores our fundamental tendency to gloss over technological issues by blaming mistakes on the people using the technology. I believe it is important to recognize this and to address the basic issues.

Sometimes we need to get some distance from an issue in order to see it clearly. Last week I attended a motivational seminar given by Curtis Zimmerman. Mr. Zimmerman is a talented speaker with a compelling message about overcoming adversity and changing the direction of one’s life, individually and as a leader. He teaches juggling as a way to force the audience to drop its barriers to listening and learning. The key takeaways from his presentation are that we need to change our perspectives to recognize and reward failures, not to hide them. He also identifies that we are living a script, someone else’s or our own, and that we need to rewrite the script in order to “live the dream” in our own lives.

Earlier in April, we heard about a US Airways pilot discharging his gun in the cockpit while stowing it for landing. This was an unfortunate incident, but one to learn from. In a conversation with another (off-duty) pilot on a flight to North Carolina, we determined that this situation demonstrates that current on-aircraft gun handling policies and weapon configurations are accidents waiting to happen.

The guns carried by pilots are the same as those used by law enforcement. The guns have no positive locking safety switch, a round is chambered (by policy), and the gun is out and ready to use while the craft is in the air. Given the backup and failsafe environment that a cockpit represents, it is amazing that a device configured in this manner has been introduced without appropriate, common-sense precautions. This is one reason we often read about law enforcement officers having self-inflicted accidents. Fortunately, in this case no one was injured, but the pilot did lose his job.

The bottom line here is that US Airways did not reward him for demonstrating a failure in the system and take appropriate actions to prevent similar failures in the future. The result is that we will continue playing out this flawed script. Next time, someone may get hurt.

A notorious, identity-related failure has to do with the performer and musician Britney Spears. While undergoing medical treatment, her medical records were voluntarily accessed by professional and medical staff having no reasonable association with her care. This demonstrates that the medical records system in use by her provider has inadequate controls. The resolution to this situation is that a number of non-physicians were fired, while the physicians were only “disciplined”.

The bottom line here is that we have different scripts for different people. In a medical community, the physicians are in control, and are in a position to continue to violate patient privacy at will, until fundamental changes are introduced into the records systems.

And late last week, we heard of yet another records disclosure failure. WellPoint, a health care benefits firm, exposed nearly 130,000 personal medical records (records, mind you, not attributes like social security numbers) by using a third-party’s improperly secured web servers. This is the first occurrence of a records disclosure of this magnitude, and is the harbinger of what is likely to come.

The risk of disclosure, misappropriation and misuse of our medical records is higher today than ever, and the burden of dealing with the situation is being pushed off to us. The risk of aggregation aggravates the problem even more, since companies who want to collect this information, like Microsoft and Google, will become targets of compromise. Whatever mechanisms they employ to protect this information must be professionally vetted by independent experts prior to any public deployments. Since there is no medical equivalent in this country to the credit reporting bureaus, we have even fewer means to protect ourselves than we do in the case of financial compromises. This being the case, we can’t afford to make mistakes.

The final “bottom line” is that anyone dealing with private information needs to recognize that it can cause irreparable harm if it is not handled in an appropriate manner. We have already heard of situations where a person’s medical identity has been hijacked to obtain services for someone else, and run up payments to the benefits limit. Medical conditions could also be used as a gating factor for denial of employment. My family learned of my father’s impending demise due to the disclosure of diagnostic information by an indiscreet radiology technician.

We can’t continue with the same old same old; it’s clearly inadequate, as are regulations regarding disclosure of compromises (such as California’s SB 1386). We need to examine, reward and learn from these organizational and systemic failures, or else the script of records disclosures, potentially on the order of millions of records, will continue.

Hitachi! Who knew?

2008-04-09T17:23:05-07:00

Blogger: Lori Rowland

Using the 2008 RSA conference as its platform, Hitachi announced the acquisition of majority shares in M-Tech. The new formed company will operate under the name Hitachi ID Systems and be rolled into Hitachi’s information security portfolio. Hitachi ID Systems will operate as a subsidiary of the Hitachi parent company.

M-Tech, headquarter in Calgary, Alberta Canada has been a long standing vendor in the IdM market. The company’s product profile includes provisioning, password management, privileged account user, AD group management, and various other IdM technologies. M-Tech is best known for P-Synch, its password management offering, but has also faired well in the provisioning market.

While Hitachi is well known in North America, it is a powerhouse in Asian markets. Hitachi sells various consumer products (e.g. electronics and power tools), but also offers hardware and software components for enterprise organizations. Hitachi has a heavy presence within Asian enterprise organizations. The Asian market has been slower to adopt IdM technologies, however it is gaining traction primarily because of the enactment of laws and regulations, such as Japan’s Financial Instruments and Exchange Law (J-SOX). Hitachi ID Systems may have “a foot in the door” with Hitachi’s existing customer base.

Another interesting characteristic of the acquisition is that Hitachi ID Systems will operate as a subsidiary. According to M-Tech founders Gideon Shoham, CEO and Idan Shoham, CTO, M-Tech had been approached by other vendors in the market and had turned down acquisition offers. What made the Hitachi offer stand out? As a subsidiary, M-Tech founders will maintain control over technology direction and day-to-day operations, the M-Tech employee base will remain intact, and the impact on M-Tech’s existing customers will be minimal.

M-Tech realized several other benefits to the acquisition. As the IdM market has become increasingly competitive it was difficult for M-Tech to compete against large, major brand vendors. The acquisition gives M-Tech (now Hitachi ID Systems) access to a global sales team and a large information security consulting team which will be trained on the Hitachi ID Systems product family. Most importantly it gives M-Tech global name recognition.

The attitude of this acquisition seems somewhat different than acquisitions we have seen in the past. While the benefits of the acquisition to M-Tech are obvious, Hitachi’s (the parent company) overall vision for the IdM it is not yet clear. The company does offer various security technologies such as RFID and vein pattern recognition biometrics. However, how and if these technologies will be integrated with M-Tech’s product family has not yet been defined.

Hitachi’s acquisition of M-Tech will no doubt leave some in the market scratching their heads in wonderment. It is too early to tell the full impact of the acquisition. However, one thing is clear, M-Tech needed the backing and sales channel of a larger vendor to progress in the market. However the battle is yet to be won. This is an unpredictable market; customers are concerned with vendor viability and longevity. The long-term relationship between vendor and customer has become a differentiating factor for many IdM purchases. To be successful, Hitachi ID Systems must quickly communicate a clear vision and an aggressive strategy. Although Hitachi is a recognized name – they are competing with large vendors such as IBM, Oracle, and Microsoft all of whom have already established themselves as powerhouses in the IdM market.

This acquisition proves that the IdM market is full of surprises – never a dull moment. There is still ample opportunity for acquisitions. Acquisition activity will likely continue in the role management, entitlement management, and authorization spaces. However, even the more mature markets like the provisioning market may see continued activity – as evident by the M-Tech acquisition.

The MIFARE Classic Card is Hacked

2008-03-19T11:45:06-07:00

Blogger: Mark Diodati

Some of you may have read that the proprietary symmetric key cryptographic algorithm of the MIFARE Classic card has been broken. The MIFARE Classic card is used in physical access control systems (PACS) and contactless payment systems (including tollway and public transportation systems). By some estimates, there are 500 million MIFARE cards deployed worldwide, and the majority of them are MIFARE Classic cards. Karsten Nohl and his team completed the hack, and the team was able to clone a MIFARE Classic card in less than two minutes (the “skimming” or reading of the card takes less than a few seconds). Perhaps not co-incidentally, NXP (the owners of the MIFARE intellectual property) announced on March 10 that they have a new-and-improved MIFARE card that leverages AES 128-bit encryption. The first samples will be available in Q4 of 2008. The refreshment of hundreds of millions of cards will be completed at a much later date.

You may be aware of the MIFARE vs. HID Prox card religious war in the PACS space. From my experience talking with customers, there are more HID Prox cards used in PACS in the United States as compared to the MIFARE card. The MIFARE proponents consistently tout the security value of MIFARE technology over HID Prox technology, and have pointed to the fact that HID Prox cards could be readily cloned. You can see a video of the HID Prox card clone, from the 2007 RSA Conference here. The conventional wisdom was that the MIFARE card was unclonable. The conventional wisdom was wrong.

The impact of the MIFARE hack for those reliant payment systems (and its consumers) is increased fraud. The cloning of the card does not require possession, only proximity. I am unaware of any preventative measures that would preclude a fraudster from walking around a parking garage and cloning those tollway cards that are mounted in everyone’s windshield. Some people might consider this an act of civil disobedience, particularly if they drive on the Illinois Tollway with any frequency (as Triumph the Insult Comic Dog would say “I keed!”). Also, skimming and cloning the user’s public transportation card while they ride the train is a likely outcome. If you are aware of any preventative measures, please let me know.

What is the impact to PACS security? The reality is that many PACS deployments did not leverage the MIFARE encryption features. The management of symmetric keys across the relatively complex PACS environment (specifically, cards, readers, controllers, and hosts) remains a daunting process. For these deployments without encryption, it’s business as usual. Those organizations that deployed the MIFARE technology with encryption should realize that they are not as secure as they thought. Either way, as we have said before, no authentication method is bulletproof. Organizations should be using other controls – like auditing and security event correlation – to enhance the security of their PACS.

Finally, when will people learn their lesson? Cryptographic algorithms should be public so that they can be scrutinized and tested. Secret algorithms aren’t more valuable because they are secret. Bruce Schneier has been saying this for years.

If you are interested more details on PACS architecture and components, I recommend my recent Burton Group research document “Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems” (subscription required).