The Notion of Identity: An Interview with Quantum Secure CEO Ajay Jain about Converged Physical and Logical Identity and Access Management

| 0 Comments | 0 TrackBacks
jain.jpgHow many identities do you have? The question should not be taken lightly. In a typical enterprise, one person may have multiple identities with multiple privileges across different systems, from payroll to applications to geographically dispersed physical facilities. Effectively managing those identities is an issue getting increased attention from both logical and physical security professionals, making it a natural area for converged solutions.

While researching converged logical and physical identity and access management, Security Squared recently spoke with Ajay Jain (pictured left), CEO of Quantum Secure. Jain's perspective on logical and physical security convergence has been shaped by working with such clients as Toronto Pearson International Airport; Juniper Networks; Adobe and others. These clients use Quantum Secure's SAFE Physical-Identity Management System (P-IDMS), the San Jose, Calif.-based company's signature product.

SAFE enables enterprises, especially those with complex physical access management needs, to create "one identity per individual and one provisioning process across all physical locations and physical access control systems." It accomplishes this by tight integration with IT-side identity sources as well as bridging into any physical access control system.

Jain talked with Security Squared about the role of identity in effective security, the need for converged physical and logical identity/access management (IAM), and the risks of separate logical and physical identities and more.

What follows is an abridged and edited transcription of our conversation:

Jain on how identity was perceived as proprietary physical access control systems were implemented:

....The notion of an identity was never understood properly: who is the identity, what is the credential of that identity, what is the role of that particular identity, what are the access privileges of that identity and what is the identity allowed to do and what then if that identity does something else...is there a way to keep track of that...is there a way to not allow that identity to do something which is not supposed to be done by that particular identity in that role.

These are all the challenges that folks from Oracle, Sun and all of those partners of ours are solving from...the digital persona standpoint. Identity has a digital persona: it goes into the network, it goes into various applications, and they have rules, some kind of policies, based upon which they've given access so an [accounts payable] manager can go into the SAP system [and] pay someone's invoice but...not be allowed to bring up a new vendor--that's someone else's role. There's all that stuff that happens in the digital side of the house....

....But on the physical side of the house, there's no concept of an identity. You have a card, the card has a concept of an identity, right? The card has a number, XYZ, you enter the card into the door reader, you get [access]....But the concept of an identity has been missing so long--for years and years and years because nobody understood or cared: what's the credential that goes with that identity, what's the privilege, what's the role, why does this person need to go in there, who needs to authorize that...all of those things were missing because people were just calling, or emailing: I need this person to go in this building, the access is given. That's been the modus operandi before.

So all the access control systems never actually looked into identity as an identity--we always were door managers. Open, close the door, based upon a certain external input coming into their environment....

But when [Quantum Secure] looked into the identity ourselves, we said, okay, let's take a pause here: we're going to take the identity from the IT world and we're going to do exactly what we're supposed to, to recognize that identity, authenticate that identity, then authorize that identity into my physical world based upon certain roles, policies and things like that. So this authentication, authorization and recognition of an identity basically became our "imbibe concept" on the physical side of the house.

So when we go out and deploy our system, on the one end we do connect with all the IT systems--authoritative identity sources--we imbibe all those attributes, all those credentials, privileges and roles that would make our lives in the physical world easy.

On disparate identities across systems and locations:

Now another question is: I'm an identity. I'm Sharon Watson and I live in San Jose, I work in San Jose, I have a Sharon Watson persona in San Jose, but in San Francisco, I could be Sharon W. I have a different card. I go to London, I could be a completely different person--maybe a temporary card is issued to me that I always carry with me. So I lose my identity notion right there. There's no identity notion in a fragmented, disjointed system of silos of applications.

So one of the things we do is that once your authoritative identity has been established...we manage that particular identity concept and digitalize that identity into the physical world as well. So wherever you go...you just need one card, and that card should be a Sharon Watson card. To take it to the next stage, it could be fingerprint authenticated, biometric system authenticated, and that can be done only at one time, so then you're free to move in your allowed privileged areas anywhere in the world.

