Johnson Controls on Integrated Physical/Logical Identity Management

| 0 Comments | 0 TrackBacks
JCI logo.jpgIt's not just the IBMs, CAs, Suns and other heavy hitting IT firms that talk about authoritative data sources and roles-based policies. Johnson Controls, probably best known for wide-ranging building automation and physical security solutions, is talking "integrated identity management access control architectures" and their potential for improving security while cutting costs.  

Brandon Arcement, manager, global security technology for Johnson Controls, gave a webinar in early May entitled "Enhanced Identity & Compliance Management Delivered Through Systems Integration." His audience: physical security specialists.  His key point: linking logical and physical identities across disparate systems saves time and money while improving security and increasing compliance.

As part of our effort to explore physical/logical identity management convergence, Security Squared's Sharon J. Watson talked with Arcement on May 19 to learn more about Johnson Control's perspective on converging identity management across the IT and physical security worlds.

What follows is an edited, abridged transcript of our conversation.

Sharon J. Watson: What kinds of customers typically are you talking to about this kind of integrated access control architecture?

Brandon Arcement: The ones that really feel it, that know there has to be a solution out there, are the ones with a lot of disparity in their access control systems, or a lot of manual processes and a lot of labor spent managing identities. Those are the ones that feel it the most and say, gosh, there's got to be a solution. But quite honestly, there's value in it even for those customers who may not realize they have an issue. There's an ROI for [them]. A lot of people didn't even know they could be saving money, they didn't realize how much money they were spending.

SJW: That [description] sounds like it could apply to health care, airports--I see you've done work at Toronto Pearson.

BA: If you look at airports, most have one physical access control system but if you look at where they get their identity information from, an airport always has several if not hundreds of employers within that facility. You have all the restaurants, the different airlines, people who work for the city, people who work for the airport, they're all different HR systems or IT systems in different employers. So the airport [operator] has to get that information from everywhere, and it's very tight security as well. There are a tremendous amount of manual processes, so [an integrated identity management architecture] makes a lot of sense for airports.

Quantum Secure did that identity management overhaul [at Toronto Pearson] with Deloitte, but we're also working very closely with Quantum Secure. We've also done a lot of security work at Toronto airport, they're a big customer of ours on the more traditional security end, access control and CCTV.

SJW: You've talked about a single authoritative source of identity data. Do you find in this space you're competing with people like Sun, IBM, CA and Unisys, others that are talking about identity management and user provisioning?

BA: Not yet. And I'll tell you why: because we have the security domain expertise that they don't have, and they haven't really moved down into this space. We're not really moving up into that space yet. What we are doing is utilizing that infrastructure they've sold to many of our customers to manage identities across the IT space, to provision access control privileges as well.

They haven't shown much interest in moving to the physical security space, and they offer great value for the customers in the IT space. We aren't really moving there. We're just leveraging what they're doing there to expand it into the physical security realm as well.

SJW: Let's dive into that more. As I've been talking to IBM and Sun and researching provisioning on the IT or logical side, they do a lot of work on assigning logical access rights to someone, the applications they're allowed to get into, even down to a page of an application or a specific function. Typically, are you taking and tapping that policy data for your purposes?

BA: Sort of. They have a database that holds all the identity information, like your name, pay grade, title, who you report to, geographic location and so on. Based on those, they then set up rules that provision access for the IT space generally. What we can do, using vendors like Quantum Secure, we can take that identity information from a Sun, Novell, IBM, and use it to provision access across the physical space as well. It's an automatic connector that just pulls that information. We set up rules for how we're going to provision physical access control very similar to how they [provision logical access] in the IT space.

So just like you said, they can provision access down to the page or the link or the button, everything within the application is configurable. Same thing in the physical access control world. We can provision access down to the facility, to the building, to the door, to a specific area.

SJW: Are you getting any sense that folks on the IT side could get that granular too? Could they build that access into their databases, so it becomes the single source of all the access data, logical or physical?

BA: I know those companies you're talking about understand the IT world, they understand identity management there, but I don't know that they've had a focus on physical security, that they have the domain expertise to really tie into physical access control yet.

SJW: If you are able to be real granular in how you provision physical access, you could do interesting things integrating with the logical system, like denying [logical] access if a certain physical indicator isn't there--like they didn't swipe their badge at a particular door. When you get into that realm, which are the players who get the value picture?

BA: You really have to engage all stakeholders in a project like this pretty early on. IT is involved in almost every project we do now. It would be abnormal for IT not to be involved. Physical security is involved. There are other players, like risk management, business continuity, HR folks are sometimes involved. It can get pretty broad.

