The Federated Reserve Part II

The Federated Reserve

I have been thinking more about the Federated Reserve notion and thinking specifically about that fact that since it doesn’t exist, who will (or should) create it, and how will the creators be determined or selected? Is that what companies are trying to figure out? Is it collaborative enough? Are the right players at the table to help build this, or is it up to an organization to figure this out on their own?

I suppose that I should probably research the real Federal Reserve System to see how that came about, but I’m not sure it will work in the context of private enterprise. I’ll leave it alone for now. That said, who should make up the Federated Reserve System/governing body?

My first reaction is that there needs to be a consensus of organizations and people with the most to gain and the most to lose that would comprise the Federated Reserve System (FRS). The software manufacturers need to be there, as should any publicly traded company (compliance reasons alone), and perhaps the Federal Government should be involved at the high level since there is no competitive interest in the Federal Government developing the best set of standards, but they have been involved (for better or for worse) in the development of standards and there has to be something that can be learned from the process, even if it’s how NOT to do something. So when I assemble this oversight body and think about the practical application - does it work?

If I think about the notion of data as currency, I may not be able to realistically know everyone who is consuming it or producing/using it, but shouldn’t I know what its value is at all times relative to other currency not my own, and shouldn’t people with the right access have access to the right denomination when they need it?

And if the value is determined by me the person, or me the organization, shouldn’t the fact that it has value be enough to want to secure it even if it is just enabling the access to it?

Then it brings up the whole Identity Management vs. privacy dilemma that is also looming out there - As a governing body, can I or will I know who is producing and consuming (using) the currency at all times? Should I? What if the currency is counterfeit or propaganda? What if the currency’s negative value is worth more being used for bad than for good? I can use real currency today to buy weapons or medicine – which does more harm than good? Who determines the value?

I think the standards based initiatives that are underway is a great start, we need to create the field on which we will play. There should also be a high level of transparency, much like the trading systems and currency exchanges that exist today so that a baseline of expectations about how value will be calculated across the board is known, and then it is up to the producers of currency to know what the value is and decide how much currency should be floating around at any given time, and how to safeguard its value.

I am at the Sun Sales Kickoff in balmy Arizona this week and I hope to learn more about one company’s vision on some of this, and I’ll report back.

The Federated Reserve

As I was drifting off to sleep last night I was self centeredly thinking about the brilliance of my metaphoric mind and the metaphor of companies trying to protect their currency (data) while at the same time realizing there is no Federal Reserve System out there to quantify or maintain the value of currency within an organization let alone between organizations. Then I got to thinking - isn't that what Federation is all about?

Are companies trying to create a 'Federated Reserve System'?

If I think about currency of a company, that currency has a subjective value to me, the organization. It also has a subjective value to the recipient/user of the currency which may have the same value, be more valuable, or be less valuable as the recipient/user determines. Where is the level playing field? Should there be one? Or should there just be a transparent exchange (respository) with very high level rules (standards) that govern currency value?

This cuts across all data, right? If I were Lars Ulrich from Metallica (for the record I stopped buying Metallica stuff after the San Mateo courthouse steps grandstanding incident - bonehead move IMHO) the value of my music, lyrics, and composition of songs has a value to me personally and the band. To my record company/label it has a value which is more than Lars, becuase the number of users/recipients of that currency is exponentially higher than Lars. Go one step further and that currency (data, now a song) has a value to each fan - I place a higher value on the currency because I will use it while my parents wouldn't take the currency if it was loaded on a free iPod (a found wallet in this metaphor).

Enter Napster, Kazaaa, etc. which is a governance-less exchange which totally devalues the currency across the board for many but not for all. To me it's still relative high value, however to the other components of the currency chain, its value has diminshed beyond belief. I realize I am off topic a bit here with Identity, but I do think that in this example it points out the necessity of a 'Federated Reserve System' for data, or in our world, currency.

One hope I do have is that all the components of Identity Management get knitted together and that there is a Federated Reserve System that is established. I also hope it is as elegant and flawed as the one that exists in the real world and takes into account that currency is just currency, and it's the people that must know and manage its value - not the currency.

MM