On converged IAM and compliance:

Compliance related to who gets what, who's allowed where, why, and who authorized that is something that is completely missing in physical security because there's no accountability out there. The process today is very manual and unaccountable: very email based, phone call based. Some companies are form based. But no one keeps track of any of those things. If you go back and audit and ask how come Dan got access into this particular restricted zone last year, nobody would have a clue.

Who let him in, how many times has he been in that restricted area, why he was there 25 times in the last year? All of those things have now become scrutinized by laws that have come into place in the last 5-7 years...

On managing the potential fluidity of an identity:

We have one of the very large airports in Canada...they have about 35,000 employees, over 220 employers out there and...it becomes very complicated...because they have a lot of areas and restricted zones...and the notion of identity also keeps on changing because today, I'm an employee of Delta Airlines from 8:00 a.m to 12:00 p.m. and from 1:00 pm to 4:00 pm I become an employee of United Airlines. So my identity suddenly makes a change after a time, and there's no system out there or anywhere where you can manage multiple identities of the same person on the same day by the time and give various access and apply restrictions using just one identity card.

So our system becomes a superlative identity and access management on the airport side because we manage identities as opposed to the cards...this identity persisted in the system as this for the first four hours, then identity changed its shape and became something else, but the card remains the same...the card becomes the secondary credential that keeps on changing but the notion of identity is what we manage.

On establishing the authoritative identity:

...We look for an authoritative data source. Now in the airport market, there are no authoritative data sources. There's no LDAP, no IDM, it's very disjointed, fragmented, very contingent workforce out there. They come in, they go out, they're quite transient in nature. So we become the authoritative data source, "we" meaning our system becomes the authoritative data source.

But if you look into a commercial market, a high tech company or any of the other companies that we have, they do have some kind of an LDAP system or HR system where they use that system to manage the payroll of their people or contractors. That becomes our authoritative data source. If you give us a link to your authoritative data source, we want to make sure that every single identity and its attributes persist into the physical security side of the house without any alteration, without any change. We become a system of record for that identity into the physical side of the house.

On managing the physical identity life cycle:

...I won't name the company but [it's] a real scenario. I go to London, I work for company X, I get a temporary badge from that facility. I come back and after two weeks, I get terminated. Somebody in the IT side of the house terminates my network account and everything else gets terminated from the IT side. But I come to San Jose: if they don't go into the system and terminate it manually, [my access card] will always persist. My temporary card I hold from the London facilities? No clue. It will always persist. There's no recording of who gave this card to whom. There's no binding of the card to the identity. There's no identity concept out there.

What will happen after I get terminated? After hours, I can always access my San Jose facility if my card has not been terminated. Or I can walk into the London office and access that facility any time I want. That's a real case.

...The continuous management of the life cycle of that identity into the physical security structure, then the revocation of that identity cleanly across the board in the physical security infrastructure is actually a very daunting task today, a very manual task, because there are silos of infrastructure out there.

In some places there are biometric devices, in some places there are multiple access control systems, in some places different kinds of [card] reader groups, the cards themselves are very, very different. So how do you tie all of those things together into a single, homogenized, policy based system? That's where we come into the picture.

...I used to work for a company [about ten years ago], my card still works in the facility, and that facility has actually changed hands twice. Once in a while we joke around and go and check whether it works...the reason I keep that card is just to make sure the problem we are trying to solve is a real problem out there in the world.

On a mini-case study of identity-based physical access management:

Here's a scenario: This customer has telephone exchanges worldwide. In those telephone exchanges, they host other [companies'] equipment....Each exchange has an access control system...Their scenario is when a work order comes in for a repair--let's say Amazon.com needs to enter that exchange to flip a router--their contingent [third party] work force carries a card. [Our client] wants to make sure [if] the work order is from 2:00 p.m to 4:00 p.m. for the repair, that particular card will only work between 2:00 p.m. and 4:00 p.m. based upon that work order and based upon the assigned identity.

