Last week NRCan gave a presentation to the Conference Board of Canada on the role of social media in risk management. The presentation took the usual form: we discussed our experiences in managing the risk of social media implementation, focused on how to address quality of content on wikis, and how to guide and inform employees on the acceptable use of new and open technologies.

What was different about this particular presentation was the inclusion of a few slides on how social media could be used to contribute to – and in fact reinforce – risk management activities. We had an audience interested in all aspects of risk management, and as good presenters we looked at our own NRCan Wiki, our blogs and other tools to find good examples to illustrate how social media could help reduce risks – or at least serve as a way to identify risks earlier.

Joe the security guy
Take one of our IT security guys for example – let’s call him Joe . He’s a well-respected and knowledgeable NRCan employee, whose work concerns protecting corporate systems and ensuring that we’re kept well informed on any potential risks. Joe wrote a blog entry about the dangers of Twitter. It was a good, well thought out entry that generated a discussion amongst employees. Some employees were concerned that this attention to potential risk could slow things down, and the issue was discussed from a diverse variety of perspectives.

How does this support better risk management? The first thing to note is that Joe posted his blog entry voluntarily – not because he was asked or because there had been a problem, but because he saw something on the horizon and took the initiative to address it by starting a discussion with his fellow employees. This discussion took place before the Department had officially identified Twitter as a tool being used by employees, and long before it had indentified the need to provide relevant policies and guidelines.

Now that the need has arisen, the policy does not need to start from square one. There is already a base of research and opinion to be found in the discussion sparked by Joe’s blog entry. Joe has created a living repository for information and knowledge that could play a valuable role in building a risk management approach, a repository fuelled by the experiences of NRCan employees. Now policies can be built not only on theoretical implementation plans, but also on how real employees have chosen to make use of social media tools.

This is the power of social media: to build on the wisdom of crowds. In the social media forum, the latest concepts are discussed by people that have an interest in the topic, no matter whether they have an official role in the file or not. With social media, a body of valuable knowledge and experience can grow organically, fuelled by the passion and interest of real people, including those who may not have been reached through traditional lines of communication.

We must not only recognize the value but also make use of the discussions and analyses that are generated through the knowledge skunkworks of social media. Taking this inclusive and proactive approach will help us anticipate new trends and build corporate knowledge, not only for managing risk but also for any other subject matter or mandate.

Security. It’s an old problem, but it’s just been restated with a new urgency. And it has all kinds of implications for the practice of e-government as it’s evolved over the past few years.

The Cassandras were both CEOs, availing themselves of a platform at the RSA conference last month. And they were singing from the same gloomy songbook.

Enrique Salem, the new CEO at the security heavyweight Symantec, was particularly blunt. The current model of cybersecurity, he said, just isn’t working.

“It’s time to change the game,” Salem said as he called for “a bridge between day-to-day operations and security departments” to create shared plans and goals.

In Salem’s reckoning, the problem with security now is that it’s done piecemeal. His argument was nicely captured by Internetnews.com:

“(A)dministrators still perform manual analysis of threats against their systems within carefully partitioned silos. One team configures laptops, another looks after the datacenters, an operations team keeps an eye on routine tasks and an entirely separate security team does vulnerability testing. . . . Stand-alone products at various points within the system hamper policy coordination, making automation of many processes nearly impossible. Lower-level administrators end up creating de facto policy day-by-day based on how they configure e-mail, backup and server security.”

Salem’s musings ran along the same lines as the keynote address at the same conference by John Chambers, chairman and CEO of Cisco. Chambers argued that security has to become fundamental in IT infrastructure – which means integrating it into business processes.

“Security isn’t a stand-alone area,” he warned. “Security is something that has to be embedded in our strategy, it has to be embedded in our technology, it has to be automated,”

Salem and Chambers are hardly the first to worry about security, and cynics will argue that Salem in particular has a vested interest in making his case. On the other hand, CEOs don’t often go this route in public – which suggests that their fretting about the bad guys is entirely appropriate.

