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.

We’ve just concluded the sixth EIC, the European Identity and Cloud Conference. It was my fifth, but I continue to learn something new each time. Before I get into what I learned this year, a brief note to mention that EIC 2013 will return to Unterschleissheim (just outside Munich) from May 14-17. Begin to book now, it’s sure to be even bigger and better than ever.

I’ve been going to technology conferences, both big and small, for 25 years and it never ceases to amaze me that there’s always something new to learn – either a new technology, or a new way to look at technology. While it’s true that there is really nothing new under the sun – “cloud computing,” for example, has remarkable similarities to datacenter computing from the ‘60s and ‘70s – it’s also true that there is always a different way to look at data, facts, or technology which can give insights into better ways to conduct business. This year there were three such “truths” that stood out for me.

First, Dr. Barbara Mandl, who is Senior Manager of Daimler AG, responsible for the Global Daimler IT-Organization as CoC Identity and Access Management delivered a keynote entitled “What About: Bring your own Device?” Her opinion? It’s not about the device. Rather, it’s about the data, the information. While it’s true that building services to provision users and their myriad devices can be daunting, you should never lose sight of what is really important – protecting the data that is central to the organization. This is also a reminder that we frequently get bogged down in details that – in the end – don’t really matter to the detriment of the things that do.

The second was part of a discussion I had with Deepak Taneja, founder and CTO of Aveksa. We were having a discussion about “the Cloud” (so many of my conversations were about that topic), talking about why people move to Software as a Service (SaaS) or “Cloud Computing” as we now call it. What we concluded was that people were still having the same discussion that they’d had 10 years ago – only the names were different. In the late nineties people argued about Windows, Linux or Macintosh as the “best” platform to install applications on. Today, it’s about “The Cloud” or the datacenter. Now I’m not trying to minimize the differences between the cloud and the datacenter, there are major differences in terms of cost and other resources used, but when talking strictly about applications and services then it should be about the applications and services. Just as when we argued about operating systems, or about whether it was better to install apps on the server or the desktop, when we argue about using “the Cloud” or “the Datacenter” then we’re talking about the wrong thing. The most important decision is to pick the right application or service – that one that best fills our need. Choosing the platform first is like choosing a restaurant because of the color of the plates they use.

As in all computing, pick the app that serves you best, then pick the platform that best supports that app. Take into account the costs of planning, setup, installation, distribution, maintenance, upgrades and so on, but unless there are major disconnects, pick the app or service that does what your business needs it to do, and does it in a way that’s efficient, easy to use and secure.

Finally, last – but far from least – was a statement from Susan Morrow. She’s Head of Research and Development at London’s Avoco Secure Ltd. And is involved in the design of Cloud based, verified, consumer identities for use by governments and commercial organizations. I emphasize that she’s involved in design. Susan is also active in the Kantara Initiative’s User Managed Access protocol, again as part of the design team. She was on a panel I moderated on Consumer Identity (what we used to call User-Based Identity) but caused us – especially me – to sit up and take notice when she offered an opinion near the end of the group discussion. She urged that vendors actively recruit more women for their application (and service and protocol) design teams. Not simply because they’re severely underrepresented (although they are) but because they have (in general) a very different point of view from men. She contends (and, upon reflection, most of the audience agreed) that women, in general, take a more holistic view of things including technology.

The dictionary defines “holistic” as: “relating to or concerned with wholes or with complete systems rather than with the analysis of, treatment of, or dissection into parts…” What she meant was that men often get bogged down into small parts of the design while losing sight of what the overall plan is. After thinking a moment I realized that this relates directly to something my wife often tells me. Here’s an example. My wife may be cooking and realize that she needs cilantro for the dish, but doesn’t have any in the fridge. She’s aware that sending me out for some means I won’t come back until I’ve found it – even if it means visiting dozens of stores and spending hours in the search. If she goes herself, she’ll go first to the most likely store, but if there isn’t any cilantro she’ll then think about what she can substitute. The difference is that she sees the big picture – delivering a tasty dinner to the table on time – while I see the detail – finding cilantro!

It’s something that all vendors and all software designers need to keep in mind, but it would be easier if a woman was on the design team.

This is analogous to the KuppingerCole theme that IT’s job is to support the business rather than to create beautiful technology. Technology is just a tool of the enterprise; it’s the plumbing on which the services and applications run. But it isn’t really about the services and apps, either. It’s about the output and how that furthers the goals of the business.

The French tells us that the more things change, the more they stay the same (plus ça change, plus c’est la même chose). And it is the biblical book of Ecclesiastes (attributed to King Solomon) that tells us that “there is nothing new under the sun.” But I’m telling you that there is always a new way to view what we feel are “truths” and that new way might very well be better that the old way.

See you in Munich in 2013!

Back in the mid 1990’s, Fiber Distributed Data Interface (FDDI) was touted as the networking protocol of the future. It could handle traffic of 100 megabits per second (mbps) and was considered far more reliable than Ethernet (which was only 10 mbps, anyway) as it was a deterministic protocol based on the Token Bus architecture (similar to Token Ring). Standard Ethernet protocol was considered to be unable to provide more than 10 mbps bandwidth and – due to its “collision detection” technology – was also considered unreliable. Yet here we are today with most networks tied together by 100 mbps and even gigabit Ethernet! How is that possible?

Simple, really: what we call “Ethernet” today is vastly different from the protocol Bob Metcalfe invented and that we used in the early to mid 90’s.

Ten years ago we were all agog over what became known as “user-centric identity”, which was effectively launched at the first Internet Identity Workshop when a group of people merged their projects: OpenID, Lightweight Identity (LID), Sxip, and XRI. Microsoft’s CardSpace eventually associated with the group, but CardSpace was never subsumed into OpenID, preferring to define transaction points where the two protocols could interact.

Well, you know the rest of the story. Microsoft appears to have abandoned CardSpace. OpenID was co-opted by Google and Facebook who forked the open source protocol to create their own identity systems. Sxip disappeared into the hungry maw of Ping Identity, and XRI development has, essentially, ceased.

But there’s a new lightweight, user-oriented identity protocol rising, and it’s called “OpenID Connect”! And OpenID Connect bears a relationship to OpenID similar to Gigabit Ethernet’s relationship to Metcalfe’s Ethernet. That is, they share a name.

OpenID Connect goes a long way towards solving some of the problems of OpenID, especially security issues, as it includes a binding to the Secure Access Markup Language (SAML) protocol and is built on top of Oauth, while maintaining a semblance of an easy-to-implement system for developers and easy-to-use for users. As a plus, Google is actively participating in its development while Facebook and Microsoft are looking on to see if the effort to join the party will pay dividends in terms of people’s usage.

