Converging Physical and Logical Identities, Hands-On

| 2 Comments | 0 TrackBacks
Systems Integrator SecureNet on Converging Identities Today

Creating a converged physical/logical identity and linking it to a single credential is possible today. That's very clear based on the experiences of Greg Thornbury, vice president, and Eric Rohleder, account manager, at Dallas-based SecureNet, Inc., a systems integrator. SecureNet first became involved with converged identities nearly a decade agosecurenet.jpg with a client trying to increase network and physical access security simultaneously--but nearly separately, until it became clear there was a way to leverage one credential to do both.

In this interview, conducted last month for our "One Person, One Identity, One Credential" feature by Sharon J. Watson, Rohleder and Thornbury discussed that implementation as well as what's driving identity convergence, how to accomplish roles-based physical access and the gulf between IT security and physical security expertise.

What follows is a transcription of our conversation, edited for clarity and length.


Sharon J. Watson: Tell me about the kinds of companies that come to you, either asking for a converged physical/logical identity management solution or to whom you recommend such solutions.

Eric Rohleder: It can be...companies realizing they don't have real control over who has access to their facilities. It could be they have quite a few locations and currently at each location they've got a standalone PACS, and they've got issues with employees...that have to get a different badge for each facility [they visit] or at the very least need to be entered into a different database to go to a facility.

They start to realize that's causing them some issues. It's real easy to get somebody into those databases. It's getting them out of all those different databases that's a real challenge....That can cause you problems on an audit.

Greg Thornbury: Although those issues are quite widespread and common given how PACS have been implemented, most of our clients find they have some sort of business driver that's making them look at this. In a lot of cases right now, it's regulatory; it may be in response to an audit like Eric mentioned. There's certainly a climate out there that tends to drive these things. It's not somebody saying, gee, this would be nice to do and getting the funds budgeted to do it on that basis. There's another driver pushing it in most cases.

ER: We're seeing activity from the energy sector [because of] the NERC CIPs. HSPD-12 has a lot of customers worried because there are rules in there saying only authorized people can physically have a badge and get to certain areas, and companies are trying to figure out how to control that. PCI compliance--if companies are taking orders via credit card, they have to control access to those physical files. One way they're doing that is on the logical side; on the other, auditors are asking, 'Where do you have that data stored? Over there in that room? Well, prove to me only the right people can get into that room.'

SJW: How often is it that folks with these challenges are also trying to control access to their logical systems with a physical credential?

GT: How often are we finding clients that want to use the same credential to gain access to the network as well as physical security? We're seeing a lot more of that. It's obviously not the mainstream way that everybody does things. The mainstream is still user name and password to get onto the network. But most companies, again, are finding a business driver, whether it's regulatory or security concerns, that are making them go to a higher level of security than what they can get with user name and password. Once they start looking at that, a lot of times they'll look at something with dual factor authentication or token authentication because that will also solve problems with remote access.

Then it becomes easy and natural for them to think, well, I'm carrying a credential of some kind, and it's pretty well known that there's technology out there to allow you to use that credential to get onto the network just the way you use user name and password today. So I think first of all, there's gotta be a driver that makes you start looking in that direction. But once you start looking that way, it's pretty well defined technology....

We're seeing more and more companies do it. As Eric mentioned, some are industry or vertical market specific. Health care has some big issues we see activity in, energy is another, the government is way down that road already. Big energy companies, oil and gas, health care, county and state government infrastructure are where we're doing a lot of work in this area.

SJW: As I 've been researching this area, it seems like to get to one physical credential to work with all the systems, all the physical access control systems (PACS) need to be connected or to have the physical credential mapped to one identity. So how do you approach that?

GT: There's probably not a simple answer to that. Typically what you'll find is there's a mix of technology out there. We'll find a client with multiple locations across the country with multiple standalone PACS, there's probably a pretty good chance they'll all be different. There's probably a better chance of that than finding out there's any kind of standardization going on.

But in a lot of cases, though the hardware and software behind each system is unique, there's probably a lot of commonality when it comes down to the card itself. The card business on the physical security side is so well dominated by HID that it's a pretty safe bet that a vast majority of those cards--unless they're really, really old systems--[are] HID cards.

