SaaS: Be careful what you sign up for

September 12th, 2018

There is no question that the world is moving from on-premises software to cloud-hosted, vendor-managed alternatives. Software-as-a-Service (SaaS) means that applications are professionally deployed and managed by specialists and hosted in someone else’s data center. Success stories including Salesforce.com, Microsoft Office 365 and ServiceNow are just examples of this macro trend.

When organizations move applications from on-premises to SaaS, there is a risk of losing significant capabilities. This happens because legacy software has evolved over decades to handle complex edge cases, while SaaS alternatives are relatively new and often missing key features.

This is not always the case, but seems to be quite common in the IAM segment. While solutions such as Salesforce and Office 365 are “feature complete” in the sense that they offer materially the same capabilities as on-premises alternatives, services that are branded as “Identity as a Service” (IDaaS) from Okta, Azure AD and others are much thinner, offering some combination of directory services, single sign-on (mainly via federation), basic (de)provisioning to SaaS applications and in some cases 2FA or simple account creation and deactivation.

In other words, IDaaS is often a misnomer, referring instead to single sign-on as a service (SSOaaS) plus some very limited IAM features. There is nothing wrong with these services — but calling them IDaaS is not quite truth in advertising as customers may get less than they expect.

There is no technical barrier preventing vendors from offering more feature rich IAM systems as a service. Indeed, IAMaaS is probably a better acronym than IDaaS for solutions that include connectors to manage both on-premises and SaaS applications, both automated and request/approval based access provisioning and governance features such as access reviews, approval workflows, analytics, segregation of duties policy and role based access control.

Hitachi ID, and doubtless some competitors as well, offers exactly this: full-featured IAM hosted in the cloud and managed by the software vendor.

One of the expectations that organizations bring to SaaS is shorter, less costly implementations. In practice, this has nothing to do with where the application is hosted (on-premises versus cloud) and everything to do with standardized configurations and frequent, automated version upgrades. In this regard, Hitachi ID may be unique, as we offer “Identity Express” — a set of standardized business processes for workforce IAM and for partner portal IAM, which helps both to speed up IAM implementations and provide more feature-rich joiner/mover/leaver process automation than would be possible with a custom approach to system deployment.

For those of you with a mandate to “move to the cloud,” the guidance is two-fold: (a) understand the difference between IDaaS (really SSOaaS) and IAMaaS (hosted, leased, managed IAM) and (b) focus on adopting best practices business processes, not just moving the IAM system from your data center to someone else’s.

A practical use for blockchain: disarming censors

July 24th, 2018

An interesting news story out of China:

The predictable, sad but not really noteworthy bit: a vaccine manufacturer saved money by making bogus vaccines and its executives were hauled away by police.

The predictable government response: delay publication of the news, as it implies a corrupt regulator and suppress subsequent social media posts on the subject.

The interesting and innovative bit: repost the story as metadata in an Ethereum transaction, such that it gets replicated across all participants in that blockchain and becomes impossible to tamper with or delete.

https://www.theverge.com/2018/7/24/17607690/chinese-internet-users-blockchain-share-censored-news-article-vaccines

This is fascinating! An interesting way to totally defeat, once and for all, state authorities bent on censorship. Just encode public messages in blockchain transaction metadata. Brilliant, though dangerous (what if the state figures out who issued/signed the transaction? jail time at a minimum).

Most of the interest in blockchain is conjecture about hypothetical use cases, but this use case is legitimate and practical – a rare thing.

Privileged Access in an IoT world

June 19th, 2018

While it may seem like securing IoT is an abstract problem, in reality it is anything but.

Apparently Tesla (and possibly also SpaceX, separately, a couple of years ago) has been hit by internal sabotage to critical code and possibly other processes.

SC Magazine.

If you thought PAM was purely about administrator access to IT systems, you were wrong. How about PAM access to code check-ins? PAM access to factory control systems? PAM access to sensors (cameras?) and actuators?

This is reality, not theory.

Did your company spend millions on “access governance” and fail to automate anything?

