That was the EIC16 that was

Each year, the German security consultancy firm KuppingerCole in Munich is organizing a multi-day conference on the theme of identity and access management.

The KC conference was well organized. Nice location for both sessions and the inevitable vendor marketplace. Lovely brochures, event app, fine catering and a lot of famous people. We'll get back to that later. KC is a large company, has many expert analysts and these are actively present. They moderate panels, are chairing different tracks and give presentations.

The conference lasts three days, long days ... the first keynote generally starts at half past eight and the day closing somewhere between 19 and 20. But that's not all, there are also pre- and post-conference workshops. I decided to join a preconf day this year, namely the workshop on the theme blockchain. I cannot give a full overview of the conference, but I will point to a few highlights.

The hype of this moment is Blockchain. The pre-conference workshop lasted a whole day and treated the backgrounds and ideas around Blockchain and also bitcoin. Also on the third day there was extensive attention given to blockchain in one of the four parallel tracks. Briefly: Blockchain is a promising technology (immutable storage of transactions, transparent, fast and cheap), but so far it’s little used (not really an anonymous platform, ‘bitcoin image’ is not very positive). But biggest problem is the issue of trust. Can you trust the blockchain, do you trust the longevity and continuity? But the advice is: go play with it, within a year or three there are business cases and apps to make use of blockchain technology.

Second hype: CIAM, customer Identity & Access Management. And yet, actually not quite a hype, we have already know,  implement and use it. More importantly is the underlying mechanism, namely federation.

More or less the same applies to IoT and Big Data. These developments also look at federated solutions to preserve both the business benefits and guarantees regarding privacy.

Federation was not only reflected in many presentations. There was a separate track in which the OpenID Foundation presented the many developments. Of course there was OpenID Connect (yes, we really should implement this as often and as broad as possible) and OIX (OpenId Exchange, it so looks like the implementation of what I wished for in my old blogs - http://id-use.blogspot.com/2008/06/trust-model-for-identity-providers.html ), but also a number of working groups on the themes of health (the OpenID Heart working group led by Eve Maler of Forgerock) and the Financial Services API WG.

But not everything topic at EIC16 was about IAM technology, unquestionable the most impressive presentation was by Mia Harbitz of the World Bank. She described identity management in a world where a birth certificate is already a challenge. Children with a birth certificate get a vaccination three times as often as children without a birth certificate. She had more shocking numbers of people without a formal identity, without access to life saving services because of it.

Providing an identity to refugees is also a hot topic (especially in Germany, with 800,000 refugees in the past year). This was discussed in a separate track with an interesting panel discussion. It soon turned out that we give refugees an identity because we want to avoid them actually abusing the services paid by us. Not because we want to offer our refugees just enough identity to survive. Sad really ...

An interesting development was an initiative by Ian Glazer (Salesforce). He and Kantara (for example known for User Managed Access – we should make this a default way of customer access control) took the initiative to investigate whether the Identity professionals can unite. The "Keepers of Identity" are increasingly more import, cooperation is essential. More info: https://kantarainitiative.org/digital_identity_professional/

And for those of us who are in despair… there are still use cases for on premise use of Active Directory. Kim Cameron (Microsoft) sees a shift to Azure AD, but an on premise AD will still remain for the coming years.

These were intense days. I finally met with many digital friends. And I advise you to look up the hashtag #eic16 on twitter. Lots of nice tweets, many photos and video’s and links to interesting articles.

And do yourself a pleasure and visit the blog of my good friend Alessandro Festa...

No business case for Identity Providers (part 3)

Would I like to be an identity provider?
Well, of course. I would make sure that my identities were very reliable and reusable. My identities must be trusted in order to make them reusable by different service providers, the government, banks and other websites. This, of course, requires the use of open standards and an auditable governance and trust framework. To achieve this, I need a business model, because someone has to pay for all this. In my opinion there are several models:

• The citizen/customer pays for his digital identity
• The citizen/customer gets a digital identity for free, no costs
• We license a trust framework

$Identity

Anyone requiring a digital identity by a trustworhy Identity Provider needs to pay for the use of the digital identity. The question is if I, as a consumer, would be willing to pay for a digital identity. If I can't use the identity, I don't want to pay for it: 'What's in it for me?'. This model requires a convincing story: as a consumer I need the assurance of the reuse potential.

If I were an identity provider, would you pay for my digital identity if I could guarantee reuse? If so, how much? That's difficult to calculate. There are many costs attached to running a trustworthy identity management system. Most of theses costs are fixed costs. The more identities I can sell, the lower the management and security costs per identity and thus the lower the price of a digital identity. How about $20 for every identity? And with a periodic renewal every 2 years? Because identities erode.

Zero$ identities

There are different variants of this model.

1) Like I mentioned in an earlier post, the Dutch DigiD is an example of a trustworthy free identity. The identity is free, the costs of the identity are made up for by the identity provider. Because of the use of DigiD, Dutch citizens can perform a lot of G-C transactions online, data entry is moved from the civil service to the citizen. The disadvantage of this model is that the reuse potential is low. The identity can only be used at a fw service provider within the trust framework, like local government and a limited number of legally appointed third parties.

