Centralizing Physical/Logical Security Operations: A View from PSIM Vendor VidSys

| 0 Comments | 0 TrackBacks

David Fowler of VidSys discusses combining physical and logical security operations into a single center

"The risks they see to the organization don't know the boundaries between logical and physical security."

That's what security and business leaders in the Fortune 100 are realizing, says David Fowler, senior vice president, product development and marketing for VidSys, a physical information management system (PSIM) vendor.  

Risks to the enterprise may be caught by dozens of systems. On the physical side, there's video, access control, visitor management, building automation, life safety, etc. On the IT or logical side, security information management systems monitor network components as well as databases, applications and systems for intrusions, attacks, service disruption, viruses, access alerts, etc.  

What Security Squared is exploring is whether enterprises are making headway in correlating alarms between physical and logical security to determine whether a situation is under way and how best to address it. Sharon J. Watson spoke at length with Fowler (pictured)
DFowler.jpgearlier this week about the topic. Here's the first part of our conversation, edited for clarity and length. In part 2, appearing tomorrow, we talk more about who owns centralized security operations and the demands centralized ops place on logical and physical security organizations.

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

David Fowler: Centralized security operations is a topic that's gaining a lot of momentum, especially given what we're seeing on the integration among physical security devices. The logical to physical security integration has been road-blocked by the fact you couldn't get most of the physical security devices to talk to each other. So making all of physical talk to logical was even a bigger hurdle.

What a lot of people had done in the short term was they just reduced that to identity management: 'If I can just do access control, at least I've got some integration between my physical and logical side.'

But for the majority of the organizations we're dealing with, and we're dealing with some very big corporate organizations, Fortune 100 companies, they're looking for a way to go after risk management. The risks they see to the organization don't know the boundaries between logical and physical security. So ideally what they want is the ability to start with 'how do I manage my risks?' and then translate that to 'What do I need in an overall security or risk management solution that comes from the physical and logical side that can be pulled together to help me address those issues?'

So the first thing they run into is they can talk to some of the stuff between the logical and physical side but they're handcrafting the connections between them. What they would like to do is take what they've done in the past on SIM--the security information management activity--and pool that with emerging technologies in PSIM--physical security information management. They can bring the two of them together into a command center, then they could move up to a higher level and say, 'What's my risk, how do I translate that risk into policies I can manage with both of these technologies?' That's where some of the customer we're dealing with are going.

Sharon J. Watson: So if you have a PSIM system like yours and you've got the SIMs, do you largely have the problem licked?

DF: You have the two ingredients that I think are the meat of the stew. You've got the meat and potatoes. What you really need is the ability to pool those technologies or solutions into what really addresses the problems you're going after. Usually that's some kind of policy management definition you want to put in place. You can do that logically--you can do that on paper. You can say here's my risk, therefore here's my policy.

A policy might [state] 'the intellectual property I have within the building can only be accessed by someone who's physically resident within the building...and they can only do it from specific locations that are monitored by video cameras so we have a record of who was actually accessing it as opposed to, well, someone signed in.'

You can create a policy that says that's the way things ought to work, but then you have to manually enforce that policy and if you have a problem, then you have to go back and collect the data from multiple sources to determine what actually went wrong. The alternative to that is you establish what the policy is and then the policy gets translated into rules that pool what I know on the IT side with what I know on the physical security side such that when somebody goes to log in, it not only determines first, are they physically in the building; second, have they badged into the location they're supposed to be in; third, is there someone physically in that room [confirmed] from motion detection, let's say...then that ties to the logical log-in address the person is using.

SJW: Is that another layer of software that needs to perform those translations, that turns the policies into the rules?

DF: There are two ways it could be done. One way is you could choose one or the other. You could choose the policies on the SIM side and use that one, but then you have to pull the information from the physical security side. Or you could do the same thing on the physical security side and pull information from the logical side.  I think that's the way you'll see it done in the first phase. The logical and physical security systems will talk to each other and exchange information, and you'll pick one or the other for establishing your policies.

Over time, if an organization moves to a higher level risk management solution, then you might see a higher order policy definition that then translates into instructions for both. But in the short term, when you break these things down, what it turns out to be is that each side needs information from the other side.

