As
smartphones have become
de rigueur in the global
digital economy,
users want them to do more work, and businesses want them to be more
productive for their employees -- as well as powerful added channels to consumers.
But neither businesses nor mobile-service providers
have a cross-domain architecture that supports all the new requirements
for a secure digital economy, one that allows safe commerce, data sharing and user privacy.
So how do we blaze a better path to a secure
mobile future? How do we make today’s ubiquitous
mobile devices as low risk as they are indispensable?
BriefingsDirect recently posed these and other questions to a panel of experts on mobile security:
Paul Madsen, Principal Technical Architect in the Office of the CTO at Ping Identity;
Michael Barrett, President of the
FIDO (Fast Identity Online) Alliance, and
Mark Diodati, a Technical Director in the Office of the CTO at Ping Identity. The sponsored panel discussion is moderated by me,
Dana Gardner, Principal Analyst at
Interarbor Solutions.
Here are some excerpts:
Gardner: We're approaching this
Cloud Identity Summit 2014
(CIS) in Monterey, Calif. on July 19 and we still find that the digital economy is
not really reaching its full potential. We're still dealing with ongoing
challenges for trust, security, and governance across mobile devices
and network.
Even though people have been using mobile
devices for decades—and in some markets around the world they're the
primary tool for accessing the Internet—why are we still having
problems? Why is this so difficult to solve?
Diodati: There are so many puzzle pieces to make the
digital economy fully efficient. A couple of challenges come to mind.
One is the distribution of identity. In prior years, the enterprise did a
decent job -- not an amazing job, but a decent job -- of identifying
users, authenticating them, and figuring out what they have access to.
Once
you move out into a broader digital economy, you start talking about
off-premises architectures and the expansion of user constituencies.
There is a close relationship with your partners, employees, and your
contractors. But relationships can be more distant, like with your
customers.
Emerging threats
Additionally, there are issues with
emerging security threats. In many cases, there are fraudsters with
malware being very successful at taking people’s identities and stealing money from them.
Mobility can do a couple of things for us. In the old
days, if you want more identity assurance to access important
applications, you pay more in cost and usability problems. Specialized
hardware was used to raise assurance. Now, the smartphone is really just
a portable
biometric device
that users carry without us asking them to do so. We can raise
assurance levels without the draconian increase in cost and usability
problems.
We’re not out of the woods yet. One of the
challenges is nailing down the basic administrative processes to bind
user identities to mobile devices. That challenge is part cultural and
part technology.
[See more on a new vision for identity.]
Gardner: So it seems that we
have a larger set of variables, end users, are not captive on network,
who we authenticate. As you mentioned, the mobile device, the
smartphone, can be biometric and can be an even better authenticator than
we've had in the past. We might actually be in a better position in a
couple of years. Is there a transition that’s now afoot that we might
actually come out better on the other end?
Madsen: The opportunities are clear. As Mark indicated, the
phones, not just because of its technical features, but because of the
relatively tight binding that users feel for them, make a really strong
authentication factor.
It's the old trope of something you have, something
you know, and something you are. Phones are something you already have,
from the user’s point of view. It’s not an additional hard token or hard
USB token that we're asking employees to carry with them. It's something they want to carry, particularly if it's a
BYOD phone.
So
phones, because they're connected mobile computers, make a really
strong second-factor authentication, and we're seeing that more and
more. As I said, it’s one that users are happy using because of the
relationship they already have with their phones, for all the other
reasons.
[See more on identity standards and APIs.]
Gardner: It certainly seems to make
sense that you would authenticate into your work environment through
your phone. You might authenticate in the airport to check in with your
phone and you might use it for other sorts of commerce. It seems that we
have the idea, but we need to get there somehow.
What’s
architecturally missing for us to make this transition of the phone as
the primary way in which people are identified session by session, place
by place? Michael, any thoughts about that?
User experience
Barrett: There are a couple of things. One, in today’s world, we don’t yet have
open standards
that help to drive cross-platform authentication, and we don’t have the
right architecture for that. In today’s world still, if you are using a
phone with a
virtual keyboard,
you're forced to type this dreadful, unreadable tiny password on the
keyboard, and by the way, you can’t actually read what you just typed.
That’s a pretty miserable user experience, which we alluded to earlier.
But also, it’s a very ugly. It’s a mainframe-centric
architecture. The notion that the authentication credentials are shared
secrets that you know and that are stored on some central server is a
very, very 1960s approach to the world. My own belief is that, in fact,
we have to move towards a much more device-centric authentication model,
where the remote server actually doesn’t know your authentication
credentials. Again, that comes back to both architecture and standards.
My
own view is that if we put those in place, the world will change. Many
of us remember the happy days of the late '80s and early '90s when
offices were getting wired up, and we had client-server applications
everywhere. Then,
HTML and
HTTP
came along, and the world changed. We're looking at the same kind of
change, driven by the right set of appropriately designed open
standards.
Gardner: So standards, behavior, and
technology make for an interesting adoption path, sometimes a chicken
and the egg relationship. Tell me about FIDO and perhaps any thoughts
about how we make this transition and adoption happen sooner rather than
later?
Barrett: I gave a little hint. FIDO is
an open-standards organization really aiming to develop a set of
technical standards to enable device-centric authentication that is
easier for end users to use. As an ex-CTO, I can tell you the experience
when you try to give them stronger authenticators that are harder for
them to use. They won’t voluntarily use them.
FIDO is an open-standards organization really aiming to develop a set of
technical standards to enable device-centric authentication that is
easier for end users to use.
We have to do better
than we're doing today in terms of ease of use of authentication. We
also have to come up with authentication that is stronger for the
relying parties, because that’s the other face of this particular coin.
In today’s world, passwords and pins work very badly for end users. They
actually work brilliantly for the criminals.
So I'm
kind of old school on this. I tend to think that security controls
should be there to make life better for relying parties and users and
not for criminals. Unfortunately, in today’s world, they're kind of
inverted.
So FIDO is simply an open-standards
organization that is building and defining those classes of standards
and, through our member companies, is promulgating deployment of those
standards.
Madsen: I think FIDO is important.
Beyond the fact that it’s a standard is the pattern that it’s
normalizing. The pattern is one where the user logically authenticates
to their phone, whether it be with a fingerprint or a pin, but the
authentication is local. Then, leveraging the phone’s capabilities --
storage, crypto, connectivity. etc. -- the phone authenticates to the
server. It’s that pattern of a local authentication followed by a server
authentication that I think we are going to see over and over.
Gardner: Thank you, Paul. It seems to me that most people are onboard with this.
I know that, as a user, I'm happy to have the device authenticate. I
think developers would love to have this authentication move to a
context on a network or with other variables brought to bear. They can
create whole new richer services when they have a context for
participation. It seems to me the enterprises are onboard too. So
there's a lot of potential momentum around this. What does it take now
to move the needle forward? What should we expect to hear at CIS?
Moving forward
Diodati:
There are two dimensions to moving the needle forward: avoiding the
failures of prior mobile authentication systems, and ensuring that
modern authentication systems support critical applications. Both are
crucial to the success of any authentication system, including FIDO.
At CIS, we have an in-depth, three-hour FIDO workshop and many mobile authentication sessions.
There
are a couple of things that I like about FIDO. First, it can use the
biometric capabilities of the device. Many smart phones have an
accelerometer, a camera, and a microphone. We can get a really good initial authentication. Also, FIDO leverages
public-key technology, which overcomes some of the concerns we have around other kinds of technologies, particularly one-time passwords.
Madsen: To that last point Mark, I think FIDO and
SAML,
or more recent federation protocols, complement each other wonderfully.
FIDO is a great authentication technology, and federation historically
has not resolved that. Federation didn't claim to answer that issue, but
if you put the two together, you get a very strong initial
authentication. Then, you're able to broadcast that out to the
applications that you want to access. And that’s a strong combination.
Barrett: One of the things that we haven't really mentioned here -- and Paul just hinted at it -- is the relationship between
single sign-on
and authentication. When you talk to many organizations, they look at
that as two different sides of the same coin. So the better application
or ubiquity you can get, and the more applications you can sign the user
on with less interaction, is a good thing.
Gardner:
Before we go a little bit deeper into what’s coming up, let’s take
another pause and look back. There have been some attempts to solve
these problems. Many, I suppose, have been from a perspective of a
particular vendor or a type of device or platform or, in an enterprise
sense, using what they already know or have.
Proprietary technology is really great for many things, but there are
certain domains that simply need a strong standards-based backplane.
We've had containerization and
virtualization
on the mobile tier. It is, in a sense, going back to the past where you
go right to the server and very little is done on the device other than
the connection. App wrapping would fall under that as well, I suppose.
What have been the pros and cons and why isn’t containerization enough
to solve this problem? Let’s start with Michael.
Barrett:
If you look back historically, what we've tended to see are lot of
attempts that are truly proprietary in nature. Again, my own philosophy
on this is that proprietary technology is really great for many things,
but there are certain domains that simply need a strong standards-based
backplane.
There really hasn't been an attempt at this for some years. Pretty much, we have to go back to
X.509
to see the last major standards-based push at solving authentication.
But X.509 came with a whole bunch of baggage, as well as architectural
assumptions around a very disconnected world view that is kind of
antithetical to where we are today, where we have a very largely
connected world view.
I tend to think of it through
that particular set of lenses, which is that the standards attempts in
this area are old, and many of the approaches that have been tried over
the last decade have been proprietary.
For example, on my old team at
PayPal,
I had a small group of folks who surveyed security vendors. I remember
asking them to tell me how many authentication vendors there were and to
plot that for me by year?
Growing number of vendors
They
sighed heavily, because their database wasn’t organized that way, but
then came back a couple of weeks later. Essentially they said that in
2007, it was 30-odd vendors, and it has been going up by about a dozen a
year, plus or minus some, ever since, and we're now comfortably at more
than 100.
Any market that has 100 vendors, none of
whose products interoperate with each other, is a failing market,
because none of those vendors, bar only a couple, can claim very large
market share. This is just a market where we haven’t seen the right kind
of approaches deployed, and as a result, we're struck where we are
today without doing something different.
Gardner: Paul, any thoughts on containerization, pros and cons?
Madsen:
I think of phones as almost two completely orthogonal aspects. First is
how you can leverage the phone to authenticate the user. Whether it’s
FIDO or something proprietary, there's value in that.
Secondly is the phone as an application platform, a means to access potentially sensitive applications. What
mobile applications
introduce that’s somewhat novel is the idea of pulling down that
sensitive business data to the device, where it can be more easily lost
or stolen, given the mobility and the size of those devices.
IT, arguably and justifiably, wants to protect the business data on it,
but the employee, particularly in a BYOD case, wants to keep their use
of the phone isolated and private.
The challenge
for the enterprise is, if you want to enable your employees with
devices, or enable them to bring their own in, how do you protect that
data. It seems more and more important, or recognized as the challenge,
that you can’t.
The challenge is not only protecting
the data, but keeping the usage of the phone separate. IT, arguably and
justifiably, wants to protect the business data on it, but the employee,
particularly in a BYOD case, wants to keep their use of the phone
isolated and private.
So containerization or
dual-persona systems attempt to slice and dice the phone up into two or
more pieces. What is missing from those models, and it’s changing, is a
recognition that, by definition, that’s an identity problem. You have
two identities—the business user and the personal user—who want to use
the same device, and you want to compartmentalize those two identities,
for both security and privacy reasons.
Identity standards and technologies could play a real role in keeping those pieces separate.The employee might use
Box
for the business usage, but might also use it for personal usage.
That’s an identity problem, and identity will keep those two
applications and their usages separate.
Diodati:
To build on that a little bit, if you take a look at the history of
containerization, there were some technical problems and some usability
problems. There was a lack of usability that drove an acceptance problem
within a lot of enterprises. That’s changing over time.
To
talk about what Michael was talking about in terms of the failure of
other standardized approaches to authentication, you could look back at
OATH,
which is maybe the last big industry push, 2004-2005, to try to come up
with a standard approach, and it failed on interoperability. OATH was a
one-time password, multi-vendor capability. But in the end, you really
couldn’t mix and match devices. Interoperability is going to be a big,
big criteria for acceptance of FIDO.
[See more on identity standards and APIs.]
Mobile device management
Gardner:
Another thing out there in the market now, and it has gotten quite a
bit of attention from enterprises as they are trying to work through
this, is
mobile device management (MDM).
Do you have any thoughts, Mark, on why that has not necessarily worked
out or won’t work out? What are the pros and cons of MDM?
Diodati:
Most organizations of a certain size are going to need an enterprise
mobility management solution. There is a whole lot that happens behind
the scenes in terms of binding the user's identity, perhaps putting a
certificate on the phone.
Michael talked about X.509.
That appears to be the lowest common denominator for authentication from
a mobile device today, but that can change over time. We need ways to
be able to authenticate users, perhaps issue them certificates on the
phone, so that we can do things like IPSec.
Also, we may be required to give some users access to offline secured data. That’s a combination of apps and
enterprise mobility management (EMM)
technology. In a lot of cases, there's an EMM gateway that can really
help with giving offline secure access to things that might be stored on
network file shares or in
SharePoint, for example.
If
there's been a stumbling block with EMM, it's just been that the
heterogeneity of the devices, making it a challenge to implement a
common set of policies.
The fundamental issue with MDM is, as the name suggests, that you're
trying to manage the device, as opposed to applications or data on the
device.
But also the technology of EMM had to mature. We went from
BlackBerry Enterprise Server, which did a pretty good job in a homogeneous world, but maybe didn't address everybody’s needs. The
AirWatchs and the
Mobile Irons of the world, they've had to deal with heterogeneity and increased functionality.
Madsen:
The fundamental issue with MDM is, as the name suggests, that you're
trying to manage the device, as opposed to applications or data on the
device. That worked okay when the enterprise was providing employees
with their BlackBerry, but it's hard to reconcile in the BYOD world,
where users are bringing in their own
iPhones or
Androids. In their mind, they have a completely justified right to use that phone for personal applications and usage.
So
some of the mechanisms of MDM remain relevant, being able to wipe data
off the phone, for example, but the device is no longer the appropriate
granularity. It's some portion of the device that the enterprise is
authoritative over.
Gardner: It seems to me,
though, that we keep coming back to several key concepts: authentication
and identity, and then, of course, a standardization approach that
ameliorates those interoperability and heterogeneity issues.
[See more on a new vision for identity.]
So
let’s look at identity and authentication. Some people make them
interchangeable. How should we best understand them as being distinct?
What’s the relationship between them and why are they so essential for
us to move to a new architecture for solving these issues? Let’s start
with you, Michael.
Identity is center
Barrett:
I was thinking about this earlier. I remember having some arguments
with Phil Becker back in the early 2000s when I was running the
Liberty Alliance,
which was the standards organization that came up with SAML 2.0. Phil
coined that phrase, "Identity is center," and he used to argue that
essentially everything fell under identity.
What I
thought back then, and still largely do, is that identity is a broad and
complex domain. In a sense, as we've let it grow today, they're not the
same thing. Authentication is definitely a sub-domain of security,
along with a whole number of others. We talked about containerization
earlier, which is a kind of security-isolation technique in many
regards. But I am not sure that identity and authentication are exactly
in the same dimension.
In fact, the way I would
describe it is that if we talk about something like the
levels-of-assurance model, we're all fairly familiar with in the
identity sense. Today, if you look at that, that’s got authentication
and identity verification concepts bound together.
Today, we've collapsed them together, and I am not sure we have actually done anybody any favors by doing that.
In
fact, I suspect that in the coming year or two, we're probably going to
have to decouple those and say that it’s not really a linear
one-dimensonal thing, with level one, level two, level three, and level
four. Rather it's a kind of two-dimensional metric, where we have
identity verification concepts on one side and then authentication comes
from the other. Today, we've collapsed them together, and I am not sure
we have actually done anybody any favors by doing that.
Definitely,
they're closely related. You can look at some of the difficulties that
we've had with identity over the last decade and say that it’s because
we actually ignored the authentication aspect. But I'm not sure they're
the same thing intrinsically.
Gardner:
Interesting. I've heard people say that any high-level security mobile
device has to be about identity. How else could it possibly work?
Authentication has to be part of that, but identity seems to be getting
more traction in terms of a way to solve these issues across all other
variables and to be able to adjust accordingly over time and even
automate by a policy.
Mark, how do you see identity and authentication? How important is identity as a new vision for solving these problems?
Diodati:
You would have to put security at the top, and identity would be a
subset of things that happen within security. Identity includes
authorization -- determining if the user is authorized to access the
data. It also includes provisioning. How do we manipulate user
identities within critical systems -- there is never one big identity in
the sky. Identity includes authentication and a couple of other things.
To answer the second part of your question, Dana, in
the role of identity and trying to solve these problems, we in the
identity community have missed some opportunities in the past to talk
about identity as the great enabler.
With mobile
devices, we want to have the ability to enforce basic security controls ,
but it’s really about identity. Identity can enable so many great
things to happen, not only just for enterprises, but within the digital
economy at large. There's a lot of opportunity if we can orient identity
as an enabler.
Authentication and identity
Madsen:
I just think authentication is something we have to do to get to
identity. If there were no bad people in the world and if people didn’t
lie, we wouldn’t need authentication.
We would all
have a single identifier, we would present ourselves, and nobody else
would lay claim to that identifier. There would be no need for strong
authentication. But we don’t live there. Identity is fundamental, and
authentication is how we lay claim to a particular identity.
Diodati:
You can build the world's best authorization policies. But they are
completely worthless, unless you've done the authentication right,
because you have zero confidence that the users are who they say there
are.
Gardner: So, I assume that multifactor
authentication also is in the subset. It’s just a way of doing it
better or more broadly, and more variables and devices that can be
brought to bear. Is that correct?
Madsen: Indeed.
We have to apply a set of adaptive techniques to get better identity assurance about the user.
Diodati:
The definition of multifactor has evolved over time too. In the past,
we talked about “strong authentication”. What we mean was “two-factor
authentication,” and that is really changing, particularly when you look
at some of the emerging technologies like FIDO.
If
you have to look at the broader trends around adaptive authentication,
the relationship to the user or the consumer is more distant. We have to
apply a set of adaptive techniques to get better identity assurance
about the user.
Gardner: I'm just going to make
a broad assumption here that the authentication part of this does get
solved, that multifactor authentication, adaptive, using devices that
people are familiar with, that they are comfortable doing, even
continuing to use many of the passwords, single sign-on, all that gets
somehow rationalized.
Then, we're elevated to this
notion of identity. How do we then manage that identity across these
domains? Is there a central repository? Is there a federation? How would
a standard come to bear on that major problem of the federation issue,
control, and management and updating and so forth? Let’s go back to
Michael on that.
Barrett: I tend to start from a
couple of different perspectives on this. One is that we do have to fix
the authentication standards problem, and that's essentially what FIDO
is trying to do.
So, if you accept that FIDO solves
authentication, what you are left with is an evolution of a set of
standards that, over the last dozen years or so, starting with SAML 2.0,
but then going on up through the more recent things like
OpenID Connect and
OAuth 2.0,
and so on, gives you a robust backplane for building whatever business
arrangement is appropriate, given the problem you are trying to solve.
Liability
I
chose the word "business" quite consciously in there, because it’s fair
to say that there are certain classes of models that have stalled out
commercially for a whole bunch of reasons, particularly around the
dreaded L-word, i.e, liability.
We tried to build
things that were too complicated. We could just describe this grand
long-term vision of what the universe looked like.
Andrew Nash
is very fond of saying that we can describe this rich ecosystem as
identity-enabled services and so on, but you can’t get there from here,
which is the punch line of a rather old joke.
Gardner:
Mark, we understand that identity is taking on a whole new level of
importance. Are there some examples that we can look to that illustrate
how an identity-centric approach to security, governance, manageability
for mobile tier activities, even ways it can help developers bring new
application programming interfaces (APIs) into play and context for commerce and location, are things we haven’t even scratched the surface of yet really?
Identity is pretty broad when you take a look at the different disciplines that might be at play.
Help
me understand, through an example rather than telling, how identity
fits into this and what we might expect identity to do if all these
things can be managed, standards, and so forth.
Diodati:
Identity is pretty broad when you take a look at the different
disciplines that might be at play. Let’s see if we can pick out a few.
We
have spoken about authentication a lot. Emerging standards like FIDO
are important, so that we can support applications that require higher
assurance levels with less cost and usability problems.
A
difficult trend to ignore is the API-first development modality. We're
talking about things like OAuth and OpenID Connect. Both of those are
very important, critical standards when we start talking about the use
of API- and even non-API HTTP based stuff.
OpenID
Connect, in particular, gives us some abilities for users to find where
they want to authenticate and give them access to the data they need.
The challenge is that the mobile app is interacting on behalf of a user.
How do you actually apply things like adaptive techniques to an API
session to raise identity assurance levels? Given that OpenID Connect
was just ratified earlier this year, we're still in early stages of how
that’s going to play out.
Gardner: Michael, any thoughts on examples, use cases, a vision for how this should work in the not too distant future?
Barrett:
I'm a great believer in open standards, as I think I have shown
throughout the course of this discussion. I think that OpenID Connect,
in particular, and the fact that we now have that standard ratified, [is
useful]. I do believe that the standards, to a very large extent, allow
the creation of deployments that will address those use-cases that have
been really quite difficult [without these standards in place].
Ahead of demand
The
problem that you want to avoid, of course, is that you don’t want a
standard to show up too far ahead of the demand. Otherwise, what you
wind up with is just some interesting specification that never gets
implemented, and nobody ever bothers deploying any of the
implementations of it.
So, I believe in just-in-time
standards development. As an industry, identity has matured a lot over
the last dozen years. When SAML 2.0 came along in Shibboleth, it was a
very federation-centric world, addressing a very small class of use
cases. Now, we have a more robust sets of standards. What’s going to be
really interesting is to see, how those new standards get used to
address use cases that the previous standards really couldn’t?
I'm
a bit of a believer in sort of Darwinian evolution on this stuff and
that, in fact, it’s hard to predict the future now. Niels Bohr famously
said, "Prediction is hard, especially when it involves the future.”
There is a great deal of truth to that.
Prediction is hard, especially when it involves the future.
Gardner: Hopefully we will get some clear insights at the
Cloud Identity Summit this month, July 19, and there will be more information to be had there.
I also wonder whether we're almost past the point now when we talk about mobile security, cloud security,
data-center
security. Are we going to get past that, or is this going to become
more of a fabric of security that the standards help to define and then
the implementations make concrete? Before we sign off, Mark, any last
thoughts about moving beyond segments of security into a more pervasive
concept of security?
Diodati: We're already starting to see that, where people are moving towards
software as a service (SaaS)
and moving away from on-premises applications. Why? A couple of
reasons. The revenue and expense model lines up really well with what
they are doing, they pay as they grow. There's not a big bang of initial
investment. Also, SaaS is turnkey, which means that much of the
security lifting is done by the vendor.
That's also certainly true with
infrastructure as a service (IaaS). If you look at things like
Amazon Web Services (AWS). It is more complicated than SaaS, it is a way to converge security functions within the cloud.
You may also be interested in:
