Identity Management Rules Cloud, PACS and LACS: Brivo's Take

| 0 Comments | 0 TrackBacks

Page:   1   2  Next  »

The Cloud is hovering over ASIS this year, with a handful of educational sessions focusing on security services now available as hosted services or on how to ensure your software-as-a-service (SaaS) provider has properly secured its offering (aka, the data center it operates that holds your data).

Security Squared was interested in a different angle on the cloud: whether and how physical security professionals can use their tools to help their enterprises secure cloud access. For perspective and always-bracing honesty, we turned to Steve Van Till, CEO of Brivo Systems,
Thumbnail image for Thumbnail image for RGBbrivologo.jpg
a veteran at offering cloud-based physical access control and video surveillance. Here's a transcript of our conversation, edited for clarity:

***************

Sharon J. Watson, Security Squared: In the IT world, a really big issue related to securing the cloud is controlling what an employee or client does in the cloud: managing the access to the cloud, managing what they do once they get to that application that is on someone else's server. We've talked before about how many of your clients use your system to associate some logical data with a person's physical access: I paid my bill, therefore I am allowed into this section of the health club.

So it strikes me as very logical that we would associate physical information with what a person is allowed to do in a virtual space. That brings physical access control to my mind. So talk me through that a little bit. What are some of the challenges to making that happen? Why wouldn't physical security professionals say, hey, there must be a way to use this PACs to help with my company's challenges about securing identities in the cloud?

Steve Van Till, CEO, Brivo Systems:
The way I look at this whole world is that there are three circles. One is at the top: I would call that one identity management. Then there's one circle down and to the left that I would call logical access control and another one down and to the right that would be physical access control.

In this new universe that is emerging, I think identity management systems--and they can take many different shapes, they can be very small and inexpensive or be very expensive--the identity management system is really the primary authoritative data source. For each identity that's in there, there can be one or 100 or 1000 attributes associated with that individual. These attributes might include things like where they work, what their title is, what their role is at the company, all those kinds of things.

Then, with those known attributes about each person in the identity system, any other application, whether it's a logical access control application or physical access control application, can enforce policies that are based on all those attributes a person has. So what you see happening is that logical access and physical access systems are both peers of one another. They are both "relying parties"--that's the terminology used in the identity management space--they are both relying parties on the authoritative data source that's represented by the identity management system.
In any of these discussions in the identity management field, those are two very important concepts: authoritative source and then the relying party. Outside of the people who are doing identity management the right way, what happens in a lot of discussions is people start asking the question, "Well, can the PAC system do this and this and this, and then can the LAC system do this and this and this? Can they exchange information?"

Then what happens in most of those discussions is that the whole notion of authoritative source and relying party becomes very, very muddy. As soon as it does, nobody knows who's on first and what's on second anymore, because while the physical access control systems have some data, like this list of names, how does that then relate to the logical access? Which one is in charge? Which is offering what access to whom?

So the very first thing you need to do if you're building one of these systems or selling one of these systems or writing about them is be very clear about those three concepts: identity management, logical access and physical access. The identity management system always needs to be the authoritative source for identity information and any other associated attributes. The other folks, whoever they are--PACs, LACs, what have you-- are relying parties.

Now, some people might choose to combine one or more of those services inside a single product offering. That's again a confusing factor in the marketplace.  
You've really blurred the line, and then it becomes difficult to have a discussion about which product is actually doing what. I think is important is to start with a strong conceptual framework for what's actually going on in this space and then start asking questions about this product or that company.

On Identity as a Service


Van Till:
What happened is that there are probably 15 or 20 software as a service companies who have gone out and purchased this Oracle or Sun [identity management] stuff or somebody else's software, they've wrapped it inside of a website and now they're saying "John Q. Public, putting an identity management system in place for your company of 350 people is a lot more expensive and a lot more difficult than what you want to undertake. Why don't you just buy it from us as a service?"

So you're starting to see identity management as a service as a product offering but if you look at the market, what's happening is that history is repeating itself in the sense that you have all these different silos of applications emerging in the cloud just like they emerged in the corporation over the past 20 or 30 years. So now let's say I'm going to SaaS company A for identity management and to Brivo for my physical security management, I'm going to some Axis partner for video as a service, then to salesforce.com for CRM management as a service and so on and so forth. Now I've got 10 different software as a service offerings, and I've got my 350 employees, and I've got a mess on my hands because they all have different logins to all these different things and I can't do a single view.