So when we start doing analysis and survey work for clients, one of the first things we look at is where our commonality points will be. Our goal is to reuse as much of what's out there as possible. But typically we do run into situations in which components of those different systems have to be changed out or interfaced in order to tie these things together.

It's not so much critical that you have a single central database [for identity data]. You can lay a lot of different architecture over this, whether it's multiple servers and databases or a single server and database, but what you have to have is a common or a set of common authoritative sources and a way to communicate with these separate systems in a quick manner. You need to make changes to and from the authoritative source level and let that flow out.

In a lot of those cases, we'll look for the piece that's common, and that's often the credential. From there, it's pretty easy to look at what you can keep and what you can change.

The other side of it is it's a migration path. It doesn't happen overnight. You have time to scope out things and see how it's all going to fit. If you look at what identity management really means, there's a whole lot more to it than just defining an identity. There's roles, and business processes and rules around it, and it doesn't do any good at all for me to push changes to an identity in a database that's sitting across the United States if I still have someone over there who can walk in tomorrow and manually create a new identity and violate those business rules and processes. That's really the key to the system, being able to manage all that and be able to enforce all those policies and rules.

SJW: That authoritative source level--what typically does that turn out to be or do you have to create it?

GT: We haven't had to totally create one yet. That's the good news. In the client world we're working with, there's typically a sound and clean database and source for all the employee data. In eight out of ten times, for the employees, it's Active Directory. Everyone's using a Windows desktop environment, Active Directory manages those users. We're starting to see that as pretty standard. We have a clean, simple source to look to for employee data.

But a lot of companies are using contractors now as well. In a lot of cases, the contractors aren't managed inside of Active Directory in the same way employees are managed. Typically we'll have several authoritative sources: one for employees and a separate authoritative source for contractors. We've also got solutions that tie in visitor management systems creating visitor credentials and in that case, you've got even a third authoritative source for where the visitor data comes from.

I think we've really found only one client in our history who had a true authoritative source for every single person in their facility, whether employee or contractor. So that's really pretty rare.

SJW: Eric had mentioned earlier he'd read my interview with Dave Hansen over at CA, and Dave really thought Active Directory should not be the authoritative source. He said that put IT in control of creating identities and that to him was a problem. He thought that responsibility should be backed up to HR and its systems.

GT: We've done some deployments where we've pointed to HR systems like Peoplesoft, SAP, things like that. We typically have found, even when we're doing that, a lot of resistance on the part of the end user to allow us to really connect to that production HR system. So when we have done it, we've typically done it through some middle connection or step. A batch process at the end of the day or an instance of that database copied out there that's not running in production.

We do see a lot of Active Directory use. It's not perfect. It's got more accounts in it than you need--machine and administrator accounts. There are pretty easy ways to filter through that.

A lot of what we do as an integrator is speak to our client and do a lot of listening and find out what is the best authoritative source. In a lot of organizations, you're going to find that answer isn't going to be consistent. We're flexible. We've done it both ways. It's great to connect to HR; that's truly the originating point for a lot of that data. In other cases, it seems like HR doesn't keep up everything from an employee location standpoint the way IT does. In those cases, Active Directory may be the better source. At the end of the day, it's always the end user's decision. We try to help them and consult with them. We can look at different sources, so it doesn't really matter to us as long as it's the authoritative source.

ER: Another nice part of connecting to Active Directory, since we're talking about physical/logical convergence, is the logical access is usually tied to Active Directory. So you go to Active Directory and deactivate an identity, you know in one step you're going to get physical and logical turned off at the same time.

SJW: Where do physical access rights policies get created and how do they get linked to logical access rights?

GT: It's probably going to be a two-part answer. Let's say I'm a new employee here at the company. I'm an IT support person and work in the southwest region of the company, and I've got responsibility to cover a three-state area with X number of offices. There's probably some information somewhere, either in the HR system or Active Directory, that tells me an office code, a department code, a regional code I'm probably associated with. If there's a policy in the company that says an IT administrator has access to all of the network closets within his areas...I can start building a role that pulls information from that authoritative source and turns it into an access level inside the access control system.