There are always people who are going to be driving things from the logical side and others driving from the physical side. The best quote...that drove this home for me was a head of a global physical security operation for a Fortune 100 company said to me the IT department could care less about bomb blast coatings on building windows, so they're never going to be fully integrated with the physical security side and the concerns managed by that organization. That doesn't mean they don't share information and share policies but it's likely you're going to have two orgs managing different issues.

We're seeing the beginning of that in some of the RFPs that are coming out, where organizations are saying I'm willing to accept I have my logical security side and I have my physical security side but I want to know whatever solutions I pick will talk to each other and that I don't have to do one-off [connections between the logical system and each physical security system]. They really want just one connection between logical and physical, and they share the information.

We also see that [demand] even within the physical security side where organizations have segmented control of their physical security solutions. For instance, in a city environment, you have dispatch centers. They have a computer-aided dispatch system. For incoming 911 calls, that's really important to handle those calls quickly and dispatch someone. But you want that information to also be tracked into your incident management system because once you dispatch someone to that site, there may be an ongoing situation that you have to manage. It could involve a gunshot detection system, video cameras on the road, a park or a building, it might involve smoke detectors in a building with the fire department.

So there is a computer-aided dispatch component and there's a physical security situation management component, and the two need to be able to talk to each other even though in most situations they might operate independently of each other.

SJW: That brought up something I'm curious about. There's a fairly clear line between centralized security operations and incident management?

DF: I would say no. It is true that especially these days as organizations are consolidating their security operations that they're building out global security operations centers that may or may not be managing all of the incidents that are happening. But in that global security operations center, they are centralizing all of the information that's been worked and all the incidents, or what we would call situations that are being worked. We differentiate between an incident and a situation, in that an incident may be an alarm coming in but a situation is more likely a series of alarms that make up the actual problem. When you talk to most organizations, they say we have a lot of individual alarm incidents but at the end of the day the things we really worry about are the complex ones that represent situations.

So I'll give you a quick example of a model we're seeing now in a number of organizations. These would be more private sector as opposed to public. Three of the organizations we're working with right now are moving to a global security operations center for their worldwide operations. What they're doing is they're reducing the amount of security infrastructure they have to put in on a site-by-site basis by not manning all sites 24 by 7. They're creating "follow the sun" regional security operations centers, and these regional centers are up during the daylight hours or during the normal work hours and during the off hours, the global security operations center is monitoring the site. That's manned 24 by 7.

In that model, if there is a situation at a site after hours, they have all the information they need to dispatch someone locally. Because the system they're putting in--in this particular case, our software--are all browser based, a security operations manager in Hong Kong can jump on a computer anywhere, even from his home at night, to monitor everything that's going and be seeing the same things they're seeing at the global security operations center, and he can determine what he needs to do right from there.

SJW: So given that you're working with these Fortune 100 type companies, I'm curious as they're bringing information into those operations centers, how often have you seen them establish convergence between logical identity management systems and their physical identity management systems?

DF: I'd say very early stage. They're doing some rudimentary stuff, often it involves more of the provisioning type of activities, in other words, when I provision you to access the SAP system, I provision you to have a badge to access the building.

But the more sophisticated rules-based activities, especially when it reaches outside of just the access control system, that becomes a lot more difficult and usually they stop short of that. Most of the attention we've seen so far in the area has less to do with security and more to do with provisioning: How do I make it easy for the people who are responsible for granting badges and access rights to provision for a new employee, to address a change in an employee's status or to make sure that all rights are taken away when they're terminated.

SJW: In some places where security is more the top of mind concern, a couple of consultants had talked to me about how when you have the two identities tightly intertwined, you can correlate their activities better.

DF: Right.

SJW: So if you don't have those physical/logical identities tightly tied, how then in a centralized security operation are you able to say, hmm, that logical alarm ties to what happened over here with this the physical alert?

DF: In most cases, organizations are doing that manually today. Because their operations have been run by two different departments and they haven't pooled this stuff, the tendency is to say if I have an access violation control violation at the computer level, I'll track it back to a terminal, and then once I find out what terminal, I'll go over to the physical security guy and say, can you tell me who is badged in at that point in time to that building and potentially, can we bring up the recorded video to verify in fact the person who badged in is the person who is logged in. So you hear about a lot of it being done forensically as opposed to setting policies in advance.

