Kuppinger Cole — Is API Growth in a Stall?

In Craig Burton

Intro

Last year when we published the API Economy document, we showed the growth rate of APIs over time. Examining the numbers from the same source — the ProgrammableWeb — in 2012 it appears as if the hockey stick growth of over 100% each year is starting to slow down.

What is really happening?

The numbers

Figure 1 shows the original numbers we published in the Open API Economy report. It shows a compound annual growth rate of roughly 100% each year starting in 2005. The source of the numbers is the ProgrammableWeb.

Figure 1: 100% Annual Growth Rate. Source: The ProgrammableWeb

Figure 2 shows an extrapolation of what the numbers should look like using the same growth rate up to the year 2016. The numbers show approximately 30,000 APIs.

Figure 2: Projected Open API Growth Rate. Source: Craig Burton and Phil Windley

A few days ago, I received an email from a reader who had compiled the numbers from the ProgrammableWeb so far for 2012. Figure 3 shows a graph of the numbers up until the first of May 2012 and it looks like the growth rate is starting to stall.

Figure 3: Open API Growth to May 2012. Source: ProgrammableWeb

I postulated with the reader that key thing to consider here is that these numbers are based open publicly available APIs and not reflect any private API growth at all. And that in all likelihood any glitches that we see in the Open API growth are expected to happen as the private sector catches up or even surpasses the Open API growth.

Of course I have absolutely no empirical data to back up my position.  I am just making it up.

However, we had a briefing from 3Scale Networks the other day. 3Scale is a major provider of API development and support technology for both small and large companies. 3Scale’s Dr. Steven Willmott gave an excellent presentation at EIC 2012 about the Open API Economy.

In the briefing — just last week — Steve gave us more insight on what is happening with their customers. Steve pointed out that the largest area of growth for their business was in companies that do not publish their APIs and that are being driven by mobile and tablet app growth.

Their projections show the number of APIs in total — including both private and public APIs — to be somewhere around 250,000. He also said that while they watch the numbers published by the ProgrammableWeb, they also do their own data mining and tracking of API growth.

Now I know that the success of 3Scale’s business depends on a healthy API growth rate. And as such I have to consider discounting somewhat the growth projections they give us. Even so, the growth numbers and logic 3Scale provided in the briefing make a lot of sense and seem to reflect many other indicators and conversations I am having with both customers and vendors.

Summary

I think the slight downturn we see in the Open API growth for the beginning of this year is not a long term trend.

Every other indicator I look at — although none of them are exact science — indicate that if anything the actual growth rate of APIs is still on a steep increase.

Time will tell.

Ian Glazer - Gartner — Put 100 Relying Parties in a Room and What Do You Get?

It’s an open secret among us identity geeks that, despite all of federated identity’s progress, one thing has lagged significantly: relying party participation¹. Getting relying parties to the table, to talk about challenges they have with identity on the Internet, has always been a hard problem. Although the identity community has grown, the number of relying parties getting involved with things like the Internet Identity Workshop hasn’t kept pace.

Willingly or not, NIST’s National Strategy for Trusted Identities in Cyberspace (NSTIC) has taken up the challenge of increasing relying party participation. Without real-life use cases based on actual business, actually problems, NSTIC is, though aspirational, vague. However, armed with a set of discrete use cases, NSTIC (and more importantly the identity community) can begin to craft solutions, discover unforeseen challenges, strengthen protocols, and tackle policy issues. But to get these needed use cases requires relying parties to be involved.

To that end, NSTIC is hosting an event at the White House Wednesday May 23rd. The program office has invited over 100 companies all of whom are potential relying parties. These companies are household names, spanning multiple industry sectors. In short, they are a cross-section of economic engines of this country, and by bringing them together in a safe space, the NSTIC program office hopes pick up the pace of relying party engagement and bolster the ranks of companies who can become more efficient and unlock new value by using federated identity.

But there’s only so much convincing the government can do directly. At the event, I’ll be moderating a panel of companies from different industries discussing the value they can recognize by using the techniques that NSTIC promotes. I am going to try and tweet as much as I can from the event and will follow up with a post on its results. If you want to keep tabs on NSTIC’s relying party party, follow me, and tune in on Wednesday May 23^rd at 10am eastern.

 

1 I know that getting identity providers to play is an issue too but that seems to be an easier problem to solve.

Marc Canter - Broadband Mechanics — Going to Kansas City, Kansas City here I come…

There’s a Perfect Storm moment happening in the Kansas Cities – and Digital City Mechanics – will be there!

Matt Pollicove - CTI — Latest Information

When I'm looking for the latest information on IDM, I check all of the usual places like the IDM Discussion and Documentation sites on SDN, which are great, but sometimes I need more focused information. Lately, there's a resource I've been going to more and more, and it's really one of the first things that we should do when we have questions, and that's RTFM.

The SAP IDM team has done a great job of supplementing the included help files with an online copy. More importantly, it seems to be updated regularly. This turns a  useful resource into a vital tool.  

OpenID.net — Open Source Approach Needed for Advancing Internet Identity

European-based identity and security analyst firm, KuppingerCole, announced last week that OpenID Connect was awarded the 2012 European Identity and Cloud Award in the category for Best Innovation/New Standard. This recognition was largely based on OpenID Connect’s potential to significantly change digital identity using a simple interoperable Internet identity protocol to improve the way we interact with each other online.

According to Dave Kearns of KuppingerCole, OpenID Connect’s design philosophy to “make simple things simple and make complicated things possible” can play a critical role in creating the technical specifications (“tools”) necessary for advancing Internet identity across both traditional and evolving digital platforms.

“What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices.”

As Dave sees it, OpenID Connect is to OpenID 2.0 as Gigabit Ethernet is to Bob Metcalfe’s original Ethernet. First, where integration of OpenID 2.0 requires an extension, OpenID Connect, which performs many of the same functions as OpenID 2.0, is built into the protocol and is API-friendly. Second, OpenID Connect provides a secure, flexible and interoperable identity layer on top of OAuth 2.0 specifications, enabling participants to exchange any claims relevant to their application. It doesn’t define ways to authenticate users or communicate information about them. Instead, OpenID Connect uses a default set of common claims about a user (e.g., name, email address, user identifier enabling SSO) to allow digital identities to be used across websites and applications.

In an indirect but important way, OpenID Connect supports the mission of the Open Identity Exchange (OIX), which similarly suggests open source for Internet identities. The relationships, dependencies and synergies between OpenID Connect and the OIX can play an integral role in the advancement of digital identities.

OpenID Connect’s modular design “tools” give relying parties the flexibility to deploy the attributes they need to improve operational efficiency and security while remaining interoperable. From a policy standpoint, OIX helps set the stage for industry stakeholders and policymakers to create and publish the policy “rules” for open identity trust frameworks that improve the user experience and protect identity and privacy..

Together, this new open approach for creating custom “tools and rules” can play a useful role in establishing the levels of assurance and elevating trust in internet identities across multiple jurisdictions and improving the way public and private industry interacts with users over the Internet.

Radovan Semančík - nLight — Use the Source, Luke

All software is bad and it is not likely to change anytime soon. There is not a substantial difference between open source and commercial software when it comes to product quality. Both are difficult to use, very hard to diagnose and unsuitable for any practical purpose without a good deal of ugly hacking. But there is one little detail that actually makes a huge difference: source code.

I have spent most of today fighting with a code generation plugin that is part of our build. The code gave all kinds of helpful error messages such as "Index out of bounds: -1" and "null". There were no logs and no diagnostics output. The -verbose option was most likely provided just for the sake of completeness and had no practical effect. It was simply a dream of every engineer. A very bad dream.

I have been in such situation numerous times, mostly with commercial software. That was a nasty experience in vast majority of the cases. Usually I had to spend many hours reading the useless documentation provided with the product and trying to diagnose the problem using any available tool ... just to fail miserably. Then I would file a trouble ticket and play a long ping-pong match with the support team. If I would be really lucky, few weeks later after many exchanges (and my nerves almost lost in the process) I might have received a hint what the solution might look like. But the most likely outcome is that the support team provides no useful information and I would need to create an ugly workaround all by myself. This happened too many times already.

But today the situation was different. The package that I was using was not a commercial software. It was open source. So I have downloaded the source code, fought with it for a few minutes and finally I had a fresh build of my own. I have navigated the labyrinth of ugly uncommented code and dropped few debug messages here and there. After many attempts and failures I have figured out what is wrong. And solved the problem with only minimal amount of ugly hacking. In just one day.

Few weeks compared to one day. That looks like a huge difference to me. That's one of many reasons why I have stopped to use almost all commercial software. It is just not worth the time. If you don't have buildable and modifiable source code you have nothing. Nothing at all.

May the Source be with you.

Johannes Ernst - NetMesh — Personal Clouds and Life Management Platforms

Martin Kuppinger, of analyst firm Kuppinger Cole, has an interesting report out titled “Life Management Platforms: Control and Privacy for Personal Data“. In it, he brings together some major technology and social trends to predict an opportunity for individuals to manage their own data, in a privacy-protecting way, while improving interaction with major vendor organizations [...]

CA on Security Management — FBI Campaign on Corporate Espionage Highlights Insider Threats

Last week the FBI launched a campaign to educate the public about the threat of corporate espionage. What is new about this initiative is that the FBI is talking directly to the public about espionage and providing a list of suspicious behaviors that employees of U.S. companies should be on the lookout for. The campaign will even extend beyond the Internet to billboards and messages on bus...

 

Ping Talk - Ping Identity — Workshop lineup outlines deep look at ID trends

One of the special features of the Cloud Identity Summit is our two-day opening schedule of in-depth workshops that cover various topics both related to Ping products and industry standards at large.

This workshop lineup has been a highlight for attendees in the past with its three-hour sessions that go deep and broad. The workshops provide the set-up for the conference schedule, which runs the following two days.

This year, we are also adding a series of one-hour lectures, a free three-hour workshop focusing on our cloud SSO environment PingOne, a user group meeting for our customers and a set of Industry Summits run by the OpenID Foundation (Day 1) and the Open Identity Exchange (Day 2). Both of those session are free and open to all attendees.

We think this kind of in-depth education is key as identity extends to the cloud and mobile devices, and as Ping broadens its product lineup and feature sets.  It’s also a critical starting point for those who are just starting to sync with identity federation and Cloud IAM trends. 