June 8th, 2018

Imagine that you’re a mid-sized organization (say 2,500 employees in the case of a particular, real-world organization I have in mind) and a few years ago your company took the advice of a leading systems integrator / consulting firm and purchased licenses for the market leading IAM product.

You have since invested over $4 million in software, runtime platform, maintenance fees and lots (!) of implementation services. You have purchased as much consulting time as seemed appropriate, and you still have projects on the go.

By this time, after this much time and money spent, you would expect to have a lot of integrations and process automation in place, wouldn’t you? Several years and 4 million dollars should buy a lot, you’d think.

Unfortunately, if you were convinced to buy SailPoint, you probably haven’t got much to show for it. You have an excellent platform for running access certification campaigns, and you have built a system that integrates directly with your AD domain, plus consumes all sorts of CSV files from many applications, but that’s about it.

You haven’t automated any joiner/mover/leaver processes.

You don’t have a request portal rolled out to your users.

The SoD enforcement is sketchy at best — there are definitely ways to submit requests that should but do not trigger SoD violations.

Integrations are mainly via “flat files” — not real connectors.

But hey – there are pretty dashboards! Those must add value, right?

That’s not a great way to spend $4 million, but the integrator keeps proposing more — though every deployment phase seems to amount to just more CSV file “integrations.”

Maybe it’s time to get off the treadmill and look at better solutions, that can actually automate IAM processes, rather than delivering “access governance” but only promising (and never delivering) IAM process automation?

I can name a few organizations in this boat. Are you stuck in this situation too?

Please ‘like’ or ‘share’ if this scenario sounds all too familiar.

PC, Smart phone shipments declining

March 1st, 2018

I noticed two apparently-unrelated news articles today:

9to5google.com

and

theregister.co.uk

One talks about declining unit sales of phones and the other talks about the same thing for PCs.

Reading these articles, you’d think the sky is falling. Less phones are selling, on an annual basis! Less PCs too! Oh no! These industries are in trouble!

I think the reality is actually much simpler: PCs have been quite good for years now. Smart phones have likewise reached a plateau in terms of functionality and performance. Sure, new PCs and phones are nicer than old ones, but the extra screen pixels, camera resolution and compute power are not solving any new problems – they just meet the same old needs slightly better than before.

More than that, both PCs and phones are increasingly used to access cloud platforms. The heavy computation, storage, etc. are done on someone else’s server, not on personal devices any more. This makes local compute and storage even less meaningful.

So when a hardware manufacturer asks for $1000 for a shiny new phone or $1500 for a shiny new PC, most consumers compare the extra value of the new toy to the functionality of their existing PC or phone and choose to just leave the old device alone. It’s not broken. It’s working fine. Why upgrade?

I think this is the new normal. If you write software, or provide on-line services, then you shouldn’t care about this. People are on-line pervasively. They use browsers to access everything. There is no problem here.

If you are a phone or PC manufacturer, you just have to reset your expectations. The hardware replacement cycle is lengthening, not because consumers don’t want your product any more, but because your last generation was very good and the current generation is not so much better as to justify a new purchase. You’ll still sell lots of units, but the age of rapid growth is over. Heck, the only way you’ll grow your shipments is to win more market share from competitors. Get used to flat sales and razor thin margins folks. That’s the steady state of selling hardware.

Will this situation change? I doubt it. I have a hard time imagining what new capabilities phone or PC makers will be able to invent tomorrow, to excite consumers into a big hardware refresh cycle.

So a tough situation for hardware makers and a good situation for everyone else. That’s life.

Groups versus roles

February 12th, 2018

Periodically, I’m asked what the difference is between groups and roles. This is coming up even more frequently now that we’ve released version 11.0 of the Hitachi ID Identity and Access Management Suite, which includes full lifecycle management of groups (i.e., create, delete, update group objects on systems like AD).

This is actually a harder question to answer than one might think, because different systems and applications use the terms interchangeably. The object that I think of as a group might be called a group on one system (e.g., AD) and a role on another (e.g., SAP).

