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...

Stork and other assurance frameworks

As I wrote earlier am involved in the Dutch OpenID.nl+ initiative to help grow the acceptance of OpenID (and to a lesser degree Information Card) in The Netherlands. Within the initiative Identity Providers and Relying Parties define an interoperability standard whereby Relying Parties can rely on digital identities from Identity Providers, based on the verification level of identity attributes by the participating Identity Providers. RP's can authorize users based on the verification information in the claims.

The Trust Framework is based on the assumption that trust derives from the reliability of the identity provider (including the reliability of the identity priovisioning process) and from the reliability of the use of a digital identity. Meaning that there are two parameters: trust in the identity as verified by the identity provider and trust in the use of an identity by the individual owning a digital identity (proof of posession). IdP's must adhere to a certification scheme to prove their reliability. The OpenID.nl+ initiative manages the white list with trusted IdP's.


International developments like STORK also define authentication assurance levels, but these levels are a combination of Identification (by the IdP) and the method of authentication (by the user, based on proof of identity). These assurance levels are the product of a mix of both parameters.


The strange issue is that for certain levels a low level of trust in the process can be compensated by using a strong form of authentication. So QAA2 can be the result of accepting an identity that's hardly verified by an identity provider, but requiring a one time password. Strangely, that would mean that the IdP may not fully know the individual who is issued a digital identity, but you know for sure that the user of the digital identity is the rightful owner of the identity. So someone logging in as Mickey Duck may not really be Mickey Duck, but he is the rightful owner of Mickey Duck's digital id.

In the OpenID.nl+ initiative the net effect may be the same, for most combinations, but the vision on trust is more distinct, the implementation offers a lot more granularity (because of the trust model), although implementing this granularity is not yet part of the roadmap.
In my opinion you shouldn't require a combined assurence level, but you should demand a certain level of trust in ownership of a digital identity and the use of a digital identity.

I will probably get this al wrong, since this model is widely accepted, but then again, maybe I'm not.

Open Trust Frameworks for Open Government

As I wrote earlier, the biggest problem in the identity 2.0 space is the absence of trustworthy public Identity Providers. I called for a trust framework that would enable differentiation in trust levels for identity providers. Of course that requires some major party to define the standards.
There is some great news about the development of a standard trust framework for identity providers. Initiated by the US Government the Open Trust Framework for Open Government was formed. In a White Paper the methods are described.

There are other initiatives, like the Dutch OpenIDPlus. Let's just hope that these initiatives will converge into an interoperable international standard.

Facebook game review Spymaster

After playing Mafia Wars for a few weeks, I accepted an invitation to join Spymaster. Spymaster is all about the spying game, you're a secret agent (either Russian, American or British) doing jobs and killing enemies. Here too you get energy and health, time based, and use it to do tasks and attacking other agents.
Gameplay is easy. Energy permitting, you select a task and do it. By doing a task you deserve more or less experience points, depending on the outcome of the task. When you get enough xp's you enter a new level and you unlock more jobs and other level adversaries.
You also earn money, that you can use to buy stuff. Weapons (to gain more attack of defense power), safe houses (to earn a steady income).

After playing for a few days, I decided to stop playing the game. It was boring. Every level you would do a task and succeed or not. You would injure an enemy or not. The 'or not' value was to big for me to enjoy the game. Due to the random results, buying weapons and attacking lesser agent seemed to make no difference. I lost some fight and I never understood why. Probably I'm not a spy.













The gameplay was a unrewarding.
The game looked complex. There are spies and spymasters in 'rings' and I never found out how people came to belong to my ring, or how many spymasters were on my side.

The atmosphere in the game was not great. The text mode screen lacked any visual clue about actions or status. Just plain white on black. The only nice feature was the ihntermezzo while wainting for the results of a fight. Gunshots or an animation of an agent on screen. That's about it.

It's a great way to gain plenty followers on Twitter. I did connect my Twitter account to Spymaster, status messages were converted to tweets. Nice if you need followers.