Here’s a look at the workshop lineup:

[More]

Kuppinger Cole — The Future of IT Organizations – why IT needs a marketing department

In Martin Kuppinger

Some weeks ago we published a report called “The Future of IT Organizations“. This report talks about how to restructure IT Organizations, following the basic structure we propose for IT in the KuppingerCole IT Paradigm. That paradigm is first described in the KuppingerCole Scenario “Understanding IT Service and Security Management”. From our perspective, IT organizations have to change fundamentally in order to redefine the way we do IT to better deal with challenges like Cloud Computing.

When looking at the future of IT, there is one area which I find particularly interesting. Some of this came to my mind when reading one of the blog posts of Chuck Hollis, Global Marketing CTO of EMC Corporation. The blog post is titled “Why IT Groups will invest in Marketing” and is focused on the need for marketing.

What I liked in that post was the distinction of inbound and outbound marketing for IT – a distinction I picked up and I have to recognize Chuck for. I then aligned it with the KuppingerCole IT model, adding another element which is “product management”.

The IT of the Future is demand-driven. Today’s IT should be as well but reality frequently shows a different picture. Providing the services business really needs is very much about that demand-driven IT. That requires understanding the customers. And that is where the topics of Outbound and Inbound Marketing come into play.

Outbound Marketing is the more common approach. We all are familiar with this in everyday life when getting confronted with advertisements and other types of market communication from vendors. For IT Organizations there are two main aspects for Outbound Marketing:

• Positioning IT as the one and only source of the services business requires
• Selling the IT services which are produced on-premise as part of these business services

The first part is of high importance because IT should remain in control (or get back control) of all the IT services which are either produced on-premise or procured from the Cloud. Without centralized control organizations will, over time, struggle massively with their IT services. Furthermore, there is no way to get a grip on IT cost without such centralized control

The other part of outbound marketing is mandatory as well. The ability to sell the services which are produced on-premise is important. On-premise IT is in competition with cloud services. Thus it is not only about producing the “better” IT services; it is also about selling them. IT Organizations have to change their attitude from being reactive to becoming a proactive provider of services to the business organization.

But there is the other side of the coin as well. That is about Inbound Marketing. Inbound Marketing is even more about the customer’s need – with the customer being the business part of your organization. Inbound Marketing is (amongst other things) about

• The specific needs of your customer
• Identifying the buyers on the customer side (which even in large organizations frequently is not as clear as it should be when it comes to budget discussions)
• Understanding how the customer wants to consume

It is about understanding the customer and driving the IT Organization in a way that the right services are offered. In fact this is about a strategic and standardized approach to providing exactly the services business needs.

From an organizational perspective, IT has to fundamentally change its interaction with business. It is about bringing the demand-supply principle to life, which has been discussed for quite a while. The need to do that is greater than ever.

What do IT organizations need at that level?

• They need to identify the “customer’s customers”, e.g. the persons within the business organization who are requesting the business services. That might require changes in the business organization as well, given that the business needs contact points. Notably, these persons might be less technical than today, given that the ideal of the future IT organization is to provide business services the way business needs them.
• They need, as mentioned earlier, IT Marketing, i.e. persons caring for the outbound as well as the inbound marketing.
• They need “product managers”. If you look at large and successful vendors, product management always plays an important role. They are the link between the customer and software development. They have to translate between customer requirements and development. Sort of the same role applies to them here: They work closely with IT Marketing and the customer’s customers on one side and the Service Management within the IT Service & Security Management Layer to map these.

Simply said: IT Organizations in their changing role as suppliers to the demand of business should act like successful software organizations – with the difference that they don’t need that level of sales but more the marketing and product management parts.

Kuppinger Cole — EIC 2012 Session: Database Firewalls - Advancing Security for Enterprise Data

In KuppingerCole Podcasts

Martin Kuppinger, KuppingerCole
Dr. Steve Moyle, Oracle
Sebastian Rohr, KuppingerCole

April 19, 2012 16:30

Watch online

Drummond Reed - Cordance — Support Standard Information Sharing Labels

One more a tip o’ the hat to Phil Windley for saving me a thousand words. He’s wonderfully articulated the reasons you should support Joe Andrieu’s Kickstarter project for the Standard Information Sharing Label.

Phil sums it up perfectly:

Just like we have a standard label for drugs so that people can more easily understand how to take a drug and what it does, we should have a standard label for sites that want you to share your personal information.

It won’t get us everything that the Respect Network will, but it’s a good step in the right direction. Move your cursor right on over to the project and show you care about seeing what’s really happening with your personal data.

(And what better time to show your support for the standard label than during Privacy/Identity/Innovation 2012 going on right now in my home city of Seattle. Hats off to Natalie Fonseca and Marc Licciardi for an outstanding set of talks on the first day.)

Phil Windley - Kynetx — Standard Information Sharing Labels

Some years ago, based on an idea that came up on a train ride to the airport from OSCON, Kaliya Hamlin, Aldo Castaneda and I put together a The paper for the W3C Workshop on Transparency and Usability of Web Authentication was accepted for presentation on identity rights agreements. The idea is that you ought to be able to mark up data you share to let people know how it can be used. Think Creative Commons for personal data. Recently a number of people, including myself, Drummond Reed, and Marc Davis, discussed a similar idea at a WEF Tiger day.

Joe Andrieu has a proposal that is slightly less ambitious and serves as the launching pad for more complete solutions. Joe's idea is simple and easy to understand. Just like we have a standard label for drugs so that people can more easily understand how to take a drug and what it does, we should have a standard label for sites that want you to share your personal information so it's easy to understand what's going to happen if you say yes. Contrast this with the current EULA model where people are faced with 70 pages of information in a non-standard format that they need to understand if they're to truly be smart about what they share.

Joe has a Kickstarter project for Standard Label to get money to design the label. If you care about understanding what you're sharing and think people should be smarter about what they share, then I encourage you to support this project, even if you can only give a $1, give something so show you're behind the work. Here's the video from the Kickstarter page.

Now, go and back the project!

Phil Windley - Kynetx — Rich Sharing and Personal Channels

The Social Web has shown us the power of connecting. Facebook has friends, LinkedIn has connections, and Twitter has followers. These channels allow their owners to communicate with others, although their capabilities vary greatly. But the resulting relationship graphs are stilted because their proprietary nature makes interoperation and extension difficult—in spite of all of the money and time invested in creating APIs to access them.

I look forward to a relationship network that is based on open standards just as the email network and indeed the Internet itself are. The power of the Internet to serve an untold variety of purposes in a flexible way is a direct result of the open standards upon which it is based. Relationship networks based on open standards will provide unprecedented value and opportunities for people because of the new applications it will engender.

This paper will describe something called a personal channel, based on open standards and protocols, that can form such a relationship network. Personal channels link personal clouds, the subject of an earlier white paper. This paper assumes a knowledge of personal clouds, their features and their capabilities. We will share that channels have properties necessary to induce rich sharing, a hallmark of flexibility without which they would not be able to accomplish all that is needed.

Personal Channels

Long ago, personal computers were interesting in their own right. That changed in the 90's with the emergence of widespread network connectivity. Anymore, a PC that's not connected to the Internet is not only boring, it's non-functional for many of the tasks that people perform every day. If you don't believe me, just turn off the network on your computer for a day. And of course, the modern personal computer—the smartphone—makes connectivity the very foundation of the platform.

Like personal computers, personal clouds are only interesting when they are connected. Personal channels link personal clouds. The collection of channels connecting myriad personal clouds form a relationship network. On an open standard relationship network, the attributes, permissions, and capabilities of a relationship are standardized and extensible. Every relationship is a link. A link may be a simple one-way (asymmetric) subscriber relationship that does not require involvement of the second party, or it may be a stronger two-way (symmetric) relationship in which both parties act as publisher and subscriber.

In either case, when data and messages can flow in one or both directions across a link, it is called a channel. The control each party has over the channel--the terms and conditions to which they agree over how it will work--is called a link contract. Control over the channel still resides in the link contract(s) with the connected parties. The following figure shows two personal clouds connected via a channel controlled with a link contract.

Channels exhibit the following properties:

• Personal channels provide separately revocable, separately trackable authority to share between personal clouds.
• Any given personal cloud can have any number of inbound and outbound channels. Any two personal clouds may share multiple channels for different purposes.
• Channels use a combination of the Event eXchange Protocol (EXP) and XRI Data Interchange (XDI) protocol that give them metaprotocol capabilities. Channels are ways of doing something instead of a place for doing something.
• Link contracts are a flexible means of declaring fine-grained access control to data and services. Link contracts specify the nature and behavior of a channel.
• Channels are the conduits over which messages pass between personal clouds. These messages include event notifications, data queries, and data transfers.
• A channel need not be restricted to just two parties. It may connect the members of a group (e.g., email distribution lists), or access may be fully public (e.g., blogs or Twitter feeds).

Like email, channels form a point-to-point network between personal clouds all speaking the same protocol. Unlike an email server, whose sole function is usually email processing, a personal cloud is more like a general-purpose computer in the cloud; it has an operating system that runs applications, processes events, and manages data under direct control of its owner.

This is why channels on the relationship web can be dramatically more useful to individuals and businesses than ordinary email or Web connections.

Rich Sharing

Marc Stiegler of HP Labs has written (PDF) and spoken about rich sharing. Alan Karp has written about PubShare, a system Marc built that demonstrates rich sharing. Alan relates two stories that contrast our expectations about sharing in the physical and online worlds. The first takes place in the physical world:

In an emergency, Marc asked me to park his car in my garage. I couldn't do it, so I asked my neighbor to do it for me and said to get the garage key from my son.

The second involves an online file sharing scenario:

In an emergency, Marc asked me to copy a file from his computer to mine. I couldn't do it, so I asked my neighbor to do it for me and said to get access to my computer account from my son.

The second story is ludicrous to us because we can't see a reasonable way for it to work even though it closely resembles the scenario from the physical world.

Rich sharing characterizes what makes human communication in the physical world work. Using this model, we can determine how to create better online communication systems. Communication systems, like email, that embody rich sharing feel natural to users and thus succeed. Systems that don't feel stilted or unwieldy and thus don't scale the way their designers intended.