Ambiguous and overloaded terminology is very common in the IAM business, unfortunately.

Still, there’s a difference, once you define the two terms. To understand it, we should start with definitions. I’ll use Hitachi ID’s standard nomenclature here:

  • A group is an object that exists on a target system (LDAP, AD, SAP, RAC/F, etc.). Accounts are attached to the group as members. The group is assigned security privileges. This way, it’s not necessary to assign individual access rights to each user — which would be painful for a variety of reasons.Note that this is an approximate definition. For example, on some systems, groups can contain other groups as members (AD, RAC/F come to mind). On other systems, groups are also used as mail distribution lists (AD, LDAP). In some cases, a group on one system can contain among its members accounts or groups from another system (AD with cross-domain groups, for example).
  • A role is an object that exists on the IAM system. It’s used to collect entitlements (mainly groups, but also accounts) on target systems for more convenient assignment. Roles are typically nested — i.e., roles can contain other roles.Roles may be “technical” which just means that they represent collections of entitlements that are normally assigned together, but might not make much sense to business users, or they might be “organizational” which means that they represent business functions that requesters, authorizers or reviewers are more likely to understand. The difference here is a bit fuzzy, and that’s OK.

Beyond groups being on the target system and roles being in the IAM system, how are roles and groups different?

It turns out that how these objects are used in practice is quite different!

While IAM software vendors and implementation consultants strive to make role management a business-friendly task that managers will participate in, I’ve found that this rarely comes to pass. Managers rarely have the motivation, skills or time to participate meaningfully in defining or updating role definitions.

This has practical consequences: an IT team is ultimately responsible for defining and maintaining roles. They have limited visibility into business requirements and limited time to spend on any given role. These constraints make role definitions fairly static and formal.

Static, formal IAM roles usually wind up representing business functions (think job code). With static, formal roles it is natural to automatically assign roles: For example, birthright access for employees and contractors, departmental level roles for common access rights, job-code driven roles for jobs that are shared by large numbers of workers, etc. As HR systems or requests update identity attributes, the IAM system recalculates eligibility criteria and automatically assigns or revokes roles.

The consequence of all this is that roles are used to assign highly predictable, very regular access rights to users. If your location, department code, job code or cost centre can be used to predict your access rights and if your access rights are the same as many other people, then roles are the right tool to assign those rights to you, without extra manual intervention.

In practice, some access rights are simply hard to predict based on available data. For example, projects start up and wind down all the time. There is usually nothing in the HR database to indicate that a given user is involved in a project, so automation driven by HR data cannot grant or revoke project-related access rights.

This is part of a general pattern: automatic assignment of rights, via roles or not, only works well if we have both a sufficiently detailed, timely and reliable data source and a matching model that maps from identity attributes to entitlements.

Where this pattern ends is where directly assigned privileges begin. For directly assigned privileges, users could create new roles and request role assignment, but in practice users will skip the role definition step and just request the rights they want. i.e., users will request membership in the security groups that grant access to the share, folder or other item they wish to access, or ask to join a given mail distribution list.

There are two patterns for group membership management: groups may be included in roles, in which case they tend to be automatically assigned to appropriate users, or groups are not part of a role, in which case they tend to be requested on an as-needed basis.

Put another way: roles are formal and static, while groups may also be ad-hoc and dynamic.

What does ad-hoc mean?

  • Ad-hoc groups won’t be automatically assigned, so users must be able to sign into a portal and find and request them.
  • Users often don’t know what group to ask for (or even where to find the request portal), so significant usability support is required.
  • Ad-hoc may also mean creating and deleting the groups themselves, rather than just just requesting membership.
  • Anyone could request anything, so an approval workflow is required to prevent inappropriate requests from being completed.
  • Nobody ever asks for access rights to be reduced, so a periodic access review and revocation process is essential.

And that’s it:

  • Roles are IAM constructs used to build a formal model of predictable, static access rights that are usually automatically assigned,
  • Groups are objects on existing systems and applications. They may either be parts of roles, or may be requested, approved, reviewed and revoked in an ad-hoc manner.

