Moved

Just a quick note to anyone who gets to my old blog address at https://eternaloptimist.wordpress.com: I’ve moved, you can find me now at http://eternallyoptimistic.com.

Thanks,

Pamela

Analogous?

For whatever reason, I’ve been pondering similarities and differences between financial and IT risk lately, and one big difference seems to be around reputation in these two areas.  The financial world painstakingly maintains institutionalized memory of credit issues through standardized credit ratings.  Companies, cities, and even countries are rated based on current and past performance, and a ratings downgrade is a BIG deal.

Why isn’t there an analogous service for systems security risk?  For example,  Mike Ramirez just pointed out a data breach at Monster.com,  I’d love to go somewhere and see, was that the first time?  Have they been breached before, and I simply didn’t hear about it? How about Heartland Payment Systems?  It seems to me that right now, companies can get away with repeat offenses,  simply by flying under the radar.

Of course, there is always the Listeriosis Clause to consider — who do you trust more, the company with a dedication to quality that is forced to disclose, or the lazy/ignorant company who never even looks, and therefore never has to tell?

In any case, I’d like to see collections of disclosures about the various services I choose to use or do business with.  I’d like to see data collection for the purposes of comparing privacy policies,  TOSs, known breaches of or challenges to those policie. Another issue that I believe could gain prominence is being able to easily research whether the companies I interact with are sending/storing my information across international borders.   I think there would be some really interesting discoveries in such a body of data.

Good laugh

http://www.pingidentity.com/vid-test.html

I wasn’t expecting to enjoy this — but I did.  There are some great lines, you just have to get past the obligatory intro scenes 🙂    The plot is familiar — not because I’ve seen the movie but because I’ve lived the integrations.

My favorite — princess Leia having to stop transmitting her plea for help because the “storm-consultants” were coming…. there are more but I wouldn’t want to spoil it for you.

What’s in a 100 Million?

100 million credit cards compromised.  Just like that.  Heartland Payment Systems was hacked in May, and now the following January they are famous for all the wrong reasons.

What gets me about this, is that this processor was storing and forwarding the exact same set of data that the consumer provided.  Why??? Why not alter that data at each step, such that the data needed for processing is not the same set of data needed to initiate a transaction?  Using these kinds of methods may not prevent theft of data, but they can sure as heck increase the difficulty in using that data to make a profit.

I wonder what the cost is to the credit card companies per re-issued card?   Adding the postage, labor, and manufacturing time, I have to imagine this will not be cheap.    Changing an already established system isn’t cheap either, but what are the options?  Getting better promises of security from your payment vendors?   Yeah.  Right.

Justice for Azigo Post

Yesterday’s Azigo post is now stylin’, with extra features like images and bullets!    If you held off of reading that post because the large bricks of unformatted text were making your eyes bleed, you can go back now:  https://eternaloptimist.wordpress.com/2009/01/13/azigo-a-go-goes/

Otherwise,  check out the comments on the post,  also two corrections:

• Through my own ignorance, I mistakenly intimated that the desktop portion of Azigo was going away, when in fact Adobe AIR *is* the desktop portion, and in fact the goal is to move all functionality into Adobe AIR.  I hope I improved the situation with that explanation, and that there doesn’t need to be a correction to the correction 🙂
• There is a card usage/history section, I just didn’t see it.  In fact, if you look at my own screenshot, you can clearly see the  “History” tab just above Dr. Evil’s head.  Apparently my powers of observation took a dip there…

Apologies for the formatting wackiness, and the omissions/errors,

Pamela

Azigo A-go-goes

I’ve finally had a chance to use Parity’s Azigo Identity Selector, and I have to say I’m impressed.

Pretty huh?

Azigo’s biggest differentiating factor is the fact that cards are stored in the cloud — Azigo uses an Adobe AIR front-end to talk to your cloud-based cardstore and submit your cards.  Of course it doesn’t look any different to the user, until the user installs azigo on a second computer, and discovers that their cards are ready to go, no importing required.

Here’s what I loved about Azigo:

• Easy, beautiful installation script — Azigo is actually a really complex beast, right now there are several parts that have to be downloaded and configured, but the install script takes care of everything.
• Pretty prettiness — The design is beautiful, it is a joy to see the fonts and colors and rounded spaces.
• BEST PART:  there is a simple mechanism to group and organize cards according to function.   This is a feature I’ve been dying for for YEARS.  I can now finally separate my OSIS interop cards from my PamelaWare Test Cards from my ICF & PamelaWare Admin cards from the cards I’m playing with at various IdPs.

Issues I found with Azigo:

• It takes a bit to initially understand the relationship between Azigo in the browser and Azigo the desktop application.  It took only a tiny bit of exploration to get things straight in my mind, but that could be a problem for less adventurous souls.  I understand that the desktop application will be going away in the future anyway, so this is a short-term issue.
• There is a checkbox when you send a card to a site that asks if you want to just automatically send that card every time that site asks for a card – but there is no persistence to that checkbox, it defaults to automatic submission every time you use the card.   It drives me nuts to have to remember to click that checkbox every time.  I’m assured that this checkbox will become persistent in the future.
• I found a few other bugs – which isn’t surprising, it just shows that Azigo will improve as people use the application in situations beyond initial testing parameters.  The friendly identifier didn’t correspond to that of the RP, and I had trouble uploading a card image.  Both of these have been reproduced now, and are on their way to being fixed.
• As a feature request, I am excited to see what the Azigo folks can do with card audit data.  I can’t find any card usage/history data at this point, but hopefully it is coming.

Things I wonder about Azigo

• I worry about the fact that the cardstore itself is protected by a username & password.  By putting the cardstore in the cloud, we end up having to protect the protection mechanism, and the one that we can’t use to do that are information cards…
• I wonder if Azigo would license the code to people so that they could run their own cardstores?  I think there could be interesting possibilities in the Enterprise for something like this, perhaps you could do something wacky like combining existing privilege management products with Azigo.  In that case, a short-term user that you don’t want to provision an account to could get limited access to a cardstore containing an elevated privilege card.  This might be useful in the case for a real-life example where a given vendor has a rotating stack of 12 or more auditors, and you wish not to have to provision an account for this revolving door of people, but you want to retain contractual obligations and historical audit.
• Because this service is available anywhere, it would theoretically be a juicy target for remote attack.  I would love to eventually see user-configurable additional security features in the case where the cardstore is accessed from new IP addresses or countries, or in the case where some threshold of acceptable authentications were exceeded.   I know this is advanced, but I think it would improve confidence in the security of the cardstore.

Overall, I have to say that this selector greatly exceeded my expectations.  Not only is the product really polished, but the people behind the product have been really responsive, making sure to address all of the issues I brought up to them.    Azigo has really made good on the promise of information cards here. For those who don’t follow this area closely, I suggest keeping your eyes on the parent company, Parity.  Parity has always been a leader with respect to mindshare in the area of information cards, but now their products are showing that they are not just up in the ivory tower.  They mean business, and they are going to raise the stakes.

Fun with Claims Games

Andy has a claims quandary – check out his blog post to see it:  http://xditao.blogspot.com/2009/01/claim-game.html.

To paraphrase, the question is how could a Library model a set of roles that a user might possess, and ask for possession of those roles in a way that doesn’t inconvenience the user by forcing them to undergo multiple card transactions?

Here is my proposed solution, and I just made this up so feel free to call me an idiot if deserved:

1. Create a set of “role” claim names:
   • http://library.com/role_claims/system_admin
   • http://library.com/role_claims/book_borrower
2. Create a set of  “action” claim names:
   • http://library.com/action_claims/has_library_role
   • http://library.com/action_claims/does_not_have_library_role
3. In your RP trigger object, ask for actions as required claims, and specific roles as optional claims, for example:
   • Required:  has_library_role
   • Optional:   system_admin
4. The Identity Provider evaluates the actions against each of the specified role claims, and returns the applicable roles as the values for each action.
   • In the example above,  the value returned for has_library_role could contain the string: system_admin, communicating that the user does indeed possess the role.
   • A more complicated action might be “has_all_roles” where three role claims are optionally specified, and the return value of the action claim is TRUE only if the user possesses all three of the specified role claims.

Here’s what I like about this scheme:

• The RP can always expect a definitive answer for the action claim.
• Minimal data is transmitted.
• Only the action claims would determine card selection at the beginning of the transaction.
• The IdP can control the context of what is returned.
  • It could evaluate the requested roles to be sure the RP has the right to ask.
  • It could return something as simple as a role list, or something as complex as an XACML statement.
• Role claims can grow and change, while action claims can remain static (this is important for managed cards, since IIRC additions to required claims offered would result in users having to download a new version of the managed card template, not something you want to happen often).
• Action claims can represent very complex and specific logic if need be.

What do you think Andy?   Could it work?

She’s Geeky 2009

Hats off to Kaliya for organizing She’s Geeky this year – I wish I could be there.

I love the idea of showing up and just finding out what other women in technology are doing, it seems like such a positive experiment.  I hope you all have a great time!