And, since SAML is part and parcel of most enterprise identity federation schemes (including those that connect the enterprise to cloud-based platforms) the work on OpenID Connect could bridge the divide between Enterprise Identity and that which we called “User-centric”.

But it’s no longer called “User-centric” identity. Today’s term is “Consumer Identity” and it’s part of the movement called the “Consumerization of IT” (CoIT), which has evolved from the Bring Your Own Device (BYOD) movement.

Not only are enterprise users bringing their own device, they’re connecting to “x-as-a-service” (Software aaS, Platform aaS, etc.) entities on their own, which could compromise corporate data as well as the users own safety and security.

Business protocols in the consumer space, corporate consumers acting as their own IT dept., all thrown together by a few simple protocols. See how it’s all interconnected?

Next week at the European Identity & Cloud Conference (EIC) I’ll be moderating a half-day track on Consumer Identity, while BYOD will be the topic of a webinar we’ll be announcing for early May. More on BYOD in the next issue, today let’s set the table for Consumer Identity.

Joining me at EIC are a number of veterans of the User-centric Identity battles including Microsoft’s Kim Crawford, Tony Nadalin (formerly IBM) & Mike Jones, OpenID’s John Bradley & Don Thibeau, XRI’s Drummond Reed and Google’s Andrew Nash. We’ll be joined by a number of others involved in various aspects of consumer identity and CoIT as we discuss three distinct topics.

First off, we’ll do an overview of current trends in Consumer Identity Systems. Microsoft’s Cameron, & OpenID’s Bradley will be joined by Colin Wallis (New Zealand Government), Susan Morrow (Avoco Secure Ltd) and Malcolm Crompton (Information Integrity Solutions) to look at trends in the face of consumer expectations concerning their online experience which is becoming ever more sophisticated. At the same time, the negative aspects of online privacy are becoming better understood and more frequently questioned by those consumers. These issues are impacting the design and development of consumer identity systems and it’s a question of whether our current offerings, such as SAML with OpenID Connect, can provide the type of identity system that will perform to the expectations of this increasingly sophisticated audience in terms of user control, privacy and security.

The second session will be a review of the status of key internet identity protocols including OpenID Connect, OAuth 2.0 and Account Chooser. Here I’ll be joined by Axel Nennker (Telekom Innovation Laboratories) as well as Microsoft’s Jones, OpenID’s Bradley and Google’s Nash. This promises to be a high level overview of the protocols, and an explanation of why major technology companies have standardized on them. One topic we will surely discuss is how the functionality of the OpenID v2 protocol has been re-implemented on top of OAuth to create OpenID Connect. The session will also delve into the security problems of websites that run their own password based login systems, and what they can do to improve their security as well as their users’ experience.

Finally, Microsoft’s Nadalin, OpenID’s Thibeau, & Google’s Nash along with Drummond Reed (Connect.Me), Scott David (K&L Gates LLP) & Jeff Stollman (Secure Identity Consulting) will gather to toss around the topic “Barn-Raising At Internet Scale: Trust Framework Development for Open Identity”.

This will be a fascinating look at how a group of people came together in response to the US Government’s call for development of a safe, secure identity framework for the internet. In April 2011, the US Department of Commerce released its National Strategy for Trusted Identities in Cyberspace (NSTIC) which called for a public-private partnership to create a secure commercial, social, and civic identity ecosystem. The Open Identity Exchange (OIX) has taken the lead in constructing both the rules and tools for the rapid, internet-scale creation of such an ecosystem: the Trust Framework. Other governments have now joined in the call for secure public protocols that protect citizen identities and we’ll touch on those as we see how they relate to NSTIC. The question, then, is two-fold: can these systems be created and be effective, and can various national systems inter-relate and coexist.

As always, it promises to be a group of lively sessions with the occasional difference of opinion that can bring about greater understanding. If you’ll be at EIC, mark these sessions on your agenda. If not, we’ll be writing about the conclusions, at least, in future entries. Either way, this will touch on topics and reach conclusions important to each and every one of you.

I saw a marketing brochure the other day that claimed “Today’s average enterprise utilizes 16 different directories,” touting their synchronization engine for provisioning and de-provisioning. The vendor’s take seemed to be that 16 was a huge number, but I merely chuckled to myself. Fifteen years ago, while barnstorming the US for a provisioning vendor I would frequently ask the audience how many identity stores they’d identified in their organization. I still remember one memorable response: “we’ve found 116, but we’ve only just started looking.”

Ten years ago, soon after the Liberty Alliance introduced the concept of “federation” as a way for partners, clients, vendors and others to share authentication and authorization, I discovered – again, by asking users at a conference session – that one of the major uses of the federation technology was to connect the different parties after mergers and acquisitions so that the newly formulated organization could do real business while the IT department caught up with the different, disparate and often unconnectable systems that existed in the various parts of the enterprise. The standout memory here was one of the “big 5” US banks who had acquired a small, community bank in California which was still running one update program on an old (i.e., pre-1980) Z-80 single-board machine which couldn’t be integrated with the bank’s network nor was it viable to re-write the software. They never did find a way to connect it directly to the bank’s systems.

All this is to say that by early in the 21^st century, both synchronization and federation were being used to connect various identity data stores throughout the enterprise. As for data stores located “beyond the firewall” (back in those days there really was a firewall around the enterprise network), very little was being done. What had been called “web services”, and which was now morphing into “software as a service”, wasn’t much involved in the movement of identity data yet, although it was certainly much talked about by analysts and pundits.

At this time, too, simplified sign-on (SSO) was largely confined to systems within the enterprise even though there was a lot of talk about SSO for web services.

Provisioning for what would eventually be called “cloud services” was, essentially, non-existent. Although Business Layers, the pioneer in provisioning apps, had – at the time they announced eProvisionware, provisioning for the enterprise – promised that provisioning for external users and apps would be coming “real soon” it still hadn’t occurred 5 years later when the company was acquired And its products disappeared.

Ten years ago, when Service Provisioning Markup Language (SPML) was launched, one of its tenets was that SPML would enable cross-organizational provisioning with a vague reference to some sort of cloud-like service. Ten years later, we’re still waiting.

Identity services in the cloud-computing arena pretty much boil down to a choice of federation or synchronization.

We’ll be doing a session at the European Identity and Cloud Conference called “Federation or Synchronization – the Future of the Cloud” featuring Patrick Harding from Ping Identity, Andrew Nash from Google and Darran Rolls of SailPoint, three gentlemen very familiar with these two methods. To kick off that session I’ll be speaking about “What Federation is About – in Theory and in Practice.” So for today I’ll concentrate on synchronization.