Sharing is easy and technically uninteresting in situations where the shared item is public and there's no need to authorize access to it. Similarly workgroup-style sharing is relatively straightforward and the tools for protecting resources in workgroups such as role-based authorization control (RBAC) and access control lists (ACLs) are well understood. For purposes of contrast, let's call unprotected and workgroup-style simple sharing.

Sharing becomes much more nuanced when access to the shared item must be restricted and the players in the sharing scenario operate in independent security domains. Many real-world scenarios require rich sharing. Stiegler and Karp demonstrate why workgroup-style sharing can't accommodate rich sharing scenarios.

Rich sharing is characterized by six key features:

• Dynamic—Sharing can be done without reconfiguring the system or having other work done by the sharer's IT department.
• Attenuated—Sharing happens with the right permissions on the right items.
• Chained—A shared item can be reshared in appropriate ways. Authority can be re-delegated. Building attenuated chains of delegated authority is difficult in simple sharing architectures.
• Cross domain—Sharing can occur across security domains without the user linking the domains in an ad hoc manner or the IT department having to setup special purpose federated identity systems.
• Recomposable—The shared item or service can be used in conjunction with other resources and services even if those documents and services exist in a separate security domain.
• Accountable—Even though sharing can be re-delegated along a chain, the original owner must maintain the ability to audit and track the use of the shared item and hold the appropriate parties accountable for misuse.

Stiegler and Karp make a case that email succeeds because email demonstrates these six attributes. In contrast, it's easy to find examples in other sharing architectures that fail to incorporate one or more of these and thus become difficult to use as the sharing scenarios get more complicated. Today's popular social networks all fail to meet one or more of the above attributes.

Personal Channels Support Rich Sharing

Personal channels exhibit rich sharing. We mentioned in an earlier section of this paper that channels provide a metaprotocol for interaction. Thus they represent a way of doing things rather than a place. Rich sharing is more easily supported by ways—protocols—rather than by places. In fact, I argue that properties of rich sharing such as being cross domain and recomposable are nearly impossible to achieve using a place such as a Web site.

Let's examine the attributes of rich sharing and see how channels stack up:

• Dynamic—A personal cloud can use a personal channel to send a message to any other personal cloud that subscribes to it at any time. Subscriptions can be formed between two personal clouds or between a cloud and another network service at will.
• Attenuated—Link contracts provide a means of fine grained access control that enables attenuation.
• Chained—Upon receiving a message on a channel, a personal cloud can delegate that message to other personal clouds. This delegation may be algorithmic, but is always under the ultimate control of the personal clouds owner.
• Cross domain—Each personal cloud functions as its own domain in the same sense that an email inbox represents an independent domain controlled by its owner. Thus a channel carries messages from one domain to another.
• Recomposable—Messages sent along a channel, be they events, queries, or data are composed with other information from other sources (e.g. APIs, other channels, etc.) as part of the processing done by a personal cloud.
• Accountable—Channels are uniquely identified and individually revokable. The unique identity combined with the ability to declare authoritatively the nature and behavior of the channel via link contracts provides flexible accountability that can be tuned to a given purpose.

Conclusion

Rich sharing requires that the sharing be dynamic, accountable, recomposable, and cross-domain, while enabling the chaining (repeated redelegation) of attenuated access (including separable revokablity). We have shown that personal channels exhibit these properties and thus enable rich sharing.

Because channels support rich sharing, they are extremely flexible and can be used for many purposes. Personal channels provide a messaging system for personal clouds that provides access-controlled, filtered, trustworthy notifications, data exchange, and sharing. Future papers will expand on these benefits of personal channels.

Marc Canter - Broadband Mechanics — Activity based experiences

Here are some archival ideas from 2002:

Ping Talk - Ping Identity — This Week in Identity - Getting the digital car keys

Dave Miller is the CSO for Covisint. Among other endeavors, Covisint runs the OnStar network, the in-car satellite connection offered on cars from General Motors. OnStar offers car owners many services including remote unlocking, crash detection, and remote diagnostics. Dave has spoken in the past about the various identities required for the operation of OnStar - the car, the owner, and the driver. Being a “man-rated” system, the effectiveness of authentication is paramount, but as always, convenience is a factor. In this interview with CSO magazine, Dave relates the real-world challenges he’s encountered in designing the security of OnStar.

• Dave Miller: Will your next car steal itself?
  “The second issue is deprovisioning. This involves managing the process when an owner sells a car, and making sure that the previous owner can't still remotely start the car. "If the user [identity] isn't automatically deprovisioned from the old owner to the new owner, the old owner can still control the car's operation," Miller says.”

There were several other items of interest to the identity community:

[More]

Kuppinger Cole — EIC 2012 Session: Exchanging Metadata through Different Federations on a Global Scale

In KuppingerCole Podcasts

Nicole Harris, Head of Identity Management, JISC Advance

April 19, 2012 15:40

Watch online

Kuppinger Cole — EIC 2012 Session: Federation or Synchronization – the Future of the Cloud

In KuppingerCole Podcasts

Andrew Nash, Google
Darran Rolls, SailPoint
Travis Spencer, Ping Identity

April 19, 2012 15:20

Watch online

Kuppinger Cole — EIC 2012 Session: What Federation is About – in Theory and in Practice

In KuppingerCole Podcasts

Dave Kearns, KuppingerCole

April 19, 2012 15:00

Watch online

Kuppinger Cole — EIC 2012 Session: Security for Virtualized Environments, Privileged Users and PCI Compliance

In KuppingerCole Podcasts

Guy Balzam, CA Technologies
Stephan Bohnengel, VMware
Giovanni Ciminari, Telecom Italia

April 19, 2012 14:30

Watch online

Kuppinger Cole — EIC 2012 Session: From Virtualization to the Cloud and Beyond

In KuppingerCole Podcasts

Craig Burton, KuppingerCole
Martin Kuppinger, KuppingerCole

April 19, 2012 14:00

Watch online

Kuppinger Cole — Intention and Attention – how Life Management Platforms can improve Marketing

In Martin Kuppinger

Life Management Platforms will be among the biggest things in IT within the next ten years. They are different from “Personal Data Stores” in the sense of adding what we call “apps” to the data stores and being able to work with different personal data stores. So they allow to securely working with personal data by using such apps which consume but not unveil that data – in contrast to a data store which just could provide or allow access to personal data. They thus are more active and will allow every one of us to deal with his personal data while enforcing privacy and security. Regarding “Personal Clouds”, that might be or become Life Management Platforms. However I struggle with that term given that it is used for so many different things. I thus prefer to avoid it. Both today’s personal data stores and personal clouds have a clear potential to evolve towards Life Management Platforms – let’s wait and see. I’ve recently written a report on Life Management Platforms, describing the basic concepts and looking at several aspects like business cases. This report is available for free.

The other big thing around this topic is the book “The Intention Economy”, written by Doc Searls. It is a must read and even while it mainly focuses on the relation between vendors and customers, there is a big overlap between what Doc has written there and what we at KuppingerCole expect to happen with Life Management Platforms.

Doc’s basic point is that the Intention Economy will change the relationship between vendors and customers. I like these two quotes:

„Relationships between customers and vendors will be voluntary and genuine, with loyalty anchored in mutual respect and concern, rather than coercion. So rather than „targeting“, „capturing“, „acquiring“, „managing“, „locking in“, and „owning“ customers, as if they were slaves or cattle, vendors will earn the respect of customers who are now free to bring far more to the market‘s table than the old vendor-based systems ever contemplated, much less allowed.“

„Likewise, rather than guessing what might get the attention of customers – or what might „drive“ them like cattle – vendors will respond to the actual intention of customers. Once customers‘ expressions of intent become abundant and clear, the range of economic interplay between supply and demand will widen, and its sum will increase. The result we will call the Intention Economy.“

„This new economy will outperform the Attention Economy that has shaped marketing and sales since the dawn of advertising.“

Yesterday I did a presentation at an event organized by doubleSlash, a German Consulting and Software Company focused on Sales and Marketing. The so called “slashTalk” had the title “After the Social Media Bang” and focused on what companies will have to do now. There were several marketing executives and experts from different companies in the room.

Before my presentation on Life Management Platforms there was another presentation which I found extremely interesting. Björn Eichstädt, founder and managing partner at Storymaker, a company which originally started as a PR agency, talked about his view on attention and why today’s marketing fails (in most cases). Björn has a degree in neurobiology, so he is far more than just a PR guy. He talked about “attention” and the small period of time within which you can catch someone’s attention. But it could be done, as with what today’s social networks provide. However, it isn’t easy today. On the other hand, providing what fits to the current target of attention is much more promising than trying to change the attention, like traditional marketing is doing.

Taking this view, the one of Doc Searls, and the idea of Life Management Platforms the way we at KuppingerCole have it in mind shows that this is where things become really interesting: A Life Management Platforms allows expressing your Intention. The Intention is nothing other than a vital part of where your current Attention is focused. In other words: Knowing the Intention is about knowing at least an important part of the current Attention, which is much better than trying to change the Attention. Furthermore, Life Management Platforms could provide more information about the current Attention in real-time, but in a controlled way – controlled by the individual. That allows getting even more targeted information and makes this concept extremely attractive for everybody – the vendors and the individuals.

Imagine a world in which you can allow others to provide you exactly that piece of information you are interested in. Let’s give an example:

Your profile on a social network might provide the information that you just arrived at the airport in a specific city. Some vendors might track this information and send you welcome messages, pointing to their local assistance, or other offerings. That could be done based on what today’s social networks provide. And this is nice if you receive only one message or offers which really suit your needs. But if you receive 20 messages from companies which detected that your attention might be on that, it is just annoying.

In a Life Management Platform you can control whom to inform about such a “social” event. That can be specific companies or industries. They know that someone arrived at the airport and needs some specific information, about directions, the next ATM, or the next public WLAN hotspot – or whatever else. The system provides that information to you and you use the service. This obviously is the better approach.

You might ask how this differs from typing “MUC ATM map” or “IAD WIFI” into a search engine? The fundamental difference is that the Life Management Platform can express your intention once it has learned about it – and you might have the same intention every time you arrive at an airport. It acts for you and consumes your preferences like for example the personal data about the mobile phone providers you have contracts with and you prefer for roaming or the banks you have accounts at to find the ATMs without additional fees or even without fees. Entering all that information into a search engine is annoying. And selecting the results in mind is annoying as well. So there is an obvious value even in that simple use case. And for sure you might not want to give all that information about your bank accounts away – you might want something (the app in Life Management Platforms) to act upon without unveiling that information. You might want minimal disclosure.