If I can take some information--this is where the heavy lifting of this stuff happens, a lot of up front consultation with the client to understand how their business works and what those rules are--but if I can say, all our IT guys in this region will have access to all these locations, and it's the same in our other regions, and there's a way in some source to identify their location, then I can build a grouping of doors, and calendars and clock schedules around it to say, okay, you're in this job role and you're based out of [the southwest region], you're going to get Monday through Friday, 8-5 access to these doors. I can automatically grant and take away that access level in the PACS based on the role.

Even if the employee doesn't leave the company but the role changes, I can remove that access. So if I can do that consistently and automate it and remove the manual entry of it from the system and lock that out, then I've really got something that's valuable at audit time because I can show you a repeatable process that follows my rules that can't be broken systematically. And it complies--there's no way for this person to get access to my data center once he quits that role. That's just part one of that answer.

SJW: I need to stop you there. So that role resides in Active Directory and you pull it into the physical access control system?

Greg: No, I'm taking information out of Active Directory. Think of me as having a look up table--I'm going to say a combination of this employee's department, location code, job title, equals in the look up table--give me access level 5 and access level 5 is all the doors in that grouping. That's how I'm doing it. I'm not writing rules in Active Directory or changing the schema of Active Directory or extending it...I'm looking at what's in there and determining through conversations with the client what the rules typically should be, and validating it, that this is really the right way to do this so that now I've got a role.

That gives me really good role-based access control. And if we're doing it right, we set up the system so that's the only way you get access levels added to your access control card. You have to be an active employee and you have to be in the right role and we use the look up table features in our little tool that we use to feed in authoritative sources, and now I'm giving you this access level.

That's going to work in probably 85% or better of the cases. But then there will be this 10-15 percent it doesn't fit. Then we implement a piece called workflow. It's not perfect either, but it'll get you darn close. So if I'm the IT guy just hired...but I'm here to work on a specific project that no one else in my role really works on, so I need access to the heart of the data center.

Well, I don't want to write a role for one person. In that case, I'm going to have a piece of work flow that sends the request to the owner of the data center. Think of it now as like voting in Outlook. If I ask you to vote, approve or disapprove something in Outlook, you can open it, read it, approve or disapprove it. I can automate almost 100 percent of the work flow piece so it comes back, and I can see the owner of that data center has approved this access level upgrade for Greg, so now I have a trail to that exception. Behind the scenes, I grant the access rights to that specific door on top of the other things Greg has in his role, so when the auditor comes around and asks who has access to the data center and why, I have this complete trail. We even have clients who do look-ahead reports and so the owner of an area has to re-validate who has access to it on a defined time frame, like every six months.

Role-based will do a fine job in most cases. And most companies have rules, and they have roles. They may not think of them that way, but when you start talking to them about how they grant access levels, we find out that they really do. They may not be documented, but they have them. That'll cover 85% or more of the cases we're looking at.

The outliers, after we identify them, it's a pretty straightforward piece of workflow to get those approvals done and to have the documentary trail on that too. So at the end of the day, the goal is to not be manually assigning access, but to have it completely automated so that everything gets tied back to that identity and there's a role associated with it that I can turn things on and off with.

SJW: Had either of you come prepared to talk about something you especially wanted to emphasize?

ER: We are passionate about convergence, because we see it more and more, and so few people out there seem to understand it.

SJW: What's the disconnect? What aren't they understanding?

ER: A lot of the physical access integrators don't understand the IT aspect of it, and the IT guys don't understand the physical access side of it.  A little while ago, an IT consulting company came to us and said we want to start buying and selling these smart cards, we want to see how the physical access side of it works, could you send us a card reader?

We asked, what are you going to do with the card reader? 'Well, we're going to hang it next to the door and see how it opens up the door.'

