Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Hitachi ID Systems Blogs

Advanced search in an IAM system: a privacy threat

September 15th, 2014

XKCD posted an amusing comic about the intersection of SQL and data privacy a while ago, here – xkcd.com/1409/.

This is interesting in that it highlights the threat to privacy by an innocuous seeming search feature. Never mind the SQL syntax in the comic – imagine that you can search for users whose ‘scheduled term date’ is in the next 30 days, or whose ‘most recent performance review’ was a low grade. Even if the IAM system refuses to show you the values of those fields, the presence or absence of a user in a search result set would compromise privacy and possibly corporate security.

What to do?

You have two options:

  • Eliminate search on sensitive attributes entirely; or
  • Ensure that the IAM system filters out search results which were included on the basis of the values of sensitive attributes.

I imagine that most IAM products and deployments out there opt for the former. You can’t search on ‘scheduled term date’ and the like. That’s fine – it’s safe, I guess, but it’s also extremely limiting. What if, as a manager, I want to run that query and see which of my subordinates, some of which are contractors, are about to reach the end of their work term? I might then wish to request extensions for some of them, because their projects are still active. Alternately, I might request to turn some contractors into employees.

In other words, simply refusing to search on these things is not a satisfactory solution – it leaves out too much useful functionality.

That brings us to the second option — build a search engine smart enough to figure that a given record should not be included in the result set because this particular requester should not be able to see the sensitive attribute value for this particular user. That’s hard, but creates much more value for the end user.

This is the approach we opted for at Hitachi ID. Hopefully our customers like it. ;-)

My CC was hacked – but where?

September 4th, 2014

We recently got a call from the bank, asking to verify that a series of transactions were valid. As it turned out, nothing was amiss and no action (e.g., new CC) had to be taken.

But this kind of call gets you thinking: why did the bank call? Presumably because there was a bulk compromise of some or all transactions at some retailer that the bank deals with. Recent news releases (Target, Home Depot, etc.) make this seem likely.

As a consumer, I really want to know. Which vendor got hacked? At all locations or just one (physical or virtual) retail outlet? I want to know because, frankly, I might be more careful doing business with that retailer or outlet in the future.

The banks don’t release this information today. There is a hack, they know about it, but they don’t tell me who was hacked, or when, or where? This is presumably because they don’t want to anger (embarass?) their merchant customer. I get that, but I’m their customer too, and so are millions of other consumers. I think the banks should disclose what they know to the consumers, as this will reduce the total cost of the impact of the hack. It will also provide a much stronger incentive to merchants to lock things down, and over time may reduce the cost of attacks.

At the end of the day, the bank did nothing wrong, the merchant had an error of omission, not commission (inadequate protection) and the consumer did nothing wrong. Can’t we just all be open and transparent about the event, to help work together to keep out the bad guys?

Another day, another hack

September 2nd, 2014

This time, it’s the “Fappening” – titillating name, that. A bunch of young starlets had compromising photos lifted from their iCloud accounts and posted online.

Apple claims innocence, and they are likely telling the truth. Why would only a few dozens (or hundreds? thousands?) of iCloud accounts have been hacked? That’s not consistent with a systemic security failure at Apple.

So how did these “hackers” get in? Likely they found a stash of e-mail addresses and passwords from some other breach, on-line somewhere. There have been plenty of large scale breaches in the past year or two. They would then have looked for persons of interest in the stash of IDs/passwords and, having found some, tried some of these same login credentials on the Apple site.

Simple enough – no technical skills required – just persistence.

Are there lessons to be learned here? Sure!

  • If your account on one system has been hacked, change your passwords everywhere, not just on that one site.
  • Heck, change all your passwords once in a while, on the theory that some of them may have been hacked and you were not notified.
  • Keep different passwords on different systems, or at least on systems that have different security profiles, both in terms of how securely you suspect they are managed and in terms of how much you would care if they were compromised. Don’t use the same password on Facebook and your bank, for example.
  • Don’t store sensitive, personal data in plaintext on systems or media you don’t physically control. Putting nude pictures of yourself on the cloud? Not so smart.

Mind you, nobody ever seems to learn. I’m sure this sort of thing will happen again, soon.

Do you still limit daily password changes?

July 30th, 2014

Once upon a time, password history enforcement used code that stored hashes of the “last N” passwords for each user.  N was typically a small integer – often less than 10.  Some users would figure out what N was and, when the time came to change their password, made N+1 password changes, where the last password reverted to their original password.

Such users are both smart and stupid.  Smart, because they figured out how the underlying security system worked and how to circumvent it.  Stupid, because they opted for static passwords and thus weakened the security of their own accounts.

Some organizations figured out that they had users using the “N+1 trick,” and found a low-tech way to make it painful for the offending users.  They limited the number of times a user could change his own password in the course of a single day, typically to just 1.  A user who wanted to use the “N+1 trick” would be obliged to do so over N+1 days, which pretty much eliminated the attractiveness of the scheme.

