A Leading Physical Access Control Vendor Gets Logical
When discussing the creation of a single enterprise identity represented by one credential good in both the physical and logical space, physical access control systems (PACS) can easily be seen as barriers to that goal. To find out more about how PACS may fit into a converged identity world, Security Squared spoke last month with Erik Larsen (pictured),
director of product management for Lenel Systems, as background for our "One Person, One Identity, One Credential" article.
Larsen discussed Lenel's specific approach to logical integration, as well as customer and industry trends re: merging physical and logical identities. What follows is an abridged transcript of our conversation, edited for clarity and length.
***********
Sharon J. Watson: In researching this converged identity management story, about tying physical access into logical access systems, I'm thinking I don't have enough perspective on what physical access control systems (PACS) bring to this arena. So I'm hoping we can talk through that today.
Erik Larsen: It doesn't surprise me you're missing that perspective. In the past, [physical access control] has come from hardware manufacturers. The focus is securing perimeters and dealing with physical security facilities, those areas of an organization. It gets very narrow in focus: Let's create a silo, we want to protect the silo, let's make sure it can't be infiltrated from anywhere else, and therefore it gets into a mindset of okay, the only way to secure it is by not opening it up.
As an industry, we've kind of tried to push outside of that. I think Lenel is at the forefront of that. Because if you look at Lenel as a company, we came at it not only from a software perspective--let's design software and find hardware that works with our software--but also, let's become a security platform that can leverage an organization and the processes an organization has put in place to secure its people, its intellectual property and also the facility itself.
So in regards to our products and how we approach this and what our customers see as the value add or the unique features of OnGuard and IdentityDefender, I can start by stating that OnGuard has a lot of these connectors built into it. For example, the user accounts, the people that actually log into the application. Not only can you have an internal user name and password that's stored in our system, but you can link it to a directory account. So it automatically will link up to an [Lightweight Directory Access Protocol-based directory] LDAP and allow for that user to single sign-on into the application from their NT authenticated account they have for their network.
That's important because a lot of times IT wants to instill policies around passwords and retention of passwords and those types of things. Why not leverage that technology and also make it a little more integrated so that the physical access control system is tied to the IT policies and procedures on passwords.
From our perspective, that made logical sense. So we've had that for several years, and it's out of the box, the product does that. It's not a feature that requires a license or special cost associated with it. That's something we can provide the customer, a true value add, and it helps to secure the system, so why not make that available to everyone?
So that's the user side....The other side of the Lenel system is the user of the cards within the building, the physical access control itself. Within our system, we call those "cardholders." So there is a separation: "users" are those logging in and doing activities in the software--and "cardholders" are those employees, visitors, others, that are walking through the building interacting with the doors. So we also extend an option to link cardholders to directory accounts.
It's a little more complicated because what happens in a LDAP account, there are many different fields available and the structure you set up is customizable. On the cardholder side are those people who are badge cardholders in our system. We allow the customer the flexibility to create new fields and associate or customize that to meet their needs. Maybe they want to keep demographic information or vehicle information or project information specific to an individual cardholder. So we allow them to customize that interface.
So there are two pieces that are customizable: the directory, and also the OnGuard cardholders. So to match them together--it's very challenging to just do a generic map. A customer might have an employee ID number and they want to put that in a unique field in the directory. Then they want to create a custom field on the cardholder side that will be this employee ID number. How do you map those together?
So we offer a service, there's an integration, that will synchronize the cardholders of the OnGuard system with the directory account users. That's more our large enterprise customers. For the SME market, it doesn't play in that much. If your population is less than a thousand people, it's probably just as easy to create individual accounts within the PACS system and keep them separate.
When you get above a thousand-person population and if you're dealing with high turnover, or enterprise organizations across multiple facilities, now that is much more challenging to manage. So it's those customers that have adopted this interface we offer so that if somebody is added to the directory...it will automatically create a cardholder in our system, all the information is there that the network or the directory had except for the photographic or maybe some other information about what doors they're allowed to have access to.
Then, either based on what we consider to be site managers or local managers, department managers, they define what access [the person] should have and can automatically assign that to the badge.
The last piece is the photograph. Typically, the HR system or where you have e-directories and such--if the directory or NT system does not have the photograph of the person, then they'd go to the access control system, add a photograph, print the badge, and now the badge is linked to the directory account that they have--so that if something happens on either side, they can update the information.
Within our enterprise customers, we are seeing a large adoption of that.
The last point on this would be as we have seen a trend toward standardizing on credentials, both within the government sector and also with large enterprise organizations, saying it's no longer just good enough to have a proximity badge. As we start looking at tying it into logical access, trusting who that person is and that the badge is authentic is critical. So one of the other things we have seen is organizations wanting to put checks and balances on how they actually provide the badges, how do they secure them before they go to employees and how do we make sure this employee should have this badge and what is the status of this badge?
That's where the IdentityDefender comes in. It's really an add-on module to the OnGuard system. It has a workflow element that says you'll go through these checks and balances before a badge is given. I can't just walk up to a badge operator and say, I'm a new employee, here's my information. Print me out a badge. The IdentityDefender workflow is really to say I need to validate who you are, so I might grab some information, like the biometrics of the person. I could create a file that would be submitted to a background or credit or investigative check before I say this person is going be issued a badge.
Once all those checks have been done--and they may be internal to the organization or external against other systems--then the badge operators receive a response indicating this person is able to receive a badge, that all the checks have been completed and because we've had the biometrics from before, we validate the biometrics once again to make sure we're giving the right badge to the right individual.
That adoption of IdentityDefender has been a little bit slower because a lot of these types of checks, both to credit checks or investigative, are either in silos amongst themselves or in highly secure government facilities, and they really haven't opened it up for the enterprises. Some HR departments will do it. They'll submit a paper copy for a credit check on somebody and get a response, but those systems in general are kind of seen as separate silos and it's hard to connect them together....
In terms of market adoption, are customers ready for that? That's not the widespread adoption. The widespread adoption is OnGuard and having cardholders of OnGuard integrated with the directory account so that if someone is added to the directory, they're automatically added to OnGuard, and it allows for the large enterprise organization to manage their employee population for both logical access and physical access.
SJW: I'd like to talk about that process you went through between OnGuard and the employee directory...You'd said it's up to the local managers, business end users, to define the access rights associated with the badge. Is that something they do ahead of time so those badge rules are built into OnGuard and automatically assigned to a badge? Or is done later?
EL: It can be both. We have customers that do it either way. When the identity is provisioned within the logical directory and it passes the information through the LDAP interface into OnGuard cardholder, we define the badge type and that badge type would have default access rights that are assigned to it.
From a user perspective, it's seamless. I go to HR, they create the account for me or it gets automatically provisioned into the directory, we are then looking in real time at the directory, getting the information back and the badge is then created.
That's how we address the standard access rights. If you're a new employee of Lenel, you're going to have access to common areas, to standard conference rooms, break rooms, those types of things. But if you're going to be working on a specific project for a site manager or department, that department might say, for this specific [instance], we want to provide you additional access. They'd provide that after the fact then.
There are some things going on right now in regards to linking your role within...the directory account, and how to pass that over to the access levels within the physical access control so that you're automatically given those access rights based on the role you're going to be doing. That is something that through that LDAP interface is possible.
But I will say the trend right now with physical security is not to get to that level of detail. What ends up happening is the local site manager or department manager wants to retain a little bit more control than just providing IT the authority to let people into their space. But it is possible and the interface is designed so that it allows for it.
SJW: So some of those business end users are not all that comfortable with having that many privileges automated.
EL: Especially when you get into project-specific privileges.
This is kind of off-topic but if you really want to see about pushing the envelope on the concept of physical access control integrated with the rest of the organization, there's something we're developing right now. [We] have launched a green initiative with a sister company of UTC called ALC, they're underneath Carrier, and also with Cisco and Cisco phone systems. They have a proof of concept they've been running and pulling analysis from of the PACS tied to the IP telephony network system tied to the building automation energy management system of a facility.
So if I'm...a remote employee, I'm going to come in for a day, the concept here is I go to a kiosk, request an office space at a particular time and only at the point in time does it activate and energize those items I'd have within that space.
So my IP phone is transferred to that remote desk, my printers would automatically transfer to local printers, the system would know based on my physical access control profile that have been defined that my preference is to have a room sustained at 72 degrees and I prefer ambient light over direct sunlight, and it would automatically adjust shades and lights [and] the temperature of the room so it's sustained for that period of time.
It's taking it all to the next level. Take conference rooms...setting it up through our visitor management, you define how many visitors you'll have, you reserve the space. Automatically when that session starts, the lights are at the right level; when it's done, it automatically turns things off. Then, through some of the work we do through our intelligent video analytics, we can also monitor the room for the occupancy and if the room is not being occupied, the PACS notifies the building automation system to bring back those resources like the light and shades, and everything else.
That's really what we are trying to do. The integration to the directory, the logical--we see the value to the customer is it allows them to have a better understanding of who has rights to their network and to their physical facilities. It allows the administration of access rights and managing of people's responsibilities within the organization more efficiently, and the third thing is it reduces the cost of going ahead and deploying that type of solution and going through that process. Any time you can leverage sharing of information and having the systems communicate with one another just improves the efficiencies over all.
SJW: If you have a client who wants this kind of integration between their directories and PACS and other systems but they aren't willing to standardize on Lenel, how can you help with that?
EL: What we try to do is provide standard tools, interfaces that allow an organization to leverage both their existing and the new technologies. [The core of] Lenel OnGuard is a physical access control system. So if we look at the LDAP or the network infrastructure as being the backbone for the identity provisioning, then there's no reason why we wouldn't be able to share that same information with another third party PACS--as long as they have that capability.
And that's the thing that's outside of our control. We try to leverage the fact we want to create these hooks for the user accounts into the LDAP, for the cardholders into the LDAP, for the access levels to be provisioned...but if another PACS is not at that same level of integration and they don't have the ability to provide that to the directory, it's going to make it very hard for the customer to leverage that existing system. We can only take it so far.
That is the success of companies like Quantum Secure [a Lenel OEP partner]. What they are trying to do, leveraging integration into PACS, is that they become that buffer that would then take third party system A, third party system B and the Lenel OnGuard system and tie them together and then handle the provisioning and the administration of access rights.
Now I know there are some shortfalls with that also because when we look at enterprise architecture and the strength of our solution and how we administer not only the standard stuff of where you have access and when but get into cardholder and custom fields and the unique attributes you assign to the "users" of the system and the "cardholders," it's hard to create a generic application or platform that's going to be able to handle that from all these different systems. So the same challenges we've run into on creating this interface to the LDAP are the same challenges that another company would run into trying to create a standard interface between independent PACS.
So if you do have to replace--and I'm not saying that's the optimal solution--but if you do wind up having to replace, there's a lot of existing infrastructure you can leverage if you're going from one system to another. You have to look at two costs. One cost is the administration of the system. So if PACS systems A, B, C, and D have different back-up policies and different training and upgrades, there's a substantial cost associated with maintaining those separate databases, systems, and updates. So consolidating to one system does save the end user cost over time because now they have one system they're managing for the entire physical access control.
The other cost they can save if they decide to convert over and merge to one common platform for PACS is a lot of the cost associated with the readers and the electro-mechanical hardware that goes into the doors; the wiring infrastructure that's used to communicate to these different devices; the servers, the platforms used for hosting these systems. Typically when talking with our VARs, we normally hear a price per door of anywhere from $2500 to $4000 to secure it. If you look at that cost and what's associated with it, the actual replacement cost of what we consider the controller board, or the board that goes into the closet, and then the software, that is less than 20% of that total cost.
So in the grand scheme of things, is it still a big price tag? Yeah. If I'm an enterprise and have a thousand readers deployed, it's going to cost me several hundred thousand dollars to replace the system and go to a common platform. But in the grand scheme of what have I invested over the long run for this entire system, I've invested millions of dollars and I'm able to retain a lot of [that investment] during that conversion and...and I have the savings of having one platform to manage and update going forward
SJW: Do you forsee a time, Erik, when maybe one way to handle the standardization would be as more of these devices become more intelligent, more IP-based, they could bypass a PACS, and the logical identity system could handle more of these resources, could provision the physical access?
EL: I hope not! The big item I see is there would have to be a merging of the minds of what is physical access control and what is logical access control. There are several elements of physical access control that are not covered by logical, and there are several elements of logical access control that are not covered by physical access.
Having network switches and routers that have physical access control integrated on them and having IP at the edge or on the reader--it's trying to push the IP infrastructure all the way down.
We have customers that try to go that way--the OnGuard platform will work with the Lenel hardware; it will also work with the HID Edge hardware. If you have an HID Edge IP reader, you can attach it to our system, and you don't go through our access control infrastructure. You're not using our cabling, you're not using the Lenel reader interface modules and controllers and logic we've built into our infrastructure. You're just using the server software to provision rights down to those readers. We support that today. And there are customers that want to go that way.
The concerns we've also heard from customers is that by having IP Ethernet capabilities on the outside of the reader, how secure is that? What do we need to look at within our infrastructure to make sure it is secure? Because you can secure it, though VPNs and separate subnets. You can do that, but there is a cost associated with it. So is there a benefit of doing that?
....What are the other things used for physical access control? You have video, you have storage of video, you have analytics, you have fire and intrusion, you have asset management, anti-passback, who has access and when shouldn't they have access--all of that would have to be built into either a directory structure or some sort of logical access system.
Within the physical access control, with heightened security, there's the whole concept of mustering--in the event of catastrophe, having people leave an area and report somewhere else and provide real time reports. There are redundancies built into physical access control infrastructure to support that--redundant, alternate types of communications.
Is the customer's IP infrastructure ready to support that? Some are, some aren't. There are a lot of hidden things that on the surface you can say, yes, a logical access control system could provide a credential that could be used for physical access control, they could control the doors, end of story. But when you dig into the details of it, both from the IT infrastructure and then for the actual use cases for what the customer is trying to do with the securing of their people and facilities, it gets a lot deeper and a lot more complicated.
SJW: Earlier you'd talked about how authenticating people was becoming more important and that's part of what IdentityDefender does with its workflow tools. Can you talk about the impact of that need on the physical tools used to authenticate identity?
EL: It's definitely becoming more important. Within the industry, there's a lot of discussion around multifactor authentication. It's not just what you have, but who you are and what you know. A lot of that can be combination of biometric, PIN, card and also taking it to the next level, so it's not only the card, but how do we validate the card is real and should be trusted.
Biometrics plays a big role. We have seen a trend, an increase in the use of biometrics, fingerprint, vein, hand geometry, retinal. We've seen some concept work on the facial detection and granting access there. I don't think it's as widespread as what I would consider the more fundamental, core biometrics technologies.
We're also seeing a trend, especially in the last year, to provide some sort of authentication of a credential [by] talking to some third party system....So the PACS is not just looking at, I have this badge and have this access level and time, but [going] to a third party system and validating/authenticating who they are and what they have in their possession, this credential, and determining if it should grant them access from that.
SJW: Is that typical of folks outside the government with high security needs?
EL: We're not seeing the adoption in the SME market, it's not there yet, it's too expensive. In the large enterprise, if you're looking at IT financial type of companies, those vertical markets, the adoption isn't toward the authentication but wanting a common credential that will work between the logical space and the physical access. But if you're a large organization working closely with entities of either the ports or government agencies doing secure work, then they're looking at these types of credentials and looking at authenticating the credential and the person for physical access control.
SJW: To clarify for me, we opened talking about OnGuard "users" and "cardholders." Within OnGuard, are these users and cardholders linked through the directory interface to create one credential for one identity?
EL: The answer is yes and no. It can be configured both ways. If customers have embraced the concept of using a credential for logical access, say the Imprivata OneSign solution [Editor's note: Imprivata
When discussing the creation of a single enterprise identity represented by one credential good in both the physical and logical space, physical access control systems (PACS) can easily be seen as barriers to that goal. To find out more about how PACS may fit into a converged identity world, Security Squared spoke last month with Erik Larsen (pictured),
director of product management for Lenel Systems, as background for our "One Person, One Identity, One Credential" article. Larsen discussed Lenel's specific approach to logical integration, as well as customer and industry trends re: merging physical and logical identities. What follows is an abridged transcript of our conversation, edited for clarity and length.
***********
Sharon J. Watson: In researching this converged identity management story, about tying physical access into logical access systems, I'm thinking I don't have enough perspective on what physical access control systems (PACS) bring to this arena. So I'm hoping we can talk through that today.
Erik Larsen: It doesn't surprise me you're missing that perspective. In the past, [physical access control] has come from hardware manufacturers. The focus is securing perimeters and dealing with physical security facilities, those areas of an organization. It gets very narrow in focus: Let's create a silo, we want to protect the silo, let's make sure it can't be infiltrated from anywhere else, and therefore it gets into a mindset of okay, the only way to secure it is by not opening it up.
As an industry, we've kind of tried to push outside of that. I think Lenel is at the forefront of that. Because if you look at Lenel as a company, we came at it not only from a software perspective--let's design software and find hardware that works with our software--but also, let's become a security platform that can leverage an organization and the processes an organization has put in place to secure its people, its intellectual property and also the facility itself.
So in regards to our products and how we approach this and what our customers see as the value add or the unique features of OnGuard and IdentityDefender, I can start by stating that OnGuard has a lot of these connectors built into it. For example, the user accounts, the people that actually log into the application. Not only can you have an internal user name and password that's stored in our system, but you can link it to a directory account. So it automatically will link up to an [Lightweight Directory Access Protocol-based directory] LDAP and allow for that user to single sign-on into the application from their NT authenticated account they have for their network.
That's important because a lot of times IT wants to instill policies around passwords and retention of passwords and those types of things. Why not leverage that technology and also make it a little more integrated so that the physical access control system is tied to the IT policies and procedures on passwords.
From our perspective, that made logical sense. So we've had that for several years, and it's out of the box, the product does that. It's not a feature that requires a license or special cost associated with it. That's something we can provide the customer, a true value add, and it helps to secure the system, so why not make that available to everyone?
So that's the user side....The other side of the Lenel system is the user of the cards within the building, the physical access control itself. Within our system, we call those "cardholders." So there is a separation: "users" are those logging in and doing activities in the software--and "cardholders" are those employees, visitors, others, that are walking through the building interacting with the doors. So we also extend an option to link cardholders to directory accounts.
It's a little more complicated because what happens in a LDAP account, there are many different fields available and the structure you set up is customizable. On the cardholder side are those people who are badge cardholders in our system. We allow the customer the flexibility to create new fields and associate or customize that to meet their needs. Maybe they want to keep demographic information or vehicle information or project information specific to an individual cardholder. So we allow them to customize that interface.
So there are two pieces that are customizable: the directory, and also the OnGuard cardholders. So to match them together--it's very challenging to just do a generic map. A customer might have an employee ID number and they want to put that in a unique field in the directory. Then they want to create a custom field on the cardholder side that will be this employee ID number. How do you map those together?
So we offer a service, there's an integration, that will synchronize the cardholders of the OnGuard system with the directory account users. That's more our large enterprise customers. For the SME market, it doesn't play in that much. If your population is less than a thousand people, it's probably just as easy to create individual accounts within the PACS system and keep them separate.
When you get above a thousand-person population and if you're dealing with high turnover, or enterprise organizations across multiple facilities, now that is much more challenging to manage. So it's those customers that have adopted this interface we offer so that if somebody is added to the directory...it will automatically create a cardholder in our system, all the information is there that the network or the directory had except for the photographic or maybe some other information about what doors they're allowed to have access to.
Then, either based on what we consider to be site managers or local managers, department managers, they define what access [the person] should have and can automatically assign that to the badge.
The last piece is the photograph. Typically, the HR system or where you have e-directories and such--if the directory or NT system does not have the photograph of the person, then they'd go to the access control system, add a photograph, print the badge, and now the badge is linked to the directory account that they have--so that if something happens on either side, they can update the information.
Within our enterprise customers, we are seeing a large adoption of that.
The last point on this would be as we have seen a trend toward standardizing on credentials, both within the government sector and also with large enterprise organizations, saying it's no longer just good enough to have a proximity badge. As we start looking at tying it into logical access, trusting who that person is and that the badge is authentic is critical. So one of the other things we have seen is organizations wanting to put checks and balances on how they actually provide the badges, how do they secure them before they go to employees and how do we make sure this employee should have this badge and what is the status of this badge?
That's where the IdentityDefender comes in. It's really an add-on module to the OnGuard system. It has a workflow element that says you'll go through these checks and balances before a badge is given. I can't just walk up to a badge operator and say, I'm a new employee, here's my information. Print me out a badge. The IdentityDefender workflow is really to say I need to validate who you are, so I might grab some information, like the biometrics of the person. I could create a file that would be submitted to a background or credit or investigative check before I say this person is going be issued a badge.
Once all those checks have been done--and they may be internal to the organization or external against other systems--then the badge operators receive a response indicating this person is able to receive a badge, that all the checks have been completed and because we've had the biometrics from before, we validate the biometrics once again to make sure we're giving the right badge to the right individual.
That adoption of IdentityDefender has been a little bit slower because a lot of these types of checks, both to credit checks or investigative, are either in silos amongst themselves or in highly secure government facilities, and they really haven't opened it up for the enterprises. Some HR departments will do it. They'll submit a paper copy for a credit check on somebody and get a response, but those systems in general are kind of seen as separate silos and it's hard to connect them together....
In terms of market adoption, are customers ready for that? That's not the widespread adoption. The widespread adoption is OnGuard and having cardholders of OnGuard integrated with the directory account so that if someone is added to the directory, they're automatically added to OnGuard, and it allows for the large enterprise organization to manage their employee population for both logical access and physical access.
SJW: I'd like to talk about that process you went through between OnGuard and the employee directory...You'd said it's up to the local managers, business end users, to define the access rights associated with the badge. Is that something they do ahead of time so those badge rules are built into OnGuard and automatically assigned to a badge? Or is done later?
EL: It can be both. We have customers that do it either way. When the identity is provisioned within the logical directory and it passes the information through the LDAP interface into OnGuard cardholder, we define the badge type and that badge type would have default access rights that are assigned to it.
From a user perspective, it's seamless. I go to HR, they create the account for me or it gets automatically provisioned into the directory, we are then looking in real time at the directory, getting the information back and the badge is then created.
That's how we address the standard access rights. If you're a new employee of Lenel, you're going to have access to common areas, to standard conference rooms, break rooms, those types of things. But if you're going to be working on a specific project for a site manager or department, that department might say, for this specific [instance], we want to provide you additional access. They'd provide that after the fact then.
There are some things going on right now in regards to linking your role within...the directory account, and how to pass that over to the access levels within the physical access control so that you're automatically given those access rights based on the role you're going to be doing. That is something that through that LDAP interface is possible.
But I will say the trend right now with physical security is not to get to that level of detail. What ends up happening is the local site manager or department manager wants to retain a little bit more control than just providing IT the authority to let people into their space. But it is possible and the interface is designed so that it allows for it.
SJW: So some of those business end users are not all that comfortable with having that many privileges automated.
EL: Especially when you get into project-specific privileges.
This is kind of off-topic but if you really want to see about pushing the envelope on the concept of physical access control integrated with the rest of the organization, there's something we're developing right now. [We] have launched a green initiative with a sister company of UTC called ALC, they're underneath Carrier, and also with Cisco and Cisco phone systems. They have a proof of concept they've been running and pulling analysis from of the PACS tied to the IP telephony network system tied to the building automation energy management system of a facility.
So if I'm...a remote employee, I'm going to come in for a day, the concept here is I go to a kiosk, request an office space at a particular time and only at the point in time does it activate and energize those items I'd have within that space.
So my IP phone is transferred to that remote desk, my printers would automatically transfer to local printers, the system would know based on my physical access control profile that have been defined that my preference is to have a room sustained at 72 degrees and I prefer ambient light over direct sunlight, and it would automatically adjust shades and lights [and] the temperature of the room so it's sustained for that period of time.
It's taking it all to the next level. Take conference rooms...setting it up through our visitor management, you define how many visitors you'll have, you reserve the space. Automatically when that session starts, the lights are at the right level; when it's done, it automatically turns things off. Then, through some of the work we do through our intelligent video analytics, we can also monitor the room for the occupancy and if the room is not being occupied, the PACS notifies the building automation system to bring back those resources like the light and shades, and everything else.
That's really what we are trying to do. The integration to the directory, the logical--we see the value to the customer is it allows them to have a better understanding of who has rights to their network and to their physical facilities. It allows the administration of access rights and managing of people's responsibilities within the organization more efficiently, and the third thing is it reduces the cost of going ahead and deploying that type of solution and going through that process. Any time you can leverage sharing of information and having the systems communicate with one another just improves the efficiencies over all.
SJW: If you have a client who wants this kind of integration between their directories and PACS and other systems but they aren't willing to standardize on Lenel, how can you help with that?
EL: What we try to do is provide standard tools, interfaces that allow an organization to leverage both their existing and the new technologies. [The core of] Lenel OnGuard is a physical access control system. So if we look at the LDAP or the network infrastructure as being the backbone for the identity provisioning, then there's no reason why we wouldn't be able to share that same information with another third party PACS--as long as they have that capability.
And that's the thing that's outside of our control. We try to leverage the fact we want to create these hooks for the user accounts into the LDAP, for the cardholders into the LDAP, for the access levels to be provisioned...but if another PACS is not at that same level of integration and they don't have the ability to provide that to the directory, it's going to make it very hard for the customer to leverage that existing system. We can only take it so far.
That is the success of companies like Quantum Secure [a Lenel OEP partner]. What they are trying to do, leveraging integration into PACS, is that they become that buffer that would then take third party system A, third party system B and the Lenel OnGuard system and tie them together and then handle the provisioning and the administration of access rights.
Now I know there are some shortfalls with that also because when we look at enterprise architecture and the strength of our solution and how we administer not only the standard stuff of where you have access and when but get into cardholder and custom fields and the unique attributes you assign to the "users" of the system and the "cardholders," it's hard to create a generic application or platform that's going to be able to handle that from all these different systems. So the same challenges we've run into on creating this interface to the LDAP are the same challenges that another company would run into trying to create a standard interface between independent PACS.
So if you do have to replace--and I'm not saying that's the optimal solution--but if you do wind up having to replace, there's a lot of existing infrastructure you can leverage if you're going from one system to another. You have to look at two costs. One cost is the administration of the system. So if PACS systems A, B, C, and D have different back-up policies and different training and upgrades, there's a substantial cost associated with maintaining those separate databases, systems, and updates. So consolidating to one system does save the end user cost over time because now they have one system they're managing for the entire physical access control.
The other cost they can save if they decide to convert over and merge to one common platform for PACS is a lot of the cost associated with the readers and the electro-mechanical hardware that goes into the doors; the wiring infrastructure that's used to communicate to these different devices; the servers, the platforms used for hosting these systems. Typically when talking with our VARs, we normally hear a price per door of anywhere from $2500 to $4000 to secure it. If you look at that cost and what's associated with it, the actual replacement cost of what we consider the controller board, or the board that goes into the closet, and then the software, that is less than 20% of that total cost.
So in the grand scheme of things, is it still a big price tag? Yeah. If I'm an enterprise and have a thousand readers deployed, it's going to cost me several hundred thousand dollars to replace the system and go to a common platform. But in the grand scheme of what have I invested over the long run for this entire system, I've invested millions of dollars and I'm able to retain a lot of [that investment] during that conversion and...and I have the savings of having one platform to manage and update going forward
SJW: Do you forsee a time, Erik, when maybe one way to handle the standardization would be as more of these devices become more intelligent, more IP-based, they could bypass a PACS, and the logical identity system could handle more of these resources, could provision the physical access?
EL: I hope not! The big item I see is there would have to be a merging of the minds of what is physical access control and what is logical access control. There are several elements of physical access control that are not covered by logical, and there are several elements of logical access control that are not covered by physical access.
Having network switches and routers that have physical access control integrated on them and having IP at the edge or on the reader--it's trying to push the IP infrastructure all the way down.
We have customers that try to go that way--the OnGuard platform will work with the Lenel hardware; it will also work with the HID Edge hardware. If you have an HID Edge IP reader, you can attach it to our system, and you don't go through our access control infrastructure. You're not using our cabling, you're not using the Lenel reader interface modules and controllers and logic we've built into our infrastructure. You're just using the server software to provision rights down to those readers. We support that today. And there are customers that want to go that way.
The concerns we've also heard from customers is that by having IP Ethernet capabilities on the outside of the reader, how secure is that? What do we need to look at within our infrastructure to make sure it is secure? Because you can secure it, though VPNs and separate subnets. You can do that, but there is a cost associated with it. So is there a benefit of doing that?
....What are the other things used for physical access control? You have video, you have storage of video, you have analytics, you have fire and intrusion, you have asset management, anti-passback, who has access and when shouldn't they have access--all of that would have to be built into either a directory structure or some sort of logical access system.
Within the physical access control, with heightened security, there's the whole concept of mustering--in the event of catastrophe, having people leave an area and report somewhere else and provide real time reports. There are redundancies built into physical access control infrastructure to support that--redundant, alternate types of communications.
Is the customer's IP infrastructure ready to support that? Some are, some aren't. There are a lot of hidden things that on the surface you can say, yes, a logical access control system could provide a credential that could be used for physical access control, they could control the doors, end of story. But when you dig into the details of it, both from the IT infrastructure and then for the actual use cases for what the customer is trying to do with the securing of their people and facilities, it gets a lot deeper and a lot more complicated.
SJW: Earlier you'd talked about how authenticating people was becoming more important and that's part of what IdentityDefender does with its workflow tools. Can you talk about the impact of that need on the physical tools used to authenticate identity?
EL: It's definitely becoming more important. Within the industry, there's a lot of discussion around multifactor authentication. It's not just what you have, but who you are and what you know. A lot of that can be combination of biometric, PIN, card and also taking it to the next level, so it's not only the card, but how do we validate the card is real and should be trusted.
Biometrics plays a big role. We have seen a trend, an increase in the use of biometrics, fingerprint, vein, hand geometry, retinal. We've seen some concept work on the facial detection and granting access there. I don't think it's as widespread as what I would consider the more fundamental, core biometrics technologies.
We're also seeing a trend, especially in the last year, to provide some sort of authentication of a credential [by] talking to some third party system....So the PACS is not just looking at, I have this badge and have this access level and time, but [going] to a third party system and validating/authenticating who they are and what they have in their possession, this credential, and determining if it should grant them access from that.
SJW: Is that typical of folks outside the government with high security needs?
EL: We're not seeing the adoption in the SME market, it's not there yet, it's too expensive. In the large enterprise, if you're looking at IT financial type of companies, those vertical markets, the adoption isn't toward the authentication but wanting a common credential that will work between the logical space and the physical access. But if you're a large organization working closely with entities of either the ports or government agencies doing secure work, then they're looking at these types of credentials and looking at authenticating the credential and the person for physical access control.
SJW: To clarify for me, we opened talking about OnGuard "users" and "cardholders." Within OnGuard, are these users and cardholders linked through the directory interface to create one credential for one identity?
EL: The answer is yes and no. It can be configured both ways. If customers have embraced the concept of using a credential for logical access, say the Imprivata OneSign solution [Editor's note: Imprivata
A Leading Physical Access Control Vendor Gets Logical
When discussing the creation of a single enterprise identity represented by one credential good in both the physical and logical space, physical access control systems (PACS) can easily be seen as barriers to that goal. To find out more about how PACS may fit into a converged identity world, Security Squared spoke last month with Erik Larsen (pictured), director of product management for Lenel Systems, as background for our "One Person, One Identity, One Credential" article.
Larsen discussed Lenel's specific approach to logical integration, as well as customer and industry trends re: merging physical and logical identities. What follows is an abridged transcript of our conversation, edited for clarity and length.
***********
Sharon J. Watson: In researching this converged identity management story, about tying physical access into logical access systems, I'm thinking I don't have enough perspective on what physical access control systems (PACS) bring to this arena. So I'm hoping we can talk through that today.
Erik Larsen: It doesn't surprise me you're missing that perspective. In the past, [physical access control] has come from hardware manufacturers. The focus is securing perimeters and dealing with physical security facilities, those areas of an organization. It gets very narrow in focus: Let's create a silo, we want to protect the silo, let's make sure it can't be infiltrated from anywhere else, and therefore it gets into a mindset of okay, the only way to secure it is by not opening it up.
As an industry, we've kind of tried to push outside of that. I think Lenel is at the forefront of that. Because if you look at Lenel as a company, we came at it not only from a software perspective--let's design software and find hardware that works with our software--but also, let's become a security platform that can leverage an organization and the processes an organization has put in place to secure its people, its intellectual property and also the facility itself.
So in regards to our products and how we approach this and what our customers see as the value add or the unique features of OnGuard and IdentityDefender, I can start by stating that OnGuard has a lot of these connectors built into it. For example, the user accounts, the people that actually log into the application. Not only can you have an internal user name and password that's stored in our system, but you can link it to a directory account. So it automatically will link up to an [Lightweight Directory Access Protocol-based directory] LDAP and allow for that user to single sign-on into the application from their NT authenticated account they have for their network.
That's important because a lot of times IT wants to instill policies around passwords and retention of passwords and those types of things. Why not leverage that technology and also make it a little more integrated so that the physical access control system is tied to the IT policies and procedures on passwords.
From our perspective, that made logical sense. So we've had that for several years, and it's out of the box, the product does that. It's not a feature that requires a license or special cost associated with it. That's something we can provide the customer, a true value add, and it helps to secure the system, so why not make that available to everyone?
So that's the user side....The other side of the Lenel system is the user of the cards within the building, the physical access control itself. Within our system, we call those "cardholders." So there is a separation: "users" are those logging in and doing activities in the software--and "cardholders" are those employees, visitors, others, that are walking through the building interacting with the doors. So we also extend an option to link cardholders to directory accounts.
It's a little more complicated because what happens in a LDAP account, there are many different fields available and the structure you set up is customizable. On the cardholder side are those people who are badge cardholders in our system. We allow the customer the flexibility to create new fields and associate or customize that to meet their needs. Maybe they want to keep demographic information or vehicle information or project information specific to an individual cardholder. So we allow them to customize that interface.
So there are two pieces that are customizable: the directory, and also the OnGuard cardholders. So to match them together--it's very challenging to just do a generic map. A customer might have an employee ID number and they want to put that in a unique field in the directory. Then they want to create a custom field on the cardholder side that will be this employee ID number. How do you map those together?
So we offer a service, there's an integration, that will synchronize the cardholders of the OnGuard system with the directory account users. That's more our large enterprise customers. For the SME market, it doesn't play in that much. If your population is less than a thousand people, it's probably just as easy to create individual accounts within the PACS system and keep them separate.
When you get above a thousand-person population and if you're dealing with high turnover, or enterprise organizations across multiple facilities, now that is much more challenging to manage. So it's those customers that have adopted this interface we offer so that if somebody is added to the directory...it will automatically create a cardholder in our system, all the information is there that the network or the directory had except for the photographic or maybe some other information about what doors they're allowed to have access to.
Then, either based on what we consider to be site managers or local managers, department managers, they define what access [the person] should have and can automatically assign that to the badge.
The last piece is the photograph. Typically, the HR system or where you have e-directories and such--if the directory or NT system does not have the photograph of the person, then they'd go to the access control system, add a photograph, print the badge, and now the badge is linked to the directory account that they have--so that if something happens on either side, they can update the information.
Within our enterprise customers, we are seeing a large adoption of that.
The last point on this would be as we have seen a trend toward standardizing on credentials, both within the government sector and also with large enterprise organizations, saying it's no longer just good enough to have a proximity badge. As we start looking at tying it into logical access, trusting who that person is and that the badge is authentic is critical. So one of the other things we have seen is organizations wanting to put checks and balances on how they actually provide the badges, how do they secure them before they go to employees and how do we make sure this employee should have this badge and what is the status of this badge?
That's where the IdentityDefender comes in. It's really an add-on module to the OnGuard system. It has a workflow element that says you'll go through these checks and balances before a badge is given. I can't just walk up to a badge operator and say, I'm a new employee, here's my information. Print me out a badge. The IdentityDefender workflow is really to say I need to validate who you are, so I might grab some information, like the biometrics of the person. I could create a file that would be submitted to a background or credit or investigative check before I say this person is going be issued a badge.
Once all those checks have been done--and they may be internal to the organization or external against other systems--then the badge operators receive a response indicating this person is able to receive a badge, that all the checks have been completed and because we've had the biometrics from before, we validate the biometrics once again to make sure we're giving the right badge to the right individual.
That adoption of IdentityDefender has been a little bit slower because a lot of these types of checks, both to credit checks or investigative, are either in silos amongst themselves or in highly secure government facilities, and they really haven't opened it up for the enterprises. Some HR departments will do it. They'll submit a paper copy for a credit check on somebody and get a response, but those systems in general are kind of seen as separate silos and it's hard to connect them together....
In terms of market adoption, are customers ready for that? That's not the widespread adoption. The widespread adoption is OnGuard and having cardholders of OnGuard integrated with the directory account so that if someone is added to the directory, they're automatically added to OnGuard, and it allows for the large enterprise organization to manage their employee population for both logical access and physical access.
SJW: I'd like to talk about that process you went through between OnGuard and the employee directory...You'd said it's up to the local managers, business end users, to define the access rights associated with the badge. Is that something they do ahead of time so those badge rules are built into OnGuard and automatically assigned to a badge? Or is done later?
EL: It can be both. We have customers that do it either way. When the identity is provisioned within the logical directory and it passes the information through the LDAP interface into OnGuard cardholder, we define the badge type and that badge type would have default access rights that are assigned to it.
From a user perspective, it's seamless. I go to HR, they create the account for me or it gets automatically provisioned into the directory, we are then looking in real time at the directory, getting the information back and the badge is then created.
That's how we address the standard access rights. If you're a new employee of Lenel, you're going to have access to common areas, to standard conference rooms, break rooms, those types of things. But if you're going to be working on a specific project for a site manager or department, that department might say, for this specific [instance], we want to provide you additional access. They'd provide that after the fact then.
There are some things going on right now in regards to linking your role within...the directory account, and how to pass that over to the access levels within the physical access control so that you're automatically given those access rights based on the role you're going to be doing. That is something that through that LDAP interface is possible.
But I will say the trend right now with physical security is not to get to that level of detail. What ends up happening is the local site manager or department manager wants to retain a little bit more control than just providing IT the authority to let people into their space. But it is possible and the interface is designed so that it allows for it.
SJW: So some of those business end users are not all that comfortable with having that many privileges automated.
EL: Especially when you get into project-specific privileges.
This is kind of off-topic but if you really want to see about pushing the envelope on the concept of physical access control integrated with the rest of the organization, there's something we're developing right now. [We] have launched a green initiative with a sister company of UTC called ALC, they're underneath Carrier, and also with Cisco and Cisco phone systems. They have a proof of concept they've been running and pulling analysis from of the PACS tied to the IP telephony network system tied to the building automation energy management system of a facility.
So if I'm...a remote employee, I'm going to come in for a day, the concept here is I go to a kiosk, request an office space at a particular time and only at the point in time does it activate and energize those items I'd have within that space.
So my IP phone is transferred to that remote desk, my printers would automatically transfer to local printers, the system would know based on my physical access control profile that have been defined that my preference is to have a room sustained at 72 degrees and I prefer ambient light over direct sunlight, and it would automatically adjust shades and lights [and] the temperature of the room so it's sustained for that period of time.
It's taking it all to the next level. Take conference rooms...setting it up through our visitor management, you define how many visitors you'll have, you reserve the space. Automatically when that session starts, the lights are at the right level; when it's done, it automatically turns things off. Then, through some of the work we do through our intelligent video analytics, we can also monitor the room for the occupancy and if the room is not being occupied, the PACS notifies the building automation system to bring back those resources like the light and shades, and everything else.
That's really what we are trying to do. The integration to the directory, the logical--we see the value to the customer is it allows them to have a better understanding of who has rights to their network and to their physical facilities. It allows the administration of access rights and managing of people's responsibilities within the organization more efficiently, and the third thing is it reduces the cost of going ahead and deploying that type of solution and going through that process. Any time you can leverage sharing of information and having the systems communicate with one another just improves the efficiencies over all.
SJW: If you have a client who wants this kind of integration between their directories and PACS and other systems but they aren't willing to standardize on Lenel, how can you help with that?
EL: What we try to do is provide standard tools, interfaces that allow an organization to leverage both their existing and the new technologies. [The core of] Lenel OnGuard is a physical access control system. So if we look at the LDAP or the network infrastructure as being the backbone for the identity provisioning, then there's no reason why we wouldn't be able to share that same information with another third party PACS--as long as they have that capability.
And that's the thing that's outside of our control. We try to leverage the fact we want to create these hooks for the user accounts into the LDAP, for the cardholders into the LDAP, for the access levels to be provisioned...but if another PACS is not at that same level of integration and they don't have the ability to provide that to the directory, it's going to make it very hard for the customer to leverage that existing system. We can only take it so far.
That is the success of companies like Quantum Secure [a Lenel OEP partner]. What they are trying to do, leveraging integration into PACS, is that they become that buffer that would then take third party system A, third party system B and the Lenel OnGuard system and tie them together and then handle the provisioning and the administration of access rights.
Now I know there are some shortfalls with that also because when we look at enterprise architecture and the strength of our solution and how we administer not only the standard stuff of where you have access and when but get into cardholder and custom fields and the unique attributes you assign to the "users" of the system and the "cardholders," it's hard to create a generic application or platform that's going to be able to handle that from all these different systems. So the same challenges we've run into on creating this interface to the LDAP are the same challenges that another company would run into trying to create a standard interface between independent PACS.
So if you do have to replace--and I'm not saying that's the optimal solution--but if you do wind up having to replace, there's a lot of existing infrastructure you can leverage if you're going from one system to another. You have to look at two costs. One cost is the administration of the system. So if PACS systems A, B, C, and D have different back-up policies and different training and upgrades, there's a substantial cost associated with maintaining those separate databases, systems, and updates. So consolidating to one system does save the end user cost over time because now they have one system they're managing for the entire physical access control.
The other cost they can save if they decide to convert over and merge to one common platform for PACS is a lot of the cost associated with the readers and the electro-mechanical hardware that goes into the doors; the wiring infrastructure that's used to communicate to these different devices; the servers, the platforms used for hosting these systems. Typically when talking with our VARs, we normally hear a price per door of anywhere from $2500 to $4000 to secure it. If you look at that cost and what's associated with it, the actual replacement cost of what we consider the controller board, or the board that goes into the closet, and then the software, that is less than 20% of that total cost.
So in the grand scheme of things, is it still a big price tag? Yeah. If I'm an enterprise and have a thousand readers deployed, it's going to cost me several hundred thousand dollars to replace the system and go to a common platform. But in the grand scheme of what have I invested over the long run for this entire system, I've invested millions of dollars and I'm able to retain a lot of [that investment] during that conversion and...and I have the savings of having one platform to manage and update going forward
SJW: Do you forsee a time, Erik, when maybe one way to handle the standardization would be as more of these devices become more intelligent, more IP-based, they could bypass a PACS, and the logical identity system could handle more of these resources, could provision the physical access?
EL: I hope not! The big item I see is there would have to be a merging of the minds of what is physical access control and what is logical access control. There are several elements of physical access control that are not covered by logical, and there are several elements of logical access control that are not covered by physical access.
Having network switches and routers that have physical access control integrated on them and having IP at the edge or on the reader--it's trying to push the IP infrastructure all the way down.
We have customers that try to go that way--the OnGuard platform will work with the Lenel hardware; it will also work with the HID Edge hardware. If you have an HID Edge IP reader, you can attach it to our system, and you don't go through our access control infrastructure. You're not using our cabling, you're not using the Lenel reader interface modules and controllers and logic we've built into our infrastructure. You're just using the server software to provision rights down to those readers. We support that today. And there are customers that want to go that way.
The concerns we've also heard from customers is that by having IP Ethernet capabilities on the outside of the reader, how secure is that? What do we need to look at within our infrastructure to make sure it is secure? Because you can secure it, though VPNs and separate subnets. You can do that, but there is a cost associated with it. So is there a benefit of doing that?
....What are the other things used for physical access control? You have video, you have storage of video, you have analytics, you have fire and intrusion, you have asset management, anti-passback, who has access and when shouldn't they have access--all of that would have to be built into either a directory structure or some sort of logical access system.
Within the physical access control, with heightened security, there's the whole concept of mustering--in the event of catastrophe, having people leave an area and report somewhere else and provide real time reports. There are redundancies built into physical access control infrastructure to support that--redundant, alternate types of communications.
Is the customer's IP infrastructure ready to support that? Some are, some aren't. There are a lot of hidden things that on the surface you can say, yes, a logical access control system could provide a credential that could be used for physical access control, they could control the doors, end of story. But when you dig into the details of it, both from the IT infrastructure and then for the actual use cases for what the customer is trying to do with the securing of their people and facilities, it gets a lot deeper and a lot more complicated.
SJW: Earlier you'd talked about how authenticating people was becoming more important and that's part of what IdentityDefender does with its workflow tools. Can you talk about the impact of that need on the physical tools used to authenticate identity?
EL: It's definitely becoming more important. Within the industry, there's a lot of discussion around multifactor authentication. It's not just what you have, but who you are and what you know. A lot of that can be combination of biometric, PIN, card and also taking it to the next level, so it's not only the card, but how do we validate the card is real and should be trusted.
Biometrics plays a big role. We have seen a trend, an increase in the use of biometrics, fingerprint, vein, hand geometry, retinal. We've seen some concept work on the facial detection and granting access there. I don't think it's as widespread as what I would consider the more fundamental, core biometrics technologies.
We're also seeing a trend, especially in the last year, to provide some sort of authentication of a credential [by] talking to some third party system....So the PACS is not just looking at, I have this badge and have this access level and time, but [going] to a third party system and validating/authenticating who they are and what they have in their possession, this credential, and determining if it should grant them access from that.
SJW: Is that typical of folks outside the government with high security needs?
EL: We're not seeing the adoption in the SME market, it's not there yet, it's too expensive. In the large enterprise, if you're looking at IT financial type of companies, those vertical markets, the adoption isn't toward the authentication but wanting a common credential that will work between the logical space and the physical access. But if you're a large organization working closely with entities of either the ports or government agencies doing secure work, then they're looking at these types of credentials and looking at authenticating the credential and the person for physical access control.
SJW: To clarify for me, we opened talking about OnGuard "users" and "cardholders." Within OnGuard, are these users and cardholders linked through the directory interface to create one credential for one identity?
EL: The answer is yes and no. It can be configured both ways. If customers have embraced the concept of using a credential for logical access, say the Imprivata OneSign solution [Editor's note: Imprivata
When discussing the creation of a single enterprise identity represented by one credential good in both the physical and logical space, physical access control systems (PACS) can easily be seen as barriers to that goal. To find out more about how PACS may fit into a converged identity world, Security Squared spoke last month with Erik Larsen (pictured),
director of product management for Lenel Systems, as background for our "One Person, One Identity, One Credential" article. Larsen discussed Lenel's specific approach to logical integration, as well as customer and industry trends re: merging physical and logical identities. What follows is an abridged transcript of our conversation, edited for clarity and length.
***********
Sharon J. Watson: In researching this converged identity management story, about tying physical access into logical access systems, I'm thinking I don't have enough perspective on what physical access control systems (PACS) bring to this arena. So I'm hoping we can talk through that today.
Erik Larsen: It doesn't surprise me you're missing that perspective. In the past, [physical access control] has come from hardware manufacturers. The focus is securing perimeters and dealing with physical security facilities, those areas of an organization. It gets very narrow in focus: Let's create a silo, we want to protect the silo, let's make sure it can't be infiltrated from anywhere else, and therefore it gets into a mindset of okay, the only way to secure it is by not opening it up.
As an industry, we've kind of tried to push outside of that. I think Lenel is at the forefront of that. Because if you look at Lenel as a company, we came at it not only from a software perspective--let's design software and find hardware that works with our software--but also, let's become a security platform that can leverage an organization and the processes an organization has put in place to secure its people, its intellectual property and also the facility itself.
So in regards to our products and how we approach this and what our customers see as the value add or the unique features of OnGuard and IdentityDefender, I can start by stating that OnGuard has a lot of these connectors built into it. For example, the user accounts, the people that actually log into the application. Not only can you have an internal user name and password that's stored in our system, but you can link it to a directory account. So it automatically will link up to an [Lightweight Directory Access Protocol-based directory] LDAP and allow for that user to single sign-on into the application from their NT authenticated account they have for their network.
That's important because a lot of times IT wants to instill policies around passwords and retention of passwords and those types of things. Why not leverage that technology and also make it a little more integrated so that the physical access control system is tied to the IT policies and procedures on passwords.
From our perspective, that made logical sense. So we've had that for several years, and it's out of the box, the product does that. It's not a feature that requires a license or special cost associated with it. That's something we can provide the customer, a true value add, and it helps to secure the system, so why not make that available to everyone?
So that's the user side....The other side of the Lenel system is the user of the cards within the building, the physical access control itself. Within our system, we call those "cardholders." So there is a separation: "users" are those logging in and doing activities in the software--and "cardholders" are those employees, visitors, others, that are walking through the building interacting with the doors. So we also extend an option to link cardholders to directory accounts.
It's a little more complicated because what happens in a LDAP account, there are many different fields available and the structure you set up is customizable. On the cardholder side are those people who are badge cardholders in our system. We allow the customer the flexibility to create new fields and associate or customize that to meet their needs. Maybe they want to keep demographic information or vehicle information or project information specific to an individual cardholder. So we allow them to customize that interface.
So there are two pieces that are customizable: the directory, and also the OnGuard cardholders. So to match them together--it's very challenging to just do a generic map. A customer might have an employee ID number and they want to put that in a unique field in the directory. Then they want to create a custom field on the cardholder side that will be this employee ID number. How do you map those together?
So we offer a service, there's an integration, that will synchronize the cardholders of the OnGuard system with the directory account users. That's more our large enterprise customers. For the SME market, it doesn't play in that much. If your population is less than a thousand people, it's probably just as easy to create individual accounts within the PACS system and keep them separate.
When you get above a thousand-person population and if you're dealing with high turnover, or enterprise organizations across multiple facilities, now that is much more challenging to manage. So it's those customers that have adopted this interface we offer so that if somebody is added to the directory...it will automatically create a cardholder in our system, all the information is there that the network or the directory had except for the photographic or maybe some other information about what doors they're allowed to have access to.
Then, either based on what we consider to be site managers or local managers, department managers, they define what access [the person] should have and can automatically assign that to the badge.
The last piece is the photograph. Typically, the HR system or where you have e-directories and such--if the directory or NT system does not have the photograph of the person, then they'd go to the access control system, add a photograph, print the badge, and now the badge is linked to the directory account that they have--so that if something happens on either side, they can update the information.
Within our enterprise customers, we are seeing a large adoption of that.
The last point on this would be as we have seen a trend toward standardizing on credentials, both within the government sector and also with large enterprise organizations, saying it's no longer just good enough to have a proximity badge. As we start looking at tying it into logical access, trusting who that person is and that the badge is authentic is critical. So one of the other things we have seen is organizations wanting to put checks and balances on how they actually provide the badges, how do they secure them before they go to employees and how do we make sure this employee should have this badge and what is the status of this badge?
That's where the IdentityDefender comes in. It's really an add-on module to the OnGuard system. It has a workflow element that says you'll go through these checks and balances before a badge is given. I can't just walk up to a badge operator and say, I'm a new employee, here's my information. Print me out a badge. The IdentityDefender workflow is really to say I need to validate who you are, so I might grab some information, like the biometrics of the person. I could create a file that would be submitted to a background or credit or investigative check before I say this person is going be issued a badge.
Once all those checks have been done--and they may be internal to the organization or external against other systems--then the badge operators receive a response indicating this person is able to receive a badge, that all the checks have been completed and because we've had the biometrics from before, we validate the biometrics once again to make sure we're giving the right badge to the right individual.
That adoption of IdentityDefender has been a little bit slower because a lot of these types of checks, both to credit checks or investigative, are either in silos amongst themselves or in highly secure government facilities, and they really haven't opened it up for the enterprises. Some HR departments will do it. They'll submit a paper copy for a credit check on somebody and get a response, but those systems in general are kind of seen as separate silos and it's hard to connect them together....
In terms of market adoption, are customers ready for that? That's not the widespread adoption. The widespread adoption is OnGuard and having cardholders of OnGuard integrated with the directory account so that if someone is added to the directory, they're automatically added to OnGuard, and it allows for the large enterprise organization to manage their employee population for both logical access and physical access.
SJW: I'd like to talk about that process you went through between OnGuard and the employee directory...You'd said it's up to the local managers, business end users, to define the access rights associated with the badge. Is that something they do ahead of time so those badge rules are built into OnGuard and automatically assigned to a badge? Or is done later?
EL: It can be both. We have customers that do it either way. When the identity is provisioned within the logical directory and it passes the information through the LDAP interface into OnGuard cardholder, we define the badge type and that badge type would have default access rights that are assigned to it.
From a user perspective, it's seamless. I go to HR, they create the account for me or it gets automatically provisioned into the directory, we are then looking in real time at the directory, getting the information back and the badge is then created.
That's how we address the standard access rights. If you're a new employee of Lenel, you're going to have access to common areas, to standard conference rooms, break rooms, those types of things. But if you're going to be working on a specific project for a site manager or department, that department might say, for this specific [instance], we want to provide you additional access. They'd provide that after the fact then.
There are some things going on right now in regards to linking your role within...the directory account, and how to pass that over to the access levels within the physical access control so that you're automatically given those access rights based on the role you're going to be doing. That is something that through that LDAP interface is possible.
But I will say the trend right now with physical security is not to get to that level of detail. What ends up happening is the local site manager or department manager wants to retain a little bit more control than just providing IT the authority to let people into their space. But it is possible and the interface is designed so that it allows for it.
SJW: So some of those business end users are not all that comfortable with having that many privileges automated.
EL: Especially when you get into project-specific privileges.
This is kind of off-topic but if you really want to see about pushing the envelope on the concept of physical access control integrated with the rest of the organization, there's something we're developing right now. [We] have launched a green initiative with a sister company of UTC called ALC, they're underneath Carrier, and also with Cisco and Cisco phone systems. They have a proof of concept they've been running and pulling analysis from of the PACS tied to the IP telephony network system tied to the building automation energy management system of a facility.
So if I'm...a remote employee, I'm going to come in for a day, the concept here is I go to a kiosk, request an office space at a particular time and only at the point in time does it activate and energize those items I'd have within that space.
So my IP phone is transferred to that remote desk, my printers would automatically transfer to local printers, the system would know based on my physical access control profile that have been defined that my preference is to have a room sustained at 72 degrees and I prefer ambient light over direct sunlight, and it would automatically adjust shades and lights [and] the temperature of the room so it's sustained for that period of time.
It's taking it all to the next level. Take conference rooms...setting it up through our visitor management, you define how many visitors you'll have, you reserve the space. Automatically when that session starts, the lights are at the right level; when it's done, it automatically turns things off. Then, through some of the work we do through our intelligent video analytics, we can also monitor the room for the occupancy and if the room is not being occupied, the PACS notifies the building automation system to bring back those resources like the light and shades, and everything else.
That's really what we are trying to do. The integration to the directory, the logical--we see the value to the customer is it allows them to have a better understanding of who has rights to their network and to their physical facilities. It allows the administration of access rights and managing of people's responsibilities within the organization more efficiently, and the third thing is it reduces the cost of going ahead and deploying that type of solution and going through that process. Any time you can leverage sharing of information and having the systems communicate with one another just improves the efficiencies over all.
SJW: If you have a client who wants this kind of integration between their directories and PACS and other systems but they aren't willing to standardize on Lenel, how can you help with that?
EL: What we try to do is provide standard tools, interfaces that allow an organization to leverage both their existing and the new technologies. [The core of] Lenel OnGuard is a physical access control system. So if we look at the LDAP or the network infrastructure as being the backbone for the identity provisioning, then there's no reason why we wouldn't be able to share that same information with another third party PACS--as long as they have that capability.
And that's the thing that's outside of our control. We try to leverage the fact we want to create these hooks for the user accounts into the LDAP, for the cardholders into the LDAP, for the access levels to be provisioned...but if another PACS is not at that same level of integration and they don't have the ability to provide that to the directory, it's going to make it very hard for the customer to leverage that existing system. We can only take it so far.
That is the success of companies like Quantum Secure [a Lenel OEP partner]. What they are trying to do, leveraging integration into PACS, is that they become that buffer that would then take third party system A, third party system B and the Lenel OnGuard system and tie them together and then handle the provisioning and the administration of access rights.
Now I know there are some shortfalls with that also because when we look at enterprise architecture and the strength of our solution and how we administer not only the standard stuff of where you have access and when but get into cardholder and custom fields and the unique attributes you assign to the "users" of the system and the "cardholders," it's hard to create a generic application or platform that's going to be able to handle that from all these different systems. So the same challenges we've run into on creating this interface to the LDAP are the same challenges that another company would run into trying to create a standard interface between independent PACS.
So if you do have to replace--and I'm not saying that's the optimal solution--but if you do wind up having to replace, there's a lot of existing infrastructure you can leverage if you're going from one system to another. You have to look at two costs. One cost is the administration of the system. So if PACS systems A, B, C, and D have different back-up policies and different training and upgrades, there's a substantial cost associated with maintaining those separate databases, systems, and updates. So consolidating to one system does save the end user cost over time because now they have one system they're managing for the entire physical access control.
The other cost they can save if they decide to convert over and merge to one common platform for PACS is a lot of the cost associated with the readers and the electro-mechanical hardware that goes into the doors; the wiring infrastructure that's used to communicate to these different devices; the servers, the platforms used for hosting these systems. Typically when talking with our VARs, we normally hear a price per door of anywhere from $2500 to $4000 to secure it. If you look at that cost and what's associated with it, the actual replacement cost of what we consider the controller board, or the board that goes into the closet, and then the software, that is less than 20% of that total cost.
So in the grand scheme of things, is it still a big price tag? Yeah. If I'm an enterprise and have a thousand readers deployed, it's going to cost me several hundred thousand dollars to replace the system and go to a common platform. But in the grand scheme of what have I invested over the long run for this entire system, I've invested millions of dollars and I'm able to retain a lot of [that investment] during that conversion and...and I have the savings of having one platform to manage and update going forward
SJW: Do you forsee a time, Erik, when maybe one way to handle the standardization would be as more of these devices become more intelligent, more IP-based, they could bypass a PACS, and the logical identity system could handle more of these resources, could provision the physical access?
EL: I hope not! The big item I see is there would have to be a merging of the minds of what is physical access control and what is logical access control. There are several elements of physical access control that are not covered by logical, and there are several elements of logical access control that are not covered by physical access.
Having network switches and routers that have physical access control integrated on them and having IP at the edge or on the reader--it's trying to push the IP infrastructure all the way down.
We have customers that try to go that way--the OnGuard platform will work with the Lenel hardware; it will also work with the HID Edge hardware. If you have an HID Edge IP reader, you can attach it to our system, and you don't go through our access control infrastructure. You're not using our cabling, you're not using the Lenel reader interface modules and controllers and logic we've built into our infrastructure. You're just using the server software to provision rights down to those readers. We support that today. And there are customers that want to go that way.
The concerns we've also heard from customers is that by having IP Ethernet capabilities on the outside of the reader, how secure is that? What do we need to look at within our infrastructure to make sure it is secure? Because you can secure it, though VPNs and separate subnets. You can do that, but there is a cost associated with it. So is there a benefit of doing that?
....What are the other things used for physical access control? You have video, you have storage of video, you have analytics, you have fire and intrusion, you have asset management, anti-passback, who has access and when shouldn't they have access--all of that would have to be built into either a directory structure or some sort of logical access system.
Within the physical access control, with heightened security, there's the whole concept of mustering--in the event of catastrophe, having people leave an area and report somewhere else and provide real time reports. There are redundancies built into physical access control infrastructure to support that--redundant, alternate types of communications.
Is the customer's IP infrastructure ready to support that? Some are, some aren't. There are a lot of hidden things that on the surface you can say, yes, a logical access control system could provide a credential that could be used for physical access control, they could control the doors, end of story. But when you dig into the details of it, both from the IT infrastructure and then for the actual use cases for what the customer is trying to do with the securing of their people and facilities, it gets a lot deeper and a lot more complicated.
SJW: Earlier you'd talked about how authenticating people was becoming more important and that's part of what IdentityDefender does with its workflow tools. Can you talk about the impact of that need on the physical tools used to authenticate identity?
EL: It's definitely becoming more important. Within the industry, there's a lot of discussion around multifactor authentication. It's not just what you have, but who you are and what you know. A lot of that can be combination of biometric, PIN, card and also taking it to the next level, so it's not only the card, but how do we validate the card is real and should be trusted.
Biometrics plays a big role. We have seen a trend, an increase in the use of biometrics, fingerprint, vein, hand geometry, retinal. We've seen some concept work on the facial detection and granting access there. I don't think it's as widespread as what I would consider the more fundamental, core biometrics technologies.
We're also seeing a trend, especially in the last year, to provide some sort of authentication of a credential [by] talking to some third party system....So the PACS is not just looking at, I have this badge and have this access level and time, but [going] to a third party system and validating/authenticating who they are and what they have in their possession, this credential, and determining if it should grant them access from that.
SJW: Is that typical of folks outside the government with high security needs?
EL: We're not seeing the adoption in the SME market, it's not there yet, it's too expensive. In the large enterprise, if you're looking at IT financial type of companies, those vertical markets, the adoption isn't toward the authentication but wanting a common credential that will work between the logical space and the physical access. But if you're a large organization working closely with entities of either the ports or government agencies doing secure work, then they're looking at these types of credentials and looking at authenticating the credential and the person for physical access control.
SJW: To clarify for me, we opened talking about OnGuard "users" and "cardholders." Within OnGuard, are these users and cardholders linked through the directory interface to create one credential for one identity?
EL: The answer is yes and no. It can be configured both ways. If customers have embraced the concept of using a credential for logical access, say the Imprivata OneSign solution [Editor's note: Imprivata
Bookmark this on Delicious
Subscribe to our site's news feed