Bitcoin Hype

January 16th, 2018

Blockchain has become quite the hyped technology over the past year.

Consider this: it’s a distributed, validated ledger of transactions. It’s useful to transfer value between parties who may not know each-other, who may wish to remain anonymous and who wish to ensure that transfer is singular — no “double payment.”

That’s the high level picture.

On the other hand, it’s got some draw-backs:

  • It’s computationally expensive, by design.
  • It’s a profligate user of electrical energy.
    Bitcoin alone is estimated to consume over 41 terawatt-hours per year:
    digiconomist.net/bitcoin-energy-consumption.
  • It’s slow.
    The entire Bitcoin network only processes about 300,000 transactions/day
    or about 3.5 transactions/second).
    blockchain.info/charts

People have lots of wild theories about where this technology will bear fruit, but in practice the only major use case today is for criminals to pay for goods and services. Awesome.

The other “use case” today is a speculative market in exchanging Bitcoin for hard currency, like USD. Here’s the chart:

www.xe.com/currencycharts/?from=XBT&to=USD&view=1Y

I recently read a great write-up comparing the hype of blockchain to the reality:

hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100

So what’s the reality?

  • Is it a safe place to store value? Only if you are sure that your private key and/or password will never be compromised and that you’ll never make a mistake when transferring funds. If you don’t trust yourself enough for that, with large value wealth storage, then it’s a bad platform for you.
  • Are bitcoin exchanges a safe place to store money? Given their history of hacks and shady business, I’d say no.
  • Is it good for funds transfer? Not really, given the cost and delay of transactions. Only criminals who really, really need anonymity would put up with the awful process.
  • Is it good for small payments? Not really. Too slow and costly.
  • Is it a good alternative for hyper-inflationary currencies issued by idiot regimes? US Dollars or Euros are a more practical choice there.
  • Does it have stable value? If you read the news, you know that Bitcoin/USD exchange rates have behaved more like a bubble than an investment-grade product.
  • Would it be a good alternative to inter-bank transfers? Maybe, but not anytime soon.
  • What about smart contracts? Sounds good, but people engaged in legal contracts generally want to understand what they are signing up for, and few can read algorithms. Moreover, how do you tie a smart contract to real-world trigger events?
  • What about using it to manage identities? The only plausible use case here is for citizens or consumers (forget about identities within the enterprise) and in any case it’s not clear how to link such a blockchain to physical things like birth records or driver licenses.

In other words, it’s a cool way for criminals to transfer funds anonymously and a plausible way for institutions to handle large but infrequent transfers among themselves. For everything else, the cost, inconvenience, non-repudiation, delay and even anonymity look like problems rather than advantages.

But everyone is making noises about “doing blockchain,” like this soft drink company:

Long Island Iced Tea?

So why is everyone jumping on the blockchain bandwagon? Because it’s the latest fad, and if your company tells the world that it’s researching the latest blockchain technology, your stock price will probably get a bounce. But don’t hold your breath for results.

Even “security consulting” firms get hacked

September 26th, 2017

I have to confess – I love irony.

… Sounds nice, but the reality is more like this …

Sounds like their Office 365 admin account got hacked … because they used neither the built-in 2FA on Azure nor a privileged access management system. Like our friends at Equifax, Deloitte delayed public disclosure as long as possible and is actively down-playing the scope of the (very serious, it seems) compromise.

Would you take security advice from a firm that got hacked in this way and failed to disclose to their customers?

Equifax breach

September 8th, 2017

The Equifax breach reported this week sets a new bar for exploited PII!

Apparently SSN, name, DoB and in some cases CC data for 143 million Americans was compromised. Given that probably 1/4 of the population has no credit cards (children, the elderly, illegal immigrants, etc.), this means that PII for over half of US card-holders was compromised in a single hack. That’s huge!

What can we learn from this?

First, what not to do? Other firms should learn from Equifax’ mistakes:

  1. Equifax let this happen, presumably by under-investing in IT security. Did they have a privileged access management system? Effective access deactivation processes? Pen testing against apps? Sound firewalls? 2FA? I don’t know, but I bet some of those questions will come back with a “no.”
  2. Equifax discovered the breach on July 29 but disclosed Sep 7. That’s a 40 day delay – disgraceful and probably illegal in some states.
  3. While the Yahoo breach was larger, this one included SSNs and some D/Ls, so the data stolen from Equifax is much more suitable for identity theft. This is bad folks.
  4. There may have been insider trading – three executives sold some stock after the breach was discovered but before it was public. If they knew about the breach, they are risking jail time.
  5. Equifax setup a web site for consumers to check if their information was included in the hack. But apparently you have to waive your right to join a class action lawsuit against Equifax to use it. That’s “sneaky” – except that lots of people caught on, so now it’s just more bad press.

Bottom line: Equifax could well go out of business as a consequence of this event and how badly it was handled. I’d lay at least 50/50 odds that this event kills them within the next few years, as litigation works its way through the courts.

Next, what to do?

  1. Watch your mail for letters from banks or other firms, to see if someone has taken out a loan in your name. Consumers beware, your info is probably compromised!
  2. Stop using name, SSN or DoB as credentials. If someone calls your IT help desk and you need to authenticate them, this data should be assumed to be public and not suitable for authentication.
  3. Lock down your IT systems. You don’t want to be the next victim.

UPDATES:

  1. just saw this:
    Equifax Faces Multibillion-Dollar Lawsuit Over Hack. That didn’t take long!
  2. Krebs lambastes Equifax, noting among other things that the web site to check if you’re affected by the breach appears to be bogus – it just returns a random string, and issues a predictable PIN. He also gives good advice (news to me, as I’m not an American), that you can visit his earlier post to learn how to lock down your credit profile, which should offer some protection against incompetent credit rating agencies combined with identity thieves, at no cost.
  3. It just won’t stop. They were caught with their pants down in Argentina too! admin/admin logins

But what about usability?

May 17th, 2017

Thin and beautiful devices are commonplace nowadays, but it feels like nobody cares about usability any more.

What got me thinking about this is the age of my laptop. It’s an older Lenovo and has an awesome keyboard. We’re talking full keys, long travel, pre-chiclet design. My laptop is ugly as sin, but really easy to use when I travel. Sooner or later I’m going to have to replace this thing, and it seems that all laptops nowadays have chiclet keyboards. Ugh. I find it difficult to type at any appreciable speed on chiclet keyboards.

The newer keyboards look nicer, but they are harder to use. Smaller keys and shorter vertical travel.

This is a part of a larger trend.

Another example is very thin phones — with too small batteries and consequently less-than-desired battery life. I’d really rather my phone was 1mm thicker, a few tens of grams heavier, but had twice the battery life. I think most consumers might agree with me on that one.

Want another example? How about SIM cards. Oh how I hate the shrinkage of SIM cards! I travel often and instead of paying high roaming fees, I like to pick up a local SIM card when I arrive at foreign airports. That works great, but the SIM cards themselves have become so small that they are hard for someone with adult-size fingers to manipulate. Was it really necessary to shave off an extra few square millimeters? All SIM cards are electronically identical — the shrinkage is just in the plastic surrounding the chip. The original SIM card design was quite small, and new “micro” and “nano” SIMs are awful.

I’ve got more examples! Ports on laptops are one: Many new laptops either omit ports (Ethernet, VGA, etc.) or require dongles. Looks great, very thin, but quite a nuisance to use. Laptop power adapters are another. Why are there a hundred different kinds of plugs? All laptops consume 20V and about 5A – so why do we need so many shapes and sizes of power plugs?

Maybe this is an opportunity for some manufacturers to carve out a niche, selling to users who care about usability:

  • Build slightly thicker devices, with more ports and bigger batteries.
  • Support “big” SIM cards in phones.
  • Standardize on something like USB-C PD for power, even in laptops.
  • Advertise that these devices are built to be used, not just looked at.