There's no question, though, when you bring the physical and logical sides together and start sharing information, sharing identities is one of the first places that you go. Because that is, both from a provisioning perspective and in terms of being able to track things, what I would consider to be a critical component.

I'll give you some examples of where organizations are looking to go as they bring the two sides together. One that was brought up to us: they have badges for employees today that are location based. In other words, you badge into a building or a floor. And what they want to move into is proximity based or RFID-based badging where it's not only where you badge in but also where you've gone in the building.

That's particularly important if, as an example, I'm allowing visitors into a center where I have intellectual property I'm worried about. They want to go one step beyond that because in an emergency satiation, particularly if there were a terrorist attack or a fire in the building, they want to be able to get everybody out. One of the mechanisms they use for doing that is they can take the fire alarm or smoke detecting alarm or panic alarms that have gone off [and] automatically send messages out across the intercom or phone systems. They can send different messages to different floors or different groups based on who is there.

So if I know the terrorists are on the executive floor, I can send messages to all the other floors, and I can send a different message to the executive floor. That's the physical security side tapping in to get the identity information so I know who is on that floor based on the proximity badges.

The second part of this...at the gathering points outside the building, I can use portable detection systems to detect who is actually there and who is not there, and by virtue of that, I can keep a list of the people who haven't rallied at the point and can go back to the building and use the proximity system to locate where their badges are in the building. Then I can use the camera system to zero in on those locations to determine whether I have an employee down or I have someone who left their badge behind on their desk.

SJW: What I want to make sure I understand is...tying together the physical and logical identities...that activity would need to occur in another system, like a PACS that had identities that were linked to logical identities in an [IT] identity management system and the PSIM solution could attach to both of those?

DF: A slight change to that. That's certainly one scenario. But the more likely scenario is that the PSIM solution is managing all the access control as well. The physical devices and the ability to have one identity across all the physical devices, those are the kinds of things a PSIM solution can do. Then the logical coupling of that with the IT system, that would be something that PSIM would do as well.

Usually what happens when we get brought in is, they say we have the following access control systems, the following video systems, the following intrusion detection systems, fire alarms, building management, and so on, and then what we'll do is integrate all those things into one entity, which is the PSIM solution.  Then there's a set of rules they put in place for managing all of those devices. In other words, how do you know when you have a problem, how do you know when you have a situation. They tell us what those are and those become the rules in our system, and the system looks for those situations, for those alarms going off. Then it pops up as part of the instructions on what to do or automatically executes the instructions for what to do in those situations.

If in the course of that [the PSIM solution] needed information from the identity management system on the SIM side, on the logical side, then we would tap the logical security system on the shoulder and ask it for the information. Sometimes we do that automatically in advance, like we'll automatically set up with Active Directory so if all the identities are in Active Directory, we've already pulled the identities and established those within our system even before the particular situation might come up.

The reverse is also true. If there is a situation that may be initiating on the logical security side, they'll send us that alarm information, and we in turn will incorporate that into the development of whatever situation is being managed on our end.

SJW:  I understand there is that data flow, that you can pull the data where you need to. What I'm trying to understand is if the company itself has not done a good job of ensuring at the time of provisioning that a logical identity corresponds to a physical identity, can you overcome that?

DF: You can, but you are doing it on a point basis. In other words, if you don't have...let's say the customer happens to have Novell and has our solution. The lowest common denominator for integration would be both the applications are on the same screen in the command center. But that's not really integration.

The next level of integration we're likely to see is that both sides, the logical side and the physical side, have specific scenarios they're working off of. And in the course of those scenarios, they're looking for information from the other side. What they end up doing in most cases is establishing just the connection they need for the information that addresses the specific incidents. So it's not a generalized solution saying anything that's happening on logical is known in physical and anything in physical is known on logical. Not today--and probably not for the foreseeable future.

But organizations are sharing things like...I mentioned Active Directory. They're sharing directory information so that an identity on one side can be used as an identity on the other side. And alarms on one side can be shared with the other side mutually.

###