2) Another instance of this model is a company that pays for the costs of identity management and provisioning for it's own customers. Just like the mentioned Digid case, but with a larger reuse objective. All parties in the trust framework abide by the rules of the trust framework and guarantee the conformance to the rules. This means that there should be auditable quality and trust criteria, resulting in some kind of a seal of approval... It looks a lot like the OpenID+ model I wrote about in a previous post.

An identity that can be used often, has a higher value that an identity without reuse potential, hence an identity provider with high reuse value identities will have a better reputation and may be willing to invest in this identity provisioning service. What will this cost? The trust framework will be expensive, so the costs of such an identity will be higher than the costs of the first model, let's say $50 per identity. Investments with a positive Return on Investment, even more if the service will result in frequent customer contact as well, for instance because of periodic renewal of the identity.

Commercial providers of free identities like Facebook, Twitter and LinkedIn, implement this model in some way. The reuse potential of this model is moderate to low, because of the lack of a Trust Framework. Only service providers within the trust framework of the identity provider (think of Blogspot, that enables you to use your Gmail account to logon) offer the reuse potential. Other SP's, who don't require trust, but who just rely on the identification and authentication of a customer, may allow the use of a free account.

What is the business case for identity provisioning for these commercial IdP's? They offer a free digital ID, but who is paying for it? Because when using it, by logging in using open protocols like Oauth, there is no transaction fee for authentication. This is an interesting question. These IdP's seem to gain a lot of money by managing your digital ID in a different way. Managing and securing identities is costly, but their business model has an enormous ROI because of the services they offer by analysing the value of your identity, your profile. Your behavior is valuable…

Is such an identity a good match for all purposes? Obviously not. there is no trust in your digital ID, because, no matter what 'real name' policy, the IdP doesn't really know you, it only knows your profile. And the provider knows every service provider you use, based on your logon.

You could upgrade the value of an untrusted digital ID, by using a third party verification schema. For instance upgrade your twitter account by having it validated by another trust framwork. This of course creates a larger reuse potential (in the other trust framework) with your simple logon feature. But of course, someone will have to pay for the added trust by verification in a third party trust framework. There's no free lunch...

3) The third instance of this model is that an identity provider gives out free identities, but makes service providers, who trust the identity, pay the fee. That could be based on a per per use fee, or in a subscription kind of fee. This creates a high reuse potential, within this trust framework. In this way the service provider doesn't have to pay all costs for identity provisioning, thereby saving a lot of money and limiting compliance risks – if you don't manage identity data, you can't lose them… How much should this cost? Hard to say, but I think that $0.10 per reliable authentication could well be feasible. Or a subscription fee of, let's say, $10 per customer per year?