There's a whole lot more to it than that. That door has to be already built to handle a physical access solution. There are a lot of wires, a lot of hardware, a lot of software involved--you just can't hang the reader on the door. That just really reinforced that a lot of these IT guys don't really understand what's going on in the physical side. We've seen some IT shops that think they're going to get into physical access and then realize, oh my gosh, I need to know about all the local codes--safety codes, fire codes--that sort of information. One side doesn't seem to understand the other, and it's kind of funny to be on the sideline and watch people try to put together a plan.

On the physical integrator side, when they're going to sell the contact smart card, they just kind of deliver the badge and walk away. 'Here you go, now make it work.' And most customers are looking for a full solution.

SJW: Did you two gentlemen come to SecureNet with this convergence expertise or did you build it up?

GT: It's something we learned here. We were very fortunate, quite a few years ago, to get involved in the very early days of this. We were involved with an existing client who through the process of a merger wanted to merge two physical security systems the two companies had. At the same time, they were going to increase the desktop security of the two networks, put them together.

The IT department was going down a road to look at dual factor authentication to increase desktop security, and the physical security department was going down the road to put its two systems together. So they're both on the same road when they discovered the physical security guys were going to have to rebadge everybody, and the IT department wanted to issue a smart badge to everyone to control remote and desktop access.

So we were in the right place at the right time, about eight or nine years ago now, to work with putting all that together with what then in private industry was one of the first true enterprise single card solutions. So we learned an awful lot. We had to do some research, work with some technology partners to build some things to work with Active Directory and some of these authoritative sources we've been talking about. So we probably spent a couple years learning all this, but at the end of that, we were deploying it, living with it and supporting it on a daily basis.  We got the experience in the line of fire.


Systems Integrator SecureNet on Converging Identities Today

Creating a converged physical/logical identity and linking it to a single credential is possible today. That's very clear based on the experiences of Greg Thornbury, vice president, and Eric Rohleder, account manager, at Dallas-based SecureNet, Inc., a systems integrator. SecureNet first became involved with converged identities nearly a decade agosecurenet.jpg with a client trying to increase network and physical access security simultaneously--but nearly separately, until it became clear there was a way to leverage one credential to do both.

In this interview, conducted last month for our "One Person, One Identity, One Credential" feature by Sharon J. Watson, Rohleder and Thornbury discussed that implementation as well as what's driving identity convergence, how to accomplish roles-based physical access and the gulf between IT security and physical security expertise.

What follows is a transcription of our conversation, edited for clarity and length.


Sharon J. Watson: Tell me about the kinds of companies that come to you, either asking for a converged physical/logical identity management solution or to whom you recommend such solutions.

Eric Rohleder: It can be...companies realizing they don't have real control over who has access to their facilities. It could be they have quite a few locations and currently at each location they've got a standalone PACS, and they've got issues with employees...that have to get a different badge for each facility [they visit] or at the very least need to be entered into a different database to go to a facility.

They start to realize that's causing them some issues. It's real easy to get somebody into those databases. It's getting them out of all those different databases that's a real challenge....That can cause you problems on an audit.

Greg Thornbury: Although those issues are quite widespread and common given how PACS have been implemented, most of our clients find they have some sort of business driver that's making them look at this. In a lot of cases right now, it's regulatory; it may be in response to an audit like Eric mentioned. There's certainly a climate out there that tends to drive these things. It's not somebody saying, gee, this would be nice to do and getting the funds budgeted to do it on that basis. There's another driver pushing it in most cases.

ER: We're seeing activity from the energy sector [because of] the NERC CIPs. HSPD-12 has a lot of customers worried because there are rules in there saying only authorized people can physically have a badge and get to certain areas, and companies are trying to figure out how to control that. PCI compliance--if companies are taking orders via credit card, they have to control access to those physical files. One way they're doing that is on the logical side; on the other, auditors are asking, 'Where do you have that data stored? Over there in that room? Well, prove to me only the right people can get into that room.'

SJW: How often is it that folks with these challenges are also trying to control access to their logical systems with a physical credential?