With a large company, there may be 5,000 work orders every week, 10,000 work orders every week...in order to process that you need about 50 people to do checks and balances. Or you have a system in which you are managing the notion of that identity, and an external stimulus, which is the work order, coming in, and then binding that particular physical access card to that identity and thus allowing that physical security system to imbibe that identity notion, not the card. Once the work order is finished, then [you] disjoin the identity with that card, and the card then becomes a useless card, meaning there are no privileges associated with that card, it deactivates itself.

That's a very real life example I just gave you.

On comparing the ability to create access policies across disparate physical systems with the provisioning capabilities of logical systems:

Well, let's say you're a VP at a large company or a senior director on up. You want to make sure my director and VPs on up all have access to my facilities worldwide. The only way they can do that is manual in nature. You have 25 access control systems...and you have 25 executives and somebody goes in, 25 times 25, and puts those records into the access control systems. There's no concept of a policy that says okay, I'm going to connect to an authoritative data source, that data source is always current, gives me real time information of who the directors on up are, and I write that policy in ten minutes and it says regardless of number of access control systems, regardless of how disjointed they are, I want to make sure these people have lobby access across the world. That's the difference.

There's no one off case per se. Because of the disparity and disjointedness across the physical access control system world, the notion of a process does not exist. You can do that in the IT world, say "director and up," and all of those would get access to my Sharepoint document management system. It's very easy for them to do that because they connect with LDAP, give all the privileges to the Sharepoint directory. Very simple. It's done, right? But in the physical world, there's no network of anything, it's all disjointed, disconnected, archaic technologies associated with that. That's where the problem comes in, because someone manually does it 25 by 25 times.

On the impact of Oracle's acquisition of Sun, given that both companies have competitive logical identity management offerings:

I have two thoughts on that. Number one, both Oracle and Sun are very, very strong partners of Quantum Secure, and we respect both of them. I think if you look into the typical history of Oracle, when they acquire a large company, it doesn't mean that the products are retired immediately. They still have PeopleSoft, and they still have Oracle, that's two separate offerings out there. I would say [the IDMs] would continue four or five years before they make distinctions.

Point number two for Quantum Secure per se, since we connect with both of them and we regard both of them as an authoritative data source for us coming in, it really doesn't matter...say for argument's sake, Sun IDM becomes Oracle IDM. For our world it really doesn't matter because we already connect, we already have complete integrative processes with these two systems. So...if a customer switches from Sun to Oracle or Oracle to Sun, we'll have a very small simple agent change, and we will be live again.

On what physical access control systems can offer to logical identity management systems when integrated:

In today's world, the physical system rarely offers anything to the logical, right? But when we connect these systems together, we offer a lot of things to the logical systems during the course of identity management. For instance, somebody is terminated and walk[s] out right away. We send that message out to the logical systems about that termination.

So now a PACS system or any other physical security system cannot do that....we do that basically based upon the need of the market today, the problems they're trying to solve which are integrative for both the logical and physical side of the house.

(Read additional examples here in an interview with Jain on PSIM.)

On the need to associate physical and logical identities at all times:

...The biggest thing that [CIOs and CSOs] need to understand is that identity has two personas...a digital persona and a physical persona. Unless the digital personal and the physical persona are together at all times, their security will be compromised, or can be compromised. This is the biggest message. If we don't keep that persona together at all times, in whatever form or fashion...if there are role changes up there on the digital side, that must change down in the physical; if last name changes in digital, last name must change in physical; something happens in digital, the same thing has to take effect in physical.

If you cannot keep those concomitant with each other all the time, security can be compromised --it will be very easy to compromise.

Security Squared visitors are invited to share this article. If you wish to excerpt material, we request that you cite Security Squared as the source, or better still, link directly to this page. Thank you for your consideration. 