It can depend on the vertical market as well, depending on who else the end user thinks needs to be involved to create those policies.

SJW: How involved can that get, creating the policies and creating the ID data?

BA: They're two separate things. First there's cleansing the data. Your name exists in so many different databases [in so many variations] that if you're going to integrate them and combine them you have to make sure [the name] appears the same in all those databases--so that data needs to be cleansed. That can get pretty involved. There are some tricks and IT scripts you can use to ease that pain, but it's something to be aware of going into the project.

Thumbnail image for JCILargechart.jpgThen the other issue was creating the rules. You can get really in-depth and get hung up on creating the policies. What's important is that you install an infrastructure and an architecture that allow you flexibility to create and customize rules (see illustration, left). You'll probably know about 50% of [the rules] off the bat. There may be things you want to add and tweak down the road. So at the end of a year, hopefully you're 75% of the way there. Two years, you're 95% of the way there. So it's really the architecture and infrastructure that allow you the flexibility to create and customize the rules. But you won't get 100% of the policies put in right off the bat.

There will be things the customer will think of that they hadn't thought of before because the previous technology didn't allow it.

SJW: Do you have any examples of that, functions or capabilities [integrated physical/logical access management] gives them they didn't have before?

BA: One key thing is the ability to share real-time data across disparate systems. Before it wasn't something you thought of because the technology just didn't enable it, you couldn't fathom it--like not being able to log into a computer unless you're physically in the same location as your computer. You couldn't share data real-time like that [before] so it really wasn't easy to imagine that being possible.

An example might be a customer right now manually has to check whether a person has been to training before allowing them onto the factory floor. They have a training database, so they may always have done that process manually. They didn't think to integrate it into the provisioning process. But now they have a system that allows for automatic real time checking of that database, they might go back and say, we'd like to pull this into the mix now and during our provisioning process, do one more check against this training database and automate that as well. That's an example of something they might not think of when we first do the installation. They may buy the systems and the integration for a totally different reason, to solve some other pain point, but as they move down the road, they find out what's feasible.

SJW:
Let me go back to something: I understand you work to create the rules for the physical access. Could you foresee a point in time where...logical and physical provisioning could get tied closely together -where a person is assigned logical role X, these physical access rules are associated with logical role X, so we can assume if person gets logical role X, they should get physical role B.

BA: That's exactly right. I talked earlier about how we can grab from Sun or IBM or Novell information like name and physical location, but it's really configurable. We could only grab the name and this field X. And X is the role assigned by that system. Then we can just say, when it's X in this system, assign physical access privileges B. So we can grab as much or as little information as is in that system or we can grab information from multiple systems.

So physical access privileges can be automatically given based on one field...or we could give you physical access control privileges based on 50 different characteristics: title, pay grade, physical location, first name starting with the letter S and also information from that IT system regarding the privileges you have for logical access.

Often times, especially large organizations, they don't have just one IT system, they have multiple systems. You might be grabbing it from multiple places.

SJW: In a situation like Toronto Pearson and others with big disparate employee bodies to credential, I'm guessing some of those smaller businesses [under those roofs] might not have much of an identity management system but you'd still need to bring them in somehow.

BA: They still have some way of managing identities, though.

SJW: The image that came to mind was the little floral shop that's always inside a hospital lobby. I suppose as hospitals get more security conscious, those people might need badges, and it strikes me your system could be the primary ID point for people in those situations.

BA:
That's exactly right. There are really two types of identities in a hospital or an airport. There are what we call the trusted ones, the trusted identities that exist in the logical access control systems or that come from that authoritative data source, that HR system, that IT system.

Then there are also untrusted identities. They may be visitors, temporary contractors, or the floral shop people. Those are the ones that haven't gone through the background checks or the drug screening or all the other different things that authoritative data source [required] to let them in.  So those untrusted identities should probably have a separate process for being added to the system.

SJW: As physical and logical IDs get more converged, it seems being able to authenticate that identity is truly who you think it is becomes more important. What are you are seeing in terms of two factor or multi-factor authentication or what you are recommending as secure and practical to implement?

BA: In the airports, you see multifactor a lot, and you see card and pin used most frequently. The only other way to use multifactor is to use card and biometric, and we're seeing that quite a bit. There are a lot of airports that are doing that. We did a tremendous amount of work at Seattle-Tacoma airport where they have hundreds of biometric readers [and do] card and biometrics.