GT: How often are we finding clients that want to use the same credential to gain access to the network as well as physical security? We're seeing a lot more of that. It's obviously not the mainstream way that everybody does things. The mainstream is still user name and password to get onto the network. But most companies, again, are finding a business driver, whether it's regulatory or security concerns, that are making them go to a higher level of security than what they can get with user name and password. Once they start looking at that, a lot of times they'll look at something with dual factor authentication or token authentication because that will also solve problems with remote access.

Then it becomes easy and natural for them to think, well, I'm carrying a credential of some kind, and it's pretty well known that there's technology out there to allow you to use that credential to get onto the network just the way you use user name and password today. So I think first of all, there's gotta be a driver that makes you start looking in that direction. But once you start looking that way, it's pretty well defined technology....

We're seeing more and more companies do it. As Eric mentioned, some are industry or vertical market specific. Health care has some big issues we see activity in, energy is another, the government is way down that road already. Big energy companies, oil and gas, health care, county and state government infrastructure are where we're doing a lot of work in this area.

SJW: As I 've been researching this area, it seems like to get to one physical credential to work with all the systems, all the physical access control systems (PACS) need to be connected or to have the physical credential mapped to one identity. So how do you approach that?

GT: There's probably not a simple answer to that. Typically what you'll find is there's a mix of technology out there. We'll find a client with multiple locations across the country with multiple standalone PACS, there's probably a pretty good chance they'll all be different. There's probably a better chance of that than finding out there's any kind of standardization going on.

But in a lot of cases, though the hardware and software behind each system is unique, there's probably a lot of commonality when it comes down to the card itself. The card business on the physical security side is so well dominated by HID that it's a pretty safe bet that a vast majority of those cards--unless they're really, really old systems--[are] HID cards.

So when we start doing analysis and survey work for clients, one of the first things we look at is where our commonality points will be. Our goal is to reuse as much of what's out there as possible. But typically we do run into situations in which components of those different systems have to be changed out or interfaced in order to tie these things together.

It's not so much critical that you have a single central database [for identity data]. You can lay a lot of different architecture over this, whether it's multiple servers and databases or a single server and database, but what you have to have is a common or a set of common authoritative sources and a way to communicate with these separate systems in a quick manner. You need to make changes to and from the authoritative source level and let that flow out.

In a lot of those cases, we'll look for the piece that's common, and that's often the credential. From there, it's pretty easy to look at what you can keep and what you can change.

The other side of it is it's a migration path. It doesn't happen overnight. You have time to scope out things and see how it's all going to fit. If you look at what identity management really means, there's a whole lot more to it than just defining an identity. There's roles, and business processes and rules around it, and it doesn't do any good at all for me to push changes to an identity in a database that's sitting across the United States if I still have someone over there who can walk in tomorrow and manually create a new identity and violate those business rules and processes. That's really the key to the system, being able to manage all that and be able to enforce all those policies and rules.

SJW: That authoritative source level--what typically does that turn out to be or do you have to create it?

GT: We haven't had to totally create one yet. That's the good news. In the client world we're working with, there's typically a sound and clean database and source for all the employee data. In eight out of ten times, for the employees, it's Active Directory. Everyone's using a Windows desktop environment, Active Directory manages those users. We're starting to see that as pretty standard. We have a clean, simple source to look to for employee data.

But a lot of companies are using contractors now as well. In a lot of cases, the contractors aren't managed inside of Active Directory in the same way employees are managed. Typically we'll have several authoritative sources: one for employees and a separate authoritative source for contractors. We've also got solutions that tie in visitor management systems creating visitor credentials and in that case, you've got even a third authoritative source for where the visitor data comes from.

I think we've really found only one client in our history who had a true authoritative source for every single person in their facility, whether employee or contractor. So that's really pretty rare.

SJW: Eric had mentioned earlier he'd read my interview with Dave Hansen over at CA, and Dave really thought Active Directory should not be the authoritative source. He said that put IT in control of creating identities and that to him was a problem. He thought that responsibility should be backed up to HR and its systems.

GT: We've done some deployments where we've pointed to HR systems like Peoplesoft, SAP, things like that. We typically have found, even when we're doing that, a lot of resistance on the part of the end user to allow us to really connect to that production HR system. So when we have done it, we've typically done it through some middle connection or step. A batch process at the end of the day or an instance of that database copied out there that's not running in production.