And if that’s true, reflect for a moment on the consequences for the good old Internet, vehicle of choice for citizen cyberconnection with government.

It’s simple, really: If the bad guys make the Internet in its various incarnations too risky, people will simply abandon it where possible. Snail mail used to work as a way to pay your taxes; it still does, by all accounts.

Which of course would leave all those nifty vehicles of electronic service delivery – the pride and joy of e-government over the past 10 to 15 years – in a difficult spot.

Pity, that.

The Identity Metasystem offers a new way to think about the relationship between parties that are interested in either consuming or producing identity information. Sometimes this is referred to as Identity 2.0, or more correctly as User Centric Identity. This new paradigm offers many benefits, from increased security, enhanced privacy, and the opportunity for new business models. It is sometimes misinterpreted as a technology that nullifies the current identity practices that many enterprises have in place. This is most likely due to the technical nature of most literature available on User Centric Identity, and on the focus of standards and interoperability. But it could not be farther from the truth.

What is really important about the Identity Metasystem is that it defines an “Identity Dial Tone” that prescribes how identity can flow seamlessly through enterprise websites, web services, and the ever growing social networking and collaboration services, spanning both high and low trust situations. For the potential opportunity of this new ecosystem to thrive, it is important that it is embraced and delivered to enterprise customers in a way that allows them to incorporate the concepts in their existing infrastructures, without the fear that large portions of the solutions will need to be replaced or significantly modified.

I also collaborated on the joint paper “CA and Microsoft Support for User-Centric Identity and the Identity Metasystem”, that describes how SiteMinder can participate within the Identity Metasystem by allowing Relying Parties to accept Information Cards from Identity Providers. 

Both of those blog postings have been from an educational view, but this one will be my own opinion.  To give some context for the discussion to follow, you should be familiar with the Identity Metasystem.   

Here is a quick recap of the main actors the Identity Metasystem defines:

Identity Provider (IdP) – produces identity in various formats.  I like to think of it as an identity prism.  It can produce my identity information in many flavors, based on the context of how I would like to use it, and on the policies defined.  Bottom line, it burps out identity in multiple token formats, based on policy.

Relying Party (RP) – consumes identity information provided by an Identity Provider.

Subject – me, the user who wants to access some service, and has to give then some identity information.

Identity Selector – a chunk of software that provides a mechanism for me (the subject) to manage and use their identity personas.

The Identity Metasystem describes a fundamentally new way to think about identity, how it is produced and consumed, and the rules that govern how this should happen.  Information Cards (CardSpace) is a particular implementation of the Identity Metasystem, the user-centric perspective.  Because Information Cards was the first implementation, and because it has a visual component (the selector), it made logical sense to use this new concept as an educational mechanism to educate people on the Identity Metasystem concepts.

People reacted positively to this approach, as we know a picture is worth a thousand words.  The problem is that I think we have painted ourselves into a corner.  The Identity Metasystem is more than Information Cards; they are just the tip of the iceberg.

Because the scenario that we have been using to date pushes the user-centric concept, people mistakenly interpreted the entire capability of this new Metasystem as only supporting user-centric behavior.  I fell into this trap at the beginning also.  I think we need to discuss the new ecosystem from a different perspective.

Most existing Identity Metasystem examples described a user accessing a web site and providing a computer equivalent rendition of a user license.  The visual metaphor made it easy to understand how things were happening.  This made sense since the most logical way to describe the new user-centric paradigm was to relate it to real world items and behaviors.  The infocard and its usage of claims became the central point of discussion and of education.

But if you take the time to really look at the Identity Metasystem and how it is constructed, you will realize that it is much grander that that — much of it is under the water line, and it’s big.  To really educate people on what problems the Identity Metasystem can help solve, we need a better way to describe it in a way that others can understand.  Basically, it needs to be a simple concept to explain and understand.