As biometric technologies get less expensive and the need to manage identities and know exactly who is where--not just that they have a card and PIN, but who they are--becomes more important, I think you'll see that proliferation.
JCI logo.jpgIt's not just the IBMs, CAs, Suns and other heavy hitting IT firms that talk about authoritative data sources and roles-based policies. Johnson Controls, probably best known for wide-ranging building automation and physical security solutions, is talking "integrated identity management access control architectures" and their potential for improving security while cutting costs.  

Brandon Arcement, manager, global security technology for Johnson Controls, gave a webinar in early May entitled "Enhanced Identity & Compliance Management Delivered Through Systems Integration." His audience: physical security specialists.  His key point: linking logical and physical identities across disparate systems saves time and money while improving security and increasing compliance.

As part of our effort to explore physical/logical identity management convergence, Security Squared's Sharon J. Watson talked with Arcement on May 19 to learn more about Johnson Control's perspective on converging identity management across the IT and physical security worlds.

What follows is an edited, abridged transcript of our conversation.

Sharon J. Watson: What kinds of customers typically are you talking to about this kind of integrated access control architecture?

Brandon Arcement: The ones that really feel it, that know there has to be a solution out there, are the ones with a lot of disparity in their access control systems, or a lot of manual processes and a lot of labor spent managing identities. Those are the ones that feel it the most and say, gosh, there's got to be a solution. But quite honestly, there's value in it even for those customers who may not realize they have an issue. There's an ROI for [them]. A lot of people didn't even know they could be saving money, they didn't realize how much money they were spending.

SJW: That [description] sounds like it could apply to health care, airports--I see you've done work at Toronto Pearson.

BA: If you look at airports, most have one physical access control system but if you look at where they get their identity information from, an airport always has several if not hundreds of employers within that facility. You have all the restaurants, the different airlines, people who work for the city, people who work for the airport, they're all different HR systems or IT systems in different employers. So the airport [operator] has to get that information from everywhere, and it's very tight security as well. There are a tremendous amount of manual processes, so [an integrated identity management architecture] makes a lot of sense for airports.

Quantum Secure did that identity management overhaul [at Toronto Pearson] with Deloitte, but we're also working very closely with Quantum Secure. We've also done a lot of security work at Toronto airport, they're a big customer of ours on the more traditional security end, access control and CCTV.

SJW: You've talked about a single authoritative source of identity data. Do you find in this space you're competing with people like Sun, IBM, CA and Unisys, others that are talking about identity management and user provisioning?

BA: Not yet. And I'll tell you why: because we have the security domain expertise that they don't have, and they haven't really moved down into this space. We're not really moving up into that space yet. What we are doing is utilizing that infrastructure they've sold to many of our customers to manage identities across the IT space, to provision access control privileges as well.

They haven't shown much interest in moving to the physical security space, and they offer great value for the customers in the IT space. We aren't really moving there. We're just leveraging what they're doing there to expand it into the physical security realm as well.

SJW: Let's dive into that more. As I've been talking to IBM and Sun and researching provisioning on the IT or logical side, they do a lot of work on assigning logical access rights to someone, the applications they're allowed to get into, even down to a page of an application or a specific function. Typically, are you taking and tapping that policy data for your purposes?

BA: Sort of. They have a database that holds all the identity information, like your name, pay grade, title, who you report to, geographic location and so on. Based on those, they then set up rules that provision access for the IT space generally. What we can do, using vendors like Quantum Secure, we can take that identity information from a Sun, Novell, IBM, and use it to provision access across the physical space as well. It's an automatic connector that just pulls that information. We set up rules for how we're going to provision physical access control very similar to how they [provision logical access] in the IT space.

So just like you said, they can provision access down to the page or the link or the button, everything within the application is configurable. Same thing in the physical access control world. We can provision access down to the facility, to the building, to the door, to a specific area.

SJW: Are you getting any sense that folks on the IT side could get that granular too? Could they build that access into their databases, so it becomes the single source of all the access data, logical or physical?

BA: I know those companies you're talking about understand the IT world, they understand identity management there, but I don't know that they've had a focus on physical security, that they have the domain expertise to really tie into physical access control yet.

SJW: If you are able to be real granular in how you provision physical access, you could do interesting things integrating with the logical system, like denying [logical] access if a certain physical indicator isn't there--like they didn't swipe their badge at a particular door. When you get into that realm, which are the players who get the value picture?

BA: You really have to engage all stakeholders in a project like this pretty early on. IT is involved in almost every project we do now. It would be abnormal for IT not to be involved. Physical security is involved. There are other players, like risk management, business continuity, HR folks are sometimes involved. It can get pretty broad.