jain.jpgHow many identities do you have? The question should not be taken lightly. In a typical enterprise, one person may have multiple identities with multiple privileges across different systems, from payroll to applications to geographically dispersed physical facilities. Effectively managing those identities is an issue getting increased attention from both logical and physical security professionals, making it a natural area for converged solutions.

While researching converged logical and physical identity and access management, Security Squared recently spoke with Ajay Jain (pictured left), CEO of Quantum Secure. Jain's perspective on logical and physical security convergence has been shaped by working with such clients as Toronto Pearson International Airport; Juniper Networks; Adobe and others. These clients use Quantum Secure's SAFE Physical-Identity Management System (P-IDMS), the San Jose, Calif.-based company's signature product.

SAFE enables enterprises, especially those with complex physical access management needs, to create "one identity per individual and one provisioning process across all physical locations and physical access control systems." It accomplishes this by tight integration with IT-side identity sources as well as bridging into any physical access control system.

Jain talked with Security Squared about the role of identity in effective security, the need for converged physical and logical identity/access management (IAM), and the risks of separate logical and physical identities and more.

What follows is an abridged and edited transcription of our conversation:

Jain on how identity was perceived as proprietary physical access control systems were implemented:

....The notion of an identity was never understood properly: who is the identity, what is the credential of that identity, what is the role of that particular identity, what are the access privileges of that identity and what is the identity allowed to do and what then if that identity does something else...is there a way to keep track of that...is there a way to not allow that identity to do something which is not supposed to be done by that particular identity in that role.

These are all the challenges that folks from Oracle, Sun and all of those partners of ours are solving from...the digital persona standpoint. Identity has a digital persona: it goes into the network, it goes into various applications, and they have rules, some kind of policies, based upon which they've given access so an [accounts payable] manager can go into the SAP system [and] pay someone's invoice but...not be allowed to bring up a new vendor--that's someone else's role. There's all that stuff that happens in the digital side of the house....

....But on the physical side of the house, there's no concept of an identity. You have a card, the card has a concept of an identity, right? The card has a number, XYZ, you enter the card into the door reader, you get [access]....But the concept of an identity has been missing so long--for years and years and years because nobody understood or cared: what's the credential that goes with that identity, what's the privilege, what's the role, why does this person need to go in there, who needs to authorize that...all of those things were missing because people were just calling, or emailing: I need this person to go in this building, the access is given. That's been the modus operandi before.

So all the access control systems never actually looked into identity as an identity--we always were door managers. Open, close the door, based upon a certain external input coming into their environment....

But when [Quantum Secure] looked into the identity ourselves, we said, okay, let's take a pause here: we're going to take the identity from the IT world and we're going to do exactly what we're supposed to, to recognize that identity, authenticate that identity, then authorize that identity into my physical world based upon certain roles, policies and things like that. So this authentication, authorization and recognition of an identity basically became our "imbibe concept" on the physical side of the house.

So when we go out and deploy our system, on the one end we do connect with all the IT systems--authoritative identity sources--we imbibe all those attributes, all those credentials, privileges and roles that would make our lives in the physical world easy.

On disparate identities across systems and locations:

Now another question is: I'm an identity. I'm Sharon Watson and I live in San Jose, I work in San Jose, I have a Sharon Watson persona in San Jose, but in San Francisco, I could be Sharon W. I have a different card. I go to London, I could be a completely different person--maybe a temporary card is issued to me that I always carry with me. So I lose my identity notion right there. There's no identity notion in a fragmented, disjointed system of silos of applications.

So one of the things we do is that once your authoritative identity has been established...we manage that particular identity concept and digitalize that identity into the physical world as well. So wherever you go...you just need one card, and that card should be a Sharon Watson card. To take it to the next stage, it could be fingerprint authenticated, biometric system authenticated, and that can be done only at one time, so then you're free to move in your allowed privileged areas anywhere in the world.

On converged IAM and compliance:

Compliance related to who gets what, who's allowed where, why, and who authorized that is something that is completely missing in physical security because there's no accountability out there. The process today is very manual and unaccountable: very email based, phone call based. Some companies are form based. But no one keeps track of any of those things. If you go back and audit and ask how come Dan got access into this particular restricted zone last year, nobody would have a clue.

Who let him in, how many times has he been in that restricted area, why he was there 25 times in the last year? All of those things have now become scrutinized by laws that have come into place in the last 5-7 years...

On managing the potential fluidity of an identity:

We have one of the very large airports in Canada...they have about 35,000 employees, over 220 employers out there and...it becomes very complicated...because they have a lot of areas and restricted zones...and the notion of identity also keeps on changing because today, I'm an employee of Delta Airlines from 8:00 a.m to 12:00 p.m. and from 1:00 pm to 4:00 pm I become an employee of United Airlines. So my identity suddenly makes a change after a time, and there's no system out there or anywhere where you can manage multiple identities of the same person on the same day by the time and give various access and apply restrictions using just one identity card.

So our system becomes a superlative identity and access management on the airport side because we manage identities as opposed to the cards...this identity persisted in the system as this for the first four hours, then identity changed its shape and became something else, but the card remains the same...the card becomes the secondary credential that keeps on changing but the notion of identity is what we manage.

On establishing the authoritative identity:

...We look for an authoritative data source. Now in the airport market, there are no authoritative data sources. There's no LDAP, no IDM, it's very disjointed, fragmented, very contingent workforce out there. They come in, they go out, they're quite transient in nature. So we become the authoritative data source, "we" meaning our system becomes the authoritative data source.

But if you look into a commercial market, a high tech company or any of the other companies that we have, they do have some kind of an LDAP system or HR system where they use that system to manage the payroll of their people or contractors. That becomes our authoritative data source. If you give us a link to your authoritative data source, we want to make sure that every single identity and its attributes persist into the physical security side of the house without any alteration, without any change. We become a system of record for that identity into the physical side of the house.

On managing the physical identity life cycle:

...I won't name the company but [it's] a real scenario. I go to London, I work for company X, I get a temporary badge from that facility. I come back and after two weeks, I get terminated. Somebody in the IT side of the house terminates my network account and everything else gets terminated from the IT side. But I come to San Jose: if they don't go into the system and terminate it manually, [my access card] will always persist. My temporary card I hold from the London facilities? No clue. It will always persist. There's no recording of who gave this card to whom. There's no binding of the card to the identity. There's no identity concept out there.

What will happen after I get terminated? After hours, I can always access my San Jose facility if my card has not been terminated. Or I can walk into the London office and access that facility any time I want. That's a real case.

...The continuous management of the life cycle of that identity into the physical security structure, then the revocation of that identity cleanly across the board in the physical security infrastructure is actually a very daunting task today, a very manual task, because there are silos of infrastructure out there.

In some places there are biometric devices, in some places there are multiple access control systems, in some places different kinds of [card] reader groups, the cards themselves are very, very different. So how do you tie all of those things together into a single, homogenized, policy based system? That's where we come into the picture.

...I used to work for a company [about ten years ago], my card still works in the facility, and that facility has actually changed hands twice. Once in a while we joke around and go and check whether it works...the reason I keep that card is just to make sure the problem we are trying to solve is a real problem out there in the world.

On a mini-case study of identity-based physical access management:

Here's a scenario: This customer has telephone exchanges worldwide. In those telephone exchanges, they host other [companies'] equipment....Each exchange has an access control system...Their scenario is when a work order comes in for a repair--let's say Amazon.com needs to enter that exchange to flip a router--their contingent [third party] work force carries a card. [Our client] wants to make sure [if] the work order is from 2:00 p.m to 4:00 p.m. for the repair, that particular card will only work between 2:00 p.m. and 4:00 p.m. based upon that work order and based upon the assigned identity.