Synchronization services are part of the bread and butter of cloud computing. Services such as Dropbox which synchronize file shares between and among various client desktops allow us greater freedom when moving about the world. Dropbox in concert with CloudOn allows me to bring my necessary Microsoft Office documents with me on my iPad – and edit them on that device. But that’s for files, what about identity data?

Directory systems, such as Active Directory, have built in replication mechanisms. Some cloud services take advantage of these to enable easy provisioning of cloud service users. One of the better implementations is – what else? – Microsoft’s own Office365.

Office365 is a cloud-based office productivity service with versions for small, mid-sized and large enterprises. The SMB version (approx. $6/user for up to 50 users) includes:

• Cloud-based email using your own domain name;
• Shared calendars;
• Instant messaging, PC-to-PC calling, and video conferencing;
• Web-based viewing and editing of Word, Excel, PowerPoint, and OneNote files;
• Team site for sharing files; and
• External website

For large organizations, you can bundle in licenses for desktop versions of the Office suite as well.

Office365 uses Active Directory synchronization to move user identity information between your datacenter and the cloud space. It should be noted that Office365 can also use a federation mechanism (which Microsoft refers to as single sign-on) which enables your company’s users to sign in to Office 365 by using their corporate credentials. Microsoft recommends you start this way while setting up synchronization – which can take a while.

Synchronization of AD for Office365 takes a bit of preparation, some testing, and a multiphase commit so that you can back away if you want. Once you’ve committed to synchronization it can be difficult to reverse.

In a Microsoft Office 365 environment, source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a cross-premises deployment. For example, by running Active Directory synchronization, you are mastering objects from within your on-premises Active Directory. Alternatively, when you create objects by using the Exchange Control Panel (ECP) or the Office 365 portal, you are mastering objects from within the Office 365 cloud.

Office 365 requires a single source of authority for every object. This reduces the likelihood that directory data could be inadvertently overwritten.

By default, Office 365 directory objects are mastered in the cloud, which means they must be edited by using cloud-based tools. You can use the Office 365 portal, Windows PowerShell, or the ECP to create users, mailboxes, contacts, and groups in the cloud directory. All subsequent changes to these objects are also made by using the same tools. In this scenario, the source of authority is in the cloud.

When the directory synchronization tool is activated in the Office 365 Admin page, and after the first sync cycle has been completed, the source of authority is transferred from the cloud to the on-premises Active Directory. In this scenario, users, contacts, and groups are created on-premises and then synchronized to the cloud. All subsequent changes to the cloud objects (with the exception of licensing) are mastered from the on-premises Active Directory tools. The corresponding cloud objects are read-only. Administrators cannot edit cloud objects if the source of authority is on-premises.

Up until the completion of that first sync cycle, you can safely back out of the synchronization scenario.

If you’re interested in the specifics of Microsoft’s synchronization for Office365, you should read “Directory synchronization and source of authority,” which has all the details.

To synchronize your directory data either from a non-Active Directory system in your datacenter or to a non-Active Directory system in the cloud (or both), the cloud service provider needs to invest in a synchronization service such as The UnboundID Synchronization Server. This allows you to synchronize data between and among LDAPv3, RDBMS, and Active Directory data repositories. With the UnboundID server – but not necessarily with others – in addition to synchronizing data with standalone repositories, the server also provides a notification service that allows the service provider’s cloud applications or the customer’s on-premise applications to subscribe to receive messages from each other based upon changes made to monitored directory data, thus providing automated synchronization. Some other vendors’ service requires that synchronization be done manually.

You should investigate whether or not your cloud service provider (or potential cloud service providers) offer directory synchronization services. It’s much cleaner and more complete (as far as supporting the full panoply of IAM services) than federation. But because it can take a bit of time to initiate and fully test before going to production, its best to begin with a federation scheme which at least lets you control adding and removing users via your datacenter provisioning service.

And, remember, you can find out much more about synchronization and federation at the European Identity and Cloud Conference, April 17-20, in Munich. See you there!

There’s Identity, and there’s the Cloud. While we still can’t quite agree as to what is Identity and what are Cloud Services we also can’t wait until we decide those issues to properly connect the two.

Apps can reside either in the datacenter or in the cloud. They could also reside on our local device (PC, tablet, smartphone, etc.) but we’ll simplify today’s discussion (and leave mobile identity and apps to another day) by concentrating on these two platforms.

Identity services can reside in either place also. Often, in fact, they’ll reside in both places. More on that in a moment.

There’s a lot of confusion when two or more people discuss Identity and Cloud Services, though, because they’ll have different ideas as to what’s being identified and why as well as which direction(s) the identity data flows. Let me break it out for you.

We can have:

A.   Identity Services in the datacenter, apps in the datacenter;
B.    Identity Services in the datacenter, apps in the cloud;
C.    Identity Services in the datacenter, apps in the cloud AND the datacenter;
D.    Identity Services in the cloud, apps in the cloud;
E.    Identity Services in the cloud, apps in the datacenter;
F.    Identity Services in the cloud, apps in the cloud AND the datacenter;
G.    Identity Services in the Datacenter AND the cloud, apps in the cloud
H.    Identity Services in the Datacenter AND the cloud, apps in the datacenter;
I.    Identity Services in the Datacenter AND the cloud, apps in the datacenter AND the cloud!

Today, most corporate users are involved in case I, Identity Services in the Datacenter AND the cloud, apps in the datacenter AND the cloud, simply because most large corporations that are moving applications and data to the cloud are still in the process of doing so. These organizations started in case A (so-called “traditional computing”), moved to case C then on to I with a target – perhaps unreachable – of case G. That is, large organizations start with both identity services and apps in the datacenter then move some apps to the cloud. This is followed by moving some identity services to the cloud (perhaps through federation) and finally moving all, or almost all, services and apps into the cloud.

Join me at the European Identity and Cloud Conference next month to learn more about Federation for cloud services as we explore Federation vs. Synchronization.

Small organizations, though, are following a different timeline, especially those which don’t have what could even loosely be termed a “datacenter”. They start out initially with both identity and apps on a local device. Over time, those devices are brought together into a workgroup which may or may not have centralized identity services and apps. Now they’re being drawn to the cloud – both for identity as well as for apps and services.

Besides location and platform, we need to talk about the purpose of our choices. That is, do we want Identity for the cloud, by the cloud, in the cloud or of the cloud? And what do they all mean?

Identity FOR the cloud is what many organizations have today – authentication in the datacenter then a link (either via a portal or through federation) with cloud services and apps.

Identity BY the cloud is what the consumer, or B2C, market has: customers authenticate to the cloud service (such as Google Docs, Apple’s iTunes, or Netflix or other streaming sites), typically via a username/password combination.

Identity OF the cloud is something which is more honored in the breach today but will become important in the near future. Organizations and individuals interacting with a cloud service need to be assured that they are actually in contact with the cloud service they intended to be in contact with. Protocols such as HTTPS and SSL are useful, but don’t completely mitigate against man-in-the-middle (MITM) and man-in-the-browser (MITB) attacks. Better service authentication will become necessary as data thefts become more apparent.

Finally, there’s Identity IN the cloud. This means that the identity service is, itself, a cloud service. This has been referred to as Identity as a Service, and abbreviated as IaaS and IdaaS. In the near term, IAMaaS (Identity and Access Management as a Service) will become the norm, or at least A norm. IAM is well on its way to becoming just one more outsourced service.

For a number of years it’s been very apparent to me that enterprises have lagged well behind current technology in their IAM services. It’s not for want of desire nor is it from lack of need. It all comes down to a case of missing resources: enterprises don’t have either the fiscal capital or the human capital to keep up with the fast changing IAM landscape.

Google Docs and  Microsoft’s Office365 both make the case that using an office suite “in the cloud” means never having to worry about maintenance schedules, upgrade downtime or software patching – three of the major reasons that datacenter software is often one, two and even three releases behind the current version of a software package. By outsourcing your office productivity software to the cloud there’s a tremendous uptick in your organization’s bottom line. Could outsourcing your IAM to the cloud provide similar savings? And, if so, at what cost?

The quick answer is yes, moving your IAM services to a cloud provider can save time and money. As just one example, take provisioning. There’s little question that provisioning services have saved over non-automated methods, but there’s still the question of installing, maintaining and upgrading the software as well as the costs for integrating it with your corporate apps and services – which might reside in either the datacenter or the cloud. Similar savings can be realized by using cloud services for SSO, Role-/Rule-/Attribute-based access control, regulatory compliance (think, for a moment, about your costs for staying current on regulations), even governance. It does seem like a no-brainer, doesn’t it?

There are a few things to consider, though.

How safe is your data? How safe is your connection to the cloud? What about privacy concerns? How reliable is your IAM as a Service vendor? How reliable is the cloud platform your vendor (or you) has chosen?

Moving IAM into the cloud can present a big reward, but does that imply you have to take a big risk?

I don’t think so. Let’s review:

Identity FOR the cloud is a service to control authentication and authorization of enterprise users to cloud-based apps and services.

Identity OF the cloud encompasses methods to assure users that the cloud service they desire to connect to is the one they actually connect to.

Identity IN the cloud, also known as Identity as a Service (IDaaS) is a method of providing Identity services which reside in the cloud but are used for on-premise authentication and authorization.

We’ve made gains over the years even while keeping these different technologies separate – but wouldn’t it be easier for all of us if we could combine the functionality into one Identity Service which is For, Of and In the cloud? Join me and Vikas Jain, Director of Product Management with the Application Security and Identity Products Group at Intel, on March 29 at 11 AM EST for a thorough discussion of how identity services for, of and in the cloud can work to deliver better security with lower cost and easier manageability for your organization. It promises to be a very informative discussion.

Is Google the new Microsoft? That is, is Google now the company that “people love to hate,” so that – no matter what they do – there’s sure to be criticism of them? Ten years or so ago Google was seen as the “white knight” that would vanquish the Microsoft dragon as a worthy successor to Apple in that role. Now, though, it appears that Apple has risen from the ashes and is the valiant warrior that the Google “dark lord” is trying to usurp.
Here in the western hemisphere, the gathering of personal data in order to present ads to you which reflect your interests is considered by many to be a bad thing.

The latest round was a recent story in the Wall Street Journal purporting to show how Google had undermined and sidestepped the privacy settings on iOS devices (and computers) using Apple’s Safari browser.

It would appear that there are two possibilities: 1) the Safari mechanism was flawed; or 2) Google used a loophole or “backdoor”. In fact, both are true but the real culprit here may be the user, aided and abetted by the media – and Apple!

Safari is the only web browser which, by default, blocks third-party cookies. At least, they say they block them. In reality, Apple only blocks brain dead third party cookies since they very happily tell all and sundry under which conditions third party cookies may be allowed. According to Stanford University researcher Jonathan R. Mayer, in fact, Safari’s cookie blocking policy is less restrictive than many competing browser vendors. Specifically:

• Reading Cookies Safari allows third-party domains to read cookies.
• Modifying Cookies If an HTTP request to a third-party domain includes a cookie, Safari allows the response to write cookies.
• Form Submission If an HTTP request to a third-party domain is caused by the submission of an HTML form, Safari allows the response to write cookies.

Third-party cookies, by the way, are defined as those served by a domain different from the one in your browser’s URL bar. So if, for example, your browser is reading from mail.google.com, then any server identified as *.google.com could place a cookie, but a server at any other URL could not. As Mayer points out, though, “Google Analytics is served from google-analytics.com, Google software libraries are hosted at googleapis.com, Google static content is at gstatic.com, and Google’s advertising services are on doubleclick.net.” All of these would be considered “third parties,” even though all are Google owned and operated properties. In the real world, the non-digital world, no one gives a thought to a retailer, say, sharing a buyer’s information with the vendor who made the product. Few, if any, would object to Best Buy telling Apple that I bought a new iPad, even though they are a “third party.”

On the other hand, many of the services that Google offers its users, particularly in the realm of personalization, require that cookies be placed to identify the user, their location, their settings, etc. Many of the services we’ve come to rely on require that cookies be used. Google’s “+1″ and Facebook’s “Like” buttons, which are becoming ubiquitous across the net, are third party tools yet no one seems to complain about them.

If there were an easy way to allow some third party cookies in Safari, and if Google (and others) chose to ignore that method, then there might be reason for the outcry. But Apple tells Safari users why they block these cookies by default: “Some companies track the cookies generated by the websites you visit, so they can gather and sell information about your web activity.” If that’s what I’m told, then I certainly wouldn’t want those cookies placed on my machine! Unfortunately, while the statement is true it is very far from the entire truth. Most cookies, the very vast majority, are not used to gather data to be sold but to tailor, or personalize, the user’s experience.

Rachel Whetstone, senior vice president of communications and public policy at Google, was quoted by the Washington Post: “The Journal mischaracterizes what happened and why. We used known Safari functionality to provide features that signed-in Google users had enabled. It’s important to stress that these advertising cookies do not collect personal information.”

Not to be outdone, Microsoft jumped on the “kick Google” bandwagon when Dean Hachamovitch, Microsoft corporate vice president of Internet Explorer, declared Google was bypassing user privacy settings in Internet Explorer, also. Perhaps true, but so were tens of thousands of other websites, all using methods that Microsoft itself painfully outlined in a Knowledge Base article (since removed, but available on the Wayback Machine).

