Archive for 2012

If not passwords, then what?

Saturday, December 29th, 2012

Interesting read over at

While all the hacks described therein are quite legitimate, and some amusing (e.g., hacking Nuance voice verification by recording someone speaking each digit and replaying on demand), this does raise the question: if not passwords (and two-factor, and voice bio, and SMS/PIN and …) – then what?

That’s the million dollar question – the password-centric ecosystem, along with security questions and password reset mechanisms – is quite fragile, but it’s inexpensive to deploy and operate, accessible from any device and any location and well understood. Alternatives require changes to user behaviour, expensive infrastructure and often just create new weaknesses.

It’s easy to say “move on – passwords are not secure enough” but it’s hard to offer a convincing argument for any particular alternative.

Session capture can be creepy … keep it safe

Thursday, December 20th, 2012

One of the features we offer in our Privileged Access Manager product is the ability to record an IT user’s login session to a privileged account. This can come in handy in a variety of circumstances — forensic audit, knowledge sharing, figuring out what was done to cause a breakage, etc.

The problem is that session capture raises some serious privacy concerns. What if I’m the IT user being monitored, and I take a break from my admin duties to do a bit of personal banking. Maybe I do that at lunchtime – perfectly reasonable. The trouble is, my employer now has a video record, keystroke data, etc. of me signing into my bank account. They literally have my bank account number and password in the logs. Talk about unintended consequences! I’m sure they don’t want the data, but it’s very hard to filter it out of the capture data stream.

That’s inocuous, but what if things get really personal? What happens if an admin is called up at 3AM to fix a critical system issue. He gets out of bed, half dressed, opens his laptop, signs on and does what’s required. But session capture can also turn on his webcam – is that the admin’s partner in bed in the background? Have we activated the webcam on a corporate PC or on his personal device? Did we just enable video surveillance of our admin’s residence? The legal and ethical questions get pretty murky, pretty fast.

None of this is to suggest that session capture is an unreasonable feature — merely that it should be applied with great care.

We have been quite careful about this with our own software — we use workflow processes to approve requests to search through recordings, further workflow approvals to approve requests to play back a particular recording, policy engines to decide when session capture should be enabled and what data streams to turn on (full screen, launched window, keystrokes, copy buffer, webcam, etc.) and more. We take the privacy implications of session capture quite seriously.

Given this background, I was shocked when I recently learned that at least one of our competitors includes a feature for real time session surveillance. They literally allow an auditor, with pre-approved but not per-incident access, to watch what an admin does in real time. Wow. Talk about throwing caution to the winds!

Folks – real time surveillance is just plain creepy. Please don’t do it, even if you happen to have a tool with that capability. Instead, consider the power that session monitoring gives you to compromise someone’s privacy, and apply it very VERY conservatively.

Citrix Receiver on Linux/64-bit

Wednesday, December 19th, 2012

I had the unfortunate experience today of trying to use a Citrix ICA client (“Citrix Receiver”) on a Linux client OS.

What a joke.

The 64-bit client – once you find it through Google (it’s not offered automatically), is actually a packaged up 32-bit client. Built using Motif (anyone remember that ancient UI framework from the 1990s?). With a broken installation script, which fails to identify a 64-bit OS. And finally with broken SSL CA certificates, such that when you finally get the thing installed, through hacking scripts, installing dependencies and general screwing around, refuses to connect to the ICA server.

Citrix should decide whether they seriously want to support Linux. Either release a decent client, built with a modern UI, able to install cleanly on a modern OS, or stop taunting us with their crapware.

My advice to anyone reading this: don’t bother. If you must connect to a Citrix VDI infrastructure, and your PC runs Linux, then fire up a Windows VM and connect from there. While the UI experience of ICA inside Windows VM inside X11 is less than optimal, it at least works. The native client – not so much.

Identity, privileged identity

Monday, October 15th, 2012

I couldn’t have said it better myself:

Come work for us

Thursday, September 13th, 2012

We’re always hiring.

And here’s a brilliant description of what will get our attention in your resume — it’s funny because it’s true:

How the HR department reads your resume

Composing effective security questions

Thursday, August 9th, 2012