Life Management Platforms will enable that, amongst many other things. Given that they are a vehicle to fundamentally change the way marketing is done, moving from changing the attention to using attention and intention in a controlled and targeted way. Thus, everyone responsible for marketing should start looking at the ideas around Life Management Platforms, the Intention Economy, and Björn’s understanding of what Attention really is about. It is a simple way to get much better in Marketing and save money.

Kuppinger Cole — IIW and VRM Report

In Craig Burton

At the first of the month I attended IIW 14 in Mountain View. I also attended the VRM workshop on the 30^th. The VRM workshop was hosted by Ericsson. The IIW was held at the Computer History Museum.

Before I summarize what happened at those events, I want to give a little background on IIW.

IIW

IIW uses a format referred to as an “unconference.” The main purpose of an unconference is to avoid the traditional design of a conference. A way I have heard it described is the format developed by Harrison Owen. Legend has it that Owen noticed that during a conference, most of the real activity and deals were going on out in the hall during the breaks.

He questioned “why can’t we create a conference that works like being out in the hall all of the time?” IIW is more about that.

Here are the main operational points:

In the morning of the first day, everyone attending introduces themselves and tells all of the other attendees who they are, who they represent, why they are there and what they expect to get out of the conference.

After that, anyone is invited to create a session and a topic. Each person with a topic stands up and says what the topic is and the purpose of the session. Everyone then rushes to the open space scheduling wall and gets a particular space and time slot during the day. This is self-managed. Figure 1 shows a portion of the scheduling wall.

Figure 1: Open Session Scheduling Wall

Each time slot is 50 minutes long. Each session starts at the top of the hour. Anyone can attend any session they desire.

At the end of the day, the session leader—or someone that attended the session—gives a summary of the session. Session notes are to be emailed and posted on the IIW Wiki later.

In closing, there is an acknowledgement ceremony.

Figure 2: Acknowledgement Ceremony

In this ceremony, anyone is invited to stand up and acknowledge anyone else for anything that is relevant to the workshop. This is done by giving the person a choice of wine or chocolates. Figure 2 shows the acknowledgement ceremony and shows Doc Searls acknowledging someone.

Each day then follows the same format except that only new people who did not introduce themselves the first day are introduced.

VRM Day Overview

The entire day was discussing projects and products that are finally starting to use VRM as their underpinnings.

We also talked about Doc Searl’s new thinking about VRM. The best place to review that is by watching his presentation given at the KuppingerCole EIC 2012 conference.

Here were some of the topics discussed.

• Open API Economy
• FreedomBox
• Commercializing VRM
• Life Management Platforms
• Selling the first Vendors – Who Goes First
• VRM and CRM
• IntentCasting Networks – beyond the cliche: vertical use cases
• UI and UX for VRM, PDS, R-buttons, ToS, Cheese
• Personally Asserted Terms and Conditions
• Sovereign ID vs. Admin ID
• Customer Commons: Live!

IIW Overview

This year’s sessions were very diverse, but there were some consistent themes every day.

• VRM
• APIs
• Protocols
• Privacy
• Personal Data and Life Management Platforms

For a complete list of all of the sessions, you can look at the IIW wiki at http://iiw.idcommons.net/IIW_14_Notes

VRM

There were more VRM sessions this year than I have ever seen. I attribute this explosion of sessions to the release of Doc’s Book—The Intention Economy. Usually there was an entire day of VRM sessions every day of the workshop. On the first day, I attended almost all of the sessions. The VRM community is very broad and does not lean so much on Doc for its progress. Everyone was very excited about the book and the concepts there.

For a list of all of the sessions and some of the notes, see the VRM blog post about IIW. http://blogs.law.harvard.edu/vrm/2012/05/09/vrm-at-iiw/

In several of the sessions I focused on the link of the Open API Economy, the Life Management Platform and the roles of these two trends as they relate to VRM. From our opinion at KuppingerCole it is important to point out that VRM is much more than the counterpart to CRM and includes many more things that just e-commerce and shopping. People were very responsive to these perspectives.

Another cool result of all this is the new post that Doc Searls put up on the VRM Wiki adding and attributing KuppingerCole to the term Life Management Platform.

http://cyber.law.harvard.edu/projectvrm/Main_Page

APIs

There was much talk about APIs and Open APIs. The Open API Economy session was packed and generated great discussion.

The link to my Prezi used in the session is here.

http://prezi.com/rt07gxj02hf8/open-api-economy-ii/

Almost a thousand people (998) have viewed this presentation since the workshop – I’m really impressed.

Other API discussions were around OpenID Connect and SCIM.

Protocols

The three most active protocol discussions centered around OpenID Connect, SCIM and XDI. In addition, every discussion talking about any type of service, from privacy to personal data stores, talked about their status and intent to provide API access.

The Open API meme is clearly on fire and KuppingerCole is viewed as the thought leader around this topic.

The entire community is very excited about Open ID Connect and SCIM as they are protocols seen to solve serious problems, programmatic access to endpoints through the SAML namespace, and programmatic protocols for automated provisioning.

Privacy

There was a lot of discussion concerning privacy and the meaning of privacy. Scott David contributed significantly to this discussion with legal definitions and implications. The question kept coming up on how to build products that satisfy personal and legal privacy requirements across international boundaries. Especially since the requirements, laws and social conventions are not well defined. Again, KuppingerCole’s approach of Life Management Platforms provides some interesting thoughts (and maybe answers) on that.

Personal Data

Personal Data Stores, Personal Data Lockers, Personal Clouds, Freedom box and on and on.

The meme about Personal Data is very much on the move and in flux. Almost everyone who says they are working with Personal Data has a different notion of what it is and how it should work.

One of the presenters opened with a great joke from Steven Wright that is a useful analogy about personal data. It goes “I have a large seashell collection which I keep scattered on the beaches all over the world. Maybe you’ve seen it.”

One of the most fun and interesting personal data sessions was around the freedom box. Markus Sabadello managed this session.

http://blog.projectdanube.org/2012/05/freedombox-at-the-internet-identity-workshop/

This link gives a review of the session. He also brought up the Life Management Platform. He didn’t quite get it right, but I like it that the term is being inserted in the discussion. Life Management Platforms are much more than just data stores; there is much in it about how to ensure the secure and privacy-aware use of personal data – e.g. not just storing, but using them the right way and enabling new (and improved) forms of business.

Summary

IIW is well run and is mature and consistently meets it purpose of quality discussion and advancement of personal identity issues.

IIW 14 topics were spot on, fresh and informative.

The biggest complaint I have about IIW is that there are no notes posted for many of the sessions.

The VRM Workshop was well attended and reflects the interest shown at the KuppingerCole EIC 2012 conference.

Perhaps this year we will finally see some products that are VRM oriented.

Kantara Initiative — my Social Security – Citizen access to US Gov Services

Last week I attended the Experian Vision Conference. This conference is produced by Experian with attendance from their customers, partners and relying party services. It was a unique opportunity to speak to representatives who are stakeholders in trusted identity services communities – but not necessarily the same stakeholders that often in attend identity management specific events. Attendees were from sectors including but not limited to: risk, fraud, financial, credit, payments, and entertainment. Kantara was invited to contribute to a panel discussing Identity proofing using National Institute of Standards Technology (NIST) level 3 — strong authentication for the public and private sectors.

The panel was well received with many interested attendees who had insightful questions regarding the services coming on line, those that are already active and how compliance is verified to assure Trust. But perhaps one of the most interesting services we learned about was the recent announcement of a service from the US Social Security Administration (SSA) called “my Social Security” (read the SSA Press Release).

“my Social Security” service allows public citizens to create an account through SSA.gov which, upon verification, allows citizen access to earnings histories, social security statements and projected social security benefits upon retirement. What was even more exciting was that I was able to access the service and create a “my Social Security” account within approximately 5 minutes AND using an iPhone!

Here’s how it works
“To get a personalized online Statement, people age 18 and older must be able to provide information about themselves that matches information already on file with Social Security. In addition, Social Security uses Experian, an external authentication service provider, for additional verification. People must provide their identifying information and answer security questions in order to pass this verification. Social Security will not share a person’s Social Security number with Experian, but the identity check is an important part of this new, robust verification process.”

During the verification process I was asked to provide the last digits of a valid credit card. I decided to opt out of that mode and was provided with a number of alternate paths. I choose to verify using some values from my US Tax W-2 forms. The site also offers added security via one time pins sent to users via SMS. I encourage all US citizens/residents to try the service for your own experience.

While the press release indicates that the service is not perfect and some individuals may not be able to pass the Authentication questions, there are currently alternative means of verification via in-person proofing at a local SSA office. Trusted identity services linking citizens to government services still has a long way to go in terms of offerings and adoption, however this service is at the forefront of providing US citizens a view and access in to their benefits via US Gov services and an indicator of the exciting developments to come for trusted and verified Identity Ecosystems.

Relating to these activities I will note that, Experian is a member of the Kantara Initiative and currently has an application registered for Kantara Credential Service Provider Service Approval at Level of Assurance 3 non-crypto for a service they are offering which, once approved, would be listed in the US Federal Identity Credential Access Management (ICAM) Trust Framework which has adopted the Kantara Identity Accreditation and Approval Program based on the Identity Assurance Framework (IAF) as one of the US Gov Approved Trust Framework Providers. We at Kantara look forward to continuing development of the Trust Framework model with the US Government, Experian and all of our public and private sector members.

Andreas Åkre Solberg - Feide/UNINETT — OAuth 2.0 Providers and State

It seems there is a bunch of OAuth 2.0 providers that does not support the (required to be supported) state parameter.

I just updated the jso library to be able to deal with that.

When you are unable to keep state, you’ll run into at least two challenges:

• you don’t know from who the access token is sent (if you accept multiple providers on the same callback)
• you don’t know what scopes you sent in the request. It would be natural to fallback to this scope in your token cache, if scopes were not provided in the response. Now, instead, you need to configure global scope fallbacks.

The jso documentation is updated, on how to deal with this.

Kuppinger Cole — EIC 2012 Session: API Economy - The Provider View