With a large company, there may be 5,000 work orders every week, 10,000 work orders every week...in order to process that you need about 50 people to do checks and balances. Or you have a system in which you are managing the notion of that identity, and an external stimulus, which is the work order, coming in, and then binding that particular physical access card to that identity and thus allowing that physical security system to imbibe that identity notion, not the card. Once the work order is finished, then [you] disjoin the identity with that card, and the card then becomes a useless card, meaning there are no privileges associated with that card, it deactivates itself.

That's a very real life example I just gave you.

On comparing the ability to create access policies across disparate physical systems with the provisioning capabilities of logical systems:

Well, let's say you're a VP at a large company or a senior director on up. You want to make sure my director and VPs on up all have access to my facilities worldwide. The only way they can do that is manual in nature. You have 25 access control systems...and you have 25 executives and somebody goes in, 25 times 25, and puts those records into the access control systems. There's no concept of a policy that says okay, I'm going to connect to an authoritative data source, that data source is always current, gives me real time information of who the directors on up are, and I write that policy in ten minutes and it says regardless of number of access control systems, regardless of how disjointed they are, I want to make sure these people have lobby access across the world. That's the difference.

There's no one off case per se. Because of the disparity and disjointedness across the physical access control system world, the notion of a process does not exist. You can do that in the IT world, say "director and up," and all of those would get access to my Sharepoint document management system. It's very easy for them to do that because they connect with LDAP, give all the privileges to the Sharepoint directory. Very simple. It's done, right? But in the physical world, there's no network of anything, it's all disjointed, disconnected, archaic technologies associated with that. That's where the problem comes in, because someone manually does it 25 by 25 times.

On the impact of Oracle's acquisition of Sun, given that both companies have competitive logical identity management offerings:

I have two thoughts on that. Number one, both Oracle and Sun are very, very strong partners of Quantum Secure, and we respect both of them. I think if you look into the typical history of Oracle, when they acquire a large company, it doesn't mean that the products are retired immediately. They still have PeopleSoft, and they still have Oracle, that's two separate offerings out there. I would say [the IDMs] would continue four or five years before they make distinctions.

Point number two for Quantum Secure per se, since we connect with both of them and we regard both of them as an authoritative data source for us coming in, it really doesn't matter...say for argument's sake, Sun IDM becomes Oracle IDM. For our world it really doesn't matter because we already connect, we already have complete integrative processes with these two systems. So...if a customer switches from Sun to Oracle or Oracle to Sun, we'll have a very small simple agent change, and we will be live again.

On what physical access control systems can offer to logical identity management systems when integrated:

In today's world, the physical system rarely offers anything to the logical, right? But when we connect these systems together, we offer a lot of things to the logical systems during the course of identity management. For instance, somebody is terminated and walk[s] out right away. We send that message out to the logical systems about that termination.

So now a PACS system or any other physical security system cannot do that....we do that basically based upon the need of the market today, the problems they're trying to solve which are integrative for both the logical and physical side of the house.

(Read additional examples here in an interview with Jain on PSIM.)

On the need to associate physical and logical identities at all times:

...The biggest thing that [CIOs and CSOs] need to understand is that identity has two personas...a digital persona and a physical persona. Unless the digital personal and the physical persona are together at all times, their security will be compromised, or can be compromised. This is the biggest message. If we don't keep that persona together at all times, in whatever form or fashion...if there are role changes up there on the digital side, that must change down in the physical; if last name changes in digital, last name must change in physical; something happens in digital, the same thing has to take effect in physical.

If you cannot keep those concomitant with each other all the time, security can be compromised --it will be very easy to compromise.

Security Squared visitors are invited to share this article. If you wish to excerpt material, we request that you cite Security Squared as the source, or better still, link directly to this page. Thank you for your consideration. 

No TrackBacks

TrackBack URL: http://www.securitysquared.com/cgi-bin/mt/mt-tb.cgi/32

Leave a comment