In the identity arena, we normally view identity from three different perspectives:

Web Site Access Management solutions (User-centric federation)

1.                               Web Service/SOA management solutions (Service federation)

2.                               Enterprise Federation

These deal with the federation of identity from someone who has it (Producer), and someone who wants it (Consumer).  The issue to date has been the format that each of these federations convey their identity (SAML, WS-*, username/password, smart card, assertions, claims, etc).  Sometimes a user is involved (User-Centric Federation), sometimes it is just an identity sharing arrangement between corporations (Enterprise Federation) and sometimes it is a service call (Service Federation)

So when we attempt to use or create solutions that require identity across the spectrum of these three federation models (User, Enterprise, and Service) we are often forced to use incompatible formats (e.g. SAML1.0 vs. SAML20 vs. WS-Federation).  If we want to access a web site and then access a web service, the underlying plumbing has often gone through many hoops to make this happen, often exposing new security risks or identity information that was not relevant to the situation.  Engineers must select a “dialect” that they want to communicate in when obtaining or using identity within their solutions.  The difficulty in developing and defining these relationships (Producer-Consumer) has made our lives difficult, and it is often unable to scale as business requirements evolve.  The Identity Metasystem can help.

The example of an infocard (User-Centric Federation), where a user provides a web site (Consumer) with their information from an Identity Provider (Producer) is pretty much the same interaction pattern across the federation models.  The only major difference is in how the identity information is conveyed from the producer to the consumer, and how it is processed.  Of course this is a wildly over-simplification of the situation, since it involves complex issues such as: how the policies of the producers/consumers are defined, exposed, and discovered, privacy, compliance, etc.  But at the end of the day, the Identity Metasystem offers an Identity Dial Tone

The “Identity Dial Tone” (IdT) is the ability to produce and consume identity in various formats, based on contextual information and adhering to defined policy.  The Identity Dial Tone produces identity claims that can be used in the various types of federation scenarios; it is able to transform identity from one form to another, based on the requirements of the task.

Think about it.  The Identity Metasystem shows how to move tokens from A to B, and how to provide the right format that each participant knows about.  It describes a mechanism that can take a request in one format and produce a response in another format.  If we convert an apple to an orange, in a language and technology independent fashion, then we can start to deliver the Identity Dial Tone.  We could accept a un/pw, generate a SAML assertion, take that and generate a WS-Security Token, take that and generate a totally custom token, etc, etc.  The strength lies in being able to isolate identity information from the format required for collaboration between heterogeneous environments, and token formats.  By separating the identity from the representation, and clearly defining the requirements that an identity producer or identity consumer should follow, the Identity Metasystem lays the foundation for truly portable identity, or the “Identity Dial Tone”.

The incompatibilities between concepts like SAML, WS-*, SSO, User-Centric, and Web Services can be harmonized with the Identity Metasystem, by providing an Identity Dial Tone.  Until we start to educate everyone on the real strength of the system, we are going to be left with the misinterpretation that this relates only to user-centric identity, and the transfer of claims from point A to point B.  So, user-centric is the tip of the Identity Metasystem iceberg, the plumbing can provide for the Identity Dial Tone that helps harmonize enterprise, user, and services federation.  In future posts, I will discuss how the Identity Metasystem can be used to bridge the differences between competing federation formats and protocols.

There’s good news and bad news as public sector thinkers on things technological contemplate the approach of cloud computing.

The good news, according to a new report from the Pew Internet and American Life Project, is that people have already embraced cloud computing.

The bad news is that they still can’t get their heads around the privacy and security side of it.

Which may well mean that e-government is not about to meet the cloud – now or, frankly, ever.

The basic notion of cloud computing – a user friendly place to keep data and storage – is enormously appealing on one level. Taken to an extreme, it points to a world in which people don’t really need computers; they just need access to them now and then, wherever.

