identity-fraud

A Case of Mistaken Identity

Spice IT

by |

Answering identity questions has become paramount in today’s mobile world.  Without accurately answering the identity question, the idea of relevant, meaningful policy becomes increasingly difficult, and ultimately limits the effectiveness of the security control.

So, what do I mean by the identity question?

If I stand at the front door of most organizations today, I’m likely to see all kinds of interesting, really fun and cool devices being carried in by all different folks within the organization.  As the network security guru, I would ask myself a few questions…

Who is the user?

What is the device they just carried in?

Do I own this device or is this a personal device?

Will bad things happen if this device is connected to my network?

And at some point I usually arrive to my final questions…

What access does this user and device really need? And,

How do I protect the organization from the user and device so bad things won’t happen?

The final two questions directly deal with policy.  Many organizations are starting to think critically about differentiated access based on some level of contextual criteria, or more interesting forms of identity.  And increasingly, I see folks taking the posture of mobile devices more seriously.  There is real risk with malware ending up on Android or iOS devices.  This is why Mobile Device Management (MDM) exists and helps organizations understand if their mobile devices are compliant with company policy.  Are they running a rooted version of iOS?  Are there untrustworthy apps installed?  Does it have the right security settings enforced to protect the endpoint if it’s lost or stolen?

The trick is to arrive to meaningful policy based on identity.  What good is a policy that says no personal mobile devices are allowed on the inside network when the only question we can answer is, who is the user?  Yet, many organizations do exactly this by only using user-level authentication on their wireless network and wonder why every other attached network device is a mystery to them.  A set of valid credentials in Active Directory is no longer going to work.  It’s simply too easy for users to lift valid credentials off their corporate-issued Windows machine and drop it on the latest Android they got for Christmas.  The problem has changed, and so should the answers.

So, let’s explore some alternatives to our traditional approach to identity.

What is the device they carried in?

Interesting question.  Here we want to get an idea of what the device is to make a more intelligent decision on whether or not it should be on the network, and ultimately, based on device type, what level access it should have.

There are two generally accepted approaches to answering this question.

First, we can use Cisco Identity Services Engine (ISE) to Profile a device and try to determine exactly what type of device this is based on interesting information we can learn about the device.  Think of it as Cisco ISE trying to perform a six-point fingerprint match on the device.  The more information available to Cisco ISE, the more likely it’s able to figure it out.  Cisco ISE has an internal database that’s able to dynamically detect and classify hundreds of endpoints.  You want to know the difference between a PS3 and Xbox; no problem.  What about iPhone versus iPad?  Or Android and Blackberry?

A second approach would be to use certificates for machine-level authentication, and to bury some interesting meta-data into the certificate to help identity asset type through an 802.1x authentication session.  Now, this method will never be as accurate in determining asset type, as Cisco ISE Profiling will be.  However, if we’re looking to make a simple distinction between a Windows and a mobile device, this is a great way to do it.

The common use-case for deploying certificates for an 802.1x network is a certificate deployed on Windows machines, and a certificate on mobile devices.  Typically, Active Directory GPO would be used to deploy certificates to domain-attached Windows endpoints, which allows us to deploy a certificate from a very specific profile within the PKI environment, and gives us the opportunity to write some meta-data into the certificate that allows us to identify it as a “windows machine”

And maybe we use a MDM solution or the Cisco ISE PKI Provisioning feature to provision certificates to mobile devices from another very specific profile within the PKI environment, which also gives us the opportunity to write some meta-data into the certificate that allows us to identify it as a “mobile device”.

And now, when authenticating the device, we interrogate the certificate for interesting meta-data to make a device type decision based on “windows machine” or “mobile device”.   This is a very generic form of profiling; albeit effective in making a simple decision based on device type.  For folks that don’t need to know the difference between an Android and iPhone, but simply want to know that it’s a mobile device or Windows asset, this is a very cost-effective and simple way to approach the problem.

Do I own this device or is this a personal device?

Personally, I believe asset ownership is one of the most important questions we can ask ourselves.  It sets the table on how far and what security controls we’re willing to apply to the endpoint.  Case in point, you don’t want to posture a contractor’s device and be responsible for updating it when it breaks, which inevitably, it will.  Or maybe you only want to apply MDM controls to mobile devices you have issued.  Understanding asset ownership is key in both of these policy decisions.  So how do we show asset ownership in today’s world?

By nature of having a certificate on a machine, one could argue that the presence of the certificate itself shows asset ownership.  This notion has been generally accepted for quite some time.  The added benefit here is that it’s much simpler to perform authentication on mobile devices with certificates, (remember, there is no keyboard on the iPhone), and that we can use certificates to perform some generic profiling.  And, once we have a certificate available, maybe we do more interesting stuff with it, like two-factor VPN authentication or authenticated application access.

I see a significant amount of customers moving towards certificate-based authentication because of exactly these reasons.  If asset ownership is an important question to answer for your organization, I would strongly encourage you to think about using a certificate-based authentication method such as EAP-TLS.

Will bad things happen if I connect this device to my network? 

Possibly.  Anyone follow the latest trade rags around Android?  There is a good chance that your personal Android device is already compromised.  Apple’s story is they control the App Store, so you’re safe.  That is, as long as you don’t run a rooted version of iOS, and as long as Apple can actually control the App Store.  Disregard the fact it has been circumvented once or twice already.

But security is about risk reduction right?  This is why MDM is a real technology, and this is why there is an API between Cisco ISE and your top MDM players (MobileIron, AirWatch, Zenprise, and Good Technology) so that we can query interesting information about the posture of the mobile device before we make an access decision.

You should see this feature released in Cisco ISE 1.2 targeted around February sometime.

Comments

6 Comments

  1. smart

    It’s truly a great and useful piece of info. I’m happy that you simply shared this useful information with us. Please keep us informed like this. Thanks for sharing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>