In what appears to be the final straw, a class-action complaint has now been filed against Google for its circumvention of Safari’s privacy features. The lawsuit, filed in the US District Court for Delaware, accuses Google of willfully violating of the Federal Wiretap Act, the Stored Electronic Communication Act, and the Federal Computer Fraud and Abuse Act.

It’s time for a dose of reality, folks.

The internet and the content it provides costs money to produce. There are five possible ways to fund those costs:

1. Subscription paid by the user (popular with sports-centric sites)
2. Product purchase by the user (Amazon, eBay and the like)
3. Advertising placed by third parties (95%+ of the web)
4. Self-funded by web site owner (such as our own kuppingercole.com)
5. Funding by a donor, foundation, NGO or government body (religious and charitable sites, for example)

While there are good examples of all five, it’s number 3, the advertising model, which is most prevalent at this time. Much of the advertising we see, though, is irrelevant to our circumstances and lifestyle. Some of it can be annoying, irritating and even offensive. To combat this, vendors have unleashed “ad blocking” software for our browsers which is then combated with advertisers creating different ways of launching ads in a never ending cycle. It becomes more annoying and more offensive all the time. It’s a war that won’t end.

Now it’s possible that some people, those who are weak willed for example, prefer to have non-relevant advertising shown to them as it decreases the possibility that they might click through and – maybe – purchase something that they really don’t need. Most of us, though, I’d guess would rather be shown relevant advertising, for products that we might possibly use. But in order to show us relevant advertising the vendors (or, better, the ad-placing entity such as Google’s DoubleClick) need to know something about us. They could ask us what we like and don’t like, and Google does this in a limited way through the Google Ads Preference Manager. But it’s easier, and less intrusive, for Google to simply note where you go on the web and where you spend time. Using its knowledge of these web sites allows Google to personalize (or “tailor”) the advertising you see so that it’s relevant. For the full story of Google and ads, read Google’s Advertising and Privacy policy.

It never ceases to amaze me that so many people confuse privacy with anonymity. It’s a subject I’ve been writing for a dozen years, but is probably best summed up in this 2006 blog post, “Anonymity, identity – and privacy“. Privacy means that only those whom I wish to know something (or who because of their role – doctor, judge, spouse – need to know something) know it. Trying to keep everyone from knowing anything about you is attempting to be anonymous – and there is no true anonymity on the internet. There really never has been nor will there ever be.

But telling people the honest truth evidently doesn’t sell newspapers. So even the Wall Street Journal will resort to sensationalism – and a bit of biased reporting – to get itself talked about. And they’ll be abetted by commercial enterprises (in this case, Apple and Microsoft) who see a distinct advantage in having a competitor savaged. Fortunately, I’m here to set you straight. Your comments are welcome.

It’s been almost 15 years since Business Layers and Oblix ushered in the new age of Identity and Access Management Systems (IAM systems) with what I called at the time the “killer app” for Directory Services – electronic provisioning. Even more incredible is that it’s almost 20 years since I wrote a workflow-based provisioning application (I even called it “employee provisioning”) based on Microsoft’s messaging application programming interface (MAPI). It actually was quite primitive in terms of 21^st century provisioning tools in that it relied on automated email messages to inform people of things that needed to be done (grant access, deliver hardware, etc.) with an automated “nag” system if the task wasn’t marked as completed.

I know that my system is no longer used and I really doubt that the Business Layers’ and Oblix provisioning systems are still in use. But lots of people are still using lots of systems that no longer are offered. In the provisioning area alone I’ll wager that there are still installations from Thor, Waveset, M-Tech, Sun and more none of which are still being offered – at least not under that brand name.

And it’s not only provisioning systems that have gotten “long in the tooth” in your datacenter. Every aspect of IAM has probably moved forward at least one generation since you installed it, and many have moved quite a bit forward. Let me hasten to add that it probably isn’t your fault that this has happened, especially if you’ve followed the advice we’ve been handing out over those fifteen years since electronic provisioning first became a real possibility and the IAM revolution was launched.

Back then, and for some time after, no one vendor could supply all of your IAM needs. It’s possible to argue that that is still true, but – if it is – it’s less true today than it was, say 10 years ago. So what we, the IAM gurus, suggested was that you choose “Best of Breed” solutions and hammer them together. “Best of Breed” was an amorphous term, though, covering a great many things. In reality we meant “best for you” depending on your circumstances.

Getting all of those apps from all of those vendors to work together was a real chore – one that kept IAM consultants rolling in dough as they cobbled together scripts, apps, services and more so that you had a semblance of an IAM infrastructure.

Anyone who had gone through the experience of surveying the market, demo’ing software or trying out a “proof of concept” from multiple vendors for each area (Provisioning, SSO, Access Control, Governance, etc.) of the IAM continuum came through the exercise very tired, very bruised and very wary of starting again.

Over the years, the apps that were chosen were sometimes updated (by the customer – they were frequently updated by the vendor) whenever doing so wouldn’t break the intricate relationship with the rest of your IAM services. Sometimes – when a vendor was acquired – the app you were using would simply disappear from the market to be, perhaps, replaced by something similar (or not) depending on the whims of the new vendor.

What it all means is that those of you who should be commended for being the early adopters in the IAM space are, essentially, stuck with a cobbled together system which in many of its facets is no longer supported by its vendor, or may not even have a vendor to support it any longer.

Others of you, of course, would have spent an inordinate amount of time replacing parts of the system as mergers and acquisitions occurred. So you may have started out with Business Layers’ eProvisionware as a provisioning app. When that company was acquired by Netegrity, you might have switched your provisioning services to the leader at that time, Waveset. Waveset which, less than a year later, was acquired by Sun Microsystems. Still, you might have stayed with the people you know and, gradually, installed Sun Identity Manager. Which has now been acquired by Oracle.

Another possibility is that you, early on, went with Oblix for provisioning. Until they were acquired by Oracle early in 2005. Well, you quickly switched to the then highly recommended independent provisioning vendor – Thor Technologies. Which was acquired by Oracle!

Where does it all end? Will Larry Ellison eventually acquire everyone in the IdM space? Probably not, at least not as long as there are other major players. But what does it mean for you?

Two points I want to make up front:

• What was “Best of Breed” a few years ago may no longer be;
• Choosing “Best of Breed” today may be a security nightmare.

Yesterday’s “Best of Breed” was probably a stand-alone application from a vendor who was committed to a particular IAM niche. For example, PassLogix was long thought the Best of Breed Enterprise Simplified Signon (ESSO) solution. When that company was acquired 18 months ago, though (by, you might have guessed, Oracle) others who were using the product began to scramble to find a replacement – it was no longer feasible to add Passlogix’ V-Go ESSO to the other multi-vendor IAM apps you were using.