We do see a lot of Active Directory use. It's not perfect. It's got more accounts in it than you need--machine and administrator accounts. There are pretty easy ways to filter through that.

A lot of what we do as an integrator is speak to our client and do a lot of listening and find out what is the best authoritative source. In a lot of organizations, you're going to find that answer isn't going to be consistent. We're flexible. We've done it both ways. It's great to connect to HR; that's truly the originating point for a lot of that data. In other cases, it seems like HR doesn't keep up everything from an employee location standpoint the way IT does. In those cases, Active Directory may be the better source. At the end of the day, it's always the end user's decision. We try to help them and consult with them. We can look at different sources, so it doesn't really matter to us as long as it's the authoritative source.

ER: Another nice part of connecting to Active Directory, since we're talking about physical/logical convergence, is the logical access is usually tied to Active Directory. So you go to Active Directory and deactivate an identity, you know in one step you're going to get physical and logical turned off at the same time.

SJW: Where do physical access rights policies get created and how do they get linked to logical access rights?

GT: It's probably going to be a two-part answer. Let's say I'm a new employee here at the company. I'm an IT support person and work in the southwest region of the company, and I've got responsibility to cover a three-state area with X number of offices. There's probably some information somewhere, either in the HR system or Active Directory, that tells me an office code, a department code, a regional code I'm probably associated with. If there's a policy in the company that says an IT administrator has access to all of the network closets within his areas...I can start building a role that pulls information from that authoritative source and turns it into an access level inside the access control system.

If I can take some information--this is where the heavy lifting of this stuff happens, a lot of up front consultation with the client to understand how their business works and what those rules are--but if I can say, all our IT guys in this region will have access to all these locations, and it's the same in our other regions, and there's a way in some source to identify their location, then I can build a grouping of doors, and calendars and clock schedules around it to say, okay, you're in this job role and you're based out of [the southwest region], you're going to get Monday through Friday, 8-5 access to these doors. I can automatically grant and take away that access level in the PACS based on the role.

Even if the employee doesn't leave the company but the role changes, I can remove that access. So if I can do that consistently and automate it and remove the manual entry of it from the system and lock that out, then I've really got something that's valuable at audit time because I can show you a repeatable process that follows my rules that can't be broken systematically. And it complies--there's no way for this person to get access to my data center once he quits that role. That's just part one of that answer.

SJW: I need to stop you there. So that role resides in Active Directory and you pull it into the physical access control system?

Greg: No, I'm taking information out of Active Directory. Think of me as having a look up table--I'm going to say a combination of this employee's department, location code, job title, equals in the look up table--give me access level 5 and access level 5 is all the doors in that grouping. That's how I'm doing it. I'm not writing rules in Active Directory or changing the schema of Active Directory or extending it...I'm looking at what's in there and determining through conversations with the client what the rules typically should be, and validating it, that this is really the right way to do this so that now I've got a role.

That gives me really good role-based access control. And if we're doing it right, we set up the system so that's the only way you get access levels added to your access control card. You have to be an active employee and you have to be in the right role and we use the look up table features in our little tool that we use to feed in authoritative sources, and now I'm giving you this access level.

That's going to work in probably 85% or better of the cases. But then there will be this 10-15 percent it doesn't fit. Then we implement a piece called workflow. It's not perfect either, but it'll get you darn close. So if I'm the IT guy just hired...but I'm here to work on a specific project that no one else in my role really works on, so I need access to the heart of the data center.

Well, I don't want to write a role for one person. In that case, I'm going to have a piece of work flow that sends the request to the owner of the data center. Think of it now as like voting in Outlook. If I ask you to vote, approve or disapprove something in Outlook, you can open it, read it, approve or disapprove it. I can automate almost 100 percent of the work flow piece so it comes back, and I can see the owner of that data center has approved this access level upgrade for Greg, so now I have a trail to that exception. Behind the scenes, I grant the access rights to that specific door on top of the other things Greg has in his role, so when the auditor comes around and asks who has access to the data center and why, I have this complete trail. We even have clients who do look-ahead reports and so the owner of an area has to re-validate who has access to it on a defined time frame, like every six months.