Frank Voisin has an interesting blog, where he succinctly defines the objectives of well crafted security questions:

In short, they should have definitive answers; be applicable to the majority of users; be memorable and safe.

Well put.

Retiring Sun IDM

Wednesday, August 1st, 2012

A timely reminder that Sun/Waveset is approaching end of life, and what customers can expect in the process of replacing it was posted today:

Short and to the point – I couldn’t agree more.

fun stuff

Tuesday, July 31st, 2012

I usually ride my bike to work, but this might be an acceptable alternative:


Physical security – gun safes

Friday, July 27th, 2012

Interesting story at It seems that quite a few commercially available, consumer-grade gun safes are not actually safe – a 3 year old can (literally) open them without knowledge of the code or posession of the key.

Just goes to show you – security by obscurity is a fallacy, in the physical world as well as the digital world.

It’s all about relationships, not roles

Tuesday, June 19th, 2012

Are roles the right way to control access?

In some cases, clearly yes — there’s a whole formal model of role-based access control (RBAC) out there and it’s worked well in some business contexts for years.

But in other cases, just as clearly, RBAC is inadequate.

I raise this because in the context of an identity management system, one of the things we have to do is control who has access to whose profile. For example, can one employee see another’s work phone number? Home phone number? Scheduled termination date? Who can edit these things?

It turns out that pure RBAC is a poor model for access controls in these cases.

If we use RBAC, then we have to define roles for users who can access this data. Whose data can they access? Everyone’s apparently. For example, we might say that “all employees can access the work phone numbers of all users.” Sounds reasonable. Another example might be “only HR can access home phone numbers and scheduled termination dates.” Is that reasonable too?

If we think about these examples, we have to conclude that RBAC isn’t up to the task. For example, do we allow one HR user to see another HR user’s scheduled termination date? What about his own? If Bob in the corner (who happens to work in HR) is going to be terminated on Friday, should he know that? That’s a security problem.

What about usability problems? I would think that co-workers should be able to find one another’s home phone number. What happens if someone is hurt at work and you want to contact their family? How about if there is an emergency off-hours and you want to call someone to see if they can help? Clearly, we want to open up home contact information — not to the entire organization, as this could raise privacy concerns — but perhaps to people in the same department or location.

The same thing applies to scheduduled termination dates. It would be useful for managers to be able to see and change these for their subordinates. For example, a manager responsible for a large segment of the organization might want to periodically see what contractors are due for termination in the coming few weeks and perhaps extend some contracts to allow for unfinished work. On the other hand, the same manager should not be able to see his own scheduled termination date, or that of anyone who does not report to him.

The common thread that runs through these scenarios is relationships. What one user — lets call him the requester — can see of and modify in another’s profile — lets call the second user the recipient — should depend not merely on the requester’s role, but also on the relationship between the requester and recipient.

That’s the context of access control decisions inside an identity management system. In other systems, context may include other things — how is the requester related to the data he wishes to access?

And this is where RBAC falls short. To make access control decisions about what a given user can see or do, we need more than the identity of the requester — we need context for their requested access. In identity management, that context is a relationship.

So why do I bring this up?

In previous releases of Hitachi ID Identity Manager, access control within our software was built on an RBAC model. What I’ve seen of other, competing products is the same — access control decisions are made based on the requester’s role and usually nothing else.

Organizations that wanted to manage sensitive data in their IDM system would then either have to exclude it, reducing the value of their investment, or write lots of custom code, increasing the cost of their system. These were not good options.

Starting with release 8.0 of Hitachi ID Identity Manager, we completely overhauled our internal access control model. Our customers first define relationships and then attach access rights to those relationships. Relationships can be anything — manager/subordinate, same-location, same-department, etc. Really any set of criteria based on each user’s profile attributes and group memberships.

This means that with Hitachi ID Identity Manager 8.0, organizations can easily model their real-world requirements, without resorting to custom logic. Want to allow managers to see/edit termination dates for their subordinates? No problem. Want branch office IT staff to be able to reset passwords for co-located users? Easy. Want to block HR staff from seeing their own termination dates? Simple.

Call us and try it out. You’ll be impressed by the difference a smarter access control model can make.