So along come companies--Ping Identity would be a great example--that say what you really need to do as part of the identity management of your employees is also have single sign-on services that work in the cloud. So Ping has put together identity management plus single sign-on such that if you register all your people with Ping as the authoritative data source--who they are, what their privileges are--they can use a single login with any of the other SaaS applications your company might be using and [access to those] can be managed consistently from one place.  

Again, it gets back to that authoritative source. In that context, again unless someone's putting together a combined offering, I think the clear way to speak about this is that there is an identity management service, it probably is going to have a single sign-on capability associated with it, then all these other applications, whether logical or physical in nature, are really subservient to that identity management solution in so far as role-based permissions and privilege management are concerned.

Page:   1   2  Next  »

The Cloud is hovering over ASIS this year, with a handful of educational sessions focusing on security services now available as hosted services or on how to ensure your software-as-a-service (SaaS) provider has properly secured its offering (aka, the data center it operates that holds your data).

Security Squared was interested in a different angle on the cloud: whether and how physical security professionals can use their tools to help their enterprises secure cloud access. For perspective and always-bracing honesty, we turned to Steve Van Till, CEO of Brivo Systems,
Thumbnail image for Thumbnail image for RGBbrivologo.jpg
a veteran at offering cloud-based physical access control and video surveillance. Here's a transcript of our conversation, edited for clarity:

***************

Sharon J. Watson, Security Squared: In the IT world, a really big issue related to securing the cloud is controlling what an employee or client does in the cloud: managing the access to the cloud, managing what they do once they get to that application that is on someone else's server. We've talked before about how many of your clients use your system to associate some logical data with a person's physical access: I paid my bill, therefore I am allowed into this section of the health club.

So it strikes me as very logical that we would associate physical information with what a person is allowed to do in a virtual space. That brings physical access control to my mind. So talk me through that a little bit. What are some of the challenges to making that happen? Why wouldn't physical security professionals say, hey, there must be a way to use this PACs to help with my company's challenges about securing identities in the cloud?

Steve Van Till, CEO, Brivo Systems:
The way I look at this whole world is that there are three circles. One is at the top: I would call that one identity management. Then there's one circle down and to the left that I would call logical access control and another one down and to the right that would be physical access control.

In this new universe that is emerging, I think identity management systems--and they can take many different shapes, they can be very small and inexpensive or be very expensive--the identity management system is really the primary authoritative data source. For each identity that's in there, there can be one or 100 or 1000 attributes associated with that individual. These attributes might include things like where they work, what their title is, what their role is at the company, all those kinds of things.

Then, with those known attributes about each person in the identity system, any other application, whether it's a logical access control application or physical access control application, can enforce policies that are based on all those attributes a person has. So what you see happening is that logical access and physical access systems are both peers of one another. They are both "relying parties"--that's the terminology used in the identity management space--they are both relying parties on the authoritative data source that's represented by the identity management system.
In any of these discussions in the identity management field, those are two very important concepts: authoritative source and then the relying party. Outside of the people who are doing identity management the right way, what happens in a lot of discussions is people start asking the question, "Well, can the PAC system do this and this and this, and then can the LAC system do this and this and this? Can they exchange information?"

Then what happens in most of those discussions is that the whole notion of authoritative source and relying party becomes very, very muddy. As soon as it does, nobody knows who's on first and what's on second anymore, because while the physical access control systems have some data, like this list of names, how does that then relate to the logical access? Which one is in charge? Which is offering what access to whom?

So the very first thing you need to do if you're building one of these systems or selling one of these systems or writing about them is be very clear about those three concepts: identity management, logical access and physical access. The identity management system always needs to be the authoritative source for identity information and any other associated attributes. The other folks, whoever they are--PACs, LACs, what have you-- are relying parties.

Now, some people might choose to combine one or more of those services inside a single product offering. That's again a confusing factor in the marketplace.  
You've really blurred the line, and then it becomes difficult to have a discussion about which product is actually doing what. I think is important is to start with a strong conceptual framework for what's actually going on in this space and then start asking questions about this product or that company.

On Identity as a Service