But the whole idea of a Best of Breed IAM stack from multiple vendors needs to be re-thought. The Best of Breed IAM stack was never seamlessly integrated. Scripts, publicly available protocols, data conversion hubs and some manual tweaking always seemed to be needed to insure that everything worked together. And it almost did work together. At the best of times it was probably 95% successful. But that 5% was the camel’s nose in the IAM tent.

That 5% “seam” – which for most installations was closer to 10% or 15% – is the area that hackers, crackers and other malcontents can exploit for their nefarious purposes. That’s where the security loopholes appear,Which can sometimes end up being close to 80% of your project cost, not the 5, 10 or 15% it should be.

So if your current Best of Breed solution is insecure and too complex, and if there’s really no way to improve its security by adding updates, upgrades or other potential Best of Breed applications, what should you do?

It’s time to move up a level. Rather than “Best of Breed” applications, it’s time to look at “Best Fit” suites.

You might think that with all the mergers and acquisitions of the past ten years that provisioning applications, in particular, would be offered by only a handful of vendors, but you would be wrong. Here’s a list of almost two dozen vendors offering provisioning solutions from very basic to extremely complex.

Well that didn’t take long.

Less than a week after I predicted that “2012 could be a very good year for privacy,” Google announced a new privacy policy, one which would apply across almost all of its services. Far from being seen as a good thing, though, the initial reaction was a large outpouring of grief by the privacy community. Even the general media portrayed the move in a dark light.

The Washington Post, for example, was quick to point out that “A user signing up for Gmail, for instance, might never have imagined that the content of his or her messages could affect the experience on seemingly unrelated Web sites such as YouTube.”

Some of the headlines for the stories about the change:

• Google Privacy Change Provokes Outrage (Information Week)
• Use Google? Time to Get Real About Protecting Your Digital Self (The Atlantic)
• How to close your Google Account (The Washington Post)
• Google’s New Privacy Policy Raising Questions in Washington (AdWeek)
• Google changes privacy policy to make the company one big product (VentureBeat)
• Google Changes Again, Launches One Privacy Policy to Rule Them All (Mashable)
• Google’s new privacy policy: Is this war? (KPCC radio)
• Big Brother? Google’s new privacy policy creates one massive database (Tecca)

And there’s many more just like them.

Common Sense Media claims to be “…dedicated to improving the lives of kids and families by providing the trustworthy information, education, and independent voice they need to thrive in a world of media and technology.” Their chief executive, James Steyer, was quoted in the Washington Post article as saying: “Google’s new privacy announcement is frustrating and a little frightening. Even if the company believes that tracking users across all platforms improves their services, consumers should still have the option to opt out — especially the kids and teens who are avid users of YouTube, Gmail and Google Search.”

Of course, everyone does have the option to “opt out,” by not using the service. Well, there is another way, which I’ll tell you about later.

Not all of the media was negative, though. Forbes magazine noted in its headline: “Internet Freak-out Over Google’s New Privacy Policy Proves Again That No One Actually Reads Privacy Policies”.

Google isn’t going to be collecting any more, or any different, information with this policy change. As explained in a Google blog entry (by Alma Whitten, Google’s Director of Privacy, Product and Engineering): “…we still have more than 70 (yes, you read right … 70) privacy documents covering all of our different products. This approach is somewhat complicated.” So the company is taking 60 or so of them (the others have legal reasons to be kept separate) and rolling them into one which “…covers the majority of our products and explains what information we collect, and how we use it, in a much more readable way.”

As a consequence of this, the new policy “…makes clear that, if you’re signed in, we [i.e., Google] may combine information you’ve provided from one service with information from other services. In short, we’ll treat you as a single user across all our products.”

Again, nothing new will be collected; it will simply be amalgamated into one record rather than 2, 5, 15 or more under the current policy. Will this help users, or hurt them?

The jury is still out on that, of course, but I personally believe it will help many more people than it might possibly hurt. The telling point is who gets to see that accumulated data.

As the above cited blog post notes, “We remain committed to data liberation, so if you want to take your information elsewhere you can. We don’t sell your personal information, nor do we share it externally without your permission except in very limited circumstances like a valid court order. We try hard to be transparent about the information we collect, and to give you meaningful choices about how it is used.”

Ah, so how will it be used?

Generally, Google’s critics and the company itself agree that the data will be used to personalize your experience across the multiple Google platforms (search, Gmail, Google+, YouTube, Android, etc. – each of those “70 plus” privacy policies referenced earlier refers to a different service/platform). Some see that as, well, in Gizmodo’s words: “The End of ‘Don’t Be Evil’.”

Google, though, thinks this will – for the great majority of its users – improve their on-line experience and improve it dramatically.

Not only will the search engine know more about what you’re searching for (if you enter “Jaguar” as a search term, do you mean automobiles or wild animals?), but it can tailor the advertising you see (and you will see advertising) to your tastes and desires. So if I enter “Mannequin Pis” as a search term (or to find pictures) I might see that priority is given to the famous Brussels statue or it might be to the restaurant in Olney, Maryland (about 10 miles from my office). The deciding point might be where my Android phone indicates I’m located at the time I search.

Some people find that “creepy.” I’m not one of them.

For twenty years I’ve been waiting for a personalization service like this. It was one of the reasons I became so interested in directory services and, later, identity services. It’s the promise of being my personal assistant, in theory, that’s finally being delivered.

One example that Google’s Whitten points out: “We can provide reminders that you’re going to be late for a meeting based on your location, your calendar and an understanding of what the traffic is like that day.” She could have added that emails could be automatically sent to other others scheduled for that meeting letting them know you would be late – and actually reschedule the meeting knowing what their calendars look like and approximately how long it will take you to get to the office. I find that to be an excellent use of technology. If it also means I’ll see more ads for cruises, antiques and restaurants (things I’m interested in) and fewer for shoes, fast food and skiing (which I’m not interested in) then I consider that a plus.

Now, if Google was going to package this information and distribute it to its advertisers or sell it to other third parties to do so, then I’d be in the forefront of those protesting – and I’d quite possibly be looking to replace those Google services I do use. But they aren’t. Google’s policy regarding this data stays the same, “We don’t sell your personal information, nor do we share it externally without your permission. [emphasis added]” No one has ever shown that Google violates this pledge.

Forbes’ Kashmir Hill sums it up best, I think: “When Google starts bundling everything it knows about its users and selling that to insurance companies, background check companies, and the Department of Homeland Security, that’s when I’ll trot out the ‘evil label.’ But using information from Gmail to suggest more appropriate YouTube videos or reminding an Android smartphone user that they have a Google calendar appointment in a half hour on the other side of town doesn’t strike me as the work of Lucifer.”