Part II in tomorrow's post: Who owns the centralized security operation?


David Fowler of VidSys discusses combining physical and logical security operations into a single center

"The risks they see to the organization don't know the boundaries between logical and physical security."

That's what security and business leaders in the Fortune 100 are realizing, says David Fowler, senior vice president, product development and marketing for VidSys, a physical information management system (PSIM) vendor.  

Risks to the enterprise may be caught by dozens of systems. On the physical side, there's video, access control, visitor management, building automation, life safety, etc. On the IT or logical side, security information management systems monitor network components as well as databases, applications and systems for intrusions, attacks, service disruption, viruses, access alerts, etc.  

What Security Squared is exploring is whether enterprises are making headway in correlating alarms between physical and logical security to determine whether a situation is under way and how best to address it. Sharon J. Watson spoke at length with Fowler (pictured)
DFowler.jpgearlier this week about the topic. Here's the first part of our conversation, edited for clarity and length. In part 2, appearing tomorrow, we talk more about who owns centralized security operations and the demands centralized ops place on logical and physical security organizations.

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

David Fowler: Centralized security operations is a topic that's gaining a lot of momentum, especially given what we're seeing on the integration among physical security devices. The logical to physical security integration has been road-blocked by the fact you couldn't get most of the physical security devices to talk to each other. So making all of physical talk to logical was even a bigger hurdle.

What a lot of people had done in the short term was they just reduced that to identity management: 'If I can just do access control, at least I've got some integration between my physical and logical side.'

But for the majority of the organizations we're dealing with, and we're dealing with some very big corporate organizations, Fortune 100 companies, they're looking for a way to go after risk management. The risks they see to the organization don't know the boundaries between logical and physical security. So ideally what they want is the ability to start with 'how do I manage my risks?' and then translate that to 'What do I need in an overall security or risk management solution that comes from the physical and logical side that can be pulled together to help me address those issues?'

So the first thing they run into is they can talk to some of the stuff between the logical and physical side but they're handcrafting the connections between them. What they would like to do is take what they've done in the past on SIM--the security information management activity--and pool that with emerging technologies in PSIM--physical security information management. They can bring the two of them together into a command center, then they could move up to a higher level and say, 'What's my risk, how do I translate that risk into policies I can manage with both of these technologies?' That's where some of the customer we're dealing with are going.

Sharon J. Watson: So if you have a PSIM system like yours and you've got the SIMs, do you largely have the problem licked?

DF: You have the two ingredients that I think are the meat of the stew. You've got the meat and potatoes. What you really need is the ability to pool those technologies or solutions into what really addresses the problems you're going after. Usually that's some kind of policy management definition you want to put in place. You can do that logically--you can do that on paper. You can say here's my risk, therefore here's my policy.

A policy might [state] 'the intellectual property I have within the building can only be accessed by someone who's physically resident within the building...and they can only do it from specific locations that are monitored by video cameras so we have a record of who was actually accessing it as opposed to, well, someone signed in.'

You can create a policy that says that's the way things ought to work, but then you have to manually enforce that policy and if you have a problem, then you have to go back and collect the data from multiple sources to determine what actually went wrong. The alternative to that is you establish what the policy is and then the policy gets translated into rules that pool what I know on the IT side with what I know on the physical security side such that when somebody goes to log in, it not only determines first, are they physically in the building; second, have they badged into the location they're supposed to be in; third, is there someone physically in that room [confirmed] from motion detection, let's say...then that ties to the logical log-in address the person is using.

SJW: Is that another layer of software that needs to perform those translations, that turns the policies into the rules?

DF: There are two ways it could be done. One way is you could choose one or the other. You could choose the policies on the SIM side and use that one, but then you have to pull the information from the physical security side. Or you could do the same thing on the physical security side and pull information from the logical side.  I think that's the way you'll see it done in the first phase. The logical and physical security systems will talk to each other and exchange information, and you'll pick one or the other for establishing your policies.

Over time, if an organization moves to a higher level risk management solution, then you might see a higher order policy definition that then translates into instructions for both. But in the short term, when you break these things down, what it turns out to be is that each side needs information from the other side.