The Looming Customization Support Issue

I have stumbled into to something recently that I believe warrants some discussion and that is - all of the Identity Management products that I have seen/evaluated require a serious amount of customization support that cannot be done by end users. Sure there is 'self service' but who sets that up and who changes the settings once it's set up and a policy changes.

As companies go through their software purchasing cycles one thing that is usually not covered in the process is post implementation support and who is going to do it and what it realistically is going to take in terms of skill and cost. The reason I know this is an issue is because the company I work for has been doing IdM/provisioning product implementations since 1998, before the term Identity management was coined mind you, and one of the key requests we had asked of us was - will you support this after it's deployed? Chances are your 20% support & Maintenance will get you patches, but won't cover the botched implementation of customized code.

The Support question is now being asked by many more companies and there are only a few vendors out there that offer it, let along have any references to point to to back up claims that they're covered.

Support can make or break a deployment folks.

Product vendors are in a VERY tough position because of the grey area created by the level of customization of the products and are asking themselves - where does the product (source code/out of the box application) support end and the customization support (not the product vendor's problem) begin?

Product vendors can and will spend incredible amounts of cash in this grey area of product support or customization support in the coming years. Big Companies who spend millions on software/hardware/services will beat the vendors into submission to support them beyond traditional product support because after all - it's the product that either has or caused the problem - right?

So whether you're a vendor or a company that has purchased or is looking at Identity Management for complaince, to cover your ass, or because it's just good business, look at the support issue. It's there and it's not going away.

In the spirit of full disclosure on this, I am in the business of offering this customization support and even have references. We do it for a Fortune 5 company and are working with product vendors to help them address the issue as well.

Is Identity Management really about Identity?

I was just speaking with Ian Glazer, one of the old Access 360 guys (now IBM) and we were discussing his recent acceptance of a job at TNT (who I have blogged about previously) and we were pontificating about whether or not the identity management initiatives that companies are starting are really about identity management at all.

To me identity management is all about being able to reasonably prove that the person acessing data is who they say they are and has access granted to them by role, device, application, and/or policy.

Data access management is the reactive or proactive management of a role or identity's rights to access data wherever it lives.

Today, data is like currency. The reason I say it is like currency is not because I grew up the Valley in California, but because data in general comes in many denominations, sizes, shapes, languages, and carries with it different valuations based on any number of factors. What companies, I believe, are struggling with is the problem of - there is all this currency floating around, with no central banking infrastructure to help manage or govern its value and exchange.

Think about it. It's the equivalent of everyone being a bank, with many denominations of currency, with no Federal Reserve, no FDIC, no World Bank, nothing. I can say I have $100, and to one person or organization it's worth $5 and to another person or organization it's worth $1000 with the value of the currency determined by the withdrawer, not the depositor.

Those with more data have more currency and worth, however they also have more risk, because their currency can be stolen with relative ease.

So companies who now have an exponential number of currencies under their roofs (real or virtual) are now trying to establish the underlying 'banking' infrastructure that is needed to determine currency's worth, protect it, and maintain its value in any exchange with any other bank or its currency.

So I ask the question again, are the identity management initiatives underway about identity after all?

Identity Management's Future??

Man this is a scary thought!

Truly Federated Identity Identity

Pretty funny, but not in a ha ha kind of way...

Identity Management Layers II

Layered Identity Management

I was in a meeting yesterday with Epok discussing their take on identity, and where they sit in the stack of alleged identity solutions. My verdict on these guys is:

They sit way out front (12-18 months). They are where everyone will get to when they look at Federation and what the Liberty Alliance Project is doing.

So a strategy I will be refining with my peers is one of layers of identity management where there are several solutions, tightly coupled and specific to their piece of the identity problem. There is no holy grail, amigos. Not yet anyway. I'm going to work on a picture that illustrates what I'm talking about, when I talk about this layering concept in a future blog entry.

In a nutshell, the solution that I envision starts at the transport/network level with a solution from TNT. This gives an organization their unalterable, pervasive identity or 'iDNA' (this is my term first used in July 2005, and now copyrighted).

The next level up is the directory level and you can pick your own flavor here. The next layer is the SSO layer where the users, now identified as absoltely as possible, begin to access key resources (applications or content).

The next layer is provisioning (Sun, Novell, IBM) whereby users now identified, have logged in, and now are granted access to applications and content they have been provisioned for.

The next layer, or step I guess is more accurate, is to reference the policy engine (Epok) to see what applications or content outside the organization the user has access to and is federated for.

You now have positively identified the user at a very fine level of granularity, you have authorized user access, automatically provisioned the identified user for access on your systems, AND have federated that identity to other systems outside of your domains. In short, you have arrived at the best place you can get to today - A known user, with automatically provisioned and auditable access to content and applications useful and necessary to that persons functioning (not necessarily role) as a member of these connected systems.

Pretty cool, huh?

Let me tell you cool it *really* is - mark.macauley@sdgc.com

DNA of Identity Part II

With all of the software implementations happening for compliance, the laws seem to have been written dictating that companies need to provide an access log of who is touching or accessing data on a particular system at a particular time and holding companies accountable for what happens with that information.


Who is to say that the person accessing the information is the person you believe is accessing it?


In this day and age it's too easy to do an ip address spoof, or run a program to crack a username & password, or find some other way to impersonate someone online.


In my opinion the next logical step in this whole Sarbanes Oxley compliance push in corporate America is to get closer to proving that who got access to sensitive data is who got access to sensitive data. One of the best and worst things about the internet and computer networks in general is the *perceived* relative anonymity by which we navigate the wired world.


The issue for companies is that they need to know that the people they employ have the best interests of the company in mind and won't do anything that will land management in jail. Even in the real world, as a recent example, Sonja Anticevic a Croatian woman was thought to be the victim of identity theft after rumors of insider trading in the Adidas-Reebok deal came to light. The investigation is still unfolding, but from what I've read she may have had her identity stolen and used in fraudulent activity. She is an older woman who allegedly did not have the $130K investment required to parlay into a $2M option trade.


The point is not that older Croatian women are bad, but how do they know it was her and not someone else posing as her who used her name and accounts to park the cash? This to me is the real value in any of this 'identity management' stuff, and I hope that legislation can be drafted to craft a policy whereby companies are allowed to identify their employees and their harmful actions, as absolutely and with as much respect to privacy as possible.

Over and Out

The DNA of Identity

So I was at a meeting with Trusted Network Technologies this week where I got to see their solution work. I was theer as a partner not a prospect which which means I had a chance to see the product as it really is, not a preconfigured ultimate solution presentation-ware product demo. My verdict:


One of the best thought out solutions in the market today. Why?


Many vendors (including companies I partner with) like Sun, Novell, IBM, Thor, etc. are focused on application layer identity management (IdM), and in many cases authorization then application layer IdM. TNT goes a *key* step further in my opinion which is to provide an unalterable identity not only to the user but to the machine the user uses.


Why is that significant, because the stakes just went up of somebody spoofing a login (username/password crack) or an IP address. Can someone still get past the virtual moat? Sure. I've always believed that whatever one builds, someone else can break, however, the practical application of this solution is enormous for business. Especially when you narrow down who did what by login, machine, and identity. Why do I call TNT's solution the DNA of Identity? Because I watch a lot of CSI and one of the key things they look for in their evidence is DNA. Your DNA is you in the real world and this is making it more so in the virtual world.


Take for example an offshore firm who does a lot of work for a Wall Street company. VPN's are set up and communication is tolerably secure. Then collusion happens where someone offshore gets moved off of a project at that firm, and gets put on another project at an Indonesian bank and the person's account was never shut off at the Offshore firm or at the Wall Street company. A rogue employee that was just hired from a competitor offshore comes in and gains access to that persons account on the next shift.


How do you know who did it? The more important question is how do you prove it? and the most important question is 'What is the downside/risk of not knowing how it happened and fixing it? This is exactly what I am talking to several Fortune 25 companies about right now, and proposing a reasonable fix.



By the way if you want to contact me and here other real stories where the names of all parties were changed to proctect me and my family, reach out:


Mark Mac Auley

mark.macauley@gmail.com