Blogger: Ian Glazer
A friend in the industry recently asked me for my thoughts on OpenID, InfoCards, and the US federal government's work to consume non-government issued credentials. Letting the question rattle around in my head for a while, here's what I've got so far.
My hope is that the overall ICAM initiative is successful—not because I have been eagerly waiting to interact with the federal government using some form of authenticated credential—but because we (citizens, enterprises and government) are at a pivotal moment in the history of the web. With the US government working with both the OpenID and InfoCard Foundations, there exists an opportunity to change how individuals interact with large organizations, both public and private. For the first time, individuals would be able to (even encouraged to) interact with a large organization (such as the US federal government) using an identity asserted, not by the large organization, but by the individual. In this case, the State is no longer the sole provider of identity. This breaks the monopoly that the State has had on credentials and is indicative of the future to come.
But there is a long road to walk before getting there. There are numerous concerns with these plans. Among these are notable security concerns, especially with OpenID, that the identity community is not blind to. These are not my primary concerns.
My primary concern is with the establishment of standard user behavior that could prolong existing problems. Today, after decades of enterprise training and a decade of consumer training, people naturally expect to see two text boxes on web sites. One is for their username and the one with the little stars is for their password. This behavior is ingrained. Changing this behavior is no small feat - just ask the OpenID and InfoCard groups. But it is a change that must occur to normalize people using something stronger than username and passwords to authenticate themselves.
My concern is that the behavior that is being established as a norm - the use of either an identity selector or some other user interface means - will become the username/password for the next generation. This isn't a hypothetical problem; the writing is already on the wall. Currently, OpenID will only be accepted for low-value transactions with the government known as Level of Assurance 1 (LOA1). Activities like filing tax returns requires a far greater assurance that the person is who they claim to be and thus require a Level of Assurance 3 identifier. And there is problem. The way people use an LOA3 credential may be very different than how they do so with an LOA1 credential.
If we, as an industry, normalize user behavior that meets LOA1 needs but not LOA3, we are training in behavior that has to get untrained in a near future. What the government and its partners are on the path to doing is effecting real cultural change. This kind of change doesn't happen often and is hard to do, and especially hard to undo.
I definitely want a future in which I can assert my own identity without validation from the State, but I am very willing to wait for that future to assure that the behavior the industry normalizes is one that will work for generations to come.
Don Bowen, our former colleague and dear friend lost his battle with cancer yesterday. Our deepest sympathies go out to Don’s family during this difficult time.
You will never meet a person that was as inspirational as Don. Whether in good times or bad, Don was always upbeat, energetic, and intense. During his illness, we also saw the strength of his faith, which was unwavering. Don has left a huge void in our lives and we will miss him for a long time.Blogger: Mark Diodati
Today, RSA and VeriSign announced a partnership where VeriSign can resell SecurID OTP tokens via its VIP managed authentication service. RSA can also resell the VIP authentication service.
The press release implies that the relationship between RSA and VeriSign has been co-operative and amicable. Don’t be fooled. In early 2005, VeriSign was the primary driver for the OATH industry group, expressly created to take on RSA’s “cash cow”–its SecurID OTP business. Since that time, VeriSign aggressively pursued RSA’s SecurID customers and competes against RSA in the consumer authentication space.
As applications move to the cloud (e.g., SaaS), it is essential that users are not required to carry more than one OTP to access SaaS applications from different providers. This scenario is very similar to what we’ve seen in the enterprise—the “token necklace”. Users carried multiple authenticators around their neck because the authentication domains did not speak to each other. RSA and VeriSign launched managed authentication services (the aforementioned VIP service and RSA’s Go ID service) which can overcome the token necklace issue by enabling many organizations to leverage a single token for authentication. Now that RSA can resell the VIP service, is this the end (or more likely, the de-emphasis) of RSA’s Go ID service?
This agreement provides VeriSign with some powerful capabilities. The VIP service will now work with both VeriSign (OATH-based) and RSA SecurID tokens. It’s likely that customers can mix and match token types based upon their application support and price requirements. Because VeriSign can bundle SecurID into its managed service, I believe it got the better part of the deal.
RSA derives two benefits from the partnership. Presumably, RSA will sell more SecurID tokens. Also, RSA’s ability to resell the VeriSign managed service gives broader entry into the managed authentication services market and with it the ability to better address the emergence of cloud applications (which enables RSA to sell more tokens).
Over time, the OTP form factor of choice for cloud-based applications will be the software token installed on the user’s mobile phone. We discuss this in our research document “More, More, More: The Challenge of Extended Enterprise Authentication Mobility” (subscription required).
Blogger: Bob Blakley
Andrea DiMaio of Gartner recently posted a blog entry entitled "Forget Privacy: It Is Just An Illusion".
DiMaio's lament rephrases Scott McNealy's famous quote ("You have zero privacy anyway. Get over it.")
McNealy was wrong then and DiMaio is wrong now; they're both dead wrong, and it's important.
Here's DiMaio's key sentence:
I have come to realize that, does not matter how careful we are, we are going to lose control of our privacy.
But Andrea DiMaio never had control of his privacy. And nothing - including technology - was ever going to give him control. DiMaio and McNealy assume without saying it that privacy means "keeping personal information secret". And by that definition privacy is an illusion. But "keeping personal information secret" is the wrong definition of privacy. As long as your personal information is secret, you don't even have a privacy problem. It's only when somebody else knows your personal information that you have a privacy problem.
Privacy is the problem you have after you share sensitive information.
When you discover that you might have a socially awkward medical condition and you go to the doctor, you don't keep the condition secret from him - you tell him about it so that you can get treated. And when you leave the office, you don't control your doctor; you trust him with your secret. You trust him with your private information because he has taken an oath to behave sociably and to use your personal information only in ways which benefit you.
That's how privacy works; it's not about secrecy, and it's not about control: it's about sociability. Privacy is a social good which we give to one another, not a social order in which we control one another.
Technologists hate this; social phenomena aren't deterministic and programmers can't write code to make them come out right. When technologists are faced with a social problem, they often respond by redefining the problem as a technical problem they think they can solve.
In rhetoric, we call this redefinition of the problem "framing".
The privacy framing that's going on in the technology industry today is this:
Social Frame: Privacy is a social problem; the solution is to ensure that people use sensitive personal information only in ways that are beneficial to the subject of the information.
BUT as technologists we can't (as DiMaio observes) control peoples' behavior, so we can't solve this problem. So instead let's work on a problem that sounds similar:
Technology Frame: Privacy is a technology problem; since we can't make people use sensitive personal information sociably, the solution is to ensure that people never see others' sensitive personal information.
We technologists have tried to solve the privacy problem in this technology frame for about a decade now, and, not surprisingly (information wants to be free!) we have failed. DiMaio now wants to give up. But he's forgotten the reframing; he's assuming that the technology frame is the problem, and therefore if the problem can't be solved in the technology frame it can't be solved.
The technology frame isn't the problem. Privacy is the problem. Society can and routinely does solve the privacy problem in the social frame, by getting the vast majority of people to behave sociably. Privacy isn't a new problem. It's existed in all human societies for as long as there have been human societies. Lawyers have solved it. Doctors have solved it. Priests have solved it. Friends have solved it. They've solved it by creating social structures which discourage monstrous behavior. We even have words for people who violate the often unwritten and unspoken rules governing the handling of delicate personal information; in the old days we called a man who was careless with others' secrets a "cad". Nowadays we use another word (a word which also has an anatomical denotation, if you're wondering).
Technology can't solve privacy problems, because they're not technology problems. But technology can make privacy problems worse, by making it easy to do antisocial things, or by making it hard to recognize the sensitivity of personal information and lowering our awareness that we're in a social situation and need to behave sociably; online spaces like Facebook, whose rules for handling private information are often opaque to users, create unnecessary privacy hazards in this way (see Ian Glazer's "Privacy Mirror" experiment for an example of how opaque privacy settings can undermine the sociability of an online space).
If we accept the technology frame and let technologists define privacy as control over dissemination of information, we ARE going to have less privacy. Resisting the technology frame is critical; if we don't resist it, lots of bad things happen. For example, if we accept the "privacy is defined as control of secrecy" frame, then we will start to believe (perhaps as a society, and perhaps even as a matter of law) that as soon as someone learns a piece of information about us, that information is no longer private, and we lose subsequent protections.
We don't have to accept the technology frame.
The assumption that led technologists to create the technology frame - that the social problem of getting people to behave sociably cannot be solved - amounts to an assumption that we will all be monsters.
This assumption is neither true nor acceptable. We've got to fight the technologists on this one.
Worldviews have consequences. A worldview that says "privacy is an illusion" can create a world in which there is no privacy, at least online.
My generation makes a distinction between the online world and "the real world". My kids' generation does not. The social world they live in will BE the online world - woven inextricably with what I grew up calling "the real world". I'm not willing to stand idly by and watch the sociability of that world destroyed by technologists who have given up because they can't see beyond their coding pads.
DiMaio concludes his post this way:
The problem for us, all of us, is that somebody will be watching all the time. We’d better behave.
The implied subtext is "because whoever's watching will be a monster, and turn us in to the authorities, and we'll be punished".
DiMaio is deeply irresponsible to encourage the view that just because the cryptographers can't give us a cloak of invisibility online it's OK to be a monster.
But he's right that we'd better behave. When we see someone else's private information, we'd better avert our gaze. We'd better not gossip about it. We'd better be sociable. Because otherwise we won't need the telescreen - we'll already have each other. And we'll get the society we deserve.
We are our brothers' keepers. We'd better start acting like it.
Technologists have a critical role to play in protecting privacy - but that role isn't building walls of secrecy. It's in building sociable spaces in the electronic world.
A sociable space is one in which people's social and antisocial actions are exposed to scrutiny so that normal human social processes can work.
A space in which tagging a photograph publicizes not only the identities of the people in the photograph but also the identities of the person who took the photograph and the person who tagged the photograph is more sociable than a space in which the only identity revealed is that of the person in the photograph - because when the picture of Jimmy holding a martini washes up on the HR department's desk, Jimmy will know that Johnny took it (at a private party) and Julie tagged him - and the conversations humans have developed over tens of thousands of years to handle these situations will take place.
A space in which personal information (a health record, say) always comes with metadata indicating who collected it, for what purpose it was collected, and under what terms and conditions it may be used is more sociable than a space in which a piece of personal information may be forwarded into another organization by someone who doesn't even know the information is personal. And so on.
At Burton Group we don't think privacy is an illusion. We think it's a hard issue - very hard - but that's why we're here: to give practical advice on hard issues. Ian Glazer and I have recently updated the privacy coverage our research and analysis customers get as part of their subscription. But privacy is so important and so widely misunderstood that we've decided to release our recent paper free to the public. It's here.
We hope you'll read it. We also hope you'll get in touch. Leave us comments here on the blog, email us, or call and ask for a dialog - even if you're not a customer.
Blogger: Mark Diodati
You may have heard about Symark’s acquisition of BeyondTrust. Symark is best known for its UNIX security product- PowerBroker. BeyondTrust’s primary product is Privilege Manager. Privilege Manager provides authorization (specifically, privilege delegation) for the Windows platform. The product provides Windows Group Policy templates, which enable more granular privilege delegation.
Symark has taken the BeyondTrust corporate name. It’s likely that BeyondTrust will rename Privilege Manager to PowerBroker for Windows. The Privilege Manager acquisition enables BeyondTrust to leapfrog most of its UNIX security product competitors into the Windows access control market. Only CA has a companion product for Windows. Centrify, IBM, Novell, and Quest have roadmapped Windows authorization capabilities for next year (for most of the vendors). It’s interesting that the UNIX security market leaders – CA and BeyondTrust – now possess Windows security products.
I have been skeptical for many years about necessity of a Windows product that is analogous to the classic UNIX security product. Microsoft Windows already provides the functionality that the UNIX security products provide, including centralized IdM, privilege delegation, event auditing, and finer-grained discretionary access control lists (as compared with the standard UNIX model). Windows systems clearly have a different security model and policy enforcement points (PEPs) as compared with UNIX systems. The different PEP model results in distinctive policy sets within the UNIX security product.
Still, “I want (fill in the blank with your favorite UNIX security product) for Windows” is a common utterance from customers; I have heard it, and I know that the UNIX security vendors have heard it, too. When the conversation goes a little deeper, product requirements become more ambiguous.
Ultimately, I think that customers are looking for common activity and forensic auditing, and a single place to analyze the access rights of privileged users. It remains to be seen if a Windows PEP or if privilege restriction capabilities are required.
We’re living in interesting times. Either by acquisition or development, the AD Bridge, UNIX security, privileged account management, and Windows authorization vendors are beginning to cross over into different product classes. Burton Group will be discussing this trend in our September TeleBriefing on September 29/30 – “Markets Colliding: UNIX Security, Active Directory Bridge, Privileged Account Management, and Windows Authorization” (subscription required).
For more information on UNIX security products, please see the IdPS report “Providing a Strong Foundation: The Resurgence of UNIX Security Products” (subscription required).
Blogger: Bob Blakley
9/9/9 was a day of announcements. You’ve already undoubtedly heard about the 64GB iPod touch, and if you’ve also heard about the new Leica M9 you know what to get me for Christmas this year.
But the identity world had its own big news today; the news is that the US Government has teamed up with the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon in creating the Open Identity Initiative.
This is a really big deal, for two reasons.
First, as a condition of playing with the government in this game, OIDF and ICF have had to address the longest-standing and most serious defect in the open identity ecosystem: the lack of a trust infrastructure. “What’s a trust infrastructure”, I hear you cry...
When you receive an X.509 certificate from a PKI provider, you can go to the provider’s site and read its Certification Practice Statement. This statement provides three critical pieces of information:
There’s never been any equivalent of a Certification Practice Statement for open identity providers. Today’s announcement changes that. The Open Identity Initiative has created a Trust Framework Provider Adoption Process which will allow organizations to set themselves up as roots of trust for open identity. Organizations which serve as trust roots will assess the practices and guarantees of identity providers, and they will establish registries of providers and “score” them against a set of identity assurance criteria aligned with the Liberty Alliance Identity Assurance Framework and the OMB M-04-04 and NIST SP 800-63 guidelines.
So, if a few serious organizations sign up to become Trust Framework Providers, we’ll finally have a trust infrastructure for open identity.
The second reason today’s announcement is a really big deal is that, after years of government attempts to create identities and assign them to citizens (via such bad ideas as the UK National ID scheme and the US REAL-ID act), a government has finally recognized that individuals already HAVE identities, and that it’s a better idea, for most purposes, to use these identities than to establish a new government bureaucracy to create new identities – especially if they’re identities people don’t want.
If this initiative succeeds, and I hope it does, it’s almost certain to be a much cheaper route to government consumption of reliable digital identities of citizens than something like REAL-ID would be. And it will preserve consumer choice at the same time as encouraging innovation in commercial identity technology.
So three cheers for Vivek Kundra and the boards of the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon. And while we’re at it, let’s not forget to congratulate OSIS and the Internet Identity Workshop, where many of the technologies behind today’s announcement were developed and more of the ideas were born, and the Liberty Alliance, whose work on the Identity Assurance Framework is the keystone of the trust infrastructure we are finally about to see.
Blogger: Ian Glazer
A few Facebook hacks came across my desk this week. The first set are so called "rogue" applications which do the tediously predictable grab of user information followed by the equally tediously predictable spam-a-palooza. Calling such applications "rogue" is misleading. These didn't start out okay and turn evil somewhere along the way. These apps were built to cause trouble - they are malware. Facebook has a healthy set of malware apps and the number is growing every day. You can easily spot effected Facebook users by their status messages - "Sorry for the email - my Facebook got a virus."
The second hack is of a far more interesting class. Ronen Zilberman, a security researcher, harnessed features of the Facebook platform to unwittingly perform a man-in-the-middle attack on itself. Zilberman documents how the attack works in very clear language. You can even see a video of the attack in action. Why is this a more interesting class of attack on Facebook? First, it doesn't require an application to be added to the victim's Facebook profile. Second and more importantly, this attack fundamentally turns Facebook's goals against itself.
Facebook's mission is to "give people the power to share and make the world more open and connected." Its business is to accomplish this mission before someone else does. This requires that Facebook provide a means to connect as many people, websites and services as possible and as fast as possible. And in the course of this social networking land-grab, it is not surprising that we have seen both Facebook malware and the Facebook's platform being used to support anti-social behavior. The Facebook platform is optimized to provide frictionless connections and sharing of information. But as exploits for ill-purposes increase, Facebook has to act and act in a manner counter to their mission.
Facebook is currently trying to tackle some of its privacy issues with new privacy settings. The changes to the Privacy Settings are in beta, expected to rollout system-wide shortly. I sincerely hope that Facebook simplifies the privacy settings interface while adding more granular controls - though I am not too hopeful this will happen. Furthermore, I am very curious to see if changes in privacy settings will improve the situation I discovered with Privacy Mirror - again, not too hopeful. But changes in privacy settings are just patches on the underlying problem: increased privacy controls and platform restrictiveness are antithetical to Facebook's mission. Until Facebook institutes more control within its platform, we will continue to see more malware and more "interesting" attacks.
In order to achieve its mission, Facebook has to prove that it is a safe space in which its customers can engage in social behaviors. To accomplish this, Facebook must recognize the fact that its users have relationships with each other and that Facebook itself has a relationship with each of its users. These relationships are governed by social norms and are not dictated but negotiated through countless social interactions. These relationships and the rules governing them must be respected in order for Facebook to prove that it is a safe place to make shared information public and keep private information private.
Blogger: Kevin Kampman
On Wednesday afternoon at Catalyst, we closed the Identity Management, Role and Entitlement discussion with a panel consisting of enterprise practitioners Robert Amos of NuStar Energy, Paul Rarey of Safeway, and David Laurance of JPMorgan Chase. Also on the panel were Edward Coyne of SAIC, representing both the Veterans Administration and the INCITS CS1.1 committee responsible for Role Based Access Control (RBAC), and Alan O’Connor, Research Economist with RTI International.
The purpose of the panel was to discuss the challenges and opportunities facing Role Management as a discipline, and how industry can influence continuing efforts in the RBAC standards community. In particular, Alan O’Conner was at Catalyst to learn more about enterprise experiences with roles, in order to advise the National Institute for Standards and Technology (NIST) about areas for future investment.
There were several major observations from the panel. First of all, there was agreement that roles are a business challenge, but as Paul Rarey observed, “talking to the business about roles is a non-starter.” Instead, the conversation needs to focus on business value. Robert Amos cited success in convincing the business to take ownership of roles, however the proper infrastructure must be provided to manage the relationship of roles to resources.
Another challenge is in understanding what roles are about. David Laurance identified that there were seven applications of roles discussed during the afternoon:
NIST and INCITS are interested in addressing implementation issues in organizations; this list represents a good starting point for future activity. It is not just the integration of attributes into applications that needs to be addressed, but guidance for organizations that want to characterize what people do in a meaningful context.
David contributed three challenges for role management:
During the afternoon, Robert and Paul provided excellent case studies about how their organizations successfully accomplished these, and admitted that their efforts are ongoing and would benefit from more consistent processes, procedures, and more effective role management applications. Alan observed that NIST needs these recommendations from industry in order to provide direction to their committees, and both Ed and Alan are soliciting participation of this nature.
Organizations wishing to provide input to RTI’s NIST survey can contact Alan O’Connor (oconnor@rti.org). Those interested in investigating revisions to the RBAC standard (INCITS 359-2004) can get more information about participation by contacting Ed Coyne (ed.coyne@va.gov) or Rick Kuhn (kuhn@nist.gov).
Blogger: Ian Glazer
Over the last two weeks, I have been using my homegrown Facebook application, Privacy Mirror, as a means of experimenting with Facebook’s privacy settings. Although Facebook provides a nice interface to view your profile through your friends’ eyes, it does not do the same for applications. I built Privacy Mirror with the hopes of learning what 3rd party application developers can see of my profile by way of my friends’ use of applications. I have yet to speak with representatives of Facebook to confirm my findings, but I am confident in the following findings.
Imagine that Alice and Bob are friends in Facebook. Alice decides to add a new application, called App X, to her profile in Facebook. (For clarity's sake, by "add", I mean that she authorizes the application to see her profile. Examples of Facebook applications include Polls, Friend Wheel, Movies, etc.) At this point, App X can see information in Alice’s profile. App X can also see that Alice is friends with Bob; in fact, App X can see information in Bob’s profile. Bob can limit how much information about him is available to applications that his friends add to their profiles through the Application Privacy settings. In this case, let's imaging that Bob has only allowed 3rd party applications to see his profile picture and profile status.
After a while, Alice tells Bob about App X. He thinks it sounds cool and adds it to his profile. At this point if App X, via Alice’s profile, looks at Bob’s profile it will see not only his profile picture and status but also his education history, hometown info, activities and movies. That is significantly more than what he authorized in his Application privacy settings. What is going here?
It appears what's going on is that if Alice and Bob both have authorized the same application, that application no longer respects either user's Application Privacy settings. Instead, it respects the Profile Privacy settings of each person. In essence, App X acts (from a privacy settings point of view) as if it were a friend of Alice and Bob and not a third-party application.
Putting my privacy commissioner hat for a moment, I’d want to analyze this situation from a consent and disclosure perspective. When Bob confirms his friendship with Alice he is, in a sense, opting in to a relationship with her. This opt-in indicates that he is willing to disclose certain information to Alice. Bob can control what information is disclosed to Alice through his Profile Privacy settings and this allows him to mitigate privacy concerns he has in terms of his relationship with Alice.
What Bob isn’t consenting to (and is not opting in to) is a relationship with Alice’s applications. Bob is completely unaware of which applications Alice currently has or will have in the future. This is an asymmetry of relationship. It is entirely possible that Alice and Bob will have applications in common and once they do the amount of profile information disclosed (by both of them) to an application can radically change and change without notice to either Alice or Bob. Furthermore, it is unclear which Facebook privacy settings Bob needs to manipulate to control what Alice’s applications can learn about him.
This lack of clarity is harmful. It shouldn’t take a few hundred lines of PHP, three debuggers, and an engineering degree to figure out how privacy controls work. This lack of clarity robs Facebook users of the opportunity to make meaningful and informed choices about their privacy.
This experiment started after I read the Canadian Privacy Commissioner’s report of findings on privacy complaints brought against Facebook. This report raised significant concerns about third-party applications and their access to profile information.
As of the beginning of Catalyst (today!), Facebook has about 15 days remaining to respond to the Canadian Privacy Commissioner’s office, I hope that this issue about third party applications and privacy controls is meaningfully addressed in Facebook's response.
Blogger: Gerry Gebel
We are very pleased to have Bob Mocny, director of DHS’s US-VISIT program speaking during the privacy track next Friday, July 31. Bob’s abstract, listed below, fills out an incredible privacy agenda and ensures that you will be handsomely rewarded if you stay for the full Catalyst conference. Privacy debates abound in many circles and you’ll hear several next week as speakers from Covisint, Future Identity, UCLA, Georgetown University, and Google share their issues, concerns, and opinions of privacy.
Mr’s Mocny’s session info:
A Dual Mission: Identity Management and Privacy Protection in the Federal Government
Advances in identity management technology are providing significant security benefits to the U.S. government. At the same time, federal privacy statutes require the protection of personally identifiable information collected, stored and accessed by government officials. Learn how one federal program is successfully integrating the use of biometric technology and privacy protection requirements to enhance the nation’s security. Robert Mocny, director of the U.S. Department of Homeland Security’s USVISIT program—one of the world’s largest biometric identity management systems—will discuss how the program’s privacy strategies earn public trust and contribute to the overall success of the program. The practices employed by USVISIT are applicable in both public and private sectors and important for everyone involved in developing and implementing identity management systems.