Unfortunately, limiting the number of password changes per day is unfriendly to users.  Say I change my password, then decide that the new password is not so nice after all, and want to change it again, to a better value?  What about if I change my password, forget it and need to reset it.  These are legitimate use cases and users should be able to change their password as often as needed.

Fast forward to the present, where N can either be very large (say 100) or simply open-ended (Password Manager supports  this).  In either case, we get the same benefit of the old “max once daily” rule, but without annoying users who just want to change their password again.

In this context, “max once daily” loses any conceivable benefit. There is no security advantage to preventing an authenticated user from changing his own password as often as he likes.  There is no benefit in the sense of stronger measures against password reuse, if the password history data is large or open ended.  There is only down-side.

I raise this because we still, occasionally, meet organizations that insist on enforcing this rule.  Get over it – open ended history is a better solution.  This rule should be abandoned to a curiosity of history, removed from enforced password security policies.  Use a product like Password Manager to enforce open-ended history or just set N to a large number.

Default passwords strike again!

June 11th, 2014

Amusing article in the
Winnipeg Sun. A couple of “computer whiz” grade 9 kids used a search engine to find an operators manual for the ATM at their local grocery store. In the manual, there are instructions for signing into the ATM as an admin, along with a default password.

Lo and behold, the BMO bank machine still used the default admin password, so the kids got it. Now these are nice kids, so they visited the local branch, explained the problem and made sure that the problem was fixed. No harm done, and instead rather a good deed.

What’s interesting here is that in this day and age, a *bank* was so lax about security as to leave a *cash machine*, which is protected by exactly *zero* physical security and is installed in a public place, with a *default administrator password*.

I can’t think of a more clear cut use case for deploying a Privileged Access Management solution. This password should have been a long, pseudo-random, daily string — not a factory default.

eBay compromise – the largest incident yet?

May 22nd, 2014

It seems that compromised password databases are getting bigger and bigger.

The latest one is a report that 145 million user account records (i.e., username, hashed password, some profile information such as date of birth) were exfiltrated from eBay.

(Gotta love that word … exfiltrated.)

I don’t know what attack vector was used to compromise this data, other than that the attack was carried out from inside the eBay corporate network, so discussing that will have to wait for another day.

As the scale of these incidents gets larger, new problems arise. For example, eBay (the corporation) has reacted very responsibly here – disclosing what they know and advising users to change their passwords. Users are getting used to these kinds of incidents and are trying to change their passwords. So far, so good.

But there are 145,000,000 users trying to change their passwords, more or less all at the same time. The eBay web site clearly cannot keep up. I tried to change my password, but failed:

  • First, it was hard to find the password change screen (but I did find it in the end…)
  • Once I found it, I learned that the eBay site requires confirmation that it’s a legitimate user (me) making the password change, by sending a code to my personal e-mail or phone.
  • But … the system is under such high load that I never got the confirmation e-mail. I tried asking for a text message but the site just refused, complaining about load.
  • What about users who registered an e-mail account with eBay years ago, and no longer have that account? I suppose they cannot change their password – at least not without human assistance, which also won’t scale to 145,000,000 accounts…

In short, at this scale, remediation is a problem. Maybe I’ll try to change my password tonight or tomorrow. Hopefully the storm of password changes will have slowed down by then.

What about users that employ the same password on multiple web sites (i.e., almost everybody)? This incident implies that 100,000,000 or more users are now trying to change their passwords on facebook, reddit, flickr, google, live.com, etc. I bet those sites are slammed too, and perhaps also unable to respond.

All this sounds like a strong argument for federating identity and authentication — but federating to a few large providers (like Google or Microsoft) will concentrate risk. Imagine if Google or Microsoft get compromised, and everybody was using those platforms as federated identity/authentication providers for web sites such as eBay. That would be even worse than the current eBay incident! Moreover, federation creates linkages between accounts on different services, so has the (unintended) effect of diluting privacy.

Ultimately, I think federating to a large number of small providers would be best, because compromise of any one provider would have only modest impact. Unfortunately, we are still very far from such an architecture.

Another day, another rogue admin

May 21st, 2014

Some people never learn, I guess.

This guy: (link to IT World article) will spend some quality time in jail for sabotaging work systems before he learned about his own imminent termination.

Getting fired sucks. Going to jail for these shenanigans is definitely worse.

Clearly, a privileged access management system could have mitigated the harm.

Real security: the new SOX

May 5th, 2014

In the past few years, the looming threat of non-compliance with Sarbanes-Oxley (SOX) has driven much spending on IT security. This, despite that the “security” bits in the SOX legislation are laughably vague. In section 404 of the SOX legislation, there are requirements for public-listed companies to implement, assess and certify the quality of the internal controls that impact financial systems and data. That’s about it. Weak.