In KuppingerCole Podcasts

Dr. Steven Willmott, 3Scale
April 19, 2012 12:10

Watch online

Kuppinger Cole — EIC 2012 Session: API Economy - The Consumer View

In KuppingerCole Podcasts

Fulup Ar Foll, KuppingerCole
April 19, 2012 11:50

Watch online

Kuppinger Cole — EIC 2012 Session: How the API Economy Leverages our Capabilities for Delivering Business Services

In KuppingerCole Podcasts

Craig Burton, KuppingerCole
Kim Cameron, Microsoft
Martin Kuppinger, KuppingerCole

April 19, 2012 11:30

Watch online

Kuppinger Cole — EIC 2012 Session: VRM and the Intention Economy - Now What?

In KuppingerCole Podcasts

Craig Burton, KuppingerCole
Scott David, K&L Gates LLP
Marcel van Galen, Qiy
Drummond Reed, Connect.Me
Doc Searls, Berkman Center for Internet and Society
Phil Windley, Kynetx

April 19, 2012 10:30

Watch online

Mike Jones - Microsoft — JSON Crypto Specs Draft -02: JWS, JWE, JWK, JWA and JSON Web Token (JWT) Draft -10

JSON Crypto Specs Draft -02: JWS, JWE, JWK, JWA and JSON Web Token (JWT) Draft -10

New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working group decisions made since the previous versions, including decisions made at IETF 83 in Paris and in follow-up discussions on the JOSE working group list. The drafts contain numerous clarifications, refinements, and editorial improvements. They are:

• JSON Web Signature (JWS) – Digital signature/HMAC specification
• JSON Web Encryption (JWE) – Encryption specification
• JSON Web Key (JWK) – Public key specification
• JSON Web Algorithms (JWA) – Algorithms and identifiers specification

Also, Draft -10 of the JSON Web Token (JWT) specification has been published. It uses the -02 versions of the JOSE specifications and contains parallel editorial changes to those applied to the JOSE specs.

These specifications are available at:

• http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02
• http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02
• http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02
• http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02
• http://tools.ietf.org/html/draft-jones-json-web-token-10

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02:

• Clarified that it is an error when a kid value is included and no matching key is found.
• Removed assumption that kid (key ID) can only refer to an asymmetric key.
• Clarified that JWSs with duplicate Header Parameter Names MUST be rejected.
• Clarified the relationship between typ header parameter values and MIME types.
• Registered application/jws MIME type and “JWS” typ header parameter value.
• Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
• Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
• Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
• Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
• Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02:

• When using AEAD algorithms (such as AES GCM), use the “additional authenticated data” parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting “authentication tag” value as the JWE Integrity Value.
• Defined KDF output key sizes.
• Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
• Changed compression algorithm from gzip to DEFLATE.
• Clarified that it is an error when a kid value is included and no matching key is found.
• Clarified that JWEs with duplicate Header Parameter Names MUST be rejected.
• Clarified the relationship between typ header parameter values and MIME types.
• Registered application/jwe MIME type and “JWE” typ header parameter value.
• Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the header parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
• Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
• Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
• Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
• Reformatted to give each header parameter its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02:

• Simplified JWK terminology to get replace the “JWK Key Object” and “JWK Container Object” terms with simply “JSON Web Key (JWK)” and “JSON Web Key Set (JWK Set)” and to eliminate potential confusion between single keys and sets of keys. As part of this change, the top-level member name for a set of keys was changed from jwk to keys.
• Clarified that values with duplicate member names MUST be rejected.
• Established JSON Web Key Set Parameters registry.
• Explicitly listed non-goals in the introduction.
• Moved algorithm-specific definitions from JWK to JWA.
• Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02:

• For AES GCM, use the “additional authenticated data” parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting “authentication tag” value as the JWE Integrity Value.
• Defined minimum required key sizes for algorithms without specified key sizes.
• Defined KDF output key sizes.
• Specified the use of PKCS #5 padding with AES-CBC.
• Generalized text to allow key agreement to be employed as an alternative to key wrapping or key encryption.
• Clarified that ECDH-ES is a key agreement algorithm.
• Required implementation of AES-128-KW and AES-256-KW.
• Removed the use of A128GCM and A256GCM for key wrapping.
• Removed A512KW since it turns out that it’s not a standard algorithm.
• Clarified the relationship between typ header parameter values and MIME types.
• Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
• Established registries: JSON Web Signature and Encryption Header Parameters, JSON Web Signature and Encryption Algorithms, JSON Web Signature and Encryption “typ” Values, JSON Web Key Parameters, and JSON Web Key Algorithm Families.
• Moved algorithm-specific definitions from JWK to JWA.
• Reformatted to give each member definition its own section heading.

http://tools.ietf.org/html/draft-jones-json-web-token-10:

• Clarified the relationship between typ header parameter values, typ claim values, and MIME types.
• Clarified that JWTs with duplicate Header Parameter Names or Duplicate Claim names MUST be rejected.
• Required implementation of AES-128-KW and AES-256-KW when the implementation provides encryption capabilities.
• Registered “JWT” typ header parameter value.
• Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
• Reformatted to give each claim definition and header parameter its own section heading.

HTML formatted versions are available at:

• http://self-issued.info/docs/draft-ietf-jose-json-web-signature-02.html
• http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-02.html
• http://self-issued.info/docs/draft-ietf-jose-json-web-key-02.html
• http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-02.html
• http://self-issued.info/docs/draft-jones-json-web-token-10.html

IDMGOV — Level of Confidence of What, When, Where and Who?

Last week's blog post by Dr. Peter Alterman on "Why LOA for Attributes Don’t Really Exist" has generated a good bit of conversation on this topic within FICAM working groups, in the Twitter-verse (@Steve_Lockstep, @independentid, @TimW2JIG, @dak3...) and in may other places.  I also wanted to call out the recent release of the Kantara Initiative's "Attribute Management Discussion Group - Final Report and Recommendations" (via @IDMachines) as being relevant to this conversation as well.

One challenge with this type of discussion is to make sure that at a specific point in the conversation, we are all discussing the same topic from the same perspective. So before attempting to go further, I wanted to put together a simple framework, and hopefully a common frame of reference, to hang this discussion on:

"What"	Separate out the discussion on Attribute Providers from the discussion on individual Attributes Separate out the discussion on making a decision (to trust/rely-upon/use) based on inputs provided vs making a decision (to trust/rely-upon/use) based on a "score" that has been provided
"When" (to trust/rely-upon/use)	"Design time" and "Run time"
"Where"	Where is the calculation done (local or remote)? Where is the decision (to trust/rely-upon/use) done?
"Who"	Party relying on attributes to make a calculation, a decision and/or use in a transaction Provider, aggregator and/or re-seller of attributes Value added service that takes in attributes and other information to provide results/judgements/scores based on those inputs

:- by Anil John

CA on Security Management — Defend against APT attacks from the inside out

NPR's morning edition had a segment titled "Cybersecurity Firms Ditch Defense, Learn To ‘Hunt." The focus of the piece is on attacks from China that look to gain intellectual property and other trade secrets from specifically-targeted Western firms.  This type of attack is called an Advanced Persistent Threat (APT). There is little doubt that APTs are a growing problem;...

 

Johannes Ernst - NetMesh — Personal Clouds mailing list

From the list overview: Cloud computing today typically means that we have to hand over our data to big companies who decide which features they give us (and sometimes force on us), and who can and do unilaterally change their terms of service on us whenever they like. What if instead, we could each have [...]

Radovan Semančík - nLight — The Law of Two Years

I see evidence in favor of this all the time. My colleagues that works on variety of projects and with quite a wild assortment of products are also agreeing that it holds. It looks like this might be a law:

No matter what it is, no matter how big it is, no matter how many people works on it, it always takes at least two years to create a working software product.

Kuppinger Cole — EIC 2012 Session: IT Strategies and Information Security in Banks - The Regulator´s View

In KuppingerCole Podcasts

Dr. Markus Held, Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin)
April 18, 2012 11:30

Watch online

Kuppinger Cole — Entitlement Management – has it really been an academic exercise?

In Martin Kuppinger

Recently I read a blog post from my appreciated and well known analyst colleague Kevin Kampman at Gartner Group talking about entitlement management. That post had some points which made me wonder. I’ll pick some of the quotes:

1. “One of access control’s biggest challenges is that it has often been an academic exercise. Maybe we can move the discussion forward by thinking about what is needed, not just what is possible.”
2.  “For any object, a set of conditions should be met to provide access such as time, attribute, role, etc. it seems we need a more flexible way to characterize all of the conditions that need to be met for access to be granted. Not attributes about the object itself but what you need to bring to the party to play.”
3.  “A lot of the focus in the *-BAC world is what attributes IT can provide to represent these conditions. It might make more sense to describe the conditions needed to characterize access.”

There are more, but these are some which I feel the need to comment on. Let’s start with the first one. I would agree that role management in its early days, when it first became mainstream, sometimes really was too much of an academic exercise. But if I look at the reality of projects today, that’s no longer the case. Role management is well understood and there is a lot of knowledge available on how to successfully implement role management in practice.

Going further to what dominates the evolution of Entitlement Management today, we have to look at Dynamic Authorization Management. Here neither the evolution of XACML as the key standard nor of claims as a related and somewhat overlapping approach is driven by theorists. Furthermore, most of the products in the Dynamic Authorization Management market like the ones of CA Technologies, CrossIdeas, IBM, or Oracle are derived from projects and the customer needs therein. They were built for practitioners from the very beginning. Even while they might not be perfect yet, they definitely are not the result of academic exercises. Consider also that Axiomatics, which started with strong focus on the XACML standard (and is one of the most active supporters of defining the XACML standard) is strongly led by customer feedback and experience from real world implementation projects.

My perspective is that the biggest challenge for Entitlement Management today is the organizational and process maturity of the customers, when it comes to defining business roles and business rules and when it concerns identifying the players in the business organization which have to participate. IT has become better in supporting IT business/alignment but still has some work to do on that especially with simple interfaces for defining business rules in Dynamic Authorization Management products and further improving the business interface of Access Governance tools. But this again is not the result of being too academic.