There are always people who are going to be driving things from the logical side and others driving from the physical side. The best quote...that drove this home for me was a head of a global physical security operation for a Fortune 100 company said to me the IT department could care less about bomb blast coatings on building windows, so they're never going to be fully integrated with the physical security side and the concerns managed by that organization. That doesn't mean they don't share information and share policies but it's likely you're going to have two orgs managing different issues.

We're seeing the beginning of that in some of the RFPs that are coming out, where organizations are saying I'm willing to accept I have my logical security side and I have my physical security side but I want to know whatever solutions I pick will talk to each other and that I don't have to do one-off [connections between the logical system and each physical security system]. They really want just one connection between logical and physical, and they share the information.

We also see that [demand] even within the physical security side where organizations have segmented control of their physical security solutions. For instance, in a city environment, you have dispatch centers. They have a computer-aided dispatch system. For incoming 911 calls, that's really important to handle those calls quickly and dispatch someone. But you want that information to also be tracked into your incident management system because once you dispatch someone to that site, there may be an ongoing situation that you have to manage. It could involve a gunshot detection system, video cameras on the road, a park or a building, it might involve smoke detectors in a building with the fire department.

So there is a computer-aided dispatch component and there's a physical security situation management component, and the two need to be able to talk to each other even though in most situations they might operate independently of each other.

SJW: That brought up something I'm curious about. There's a fairly clear line between centralized security operations and incident management?

DF: I would say no. It is true that especially these days as organizations are consolidating their security operations that they're building out global security operations centers that may or may not be managing all of the incidents that are happening. But in that global security operations center, they are centralizing all of the information that's been worked and all the incidents, or what we would call situations that are being worked. We differentiate between an incident and a situation, in that an incident may be an alarm coming in but a situation is more likely a series of alarms that make up the actual problem. When you talk to most organizations, they say we have a lot of individual alarm incidents but at the end of the day the things we really worry about are the complex ones that represent situations.

So I'll give you a quick example of a model we're seeing now in a number of organizations. These would be more private sector as opposed to public. Three of the organizations we're working with right now are moving to a global security operations center for their worldwide operations. What they're doing is they're reducing the amount of security infrastructure they have to put in on a site-by-site basis by not manning all sites 24 by 7. They're creating "follow the sun" regional security operations centers, and these regional centers are up during the daylight hours or during the normal work hours and during the off hours, the global security operations center is monitoring the site. That's manned 24 by 7.

In that model, if there is a situation at a site after hours, they have all the information they need to dispatch someone locally. Because the system they're putting in--in this particular case, our software--are all browser based, a security operations manager in Hong Kong can jump on a computer anywhere, even from his home at night, to monitor everything that's going and be seeing the same things they're seeing at the global security operations center, and he can determine what he needs to do right from there.

SJW: So given that you're working with these Fortune 100 type companies, I'm curious as they're bringing information into those operations centers, how often have you seen them establish convergence between logical identity management systems and their physical identity management systems?

DF: I'd say very early stage. They're doing some rudimentary stuff, often it involves more of the provisioning type of activities, in other words, when I provision you to access the SAP system, I provision you to have a badge to access the building.

But the more sophisticated rules-based activities, especially when it reaches outside of just the access control system, that becomes a lot more difficult and usually they stop short of that. Most of the attention we've seen so far in the area has less to do with security and more to do with provisioning: How do I make it easy for the people who are responsible for granting badges and access rights to provision for a new employee, to address a change in an employee's status or to make sure that all rights are taken away when they're terminated.

SJW: In some places where security is more the top of mind concern, a couple of consultants had talked to me about how when you have the two identities tightly intertwined, you can correlate their activities better.

DF: Right.

SJW: So if you don't have those physical/logical identities tightly tied, how then in a centralized security operation are you able to say, hmm, that logical alarm ties to what happened over here with this the physical alert?

DF: In most cases, organizations are doing that manually today. Because their operations have been run by two different departments and they haven't pooled this stuff, the tendency is to say if I have an access violation control violation at the computer level, I'll track it back to a terminal, and then once I find out what terminal, I'll go over to the physical security guy and say, can you tell me who is badged in at that point in time to that building and potentially, can we bring up the recorded video to verify in fact the person who badged in is the person who is logged in. So you hear about a lot of it being done forensically as opposed to setting policies in advance.