I did promise you a way to stop Google from amalgamating all of your data, didn’t I? It’s quite simple, just create separate accounts for the services you want to keep separate – Gmail, YouTube, Picassa, what have you. Google can’t force you to put every service under one account, so you can do this to maintain relative privacy – just remember which accounts cover which services!

In other privacy news, the EU has proposed updated regulations covering data breaches and the mis-handling of personal information. Companies could face penalties as high as 2% of their yearly global sales (not just EU sales) but, on the plus side, companies would now only have to deal with the privacy agency of the country they’re headquartered in rather than face all 27 EU data-protection agencies. So, stricter rules, bigger “teeth” in the law but easier compliance – it’s too soon to tell if this is a plus or a minus – and for whom.

Finally, a new debate is starting in the US about privacy and healthcare. Some have proposed what’s called a universal patient identifier, or UPI – a single unique health-care identification number for every inhabitant. This would be very useful for doctors, emergency workers, hospitals, pharmacists – and patients. Proponents say UPIs not only facilitate information sharing among doctors and guard against needless medical errors, but may also offer a safety advantage in that health records would never again need to be stored alongside financial data like Social Security numbers. Privacy activists say the data would be collected and sold to third parties causing a rise in distrust of the medical profession and a deterioration in care. Expect this debate to go one for quite some time.

Here at KuppingerCole we’ll be following these issues – as well as all identity privacy issues – as they play out round the world.

Happy New Year! At least, I sincerely hope the new year will be a happy one. But – at least in the Identity and Access marketplace – I fear it will be more of the same with banner headlines touting security breaches, insider scams and worse. Without further ado, here’s what my crystal ball sees coming down the pike in 2012.

Phishing ramps up, especially spear-phishing
Phishing is the hacker’s “art” of getting authentication and/or identity information through social engineering methods. Typically this is done via email (for example, telling you to click a link to keep your bank account credentials updated) but can also be done by means of social networking sites (such as Facebook or Twitter). Spear-phishing is typically a combination of the two, when company information is harvested from, say, Facebook or LinkedIn then people in that organization are targeted via email. This was the method used for the RSA breach which has now been attributed to persons acting on behalf of a nation-state (rumored to be China, but no “smoking gun” has been revealed).

Standard old-fashioned phishing, due to its “scatter-shot” nature, is fairly easy to combat with email security apps. Bayesian filters, originally developed to keep spam out of your inbox, can be equally effective with the phishing emails which are usually about bank accounts, on-line retail accounts or other sites where credentials and/or credit card numbers can be expected to be found. Typically, the email recipient is re-directed to a fraudulent web site made to look like the legitimate one, or given an attachment with the email described as a form to fill out (with loads of identity information requested) which must be submitted in order to “regain access” to the site in question.

More recently, the attachments have included a Trojan-like payload which is insinuated onto the recipient’s computer when the attachment is opened and this is the preferred method for spear-phishing attacks. For example, the RSA attack was an email with the subject “2011 Recruitment Plan.” Attached was a spreadsheet titled “2011 Recruitment plan.xls.” The spreadsheet contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (since corrected by Adobe).

It’s extremely difficult, if not impossible, to automate a defense against spear-phishing. Draconian measures would be needed such as forbidding employees to put company information on social networking sites or quarantining all email with attachments. The only effective measure in combating these types of attacks is user education. It’s expensive, it’s time-consuming and it’s less than 100% effective. In the RSA case, the infected employee retrieved the spear-phishing email from their trash folder!

Your money is better spent in strengthening protection on your valuable assets. Data encryption, for example, could have saved quite a few companies embarrassment in 2011, such as security consultant STRATFOR. Vow right now to encrypt all valuable data and all identity data for your organization.

New buzz words and phrases
A buzzword you may or may not hear, but that you will surely be a target of is “cloudwashing.” By this is meant the effort by vendors to associate all of their products with “the cloud” as in cloud-based computing. Whether or not the product has anything to do with cloud-based computing it will, nevertheless, be touted as somehow enabling or protecting cloud data, access, configuration, or what have you. Don’t take their word for it, ask them to demonstrate these cloud properties before you buy. While the cloud is evolutionary, not revolutionary, it still has some unique requirements in the areas of identity and security that need to be properly addressed by apps and services designed specifically for that use – not one’s which only had their marketing brochures reprinted.

We first heard about BYOD (Bring Your Own Device) in 2011 in regard to employees wishing to add connectivity to the corporate network for their iPhones and iPads. 2012 will also see them wanting to connect their Android devices (phones and tablets) so that they can do the organization’s business “their way.” While your first thought might be to resist this effort at all costs, that “cost” could be your job. Your boss, and his boss all the way up will want to use their own devices (which are probably more powerful than the company issued ones). Instead, start working now on how to safely allow them to attach to the network. Make it part of your provisioning process, so that you can quickly and easily de-provision them when the need arises – which it will, as devices become lost or stolen and employees come and go. The concept of BYOD isn’t new (I was first approached by a marketing VP with such a request back in 1987), but the emphasis is about to become dominant.

All new attack vectors, now with bright, shiny things
Malware, and malware purveyors, continually evolve. 2012 won’t halt that trend. I mentioned above the spear-phishing attacks, such as the one against RSA, which delivered a malware payload as an attachment to email. That’s a trick used in more generalized phishing, also, but the more used method is to phish someone to click on a link to a website (which might be disguised as one trusted by the target user) where a payload is surreptitiously attached to the target’s computer. But these attacks require the target to either open an attachment or click on a link that, hopefully, an educated user would recognize as a phishing attempt. So the hackers and crackers are developing new attack vectors.

One of the more insidious is to attack advertisement servers (such as Google’s DoubleClick service), either through “traditional” hacking into the server or by spear-phishing people with access to the server. These sophisticated attacks (see one description here) are hard to track down because they can be delivered from any site which uses ads from that server while the malware isn’t delivered with every ad request. You might think you got infected at funnykatz.com, but if you go back there you’ll find no evidence of something bad downloading to your machine.

Good, up-to-date anti-malware services should be installed for all users, but better education of those who have access to the powerful machines in your domain is also required. It’s really best to lock the door before the horse has a chance to wander outside!

Finally, the good news
It isn’t all gloom and doom for 2012, I feel. There will be decided improvements on the privacy front. Not a complete victory, by any means, but an improvement.

The concept of Privacy Enhancing Technology (PET) isn’t new. It was defined almost 10 years ago in “Handbook of Privacy and Privacy-Enhancing Technologies” as “…a system of ICT measures protecting informational privacy by eliminating or minimising personal data thereby preventing unnecessary or unwanted processing of personal data, without the loss of the functionality of the information system.” Microsoft’s recently acquired uProve technology is a current example. I think we’ll see more of technologies like this in coming software offerings because of another “overnight sensation” that was many years in the making.