Regarding the second aspect: Despite the criticism I sometimes have articulated regarding XACML as being a standard which is too complex for the end users (which I still believe is true), the underlying concept of implementing business rules is simple. Yes, it is annoying to write XACML, but that is true for any type of XML. Still, any business user can easily define the rules in a structure that can be used by XACML – this is straightforward and simple to understand.

And in that concept (and other approaches for Dynamic Authorization Management) it is very simple to express the full variety of rules, from more technical ones to pure business rules using business-provided constraints or competencies. This is focused on objects – but the objects can again be anything, from a piece of information (like a document) or its representation (like a share) to business activities within business processes. This is all there – so it is fairly simple to use it. And the same concepts can be used for all types of use cases. You can rely on a subset of the same set of policies for versatile, context-based authentication and authorization (which again provides attributes for other decisions) and for the internal authorization in a business application which needs to enforce complex business rules such as for the approval of new insurance contracts.

Having said this, we arrive at the third quote. Don’t we describe the conditions today? I’d say we can do it and we frequently do it, not only within Dynamic Authorization Management but also in more advanced concepts around Access Governance . These concepts go beyond roles today and can use concepts of constraints or competencies. Some implementations are tightly coupled with business activities and business processes.

By the way: Introducing a term of *-BAC doesn’t seem to provide much value to the customer. We have RBAC (which, in the NIST approach, is somewhat academic – but not in real world). We have used the term ABAC (Attribute Based Access Control) sometimes in the industry, with attributes describing any attribute which can be used within policies, including roles as a specific type of attribute. So ABAC covers everything and *-BAC only leads to babel.

Simply said: My view on the state of Entitlement Management, Access Governance, and Dynamic Authorization Management is fundamentally different from the one in that other blog post mentioned above. It think that the industry is much more mature. And not too academic.

 

Kuppinger Cole — EIC 2012 Session: Access Governance Case Study - Friends Life Realizes Quick Time To Value

In KuppingerCole Podcasts

Julia Bernal, Group Business Security & Data Protection Manager, Friends Life
April 18, 2012 17:30

Watch online

Kuppinger Cole — EIC 2012 Session: Identity & Access Management as a Key Element for a Value focused Security Strategy

In KuppingerCole Podcasts

Ralf Knöringer, Atos IT Solutions and Services GmbH
Hassan Maad, Evidian
Shirief Nosseir, CA Technologies
Christian Patrascu, Oracle
Peter Weierich, iC Consult GmbH

April 18, 2012 17:00

Watch online

Kuppinger Cole — EIC 2012 Session: How to successfully get business to participate in IAM and Access Governance

In KuppingerCole Podcasts

Dr. Martin Kuhlmann, Omada
Edwin van der Wal, Everett

April 18, 2012 15:30

Watch online

Kuppinger Cole — EIC 2012 Session: Delivering Actionable Recommendations to Senior Management based on a Structured Risk Identification and Evaluation Process

In KuppingerCole Podcasts

Dr. Waldemar Grudzien, Association of German Banks
Berthold Kerl, Deutsche Bank AG
Prof. Dr. Sachar Paulus, KuppingerCole

April 18, 2012 15:00

Watch online

Kuppinger Cole — EIC 2012 Session: Munich Re’s Identity & Access Management - Experience Report and Best Practices

In KuppingerCole Podcasts

Wolfgang Zwerch, MunichRe
April 18, 2012 14:30

Watch online

Kuppinger Cole — EIC 2012 Session: IAM Governance in the New Commerzbank

In KuppingerCole Podcasts

Dirk Venzke, Director, Commerzbank AG
April 18, 2012 14:00

Watch online

Kuppinger Cole — EIC 2012 Session: How to Address Regulatory Needs Fast and Lean

In KuppingerCole Podcasts

Dr. Waldemar Grudzien, Association of German Banks
Dirk Venzke, Commerzbank AG
Dr. Horst Walther, Kuppinger Cole
Wolfgang Zwerch, MunichRe

April 18, 2012 12:00

Watch online

Kuppinger Cole — EIC 2012 Session: Facing the Online Threats against Retail and Banking Customers - What are the Future Perspectives?

In KuppingerCole Podcasts

Prof. Dr. Sachar Paulus, Senior Analyst, KuppingerCole
April 18, 2012 11:00

Watch online

Kuppinger Cole — EIC 2012 Session: Cyber Crime, Cloud, Social Media... - IS Threats for Banks are Constantly Increasing. What Should We Be Doing?

In KuppingerCole Podcasts

Berthold Kerl, Deutsche Bank AG
April 18, 2012 10:30

Watch online

Matt Flynn - NetVision — Access Governance on Unstructured Data

Gartner research VP Earl Perkins posted a few days ago on the intersection of data and applications within IAG (Identity and Access Governance). I've certainly seen the same issues and we've been working with customers on these challenges quite a bit over the past six months. In fact, I authored a paper on the topic in April which is available in the STEALTHbits resource library titled Access Governance on Unstructured Data.

I hinted at the paper back in February and it was clear from the response I got that many are not willing to acknowledge a shift from the era of Identity Management to the era of Access Governance. But, I still see our current Access Governance efforts (as an industry) as analogous to what we did about a decade ago for Identity Management. Obviously, the industry remains dynamic and there's overlap but I think we have a pretty good handle on managing accounts while we're still working on the best ways to provide governance over access (whether to applications or data).

In my own phrasing (and ignoring structured and semi-structured data for the moment), the issue Earl addresses is, essentially that traditional IAM and IAG solutions are application-centric but a significant portion of enterprise data is unstructured (many estimates indicate that 80% of data is unstructured) rather than accessed and controlled via applications. IAG vendors are struggling with getting their arms around data as it sits out in the environment. And it's a hard problem.

I've been a part of two software vendors who addressed access rights to unstructured data. Neither company nailed it in the first attempt and there were challenges along the way. I've spoken with three large companies who tried to build in-house solutions for themselves. All failed and eventually sought commercial solutions. And I've spoken to IAG vendors who struggle with unstructured data solutions - even having tried popular brand name commercial solutions with unsatisfactory results. In my paper, I point out many of the challenges (platform coverage, geography, scalability, deployment, etc.) and how we've addressed them.

The one item that I'd differ on in Earl's post is that he mentions IAG vendors as looking to partner with SIEM and/or DLP solutions to address the issue. I don't think either is a good fit. SIEM is obviously event-driven and relies on logs. It may answer a piece of the question but it's not a direct fit. Even where it does provide value (who is doing what), it's data is limited to what shows up in logs, which isn't ideal for this scenario and doesn't generally enable context-based filtering.

And DLP may get much of the right information but the folks I've talked to describe it as overkill (too expensive and too difficult to deploy). Where DLP seems to shine is in the actual prevention (blocking action at the end-point or at the firewall). But for a quick, efficient scan of access rights and the ability to analyze high-risk conditions, I'm not sure you can bend DLP solutions to do what you need.

I'd love to discuss more with anyone interested. Let me know. I can also get you a copy of the paper. It's short and to-the-point, but is a good conversation starter.

Phil Windley - Kynetx — Unlocking Data Exchange: The Long Tail of Data

Much has been made of data lately. And with good reason. Data and the ability to exchange and process it are at the heart of modern society's productivity and prosperity. Data and algorithms are the engines that drive the economy in the 21st century.

But data is often onerous to obtain, difficult to trust, and hard to understand. Fixing these problems—making trustworthy, understandable data flow more freely, consistently, and reliably—will provide a wellspring of new ideas and companies to prosecute them.

This post makes a case that there is a structural problem standing in the way freely flowing data and describes a method for removing that structural barrier.

The Long Tail

In October 2004, Chris Anderson introduced the concept of the long tail in an article in Wired magazine. The idea, simply put is that the infinite shelf space and near-zero distribution costs brought about by the Web have revolutionized many businesses by allowing them to compete for business that was formerly too expensive to service.

The concept is called the long tail because if you plot the power law distribution of the relevant data (e.g. revenue from sales of a given book title, song title, airline ticket to a particular destination, and so on) there's always a cut off point where it gets too expensive to service the business using traditional business models. Here's one of the charts from the Wired article:

Notice that in the example shown there is a line on the curve and to the left of that line the words "Songs available at WalMart and Rhapsody". The area under the curve to the left of the cut line is the head of the curve. The area under the curve to the right of the cut—the yellow sections—is the tail and since it's long when you have infinite shelf space, it's the long tail. The area in the long tail is the revenue available to Rhapsody but not to WalMart.

The important point is that Amazon, Rhapsody, and Netflix, to use the examples in the graph, can sell all the same product as their competitors as well as product their competitors can't. A brick and mortar book store can't stock every book, but Amazon can. In many cases the area—and thus the available revenue—of the tail is larger than the area in the head.

The Long Tail of Consumer Credit

In credit markets, the kings of the long tail are Visa and Mastercard. You need credit to make a purchase. Before credit cards, you would have made a deal with the local merchant to extend credit, or in the case of a large purchase, taken out a consumer loan at the bank (my parents used to do this). Now, we just put it on the card.

The credit card, largely developed in the 1950s and 1960s represents a huge leap forward in thinking about how credit is extended. Some companies, like Diner's club and American Express developed a credit system that was based on each merchant and consumer having a direct relationship with the credit card company. Many banks did the same thing. In contrast, Visa and the Mastercard established credit networks. The following diagram depicts the relationships in the credit network.

In a credit network, both the customer and merchant have a relationship with their respective bank and their banks have relationships with the Visa network.

Table 1: Comparing Credit

	Without Credit Network	With Credit Network
Relationship	one-to-one	any-to-any
Credit Terms	per-loan	on demand
Penetration	select merchants	ubiquitous
Processing cost	expensive	cheap

Table 1 shows a few of the differences between credit before and after credit cards:

• Relationship—before credit networks, credit was extended on a one-to-one basis. You made a credit arrangement with each lender. With credit cards, the arrangement is any-to-any, you can walk into almost any merchant on earth and use credit with no need for a prior relationship. Moreover, in the networked model, both customer and merchant have relationships with independent banks. Any bank will do, so long as they're a member of the network.
• Credit terms—before credit networks, credit was done on a per-loan basis. When you needed credit, you filled out the forms for a particular credit transaction. The next week you might do it all again for another. With credit networks, you get credit on demand, in real-time
• Penetration—before credit networks, you had to select merchants based on what cards they accepted. This was frustrating to merchants and customers alike. With a credit network, even though there are still many cards, they are interoperable with any merchant, making their penetration nearly ubiquitous.
• Processing cost—without credit networks each transaction has to be negotiated and approved individually and, often manually. With a credit network transactions costs are greatly reduced through standardized contracts and automatic approval and settlement.

