Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.
I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.
This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.
I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.
I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.
But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy — but is more aligned with client business needs.
I’ve been thinking about how the public sector model for identity has changed in recent years from one where the government body controls the credential AND acts as an identity provider, to one where the credential management is delegated to a service provider. Social media login and, at the premium end, SecureKey’s briidge.net are examples of this model.
Social media credentials from Twitter, Facebook and Google are used everyday by millions of Canadians. Why not leverage these existing accounts to access government services?
The problem I have when talking to clients about these solutions is the assumption that any credential service provider (CSP) will do. That is, a public organization can (and should) readily accept any common credential, add a layer of identity proofing, create a link back to the credential (for future access) and start counting the costs saved. After all, it is all about citizen choice isn’t it?
This isn’t as simple issue. There are some fundamental problems with using low-end credentials, such as social media logins, that need to be carefully considered when delegating authentication to a third party:
Operational Disruptions — There was a great post from the Basecamp blog a few years ago (since deleted) that described how difficult it was to maintain the link between a credential provider and the site. This post talked specifically to OpenID and how changes to the credential may not be properly shared with relying parties, resulting in support calls and manual fixes. Users would also forget which OpenID account they used, and Basecamp had no automated way to reconnect them. In the end, disruptions were common for OpenID users, support costs spiked, and Basecamp discontinued its use.
Longevity — Which social media credential providers are going to be around for the long run? What consolidations of login services or outright mergers are coming? How might the protocols for social media login change? For a public-sector service wanting to provide stable, long-term services, picking the right credential service providers is extremely difficult.
Wrong Message — Social media companies (Google, Facebook, even LinkedIn) often misbehave when it comes to privacy. They routinely run afoul of privacy commissioners and even irritate their user bases when ever-invasive features are introduced. Given the poor privacy records, should a public-sector website be encouraging the use of social media login to access government services? What are the downstream risks?
Convenience — Social media login can certainly save time when it comes to authentication. I use my Twitter account to access Level 1 (low value) services frequently. I’ll admit it is convenient and I like that blogs, news websites and the like offer this option. But convenience is far less important to me when accessing my personal information on a government website. First of all, security and privacy protection matter a lot more. Further, I don’t access these sites all that often so if I have to login (or request an automated password reset) it isn’t that big of a deal to me. What would be more useful would be a common credential for all of a particular government’s services, so that I can experience single sign-on.
So what are the benefits of leveraging a social media credential for government websites? Well, for those more trusting than me, convenience and the benefit of having fewer passwords to remember is a definite plus. And cost savings can be significant for large websites, although keep in mind that a full IAM stack is still required — the public sector website will still need to provide their own login service as not all citizens will trust an alternate credential.
Ultimately, social media login for services won’t meet government privacy and security requirements for access to sensitive information. Existing in-house systems and credential solutions (like SecureKey) that specifically address the trust issue will likely prevail.
In my own city, Edmonton, they have been talking up e-voting for a while now. There was an announcement yesterday that a pilot project is being conducted to validate the process of running an online election. (More information can be found here and here.)
First of all, I think that this is exactly the type of pilot project that governments must run to be progressive and forward-thinking. These types of initiatives are high value, not just to validate a solution for this defined need, but for the organization’s other online initiatives. And the proposed e-voting identification process is an interesting one…
To be frank, I don’t have e-voting very high on my personal list of municipal problems to be solved, BUT I do have a keen interest in how people are identified online.
The City’s new project has an identity proofing process for this pilot project. It includes a unique method of collecting identity proofing documents that I haven’t seen before: citizens scan (or take a picture of) their real-world identification, then upload it to the City’s website. Allowed documents include drivers license, passport, Canadian military cards, etc. (see sidebar).
The image of the identification document is then reviewed manually by employees in the elections department and presumably compared to lists of eligible voters. Only when the document matches up with a previously registered voter will a credential be issued to the citizen for voting purposes.
This approach is convenient to citizens, or at least those that are savvy enough to scan a document and upload it to a website (which is probably a pretty high percentage of those that will consider online voting).
But whenever I see ‘convenience’ cited as a reason to do something online, I can’t help but look for the security and privacy compromises required to make that thing convenient. On first review (I haven’t done a deep dive s feel free to correct me!) here are a few things that might be compromised by such a process:
How does the process ensure that the citizen is in control of the document at the time e-voting registration takes place? For example, the passports for a household might be stored in a filing cabinet. Let’s say one member of the household is politically active and the rest don’t vote at all. How difficult would it be for the one family member to round up the passports and create multiple e-voting credentials?
There may be a privacy issue here. Scanned identification documents contain a payload of sensitive information. My passport has my legal name and birthdate — two attributes that are useful for the voter vetting process. But it also contains my passport number, my place of birth and my citizenship. None of these attributes are needed by this process, and should not be collected and stored as part of the process. (Update: The City’s 311 service has informed me that the data will be stored in Canada and destroyed no later than December 31, 2012. Also, only authorized personnel can view the data and they are subject to confidentiality agreements.)
Finally, how can one be sure that the scanned identity document has not been digitally tampered with? Paper and plastic documents have physical safeguards to increase reliability. For example, the Alberta drivers license has a hologram on it and ‘declined width text wave’ feature (and these are just two of a dozen security features). How do these features translate to the scanned image? Assuming many of these features do not translate well, how well does the scan of the document actually prove the citizen’s identity? As a comparison, would such a scan, subsequently printed, be acceptable as ID at the polling station?
It will be interesting to see how these and other challenges of e-voting will be overcome in the coming months.
The general impression is that identity management systems — in particular the authentication and authorization components — need to run continuously in order to ensure users can access their business applications. Enterprise IT shops are accustomed to building in redundancy in hardware and rigorous process to ensure systems ‘stay up’. It is not uncommon for a critical business system to have a target up-time of 99.99% or even 99.999%.
Why is this the case? Information systems availability (or lack thereof) can impact productivity and, for private businesses, profitability. And the case of medical systems — actual clinical systems, not informational websites — an outage to a system can impact health service delivery and have negative outcomes for patients. As a result, it is common for an identity management system to be designed for high availability, and for organizations to fund (hardware, software, people, etc.) the service at a level appropriate to meet this goal.
But not all systems need this type of high availability.
Take, for example, a set of web applications offered to the public for access to government information. These applications represent a sub-set of the business being conducted, i.e. they could be used to apply for funding or to access a library of online information products. In my experience, this type of public-sector system is by far the most common type of application used by citizens online.
So here’s the bombshell — these type of systems do not need to be highly available… 24/7/365 access, highly redundant services, on-call technical analysts, etc. are not part of the requirements for these web applications. Why? Because the expectations and needs of users for access are not as high as enterprise architects and overly concerned business folks lead us to believe.
Think about it for a moment: if a government website or application were down, what would most of us do? Call our elected representative in a rage? Close our business? Drive to the nearest service centre?
No. We’d do what we do when other websites are unavailable — surf on to the next one, spend some quality time on Facebook or check our email…
On September 7th, I’ll be heading to the 1st Annual Critical Infrastructure Protection Conference conference in Calgary, Alberta. This is the first edition of this conference, subtitled “Cyber Security for Energy and Communications” . With our oil sands attracting wide-spread internation attention — Warren Buffet and Bill Gates visited last week — the protection of these assets is obviously a top priority for both government and industry.
I’ll be helping to staff the Seccuris booth in the trade show, and catching whatever speakers I can. It should be rather interesting to hear Dr. Steven Flynn, the Homeland Security Advisor to Barack Obama speak on infrastructure security — even if this topic is not related to my direct interests of identity, information security and privacy.
Michael Legary from Seccuris will also be speaking on “Virtually Secure: Uncovering the Risks of Virtualization”, a look at the security of virtual server environments.
Always interesting, too, to visit Calgary. It is a rare example of how a city can be sophisticated and thriving, while still retaining its prairie town roots.
Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. — Helen Keller, author and activist. Keller, who was deaf and blind, was an advocate for many progressive causes including women’s suffrage and inclusion for people with disabilities.
On privacy and youth:
“Young people are very adept and comfortable with electronic communication. As advocates, we have to help young Canadians find the information they need to be their own privacy watchdogs” — Irene Hamilton, Manitoba Ombudsman, speaking at the semi-annual meeting of Canadian Privacy Commissioners, June 4, 2008. Visit youthprivacy.ca for more information.
On common sense?
“Many companies need to do more to prevent inexcusable security breaches. Too often, we see personal information compromised because a company has failed to implement elementary security measures such as using encryption on laptops.” Jennifer Stoddart, Canada’s Privacy Commissioner in her 2007 report to Parliament.