There's no question, though, when you bring the physical and logical sides together and start sharing information, sharing identities is one of the first places that you go. Because that is, both from a provisioning perspective and in terms of being able to track things, what I would consider to be a critical component.

I'll give you some examples of where organizations are looking to go as they bring the two sides together. One that was brought up to us: they have badges for employees today that are location based. In other words, you badge into a building or a floor. And what they want to move into is proximity based or RFID-based badging where it's not only where you badge in but also where you've gone in the building.

That's particularly important if, as an example, I'm allowing visitors into a center where I have intellectual property I'm worried about. They want to go one step beyond that because in an emergency satiation, particularly if there were a terrorist attack or a fire in the building, they want to be able to get everybody out. One of the mechanisms they use for doing that is they can take the fire alarm or smoke detecting alarm or panic alarms that have gone off [and] automatically send messages out across the intercom or phone systems. They can send different messages to different floors or different groups based on who is there.

So if I know the terrorists are on the executive floor, I can send messages to all the other floors, and I can send a different message to the executive floor. That's the physical security side tapping in to get the identity information so I know who is on that floor based on the proximity badges.

The second part of this...at the gathering points outside the building, I can use portable detection systems to detect who is actually there and who is not there, and by virtue of that, I can keep a list of the people who haven't rallied at the point and can go back to the building and use the proximity system to locate where their badges are in the building. Then I can use the camera system to zero in on those locations to determine whether I have an employee down or I have someone who left their badge behind on their desk.

SJW: What I want to make sure I understand is...tying together the physical and logical identities...that activity would need to occur in another system, like a PACS that had identities that were linked to logical identities in an [IT] identity management system and the PSIM solution could attach to both of those?

DF: A slight change to that. That's certainly one scenario. But the more likely scenario is that the PSIM solution is managing all the access control as well. The physical devices and the ability to have one identity across all the physical devices, those are the kinds of things a PSIM solution can do. Then the logical coupling of that with the IT system, that would be something that PSIM would do as well.

Usually what happens when we get brought in is, they say we have the following access control systems, the following video systems, the following intrusion detection systems, fire alarms, building management, and so on, and then what we'll do is integrate all those things into one entity, which is the PSIM solution.  Then there's a set of rules they put in place for managing all of those devices. In other words, how do you know when you have a problem, how do you know when you have a situation. They tell us what those are and those become the rules in our system, and the system looks for those situations, for those alarms going off. Then it pops up as part of the instructions on what to do or automatically executes the instructions for what to do in those situations.

If in the course of that [the PSIM solution] needed information from the identity management system on the SIM side, on the logical side, then we would tap the logical security system on the shoulder and ask it for the information. Sometimes we do that automatically in advance, like we'll automatically set up with Active Directory so if all the identities are in Active Directory, we've already pulled the identities and established those within our system even before the particular situation might come up.

The reverse is also true. If there is a situation that may be initiating on the logical security side, they'll send us that alarm information, and we in turn will incorporate that into the development of whatever situation is being managed on our end.

SJW:  I understand there is that data flow, that you can pull the data where you need to. What I'm trying to understand is if the company itself has not done a good job of ensuring at the time of provisioning that a logical identity corresponds to a physical identity, can you overcome that?

DF: You can, but you are doing it on a point basis. In other words, if you don't have...let's say the customer happens to have Novell and has our solution. The lowest common denominator for integration would be both the applications are on the same screen in the command center. But that's not really integration.

The next level of integration we're likely to see is that both sides, the logical side and the physical side, have specific scenarios they're working off of. And in the course of those scenarios, they're looking for information from the other side. What they end up doing in most cases is establishing just the connection they need for the information that addresses the specific incidents. So it's not a generalized solution saying anything that's happening on logical is known in physical and anything in physical is known on logical. Not today--and probably not for the foreseeable future.

But organizations are sharing things like...I mentioned Active Directory. They're sharing directory information so that an identity on one side can be used as an identity on the other side. And alarms on one side can be shared with the other side mutually.

###

Part II in tomorrow's post: Who owns the centralized security operation?

No TrackBacks

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

Leave a comment