These attributes are what give credit networks their long tail potential. Credit transactions of all sorts are available to a wider range of people for a wider range of goods and services from a wider range of merchants.

The Credit Network

We call Visa a "network" but that label may be confusing to people who think of networks in terms of routers and data connections. In fact Visa is two things (yes, I'm simplifying a great deal here):

1. A collection of contracts
2. A protocol

Notice there are no wires. The wires are provided by companies like First Data Corp. who actually do the processing according to the terms of Visa's contracts and protocol. Nevertheless, a network it is because it links countless people and merchants via their banks through the mechanisms of contracts and protocols.

The magic of Visa is the realization that each bank didn't need a contract with every merchant and every customer or even a contract with every other bank. That's why Visa is a "network." Visa has contracts with each bank, the banks have contracts with customers and merchants and the chain of contracts from a customer, to her bank, to Visa, to another bank, and finally to the merchant is sufficient to convince the merchant that she will be paid when she walks in a buy a new pair of shoes. Every time you use your credit card, you exercise a different path through those chains of trust. Visa is thus a trust framework.

By establishing a network that was

1. any-to-any,
2. on demand,
3. ubiquitous, and
4. cheap,

Visa was able to create a system that services the long tail of credit. Almost any transaction, almost anywhere can be handled by their network for pennies on the dollar.

Data Exchange Networks

The world of data exchange looks, in many ways, like the world of credit before Visa. Companies like Acxiom, D&B, Experian, and Lexis-Nexis sell data on a one-to-one basis, according to pre-executed contracts, in batch. And it's not cheap. These are companies who have built profitable businesses servicing the head of the curve. But they don't service the long tail. They can't, because they don't have a network.

Imagine you want to start a business that needs access to risk data (i.e. data about the trustworthiness of a business or person). First, you'll have to go through the sales process where you'll be screened to ensure you can sign a contract that has a monthly minimum (say $5000/month), then you'll have to go through legal to get contracts in place, finally you'll agree to the format for your batch of data and integrate your systems with those of the data company. Of course, you'll pay more if you need data more frequently than the norm.

If you only need a little data, or data on demand, or from different sources depending on the transaction, you don't fit in the head of the curve. How many startups don't get built because their business model needs, but can't afford, access to data? How many startups don't get built because they can't make data available cheaply? These are lost opportunities that need a new model if they're to be realized.

A data network solves this problem in exactly the same way that the Visa network solves the credit problem. By putting contracts in place up front and building a trust framework upon those contracts, a data network allows cheap, ubiquitous, on demand, any-to-any access to data.

Drummond Reed has built a company around this very idea, called Respect Network Corp (RNC). The idea is that like Visa or Mastercard, RNC will use standardized contracts to create relationships with data providers and data consumers. Protocols will describe how data transactions are initiated, negotiated, and consummated. Payment will be based on the value of the data but is likely made outside the data network on an existing payment network since they're optimized for that. As an aside, if you look at RNC's business model, you'll see a slightly different version of this based not on raw data transfers as I've described here, but more long-term relationships between merchants and their customers.

Kynetx is working closely with RNC in building the network. The model and legal framework are fairly well understood. What is less well defined at this point is the nature of the data exchange protocols. Our recent white paper, From Personal Computers to Personal Clouds, outlines what we think the nodes in the network will be like. The network itself must provide services to these nodes so that they can interact efficiently and safely. Specifically, the network must provide the following services:

• Reputation—in any-to-any interactions, players will frequently do business with nodes in the network with whom they don't have a pre-existing relationship. In the credit network, this function is performed by the banks who issue merchant accounts and by fraud algorithms that try to detect bad actors. In a data network, anyone, even the customer, might be a data provider, so a reputation system can remove some of the risk in knowing who is providing reliable data.
• Discovery—finding the data provider who has the data you want at a price you're willing to pay is tough job without some help. The network will provide discovery services to aid in this task.
• Semantic Mapping—the individual nodes in the network provide semantic data interchange, but for that to work, they need semantic maps (e.g. ontologies) that have been agreed to by participants in the network.
• Brokerage—the network facilitates payment, probably through an existing credit network. The network also facilitates setting up subscriptions to data services by passing channel details from publisher to subscriber when the relationship is established.

Building this network is a tall order compared to building credit networks. Financial transactions, for example, have simple semantics compared to data transactions. A few well-established protocols suffice for authorizing and settling credit transactions. In contrast, data transactions may need multiple protocols depending on the exact exchange, even with semantic data interchange in place. Nevertheless, such a network would open up the long tail of data transactions for dozens, even hundreds of companies in the same way that the Web opened up the long tail to ecommerce companies.

The good news is that in the second decade of the 21st century, we're ready to take on this task. The Web provides a foundation for transport and recent advances in the understanding of APIs and data interchange have prepared countless developers and companies to work in this new world. The technologies and systems described in From Personal Computers to Personal Clouds including the Event eXchange Protocol (EXP), Kinetic Rule Language (KRL), and XRI Data Interchange (XDI) are the key components in building this network. The legal framework being put in place by Respect Network Corp provides the glue that binds them together.

Public and Private

There may be some reading this who have grave misgivings about what I've described because it envisions a private, rather than public, data network. I believe that this network has to be, at least partially, private for the same reasons that no one has ever created a public credit network to rival Visa and Mastercard. The primary reason is trust.

The protocols that underlie the network I've described are all public or open source and thus available to anyone. What can't be open source is the legal framework that engenders that trust. There will necessarily be an organization that is the foundation of those contracts. While there may be several of these data interchange networks over the next few years, I believe this will likely devolve to duopoly as most other quasi-public utilities seem to do.

Unlocking Data Interchange

The network I've described in this paper solves a structural problem in data interchange that limits current business models to one-to-one, heavyweight relationships. Building an open data interchange network underneath a trust umbrella, enables new business models to thrive by reducing the friction and expense through lightweight, any-to-any interactions.

Kuppinger Cole — Preventing, or surviving, data leaks

In Dave Kearns

Just last week it was reported in The Guardian that “Computer hackers have managed to breach some of the top secret systems within the [UK] Ministry of Defence.” If the department charged with protecting the country can’t protect its own secrets then what chance does your organization have?

This is just the latest (at the time I’m writing this) in a seemingly ever escalating number of security breaches, data thefts and data losses. So much so, in fact, that Data Loss Prevention (DLP – also called Data Leak Prevention) is the fastest growing segment of the Security, Identity and Access Management (SIAM) market. Multiple press releases cross my desk every week touting the latest and greatest apps and services to protect your sensitive, privileged, and proprietary data as well as the Personally Identifiable Information (PII) of your employees, customers, vendors and partners – the data that begins the path to so-called Identity Theft.

So with so much DLP software available, why is there still a problem with data loss/leakage – and why are organizations seemingly so surprised when it occurs?

To me, one telling point is that almost all DLP packages include audit modules. The main purpose of these audit modules (other than to satisfy some compliance directive from government (e.g., HIPAA) or other organization (e. g., PCI)) is to let you know that a data loss/leak has occurred! It’s like having a sensor outside the barn that emails you with the message “By the way, the horses just got out through that unlocked barn door.”

So is there any hope?

The short answer is “no, not the way we’re doing things today.”

Early DLP software concentrated on border protection and intruder detection. The idea was that individual hackers were constantly probing your network looking for “barn doors” that weren’t locked. It was assumed that these hackers had no definite target in mind, but simply tested for easy targets. If your “door” was harder to get through than another organization’s, then they’d go to that one and leave you alone.

But the attackers have changed. The Guardian story cited above notes “China and Russia have been accused of being behind most of the sophisticated cyber-attacks, with state-sponsored hackers targeting military secrets from western governments, or intellectual property from British and American defence firms.” Additionally, organized cybercrime gangs (the so-called “Digital Mafia”) have been cited as constantly attempting to penetrate systems to obtain data for financial gain. Individual hackers have fallen far down the list of potential threats.

The DLP vendors have tried to keep up with the ever more sophisticated penetration attacks, and do a good job. But even if they can block 99.99% of penetration attempts, how many get through? It’s hard to find data, but one blogger tracked intrusion attempts a few years ago and noted 2556 in a two week period. This is not a high value target, yet even using the best available DLP products this site would still get penetrated once every 8 weeks, 6-7 times per year. A major corporation or government entity could see hundreds, even thousands times the number of attacks with a concomitant number of successful ones.

And that’s just one threat vector.

Borders, fences, firewalls, and the like are intended to protect your data from outsiders who have no legitimate right to it. But what about insiders? What about those who have the right to view and manipulate the data as part of their job?

Recently in South Carolina an employee of the state Medicaid program (a health program for certain people and families with low incomes and resources) was charged with collecting PII (Names, addresses, phone numbers, and Social Security numbers, which also double as Medicaid ID numbers) of over 200,000 clients and transferring it to his personal storage via email. This was done in small pieces over the course of several months. The employee had a legitimate right to access the data as individual records – he just amalgamated these records over time!

Many current DLP packages will monitor outgoing data (email, web postings, social networks, etc.) to see if privileged or protected data (or PII) is leaving the organization and alerting security personnel. This can minimize the data loss/leakage, but not eliminate it. In the best case scenario the data can be recovered before damage is done.

But, of course, not all insider data leakage is caused by rogue employees.

In the now classic case of RSA Security, data was stolen that allowed the hackers (believed to be state sponsored) to foil the vaunted (and ubiquitous) SecureID hardware tokens from the company. These hackers didn’t find an open door, nor did they obtain a willing accomplice on the inside. Rather, they used sophisticated phishing techniques to persuade one user to open an attachment to an email, which installed a backdoor Trojan allowing these criminals to get into the system, pose as legitimate users, and get the data they came looking for. Yes, audit software discovered the breach. But that horse was already out of the barn, in the wild and doing damage. It’s generally believed that attacks on a number of defense contractors later resulted from this breach.

And that still doesn’t cover all the possibilities.

We still read about lost laptops, notebooks and tablets; mislaid (or stolen) USB drives (it used to be floppy disks); unwiped hard drives getting recycled – all with proprietary or personal data on them. No intruder detection system, data monitoring system or any number of audit logs are going to let you know that this has occurred.

So what should you do – short of throwing up your hands and simply releasing all of your own data before someone else does?

You need a plan. Today’s DLP software should be a part of it, of course, but you need more. You need to be prepared, now, for what will happen when the data leakage occurs. Too often, when the worst happens, the organization that lost data sends out a spokesperson, who looks like a deer trapped in the headlights with no ready answers as to how they are going to cope with the disaster that’s befallen them.

Most large organizations – commercial entities, governments, university systems and the like – have well-developed disaster recovery plans. They know exactly what they’ll do in case of fire, flood, insurrection, or other disruptions to their normal flow of business. Few, if any, though, have plans to deal with the devastating disaster that data leakage and data loss can be. How devastating? Just ask the folks at VASCO Data Security. When their subsidiary, Diginotar (a Dutch security Certificate Authority), was breached and fraudulent certificates issued it was first taken over by the government and then declared bankrupt.

The reality is that you need a three-pronged approach to protect your data, determine if it’s been leaked and react promptly, efficiently and appropriately when the leak occurs. I call these three DLP, DLD and DLR.

• DLP – Data Leak Protection, which includes data encryption, firewalls, intruder detection systems and the like. These systems are designed to thwart intruders and can do a good job of that. Additionally, these systems can protect data that is inadvertently sent “into the wild” (lost, stolen or strayed computers and drives).
• DLD – Data Leak Detection; when DLP fails, this part of the solution will let you know. DLD is also the area where you monitor legitimate users (employees, contractors, vendors, partners, clients, etc.) to discover criminal behavior or fraudulent account usage. DLD systems can also be configured to trigger automatic responses shutting down the avenue through which data is leaking.
• DLR – Data Leak Resilience, or how to recover and bounce back from data leaks. In essence, this is a disaster recovery plan for data leaks and includes hardware and/or software modifications (to thwart the leak vector), notification protocols (to inform data owners or regulatory authorities as well as the press) and recovery methods (to, as much as possible, restore the situation as it existed pre-leak).

Many call this three-pronged approach Data Loss Mitigation (although at least one of my colleagues abhors the term) and I’ll stick with it for now (but your suggestions are welcome).

In any event, you need to work on the DLR portion; you need that disaster recovery plan for data leakage – so get to work on it now.

Paul Madsen — Over simplified graphical representation of OpenID Connect

CA on Security Management — CA ControlMinder Meets SAP Requirements

The CA Security team is pleased to announce that SAP has determined that CA ControlMinder meets its requirements for mission-critical customer SAP Linux environments and will fully support its own components in a Linux/CA environment. Further details can be found on the SAP support website (registration required) For further information on how CA solutions can help improve SAP security, please...

 

Marc Canter - Broadband Mechanics — An ecosystem – in Prezi

For your interactive pleasure:

Marc Canter - Broadband Mechanics — Digital City ["insert your city or region here"]

The Digital City ["insert your city or region here"] pilot project would create and maintain a series of “New Economy Apprenticeships” which would lead to a “digital economy ecosystem” in ["insert your city or region here"].  This pilot project would implement a new kind of workforce training methodology which would tie intermediate and advanced training to new economy apprenticeships, project participation and job creation.

Interns would be put to work on one-off and on-going projects, which would be paid for by local “socially conscious” sponsorships.  Entrepreneurial activities, an on-line marketplace and a video business directory would all help support and nurture this “ecosystem effect.”  The measurable results of the pilot project would be to prove that by breaking down the silos and connecting various government and business efforts together – an integrated ecosystem effect can be kickstarted which would lead to a sustainable engine that creates on-line jobs.  This ecosystem would sit on top of an open software platform and become a on-going means of on-line job creation.

The focus of the pilot would be on creating on-line jobs and teaching trainees the skills necessary to exist in a global marketplace of project based on-line workers.  Individuals entrepreneurism, rather than company based – will be the emphasis of this project.  The ["insert your city or region here"] training system would pick up where beginning computer skills classes leave off; placing trainees and interns into active projects, paired up with professionals and college educated workers.

These project teams would then produce work-for-hire sponsored projects, ranging from mobile and PC based content to educational software, visualizations and simulations.  Sponsored viral marketing campaigns (via custom produced games and apps) would focus on Barbados history, culture and people.  On-line startups and entrepreneurial activities would be supported by the pilot project, as well as a wide range of community engagement.  By directly showing community members and organizations the benefits and rewards possible by utilizing on-line social media based tools, marketing campaigns and blogging – we hope to build trust in these local communities and bridge the disconnect between government/business and citizens.

The ["insert your city or region here"] pilot project would fund one year of training, internships and an underlying open software ‘platform.’  This software ‘portal’ would enable training to happen in a classroom, or virtually anywhere in ["insert your city or region here"] – with  an Internet connection and PC/laptop.  Flexible training techniques, experiential learning and extensive usage of multimedia (videos, photos and interactive games or mobile applications) would be combined together into an integrated approach to job creation.

The software platform would feature assignments, curriculum, an on-line marketplace and business directory and real-time video help desk – which would be manned by professionals, interns and volunteers.  On-going programs, one-off projects and web services would be offered to a wide range of trainees – ranging from youth, ‘Baby Boomers’ and Moms returning to work to re-entry and welfare populations.  Returning vets and currently  under-employed workers would also participate – but only those who are the “best and brightest” – willing to make the entrepreneurial sacrifice of sweat equity – to learn a new way of doing business.

Volunteerism, mentoring and community engagement would all be taught as an effective means of job creation.  Community newsletters and media channels would be produced and utilized to provide interns real-world skills which could be applied to a wide range of online marketing techniques and professions. The idea is to get the “Haves” to help the “Have Nots.”

The ultimate goal of the DCB Pilot project to have individual and community organizations reap the benefits of on-line technology (beyond what is possible by simply using MS Office.)  The synergistic effect of combining education, business and government efforts together will create a cyber workforce (made up of both individuals and companies) ready to do business around the world – virtually via the Internet.

Jackson Shaw - Quest — Trust, but verify!

There was an interesting article related to cyber attacks targeting natural gas pipelines. I think the interesting aspect of the story is how the basis for the attack is e-mails that look like they come from co-workers and may very well include relevant personal details.

Analysis shows that the spear-phishing attempts have targeted a variety of personnel within these organizations; however, the number of persons targeted appears to be tightly focused. In addition, the emails have been convincingly crafted to appear as though they were sent from a trusted member internal to the organization.

Some attackers have become so sophisticated in their efforts that they research known employees on Internet social sites and then craft an e-mail that appears to come from someone who is known to the intended target.

Spear-phishing attacks are efforts to get employees to click on e-mail attachments.

Generally speaking I sure hope that people aren’t blindly opening attachments just because an e-mail appears to come from someone they know. Everyone does realize that it is possible to fake an e-mail’s from address, right?

In my previous post I mentioned the data breach that occurred in Utah based on a weak password that was used. Both of these events highlight the need for a privileged account management product like Quest One Privileged Password Manager. It’s not enough to simply rely on an e-mail looking like it comes from a friend or co-worker. You need multiple levels of protection in your organization to protect your critical data and systems.

Like this post? Please +1 it or tweet it (below)!

Kuppinger Cole — Advisory Note: Dealing with privacy risks in mobile environments - 70224

In KuppingerCole

The ongoing trend of IT consumerization and deperimeterization has a profound effect on modern society. Mobile devices are becoming increasingly sophisticated and their numbers are growing exponentially. Social networking has made sharing information all too easy and controlling its spread nearly impossible. Growing adoption of cloud-based services, while having obvious advantages, means that more and more sensitive information is now stored and managed by third parties, and users are no...
more

Kuppinger Cole — Dynamic Authorization Management Best Practices

In Martin Kuppinger

Due to a last minute speaker change I had to prepare a short presentation on „Dynamic Authorization Management – Best Practices from our Advisory“ for EIC 2012. When we found a replacement for the speaker, I didn’t give that presentation. However I will do a webinar on that soon and I want to provide some of the content here, as sort of an appetizer.

Dynamic Authorization Management is about dynamically deciding to approve or not authorization requests provided by services (like applications) based on policies and attributes (roles, application used, context, whatever,…). It includes policy definition and management, the access to sources for these attributes like directory servers, databases, ERP systems, and systems for context- and risk-based authentication and authorization. A key standard is XACML. The role of Dynamic Authorization Management within overall IAM (Identity and Access Management) is defined in the KuppingerCole Scenario Understanding Identity and Access Management.

A key success factor in Dynamic Authorization Management is to bring participants from all the different siloes involved to the table. You need people from the business organization, you need application architects and developers, you need IT Security, and you need others. This is a complex challenge.

Another key success factor is to set the right scope and to start small enough to be successful. The design has to cover coarse-grain and fine-grain authorization. It has to look at all types of applications and users. And thinking about the “Identity Explosion”, that means that it has to cover authorization not only for employees, but for many other types of users.

When planning the environment, the positioning of the Policy Enforcement Point (PEP) and Policy Decision Point ( PDP) (more information on XACML, PEPs, and PDPs here) is one of the challenges. Vendors provide a lot of flexibility – and you need to understand the different options to meet the performance and scalability requirements of your environment. This becomes increasingly complicated in cloud environments given that it is hard to run a large number of queries across long distances in an efficient way. So approaches like providing access controls statically to systems might come into play. Clearly, putting a lot of thought into the concepts is a key success factor, especially given that Dynamic Authorization Management has to cover more or less all of your distributed environment.

Acceptance by developers is directly related to simplicity. Keeping things simple for developers is also one of the key success factors. You should start thinking about applying the paradigms of the Open API Economy here.

The same is true for policy definition. The good thing is that the way policies are described in XACML from a conceptual perspective (so without the XML stuff around) is pretty straightforward, simple to understand, and powerful. Nevertheless you have to educate your business users in expressing their business policies and translate this for the IT level. And you shouldn’t underestimate the complexity of auditing and analyzing policies in a dynamic environment.

However, when putting sufficient work into the concepts, you can design a Dynamic Authorization Management environment today which is future-proof. You should also do it because that will help you to become much more efficient in the management of Information Security and much more agile in fulfilling today’s and tomorrow’s audit requirements.