Way back in the last century, Dr. Ann Cavoukian came up with the concept of “Privacy by Design.” Here’s how she described it:

“Back in the ’90s, it was clear to me that the time was upon us when legislation and regulation would no longer be sufficient to safeguard privacy. In my view, with the increasing complexity and interconnectedness of information technologies, nothing short of building privacy right into system design could suffice. So I developed the concept of Privacy by Design (PbD), to describe the philosophy of embedding privacy proactively into technology itself – making it the default.”

In other words, privacy shouldn’t be the icing on the cake, put on after the cake cools. It should be a major ingredient baked right in from the start.

Consider Facebook. A typical week or month at the social networking site goes like this:

1. Facebook rolls out a re-design or a new feature to “enhance the user experience” (in reality, to enhance the advertiser’s experience);
2. Privacy advocates discover all sorts of hidden flaws;
3. Facebook scrambles to make corrections;
4. Repeat.

Now that Dr. Cavoukian is the Privacy Commissioner for Ontario province in Canada a lot more people are paying attention to Privacy by Design and encouraging software vendors and service providers to incorporate the philosophy into their work by building in privacy from the start. Pressure from the growing privacy community will force the vendors to comply. 2012 could be a very good year for privacy.

In order to “accentuate the positive,” I’ll be hosting a webinar on January 26 on the subject of Privacy by Design. Joining me will be Dr. Cavoukian to explain the concept, Michelle Dennedy (Chief Privacy Officer at McAfee) creator of the iDennedy Project and author of the “Privacy Matters” blog as well as a surprise guest from the vendor community. Please join us for this fascinating topic.

Passwords have been the security standard for thousands of years, ever since they replaced biometrics as the preferred method of authentication.

Biometrics? That’s right. From pre-historic times access to secure sites (food/money storage, military camps, etc.) was biometrically controlled – the guard either recognized you or didn’t. If he recognized you and was aware that you had clearance then you’d be allowed access. Otherwise, you might get run-thru with a sword.

But as the population needing access to secure sites increased, it was no longer possible for every guard to know every authorized person. So the password was invented, and – try as we might – it’s still the most popular way to gain access to secure sites.

I’ve been writing about – and railing against – passwords for far too long now. Back in 2006 I ranted at the University of Pennsylvania for their then new policy of forcing users to change passwords annually! Then in 2009, I castigated the US National Institute for Standards and Technology for publishing “Guide to enterprise password management.”

Every identity and security guru worth his salt has at one time or another (and often more frequently) said that: 1) you should stop using username/password as an authentication method; and 2) if you must use passwords, make sure they are “strong” passwords.

There are two components to strengthening passwords:

• Length – make your passwords long with eight or more characters.
• Complexity – include letters, punctuation, symbols, and numbers. Use the entire keyboard, not just the letters and characters you use or see most often. The greater the variety of characters in your password, the better. However, password hacking software automatically checks for common letter-to-symbol conversions, such as changing “and” to “&” or “to” to “2.”

Therefore it was with a feeling of deep chagrin that I recently read a report from mobile application vendor SplashData that compiled a list of 25 most common passwords used on the Internet this year. They did this by scouring files containing millions of stolen passwords posted online by hackers. The top 10 most frequently used were:

1. password
2. 123456
3. 12345678
4. qwerty
5. abc123
6. monkey
7. 1234567
8. letmein
9. trustno1
10. dragon

Some would be quick to point the finger at the iPhone generation for these easily guessed passwords, but as my former colleague, Ping Identity’s John Fontana, pointed out: “A 1990 study of Unix password security showed a user preference for weak passwords, such as ‘password’ and ‘12345’. By the mid-90s, ‘abc123’ joined those two padlocks of password security.” So, really, we’re all to blame.

AS a side note, security expert Bruce Schneier reported in 2006 that among the 20 most popular passwords on MySpace.com were “monkey” and “monkey1”. I’ve only checked English language passwords, but I do wonder if among the top 20 German passwords we  can find “affe” and “affe1”.

It is evident that users do not want to give up using passwords. Nor, for that matter, do most application and service programmers. It’s also evident that users avoid strong passwords. And when they are forced to use strong passwords (or have them automatically generated), anecdotal evidence shows that the users will write them down and keep them close by their keyboard (or other input devices).

So what can we do?

For years I used a browser add-in called “Sxipper,” developed by Dick Hardt who was a co-founder of OpenID. Sxipper was not only a tool to remember usernames and passwords (as well as all the details needed to fill out forms) but was also a password generator, creating randomized groupings of letters, numerals and other characters that were well past the ability of most users to remember. But, of course, they didn’t need to remember them – Sxipper did it for them. Sxipper could save a file containing all of your data to local storage (in case there was ever a problem) but, sadly, this wasn’t encrypted, nor was authentication required to access Sxipper once your computer was up and running (i.e., authenticate to the OS and you could run Sxipper). Sxipper was officially killed early this year.

Even before that, though, I’d switched to using Chipdrive MyKey from SCM (now Identiv). Besides encrypting the archive file, it uses a USB stick which makes the service portable among all of your USB-enabled devices. It doesn’t, unfortunately, create passwords so I do need to be disciplined about that.

But Sxipper and MyKey are, essentially, single user solutions. What is the enterprise to do?

Some would suggest enterprise simplified signon (ESSO) is the answer, but most of those allow the user to choose their own passwords and simply, passively, deliver them up as needed. That doesn’t allow for enforcing of a strong, non-reusable, frequently changed password policy.

Instead, my suggestion is to adapt one of the Privileged Account Management (PAM) tools to the entire enterprise. There are plenty to choose from, offered by vendors such as: BeyondTrust, Cyber-Ark, Quest Software, Thycotic Software, Apere, Avecto, Xceedium, Fox Technologies, i-Sprint Innovations, Lieberman Software and Siber Systems. Some of these are stronger than others, and prices vary accordingly.  None is right for everybody, so investigate to discover which is right for you.

To take one example, though, let’s look at Cyber-Ark’s Enterprise Password Vault (EPV). Not only will EPV securely store passwords, but it will also generate strong passwords and change them regularly – up to doing so after every use! It will, of course, also audit and report on the use of those passwords. The icing on the cake is that you can by-pass username/password for accessing EVP – RSA SecurID, Web SSO, RADIUS, PKI and smartcards are all configurable methods for connecting to the vault.

Sad to say, passwords are not going to go away anytime soon. Users, and developers, won’t let them. But at least we can insure that the strongest passwords are used, without the chance for compromise by the very users they’re meant to protect.

That’s my Christmas present to you, insure a prosperous New Year by creating (or modifying) your password policy and finding the best way to enforce it. Happy Holidays!