Despite being totally ambiguous, fear of SOX non-compliance has led corporations to spend billions on IT security. I imagine much of that money was spent on useless technology and process – things that *look* like they work, but may not actually be effective.

That was then. This is now.

I just read that the CEO of Target was removed, in large part because of the huge security incident they had, with tens of millions of credit card records compromised. Now that’s a serious threat, with a material impact on the corporation, both in terms of liability (to the card companies) and brand (shoppers going elsewhere because they are afraid of the nuisance of identity theft). It seems that the impact on management is actually more serious than SOX. I can’t recall any CEO of a major corporation being terminated before, due to an IT security breach. But now we have one, and I bet all the other CEOs will take note.

http://www.reuters.com/article/2014/05/05/us-target-ceo-idUSBREA440BD20140505

It will be interesting if the response to this will be any different than it had been to SOX. i.e., if the focus this time will be on actual security, rather than merely passing audits.

Of course, we have a vested stake in this game. Organizations seeking real security need to worry about all kinds of things — control over privileged accounts, prompt/reliable/complete access deactivation when users leave, assigning needs-appropriate access rights, strong user passwords and much more. We make software that addresses these problems.

Bait-and-switch, buyer beware

May 2nd, 2014

It seems that this industry can never stop with the bait-and-switch sales strategy. It never ceases to amaze me what some of our competitors will offer, or what some customer organizations will believe.

A couple of recent examples:

  • Last summer, we were talking to a global enterprise interested in replacing a legacy, out-of-support identity management product. They had a really unrealistic timeline: 6 weeks to implement and deploy a replacement. We told them that it would simply not be that fast. One of our competitors assured them that it would be no problem. Our competitor won the business, on the basis of ludicrously false promises. Now, in retrospect, reality has set in. 8 months later (not 1.5 months!), they are about half way done with the replacement effort. Good times.
  • Recently, a software vendor in our space started offering “free” software. Of course, it would only come with limited integrations, and limited features, and just one day of consulting, and would only be free for the first year. But hey – it’s free! And if any organization is silly enough to adopt this “free” software, why they would be hard pressed to walk away when the time comes to start paying for things, or adding useful features.

This is not new – we’ve seen companies promising “enterprise deployment” of privileged access management systems, with thousands of integrations and full business process, in under 30 days. Seriously? Most organizations will need that time just to define their requirements, never mind deploy, test, migrate to production, retest, document and hand-off to operations.

But there must be money in it, because people keep offering things that are clearly too good to be true (and so are not true).

Windows 8.x: Is Microsoft in Trouble?

April 22nd, 2014

I recently bought a new laptop. As is usual these days, it came with Windows 8. This was my first “Windows 8″ computer, so I was a bit surprised by the experience, despite what others have reported.

Here’s what it came to:

  • Remove adware, trialware and other junk: 1 hour
  • Apply all available patches from Windows Update: 2 hours
  • Install useful apps (e.g., firefox, acrobat reader, skype, etc.): 1 hour
  • Upgrade to Windows 8.1: 12 hours (overnight – 3.5GB download!)
  • Fix up Windows settings to make Windows 8.1 less annoying (that whole start screen / metro thing is an abomination on non-touch devices): 1 hour

Total to make the Windows 8.1 system usable: 17 elapsed hours, of which about 2 hours required my involvement.

No wonder people buy Mac’s!

I’m a frequent Linux user, so next I shrank one of the partitions and installed Ubuntu 14.04:

  • Shrink Windows partition: 5 minutes
  • Download Ubuntu 14.04 image: 5 minutes
  • Burn the image to a USB flash drive: 5 minutes
  • Install Linux, including a full set of apps: 10 minutes

Total time to add Linux plus all the usual apps to this laptop: 25 minutes.

The irony is that the Linux install is (I think) much more user friendly. None of that Metro/Start Screen/Modern junk with jarring transitions between full-screen and Windowed apps.

I’m biased, sure, but in both directions:

  • Our company’s products install on and integrate well with Windows — I want Microsoft to succeed, at least in the corporate space.
  • I’ve been a long-term Unix user, so I’m probably more productive and certainly more comfortable with a shell than a GUI.

Still – the difference in installation experience and in the quality of the resulting desktop environment is significant, and not in Microsoft’s favour.

Ultimately, people will choose what they are familiar or comfortable with. Most users will buy a computer based on price point and will live with whatever junk it came with. Compatibility with hardware and apps is a big decision factor, and I expect that support for shiny-and-new printers and scanners is probably a point in favour of Windows. But for the average user, whose PC is used to browse the web, access e-mail, write the occasional document, etc. — Linux looks to me like a much nicer option than Windows.

That’s not good for Microsoft.