For IdP's there is a real incentive to create as much reuse potential as possible. The more often an identity is used, the higher the profit. But reuse potential is a result of reliability and reputation, Identity Provisioning is an expensive business model. And if a digital identity is not used often enough, this will result in a financial loss.

Last model...

Let's just create a trust framework and have anyone use it. Both identity providers and service providers pay a license fee and can start using it. The trust framework guarantees reuse and every party can decide their own business model (I wrote about this long ago...). But the trust framework has to be developed, managed and monitored, according to open standards and governed by legal standards. But someone has to pay for this model too. And there is an example, OIXby the Open Identity Foundation.

Lingering business case problems...

There are some other problems for identity providers and service providers. From the business case the main driver for profit is the reuse potential of digital identities. Only if there is any reuse capability, operating an IdP can be affordable. When not, there is no business case. If an identity cannot be reused, it may well be too expensive for the customer, the IdP or the SP.

But there is a strange oxymoron… The better the reuse potential, the less I am inclined to use other identities, the one with the best reuse potential will be my preferred ID. This means that I don't need another IDP. And same is true for other consumers as well. This means that there is limited room for other IDP's. (I know, you may want to use more than one identity, but that's out of scope for this post :) )

Is there a business case for IdP's?

No trust framework, no reuse. No reuse no business case. No business case no digital identities. No digital identities, no trust framework. No trust framework, no reuse, no business case.

I may want to be an Identity Provider, but I don't believe that there is a business case, unless you manage to be  the same league as facebook and friends...



(based on my Dutch language post https://www.cqure.nl/kennisplatform/digidem-4-het-opbrengstenmodel)

The business case for Identity providers (part 1)

In the Netherlands the government provides a reusable digital identity, DigiD, to it's citizens. DigiD can be used for different G-C transactions, for tax-return forms, getting certain licenses from local government, communicating with healt insurance companies and pension funds. The uses are strictly defined by law, you can't use DigiD for commercial transaction, like webshops or for other transaction. And DigiD can only be used in the Netherlands, not abroad. There is another 'minor' problem with DigiD: any Dutch citizen can request a DigiD and the DigiD Identity Provider (IdP) sends an activation code by snail-mail. Not the most secure way of identity provisioning and there have been some incidents of criminals fishing the activation letters from the mailbox. And if a criminal first requested a DigiD on behalf of a victim, of course he knows when to lookout for the mail to capture it…

Anyway the Dutch government is in the process of building a new identity framework, thereby making it possible for third parties to act as an identity provider within the Dutch eID framework.

In a series of blogposts (Dutch: First post and second one) I asked myself the question: is there a business case to become an IdP? Is there any commercial driver to become an IdP? Or are there other drivers?

I found out that it is very hard to answer these questions positively…

A few years ago I was at the European Identity conference in Munich and on one of the panels Kim Cameron remarked that everyone wants to be an IdP. If consumers use your Identity, the single fact that people use one your Identities creates a brand value. You grow a valuable reputation.

But if everyone becomes an IdP, what does that mean? Can you use and reuse every one of those identities? That makes for an interesting problem: at this moment noone wants to accept just any third party digital identities. The reuse capability is very small, too small to make people use a third party identity. We have a deadlock situation. Why is that?

Of course some identities can be reused. Think about Facebook, Twitter and LinkedIn identities. These can be reused, but just to a certain extent. These (free) identites are only trusted by service providers if there's something in for them... For a service provider these identities make it possible to have an authenticated account, without the need to store and protect identity information, like passwords. You can't lose what you don't have. So accepting third party identities is not only useful for consumers, but even more for SP's, as some kind of preventive privacy control against data leakage. But no service provider will let you make financial transactions using a facebook account. Facebook (as a service provider) may do so, but independent third parties will be very reluctant.

Why is the reuse capability of third party identities limited?

Well, in my opinion it's the lack of a transparant, and trusted, Trust Framework.

A few years ago we tried to create a Trust Framework based on the OpenID standard, we called it OpenID+. The + being the Trust Framework. The group that worked to create OpenID+ consisted of a government body, a few financial corporations, some ebusiness companies, media corporations, all prominently present on the Dutch internet space. Interestingly both IdP's and SP's took part in the development of the trust framework. The main principle being that any OpenID+ SP would have to accept any identty that was provided by any OpenID+ IdP!

We started building the policies and procedures, in our spare time (I know, I was one of the authors) and when we deemed the framework sufficiently mauture, we decided to go ahead and to start a few OpenID+ proofs of concept. In order to build the trust framework, we defined the technical extentions for OpenID, the policies for the identity provisioning processes, for deprovisioning, for auditing and legal issues. These were some of the questions that had to be answered in order to create the trust framework:

• Should we create a (secure and trusted) white list of trustworthy OpenID+ IdP's?
• How should an OpenID provider apply for the white list?
• Should there be an audit guideline for audit or self-assessment?
• Can any service provider access the white list, or should we allow only connected OpenID+ service providers?
• How could we guarantee that all providers would interprete claims and attributes in the correct manner?
• What should happen if an incident occurs? For instance in case of misuse or theft of an OpenID+ identity, or wrong interpretation of an attribute of an OpenID+ identity by a service provider?
• How about liability in case of an incident?
• How long should a white list entry be valid?
• Would we need an arbitration committee?

Quite a lot of question, and this was only a small number of questions. And that was when trouble started. Defining the standards was okay, but implementing the standards proved very difficult. We found out that building such a trust framework was very expensive. Especially the documenting and auditing of the processes and techniques proved so costly, that the parties became afraid for what would come next. Who should pay the costs of such a trust framework?

As a result the OpenID+ framework was never implemented. There was no positive business case for any of the participants.

That's not the end of it. Yet. There are several financial models for IdP's. In my next post I will introduce different models and expend on the business case for Identity Providers. And I will try to explain why the reuse capability of digital identities is critical for the succes of IdP's.

 

OpenBadge Based Access Control

A while ago I posted a few entries about using attributes instead of roles to grant access to resources. At the same time I wrote that the current way of providing attributes is limited. So far attributes are provided by identity providers, hence only parties that trust an identity provider know what attributes can be used and may decide to trust the attributes provided by the identity provider. But as I stated, there are many cases that you do not want to get an attribute from your identity provider. You may have passed an exam, received a compliment or endorsement, or you may be part of another community than the one you work for and the one who provides your (digital) identity. Your digital identity provider may not even know all these attributes. And rightly so, an identity provider needs to provide trustworthy (within the trust framework) identities.

So I came up with the idea to make it possible to receive and collect attributes, much in the same way that we are used to receive and collect badges for gaming, or scouting...?.

And I showed that such a mechanism is in use at this very moment, although not yet in the way that I want: Isaca provides digital badges to certified members. And you can collect these badges in a digital wallet, that you can also use to present youor badges.

It's a pity that there is no use other for these Isaca attributes yet. I would like to use my CISA and CISM badges to be elegible as a candidate for a security consultancy project with prospective customers. How easy it would be to just so show my Isaca badge, instead of writing a resume or pointing to my LinkedIn profile. If you need an IT Auditor, here's my Isaca CISA badge... Or if you need a CISM, just search LinkedIn for CISM badges...


Today I learned that there is a another organisation contemplating to provide badges. LibreOffice volunteers may get badges in the OpenBadge format, the same format that Isaca is using. This wil most certainly mean that we will see OpenBadge become a default adopted open standard.

We probably have to come up with use cases for access control based on OpenBadges. Currently these badges are just that, they just show that you are member of a community, but there are no permissions connected to badges. Yet...

Lessons from the Diginotar drama: We need Trust Governance

In the summer of 2011 the Dutch Certificate Service Provider Diginotar collapsed due to a hack of the back-end systems by an Iranian hacker. Since then many analysis were published. Most indicating plenty problems at Diginotar or about the inadequacies of PKI as we know it. But in my opinion the problems are more severe than just technical issues.
In 2012 the Dutch Magazine Informatiebeveiliging published my analysis (I should mention that I am one of the editors of the magazine, so there is no full independency there...). By request I translated the article.

You can find the English language version of article via this link.

(I wish to thank Jacoba for reviewing the translation)

Feel free to react.

Responsible Disclosure

These days in The Netherlands several initiatives pop-up around the issues of ethical hacking and Responsible Disclosure.

What's all the fuss about?
Last year a hacker reported a vulnerability and a data leak in a back-up server of a Dutch hospital. He claimed that he found a lot of confidential information on a server that was readily accessible from the internet. The report was made through a Dutch journalist, +Brenno de Winter.
After publishing the incident we learned that the hospital sued the hacker and for us, the security community, this was unheard of: why sue someone who reports a vulnerability? Who are the amateurs responsible for this leak and do they really think they can get away by suing a security researcher?

In the mean time the minister of Internal Affairs published his guidelines for ethical hacking. And in those guidelines a hacker might be exempt from prosecurtion if he acted conform.

So, we, the Dutch security community, were puzzled. Then rumors came in that the hacker had installed malware on the hospital's server. Sentiment changed, but despite the new guidelines, trust of the hacker community in the authorities, like the DA responsible for cyber crime, vanished. Trust was gone and so was the willingness to co-operate. And right after, some critics of the official guidelines raised their voices and it looked like the guidelines were no longer valid for the people that were addressed in the guidelines.

At this moment this is the status:

• The minster of Internal Affairs published ethical hacking guidelines
• a hackers society published their own responsible disclosure service
• Floor Terra, a researcher within the Dutch Twitter security community published a Responsible Disclosure policy site (here's a translation by Google).

And that's not all, there is at least one more initiative, but that's not yet ready for prime time yet.

Anyway a lot of activity in interesting times. Please have a look at Floor's site and feel free to react!

I will try to publish some more about all activity and invite you to join the discussion.

Your Twitter ID as a source for Twitter spam

I'm getting more and more spam in my Twitter timeline or in my twitter direct message mailbox. And these tweets come from my own twitter friends. And I'm not alone in this. Many others mention this as well.
Tweets like this: “GET MORE FOLLOWERS MY BEST FRIENDS? I WILL FOLLOW YOU BACK IF YOU FOLLOW ME” or direct messages like “lol ur famous now [link]” will in most cases link to malware infected sites.
And now and then a twitter friend reports that his twitter account was hacked.

I don't believe that this is the case. Accounts don't get hacked easily. Of course a pc could be infected with malware, with keyboard sniffers and password stealers, but apart from that, hacking an account is not that easy. Proof? Even security professionals became the source of twitter spam messages.

If your account was not hacked, how can this spam flood happen?
Tweets defininately come from a trusted person. But since there is no way that you can create a tweet with a faked sender address, these spam messages really come from your friends.
On his blog (http://nakedsecurity.sophos.com/2011/06/23/beware-shortcuts-for-getting-more-followers-on-twitter/) Graham Cluley from Sophos explains how these tweets happen. These tweets come from services that you(!) allowed access your twitter account. And these services may well do other things than you wanted them to.
Twitter can be used as an identity provider. It uses the underlying oauth protocol to authenticate twitter users for different services on the internet. And this feature is not only available on pc's but also on mobile phones. Very practical: if you use your twitter account you don't have to login using a user name and a password. All that is required is that you tell twitter to allow access for the external service. And in fact you allow the external service to post messages on your behalf.
Through this link ( https://twitter.com/settings/applications ) you can check what apps you trust to post on your behalf.

Do you really trust all these apps? My advise: You better revoke all unknown or unused apps. And btw: if I receive a strange tweet from your twitter account, I will use a second channel (like LinkedIn, or mail) to advise you to clean your twitter trusted app list.

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.