Nymwars: converging two worlds

Today this announcement was made: Facebook SIM brings social network to dumb phones. And this may well be the first convergence of the first world and the second world, convergence of the real world and the digital social networking world. And as I predicted, Facebook is one of the parties involved. Google will follow soon, mark my words...
Facebook Real Name policy will of course have a major impact. Your fb account is connected to your phone, the device you carry with you. Your virtual identity is connected to your physical identity 24/7. And I suppose that Facebook Timelines will in no time show your whereabouts, no more need to check in, fb knows it all. Frightening...
#IleftFacebook

Me, a name I call myself

Recently a few service providers initiated their Real Name policy. They require their users to use their real name in order to be able to use the services. Google+ and Facebook prohibit the use of an alias as a name. One of the most famous victims is Identity Woman. The service providers claim that the use of the real name of users helps creating more trust on the Internet. There are several reasons why this reasoning looks invalid, it looks as if there's another agenda. I will get to that later on in this post.

Of course these service providers allow you to use services like email, chat, socializing and so on. And until a few months ago these features seem to work for the Internet community. I can chat with other people. And I connect with them based on the information from within my network (about the reputation of these new connections), or based on their previous work (that I found using other Internet services), or even based on me knowing the person in real life. In no way does the real name of Internet users in my network have anything to do with me trusting them, trust is based on other parameters, reputation and performance being the most important.

A bizarre phenomenon is that many years ago I could open a Gmail account, using any stupid account name that I could imagine. Never ever did Google ask me to prove my identity as a person, and never would they claim that my mail is reliable or trustworthy. Of course they can't, because they don't know me in person and because I never needed a trustworthy email account in the first place, I just wanted a free web based communication facility. And now that they added + to my mail, they claim that all my communication will be more trustworthy if I use a different, real name.

These service providers have a point in a way that they manage to position themselves not only as a service provider, but as an identity provider, one of the major parties in a trust framework. Their users can use these identities towards other service providers, using protocols like OpenID and OAuth. But here they fail to understand that a digital identity, such as a + name, is just one of the identities that I, as a natural person, have. I have plenty more. G+ is not my real identity and you should not trust it, since this identity provider doesn't know me.

But, that's not all true. Google does know me, in the digital world. They know my interests and behavior based on my digital history. They know what I'm looking for and what other identities I have relations with. And this knowledge is valuable in exploiting their core advertising business, this knowledge is their business model. I get to use their services for free and they get to know me in order to let their commercial partners contact me for relevant offers. A fair deal, but trust is in no way a concern. I create my own network and I use the services that I want.

But how can these Googles and Facebooks earn more money? When digital identities are connected to real life consumers, ad campaigns have a higher return, these campaigns can be more relevant. And so ads are more valuable, resulting in higher earnings. That's their new business case, their new hight profit business model: connecting digital identities to real life individuals.The providers claim to help create more trust. By now they should know better. Diginotar proves that trust is not a technical issue, It's a people thing. And requiring real names does not help. In fact it is a new threat to my freedom in choosing the services that I want to use, in connecting to whoever I like and to be on the Internet who and what I like to be. Sometimes anonymity is not bad and sometimes an unreal name is more secure.

RSA mocking hype

And so finally RSA aknowledged that the march hack can in fact result in risks. It took some while and perhaps because of this the tweetosphere exploded by all experts mocking RSA: SecurID is unsafe now. And the fact that RSA said to replace unsecure SecureID's for only a few 'high risk' customers made things even worse.

And alas, for RSA things will not get better soon. Being vague about the theft of whatever was stolen does not help getting back the trust that was lost today.

But there is another problem. Media report that SecurID is corrupted, but, as long as we don't know what the real problem is, I have not yet seen an objective problem analysis. What is the real risk for a regular RSA customer? Is everybody just repeating (RT'ing) others without thinking for themselves?

Fact: trust in RSA is low. No fact: SecurID is corrupted.

Let's just think of an attack scenario like this:
An attacker can calculate the security code, based on knowledge of the algorithm, using a seed from the stolen dataset. But, what seed is the seed that belongs to a token that is used for authentication? What token is used? A web login form does not contain this information. Besides one would need a valid userid (for a Windows domain), a valid password and the pincode of the device, that is needed to proof the legitimed use of the token.

Unless an attacker has all this information, he cannot authenticate. An attacker might fool the RSA authentication server, that is not enough to enable access. More is required. That makes me think that the documented attacks must be inside jobs and that the insiders had to steal the RSA data as well to make further remote access possible.

I may be wrong, must be because of all the fuss by the security community, but I really don't see SecurID compromised. I don't trust it now, because the strange moves of RSA, but as far as I can see, SecurID can still be used as a means for strong authentication. But we need to know more of the data loss and we need to know more of the (obscure) security model.

And no, besides being a SecurID user I have no relationship whatsoever with RSA.

Personal digital lockers and standards

A new trend is born, the secure personal digital locker. It used to be called the Digital Vault, but locker feels a lot more personal.