Van Till:
What happened is that there are probably 15 or 20 software as a service companies who have gone out and purchased this Oracle or Sun [identity management] stuff or somebody else's software, they've wrapped it inside of a website and now they're saying "John Q. Public, putting an identity management system in place for your company of 350 people is a lot more expensive and a lot more difficult than what you want to undertake. Why don't you just buy it from us as a service?"

So you're starting to see identity management as a service as a product offering but if you look at the market, what's happening is that history is repeating itself in the sense that you have all these different silos of applications emerging in the cloud just like they emerged in the corporation over the past 20 or 30 years. So now let's say I'm going to SaaS company A for identity management and to Brivo for my physical security management, I'm going to some Axis partner for video as a service, then to salesforce.com for CRM management as a service and so on and so forth. Now I've got 10 different software as a service offerings, and I've got my 350 employees, and I've got a mess on my hands because they all have different logins to all these different things and I can't do a single view.

So along come companies--Ping Identity would be a great example--that say what you really need to do as part of the identity management of your employees is also have single sign-on services that work in the cloud. So Ping has put together identity management plus single sign-on such that if you register all your people with Ping as the authoritative data source--who they are, what their privileges are--they can use a single login with any of the other SaaS applications your company might be using and [access to those] can be managed consistently from one place.  

Again, it gets back to that authoritative source. In that context, again unless someone's putting together a combined offering, I think the clear way to speak about this is that there is an identity management service, it probably is going to have a single sign-on capability associated with it, then all these other applications, whether logical or physical in nature, are really subservient to that identity management solution in so far as role-based permissions and privilege management are concerned.

<!--nextpage-->

On Physical Security's Difficult Mind-Shift

Van Till: A lot of people in the physical security industry are used to looking at the world where their application, whether access control or video, is the king of the universe and everything else is a slave to it. That's a very parochial view, and it's very common. In this industry, what we are not really prepared to do mentally is make the leap to saying I'm just one in a community of applications, that insofar as identity is concerned, all are subservient to some other data source, and I have to play the game that way from now on. That's a mental shift that most people in our industry aren't prepared to make.

SJW: I understand the authoritative data source concept and the others relying on it. The authoritative source is the one that has all the information, the attributes, and access rules in systems like yours might be built on those attributes. But the physical access control system has a piece of data the authoritative source doesn't, which is that someone is physically present. How then can it share that piece of information with the identity management source so that it could have rules in it saying this person needs to be physically present to access this application?

Van Till:
That's pretty easy to do. That use case has been out there in the literature for quite a while.

SJW: Yes, in the literature.

Van Till
:  Right. There are a few companies who've done a little with that. We've never had one single customer ask us for that in 10 years. Every conference I go to that example is trotted out: well, if a person is in the building, then they can log onto the computer inside the building but if they're inside the building then their VPN access from outside can't be activated. Everybody trots out this example. I've yet to see a single customer who wanted it to work that way. That's just me.

This is a classic solution in search of a problem but the mechanics of it are very easy. Most modern contemporary access control systems have APIs on them. Those APIs can do things like say "person just entered the building," "person just exited the building," and they can share that with any other system that's out there. In the example of network access control, you could share that with the firewall or one of the other products in the Cisco suite or somebody else's suite of products.

All have policy engines that allow you to customize what the rules are for your company. So at that point, it's simply a matter of sharing the status of the individual with an existing network access control product. That's another whole world unto itself with its own acronyms, like NAC. So the NAC product can swallow status data from any source and change its behavior.  But again, that is a whole flat arena of cooperating applications. It is not that one is the boss or one is in charge.

The reverse case, which I think is more common, is that some attribute of the person has changed and now physical access has to be denied or logical access has to be denied. That tends to be employment status changes; security clearance changes, to offer a federal example; payment status changes, like with all the health clubs that we deal with.  Usually it's some logical attribute that changes, then that changes the physical access privileges they have or the network access privileges they have. We see a lot more real world examples that look like that. I think that's where most of the use cases are.

SJW
: Just to play devil's advocate: that example that's always trotted out about using physical access data as a prerequisite to log-in: You said the physical access world has not seen its systems as being one component reliant on a higher source of data, or as being peers to other systems. Is that why they haven't shared as much data?

Van Till
: I think that's part of it. I also think it's pretty rare that the physical security integrator is even having that conversation with the network administrator. Notwithstanding all the talk about convergence, I really don't think those two communities are talking quite as much as that example would require.

# # #

No TrackBacks

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

Leave a comment