To the researchers at Pew, this brave new world is already both here and successful: “Some 69% of online Americans use webmail services, store data online, or use software programs such as word processing applications whose functionality is located on the web,” they report.

Sounds terrific, and in a sense it is – except that it’s an analysis that’s heavily dependent on the success of programs like hotmail and gmail, which are pale imitations of what the theorists of cloud computing have in mind. Those deep thinkers reach way beyond simple e-mail exchange, to the entire range of programs, applications and data.

And data is the sticking point, because the same Pew project found the same Americans leery of the same privacy and security concerns which have bedeviled e-government evangelists for 15 years or more.

“(U)sers report high levels of concern when presented with scenarios in which companies may put their data to uses of which they may not be aware,” Pew reported. Specifically:

.

·         90 per cent of cloud application users say they would be very concerned if the company at which their data were stored sold it to another party.

·         80 per cent say they would be very concerned if companies used their photos or other data in marketing campaigns.

·         68 per cent of users of at least one of the six cloud applications say they would be very concerned if companies who provided these services.

Caveats abound, to be sure. This latest project by Pew was set in a private sector context, not a government setting. Plus: Its sample was exclusively American.

Still, the findings amount to a reminder of ongoing public concerns about the use of public data. It’s still a poser after all these years, one that government tech managers will ignore at their peril.

As information security professionals, we are always interested in finding stories or anecdotes to help make a point or to further educate people on the importance and need for strong information security.  

An item grabbing US headlines recently was the story concerning the inappropriate access to the passport files of the 3 major US presidential candidates, Barack Obama, Hillary Clinton, and John McCain:  http://www.cnn.com/2008/POLITICS/03/21/obama.passport/index.html

At first glance, this story did not seem particularly interesting, especially when I realized that a passport file contains basic statistics such as birth date, height, weight and eye color-information that is already widely available for such public figures as these.  Other than the applicant’s social security number, there is no real significant private data in these files.  Clearly, this was purely a case of random snooping by curious employees, much like the similar incident when people accessed the medical files of actor George Clooney’s and Britney Spears. http://abcnews.go.com/US/story?id=4498155&page=1

But, as more details around this story emerged this week, my interest in the story evolved from that of a concerned citizen to that of an information security professional.  According to State Department spokesman Sean McCormack, Senator Obama’s files had been viewed three times by contractors working for the agency starting in January.  In Clinton’s case, a trainee accessed her files in 2007.  McCormack said two of the contractors in the Obama case were “low-level” personnel and the other was in a mid-level position with no management role.

Now, let’s reconsider this situation.  These were not full-time employees doing this, but contractors and trainees who do not even work for the State Department.  And while there is nothing wrong with hiring contractors (we have since learned that the State Department hires contractors to design, build and maintain their systems), this incident raises questions about how well (or not) the State Department is provisioning access to data, application and systems.  In this situation, it is not just that it was contractors that accessed the files, but that the contractors themselves were ‘low-level’ personnel.  Unfortunately, we do not know the specific IT architectural details of the passport system, but the fact that contractors in non-management roles were able to access any and all data for highly public figures suggests that the passport system suffers from a monolithic “access for all” security model.  Unfortunately, this is often the case in legacy systems that were designed and deployed decades ago with no elaborate security access control mechanisms.  In the initial years of operation, such systems are only accessed by a small defined group of individuals.  Thus, auditing and controlling access to information is easy.  

But, as such systems become more widespread, the number of users requesting access increases rapidly.  And in the case of a high value application like the passport application system, it cannot be taken off-line over an extended period of time so that developers can create a more robust security model for the application.  As a result, this “access for all” model becomes the standard, meaning that everyone ends up with the same level of access, regardless of responsibility, title or function.