What's the purpose of a locker? It's a storage area for your personal data. The principle behind the locker (as defined by Google's Schmidt) is that you are the owner of your data.

Interestingly, now I know of at least 4 dedicated cloud based locker systems: Qiy, Digidentity, Singly, Azigo. And of course there is Google, iTunes, Amazon
And it will not end here, many more will appear, multi platform tools and apps, and, of course, the inevitable patent wars will happen too. Nevertheless, it seems a nice concept.

But having a locker is only the start. You have to get your data in there. And using a web form to upload is not very practical. Automatic interfaces will have to appear that enable upload from service providers to lockers of their customers, thereby transforming physical output on paper to digital output for delevering and storage in digital lockers.
Interesting, especially for those service providers, it will save massive amounts of paper, quite some business case!

But how will this end? Will everyone have just one locker? Or do we split risks and have separate lockers for different aspects of our lives?
And how can service providers know which locker to use to send data to? And which digital identity is required to open a locker? What legislation is there, can governments open my locker? And what if I die?

Plenty questions and hardly any answers yet. But I know for certain that we need open standards, at least locker provider should use open standards. Standards to be able to send data, upload, standards for identity.

[rant mode]And puhlease, get rid of those patents in order to make this new ecosystem work. Long time ago I had a Compuserve account and I feel that all current patent discussion can be stopped by pointing as Compuserve as an example of prior art.[/rant] (sorry about this)

Quick wins are an illusion

I wish that we could get rid of Quick Wins in programs and projects. In the past I experienced that many projects were legitimated by calculating a business case with a few quick wins. And based on that business case a steering commitee would then decide to start the project. And the first goal would be to harvest the low hanging fruits...

But in almost as many cases the projects were re-scoped after realizing the quick wins. Everyone happy: project finished in time, some financial benefits realized. But real progress, building a well structured foundation, based on the original requirements and designs, with decent quality assurance, will never be made.

Quick wins are an optical illusion for steering committee and project management. They are counter productive. You better subtract these wins from project benefits in the business case, because they make finishing a project after the starting phase so much harder, if not impossible!

Continuity as a service

(this post is not really about Identity, just a translation of my article from november 2009)

Nowadays everything is turning AAS: software, infrastructure, platform, security, identity, storage. More and more the traditional IT gets more foggy, we are more and more in the clouds. What remains of the old IT profession is to design and manage new things that have not yet been migrated to the cloud. That is no fiction: many companies transfer their legacy applications to the cloud. Even 'legacy' processes occur in the cloud, just think of HR and CRM processes. The cloud reminds me of that old Blob, the science fiction movie, cloud is becoming so pervasive that it seems to take control of everything. And just admit it, we find that exciting, scary and fun at the same time. But if everything disappears in the fog, how do we know that business is as usual?

The critical reader will, however, say that cloud is nothing new. It is nothing less than what we used to call ASP or Grid computing and so far we could reasonably well cope with that. Actually, cloud computing is a form of outsourcing and hence we do have a lot of experiences, both in a technical and a functional way. We know about the definition of requirements, managing contracts and we know how to deal with risks. We are in control.

In my opinion however, that is too simplified a representation of the problem. There is more to the cloud than just to call it a form of outsourcing. Let's make a distinction between between the cloud and the cloud. Not everything is opaque.

There are cloud variants that resemble regular ASP or outsourcing solutions. If you arrange with a provider to host specific services, that is just outsourcing, although not via leased lines, but via the Internet and that is not very exciting. It only becomes exciting if the same provider does the same for other parties and even more exciting if that provider in turn will outsource part of his business to yet another cloud provider. And that happens as we speak. Already CRM providers offer CRM services, hosted somewhere in the cloud on third party hosted cloud platforms. Just think of Amazon's Elastic Computing (EC2). Who knows where the real iron is? It seems so simple, you use a CRM service but the only specific part of the service is your personalized bill.

There are many security related questions. How about privacy, access control, change management procedures of the application, operation?
Fortunately, most of these questions are similar to the traditional outsourcing environments. Most of the problems are handled in contracts: agreements relating to ISO certifications, audits, SAS70's and TPMs are common.

But the core of the AAS problem is that contract partners are not always the parties who offers the actual service. You can try to mitigate risks in contracts, but the fact of the matter is that you want to move to the cloud, because of the positive price / performance ratio of multi-tenancy and the (re)use of standard applications. Long term subcontractor relations in the real world don't exits in the Cloud. If one platform provider is too expensive, our service provider just moves to another. This means that we are victims of the arbitrariness of our providers.

Back to the risks. Most risks are well known. Using standard operating procedures, access control and audits we can identify and mitigate problems relatively easy. And already there is a lot of information about security in the cloud. But one area of risk is not yet completely clear, the risks of business continuity.

The cloud is in many cases seen as a solution for business continuity. The cloud consists of virtualized, web based services in environments that are accessible via the Internet. This means in turn that the availability of iron is no problem (simply moving images), and scalability and performance are just issues of more iron and the availability of the Internet is the limitation of accessibility of the service. All fine. But the Cloud is not just a solution for business continuity. There are specific problems and there are no solutions to these problems yet. Indeed, even parties like Gartner have no ready-made opinion.

In this article I will briefly introduce some some specific cloud related security problems and indicate solutions to address the problems. I would like to stress that this is not a scientifically sound enumeration. It is astonishing how little is published about Cloud (SAAS) and BCM.

• The service provider drops out: can we address this as a regular contract deal, like ASP outsourcing? Unfortunately no. In a regular ASP outsourcing deal we are aware of the underlying application landscape and the underlying data models. You can for example, create a periodic copy of the environment and information and rebuild the landscape if needed. In many cases it once was your own... This is not possible in SAAS. If the provider fails, all knowledge about the apps and landscape may fall away. Apps and data structures belong to the SAAS provider and you can´t uses these if the provider fails. The minimal solution is to periodically dump data (both transactions and management and data logging) in an understandable file format. You should make this a contractual right.
• Traditionally Escow is a business continuity measure, but since changes on SAAS applications landscape may be so frequent, Escrow is not a real option anymore. At this moment there is no ´Cloud Escrow as a service´, this should be considered as a giant gap in the market.
  Gartner indicates the interesting idea to ask the cloud provider to open source the application code in case of a bankruptcy...
  An other alternative is the contractual agreement whereby you have the right to run the application in your own environment in the event of a disaster at the cloud provider's.
• It is not the SAAS service provider, but the underlying infrastructure or the platform supplier that drops out.
  Can you rely on the traditional subcontractor relations to help you into operation again? Is it enough to trust your SAAS provider to abide the contract? No way, it would take too much time to transfer the application landscape. In the cloud-epoch we also need cloud measures. Securing both data and code is vital, so it should at least be contractually arranged that a fallback in case of the SAAS failure can take place. It is not enough to claim responsibility of the SAAS provider. A switch to another SAAS provider, as a preventive measure, should legally be a realistic option.
• You need to define what can be called an incident or an emergency up front, in order to create a contractually sound escalation path.
• Of course your employees must always able to access your own application. You should therefore take care for a reliable Internet connection and thus a reliable connection to your cloud environment for your own employees. Availability is not expensive, but make sure that the coworkers can connect to the right cloud environments. Arranging for alternative connections, such as UMTS-like channels, has to be considered.
• Availability outside the regular network mean that you not only have to take technical measures, but you also need to realize functional measures. And that brings a management burden entail. Especially Identity Management in the cloud is at least as important as it is in the physical world. Identity 2.0 and federation will be very important. Ensure that these processes work as well.
• The latter does give rise to ensuring that SAAS solutions are not embedded in a chain of business processes. If such a SAAS process solution collapses, the whole chain of business processes may fail. There is more than this reason not to integrate Saas in your process chain: until today, there are still no industry standards to enable parts of business processes to make side steps to other processes and back again, like to Saas solutions in the cloud. So far, cloud solutions are point solutions. From the perspective of continuity that need not be bad at all.
• And of course all standard management security measures apply. Think of sound purchasing procedures, performing penetration testing and requiring SAS 70 Type 2 statements.

The uncertainty surrounding continuity is high at this moment. The question is whether for business-critical applications sensible solutions in the cloud exist today. An assessment around the continuity and security risks and safeguards in place seems to be appropriate. The issues described in this article should help to answer the question.

Another business case for federation

Traditionally Identity Management is almost core business for many companies. Of course we all sell products and services to consumers, but those are commodities when it comes to identifying the trouble we have managing our business. You have to comply to all kinds of laws and regulations and operating an identity business is no small task. There are lots of small processes and you have to operate in a trustworthy and secure way. And the reason? We only trust ourselves.

There are several reasons to reevaluate the need for identity management. First there is the trouble implementing the technique. Not only does it have to be secure enough, privacy laws are applicable so supervisors will be on the loose.

Second: your customers hate identity management. You're not the only one that has to manage identities, so do your customers. Identity 2.0 didn't happen just because it could.

Federation is an intriguing technique for identifying individuals. It does require another point of view, but there are many benefits. For instance you don have to manage identities, but you can have a specialist, the Identity Provider, take care of that. You only have to trust the IdP and open up your business for the new protocols. And your customers don't need yet another account and password. The can reuse an existing identity.

Last week a new business case appeared. In France new regulations require website owners to make identity information accessible to the authorities. Accounts, password, personal data. Not really what security is about. These laws apply to French companies, but perhaps also to companies dealing with French customers, although I cannot imaging how French authorities can plan to execute these regulations.

But this new development does help us to define a new business case for federation. Federation means that the relying party, the party trusting a 3^rd party IdP, doesn't have to store personal data, except for transaction data. And what you don't have, you can't lose. Or hand over to others.

Blogging on my N900

Writing blog posts is not business as usual. Most posts take a while to become published. And since I have to do more work and write some more stuff for the Dutch information security magazine, this blog gets less attention than I planned beforehand.
A new tool on my Nokia N900 smartphone (great little device) might help me writing small posts easier. Perhaps I can create a few smaller blog posts, that take less research and pondering. This is the first try...