It can depend on the vertical market as well, depending on who else the end user thinks needs to be involved to create those policies.

SJW: How involved can that get, creating the policies and creating the ID data?

BA: They're two separate things. First there's cleansing the data. Your name exists in so many different databases [in so many variations] that if you're going to integrate them and combine them you have to make sure [the name] appears the same in all those databases--so that data needs to be cleansed. That can get pretty involved. There are some tricks and IT scripts you can use to ease that pain, but it's something to be aware of going into the project.

Thumbnail image for JCILargechart.jpgThen the other issue was creating the rules. You can get really in-depth and get hung up on creating the policies. What's important is that you install an infrastructure and an architecture that allow you flexibility to create and customize rules (see illustration, left). You'll probably know about 50% of [the rules] off the bat. There may be things you want to add and tweak down the road. So at the end of a year, hopefully you're 75% of the way there. Two years, you're 95% of the way there. So it's really the architecture and infrastructure that allow you the flexibility to create and customize the rules. But you won't get 100% of the policies put in right off the bat.

There will be things the customer will think of that they hadn't thought of before because the previous technology didn't allow it.

SJW: Do you have any examples of that, functions or capabilities [integrated physical/logical access management] gives them they didn't have before?

BA: One key thing is the ability to share real-time data across disparate systems. Before it wasn't something you thought of because the technology just didn't enable it, you couldn't fathom it--like not being able to log into a computer unless you're physically in the same location as your computer. You couldn't share data real-time like that [before] so it really wasn't easy to imagine that being possible.

An example might be a customer right now manually has to check whether a person has been to training before allowing them onto the factory floor. They have a training database, so they may always have done that process manually. They didn't think to integrate it into the provisioning process. But now they have a system that allows for automatic real time checking of that database, they might go back and say, we'd like to pull this into the mix now and during our provisioning process, do one more check against this training database and automate that as well. That's an example of something they might not think of when we first do the installation. They may buy the systems and the integration for a totally different reason, to solve some other pain point, but as they move down the road, they find out what's feasible.

SJW:
Let me go back to something: I understand you work to create the rules for the physical access. Could you foresee a point in time where...logical and physical provisioning could get tied closely together -where a person is assigned logical role X, these physical access rules are associated with logical role X, so we can assume if person gets logical role X, they should get physical role B.

BA: That's exactly right. I talked earlier about how we can grab from Sun or IBM or Novell information like name and physical location, but it's really configurable. We could only grab the name and this field X. And X is the role assigned by that system. Then we can just say, when it's X in this system, assign physical access privileges B. So we can grab as much or as little information as is in that system or we can grab information from multiple systems.

So physical access privileges can be automatically given based on one field...or we could give you physical access control privileges based on 50 different characteristics: title, pay grade, physical location, first name starting with the letter S and also information from that IT system regarding the privileges you have for logical access.

Often times, especially large organizations, they don't have just one IT system, they have multiple systems. You might be grabbing it from multiple places.

SJW: In a situation like Toronto Pearson and others with big disparate employee bodies to credential, I'm guessing some of those smaller businesses [under those roofs] might not have much of an identity management system but you'd still need to bring them in somehow.

BA: They still have some way of managing identities, though.

SJW: The image that came to mind was the little floral shop that's always inside a hospital lobby. I suppose as hospitals get more security conscious, those people might need badges, and it strikes me your system could be the primary ID point for people in those situations.

BA:
That's exactly right. There are really two types of identities in a hospital or an airport. There are what we call the trusted ones, the trusted identities that exist in the logical access control systems or that come from that authoritative data source, that HR system, that IT system.

Then there are also untrusted identities. They may be visitors, temporary contractors, or the floral shop people. Those are the ones that haven't gone through the background checks or the drug screening or all the other different things that authoritative data source [required] to let them in.  So those untrusted identities should probably have a separate process for being added to the system.

SJW: As physical and logical IDs get more converged, it seems being able to authenticate that identity is truly who you think it is becomes more important. What are you are seeing in terms of two factor or multi-factor authentication or what you are recommending as secure and practical to implement?

BA: In the airports, you see multifactor a lot, and you see card and pin used most frequently. The only other way to use multifactor is to use card and biometric, and we're seeing that quite a bit. There are a lot of airports that are doing that. We did a tremendous amount of work at Seattle-Tacoma airport where they have hundreds of biometric readers [and do] card and biometrics.

As biometric technologies get less expensive and the need to manage identities and know exactly who is where--not just that they have a card and PIN, but who they are--becomes more important, I think you'll see that proliferation.

No TrackBacks

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

Leave a comment