Situations like this scream out for identity and role management.  These types of systems empower organizations to create security and access models specific for individual roles and functions.  In the State Department case, a separate role category of ‘contractor’ could be created and within the contractor category, certain roles such as trainee, manager etc. could be created with the level of security access commensurate with each role.  Such systems deliver two levels of benefits.  One, they greatly simplify management and administrative operations because the IT team only needs to manage dozens of roles instead of hundreds of individuals.  And secondly, identity management systems can reduce risk by ensuring that users’ access to information is limited to their actual business function.  Had such systems been in place at the State Department, it is unlikely that these kinds of breaches would have even happened.

One of the sticking points for Web 2.0 in a public sector context has always been privacy and security. It’s a notion crucial to both the mission and mandate of all orders of government and the general confidence of cybercitizens in online government.

There are signs, however, that such concerns may be needlessly overstated.

A recent U.S. survey by Mintel Comperemedia, for example, found that two-thirds of Americans were more concerned about security than they were five years ago. But in nearly same breath, Mintel analysts noted that identity theft is actually declining.

“The actual risk of having your identity stolen online is not as high as many people think,” eMarketer quoted Susan Menke, senior analyst at Mintel. “Financial services companies are trying to reassure consumers, but their marketing messages aren’t sticking. Companies need to find innovative new ways to convince Americans that their identities are secure online and when using e-mail.”

The most recent data from the U.S. Department of Justice indicated that less than 9 per cent of identity theft is a result of online scams. Rather, most identity theft is perpetrated through stolen mail and other low-tech methods.

In one sense, such findings support the laissez-faire approach to privacy and security which characterizes Web 2.0 tools like Facebook. In the longer term, however, what e-government managers could be looking at here is the very thin edge of a wedge that leads to new views of privacy and security issues in a public sector context. Not exactly plus ça change, maybe. But worth noting.

I couldn’t resist the blogging exercise of connecting these two seemingly unrelated concepts.  In the world of blogging, for better or worse, often the best way to attract readership is with a strange title and lead-in.  I think the title of this blog entry covers that approach sufficiently.  However thinking of IAM technologies as being like a jellyfish isn’t actually my idea.  In fact it is an idea that I just heard at the just completed Gartner IAM Summit in London England. 

So how can the IAM market and jellyfish be related?  As a starter just take a look at the diagram below – not the details, just the overall visual look (source: Gartner Group).  Stand back a bit, and yes, I think you would say it looks like a Jellyfish flowing in the tide from right to left.  In reality this diagram is Gartner’s visual summary of the various technologies that make up the IAM market and how they flow from basic categories, such as identity administration, access management, identity auditing etc….  But add a handful of differentiating color and voila! — the essence of jellyfish.

From my years of ocean sailing and swimming I have had the “pleasure” of seeing, sometimes a bit closer than I had wanted, many jellyfish.  And yes, this diagram does look like a jellyfish to me.  But are IAM technologies in anyway similar to a jellyfish?  Actually, yes in many ways.  Let me give you some of the ways I came up with:

• IAM technologies, like Jellyfish react and adjust quite quickly to their current environment…or better said, to the current in their environment.  Why else would there be so many technology strands in the IAM market?
• IAM technologies like most jellyfish are not isolated in their environment — they live and interconnect amongst their own kind….sometimes in small numbers and sometimes in very large numbers depending on the environment.
• One IAM deployment in the wild doesn’t look exactly like another one, just like one Jellyfish is bigger/smaller, longer, wider, than another one even of the same species.  Organizations have built and our building their IAM systems in reaction to their existing systems and organizational priorities….and thus ending up being different.
• IAM systems, just like their jellyfish brethren need to be highly flexible, interconnected, and responsive to their environment to be most successful.

Maybe you can think of some more similarities if you have some free cycles.  Do I think the connection between IAM and jellyfish is particularly important?  Not particularly.  My real takeaway is that diagrams such as this one really frame the tremendous variety and broad relevance of IAM technologies today and also provide a parallel warning to the undereducated – if you stick your hand into the wrong place or in the wrong way, you risk getting stung.