Role-based will do a fine job in most cases. And most companies have rules, and they have roles. They may not think of them that way, but when you start talking to them about how they grant access levels, we find out that they really do. They may not be documented, but they have them. That'll cover 85% or more of the cases we're looking at.

The outliers, after we identify them, it's a pretty straightforward piece of workflow to get those approvals done and to have the documentary trail on that too. So at the end of the day, the goal is to not be manually assigning access, but to have it completely automated so that everything gets tied back to that identity and there's a role associated with it that I can turn things on and off with.

SJW: Had either of you come prepared to talk about something you especially wanted to emphasize?

ER: We are passionate about convergence, because we see it more and more, and so few people out there seem to understand it.

SJW: What's the disconnect? What aren't they understanding?

ER: A lot of the physical access integrators don't understand the IT aspect of it, and the IT guys don't understand the physical access side of it.  A little while ago, an IT consulting company came to us and said we want to start buying and selling these smart cards, we want to see how the physical access side of it works, could you send us a card reader?

We asked, what are you going to do with the card reader? 'Well, we're going to hang it next to the door and see how it opens up the door.'

There's a whole lot more to it than that. That door has to be already built to handle a physical access solution. There are a lot of wires, a lot of hardware, a lot of software involved--you just can't hang the reader on the door. That just really reinforced that a lot of these IT guys don't really understand what's going on in the physical side. We've seen some IT shops that think they're going to get into physical access and then realize, oh my gosh, I need to know about all the local codes--safety codes, fire codes--that sort of information. One side doesn't seem to understand the other, and it's kind of funny to be on the sideline and watch people try to put together a plan.

On the physical integrator side, when they're going to sell the contact smart card, they just kind of deliver the badge and walk away. 'Here you go, now make it work.' And most customers are looking for a full solution.

SJW: Did you two gentlemen come to SecureNet with this convergence expertise or did you build it up?

GT: It's something we learned here. We were very fortunate, quite a few years ago, to get involved in the very early days of this. We were involved with an existing client who through the process of a merger wanted to merge two physical security systems the two companies had. At the same time, they were going to increase the desktop security of the two networks, put them together.

The IT department was going down a road to look at dual factor authentication to increase desktop security, and the physical security department was going down the road to put its two systems together. So they're both on the same road when they discovered the physical security guys were going to have to rebadge everybody, and the IT department wanted to issue a smart badge to everyone to control remote and desktop access.

So we were in the right place at the right time, about eight or nine years ago now, to work with putting all that together with what then in private industry was one of the first true enterprise single card solutions. So we learned an awful lot. We had to do some research, work with some technology partners to build some things to work with Active Directory and some of these authoritative sources we've been talking about. So we probably spent a couple years learning all this, but at the end of that, we were deploying it, living with it and supporting it on a daily basis.  We got the experience in the line of fire.


No TrackBacks

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

2 Comments

While I don't disagree with your analysis. There are a number of issues which make this approach pretty much of a stretch for me.

After having reviewed a number of large organizations including governement systems, there are a number of issues which must be addressed. Historically, large scale organizations were built on acquistiion therby creating a very heterogenous physical access security picture across the corporate enterprise. I have seen over a 100 types, sizes, control mechanisms, software, devices, etc. In theory, these all perform the same function, in practice, they serve as local control of the environment for access control. There are a number of issues with this approach but here are just two. In the grand scheme of things access control is still locally controled. Responsibility for the building, base, gate, area or whatever is under the control of the local authority. This creates some "trust" issues in accepting a global badge or entry device.
There is also the issue of who manages the database? This is a highly complex problem for some companies etc. since they have contractual or government requirements for deactivating credentials both physical and logical on terminating an employee. This may not be termination from the company but merely terminating form a contract for whatever reason. The issue is quite complex and it does resside in HR but rights and privileges remain a difficult subject to approach since the issue corsses so many boundaries.

Hope this helps. It is meant to be constructive and thought provoking.

Leave a comment